jiebi/CodeConvo huggingface dataset:
Code change:
makeWrapperArgs+=( "''${gappsWrapperArgs[@]}" --prefix PATH : "${lib.makeBinPath [ wmctrl ]}" <ins> --prefix LD_LIBRARY_PATH : "${lib.makeLibraryPath [ libX11 ]}" --prefix WEBKIT_DISABLE_COMPOSITING_MODE : "1" </ins> ) '';

Related discussion:
text: Describe the bug I'm unsure what the error is, but it seems to relate to ulauncher being unable to find the project path, whatever that may be. To Reproduce Steps to reproduce the behavior: Expected behavior For Ulauncher to start normally Additional context This is the error message I get: 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 Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(miyuki): nixpkgs: Maintainer information:
See the PR linked above. The issue is that the ulauncher package must be installed via , , , or something similar. Using does not work (for reasons explained in the patch). The PR both updates ulauncher and adds a note to explain what's going on to Nix users trying out the package. I think it would be a good idea to create a NixOS module for Ulauncher. I might be able to do this after I finish exams in a couple weeks.
Alright guys, the real solution here is to just use rofi. With a little work you can make it look pretty good and with a little extra work one could easily make it look similar to ulauncher. Here is my config I tried to fix this issue up but it seemed to work for maintainers thus it was the end of that story
Hello ulauncher package maintainer here. This definitely shouldn't be the end of the story. I do want to get these issues fixed. The problem is that ulauncher wants to store paths to its assets in a config file within . Typically we'd just let it use paths for everything, but that would cause ulauncher to break if we update the derivation then garbage-collect the old paths in . I also use Rofi right now, and it works. But I really want the plugin ecosystem of Ulauncher, so I'm motivated to fix this situation. Perhaps we could modify the current package to allow decoratively specifying the file contents (like ), which would allow the package to be used without messing with system state? Maybe we could even create something like and a NixOS module?
Perhaps this is a good fit for a home-manager module?
Code change:
makeWrapperArgs+=( "''${gappsWrapperArgs[@]}" --prefix PATH : "${lib.makeBinPath [ wmctrl ]}" <ins> --prefix LD_LIBRARY_PATH : "${lib.makeLibraryPath [ libX11 ]}" --prefix WEBKIT_DISABLE_COMPOSITING_MODE : "1" </ins> ) '';

Related discussion:
text: In any case, this issue can probably be closed once is merged. Maybe a new issue should be opened to track the addition of an unlauncher module?
I marked this as stale due to inactivity. &rarr;
bad bot
I installed (rev ) through . Unfortunately, I get this error message on launch anyway.
same issue here
Code change:
sha256 = "11lxkb7d79c75scrs28q4xmr0ii2li69zj1c650al3qxir8yf754"; }; <del> outputs = [ "bin" "lib" "dev" "out" "man" "dnsutils" "host" ]; </del> <ins> outputs = [ "out" "lib" "dev" "man" "dnsutils" "host" ]; </ins> patches = [ ./dont-keep-configure-flags.patch ./remove-mkdir-var.patch ] ++ stdenv.lib.optional stdenv.isDarwin ./darwin-openssl-linking-fix.patch;

Related discussion:
text: The symlinking between the multiple outputs of seems to prevent it from installing. I was looking to install it to have the dig command available. - System: 17.03pre94050. (Gorilla) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: "17.03pre94050."
11.4 still doesn't contain :-( How could we have that as default in 16.09? I consider it quite an important feature for + multiple outputs. would you be against porting that PR to 1.11.5 and making that default in 16.09 and master?
+1 for a 1.11.5 Nix release in general :)
Since this seems to be an issue for multiple packages, I am raising the severity on here.
Looks like the same kind of issue as So +1 for Nix 1.11.5 on NixOS 16.09, if that's what it takes to fix this.
ping again about nix-1.11.5 (my comment above).
Code change:
postFixup = '' # Fix include path that will be incorrect due to the "dev" output substituteInPlace "$dev/lib/cmake/LibDataChannel/LibDataChannelTargets.cmake"  <del> --replace "''${_IMPORT_PREFIX}/include" "$dev/include" </del> <ins> --replace-fail "''${_IMPORT_PREFIX}/include" "$dev/include" </ins> ''; meta = with lib; {

