jiebi/CodeConvo huggingface dataset:
Code change:
inherit pname; version = "2.0.1"; <del> outputs = [ "bin" "out" "dev" "doc" "man" ]; </del> <ins> outputs = [ "out" "lib" "dev" "doc" "man" ]; </ins> src = fetchFromGitLab { domain = "salsa.debian.org";

Related discussion:
text: I'm going to add some comments for SEO so this is easier to find
I think you have found the right culprit that caused the issue, but I suppose the issue has more to do with the itself, where it only includes if . This has been rectified in from what it seems. For now the proper solution seems to enabling polkit with .
I think that makes more sense based on the existing file structure but maybe we just switch bin to out, so it is the default and move the libs to lib instead of being in out.
I've created to make the outputs a lot more expected by moving the udev file and the systemd service to the out output and the libraries to the lib output: I didn't test it yet, so it is still in draft. If someone could verify that it doesn't break security keys again, that would be great and then please undraft it, otherwise I do it in the evening.
I do not think I can fully test this due to the amount of rebuilds, so please chime in for reviews and find the one mistake I might have done (which I hope I didn't)
Tried to build but it fails on my machine:
I've xdist to dulwich here . Let me see if we can just disable some tests as a speed up from 66s to 9s is quite good.
This should be a lot better with . I did a lot of rebuilds locally on a low and high core machine and didn't encounter any failures anymore.
This was fixed in , works fine for me.
Code change:
# Relative paths. "BINDIR=/bin" "PERLDIR=/share/perl5" <del> "MODSDIR=/lib/" </del> <ins> "MODSDIR=/nonexistent" # AMC will test for that dir before # defaulting to the "portable" strategy, so this test *must* fail. </ins> "TEXDIR=/tex/latex/" # what texlive.combine expects "TEXDOCDIR=/share/doc/texmf/" # TODO where to put this? "MAN1DIR=/share/man/man1"

Related discussion:
text: The auto-multiple-choice program does not start, on NixOS 22.11 : Steps to reproduce the behavior: auto-multiple-choice auto-multiple-choice that it's not really working A clear and concise description of what you expected to happen.
I'm trying to reproduce, without success so far. Did you install AMC from , or through nix-env/nix-shell? (I'm rebuilding my system without the global AMC to test those cases, but it triggered a full Emacs recompilation which will take some time)
I installed it using nix-env. I'll try with the systemPackage option later today. I'm using wayland with sway.
I don't think that's the issue there (also I have the very same setup, on unstable though). This message means that the program can't find the perl source module of its gui component, which indicates an installation/path issue.
I really can't reproduce, sorry. Please let me know how things go with . Does exist?
Yup, it exists : After switching with the system version, I get the same error. After updating the channels () and rebuilding () I still get the same error.
Is there a /lib/ directory at your FS root?
Yup, there is, it contains a subdirectory (modules) which is empty. Deleting it makes auto-multiple-choice work as expected.
Ok, I believe that's the root issue, but I'm not sure how to fix this. If it's fully empty besides subdirs, you should just delete it.
Does that mean that auto-multiple-choice is also broken on non nixos installations ?
No, because on those, the Perl modules AMC needs are on the global , or , or whatever. The NixOS package, OTOH, is a self-contained, so-called "portable" build where everything (libs, executables, doc…) lives in a single directory. Your issue comes from the fact that AMC tries to detect such a portable build by first looking for a global , then defaulting to dir iff the former doesn't exist: I think I can solve this by just changing the default lib dir, please don't close the issue.
will fix this.
reverted the "fix" to that issue, because it broke everything else (my fault). For the time being you need to make sure there's no on your system for AMC to work.
No problem, good luck with that !
Code change:
<ins> diff --git i/widgets/settings/settingsdialog.cpp w/widgets/settings/settingsdialog.cpp index 4deff1f..16845b5 100644 --- i/widgets/settings/settingsdialog.cpp +++ w/widgets/settings/settingsdialog.cpp @@ -802,7 +802,7 @@ bool setAutostartEnabled(bool enabled) desktopFile.write("[Desktop Entry]n" "Name=" APP_NAME "n" "Exec=""); -        desktopFile.write(qEnvironmentVariable("APPIMAGE", QCoreApplication::applicationFilePath()).toUtf8().data()); +        desktopFile.write(qEnvironmentVariable("APPIMAGE", EXEC_NIX_PATH).toUtf8().data()); desktopFile.write("" qt-widgets-gui --single-instancenComment=" APP_DESCRIPTION "n" "Icon=" PROJECT_NAME "n" "Type=Applicationn" </ins>

Related discussion:
text: The tray icon appears, but he according window shows: Steps to reproduce the behavior: syncthingtray (through home.packages in home-manager in my case) on the tray icon The proper GUI with shiny buttons and stuff
Didn't have time to do actual digging yet, but seems like it's actually a matter of launching it / nixos weirdness rather then the package itself at fault: if I run manually from the terminal it actually works as expected. if I have it launched by plasma's autostart it sits in the tray failed with the message above. if I have it launched as user systemd service through the according home-manager option, it fails to launch because it can not find the tray altogether (probably launched before plasma is ready). So the question is, why is it different when launched from autostart... The message shows the right path in after all... (Disclaimer: total nixos noob here. Maybe it's obvious for a more experienced user...)
I'd investigate this by comparing the environment of your terminal to the environment of autostart's file - try to override the line to something like:
Oh I see what's the problem.. the file generates is pointing in to the unwrapped executable.. This needs to be patched locally in nixpkgs!
That would explain it. What do you mean by "patched locally"?
I mean this:
you are invited to test the fix for your issue in .
I'm really sorry it took me forever to actually test it - had issues with the system I use it on. Anyway, the desktop file wasn't my issue either - I didn't realize the thing in tray is not the autostarted desktop file / syncthingtray process, but the plasmoid which is apparently a completely different beast running within the plasmashell process rather then a separate one. It appears automatically in tray unless I use syncthingtray with and can not be removed from there through plasma controls. Launching the process actually creates a second icon, which behaves properly.
I'm not sure I followed.. Does it work if you set ? has landed in so the environment issue fixed there should affect you somehow I think. Feel free to reopen the issue.
No, the plasmoid is what fails. The plasmoid seems to be launched in a different way, independent from the desktop file.
Code change:
<ins> diff --git i/widgets/settings/settingsdialog.cpp w/widgets/settings/settingsdialog.cpp index 4deff1f..16845b5 100644 --- i/widgets/settings/settingsdialog.cpp +++ w/widgets/settings/settingsdialog.cpp @@ -802,7 +802,7 @@ bool setAutostartEnabled(bool enabled) desktopFile.write("[Desktop Entry]n" "Name=" APP_NAME "n" "Exec=""); -        desktopFile.write(qEnvironmentVariable("APPIMAGE", QCoreApplication::applicationFilePath()).toUtf8().data()); +        desktopFile.write(qEnvironmentVariable("APPIMAGE", EXEC_NIX_PATH).toUtf8().data()); desktopFile.write("" qt-widgets-gui --single-instancenComment=" APP_DESCRIPTION "n" "Icon=" PROJECT_NAME "n" "Type=Applicationn" </ins>

Related discussion:
text: Whenever I include syncthingtray in the home manager with (which is default), the plasmoid appears in tray on next login - but no process exists. It seems to run as part of plasmashell instead and is not in the autostart at this point. Autostart seems to be a different way to start it as an alternative to the plasmoid stuff, the plasmoid is however what is running by default with the current syncthingtray package. Doesn't seem like I have permissions to reopen it in place.
According to the initially reported issue description it is indeed the Plasmoid that's causing problems here. On Plasma the Plasmoid is supposedly the preferred UI. So the goal should be to fix it. If you nevertheless want to use the executable instead you can do that of course as well. Then you can simply disable the Plasmoid by removing it from all panels/screen as usual. If the Plasmoid is shown as part of Plasma's system tray Plasmoid, you can disable it via the settings of the system tray Plasmoid. To fix the actual issue of the Plasmoid: Supposedly a file is missing in the package. The full list of files to be contained by the package should currently look like this: Of course the exact paths depend on your install prefix and paths of your Qt and Plasma installation. Maybe something is not missing but installed to the wrong directory. Did the Plasmoid (not the stand-alone executable) ever work with your packaging? If it did then I'd try to compare the last working package with the first bad.
Note that an override for the executable path (via a CMake option that then sets a define which is used if present like in your patch) could be upstreamed.
I was thinking about it just today, since usually you'd want it to be the permanent symlink and not the path (to the wrapped executable) that might be removed after a garbage collection.. Let's continue this discussion in
What is the status on this?
Code change:
<ins> diff --git i/widgets/settings/settingsdialog.cpp w/widgets/settings/settingsdialog.cpp index 4deff1f..16845b5 100644 --- i/widgets/settings/settingsdialog.cpp +++ w/widgets/settings/settingsdialog.cpp @@ -802,7 +802,7 @@ bool setAutostartEnabled(bool enabled) desktopFile.write("[Desktop Entry]n" "Name=" APP_NAME "n" "Exec=""); -        desktopFile.write(qEnvironmentVariable("APPIMAGE", QCoreApplication::applicationFilePath()).toUtf8().data()); +        desktopFile.write(qEnvironmentVariable("APPIMAGE", EXEC_NIX_PATH).toUtf8().data()); desktopFile.write("" qt-widgets-gui --single-instancenComment=" APP_DESCRIPTION "n" "Icon=" PROJECT_NAME "n" "Type=Applicationn" </ins>

Related discussion:
text: I'm still encountering this issue on my machine
I'm not sure what more could I do here.. I will report here after comment that there are no much differences between the files installed by our package and what should be installed: <details<summary<codediff our- upstream-</code</summary</details
Is this a problem affecting all NixOS users or is it just reproducible in the setup of a few people. For debugging it might help to start with the env variable set.
I'd only compare the packaging with how other Plasmoids for NixOS are packaged. Maybe there actually needs to be a difference compared to my "upstream packaging".
I don't experience this issue, here on Gnome, naturally. Other packages in Nixpkgs, like , and also put files in , according to .
Yes, you would obviously need to start a Plasma session to reproduce the issue. (Or just launch or in another session. I suppose will work in any X11 session and in any X11 or Wayland session.) Maybe it makes more sense if the users that actually use Plasma would do further debugging on their side, though. By the way, how do you use Syncthing Tray under GNOME? Last time I've checked whether it works there was no general support for system tray icons at all and issues like suggest that GNOME has no generic system tray icon support at all right now. If there are any workarounds those might be worth documenting under and could be extended with a remark to the workaround section.
As a note, I'm a pretty new NixOS user, but I switched yesterday to the unstable channel, and syncthingtray is working completely fine now.
Using .
Thanks for the report. I wonder what was the problem... I'll close this in the meantime, unless someone from the stable channels will give a detailed bug report.
Code change:
"-X gitlab.com/olaris/olaris-server/helpers.Version=${version}" ]; <del> vendorHash = "sha256-xWywDgw0LzJhPtVK0aGgT0TTanejJ39ZmGc50A3d68U="; </del> <ins> vendorHash = "sha256-bw8zvDGFBci9bELsxAD0otpNocBnO8aAcgyohLZ3Mv0="; </ins> <del> nativeBuildInputs = [ installShellFiles ]; </del> <ins> nativeBuildInputs = [ installShellFiles makeWrapper ]; </ins> # integration tests require network access doCheck = false;

Related discussion:
text: Olaris server requires ffmpeg to be available and raises an error when it can't be found: Steps to reproduce the behavior: olaris-server a library. The software runs correctly. There are two main ways to fix this: the software to use the full path to the ffmpeg dependency (ideally upstream). the program to add ffmpeg to its path. Please run and paste the result.
In fact it looks like it needs a custom image as it passes arguments that only exist on the modified version.
Actually it looks like the fork is no longer required: But this doesn't seem to be released yet. But probably is still a better option than packaging the custom ffmpeg.
yep, this looks like an easy fix EDIT: I was keen to try building the ffmpeg fork so that we can stick to a released version, however that proved prohibitively difficult, so tip of the default branch it is
no action required, but note the way I used in the pr and commit, means this issue would have autoclosed when the change merged
That is what happened.
sorry, I only saw this issue's update and assumed that you manually closed it; I assume most people involved in nixpkgs prs do not have merge perms, and github really needs to work on their ux. terribly sorry for the hassle, and assuming you were a more novice user.
No worries, GitHub really doesn't make it clear.
Code change:
- [go-camo](https://github.com/cactus/go-camo), a secure image proxy server. Available as [services.go-camo](#opt-services.go-camo.enable). <ins> - [Monado](https://monado.freedesktop.org/), an open source XR runtime. Available as [services.monado](#opt-services.monado.enable). </ins> - [Clevis](https://github.com/latchset/clevis), a pluggable framework for automated decryption, used to unlock encrypted devices in initrd. Available as [boot.initrd.clevis.enable](#opt-boot.initrd.clevis.enable). - [TuxClocker](https://github.com/Lurkki14/tuxclocker), a hardware control and monitoring program. Available as [programs.tuxclocker](#opt-programs.tuxclocker.enable).

Related discussion:
text: The [monado] package doesn't install the udev rules generated by the [xr-hardware util] from the Monado project. Install the package and check the lack of udev rules in It was expected for the udev rules to be installted with the package. The udev rules are needed as some hmd's have some strange and specific permissions. Maybe instead of adding this to the package, monado could turn into an option like . <!-- 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]: [monado]: [xr-hardware util]:
Trying packaging the udev rules similar to how . [brscan4]:
I was working on a Monado NixOS module. Perhaps I can deal with udev rules there. See
Code change:
bridge-utils = callPackage ../os-specific/linux/bridge-utils { }; <del> busybox = callPackage ../os-specific/linux/busybox { }; </del> <ins> busybox = callPackage ../os-specific/linux/busybox { # Fixes libunwind from being dynamically linked to a static binary. stdenv = if (stdenv.targetPlatform.useLLVM or false) then overrideCC stdenv buildPackages.llvmPackages.clangNoLibcxx else stdenv; }; </ins> busybox-sandbox-shell = callPackage ../os-specific/linux/busybox/sandbox-shell.nix { # musl roadmap has RISC-V support projected for 1.1.20 busybox = if !stdenv.hostPlatform.isRiscV && !stdenv.hostPlatform.isLoongArch64 && stdenv.hostPlatform.libc != "bionic"

Related discussion:
text: 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. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This looks to me like the compiler wrapper isn't respecting and/or , and it's inappropriately passing the libunwind shared object. I don't have immediate time to investigate further but did discover this minimal reproducer:
looks the same as which is due to (search path prefers .so files with ). i agree that passing in libunwind unconditionally seems not good. if one builds libcxx with the linker script at will result in but we don't so we add unconditionally. it is not clear to me why c code needs libunwind.
Code change:
tryExec = "itch"; icon = "itch"; desktopName = "itch"; <del> mimeTypes = [ "x-scheme-handler/itchio" "x-scheme-handler/itch" ]; </del> <ins> mimeTypes = [ "x-scheme-handler/itchio" "x-scheme-handler/itch" ]; </ins> comment = "Install and play itch.io games easily"; categories = [ "Game" ]; })

Related discussion:
text: Package name: itch Latest released version: 26.1.3 Current version on the unstable channel: 26.1.3 Current version on the stable/release channel: 26.1.3 <!-- 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! --- The current version is broken since butler is marked broken 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]:
The latest version on seems to be 26.1.3 which is used in the package.
There is 26.1.5 as a source code , but current package uses binaryBytecode
Code change:
optionalString config.security.pam.enableEcryptfs '' session optional ${pkgs.ecryptfs}/lib/security/pam_ecryptfs.so '' + <ins> optionalString config.security.pam.enableFscrypt '' # Work around https://github.com/systemd/systemd/issues/8598 # Skips the pam_fscrypt module for systemd-user sessions which do not have a password # anyways. # See also https://github.com/google/fscrypt/issues/95 session [success=1 default=ignore] pam_succeed_if.so service = systemd-user session optional ${pkgs.fscrypt-experimental}/lib/security/pam_fscrypt.so '' + </ins> optionalString cfg.pamMount '' session optional ${pkgs.pam_mount}/lib/security/pam_mount.so disable_interactive '' +

