jiebi/CodeConvo huggingface dataset:
Code change:
ln -sf '${file}' "${local}" '') rules} <del> if [ ! -f /etc/opensnitch-system-fw.json ]; then </del> <ins> if [ ! -f /etc/opensnitchd/system-fw.json ]; then </ins> cp "${pkgs.opensnitch}/etc/opensnitchd/system-fw.json" "/etc/opensnitchd/system-fw.json" fi '');

Related discussion:
text: Opensnitch requires system- file to be placed under /etc/opensnitchd/system- to be able to enable its System rules/Firewall settings to be active and changeable. Steps to reproduce the behavior: to OpenSnitch Statistics to the button on the left navigation window just right of Rules/System Rules. cannot change the firewall settings there. the service complains about it. Being able to access that windows' setting. These screenshot shows the corrected version of the window. ! ! Can be solved temporarily with the nixos config below (the file can be found in opensnitch github repo): <!-- 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.
Explain this line to me My hardware wouldn't be "asus" how do I find the directory for that?
the latest change to the opensnitch module (in unstable) has again a change for deploying the system- file, see the file comes from the opensnitch package and is linked to /etc/openstnichd/system- configuring this file is currently not supported. what would your use case be?
Code change:
<ins> { stdenv , lib , fetchFromGitHub , installShellFiles , binutils-unwrapped , systemd }: stdenv.mkDerivation rec { pname = "beefi"; version = "0.1.1"; src = fetchFromGitHub { owner = "jfeick"; repo = "beefi"; rev = version; sha256 = "1180avalbw414q1gnfqdgc9zg3k9y0401kw9qvcn51qph81d04v5"; }; nativeBuildInputs = [ installShellFiles ]; buildInputs = [ binutils-unwrapped systemd ]; patchPhase = '' substituteInPlace beefi  --replace objcopy ${binutils-unwrapped}/bin/objcopy  --replace /usr/lib/systemd ${systemd}/lib/systemd ''; installPhase = '' install -Dm755 beefi $out/bin/beefi installManPage beefi.1 ''; meta = with lib; { description = "A small script to create bootable EFISTUB kernel images"; license = licenses.gpl3; platforms = platforms.linux; maintainers = with maintainers; [ tu-maurice ]; homepage = "https://github.com/jfeick/beefi"; }; } </ins>

