jiebi/CodeConvo huggingface dataset:
Code change:
touch $out/etc/sane.d/dll.conf # absolute paths to convert & tesseract <ins> sed -i '/[AC_DEFINE([HAVE_IMAGE_MAGICK], [1])/a  MAGICK_CONVERT="${imagemagick}/bin/convert"' configure.ac </ins> substituteInPlace filters/magick.cpp  --replace 'convert ' '${imagemagick}/bin/convert ' substituteInPlace filters/reorient.cpp 

Related discussion:
text: I have an EPSON DS-530 scanner, that I can't use to scan anymore. Prior to upgrading to NixOS 22.05, it worked perfectly fine. Steps to reproduce the behavior: scanning as follows: a sheet of paper in the scanner and scan it using utsushi, scanimage, simple-scan, xscan, … scanner pulls the paper through, but this does not result in a scanned document with any of the programs I tested. The (probably) relevant lines of the full log output (see below) are: The page is scanned successfully. The symptoms look exactly like those described in . The full debug output is as follows: <details<summaryLog</summary</details
I just noticed that utsushi reports version 0.65.0, which doesn't match the supposed version 3.65.0 in the channel. Though it seems kinda plausible to me that utsushi just reports major version 0, as the rest matches?
Trying to debug this further by scanning with , I got the following lines of output: The line () looked suspicious to me. I attempted to narrow this down further using strace: Interestingly, this refers to a file called , that supposedly should exist in the / package's directory, but doesn't as the strace indicates. The only reference to this that I could find is in the . If not provided with a different engine as a command line parameter, it should just use tesseract. This in turn led me to in the utsushi codebase, which calls the filter. I stopped my investigation there for now. Maybe can give more context, as they came up in many of my searches regarding this.
can you try adding to and see if that works? It looks like calls out to and expects to have it in , so probably falls back to ?
can you check if fixes this?
Thank you but unfortunately this didn't help. I'm still seeing references to in the where I suspect that I should see references to tesseract instead. It would be sufficient for me to deactivate all the postprocessing that happens, but this doesn't seem intended feature in utsushi :/
As I had amassed quite a backlog of documents to scan, I started a nix shell with the utsushi version I used previously, using the following command: This works.
Code change:
touch $out/etc/sane.d/dll.conf # absolute paths to convert & tesseract <ins> sed -i '/[AC_DEFINE([HAVE_IMAGE_MAGICK], [1])/a  MAGICK_CONVERT="${imagemagick}/bin/convert"' configure.ac </ins> substituteInPlace filters/magick.cpp  --replace 'convert ' '${imagemagick}/bin/convert ' substituteInPlace filters/reorient.cpp 

Related discussion:
text: However, this is only a workaround, as this means that I need to use the interface for scanning, which is somewhat cumbersome to use and this also pulls in a lot of old packages via the dependencies. I'd be happy to try out anything at this point.
Hey, I started looking into this again and noticed that in you switched the sources from the to the repository on gitlab. I'm wondering what the reason for this was. Do you remember?
I think back than the maintainer of utsushi suggested this. Imagescan just tries to mirror the driver as it is release by epson, while utsushi contains community maintained patches, but unfortunately no clear versioning scheme.
I just bisected the changes and it turns out that is indeed the commit at which utsushi stops working for me.
That is unfortunate. Maybe we should offer both utsushi and imagescan as packages, than the user can choose.
This could be a solution. I am not sure yet, whether the problem may also stem from one of the patches introduced or the command removed in that commit. As I am getting a error, I think it possible that the problem may be related to the imagick (or a similar) dependency.
It turns out, that this problem had a . Adding the following line back to the derivation makes utsushi work again. PR adds it back to the derivation and fixes scanning on my machine.
Code change:
gfortran blas python <ins> ocl-icd </ins> cudatoolkit nvidia_x11 gtest

