jiebi/CodeConvo huggingface dataset:
Change:
limesurvey = handleTest ./limesurvey.nix {}; listmonk = handleTest ./listmonk.nix {}; litestream = handleTest ./litestream.nix {}; <ins> lldap = handleTest ./lldap.nix {}; </ins> locate = handleTest ./locate.nix {}; login = handleTest ./login.nix {}; logrotate = handleTest ./logrotate.nix {};

Discussion:
Project description An lightweight authentication server that provides an opinionated, simplified LDAP interface for authentication: clients that can only speak LDAP protocol can talk to it and use it as an authentication server. Metadata homepage URL: source URL: license: platforms: unix
Here is what I came up with so far (with big help from :heart:):
I marked this as stale due to inactivity. &rarr;
Still relevant
I gave it a try in in case someone would like to take a look at it :)
Change:
cd $out fi <del> # Remove symlinks to the input tarballs, they aren't needed. rm $out/*.tar.gz </del> <ins> # Remove symlinks to the input tarballs, they aren't needed, use -f so it # will not fail if no .tar.gz symlinks are there - for example if # sommething which is not a tarball used as a package rm -f $out/*.tar.gz </ins> createOctavePackagesPath $out ${octave} <ins> # Create the file even if the loop afterwards has no packages to run over touch $out/.octave_packages </ins> for path in ${lib.concatStringsSep " " packages}; do if [ -e $path/*.tar.gz ]; then $out/bin/octave-cli --eval "pkg local_list $out/.octave_packages; 

Discussion:
Describe the bug The new functionality looks super cool (thanks I just notices that it seems to error on an empty list. To Reproduce On latest master run . Output is: Expected behavior Successful build of Octave with no packages installed. Additional context On the other hand, works fine, so this is just a small edge case. Notify maintainers Metadata Maintainer information:
Change:
practices. ''; license = lib.licenses.gpl2Plus; <del> maintainers = with lib.maintainers; [ joshuafern AndersonTorres ]; </del> <ins> maintainers = with lib.maintainers; [ joshuafern AndersonTorres ]; </ins> platforms = lib.platforms.unix; priority = 101; }; }) <del> # TODO: report upstream about not finding SDL2_net </del>

Discussion:
Package name: dosbox-staging Latest released version: 0.81.0 <!-- Search your package here: --- Current version on the unstable channel: 0.80.1 Current version on the stable/release channel: 0.80.1 <!-- 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]:
Change:
postPatch = '' sed -i pam_kwallet_init -e "s|socat|${lib.getBin socat}/bin/socat|" ''; <ins> postFixup = '' wrapQtApp $out/libexec/pam_kwallet_init ''; dontWrapQtApps = true; </ins> }

Discussion:
Describe the bug After upgrading to 19.09pre, I am always asked for a password to unlock from . I don't recall this happening in 19.03 Some more info on how to set this up: To Reproduce Steps to reproduce the behavior: KDE with KWallet enabled out and back in to launch chromium that a password is needed Expected behavior Password used for login is used to unlock kwallet. Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(mbauer): nixpkgs: Maintainer information:
What display manager are you using?
This is the sddm display manager.
I've also noticed this.
I wasn't upgrading from stable, only from ~a few months ago, so it must have been relatively recent.
The issue here is with the pam module then if it's not automatically unlocked. ~Do you use Plasma 5 which adds?~ (read it says you use KDE) I believe this was broken with lightdm and I've recently fixed it there Could you try using lightdm and see if there's a difference?
Yeah, I think this one is KDE specific. Noticed this in my log: Looking at the coredump gives me this: Looks like a wrapping issue. This is what kwallet looks like:
I'd agree that it's most likely a wrapping issue since that's the only other major change we could tie it too. cc
I agree that the failure in sounds like a wrapping issue. Could you confirm that exists? Unfortunately, I can't tell which platform integration plugin it's trying to load; I would need to see the environment in which PAM loads.
twmn now crashes in QGuiApplicationPrivate::createPlatformIntegration again as well (I remember this happening a long time ago) I remember before I could do but even now that doesn't work
This looks like it's not happening anymore on my system. Probably fixed by either or
Actually still seeing it...
Not sure what's happening so I'll run a git bisect on it.
Should be fixed with .
It works correctly on 19.09, but regressed on current unstable:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Hi, I get this again on 20.09 stable.