Related discussion:
text: I would like to use to encrypt my home directory. is already packaged (as , for some reason) What's missing is the PAM setup (). Given that exists for EcryptFS, I would like to request support for via the option, or something similar. I am aware that EcryptFS is available, to achieve the same goals, however it seems to be considered deprecated by other distributions (, ) and has some which I am not comfortable with.
This is just to say hi and to share that I too am interested in this feature
I marked this as stale due to inactivity. &rarr;
Code change:
}; nativeBuildInputs = [ python3 dune_3 makeWrapper ]; <del> buildInputs = [ poppler_utils ] ++ (with ocamlPackages; [ oseq spelll notty nottui lwd cmdliner domainslib digestif yojson eio_main containers-data timedesc ]); </del> <ins> buildInputs = with ocamlPackages; [ oseq spelll notty nottui lwd cmdliner domainslib digestif yojson eio_main containers-data timedesc ]; </ins> postInstall = '' # docfd needs pdftotext from popler_utils to allow pdf search <del> wrapProgram $out/bin/docfd --prefix PATH : "${lib.getBin poppler_utils}/bin/" </del> <ins> # also fzf for "docfd ?" usage wrapProgram $out/bin/docfd --prefix PATH : "${lib.makeBinPath [ poppler_utils fzf ]}" </ins> ''; meta = with lib; { description = "TUI multiline fuzzy document finder"; longDescription = '' <del> Interactive grep, but word/token/phrase based rather than regex and line based, so you can search across multiple lines (simlar to Recoll but TUI). Aims to provide a good UX via text editor and PDF viewer integration. When opening a text file, Docfd opens file at first line of search result. If PDF, then Docfd opens file at first page of the search result and starts a text search of the most unique word of the matched phrase within the same page. Main intended use case: navigating directories of notes and PDFs. </del> <ins> TUI multiline fuzzy document finder. Think interactive grep for both text files and PDFs, but word/token based instead of regex and line based, so you can search across lines easily. Docfd aims to provide good UX via integration with common text editors and PDF viewers, so you can jump directly to a search result with a single key press. </ins> ''; homepage = "https://github.com/darrenldl/docfd"; license = licenses.mit;

Related discussion:
text: needs in it's path to be able to use the fuzzy file picker, e.g. produces file picker should open <!-- 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]:
Code change:
stdenv.mkDerivation rec { pkgname = "conkeror"; <del> version = "1.0pre-20160130"; </del> <ins> version = "1.0.3"; </ins> name = "${pkgname}-${version}"; src = fetchgit { url = git://repo.or.cz/conkeror.git; <del> rev = "3e4732cd0d15aa70121fe0a0403103b777c964bf"; sha256 = "1299b1kdfd2vip3w02jzvj2i8scjpsvpx19d2c8ms2pizz7xxmp4"; </del> <ins> rev = "refs/tags/${version}"; sha256 = "06fhfk8km3gd1lc19543zn0c71zfbn8wsalinvm1dbgi724f52pd"; </ins> }; buildInputs = [ unzip makeWrapper ];

Related discussion:
text: I bumped the version in which fixed the problem for me. Can you confirm?
confirm: Fix the issue. (your changes not in unstable yet). Thank you!