jiebi/CodeConvo huggingface dataset:
Change:
postFixup = '' substituteInPlace $out/etc/hp/hplip.conf --replace /usr $out <del> '' + stdenv.lib.optionalString (!withPlugin) '' # A udev rule to notify users that they need the binary plugin. # Needs a lot of patching but might save someone a bit of confusion: </del> <ins> # Patch udev rules: # with plugin, they upload firmware to printers, # without plugin, they complain about the missing plugin. </ins> substituteInPlace $out/etc/udev/rules.d/56-hpmud.rules  --replace {,${bash}}/bin/sh  <del> --replace {/usr,${coreutils}}/bin/nohup  </del> <ins> --replace /usr/bin/nohup ""  </ins> --replace {,${utillinux}/bin/}logger  --replace {/usr,$out}/bin '';

Discussion:
Printing with a HP Color LaserJet printer fails due to a crash in the filter when using the driver "hpcups 3.19.1" With the "CUPS+Gutenprint v5.2.14" driver printing works. Try to print anything, a test page would do Please run and paste the results. oops.. let's try again:
I'm having the same problem, and made some observations: hplip 3.18.5 (used in release-18.09) works, even if compiled with pkgs from release-19.03 Here's a bug report with a proposed patch: is probably here: I didn't come around to test any of those patches thoug as I have only very limited access to my HP printer.
Change:
renderAction = name: attrs: renderSection "Desktop Action ${name}" (preprocessAction attrs); actionsRendered = lib.mapAttrsToList renderAction actions; <ins> extension = if type == "Directory" then "directory" else "desktop"; </ins> content = [ mainSectionRendered ] ++ actionsRendered; in writeTextFile { <del> name = "${name}.desktop"; destination = "/share/applications/${name}.desktop"; </del> <ins> name = "${name}.${extension}"; destination = "/share/applications/${name}.${extension}"; </ins> text = builtins.concatStringsSep "n" content; checkPhase = ''${buildPackages.desktop-file-utils}/bin/desktop-file-validate "$target"''; })

Discussion:
A .desktop file gets always written, even if is set to "Directory". Steps to reproduce the behavior: xdg .directory entry in home-manager .e.g like so: an error because the written file is a .desktop file and not a .directory file xdg.desktopEntries is supposed to write a .directory file instead of a .desktop file <!-- 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.
Issue can be fixed by the following pull request:
Change:
buildPythonPackage rec { pname = "sopel"; <del> version = "6.3.1"; </del> <ins> version = "6.5.3"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "1swvw7xw8n5anb8ah8jilk4vk1y30y62fkibfd9vm9fbk45d1q48"; </del> <ins> sha256 = "4d8c1dc7e9cad73afc40d849484bc0f626aad6557951b1a0cff437af442ccb99"; </ins> }; buildInputs = [ pytest ];

