jiebi/CodeConvo huggingface dataset:
Change:
''; }; <del> nuclear = callPackage ../applications/audio/nuclear { }; </del> nuclei = callPackage ../tools/security/nuclei { }; nullmailer = callPackage ../servers/mail/nullmailer {

Discussion:
Package name: nuclear Latest released version: 0.6.31 Current version on the unstable channel: 0.6.30 Current version on the stable/release channel: 0.6.30 <!-- 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]:
Made a PR, would appreciate it if you tested it - I don't use nuclear very often at the moment.
Change:
buildInputs = let # example externalDeps': [ { name = "CRYPTO"; dep = pkgs.openssl; } ] externalDeps' = lib.filter (dep: !lib.isDerivation dep) self.externalDeps; <del> in [ lua.pkgs.luarocks ] </del> <ins> in [ luarocks_bootstrap ] </ins> ++ buildInputs ++ lib.optionals self.doCheck ([ luarocksCheckHook ] ++ self.nativeCheckInputs) ++ (map (d: d.dep) externalDeps')

Discussion:
luarocks exists that other luarocks packages can depend on. When trying to build a rockspec that depends on luarocks with , it fails. The entry in the generated luarocks config contains an entry for luarocks, but luarocks doesn't recognise it and tries to download the package instead. I have created a repository to reproduce it with: Run A workaround is to use to generate a expression for luarocks (), and to add that package to the 's instead of the package from nixpkgs. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for creating the test repo, it's helpful. I've looked at the generated LUAROCKSCONFIG and all looks good and I think luarocks just doesn't recognize the installed luarocks because of My first thought would have been to rename the current luarocks into a luarocksbootstrap and add a generated derivation, for which we could run the tests without the cyclic dependency luarocks -busted -luarocks. While this might be the best outcome longterm, I am looking into the quickfix which would be to generate the manifest for the current luarocks
Change:
src = looking-glass-client.src; sourceRoot = "${looking-glass-client.src.name}/module"; <del> patches = lib.optional (kernel.kernelAtLeast "6.4") [ ./linux-6-4-compat.patch ]; </del> hardeningDisable = [ "pic" "format" ]; nativeBuildInputs = kernel.moduleBuildDependencies;