In my case this happens cause of: Core was generated by `/run/current-system/sw/bin/kwalletd5'. Program terminated with signal SIGSEGV, Segmentation fault. 0x00007fa0556062ec in QObject::disconnect(QObject const, char const, QObject const, char const) () from /nix/store/9fmvcacvkj6s65j3l5pf96nbqwjp73wb-qtbase- /run/current-system/sw/bin/kwalletd5 seems to crash only with Plasma sessions
Change:
<del> { lib , buildGoModule , fetchFromGitHub , nixosTests , caddy , testers , installShellFiles }: let version = "2.7.6"; dist = fetchFromGitHub { owner = "caddyserver"; repo = "dist"; rev = "v${version}"; hash = "sha256-aZ7hdAZJH1PvrX9GQLzLquzzZG3LZSKOvt7sWQhTiR8="; }; in buildGoModule { pname = "caddy"; inherit version; src = fetchFromGitHub { owner = "caddyserver"; repo = "caddy"; rev = "v${version}"; hash = "sha256-th0R3Q1nGT0q5PGOygtD1/CpJmrT5TYagrwQR4t/Fvg="; }; vendorHash = "sha256-ebnSehuhbCY58ctM8IRVMfNxxbJBp6ht9cbuLdGFNek="; subPackages = [ "cmd/caddy" ]; ldflags = [ "-s" "-w" "-X github.com/caddyserver/caddy/v2.CustomVersion=${version}" ]; nativeBuildInputs = [ installShellFiles ]; postInstall = '' install -Dm644 ${dist}/init/caddy.service ${dist}/init/caddy-api.service -t $out/lib/systemd/system substituteInPlace $out/lib/systemd/system/caddy.service --replace "/usr/bin/caddy" "$out/bin/caddy" substituteInPlace $out/lib/systemd/system/caddy-api.service --replace "/usr/bin/caddy" "$out/bin/caddy" $out/bin/caddy manpage --directory manpages installManPage manpages/* installShellCompletion --cmd caddy  --bash <($out/bin/caddy completion bash)  --fish <($out/bin/caddy completion fish)  --zsh <($out/bin/caddy completion zsh) ''; passthru.tests = { inherit (nixosTests) caddy; version = testers.testVersion { command = "${caddy}/bin/caddy version"; package = caddy; }; }; meta = with lib; { homepage = "https://caddyserver.com"; description = "Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS"; license = licenses.asl20; mainProgram = "caddy"; maintainers = with maintainers; [ Br1ght0ne emilylange techknowlogick ]; }; } </del>

Discussion:
Caddy fails to build for riscv64 Steps to reproduce the behavior: ... ... ... A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. 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]:
(please fill out more parts of the bug report template next time) Assuming this is , likely an instance of . Pinging maintainers:
Hi, thanks for the ping :) The fix for this is fairly trivial. Either skip the shell completions/man pages[^1], or use something like But I am upset that you ( didn't even care enough to do the bare minimum and fill out the issue template. [^1]: Technically only the kills the build, not the , because bash pipefail defaults.
i'm sorry for the issue template, it was more of a quick note to myself. i'll do it right next time
Change:
<ins> { lib , buildPythonPackage , fetchFromGitHub , huggingface-hub , nltk , numpy , scikit-learn , scipy , sentencepiece , tokenizers , torch , torchvision , tqdm , transformers }: buildPythonPackage rec { pname = "sentence-transformers"; version = "2.2.2"; format = "setuptools"; src = fetchFromGitHub { owner = "UKPLab"; repo = "sentence-transformers"; rev = "v${version}"; hash = "sha256-hEYpDAL0lliaS1j+c5vaZ0q1hw802jfTUurx/FvgY9w="; }; propagatedBuildInputs = [ huggingface-hub nltk numpy scikit-learn scipy sentencepiece tokenizers torch torchvision tqdm transformers ]; pythonImportsCheck = [ "sentence_transformers" ]; doCheck = false; # tests fail at build_ext meta = with lib; { description = "Multilingual Sentence & Image Embeddings with BERT"; homepage = "https://github.com/UKPLab/sentence-transformers"; license = licenses.asl20; maintainers = with maintainers; [ dit7ya ]; }; } </ins>

Discussion:
Project description Natural Language Search Engine for your Org-Mode and Markdown notes, Beancount transactions and Photos Metadata homepage URL: source URL: license: gpl3 , ...
Change:
}; }; <del> meta.doc = ./livebook.md; </del> <ins> meta = { doc = ./livebook.md; maintainers = with lib.maintainers; [ munksgaard scvalex ]; }; </ins> }

Discussion:
doesn't seem to work as a module Steps to reproduce the behavior: livebook service any env variables or use environment file with any variables first of all, its systemd unit does not appear to start by default. so i did and but it doesn't work, i can't access it either by IP or by domain, which is set up in my nginx configuration as a reverse proxy. some strange things happen while the unit is active [1st screenshot]. also there's nothing in the journal except info messages about the unit itself as i see it, livebook fails to start, but the service is active because something is going on with inside this wrapper script i tried to make it work several different ways: from using option instead of my environment file to writing my very own systemd unit in NixOS configuration file, also using home-manager like so: but that doesn't work too. surely i tried starting livebook manually - and it works as expected [2nd screenshot] module/service works and is accessible systemd livebook unit works and is accessible |
---------------| NixOS 24.05.3214. (Uakari) x86_64 running on a VPS cc Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thank you for reporting this issue. I am ashamed to admit that I have actually known about this for a while now, without doing anything about it. Now that someone else is having problems with the service, I'll prioritize getting something done soon. I'm not actually sure what's going wrong, but it seems like the service hangs in the command. As far as I remember it ends up using 100% cpu and just loop forever. I'll try to take a look at it later this week.
Perhaps you have encountered this issue as well?
I've seen this before and I think it was because livebook was trying to generate a in some weird way. This is my current configuration which works: Could you try manually setting a in your service setup, please?
a screenshot from filtering cpu usage ! not so much is used i've tried setting up a cookie and you can see it works - :pleading_face: thanks!!!! ~<
The issue seems to have been described and debugged here: The solution is to set in the systemd service configuration. I'll mint a PR.
Change:
<xi:include href="locales.xml" /> <xi:include href="nginx.xml" /> <xi:include href="opengl.section.xml" /> <del> <xi:include href="shell-helpers.xml" /> </del> <ins> <xi:include href="shell-helpers.section.xml" /> </ins> <xi:include href="steam.xml" /> <xi:include href="cataclysm-dda.section.xml" /> <xi:include href="urxvt.xml" />

Discussion:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
Done!

This issue tracks the conversion of from Docbook to Commonmark per . If you intend to work on this conversion, please comment below! in this issue that you intend to work on it. (Please also post if you stop working on it) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
Done!
Change:
<del> { stdenv, buildPythonPackage, fetchPypi, pytest }: </del> <ins> { stdenv, buildPythonPackage, fetchPypi, fetchpatch, pytest }: </ins> buildPythonPackage rec { version = "0.4.0";

Discussion:
This expression fails to build on 19.03: The problem is that its checkPhase is not correct as the command cannot be found. I believe that should be in the for it to succeed. Run the below inside The error is: Please run and paste the results.
It can be put in as is usual for pytest because we have multiple versions of it within . However, the tests fail:
Not sure what is causing that error, but I use it fine for my purposes.
How do you use it if it doesn't build? Would you mind making a PR with the fix?
It does build, I use a custom pytest- because I was using it before asking it for inclusion in nixpkgs. Anyway it's now being addressed in:
Change:
eyeD3 podcastparser html5lib <del> gtk3 </del> ]; makeFlags = [

Discussion:
gPodder crashes and dumps core when trying to import an OPML file: Steps to reproduce the behavior: "Subscriptions -Import from OPML file" the crash I'm using KDE Plasma, not Gnome as a desktop, in case that's related to GSettings discovery. gdb backtrace from the coredump: <!-- 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. Maintainer information:
This crash does not appear in the flatpak verision of gPodder, so I assume it is related to our Nix packaging.
Looks like something on my system sets the right environment variable to prevent this crash: I tried to add dconf, gsettings-desktop-schemas and hicolor-icon-theme but nothing seems to be picked up by the . Maybe has a better idea? The crash only happens when I do with nix-shell.
That would be schemas from gtk3 if it crashes on trying to open file chooser.
Yeah but gtk3 is already in so something is off here with
If it is Python package, it needs strictDeps false
indeed fixes this issue, see PR
This is quite a footgun, can we disable from somehow?
Change:
runHook preInstall mkdir -p $out/{bin,${python3.sitePackages}} <del> mv gyb.py "$out/bin/gyb" mv *.py "$out/${python3.sitePackages}/" </del> <ins> mv gyb.py $out/bin/gyb mv *.py $out/${python3.sitePackages}/ </ins> runHook postInstall ''; checkPhase = '' <del> $out/bin/gyb --help > /dev/null </del> <ins> runHook preCheck PYTHONPATH="" $out/bin/gyb --help > /dev/null runHook postCheck </ins> ''; meta = with lib; {

Discussion:
Steps to reproduce the behavior: gyb Seems to fail both on master and on latest unstable. 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]:
Change:
"option 'extraLibraries' removed - use 'with*' options (e.g., 'withJava'), or overrideAttrs to inject extra build dependencies"; packInstall = swiplPath: pack: <del> ''${swiplPath}/bin/swipl -g "pack_install(${pack}, [package_directory("${swiplPath}/lib/swipl/extra-pack"), silent(true), interactive(false)])." -t "halt." </del> <ins> ''${swiplPath}/bin/swipl -g "pack_install(${pack}, [package_directory("${swiplPath}/lib/swipl/extra-pack"), silent(true), interactive(false), git(false)])." -t "halt." </ins> ''; withGui' = withGui && !stdenv.isDarwin; optionalDependencies = []

Discussion:
It seems that errors with when attempting to have in . There has been no updates in the lspserver. I came across this while trying to update my systems. Currently, says , so that was the last build I had with the lsp not causing a build failure. Steps to reproduce the behavior: this expression: It seems this started happening in . Works fine on the parent commit. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It seems adding to allows it to build, it is not clear to me how is being used here as I am not familiar with how packs work in swiProlog and why made this necessary. From looking at that commit in , it appears to be something that changed upstream. This builds:
I can confirm that with 9.1.21, swi-prolog + lsp-server builds just fine, even with the latest packaging. Something must indeed have changed upstream. 9.1.22 is the first version that stops building for me. The notes that the pack system got a refactor at that point, so that's probably what is going on here, but nothing indicates a sudden need for git. If git is now necessary for pack installation (even if we already pre-cloned everything) it should be a dependency. any idea why git became necessary here?
We can resolve this with a patch to SWI-Prolog to respect in the options, then adding that option to our invocation. I submitted a PR to SWI-Prolog (SWI-Prolog/swipl-devel). If upstream merges this, we can just apply the same patch to stable.
swi-prolog 9.2.7 backported the PR mentioned above. I've modified the package definition to supply the proper flag which suppresses git use during extraPacks install.
Change:
#     url = "https://raw.githubusercontent.com/samer--/prolog/master/typedef/release/typedef-0.1.9.tgz"; #     sha256 = "056nqjn01g18fb1b2qivv9s7hb4azk24nx2d4kvkbmm1k91f44p3"; #   }; <del> #   swiProlog = pkgs.swiProlog.override { extraPacks = map (dep-path: "'file://${dep-path}'") [ </del> <ins> #   swi-prolog = pkgs.swi-prolog.override { extraPacks = map (dep-path: "'file://${dep-path}'") [ </ins> #     julian delay list_util typedef #   ]; }; , extraPacks ? []

Discussion:
It seems that errors with when attempting to have in . There has been no updates in the lspserver. I came across this while trying to update my systems. Currently, says , so that was the last build I had with the lsp not causing a build failure. Steps to reproduce the behavior: this expression: It seems this started happening in . Works fine on the parent commit. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It seems adding to allows it to build, it is not clear to me how is being used here as I am not familiar with how packs work in swiProlog and why made this necessary. From looking at that commit in , it appears to be something that changed upstream. This builds:
I can confirm that with 9.1.21, swi-prolog + lsp-server builds just fine, even with the latest packaging. Something must indeed have changed upstream. 9.1.22 is the first version that stops building for me. The notes that the pack system got a refactor at that point, so that's probably what is going on here, but nothing indicates a sudden need for git. If git is now necessary for pack installation (even if we already pre-cloned everything) it should be a dependency. any idea why git became necessary here?
We can resolve this with a patch to SWI-Prolog to respect in the options, then adding that option to our invocation. I submitted a PR to SWI-Prolog (SWI-Prolog/swipl-devel). If upstream merges this, we can just apply the same patch to stable.
swi-prolog 9.2.7 backported the PR mentioned above. I've modified the package definition to supply the proper flag which suppresses git use during extraPacks install.
Change:
cfitsio = callPackage ../development/libraries/cfitsio { }; <del> fontconfig_210 = callPackage ../development/libraries/fontconfig/2.10.nix { }; </del> fontconfig = callPackage ../development/libraries/fontconfig { }; fontconfig-penultimate = callPackage ../data/fonts/fontconfig-penultimate {};

Discussion:
, CVSSv3=7.8 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives.
See also:
PR for unstable: PR for 20.03:
This is still an issue.
oops, sorry
We only use config files. We could probably just delete everything but from the derivation, or remove it from top-level.
Yeah, but we still ship the fontconfig binary in nixpkgs. Is there any reason we still need to provide config files parse-able by 2.10.x fontconfig implementations?
I doubt there is much of a reason these days, nobody will be running programs compiled against fontconfig 2.10. I just do not want to remove it now so that possible breakage caused by is not mixed with potential downfall from removing the unversioned path.
is a new attempt to address this.
Change:
, fetchFromGitHub , fetchpatch , installShellFiles <ins> , wrapGAppsNoGuiHook , gobject-introspection </ins> , libcdio-paranoia , cdrdao , libsndfile <ins> , glib </ins> , flac , sox , util-linux

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!