Discussion:
Ran . For some reason there are pylint tests running for ~8 minutes that eventually end up in a failure. <details<summaryPyLint test failures</summary</detailson pylint (indirectly?); running for ~10 minutes as part of package installation process.
This will need to be backported to 18.09 as the latest version released by Hydra is broken too
The tests still fails even after the above patch applied. <details<summaryHere is the log</summary</detailsHere is the patch I used: Edit: the original patch is working on the python-unstable branch so I guess it's OK
I pushed a fix to the branch: . The fix for is currently in the branch: .
Change:
<del> { stdenv, fetchurl </del> <ins> { stdenv, fetchFromGitHub </ins> , localBios ? true, nasm ? null , sdlSupport ? true, SDL ? null }: assert sdlSupport -> (SDL != null); <del> stdenv.mkDerivation { </del> <ins> stdenv.mkDerivation rec{ </ins> pname = "8086tiny"; version = "1.25"; <del> src = fetchurl { url ="http://www.megalith.co.uk/8086tiny/downloads/8086tiny_125.tar.bz2"; sha256 = "0kmq4iiwhi2grjwq43ljjk1b1f1v1x9gzrgrgq2fzfsj7m7s6ris"; </del> <ins> src = fetchFromGitHub { owner = "adriancable"; repo = pname; rev = "c79ca2a34d96931d55ef724c815b289d0767ae3a"; sha256 = "00aydg8f28sgy8l3rd2a7jvp56lx3b63hhak43p7g7vjdikv495w"; </ins> }; buildInputs = with stdenv.lib;

Discussion:
Describe the bug Homepage is down, current src link is dead. Project moved to the author's GitHub. I have no clue how to even use this package. It's one of the first you see on the "Search NixOS Packages" webpage though, and the dead links & abandoned expression has been a thorn in my eye for awhile now. I'll prolly step up and fix it myself in afew months if noone else wants to do it. To Reproduce Steps to reproduce the behavior: package expression / search on NixOS packages page. any of the links. Installation itself still works. Expected behavior A maintained package. :slightlyfrowningface: Screenshots Not really applicable. Additional context See above. Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(bt1cn): nixpkgs: Maintainer information:
Change:
owner = "cielong"; repo = "pyfx"; rev = "refs/tags/v${version}"; <del> hash = "sha256-BXKH3AlYMNbMREW5Qx72PrbuZdXlmVS+knWWu/y9PsA="; </del> <ins> hash = "sha256-Q5ihWnoa7nf4EkrY4SgrwjaNvTva4RdW9GRbnbsPXPc="; </ins> }; postPatch = '' <del> rm src/pyfx/model/common/jsonpath/*.{g4,interp,tokens} antlr -Dlanguage=Python3 -visitor -o src/pyfx/model/common/jsonpath/ *.g4 </del> <ins> rm src/pyfx/model/common/jsonpath/*.py # upstream checks in generated files, remove to ensure they were regenerated antlr -Dlanguage=Python3 -visitor src/pyfx/model/common/jsonpath/*.g4 rm src/pyfx/model/common/jsonpath/*.{g4,interp,tokens} # no need to install </ins> ''; pythonRelaxDeps = true; <del> nativeBuildInputs = [ antlr4 setuptools ]; </del> <ins> build-system = [ setuptools ]; nativeBuildInputs = [ antlr4 ]; </ins> propagatedBuildInputs = [ antlr4-python3-runtime

Discussion:
python-fx fails at runtime, while doing its initial imports. Steps to reproduce the behavior: (hash is of as-of-writing nixpkgs-unstable) pyfx tui opens. Doesn't happen when e.g. installing current python-fx with pip on arch linux. (I considered packaging instead, but only found more breakage there. Anyway, I wouldn't be terribly sad if the answer to this is "Package abandonned, will be removed".) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I have not used the TUI as so far only served as dependency for . Looks like
I poked around and I don't think that's the same issue at all. (It's the same cause, an old generated file is lying around, but it's a different old generated file.) The prePatch is pretty fishy, it first removes the antlr-related files and then invokes antlr. Fixing that runs into a few type errors, which can be fixed: Now you'd think those type errors are due to the new antler version, but that's only partially true? Downgrading still requires some patching. If I have time I'll submit a PR fixing this, but just patching out the type checks from the feels wrong, so I might consult with upstream first.
Change:
]; nativeBuildInputs = [ <ins> autoPatchelfHook </ins> pkg-config which wrapGAppsHook3

Discussion:
The package for the Ares emulator doesn't seem to include Vulkan packages so it will return if you try to run a Nintendo 64 game. Other cores that don't use Vulkan are unaffected Steps to reproduce the behavior: Ares N64 game error in console glitched or black screen The game works ! see similar issue: Ares issue before I realized it was likely NixOS: GPU: RX 6800 Driver install setup: <!-- 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:
pkgsMusl = true; pkgsStatic = true; pkgsCross = true; <ins> pkgsx86_64Darwin = true; </ins> pkgsi686Linux = true; pkgsLinux = true; pkgsExtraHardening = true;

Discussion:
We found (because it broke our build in Lix) that the following nixpkgs lib test is broken. It is run through some derivation in the test suite somewhere; finding that is an exercise to the reader, but it is included underneath somewhere. Run the following on any platform; it has been observed with this command on aarch64-darwin and x8664-linux: Then you will get an infinite output deepening like the following: Eventually it will segfault or otherwise exceed the recursion limit. We checked that this reproduces on Lix , Nix 2.18, and Nix 2.22, so it is not a Nix implementation bug for any reasonable value of "nix implementation". Steps to reproduce the behavior: the above command from a checkout of nixpkgs. ??? overflow! We don't think this is a regression from , but instead, that broken stuff was exposed as broken by actually running it on other platforms than x8664-linux. Evaluate as normal as is the case for other values of . If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Not really a maintainers list as I don't see one, but people who touched the file or the infra recently: Please run and paste the result. Note that this is not a Lix bug. system: host os: multi-user?: sandbox: version: channels(jade): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Since I have aarch64-darwin and aarch64-linux and I exposed this, I'll take a look at this tonight.
Please try with , I was able to use that command until I got:
Perhaps also check that this feature. You might need to sprinkle some more in a similar way
Thank you for mentioning that, I got it to pass on Darwin
Change:
# Note that you should always try building haskell-language-server after updating it here, since # some of the overrides in pkgs/development/haskell/configuration-nix.nix may # need to be updated/changed. <ins> # # Remember to split out different updates into multiple commits </ins> set -eo pipefail

Discussion:
Describe the bug , a nested dependency, requires < 4.1.14. To Reproduce
Can probably be closed now?
Yes, I thought that would happen automatically.
I just bumped on (something very similar to?) this:
Change:
AudioScan = buildPerlPackage { pname = "Audio-Scan"; <del> version = "1.01"; </del> <ins> version = "1.05"; </ins> src = fetchurl { <del> url = "mirror://cpan/authors/id/A/AG/AGRUNDMA/Audio-Scan-1.01.tar.gz"; hash = "sha256-gxJyAnHHrdxLvuwzEs3divS5kKxjYgSllsB5M61sY0o="; </del> <ins> url = "https://github.com/Logitech/slimserver-vendor/raw/public/8.3/CPAN/Audio-Scan-1.05.tar.gz"; hash = "sha256-9YXC8GHPRWKlV8emmTke7RB0HhiCbALmZQqtQFLcBi4="; </ins> }; buildInputs = [ pkgs.zlib TestWarn ]; env.NIX_CFLAGS_COMPILE = "-I${pkgs.zlib.dev}/include"; NIX_CFLAGS_LINK = "-L${pkgs.zlib.out}/lib -lz"; meta = { <del> description = "Fast C metadata and tag reader for all common audio file formats"; </del> <ins> description = "Fast C metadata and tag reader for all common audio file formats, slimserver fork"; homepage = "https://github.com/Logitech/slimserver-vendor"; </ins> license = with lib.licenses; [ gpl2Plus ]; }; };

Discussion:
I try to use slimserver with the tidal plugin. Slimserver looks normally (e.g the webui works), but it spams the log with and squeezelite isn't outputting any audio when i try to play something (without any error logs) Steps to reproduce the behavior: and run slimserver the tidal plugin and run squeezelite to play something I expect listening to audio but it just keeps silent. The logspam only starts as soon as i try to play something. But then it never stops even if i disconnect all players. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Which nixos release or branch are you on? Can you try using a radio station or local media as an alternative to the tidal plugin?
I'm on unstable from today. Radio and local media work fine.
I am also encountering this issue with the qobuz plugin. Also I haven't figured out why, but indexing doesn't work for me, but if i try to play a local file (finding it via the file system option) I also get similar errors complaining about not being found etc.
When I went to spin this up I discovered that library importing was failing with the same error. After some troubleshooting another vendored version of this library was found. Cleaning this up and upgrading AudioScan to the slimserver fork resolved library importing, and I verified Qobuz is also playing. and can you test this PR to see if it fixes your issues? Thanks! Feel free to comment or reopen if still having this issue.
i just tested the pr and can confirm that the tidal works fine now. Thank you very much!
Change:
<ins> { lib, buildNpmPackage, fetchFromGitHub }: buildNpmPackage rec { pname = "husky"; version = "8.0.3"; src = fetchFromGitHub { owner = "typicode"; repo = "husky"; rev = "v${version}"; hash = "sha256-KoF2+vikgFyCGjfKeaqkC720UVMuvCIn9ApDPKbudsA="; }; npmDepsHash = "sha256-u1dndTKvInobva+71yI2vPiwrW9vqzAJ2sDAqT9YJsg="; meta = with lib; { description = "Git hooks made easy 🐶 woof!"; homepage = "https://github.com/typicode/husky"; changelog = "https://github.com/typicode/husky/releases/tag/v${version}"; license = licenses.mit; maintainers = with maintainers; [ dit7ya ]; }; } </ins>

Discussion:
Project description Modern native git hooks made easy Husky improves your commits and more woof! You can use it to lint your commit messages, run tests, lint code, etc... when you commit or push. Husky supports . Zero dependencies and lightweight (6 kB) Powered by modern new Git feature (core.hooksPath) Follows and best practices regarding autoinstall User-friendly messages Optional install Like husky 4, supports macOS, Linux and Windows Git GUIs Custom directories Monorepos Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, windows
Change:
homepage = "http://pandas.pydata.org/"; description = "Python Data Analysis Library"; license = stdenv.lib.licenses.bsd3; <del> maintainers = with stdenv.lib.maintainers; [ raskin fridh ]; </del> <ins> maintainers = with stdenv.lib.maintainers; [ raskin fridh knedlsepp ]; </ins> platforms = stdenv.lib.platforms.unix; }; }

Discussion:
fails to install because tests fail. The failing test is the clipboard test that is meant to be disabled on darwin through . This is not actually disabling the test but rather forcing it to fail, but this can be fixed with a small change. Then we reach a different failing test: I'm not sure if this is darwin specific, nixpkgs specific, or a known bug in . System: OSX Sierra 10.12.4 (16E195) Nix version: 1.11.6 Nixpkgs version: 17.03.1052.
I can't reproduce the issue on NixOS, and I didn't find an issue on the pandas tracker about it either. I did see some similar issues when ran against numpy 1.12 or a different version of numexpr.
From the environment I can see that the version of numpy is 1.11.3.
This may be related to a bug in numpy (numpy/numpy) that was fixed in numpy 1.12.1. I'm trying to build again against that version and I'll see if that fixes it.
I needed to fix pytables first to get to the error you are describing:

Probably only broken when darwin build sandbox is enabled.
Similar as before?
Looks familiar. I recall fixing it last time, but that was before support for expression / derivation specific sandbox profiles was .
is this still the problem in current master?
This is broken, because yields . I couldn't actually find in darwin-nixpkgs. Is there none? Is this the missing command?
The test states: Perhaps we can just skip this test in nixpkgs too?
Change:
enableParallelBuilding = true; preConfigure = '' <ins> find -name Makefile.in | xargs sed -i '/^TMPDIR=/d' </ins> find . -name '*.sh' -or -name '*.in' -or -name '*.c' -or -name configure | xargs sed -i  -e 's@/bin/ls@${coreutils}/bin/ls@g'  -e 's@/bin/rm@${coreutils}/bin/rm@g'

Discussion:
Describe the bug ncftp fails to build on nixos-unstable To Reproduce to install ncftp on current nixos-unstable Expected behavior ncftp build should succeed Screenshots Additional context 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 Maintainer information:
Change:
PrivateDevices = true; PrivateUsers = true; <del> ProtectClock = true; </del> <ins> # Disabled as it does not allow Jellyfin to interface with CUDA devices # ProtectClock = true; </ins> ProtectControlGroups = true; ProtectHostname = true; ProtectKernelLogs = true;

Discussion:
When enabling transcoding via NVENC I get the error below (see screenshots) I looked further into the transcoding logs and found that ffmpeg is erroring with this message: . I remember NVENC transcoding in the past. Steps to reproduce the behavior: jellyfin NVENC playback transcoding a video which requires transcoding Playback working with transcoding happening on the GPU instead of the CPU. ! ! I have an Nvidia GTX 950. output: (see screenshots:
I have the same issue, I tried to run the exact same command that jellyfin uses, using , but it works fine, so I don't know what's causing this
See my comment here: It is something with the systemd hardening we apply in nixpkgs for that module.
Thanks, I'll disable it on my system to make it work
Okay, for everyone waiting for this to be fixed ~upstream~, add this in your to fix NVDEC and NVENC:
Is this an upstream issue, though? It seems like only our hardening is at fault. (In case this sounds rude: I couldn't find a better way to word this, and my apologies.)
No, you're right I wrongly used the word "upstream", I meant "in nixos" Though in this case , but it only affect debian AFAIK, but they will probably have the same issues as us
can you please try the PR and confirm it solves the issue please?
I left
Change:
<ins> { lib, rustPlatform, fetchFromGitHub, installShellFiles }: rustPlatform.buildRustPackage rec { pname = "pueue"; version = "0.1.5"; src = fetchFromGitHub { owner = "Nukesor"; repo = pname; rev = "v${version}"; sha256 = "03aj4vw8kvwqk1i1a4kah5b574ahs930ij7xmqsvdy7f8c2g6pbq"; }; nativeBuildInputs = [ installShellFiles ]; cargoSha256 = "1y33n0dmrssv35l0apfq1mchyh92cfbzjarh0m8zb2nxwhvk7paw"; postInstall = '' installShellCompletion utils/completions/pueue.{bash,fish} --zsh utils/completions/_pueue ''; meta = with lib; { description = "A daemon for managing long running shell commands"; homepage = "https://github.com/Nukesor/pueue"; license = licenses.mit; maintainers = [ maintainers.marsam ]; }; } </ins>

Discussion:
Project description Pueue is a command line queue management tool for sequential and parallel execution of long running tasks.  Installation Vector This package is conventionally installed through or , so it should be packaged like other Python programs. Metadata homepage URL: source URL: license: MIT platforms: Unix
Hey. Maintainer from pueue here. Pueue has been rewritten in Rust. It can now easily be deployed via binary or clean installed via cargo.
Hi great to hear from you! And it's nice to hear that Pueue has been rewritten in Rust. It would be easier to package if it had an upstream file. Would you be willing to provide one?
Hey Sorry for the delay, I wanted to release a new version that fixes some things before pinging you. is .
Wow, thanks much appreciated. Here's the expression I'm using: When I build it I get a build failure in the dependency of all things: It looks like CI is red for this build too, but for a different reason: Is this error familiar to you? If not it might be something about how works in Nix. My main hunch is that I'm implicitly using a that does not meet the Rust=1.39 constraint of .
Travis' pipeline failed on the old python version :D Totally forgot this still existed. The Github Actions pipeline is working for both rust stable and nightly (just a badge to the Readme) I just looked at the Nixpkg rust section and it looks like there is an option to set the Rust version: Also looked at the error you got there. It's indeed another feature that got stablilized in Rust v1.39. Thanks for packaging this for NixOs. I'm kind of honored :)
Aha, I just used so that I got the channel instead of NixOS 19.09. This works!
Change:
etcProfile = writeText "profile" '' export PS1='${name}-chrootenv:u@h:w$ ' export LOCALE_ARCHIVE='/usr/lib/locale/locale-archive' <del> export LD_LIBRARY_PATH="/run/opengl-driver/lib:/run/opengl-driver-32/lib:/usr/lib:/usr/lib32''${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH" </del> <ins> export LD_LIBRARY_PATH="/run/opengl-driver/lib:/run/opengl-driver-32/lib''${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH" </ins> export PATH="/run/wrappers/bin:/usr/bin:/usr/sbin:$PATH" export TZDIR='/etc/zoneinfo'

Discussion:
Why does include /usr/lib and /usr/lib64 in LDLIBRARYPATH? Having them mounted at those locations should be sufficient for apps built for FHS systems to work. Including them in LDLIBRARYPATH causes these libraries to be used even for nix-built packages with proper dependencies on store paths, leading to runtime crashes. An example of this sort of crash occurs when running nix inside a shell inside vscode-fhs as it runs against incorrect libraries. Is there a case where FHS binaries require LDLIBRARYPATH as well? I've tested vscode-fhs and steam with a small patch to remove these two entries and they work fine but I'd assume there was some reason for including these and I've just not tested it. Some examples of issues I've ran into that had this as a root cause, when running programs inside a FHS shell:
problematic because it has priority over inside ELF. I don't think they are any useful because in FHS env already contains all these paths.
For some reason it seems that without is unable to find libraries. I have a precompiled clang, and ldd shows: It seems that /lib is not searched because is installed prefixed. and the prefixed path only have the basics. However I am still trying to understand why is not used at all, since it's correctly symlinked:
It appears things in is only generated if they're referred to with their . So in this case is not found because the cache contains only but no . It appears that in this case using is essential for to be able to discover . This is unfortunate because this means that is breaking. If is absent then the program cannot find the so, if it's present then it takes priority over in elfs and break things that's linked to a specific glibc version. I feel that we want something that has similar semantics to but has lower priority than , but I don't think this thing exist.
Turns out there's an existing issue
Also seems relevant.
Closing as was merged.