Discussion:
Steps to reproduce the behavior: kvmfr <!-- 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]:
Change:
<ins> diff --git a/scripts/msmtpq/msmtpq b/scripts/msmtpq/msmtpq index bcb384e..dbaf1b5 100755 --- a/scripts/msmtpq/msmtpq +++ b/scripts/msmtpq/msmtpq @@ -92,6 +92,8 @@ if [ ! -v MSMTPQ_LOG ] ; then fi fi [ -d "$(dirname "$MSMTPQ_LOG")" ] || mkdir -p "$(dirname "$MSMTPQ_LOG")" + +JOURNAL=@journal@ ## ====================================================================================== ## msmtpq can use the following environment variables : @@ -144,6 +146,7 @@ on_exit() {                          # unlock the queue on exit if the lock was ## display msg to user, as well ## log() { +  local NAME=msmtpq local ARG RC PFX PFX="$('date' +'%Y %d %b %H:%M:%S')" # time stamp prefix - "2008 13 Mar 03:59:45 " @@ -161,10 +164,19 @@ log() { done fi +  if [ "$JOURNAL" = "Y" ]; then +    for ARG; do +      [ -n "$ARG" ] && +        echo "$ARG" | systemd-cat -t "$NAME" -p info +    done +  fi + if [ -n "$RC" ] ; then             # an error ; leave w/error return [ -n "$LKD" ] && lock_queue -u   # unlock here (if locked) [ -n "$MSMTPQ_LOG" ] &&  echo "    exit code = $RC" >> "$MSMTPQ_LOG" # logging ok ; send exit code to log +    [ "$JOURNAL" = "Y" ] &&  +      echo "exit code= $RC" | systemd-cat -t "$NAME" -p emerg exit "$RC"                       # exit w/return code fi } </ins>

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: msmtp <!-- 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.8.22 desired version: 1.8.23 <!-- 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:
import ./make-test-python.nix { name = "zram-generator"; <del> nodes.machine = { pkgs, ... }: { environment.etc."systemd/zram-generator.conf".text = '' [zram0] zram-size = ram / 2 ''; systemd.packages = [ pkgs.zram-generator ]; systemd.services."systemd-zram-setup@".path = [ pkgs.util-linux ]; # for mkswap </del> <ins> nodes.machine = { ... }: { zramSwap = { enable = true; priority = 10; algorithm = "lz4"; swapDevices = 2; memoryPercent = 30; memoryMax = 10 * 1024 * 1024; }; </ins> }; testScript = '' machine.wait_for_unit("systemd-zram-setup@zram0.service") <del> assert "zram0" in machine.succeed("zramctl -n") assert "zram0" in machine.succeed("swapon --show --noheadings") </del> <ins> machine.wait_for_unit("systemd-zram-setup@zram1.service") zram = machine.succeed("zramctl --noheadings --raw") swap = machine.succeed("swapon --show --noheadings") for i in range(2): assert f"/dev/zram{i} lz4 10M" in zram assert f"/dev/zram{i} partition  10M" in swap </ins> ''; }

Discussion:
Project description In the author says, In 2020 the zram-generator doesn't seem to have had any releases. In the meantime, it's gone from initial release version 0.2.0 up to the somewhat-mature version 1.1.2. It's probably a good time to port this to zram-generator. Metadata homepage URL: source URL: license: mit platforms: linux
Change:
substituteInPlace lxqt-config-appearance/configothertoolkits.cpp  --replace 'QStringLiteral("gsettings'  'QStringLiteral("${glib.bin}/bin/gsettings' <ins> substituteInPlace lxqt-config-input/keyboardlayoutconfig.h  --replace '/usr/share/X11/xkb/rules/base.lst'  '${xkeyboard_config}/share/X11/xkb/rules/base.lst' </ins> ''; passthru.updateScript = lxqtUpdateScript { inherit pname version src; };

Discussion:
When using lxqt, I cannot add keyboard layouts to . . button, and you'll see an empty list. After pressing button there should be a list of languages. As I can see, this happens, because the path to the is hard-coded in the lxqt itself. Probably, this file should be patched, then the issue will be resolved.
Please, test the fix in
Sorry, I'm a bit newbie with the nixos, I don't know how to test it Maybe you can tell me how to do it? Then I'll do it ASAP
Usually I test changes to desktop environments with a virtual machine. I need a local copy of the nixpkgs repository. I get a copy of the PR branch also prepare a configuration file for a basic machine: I build the system as a virtual machine: finally I run the virtual machine:
Change:
# them with our own. let <del> version = "3.8.5"; </del> <ins> version = "3.6.9"; </ins> sha256 = { <del> "x86_64-linux" = "1r0wz2fsx2piasl04qsgwbl88bi0ajr0dm2swbslxwkf789vk18y"; "i686-linux" = "1dvfgp9dg3frhwmchwa6fyws4im9vgicchfsv0zzflvc7rm9fcig"; </del> <ins> "x86_64-linux" = "1i260mi40siwcx9b2sj4zwszxmj1l88mpmyqncsfa72k02jz22j3"; "i686-linux" = "0qqc8qbfaighbhjq9y22ka6n6apl8b6cr80a9rkpk2qsk99k8h1z"; </ins> }."${stdenv.system}" or (throw "system ${stdenv.system} not supported"); arch =

Discussion:
Dropbox does not work for me after the last update to version to 3.8.5 (commit ). The daemon starts, but no activity at all can be observed (it doesn't sync nor start the notification applet). If I start the old version that I still have in the store (3.6.9) it works. I run nixos on 32bit. I made several attempt: unlink/relink the computer from the dropbox site; restart with fresh ~/.dropbox and ~/Dropbox dirs; etc. Nothing works.
/cc author
does output anything?
also, which channel are you on? I just set up a nixos-unstable 32bit vm with dropbox 3.8.8 (not yet pushed) and it works fine
It's probably, because with 3.8.4, dropbox' qt dependency has been upgraded to 5.4, while current nixos-stable is still on 5.3 I bet you're on stable, right? Not sure if we should backport qt 5.4 to stable, or just downgrade dropbox to 3.6.9 and hope it keeps working till there is a new stable release.
Change:
}; }; <del> Gtk3ImageView = buildPerlPackage { </del> <ins> Gtk3ImageView = buildPerlPackage rec { </ins> pname = "Gtk3-ImageView"; <del> version = "6"; </del> <ins> version = "9"; </ins> src = fetchurl { <del> url = "mirror://cpan/authors/id/R/RA/RATCLIFFE/Gtk3-ImageView-6.tar.gz"; sha256 = "0krkif9i3hrgjdskw05pcks40fmb43d21lxf4h8aclv0g8z647f0"; </del> <ins> url = "mirror://cpan/authors/id/A/AS/ASOKOLOV/Gtk3-ImageView-${version}.tar.gz"; sha256 = "sha256-0dxe0p1UQglq+xok7g4l2clJ9WqOHxCeAzWD65E0H9w="; </ins> }; buildInputs = [ pkgs.gtk3 ]; propagatedBuildInputs = [ Readonly Gtk3 ]; <del> checkInputs = [ TestDifferences ImageMagick TryTiny TestMockObject CarpAlways pkgs.librsvg ]; </del> <ins> checkInputs = [ TestDifferences TestDeep ImageMagick TryTiny TestMockObject CarpAlways pkgs.librsvg ]; </ins> checkPhase = '' ${pkgs.xvfb-run}/bin/xvfb-run -s '-screen 0 800x600x24'  make test

Discussion:
Shutter fails to build, looks like an issue with Imagemagick. Steps to reproduce the behavior: Expect that it should build, it was working on my last generation. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Maintainer information: Probably related to
'shutter' is outdated in nixpkgs, perhaps we should start with a package update.
That would be nice but I think the problem is due to changes in perl packages
i tested and fixes this
I'll update shutter but will make the pr after the above pr has been merged
Change:
sqlite xdg_utils ] ++ ( <del> with pythonPackages; [ </del> <ins> with python3Packages; [ </ins> apsw beautifulsoup4 css-parser

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: calibre <!-- 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: 4.23.0 desired version: 5.6 <!-- 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:
pango pipewire udev <ins> wayland </ins> xdg-utils xorg.libxcb zlib

Discussion:
I am running Brave with with ozone/wayland (see for how to achieve that). Brave 1.26.77 was fine, while 1.27.111 crashes with Steps to reproduce the behavior: Brave with Wayland () 1.27.111 to run Should start as Wayland client (I always check with ) I checked the underlying .deb package we are using. The only change in dependencies I could find was . Replacing our with did not fix it. Here is the output where I observed that: Please run and paste the result.
r-ryantm is a bot. Ping the real maintainers
Thanks for the notice. pinging
I can reproduce this on 1.30.89:
Still happens:
with applied fails with
I can confirm that fixes this.
Change:
, google_talk_plugin, fribid, gnome3/*.gnome_shell*/ , esteidfirefoxplugin , vlc_npapi <ins> , libudev </ins> }: ## configurability of the wrapper itself

Discussion:
No gamepads are detected in firefox. firefox-bin and chromium work fine. go to in firefox System: 17.03.1395. (Gorilla) Nix version: nix-env (Nix) 1.11.11 Nixpkgs version: "17.03.1395." Sandboxing enabled: true
I second.
Have you confirmed that gamepad support is enabled within Firefox's config? To do so, go to the URL about:config, then search for gamepad.
Yes. It's also been enabled by default for a long time now.
Change:
sed -i 's:compiler=.*:compiler=${targetPackages.stdenv.cc}/bin/${targetPackages.stdenv.cc.targetPrefix}c++:'  $out/share/openmpi/mpic++-wrapper-data.txt <ins> '' + lib.optionalString fortranSupport '' </ins> sed -i 's:compiler=.*:compiler=${gfortran}/bin/${gfortran.targetPrefix}gfortran:'   $out/share/openmpi/mpifort-wrapper-data.txt

Discussion:
Describe the bug I'm on a mission to get (and thence ) compiling on M1 Macs, and having fixed , the next stumbling block is 4.1.1. Sadly, the build fails with , presumably related to . To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. Screenshots Additional context This works fine when built for x8664 on the same machine. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(steve): nixpkgs: Maintainer information:
Submitted PR which disables Fortran support for OpenMPI on aarch64-darwin. Would that fix the issue for you or do you require Fortran?
This seems to be the build failure:
I actually have no idea if I require Fortran. I mean, presumably it's enabled for some reason, so I'm a little wary of disabling it on only one platform/arch combination: that feels like an atypical workaround.
To reproduce: I wonder if the gcc maintainers can offer any insight?
seems to hint at the stack-protector hardening, so perhaps something like could work around that? (no idea what's the real cause though, and I have no Darwin machine at hand)
You were right! Sent a PR in
Change:
]; propagatedUserEnvPkgs = [ (lib.getBin kinit) ]; postFixup = <del> let k3bPath = lib.makeBinPath [ cdrdao cdrtools dvdplusrwtools libburn normalize sox transcode vcdimager ]; </del> <ins> let binPath = lib.makeBinPath [ cdrdao cdrtools dvdplusrwtools libburn normalize sox transcode vcdimager flac ]; libraryPath = lib.makeLibraryPath [ cdparanoia ]; </ins> in '' <del> wrapProgram "$out/bin/k3b" --prefix PATH : "${k3bPath}" </del> <ins> wrapProgram "$out/bin/k3b"      --prefix PATH : "${binPath}"  --prefix LD_LIBRARY_PATH : ${libraryPath} </ins> ''; }

Discussion:
If Flac is installed, K3b should provide Flac encoder as an external audio encoder. See: is indeed a propagated build input of : So I suppose in principle it should work. However, could it be that doesn't find the executable properly on NixOS: Any ideas how to fix? Open K3b. Go to Settings -Configure K3B -Plugins Find K3B External Audio Encoder and click on the Configure icon There should be Flac option on the list, but the list is empty. Please run and paste the results.
I copied the command from the K3b link in the original post: I this as an external audio encoder. Tried to use it but the ripping stopped and showed an error immediately:
Here is a full log from the following steps: Launch K3b Choose the audio CD Choose start ripping Select Flac (that I have defined manually) as the format Start ripping Error is raised Close dialogs and exit K3b
I tried adding and on the PATH by adding them on this line: Still, the same error.
I tried with other file formats too, I still get the same error that libcdparanoia could not be loaded.
It probably uses dlopen to load . Therefore it either needs to be to LDLIBRARYPATH: or needs to be marked as required with patchelf: will not work here and is wrong.
Thanks, I made a pull request.
Change:
configFile = if (cfg.configFile != null) then cfg.configFile else configFile'; preStart = '' <del> install ${configFile} /run/${RuntimeDirectory}/ddclient.conf </del> <ins> install --mode=600 --owner=$USER ${configFile} /run/${RuntimeDirectory}/ddclient.conf </ins> ${lib.optionalString (cfg.configFile == null) (if (cfg.protocol == "nsupdate") then '' <del> install ${cfg.passwordFile} /run/${RuntimeDirectory}/ddclient.key </del> <ins> install --mode=600 --owner=$USER ${cfg.passwordFile} /run/${RuntimeDirectory}/ddclient.key </ins> '' else if (cfg.passwordFile != null) then '' "${pkgs.replace-secret}/bin/replace-secret" "@password_placeholder@" "${cfg.passwordFile}" "/run/${RuntimeDirectory}/ddclient.conf" '' else ''

Discussion:
The NixOS module for ddclient installs the config file world-readable, since commit . This results in the following warning from ddclient: Enable the NixOS ddclient module: When ddclient runs, will appear world-readable as system: host os: multi-user?: sandbox: version: channels(bfo): channels(root): nixpkgs:
Should that not be reopened? Is including and replacing with in ExecStartPre like this: a valid solution? I'm not sure if the user name is guaranteed to be unique
Oh yeah, and the above PR was reverted in too
Still getting this warning.
Change:
patches = [ ./ssh_path.patch ./mosh-client_path.patch <del> ./utempter_path.patch </del> # Fix build with bash-completion 2.10 ./bash_completion_datadir.patch ];

Discussion:
A follow up to It seems like is not getting updated when tmux sessions begin/end. Relevant links: Steps to reproduce the behavior: and note the results. a different shell, open a new tmux session: exiting tmux, run again and note that the results are the same. Tmux user sessions to show up in , , and , as is custom in other OSes. n/a n/a <!-- 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.
Change:
inherit (gnome) empathy; <ins> emptty = callPackage ../applications/display-managers/emptty {}; </ins> endeavour = callPackage ../applications/office/endeavour { }; enhanced-ctorrent = callPackage ../applications/networking/p2p/enhanced-ctorrent { };

Discussion:
Project description A simple to use cli display manager Metadata source URL: license: MIT platforms: linux
I got a video on adding a package to nixpgks here: Go applications are generally easy to add
Is that free for grabs? I'ld like to start contributing to NixOS, this one looks pretty straightforward to start with.
Seems so. :+1::rocket: Shall I assign the issue to you?
Yes, please.
Change:
pysdl2 requests send2trash <ins> setproctitle </ins> ] ++ lib.optional withDiscordRPC pypresence; makeWrapperArgs = [

Discussion:
Hi, hope I have completed the correct fields! <!-- Initial version of 6.7.1 with updated version at 7.01 --- <!-- There is currently no PR in for this update. --- The Linux desktop music player from the future Name: tauonVersion: 6.7.1Licenses: nix-env -iA current version: 6.7.1 desired version: 7.0.1 HI any update to tauon if you have time, would be greatly appreciated :) I also do not get a tauon icon showing up in gnome 4.x.x and have to exec from the command line instead...wondered if this was by design :)
Tried it out and updated the derivation while at it. I don't think I'll be using this in the long run though, since it seems to have problems with wayland and replaygain inconsistencies between file formats.
I guess it doesn't show up in the gnome dashboard because the derivation does not install a desktop file. There seems to be one in the extra/ dir in the upstream repo but that needs some adapting to work on NixOS.
Thanks for trying, although it seems to be working fine on one of my arch machines running wayland? Don't use replaygain so can't comment. In what way does the desktop file need adjusting, as, in my experience, the tauon dev has been very receptive and amenable in the past. Is the way to test?
It mostly works but I have a mixed-DPI setup and running with the X11 backend in Xwayland is notoriously blurry on scaled monitors which is a bit annoying. The native wayland backend in SDL does not have that problem but SDL also does not handle DPI changes in any way so when moving between screens with different scaling factors, first the viewport goes out of sync with window size and once it relayouts itself it does not rescale for the new DPI. I reported the replaygain issue and that indeed got fixed in a matter of hours. I usually just fetch and build PRs manually but yes, from a glance at the docs seems to do all that in one command.
Thanks for creating heads up v7.1 out overnight if you still have the pull out
v7.1.1 is out and appears to have some of your requested changes included already ...
It indeed is:
Hope the new stuff works
Change:
hash = "sha256-9QYo7jGk9iWr26j0qPQCqYsJ+vLXAsO4Xs7+7VT9/yc="; }; <del> propagatedBuildInputs = with python3.pkgs; [ configshell rtslib ]; </del> <ins> nativeBuildInputs = [ wrapGAppsNoGuiHook gobject-introspection ]; buildInputs = [ glib ]; propagatedBuildInputs = with python3.pkgs; [ configshell rtslib pygobject3 ]; </ins> postInstall = '' install -D targetcli.8 -t $out/share/man/man8/

Discussion:
it's impossible to use due to an import error: Steps to reproduce the behavior: to run eg ratbagctl "shows something". (i.e. current mouse hardware/mapping etc.) (no gui, cli only) I (may) need because it has infos/options that are not yet fully implemented in Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

When trying to launch whipper it instead fails with the following trace: Steps to reproduce the behavior: or any equivalent way of running the whipper program Clearly, I expect the program to execute without an error. I bisected the error and the bug was introduced in which bumped . <!-- 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]:
Note: Adding to double-wraps all executables, but allows to run successfully.
Also no double-wrapping.

As title says, openrazer-daemon no longer work after update. Steps to reproduce the behavior: system -daemon fail to start. Openrazer-daemon start on boot. If applicable, add screenshots to help explain your problem. Manually calling openrazer-daemon -Fv print me this: <!-- 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]:
overlay fix for anyone who have this issue.
This overlay fix worked for me, thank you!