Related discussion:
text: HTTP Toolkit is an open-source tool for debugging, testing and building with HTTP(S) on Windows, Linux & Mac. Metadata homepage URL: source URL: license: AGPL v3.0 platforms: linux, darwin
Sorry, wasn't able to get it working. The httptoolkit-server is the difficult part. I tried building from source, however one of the dependencies tries to npm install more stuff in prebuild, so it wasn't building properly. I tried packaging the prebuilt binary but it's trying to do some auto updating and also package node with itself. I could have patched this when building from source, however the prebuilt one is minified & obfuscated so I couldn't do that.
Have you a branch to continue the work ?
+1
I've started a small bounty of 20$ on this: It's not much but it would be great to have this tool on nix!
I made another attempt at packaging this and I'm pretty close to getting httptoolkit-server to compile from source. This should help with patching out stuff, since we can do it before it gets obfuscated.
if anyone needs to run this on nix the appimage provided by HttpToolkit works pretty well on nix with no extra dependencies. See and then Would still be great to have this as a nix package though.
Hey thanks for adding this! You can claim the gitpay bounty here: (I've tried to find your email to invite you but didn't have much luck) or email me at
Sent you an email,
Code change:
# Wait for network and miniupnpd. router.wait_for_unit("network-online.target") # $router.wait_for_unit("nat") <del> router.wait_for_unit("firewall.service") </del> <ins> router.wait_for_unit("${if useNftables then "nftables" else "firewall"}.service") </ins> router.wait_for_unit("miniupnpd") client1.wait_for_unit("network-online.target")