Related discussion:
text: When I try and install the package it fails because the installation procedure iterates over all the test-short executable's dependencies and is unable to locate the required It seems this dependency comes from the test-short binary being linked against the that comes with . This has a record that says it is This results in test-short requiring the library The only provides a though, so the installation then explodes when it tries to loop over the dependencies of the binary it just created and finds it can't find It is not clear to me if this would be considered an issue with or . Two possibly fixes are to for before , or a step to to provide the symlink. Try and install package System: Nix version: Nixpkgs version: Sandboxing enabled:
I decided to give the latest unstable a try as well. It dies during the as it cannot find at all anymore. Looking through the source it looks like the recent commit stripped out all together. I guess that makes (1) above the correct solution.
forgot to CC relevant people on this issue with (should be an easy fix -- just add to the )
Code change:
dependencies = [ altgraph packaging <ins> macholib </ins> pyinstaller-hooks-contrib ]; <del> makeWrapperArgs = [ </del> <ins> makeWrapperArgs = lib.optionals stdenv.hostPlatform.isLinux [ </ins> "--prefix" "PATH" ":"  (lib.makeBinPath [ glibc binutils ]) ];

Related discussion:
text: Steps to reproduce the behaviour: PyInstaller on Darwin It fails to build at gcc as gcc is not avlible on macOS CC <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Is it possible that you can make gcc only in linux but clang if pyinstaller uses clang for darwin to use that?
I got it working I am willing to contribute a fix to this.
I will need to some how package since requires it for macos systems.
But first of all since gcc is required on linux is there a possible if linux include gcc instead of clang.
Based on , it seems like and the stuff is only required on linux. Maybe we could just throw in a here? Do you know if more needed to be done to fix the darwin build? Feel free to open a PR if you'd like.
You need which I am looking to make a package for and I think I still have to test if you need . I am looking to make a pr in a couple of days to fix both pyinstaller and package
I think gcc can be replace with clang which is compatible with both linux and darwin.
Macholib is now in a pr:
Now I am looking to fix pyinstaller for darwin.
Code change:
./services/misc/octoprint.nix ./services/misc/ollama.nix ./services/misc/ombi.nix <ins> ./services/misc/open-webui.nix </ins> ./services/misc/osrm.nix ./services/misc/owncast.nix ./services/misc/packagekit.nix

Related discussion:
text: Project description WebUI service for Large Language Models Video demonstration by : .. basically self-hostable ChatGPT-like service Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin Additional info Follow-up on for open-webui nixos module. There seems to be an ongoing work on the subject by and on Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Relevant Merge Request:
Just for reference / workaround here's another nix package:
Thanks for that reference. That pdm tool workaround looks a lot more maintainable for the Python backend. Maybe i'll have time to try another PR in the next weeks. In the meantime and as a much simpler UI i packaged as part of PR It would be great if someone could review it.
I would like to mention that in the latest release switched to , I am not sure of any straightforward way to do this while packaging it for .
I just tested your flake, it's impressive, especially the nice UI at the end showing all the processes ! Regarding open-webui, it would be so nice to have that in !!!
Thank you, planning to have more UIs and devShell integration (for CLI tools that interact with ollama). I would love that too! Although there are a few challenges (like the one I pointed above regarding ), I am willing to contribute here. Also, maintainers are quick to respond, in case we need any upstream contributions to make it happen.
Code change:
, buildPythonPackage , fetchPypi , fetchpatch <ins> , setuptools </ins> }: buildPythonPackage rec {

Related discussion:
text: Describe the bug fails to run because setuptools is no longer propagated implictly. If were purely a python application built with then we would just need to add to propagatedBuildInputs and be done. However, is not simply a Python application, but a wrapper around , and isn't built using. The derivation patches the script as follows: This does result in the site-packages directories from all python packages ending up in , including setuptools (e.g. ). I'm not that familiar with Python packaging but from experimenting I found that the full path to the Python egg needs to be included (e.g. ) in order for this method to work. I made an attempt at resolving the issue but being new to Python packaging in Nix, neither are likely to be ideal: We could use buildPythonPackage in place of mkDerivation, using and use Or continue to use mkDerivation and manually set for patchPythonScript: I'm happy to submit a PR but I'm not sure what the recommended solution is here. To Reproduce Steps to reproduce the behavior: Expected behavior should launch with the extension loaded: Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
It seems is normally used by adding a to , or calling with (what the wrapper registered in does). This script then just does some addition calculations to register itself (we probably don't that at all) and some python 2 specific fixups, and then calls , which starts executing some code on import. I'd suggest to package it as a regular python application first (via ), so you can successfully import it inside a . The python tooling should automatically take care of patching the python shebang properly if you make script executable.
proposed fix
Code change:
# Hardening , graphene-hardened-malloc <del> , useHardenedMalloc ? graphene-hardened-malloc != null && builtins.elem stdenv.system graphene-hardened-malloc.meta.platforms </del> <ins> # crashes with intel driver , useHardenedMalloc ? false </ins> # Whether to disable multiprocess support to work around crashing tabs # TODO: fix the underlying problem instead of this terrible work-around

Related discussion:
text: Describe the bug After upgrading to nixos-20.03 and enabling pulseaudio support I started experiencing the "Gah! tab crashed" error too often, to the point that browsing sites with certain types of embedded media (mostly audio/video) instantly triggers the error (e.g browsing ). While troubleshooting this I also noticed that opening crashes not the tab but the browser. On the console I can see: This crash is present with default options (i.e. and ). In addition, after several crashes Tor asks to start in "Safe mode". I'm not sure what safe mode disables but it allows opening without crashing and/or triggering the segfault. This seems to hint at some interaction with external libraries and my assumption that this is somehow related to pulseaudio. To Reproduce Steps to reproduce the behavior: the URL will crash Notify maintainers Metadata The following expression was used to enable and : and installed with .
Can you try with override ?
This helps. On a quick test I didn't see any "Gah! Tab crashed" error and works fine.
It should be off by default then, it used to work :(
Could this be triggered by a missing or mismatched library? I also only started noticing this after enabling pulseaudio system-wide. If this helps diagnosing the issue...
I think it's simply because the firefox jemalloc is incompatible with the hardened allocator. firefox has to be built with for that to work. I wonder why this appears to have worked before; maybe the tbb build has changed. Relevant mailing list thread here (fair warning: it turns into a not-so-productive exchange after a few messages):
I think that at this point it'd be appropriate to revert the commit that hardened alloc support, with a note as to why, maybe opening an issue to track work (if anyone cares) to make hardened malloc work with tbb/firefox.
I'm not into the differences/advantages of each allocator. In this case I have the user hat on and unless there's a critical aspect of relevance I'm happy to trade that in favour of a functional browser.
Code change:
gtksourceview4 gdk-pixbuf librsvg <del> webkitgtk_4_1 </del> <ins> libsoup webkitgtk </ins> libepoxy gst_all_1.gstreamer gst_all_1.gst-plugins-base gst_all_1.gst-plugins-good <ins> gst_all_1.gst-plugins-bad gst_all_1.gst-plugins-ugly </ins> ]; # See https://github.com/NixOS/nixpkgs/issues/31168

Related discussion:
text: Describe the bug When I try to preview videos like .mp4 or webm in Nautilus using Sushi, it says "Your GStreamer installation is missing a plug-in". To Reproduce Steps to reproduce the behavior: NixOS with Gnome3 desktop space on a video file in Nautilus Additional context It's possible that there's some configuration in my homedir that makes it break, since I have the same homedir that I had under other Linux installs, not sure how to find it however. outputs Notify maintainers maybe? Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(wmertens): channels(root): nixpkgs: Maintainer information:
Would need to add here, I think.
that makes sense - it seems like I would like the bad and the ugly too. How about a nixpkgs configuration setting that decides which plugin sets to load, and having plugins-base include them? That should make it backwards-compatible.
Most of them depend on base so that would be a dependency cycle. Also we would need to move the wrappers into a separate derivation or we would have to rebuild everything. Alternately, you can set environment variable (I believe some NixOS module does that). Not a fan but it should work provided some ABI break does not sneak in.
I marked this as stale due to inactivity. &rarr;
Still a problem
I marked this as stale due to inactivity. &rarr;
if sushi is not a dependent of any package then why would we have to rebuild everything? What do you mean by everything? Perhaps until a separate wrapper derivation is composed we can add a configuration option to the nixos module that would add these gstreamer to it if needed. Also, doesn't work at all for me nowadays, I think since Gnome 41.
I was replying to Wout’s question above regarding a general solution pulling extra plug-ins into gst-plugins-base. For now, I would be fine with adding everything unconditionally to sushi as mentioned in I must have forgotten to test it during the update when I removed libmusicbrainz but forgot to add libsoup: Could you try
Code change:
dot-language-server = callPackage ../development/tools/language-servers/dot-language-server { }; <ins> emmet-ls = callPackage ../development/tools/language-servers/emmet-ls { }; </ins> fortls = python3.pkgs.callPackage ../development/tools/language-servers/fortls { }; fortran-language-server = python3.pkgs.callPackage ../development/tools/language-servers/fortran-language-server { };

Related discussion:
text: Project description Emmet support based on LSP. Metadata source URL: license: mit platforms: all
Code change:
storePath = config.boot.loader.grub.storePath; bootloaderId = if args.efiBootloaderId == null then "NixOS${efiSysMountPoint'}" else args.efiBootloaderId; timeout = if config.boot.loader.timeout == null then -1 else config.boot.loader.timeout; <del> inherit efiSysMountPoint; </del> <ins> inherit efiSysMountPoint initrdSecrets; </ins> inherit (args) devices; inherit (efi) canTouchEfiVariables; inherit (cfg) version extraConfig extraPerEntryConfig extraEntries forceInstall useOSProber <del> extraEntriesBeforeNixOS extraPrepareConfig extraInitrd configurationLimit copyKernels </del> <ins> extraEntriesBeforeNixOS extraPrepareConfig configurationLimit copyKernels </ins> default fsIdentifier efiSupport efiInstallAsRemovable gfxmodeEfi gfxmodeBios; path = (makeBinPath ([ pkgs.coreutils pkgs.gnused pkgs.gnugrep pkgs.findutils pkgs.diffutils pkgs.btrfs-progs

Related discussion:
text: Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.
Code change:
mpv: let <del> # arguments to the function (called `wrapMpv` in all-packages.nix) </del> <ins> # arguments to the function (exposed as `wrapMpv` in all-packages.nix) </ins> wrapper = { extraMakeWrapperArgs ? [], youtubeSupport ? true,

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: mpv <!-- 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: 0.33.1 desired version: 0.34.0 <!-- 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.
Code change:
# Don't install SUID binaries sed -i 's/-m 4755/-m 755/g' builddir/Makefile ''; buildPhase = '' <ins> runHook preBuild </ins> make -C builddir <ins> runHook postBuild </ins> ''; installPhase = '' <ins> runHook preInstall </ins> make -C builddir install LOCALSTATEDIR=$bin/var chmod 755 $bin/libexec/singularity/bin/starter-suid <del> wrapProgram $bin/bin/singularity --prefix PATH : ${stdenv.lib.makeBinPath propagatedBuildInputs} </del> <ins> # Explicitly configure paths in the config file sed -i 's|^# mksquashfs path =.*$|mksquashfs path = ${stdenv.lib.makeBinPath [squashfsTools]}/mksquashfs|' $bin/etc/singularity/singularity.conf sed -i 's|^# cryptsetup path =.*$|cryptsetup path = ${stdenv.lib.makeBinPath [cryptsetup]}/cryptsetup|' $bin/etc/singularity/singularity.conf runHook postInstall </ins> ''; postFixup = '' <del> find $bin/ -type f -executable -exec remove-references-to -t ${go} '{}' + || true # These etc scripts shouldn't have their paths patched cp etc/actions/* $bin/etc/singularity/actions/ </del> <ins> find $bin/libexec/ -type f -executable -exec remove-references-to -t ${go} '{}' + || true </ins> ''; meta = with stdenv.lib; { <del> homepage = http://www.sylabs.io/; </del> <ins> homepage = "http://www.sylabs.io/"; </ins> description = "Application containers for linux"; license = licenses.bsd3; platforms = platforms.linux;

Related discussion:
text: , CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives. Cc Cc Cc
Backporting update that resolves these ().
Fixed in 20.03 and master.
Code change:
, fetchFromGitHub , makeWrapper , rofi <del> , mpc_cli </del> <ins> , mpc-cli </ins> , perl , util-linux , python3Packages

Related discussion:
text: The mpccli package is missing bashcompletion, even though a bash completion file is in the upstream repo under contrib/mpc- . Steps to reproduce the behavior: the package a terminal and type It tries only to complete with the contents of the current directory mpc should be completed with the mpc subcomands like , , etc. On a regular system, the file would have to be installed under /etc/bashcompletion.d/ . I don't know whats the nix(os) equivalent to this.
First, I am not the maintainer of this package. Nonetheless I will review this. Second, in Nixpkgs we do "almost" the same: we use a special hook that installs those extra files at the . Now I need to sleep; please wait a bit more.
Code change:
<del> { lib, fetchFromGitHub, gitUpdater , meson, ninja, pkg-config, wrapGAppsHook , desktop-file-utils, gsettings-desktop-schemas, libnotify, libhandy, webkitgtk , python3Packages, gettext , appstream-glib, gdk-pixbuf, glib, gobject-introspection, gspell, gtk3, gtksourceview4, gnome , steam, xdg-utils, pciutils, cabextract , freetype, p7zip, gamemode, mangohud </del> <ins> { lib , fetchFromGitHub , fetchFromGitLab , gitUpdater , python3Packages , blueprint-compiler , meson , ninja , pkg-config , wrapGAppsHook4 , appstream-glib , desktop-file-utils , librsvg , gtk4 , gtksourceview5 , libadwaita , steam , cabextract , p7zip , xdpyinfo , imagemagick , procps , gamescope , mangohud , vmtouch </ins> , wine , bottlesExtraLibraries ? pkgs: [ ] # extra packages to add to steam.run multiPkgs , bottlesExtraPkgs ? pkgs: [ ] # extra packages to add to steam.run targetPkgs

Related discussion:
text: Vulkan/dxvk doesnt work on bottles. Vulkan is working correctly on my laptop as vkcube, vulkaninfo and the game im trying to run on bottles (that i ran thru wineWowPackages.staging + dxvk install from the official archive file) run perfectly. Steps to reproduce the behavior: bottles a bottle for gaming a game. the "directx error" pop up. Also, the dxvk log files say that the "VKKHRsurface" extension failed to load. DXVK/Vulkan should work on bottles. ! Please run and paste the result.
Having the exact same Issue on 22.11pre393800. (Raccoon)
If fails then there is a driver issue. Vulkan wont be able to draw anything to screen without it. When it occurs in proton issues it's usually a missing 32bit Vulkan library. Tho there can ofc probably be other causes
update: using the system wine doesn't fix dxvk either. only running thru the command line does. As i said, running it thru wine on the terminal does work, so something in the bottles thing is not working right.
I found the cause: these hardcoded paths right there: With this extra lines in , Vulkan will work on Bottles: I'm not sure if this is the best way to solve it, though. Tested only on a 64-bit bottle (I don't know if 32-bit bottles need to also link ). .
!!! nice find!