Related discussion:
text: Project description Converts Linux images and kernels into UEFI images. Metadata homepage URL: source URL: license: GPL3 platforms: Linux
Code change:
''; }) ]; <del> services.postfix = { </del> <ins> services.postfix = lib.mkIf cfg.enablePostfix { </ins> recipientDelimiter = "+";         # bake recipient addresses in mail envelopes via VERP config = { owner_request_special = "no";   # Mailman handles -owner addresses on its own

Related discussion:
text: Describe the bug Mailman module in NixOS requires postfix enabled and has no way to configure Mailman to work with other MTAs supported by both NixOS and mailman upstream. To Reproduce Steps to reproduce the behavior: postfix mailman the evaluation with an assertion Expected behavior The Mailman module allows to select an MTA of choice (or even adapts to the currently enabled MTA) Screenshots n/a Additional context Notify maintainers cc Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(vika): nixpkgs: Maintainer information:
It looks like exim's configuration should be RFC42-ised first if we want to inject Mailman-related settings into Exim config, which is a requirement (Mailman requires a custom Exim router and transport).
Yes, the module is currently quite opinionated. If you're willing to contribute exim support that's great.
I see how I could make it work, but the first version of it will require manual editing of Exim's config files (because RFC42-ising Exim will be a pain, even though I have some drafts on how to translate Nix into the syntax that's required), and I'm not sure if it will be merge-worthy enough :3
Exim config is complicated enough as is, I'm not sure adding an intermediate layer from nix will help that much. I also don't really see this integrating well with existing or other exim config. I'm honestly kind of surprised this works for postfix.
Code change:
config.nix.package ] ++ cfg.extraPackages; <del> serviceConfig = rec { </del> <ins> serviceConfig = { </ins> ExecStart = "${cfg.package}/bin/Runner.Listener run --startuptype service"; # Does the following, sequentially:

Related discussion:
text: Working with large repositories on low-memory systems (such as aarch64-linux SBCs) can lead to out-of-storage scenarios with the github-runner service because the working directory is set to by default , which is sized to 25% of the system memory by default . Ideally there can be an option to use storage instead of memory for the working directory. I'm opening an issue first because I am not sure if there is a way to work around this already; can the argument in the service be overridden, or is there another way to change for this service with a systemd setting? If there isn't a straightforward solution I can open a PR to add this as an option. Maintainers:
I also experienced issues with no space left on . So far, however, increasing its size did the job. Nevertheless, I'd also appreciate the option to use another filesystem for the runtime directory. We won't be able to use systemd for that as it demands a -like filesystem for the runtime directory.
I guess standard installs avoid this by using the directory. Maybe we should just document how increase size instead of adding another option?
You may pass an arbitrary path to the options of the configuration script. Our module currently always uses the runtime directory systemd assigns to the service.
Yeah, in our case using the runtime directory that provides makes the most sense for dynamic user, again, with documentation on how to increase the size of the runtime directory. Currently our module doesn't support static users so isn't very useful... though I'm guessing our lack of support for static users is an oversight - see details here:
Code change:
<ins> { lib , stdenv , fetchFromGitHub , meson , ninja , pkg-config , wrapGAppsHook , desktop-file-utils , appstream-glib , python3Packages , glib , gtk3 , libhandy , gobject-introspection , gst_all_1 }: python3Packages.buildPythonApplication rec { pname = "blanket"; version = "0.5.0"; src = fetchFromGitHub { owner = "rafaelmardojai"; repo = "blanket"; rev = version; sha256 = "00i821zqfbigxmc709322r16z75qsw4rg23yhv35gza9sl65bzkg"; }; nativeBuildInputs = [ meson ninja pkg-config wrapGAppsHook desktop-file-utils appstream-glib ]; buildInputs = [ glib gtk3 libhandy gobject-introspection gst_all_1.gstreamer gst_all_1.gst-plugins-base gst_all_1.gst-plugins-good gst_all_1.gst-plugins-bad ]; propagatedBuildInputs = with python3Packages; [ pygobject3 ]; # Broken with gobject-introspection setup hook # https://github.com/NixOS/nixpkgs/issues/56943 strictDeps = false; format = "other"; postPatch = '' patchShebangs build-aux/meson/postinstall.py ''; meta = with lib; { homepage = "https://github.com/rafaelmardojai/blanket"; description = "Listen to different sounds"; maintainers = with maintainers; [ onny ]; license = licenses.gpl3Plus; platforms = platforms.linux; }; } </ins>

Related discussion:
text: Project description ! Metadata homepage URL: source URL: license: gpl3 platforms: linux
FTR: This requires an update of .
I marked this as stale due to inactivity. &rarr;
Code change:
<del> diff --git a/Makefile b/Makefile index d6b9dc1..ce7c493 100644 --- a/Makefile +++ b/Makefile @@ -601,7 +601,7 @@ install-localstatedir: endif -install: all $(if $(BUILD_DOCS),install-doc) install-datadir install-localstatedir +install: all $(if $(BUILD_DOCS),install-doc) install-datadir ifneq ($(TOOLS),) $(call install-prog,$(subst qemu-ga,qemu-ga$(EXESUF),$(TOOLS)),$(DESTDIR)$(bindir)) endif </del>

Related discussion:
text: Steps to reproduce the behavior: afl <!-- 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]:
If you are planing to open a PR, you don't need to create an issue first.
I wasn't sure, thanks for clarification
Code change:
linux_5_15_hardened = recurseIntoAttrs (packagesFor kernels.linux_5_15_hardened); linux_6_1_hardened = recurseIntoAttrs (packagesFor kernels.linux_6_1_hardened); linux_6_5_hardened = recurseIntoAttrs (packagesFor kernels.linux_6_5_hardened); <ins> linux_6_6_hardened = recurseIntoAttrs (packagesFor kernels.linux_6_6_hardened); </ins> linux_zen = recurseIntoAttrs (packagesFor kernels.linux_zen); linux_lqx = recurseIntoAttrs (packagesFor kernels.linux_lqx);

Related discussion:
text: Project description Hardened patchset got released for Linux 6.6. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi, created the following merge request. Would appreciate a review.
will try to check that tomorrow's morning if my ibs allows me to, thanks
Code change:
echo "unsupported interpreter directive "$oldInterpreterLine" (set dontPatchShebangs=1 and handle shebang patching yourself)" exit 1 fi <del> newPath="$(command -v "$arg0" || true)" </del> <ins> newPath="$(PATH="${!pathName}" command -v "$arg0" || true)" </ins> else if [ "$oldPath" = "" ]; then # If no interpreter is specified linux will use /bin/sh. Set # oldpath="/bin/sh" so that we get /nix/store/.../sh. oldPath="/bin/sh" fi <del> newPath="$(command -v "$(basename "$oldPath")" || true)" </del> <ins> newPath="$(PATH="${!pathName}" command -v "$(basename "$oldPath")" || true)" </ins> args="$arg0 $args" fi

Related discussion:
text: uses to determine the substitute for the shebang path. This selects the wrong path during cross-builds and results in x8664 binaries getting pulled in as dependencies to cross-built binaries that can't possibly use them at runtime. I don't know if we can reliably pick the correct /bin/sh without it being in the PATH envvar. I presume patchShebangs works fine for binaries that don't overlap with stdenv's and are included in buildInputs. If you cross-build some packages to ARM platforms, patchShebangs runs in the fixup phase and run , you'll see it points to the native /bin/sh rather than the cross one. I was considering a PR to just add to the cross build of glibc, but figured it'd be better if the root issue were fixed instead. System: "16.03pre75806." Nix version: nix-env (Nix) 1.12pre1234abcdef Nixpkgs version: (Gorilla)
/participate. (I've stumbled across this too.)
Is it safe to assume are the only paths that will ever realistically have this problem? If so, how and where would we pull in as a buildInput without it clobbering the native /bin/sh used by stdenv to run the builder? Once we're already executing , it's too late to find any s. This problem overlaps with another, , which is that crossDrvs clobber stdenv's binaries in the PATH. The best solution I can come up with is to manually include in of e.g. glibc, add logic in to not add to the PATH when crossbuilding, based on some new derivation attr like , then search during , independently of what's set in the PATH. Or we could just make smarter about importing /bin/ PATHs that contain elements of the stdenv, namely: .
is essential to fix this without greatly complicating bootstrapping.
don't forget to close. :)
Addressed in
Code change:
<del> { lib, python3, fetchFromGitHub, git, pkg-config }: </del> <ins> { lib, stdenv, python3, fetchFromGitHub, git, pkg-config, fetchpatch }: </ins> # Note: # Conan has specific dependency demands; check

Related discussion:
text: Description Attempting to install conan with nix-env on Mac OS X errors out with the following message: To Reproduce Steps to reproduce the behavior: Expected behavior As Mac OS X is a supported platform for conan, it's expected that it would install. Additional context This appears to be due to conan's dependency on the python3-distro package, which only compiles on Linux architectures. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(tclemons): channels(root): nixpkgs:
Code change:
default = null; defaultText = literalExpression "username"; }; <ins> workDir = mkOption { type = with types; nullOr str; description = lib.mdDoc '' Working directory, available as `$GITHUB_WORKSPACE` during workflow runs and used as a default for [repository checkouts](https://github.com/actions/checkout). The service cleans this directory on every service start. A value of `null` will default to the systemd `RuntimeDirectory`. ''; default = null; }; </ins> }

Related discussion:
text: Working with large repositories on low-memory systems (such as aarch64-linux SBCs) can lead to out-of-storage scenarios with the github-runner service because the working directory is set to by default , which is sized to 25% of the system memory by default . Ideally there can be an option to use storage instead of memory for the working directory. I'm opening an issue first because I am not sure if there is a way to work around this already; can the argument in the service be overridden, or is there another way to change for this service with a systemd setting? If there isn't a straightforward solution I can open a PR to add this as an option. Maintainers:
I also experienced issues with no space left on . So far, however, increasing its size did the job. Nevertheless, I'd also appreciate the option to use another filesystem for the runtime directory. We won't be able to use systemd for that as it demands a -like filesystem for the runtime directory.
I guess standard installs avoid this by using the directory. Maybe we should just document how increase size instead of adding another option?
You may pass an arbitrary path to the options of the configuration script. Our module currently always uses the runtime directory systemd assigns to the service.
Yeah, in our case using the runtime directory that provides makes the most sense for dynamic user, again, with documentation on how to increase the size of the runtime directory. Currently our module doesn't support static users so isn't very useful... though I'm guessing our lack of support for static users is an oversight - see details here:
Code change:
inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; <del> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </del> <ins> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; julia_1 = julia_10; <del> julia = julia_1; </del> <ins> julia = julia_15; </ins> jwasm =  callPackage ../development/compilers/jwasm { };

Related discussion:
text: Julia 1.5 is out, see: and we don't have it packaged. More over, see how defines our other Julias: Several issues: is pointing to a TLS version which is old IMO. Certainly there are breaking changes seen in , but since Nixpkgs is a somewhat rolling release distro, are we going to keep these older versions and default to them for ever? I've once tried to reach for the community to hear if there's a strict policy regarding such scenarios, but Anyway, I'd like to propose a change that will keep only the LTS version and the latest - currently 1.4, and perhaps make the attribute , point to the latest. Any thoughts from maintainers or users? cc
Also, now I noticed all of our Julias fail to build, e.g:
I agree. And the 1.5 release candidates are out, so this will become the latest version in the near future. Last time I looked, the package built the same deps for all versions, including 0.7. In versions 1.0 and later, there are actually fewer dependencies (e.g. arpack and fftw have been dropped), so the package should be cleaned up to not include these unnecessary libraries in the build. I also think the default version should be the latest version (i.e., unless somebody explicitly installs julia-1-lts, they should get the latest).
OK I'm glad I have your support. I'll let this issue stay open for a while and hopefully I'll be able to take care of this a month or so from now.
cc
Back when Julia tests were not so messed up, I think there was often 1 previous version. I guess with 1.3 needing overriding to no tests, it is fine to just have julia-1-lts and Julia 1.4 as julia once Julia 1.4 gets built fine with some tests.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Haven't had a lot of time to work on julia in nixpkgs, so just posting this as a FYI.
Code change:
inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; <del> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </del> <ins> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; julia_1 = julia_10; <del> julia = julia_1; </del> <ins> julia = julia_15; </ins> jwasm =  callPackage ../development/compilers/jwasm { };

Related discussion:
text: We used multiple versions of julia at work, but we use a custom derivation, similar to this: We also do not run the tests, but in general it has been working great. Previously we also used the binary builds patched with patchelf, as there were some differences in the structure of the results of the vanilla binary build provided by julia and what we got when building from source. We gave up on using 'system' libraries, and build the releases that julia provides, as julia is very specific in the versions for its dependencies (LLVM patches mostly).
I tried to use that tarball in order to write a derivation from scratch. Here's my attempt: It fails with: Naturally I didn't further attempt to add curl or wget to the inputs, as that would fail in a sandbox as well. I've opened an issue upstream: complaining that that tarball doesn't really contain all dependencies.
I ran with sandbox enabled, and the expression I linked with works for me. So I think it is fine to just add curl to the deps, as with the full tarball, it isn't actually used.
There is another approach to avoid running tests: using precompiled binary. I tried downloading the 1.4.2 binary from and then afterward ran on the binary, then I got a running Julia interpreter just like that.
We did the same for a while using code similar to this: Unfortunately, we actually sometimes need to patch Julia, so we switched to the julia expressions from source, that I posted earlier.
Thanks that expression works well thanks to . I'm testing it now.
OK so after a long build, I got a working Julia derivation with these references: And this closure size: Which I must say it is satisfying. The question is, is this how we'd want it to be built? Using all of their dependencies and practically non of ours? Some of their dependencies are required to be patched, according to and they also specify that using the OS' libraries is not officially supported? Anyway I'd happy to get help on deciding this.
does this lead to Julia tests passing? I think for every dependency they patch, it is OK to just use their patched version. I guess it could be nice to use a separate build unpatched (but using the exact same version sounds like a likely restriction), but whatever dependency does not work right away can be switched to bundled.
Code change:
inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; <del> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </del> <ins> julia_15 = callPackage ../development/compilers/julia/1.5.nix { </ins> inherit (darwin.apple_sdk.frameworks) CoreServices ApplicationServices; }; julia_1 = julia_10; <del> julia = julia_1; </del> <ins> julia = julia_15; </ins> jwasm =  callPackage ../development/compilers/jwasm { };

Related discussion:
text: I think it did, I've set and the build passed but I haven't inspected the log much, but here it is: Currently produces this log but there's no PR yet as I think there are many makeFlags that should probably be set as well. If anyone feels confident to open a PR with this feel free to ping me for a review. I agree with the idea, but what's bothering me is that it's not absolutely clear what versions are patched and which are not - the docs vs what's actually found in is not totally inline. Also, it seems that some of the patches are old, and were suggested upstream (to the libraries) but they weren't merged there for some reason. I'm still investigating, See My current target is to decide what libraries to use our version vs their version, with the preference to use our version, in order to hopefully reduce closure size due to sharing shared libraries. The idea is to decide this by checking whether the libraries have included the patch Julia suggests, and then whether the library's maintainer has released a new version that includes Julia's maintainers' patch, and whether we ship that new version.
does this lead to Julia tests passing? I think this log is cut short before the interesting part…
I've uploaded it here:
Hmmm. Reading the log does not convince me the tests were run… Pity.
Since 1.5 was just released, the title should probably be updated to be 1.5.
Downside with the patching approach, is users lose the ability to compile against MKL, which has HUGE performance increase (last I saw showed that MKL was ~4x faster at matrix multiplication!!). Would need to also package JuliaPro to get MKL. Of course, anything working nothing working, although would be a shame to lose compilation options.
Says
Thanks garrison, I saw that, but I have a feeling it won't play nicely with Nix...although if we go patching route, perhaps could do that during buildPhase
Are you concerned about specifically or all packages that use BinaryBuilder? There are a lot of them. More on this at
As I understand binary builder, that all happens in userspace, but modifies , which is in /nix/store
The installation instructions for do not seem to require root. My guess is that it stores the modified sysimage somewhere in .