Related discussion:
text: We already have in , but only with iptables support. It would be nice to have the nftables version available as well.
Being worked on in , I'm trying to test myself but couldn't make it to work yet.
I think the PR is ready now, testing welcome!
Maybe add an option for will be better?
Code change:
bower2nix = nodeEnv.buildNodePackage { name = "bower2nix"; packageName = "bower2nix"; <del> version = "3.1.0"; </del> <ins> version = "3.1.1"; </ins> src = fetchurl { <del> url = "https://registry.npmjs.org/bower2nix/-/bower2nix-3.1.0.tgz"; sha1 = "f18a46335854ff9c5b4fe78f88309d7bf0631a1b"; </del> <ins> url = "https://registry.npmjs.org/bower2nix/-/bower2nix-3.1.1.tgz"; sha1 = "wfzj1k6jkfnk1bkgbmpni59mdab8zk3p"; </ins> }; dependencies = [ (sources."argparse-1.0.4" // {

Related discussion:
text: fetch-bower produces truncated nix-store entry when run under nix-build: Looking into the retrieved jquery in the nix store you can see jquery is actually missing: It works fine when trying to manually run it as a regular user: bower- generated by : run nix-build System: (16.09beta172. (Flounder)) Nix version: (nix-env (Nix) 1.11.4) Nixpkgs version: (16.09beta172.)
ping
Sorry for the delay I will test and merge today.
Hello thanks for your detailed report. I am getting slightly different results to you, so more investigation will be necessary. In my environment (NixOS 16.09 channel), there was no hash mismatch. Possibly something caused git to fail to download the jquery package. If it silently fails producing an incorrect result, then that is a bug in bower2nix which could be reported at
I am not sure this due to bower2nix. Fetch-bower is calling git and should handle the error's accordingly, no?
It consistently fails for me both on the latest unstable and 16.09 channels. Can you try updating your channels? My suspect was commit but I wasn't able to revert it cleanly to try it out.
By , I also mean . I have rolled the two programs into one repo. You are definitely right, is calling (indirectly, through the API), and should handle the error. I'm an avid subscriber to 16.09 and especially nixos-unstable, so have tested on those. Obviously it would be easier to fix the error handling if I can make fail myself. Do you have any further info about your setup which might be relevant? E.g. any proxy settings required for git to work. Can I also confirm that you are running before retrying ?
I don't have any proxy settings. Is it possible GitHub is rate limiting requests from bower? I found this thread interesting And yes I am running nix-store --delete before trying nix-build.
Hi are there any additional details I can provide? I am not that familiar with typescript or javascript, but I could try to narrow the issue down with some help.
How to reproduce: Expected output: bower package info json.
Code change:
bower2nix = nodeEnv.buildNodePackage { name = "bower2nix"; packageName = "bower2nix"; <del> version = "3.1.0"; </del> <ins> version = "3.1.1"; </ins> src = fetchurl { <del> url = "https://registry.npmjs.org/bower2nix/-/bower2nix-3.1.0.tgz"; sha1 = "f18a46335854ff9c5b4fe78f88309d7bf0631a1b"; </del> <ins> url = "https://registry.npmjs.org/bower2nix/-/bower2nix-3.1.1.tgz"; sha1 = "wfzj1k6jkfnk1bkgbmpni59mdab8zk3p"; </ins> }; dependencies = [ (sources."argparse-1.0.4" // {

Related discussion:
text: Actual output: nothing, not even an error message.
This problem is back. I can reproduce it by following the steps outlined in the top message. (latest nixpkgs-unstable) It did work for me a while ago though, so it looks like a regression. Did some digging around but I cannot figure it out. cc
Good catch, I think I've seen the same issue as well, but didn't bother (lack of time). Could be a different cause, but we have to start somewhere :)
Running produces correct result while -ing the following produces an output without jquery (just meta data)
Figured it out. Git doesn't see SSL certificates. I made it run with this expression I'll try to open a PR to fix this in nixpkgs. I'll also try to open a PR to bower2nix because there is a bug in it - missing SSL cert should not result in exit code 0.
Code change:
<del> { lib, fetchPypi, nixosTests, python3 }: </del> <ins> { lib, fetchPypi, nixosTests, python3, }: </ins> python3.pkgs.buildPythonApplication rec { version = "0.5.0b3.dev85";

Related discussion:
text: Steps to reproduce the behavior: pyload-ng <!-- 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]:
Thank you for notifying me, the failure is caused by the lib not yet working on python 3.12. Apparently the git upstream of pyload replaced it with which I'm packaging in , so once that's done I'll get around to updating pyload (will probably have to switch to the git version since they rarely upload new releases to pypi). For now you can override the python version as a workaround:
The override works great. Thanks!
Code change:
{ stdenv, fetchFromGitHub, kernel, bc }: stdenv.mkDerivation rec { name = "rtl8821ce-${kernel.version}-${version}"; <del> version = "5.2.5_1.26055.20180108"; </del> <ins> version = "5.5.2_34066.20200325"; </ins> src = fetchFromGitHub { owner = "tomaspinho"; repo = "rtl8821ce"; <del> rev = "ab6154e150bbc7d12b0525d4cc1298ae196e45de"; sha256 = "1my0hidqnv4s7hi5897m81pq0sjw05np0g27hlkg9fwb83b5kzsg"; </del> <ins> rev = "69765eb288a8dfad3b055b906760b53e02ab1dea"; sha256 = "17jiw25k74kv5lnvgycvj2g1n06hbrpjz6p4znk4a62g136rhn4s"; </ins> }; hardeningDisable = [ "pic" ];

Related discussion:
text: Describe The package rtl8821ce can't be compiled due to errors.
The package is the upstream GitHub repository it tracks which is the cause of this breakage. Bumping it to master should suffice in resolving this. Specifically, commit is the one that fixes the failure I too observed in rtl8821ce today while setting up NixOS.
fixes this for me and WiFi works perfectly.
Code change:
, ibus , qtbase , zstd <ins> , fetchpatch </ins> , withFcitx5Support ? false , withIbusSupport ? false }:

Related discussion:
text: In the latest stable release, the package fcitx5-openbangla-keyboard does not work. OpenBangla Keyboard package is installed but it does not integrate with fcitx5. fcitx5 crashes every time after logging in.
Here are some screenshots. ! ! !
Thanks for reporting, will take a look.
... Here is my !
Any update? Thanks.
fcitx5 crash log:
I have forked the OpenBangla Keyboard from the develop branch. After the recent commit. it built successfully in NixOS. I am now using OpenBangla Keyboard with an overlay from OpenBangla Keyboard's develop branch. !
I think change of these two lines according to this image will solve the problem. ( I don't know the correct hash = sha256, I just gave this and the correct hash was shown in the build error!) !
Thanks for looking into this. I've pulled the relevant commit and also tested at runtime this time, it does not appear to crash and outputs text properly.
Code change:
, ibus , qtbase , zstd <ins> , fetchpatch </ins> , withFcitx5Support ? false , withIbusSupport ? false }:

Related discussion:
text: openbangla keyboard installed from the unstable channel does not integrate with fcitx5. It installs just fine but does not integrate with fcitx5. Fcitx5 does not autostart too. OS: NixOS Stable DE: KDE Plasma !
Openbangla keyboard from unstable channel does not work in the unstable nix os installation too. Openbangla keyboard crashes fcitx5 and even if it is restarted switching keyboard layout says openbangla keyboard not available.
Code change:
# Darwin , gmp , libiconv <ins> , qemu </ins> , Carbon , AppKit

Related discussion:
text: On my M1 Mac, with homebrew-installed libvirt / qemu-system-aarch64, I'm able to run the VM defined in the config below without issue. However with libvirt / qemu installed via nix, I get: Some possibly related discussion . Looking at the , they're explicitly setting ; adding this seems to resolve the issue: I'm not sure whether disabling those failing tests is a reasonable thing to do. Steps to reproduce the behavior: to in A clear and concise description of what you expected to happen. Should run without , like it does with homebrew. Please run and paste the result.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
FWIW, I also encountered this issue, and have to use the following workaround: And -ing the efi firmware & vars manually. Fixing this bug can lead to great user experience: virt-manager can work out of box.
Where did you get ?
Code change:
copy_bin_and_libs () { [ -f "$out/bin/$(basename $1)" ] && rm "$out/bin/$(basename $1)" <del> cp -pdv $1 $out/bin </del> <ins> cp -pdvH $1 $out/bin </ins> } # Copy BusyBox.

Related discussion:
text: Trying to update a system to the latest "release" () results in the following error: I don't know how to easily reproduce this. At least for me, it seems to happen because the needs to adjusted. So: Try to update a system that (at least) uses ZFS I guess ... No build failure. N/A It looks like this was caused by . I'm not sure if the ZFS module is the only place that needs to be adjusted after this PR has landed. (authored the PR mentioned above) (approved the PR mentioned above) (ZFS maintainers) Please run and paste the result.
For now, I'm not sure, I can reproduce on 23.11pre504982.. It seems like the fix is obvious though.
While I understand how to adjust the two lines in , I don't know how to deal with the other occurrences of in that file.
Usually you can replace "PATH lookup handle where this binary actually is.
I have a potentially fix in
Someone should prove that before the fix, this was broken with a NixOS test ideally and with this fix, this is unbroken.
I suspect it's related to and that that's not covered by any of the existing nixos tests.
And that in turn can't trivially be tested end-to-end because nixos-generate-config doesn't actually support non-legacy zfs mounts... I've written a test and a little prose about the issue:
Maybe we should consider adding them. Using new mounts is rather convenient when the disk needs to be mounted in a live iso.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Ran into the same exact issue over here. Also running on ZFS root. (The discourse link above is mine.) EDIT: Fixed by updating to master. I think I'll be converting to flakes soon, thanks to this
Fix reverted because it broke basically the entire nixos test suite:
I get this with NixOS 23.05.
are you sure it's exactly that? The util-linux split isn't even on 23.05 so that would be very weird.
Yes
That sounds like you're somehow using unstable util-linux for the stable initramfs generation, and it's not surprising that that would break.
Code change:
copy_bin_and_libs () { [ -f "$out/bin/$(basename $1)" ] && rm "$out/bin/$(basename $1)" <del> cp -pdv $1 $out/bin </del> <ins> cp -pdvH $1 $out/bin </ins> } # Copy BusyBox.

Related discussion:
text: You can try confirming this by temporarily setting both nixpkgs to point to the same (doesn't even matter if it's unstable or stable).
I have unstable for Alacrity which is an application, I don't see how that would affect initramfs generation.
And I don't see how you'd get a split util-linux from 23.05, since wasn't backported there.
Indeed: And in fact: Which is a different util-linux version number than we see in your error message. Finally, your nix flake metadata says your using , and: So something fishy is going on here. You've got an overlay or override or something that's pulling in a different util-linux from unstable. Either that or there's some other build that's occurring as an unexpected transitive dependency that's building a nixos system using an unstable nixpkgs that doesn't contain the fix. Either way, I feel fairly confident in saying this is some obscure and subtle user error.
Code change:
}; testScript = '' <ins> from base64 import b64encode from urllib.parse import quote </ins> machine.start() machine.wait_for_open_port(80) machine.wait_for_unit("multi-user.target")

Related discussion:
text: Grocy does not properly save manuals for equipment The issue appears to be introduced by in a patch applied by nixpkgs. Changing that hunk to: Fixes the issue. I'm not currently setup for making a PR, I'm a bit busy, but I wanted an issue for other people to find if they run into the problem. grocy in nixos configuration (admin/admin is default) a new piece of equipment and attach a PDF manual to it to download manual; it will fail system: host os: multi-user?: sandbox: version: channels(aidenn): channels(root): nixpkgs:
appears to be the maintainer.
I marked this as stale due to inactivity. &rarr;
Code change:
githubId = 9959940; name = "Andreas Fehn"; }; <ins> felbinger = { name = "Nico Felbinger"; email = "nico@felbinger.eu"; matrix = "@nico:felbinger.eu"; github = "felbinger"; githubId = 26925347; keys = [{ fingerprint = "0797 D238 9769 CA1E 57B7 2ED9 2BA7 8116 87C9 0DE4"; }]; }; </ins> felipeqq2 = { name = "Felipe Silva"; email = "nixpkgs@felipeqq2.rocks";

Related discussion:
text: Project description EveBox is a Suricata alert and event management tool for the Suricata IDS/NSM Engine. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, ... Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
specs-nvim = buildVimPlugin { pname = "specs.nvim"; <del> version = "2022-09-20"; </del> <ins> version = "2024-05-19"; </ins> src = fetchFromGitHub { <del> owner = "edluffy"; </del> <ins> owner = "cxwx"; </ins> repo = "specs.nvim"; <del> rev = "2743e412bbe21c9d73954c403d01e8de7377890d"; sha256 = "1ycqvxrn13bfimf9k03bmm1baml8gyq5lxqjxh1fya44s2bg714r"; </del> <ins> rev = "dd82496f538b688cedf98429f89fef47ecb0625e"; sha256 = "0427fx6iw3i2y9ny3sz1na32bxcj8i93dbm93ckxf3bii8zqjs0s"; </ins> }; <del> meta.homepage = "https://github.com/edluffy/specs.nvim/"; </del> <ins> meta.homepage = "https://github.com/cxwx/specs.nvim/"; </ins> }; spellsitter-nvim = buildVimPlugin {

Related discussion:
text: Specs-nvim does not work in Neovim 0.10 and the author has not updated the upstream version. The derivation should point to the updated fork instead: Steps to reproduce the behavior: specs-nvim with Neovim 0.10 specs-nvim errors Should I have used the out-of-date packaging report issue template instead? Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
no pb for me. Feel free to submit a PR. Pinging as he might know better.
What does no pb mean? I'll make a PR
I guess that it means "go for it, let's switch to the fork".
Code change:
, freetype, gd, libXaw, icu, ghostscript, libXpm, libXmu, libXext , perl, perlPackages, python2Packages, pkgconfig , poppler, libpaper, graphite2, zziplib, harfbuzz, potrace, gmp, mpfr <del> , cairo, pixman, xorg, clisp, biber, xxHash </del> <ins> , brotli, cairo, pixman, xorg, clisp, biber, woff2, xxHash </ins> , makeWrapper, shortenPerlShebang }:

Related discussion:
text: <!-- 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: texlive- current version: 2.9.1 desired version: 2.10.1 <!-- 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.
Can you tell a bit about your use case?
I knew I forgot something! :smile: I'm using emacs + org-mode, and am using the =unicode-math= package with =stix2-otf= along with lualatex. In order to preview equations, the pipeline goes /However/, =dvisvgm= 2.9.1 doesn't understand the extended font data that lualatex emits (see the comments in ), and so produces corrupt output images. This was fixed in 2.10.1, which was recently released and pushed to CTAN.