jiebi/CodeConvo huggingface dataset:
Code change:
<del> <section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xi="http://www.w3.org/2001/XInclude" xml:id="sec-pkgs-ociTools"> <title>pkgs.ociTools</title> <para> <varname>pkgs.ociTools</varname> is a set of functions for creating containers according to the <link xlink:href="https://github.com/opencontainers/runtime-spec">OCI container specification v1.0.0</link>. Beyond that it makes no assumptions about the container runner you choose to use to run the created container. </para> <section xml:id="ssec-pkgs-ociTools-buildContainer"> <title>buildContainer</title> <para> This function creates a simple OCI container that runs a single command inside of it. An OCI container consists of a <varname>config.json</varname> and a rootfs directory.The nix store of the container will contain all referenced dependencies of the given command. </para> <para> The parameters of <varname>buildContainer</varname> with an example value are described below: </para> <example xml:id='ex-ociTools-buildContainer'> <title>Build Container</title> <programlisting> buildContainer { args = [ (with pkgs; writeScript "run.sh" '' #!${bash}/bin/bash exec ${bash}/bin/bash '').outPath ]; <co xml:id='ex-ociTools-buildContainer-1' /> mounts = { "/data" = { type = "none"; source = "/var/lib/mydata"; options = [ "bind" ]; }; };<co xml:id='ex-ociTools-buildContainer-2' /> readonly = false; <co xml:id='ex-ociTools-buildContainer-3' /> } </programlisting> <calloutlist> <callout arearefs='ex-ociTools-buildContainer-1'> <para> <varname>args</varname> specifies a set of arguments to run inside the container. This is the only required argument for <varname>buildContainer</varname>. All referenced packages inside the derivation will be made available inside the container </para> </callout> <callout arearefs='ex-ociTools-buildContainer-2'> <para> <varname>mounts</varname> specifies additional mount points chosen by the user. By default only a minimal set of necessary filesystems are mounted into the container (e.g procfs, cgroupfs) </para> </callout> <callout arearefs='ex-ociTools-buildContainer-3'> <para> <varname>readonly</varname> makes the container's rootfs read-only if it is set to true. The default value is false <literal>false</literal>. </para> </callout> </calloutlist> </example> </section> </section> </del>

Related discussion:
text: 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.
Hi Already opened a PR for that ().
Code change:
# NAT from external ports to internal ports. ${concatMapStrings (fwd: '' iptables -w -t nat -A nixos-nat-pre  <del> -i ${cfg.externalInterface} -p tcp  </del> <ins> -i ${cfg.externalInterface} -p ${fwd.proto}  </ins> --dport ${builtins.toString fwd.sourcePort}  -j DNAT --to-destination ${fwd.destination} '') cfg.forwardPorts}

Related discussion:
text: Should there be an ability to specify UDP port forwarding in the nat module? It would necessitate an extra property in the forwarding list specification, like .
Has done this!
Code change:
sha256 = "02pihqb1lb76a0xbfwjzs1cd6ay3ldfxsm8dvsbl6qs3vkjxax56"; }; <del> patchPhase = stdenv.lib.optionalString stdenv.cc.isClang '' </del> <ins> patches = [ ./gfan-0.6.2-cddlib-prefix.patch ]; postPatch = stdenv.lib.optionalString stdenv.cc.isClang '' </ins> substituteInPlace Makefile --replace "-fno-guess-branch-probability" "" ''; <del> buildFlags = [ "CC=cc" "CXX=c++" "cddnoprefix=1" ]; </del> <ins> buildFlags = [ "CC=cc" "CXX=c++" ]; </ins> installFlags = [ ''PREFIX=$(out)'' ]; buildInputs = [ gmp mpir cddlib ];

Related discussion:
text: Describe the bug Building fails with the following messages: Note that points to which updates . To Reproduce Steps to reproduce the behavior: Expected behavior The package is built successfully. Notify maintainers (gfan, cddlib), (cddlib) Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(omasanori): nixpkgs: Maintainer information:
cddlib put its .h file in <hash-cddlib-0.94l/include/cddlib/ rather than the old version of the library placing it .h headers in the root. <hash-cddlib-0.94j/include/ So options are get upstream to #include "cddlib/setoper.h" (and the rest of the directly pathed includes) Patch it in the derivation Take a look at the library is being why it differs from 0.94j to 0.94l ...... and see if can be symlinked (botched). not sure why it's subpathing these .h file now?
v0.94k header files are now installed to PREFIX/include/cddlib to avoid clashes with other libraries. configuration file for pkg-config : assuming cddlib installed in <prefixknown to pkg-config, "pkg-config --cflags cddlib" etc will work. (Otherwise, one would need PKGCONFIGPATH=<prefix/lib/pkgconfig). this is the source of the breakage. this probably breaks everything that uses this library.... lovely! So, options are fix it gfan upstream, or patch it in nix?????? has a 41 length thread, where the developers are trying to workout how not to break any application that uses this library and which distro's they want to break.
Thank you for your survey, The long-term solution would be fixing gfan upstream, given that this is not Nix-specific. The current Makefile assumes that, if cddlib headers are prefixed, the prefix is instead of . A variable to change the prefix will help every package maintainer IMHO. However, adding a patch to gfan just altering with into nixpkg may be fine for now. I will try to address it next week but feel free to make a PR if it is urgent for anyone.
Code change:
{ lib <ins> , cacert </ins> , fetchFromGitHub , fetchpatch , python3Packages

Related discussion:
text: chia farmer fails to register with a pool over https. Relevant log contains: Steps to reproduce the behavior: a new-style chia plot with a pool up a farming node Chia should successfully run. If applicable, add screenshots to help explain your problem. Based on , the missing file is . Upstream normally but this appears to fail here. (This is in an LXC container so it's a bit weird) system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
Code change:
--replace "/usr/include/linux/capability.h" "${linuxHeaders}/include/linux/capability.h" ''; <del> patches = lib.optionals stdenv.hostPlatform.isMusl [ </del> <ins> patches = [ ./0001-aa-remove-unknown_empty-ruleset.patch ] ++ lib.optionals stdenv.hostPlatform.isMusl [ </ins> (fetchpatch { url = "https://git.alpinelinux.org/aports/plain/testing/apparmor/0003-Added-missing-typedef-definitions-on-parser.patch?id=74b8427cc21f04e32030d047ae92caa618105b53"; name = "0003-Added-missing-typedef-definitions-on-parser.patch";

Related discussion:
text: Apparmour service doesn't reload correctly after a system switch. Steps to reproduce the behavior: anything in config with apparmor enabled nixos-rebuild switch error of apparmor service failing to restart No error, apparmor starting as it should Here my service log: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'm encountering the exact same error here.
Same issue here
Same for the issues after . However do a after that just fine.
Someone once told me that the state of AA in NixOS wasn't great. But I don't know first hand. Could be wrong. I lack any knowledge at all to even figure out the root cause of the issue. :/
AA seems to work fine in general. Just the service restart after a nixos-rebuild doesn't work.
Tested just now on nixos-23.11. AppArmor service restarts without any issues after nixos-rebuild. I think this issue is resolved.
Reopening this issue as unresolved. Currently on 24.05.. and this issue seems to be persisting after a nixos-rebuild: reloading the following units: apparmor.service, dbus.service Job for apparmor.service failed. See "systemctl status apparmor.service" and "journalctl -xeu apparmor.service" for details.
I did some more investigation on this. I have one system with a custom apparmor profile and another system with no profiles. On the system I have with a custom apparmor profile, nixos-rebuild works fine. On the other system without any apparmor profiles, nixos-rebuild fails with the message in this bug report. After nixos-rebuild, journalctl reports: In I tried running "sudo aa-remove-unknown" from zsh: The error message matches what is in the system log. I think this may be related to the aa-remove-unknown step.
As a workaround, adding this to appears to work: After this, the first nixos-rebuild switch will still cause the issue (because the profile is not installed yet). But on the second and subsequent nixos-rebuilds, there is no error message on my system.
Code change:
--replace "/usr/include/linux/capability.h" "${linuxHeaders}/include/linux/capability.h" ''; <del> patches = lib.optionals stdenv.hostPlatform.isMusl [ </del> <ins> patches = [ ./0001-aa-remove-unknown_empty-ruleset.patch ] ++ lib.optionals stdenv.hostPlatform.isMusl [ </ins> (fetchpatch { url = "https://git.alpinelinux.org/aports/plain/testing/apparmor/0003-Added-missing-typedef-definitions-on-parser.patch?id=74b8427cc21f04e32030d047ae92caa618105b53"; name = "0003-Added-missing-typedef-definitions-on-parser.patch";

Related discussion:
text: Can someone else try it and see if it works on their system too? If so, it may help to figure out the proper solution.
I tried it and it actually rebuilds without error the first time too. Hopefully that helps you or someone else figure out a permanent fix! Many thanks.
From my side the issue seems to be be fixed with the merged fixes. So I will close the issue.
If anyone wants to track the merger of the fix :
Code change:
}; nativeBuildInputs = [ pkgconfig python makeWrapper ]; <del> buildInputs = [ </del> <ins> buildInputs = [ gcc </ins> python libsamplerate libsndfile readline

Related discussion:
text: nix-shell -p supercollider [anders $ nixos-version (Flounder) [anders $ nix-env --version nix-env (Nix) 1.11.2 [anders $ nix-instantiate --eval '<nixpkgs' -A lib.nixpkgsVersion ""
you use supercollider ?
no, sorry.
Same here:
Code change:
''; }; <ins> users.allowNoPasswordLogin = mkOption { type = types.bool; default = false; description = '' Disable checking that at least the <literal>root</literal> user or a user in the <literal>wheel</literal> group can log in using a password or an SSH key. WARNING: enabling this can lock you out of your system. Enable this only if you know what are you doing. ''; }; </ins> };

Related discussion:
text: Describe the bug There are reasons to want a system, that has no user that can log in by SSH or with their password, for example in a declarative container To Reproduce Steps to reproduce the behavior: up a minimal declarative container asserts that I will be locked out from the system and refuses to build the configuration with Expected behavior nix generates me a container that I can log in with , or maybe I don't want to log into it at all (because it's a disposable VM or something of the like). I think there should be a check whether the generated system is a container and an additional "I know what I'm doing" override for other cases. I'll create a PR once we agreed on what's best. Maintainer information: Code causing the problem: mentioning since you the check.
Is it an option to set a randomly-generated (the hash itself would be generated, not obtained by honestly hashing a password)? Recovering the password from such a hash is probably harder than a lot of other attack vectors. But an override «doLockOutEveryone» sounds fine.
Setting a password would certainly be a possibility, but somewhat (for lack of a better word) really lame. Having slept a night over it, I propose , that disables all the assertions at the bottom. I can see scenarios where two users with the same uid could be wanted. I want my unixoid to always give me enough rope to shoot myself in the leg.
What about not enabling ssh and disabling the getty? It should completely lock anyone out, unless I am missing something. Take a look at the profile.
In case of a nixos declaratively defined nixos container, you are not logged out because the root system(d) can generate a root shell without any authentication, which is why I consider this a bug. Having to "fool" the assertion to actually lock oneself out is another matter, I could live with that but I don't think it's nice behavior.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this.
Code change:
''; }; <ins> users.allowNoPasswordLogin = mkOption { type = types.bool; default = false; description = '' Disable checking that at least the <literal>root</literal> user or a user in the <literal>wheel</literal> group can log in using a password or an SSH key. WARNING: enabling this can lock you out of your system. Enable this only if you know what are you doing. ''; }; </ins> };

Related discussion:
text: Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
This is still an issue.
I marked this as stale due to inactivity. &rarr;
Fixed via
Code change:
<del> { lib, stdenv, fetchurl, wrapGAppsHook, makeDesktopItem </del> <ins> { lib , stdenv , fetchurl , wrapGAppsHook , makeDesktopItem </ins> , atk , cairo , coreutils

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 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: zotero <!-- The current version can be found easily with the same process as 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: 5.0.96.3 desired version: 6.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:
nativeBuildInputs = [ appstream-glib <ins> cargo </ins> desktop-file-utils gettext glib # glib-compile-resources

Related discussion:
text: Describe the bug fails to compile with Additional context See for a possible cause. Notify maintainers cc (sorry for notifying you here and in the PR!)
Gonna try to just switch it to . We should probably update gnome docs for Rust+Gnome packages
Yeah, I think that would be best. The idea of the hooks is that is not necessary anymore in mixed projects. I will also do a PR for cargoBuildHook, since it should not be used when is set explicitly.
Code change:
, makeWrapper, ed , glib, gtk3, gnome3, gsettings-desktop-schemas, gn, fetchgit , libva ? null <ins> , pipewire_0_2 </ins> , gcc, nspr, nss, patchelfUnstable, runCommand , lib

Related discussion:
text: Project description This flag is available in most other major distros. It is necessary to enable screen sharing on wayland inside of chromium, combined with xlr-desktop-portal-wlr and pipewire. It requires the build flag and a dependency on libpipewire02. See as an example. Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ...
that would definitely be nice to have :) I actually also noticed this but unfortunately cannot test this easily as I'm not using screen sharing. If you could contribute a PR that would be awesome (but be aware that Chromium does unfortunately take quite some time to compile). Alternatively (but less preferably) we could make the required changes with the next update and test the core functionality (as always) and you could test screen sharing after the new version is available in the binary caches. Additionally we would need to package in Nixpkgs to make this work on wlroots based compositors. On Gnome/KDE this might work out-of-the-box, but I don't know what they currently implement/provide.
was just merged w/ . I'll try building chromium w/ the flag - as you say it takes a while, so I can leave it overnight and give it a shot.
how does the situation look like with ? Is the flag available there, as in, screensharing with wayland already works there?
yes, it's available in google-chrome. ! I'm still trying to get it to work with xlr-desktop-portal-wlr - I've done this in the past, but it's not working out of the box yet with
And just to make sure, you also did set as described there?
yes I did. I'm almost got it working I think. There are a few issues out of the box: -chrome is missing the pipewire 0.2 runtime dependency, so I it as (I'm on 20.03 so pkgs.pipewire is 0.2): .pipewire service doesn't work - it doesn't seem to be setting up the path correctly. I'm trying to fix this now: My current config on 20.03 looks like: Where is the same package that was recently merged.
Code change:
, makeWrapper, ed , glib, gtk3, gnome3, gsettings-desktop-schemas, gn, fetchgit , libva ? null <ins> , pipewire_0_2 </ins> , gcc, nspr, nss, patchelfUnstable, runCommand , lib

Related discussion:
text: yeah, I'm currently already looking at it - pipewire wants to execute , but it's not in . We can patch to contain the absolute path. I'll check if it works and will get back to you.
Btw, we /really/ need a sway NixOS test, and better documentation on how to use sway. I was trying stuff until it worked, and does autologin me into a sway, but there might be a smarter way to do this, without also starting X.
The sway recommendation is to just run sway from the terminal after login - that's how I do it at least. I was able to workaround the environment issue by doing (but this is a kludge I think and shouldn't be necessary). But unfortunately it's now crashing and I'm not sure why:
Yeah, even my sddm config I also had to , otherwise pipewire complained about not being able to reach dbus: Afterwards, it segfaulted, as it wasn't able to find ; I patched to be able to find the path to , and that error message is gone. Now (apart from not being able to find bluez or rtkit) it /might/ only be some version incompatibilities, not sure: I'll see if I can get as far with your chromium PR, will merge that then, and also submit the pipewire patch.
Okay, with the pipewire patch and , It seems I'm able to share at least my own application window :tada:. I don't know yet why the alacritty window nearby isn't shown, and why "Entire Screen" is black, but that's probably due to me running sway inside X via ssdm.
pipewire PRs:
I don't think you're using pipewire in that case. xdg-desktop-portal-wlr only supports full screen sharing atm. If it is black that means it's not working. By the way I had to add pipewire02 to my system packages to prevent xdg-desktop-portal from crashing. But now there seems to be some incompatibility in the pipewire service logs when chrome tries to connect:
you should be able to cherry-pick the to not have to manually add this to $PATH.
Thanks! I'm suspecting google-chrome is compiled with a too old version of pipewire.
Code change:
, makeWrapper, ed , glib, gtk3, gnome3, gsettings-desktop-schemas, gn, fetchgit , libva ? null <ins> , pipewire_0_2 </ins> , gcc, nspr, nss, patchelfUnstable, runCommand , lib

Related discussion:
text: Enabling pipewire debug logs, it seems to be sending an incompatible format to the pipewire server (similar to ). I have got this working with chromium compiled against pipewire 0.2.7 in the past, so I'm pretty sure it should work assuming the client library is recent enough. Once the chromium package has that flag enabled I'll try to retest.
I just confirmed my last comment by building chromium locally w/ rtcusepipewire=true. It works perfectly for fullscreen sharing.
Hmm take that back - it worked the first time but not anymore :/. Not sure what lib is missing where.
Seems like xdg-desktop-portal is crashing:
This might be yet another version incompatibility problem. I propose merging (as it's built with 0.2 everywhere else too), and then see if we can get it to work if the system pipewire also is 0.2. I asked upstream about these problems in - maybe 0.3 needs to support 0.2 clients for some time until we should switch.
Heads-up: the bad client situation should have been fixed with the latest pipewire release, PR at
Thanks for your help! I'm still getting the xdg-desktop-portal crash, however. I'm guessing there is something missing from my dbus environment - or perhaps it's trying to access a file/directory not available in nixos.
could you open a new issue with some more details, like logs etc.?
Okay, I made
Code change:
makeWrapper $out/lib/paperless-ngx/src/manage.py $out/bin/paperless-ngx  --prefix PYTHONPATH : "${pythonPath}"  --prefix PATH : "${path}" <del> makeWrapper ${python.pkgs.celery}/bin/celery $out/bin/celery  </del> <ins> makeWrapper ${lib.getExe python.pkgs.celery} $out/bin/celery  </ins> --prefix PYTHONPATH : "${pythonPath}:$out/lib/paperless-ngx/src"  --prefix PATH : "${path}"

Related discussion:
text: Package name: paperless-ngx Latest released version: 2.12.1 <!-- Search your package here: --- Current version on the unstable channel: 2.11.6 <!-- 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. --
Code change:
# When the extension is already available in the default extensions set. vscodeExtensions = with vscode-extensions; [ bbenoist.Nix <del> ] </del> <ins> ] </ins> # Concise version from the vscode market place when not available in the default set. ++ vscode-utils.extensionsFromVscodeMarketplace [

Related discussion:
text: Rofi doesn't seem to find the application for VSCode even though the .desktop file seems to be there. It shows the command when running but when running it doesn't seem it show.
Code change:
, vala , wrapGAppsHook , dbus <ins> , systemd </ins> , dconf ? null , glib , gdk-pixbuf , gobject-introspection , gtk2 , gtk3 <ins> , gtk4 </ins> , gtk-doc , runCommand , isocodes

Related discussion:
text: Upstream ibus-1.5.24 (in nixpkgs) supports gtk4. It will be good if we enable gtk4 support in nixpkgs. I fail to enable it with the following patch.
Code change:
let withPlugins = plugins: buildPythonPackage { <del> name = "${package.name}-with-plugins"; </del> <ins> pname = "${package.pname}-with-plugins"; inherit (package) version; </ins> dontUnpack = true; <ins> dontBuild = true; doCheck = false; </ins> nativeBuildInputs = [ makeWrapper ]; propagatedBuildInputs = plugins ++ package.propagatedBuildInputs;

Related discussion:
text: Cannot run the git tests because is broken. Steps to reproduce the behavior: The build should work, the git tests should run and pass Please run and paste the result.
Code change:
tuxtype = callPackage ../games/tuxtype { }; <ins> tworld2 = callPackage ../games/tworld2 { }; </ins> speed_dreams = callPackage ../games/speed-dreams { # Torcs wants to make shared libraries linked with plib libraries (it provides static). # i686 is the only platform I know than can do that linking without plib built with -fPIC

Related discussion:
text: Project description Tile World 2 Metadata homepage URL: source URL: license: gpl2+ platforms: linux