jiebi/CodeConvo huggingface dataset:
Code change:
vendorHash = "sha256-9nkRr5Jh1nbI+XXbPj9KB0ZbLybv5JUVovpB311fO38="; nativeBuildInputs = [ installShellFiles makeWrapper ]; <del> buildInputs = [ ttyd ffmpeg ]; </del> ldflags = [ "-s" "-w" "-X=main.Version=${version}" ]; postInstall = '' <del> wrapProgram $out/bin/vhs --prefix PATH : ${lib.makeBinPath [ ffmpeg ttyd ]} </del> <ins> wrapProgram $out/bin/vhs --prefix PATH : ${lib.makeBinPath [ chromium ffmpeg ttyd ]} </ins> $out/bin/vhs man > vhs.1 installManPage vhs.1 installShellCompletion --cmd vhs 

Related discussion:
text: A clear and concise description of what the bug is. Steps to reproduce the behavior: created with expected behavior from This might be due to vhs being outdated in nixpkgs. Please run and paste the result.
Nixpkgs has since been updated to the latest version (v0.2.0), and the error still occurs on the latest Nixpkgs commit ()
Any suggestions on a fix?
I believe the fix might be to include as a dependency and ensure that looks for the binary in the same place nix installs it (i.e. it is located in the as chromium):
The PR for this breaks vhs on darwin, since chromium isn't supported on that platform
Thanks for filing a new issue
Code change:
, fetchFromGitHub , hatchling , hatch-vcs <ins> , installShellFiles </ins> , packaging , platformdirs , pytestCheckHook

Related discussion:
text: It would be nice if the package included shell completions for bash, zsh, fish. Steps to reproduce the behavior: (In fish): pipx-specific shell completions should show. One problem specific to is that the instructions you get with do not work unless you know to install the binary first (e.g. ). I hope that mimicking would work (though I'd also like completions to be included). I might be able to try that myself at some point, but I'm not very familiar with testing that a patch to works. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
- Check for unnecessary whitespace with `git diff --check` before committing. - If you have commits `pkg-name: oh, forgot to insert whitespace`: squash commits in this case. Use `git rebase -i`. <ins> See [Squashing Commits](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_squashing) for additional information. </ins> - For consistency, there should not be a period at the end of the commit message's summary line (the first line of the commit message).

Related discussion:
text: the strict commit history guidelines require frequent use of , a command which may be unfamiliar to those that are used to projects with more lenient commit guidelines. find or write a high-quality guide to and make it available in <!-- make sure this issue is not redundant or obsolete --- [x] checked [latest Nixpkgs manual] ([source][nixpkgs-source]) and [latest NixOS manual] ([source][nixos-source]) [x] checked [open documentation issues] for possible duplicates [x] checked [open documentation pull requests] for possible solutions [latest Nixpkgs manual]: [latest NixOS manual]: [nixpkgs-source]: [nixos-source]: [open documentation issues]: [open documentation pull requests]: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
""" return subprocess.check_output( [CERTTOOL_COMMAND] + list(args), <del> preexec_fn=lambda: os.umask(0o077), </del> <ins> preexec_fn=run_as_taskd_group, </ins> stderr=subprocess.STDOUT, **kwargs )

Related discussion:
text: So I today I spawned a machine with and satisfyingly the directory was generated with all of the certificates etc that taskwarrior needs, including the clients' certificates. I noticed that the users' keys located at are owned by root with read only permissions for the root user alone. No matter what are and . I'd like to enable the group read those client keys, as well as the file so that I can configure a client easily. Thankfully the group can read the file, but not the client keys. The manual indeed explains that the command: Could be used to get those keys, but I'd like to use syncthing for that to automate the process even further. I got a bit lost while reading the . Specifically, I'm not sure why does always works in the following umask: I mean, ~why not~ - a solution is suggested in . A word of comment will be appreciated. cc .
Code change:
folder.enable ) cfg.settings.folders); <del> updateConfig = pkgs.writers.writeDash "merge-syncthing-config" '' </del> <ins> jq = "${pkgs.jq}/bin/jq"; updateConfig = pkgs.writers.writeBash "merge-syncthing-config" ('' </ins> set -efu # be careful not to leak secrets in the filesystem or in process listings umask 0077 # get the api key by parsing the config.xml

Related discussion:
text: I'm experiencing the issue for a long time now, and it was really hard to spot and debug this issue. I'm talking about this line: It's kind of hard to give instructions how to reproduce the issue. In my case, whenever the dash script runs, every folder I already have configured, fails to update. The whole configuration thus fails to be uploaded to the server. I can inspect the and the by editing that dash script, and I can see that I get folders twice in the json arrays. Hence I'm not surprised I see the following error in syncthing's web interface: ! I expect the merge script to not a JSON array with no duplicate folders IDs. Transition most of the logic from jq to bash, for easier maintenance, and use and API, and use when . I'm working on a solution at the moment but I'd like to here your comments first. cc who wrote the original dash script, other people have touched that line ever since, was the latest.
Code change:
lpath = "acme/${cert}"; apath = "/var/lib/${lpath}"; spath = "/var/lib/acme/.lego"; <del> rights = if data.allowKeysForGroup then "750" else "700"; </del> <ins> fileMode = if data.allowKeysForGroup then "640" else "600"; </ins> globalOpts = [ "-d" data.domain "--email" data.email "--path" "." "--key-type" data.keyType ] ++ optionals (cfg.acceptTerms) [ "--accept-tos" ] ++ optionals (data.dnsProvider != null && !data.dnsPropagationCheck) [ "--dns.disable-cp" ]

Related discussion:
text: Describe the bug If I change and enable when the cert/key in question already exists the group access will not be granted after rebuilding and restarting the . This is because a condition in the post start script does so only when the key is newer than the existing one. To Reproduce Steps to reproduce the behavior: without group/allowKeysForGroup and start the service to reques the certificate group and allowKeysForGroup again and restart the service, the ownership/ode will not be updated Expected behavior The group and chmod setting should be set on existing certificates as well as new ones. Metadata Please run and paste the result. Maintainer information:
Additionally, shouldn't chmod 0640 suffice on the files?
cc as potentially interested individuals
Code change:
<ins> # pkgs.snapTools {#sec-pkgs-snapTools} `pkgs.snapTools` is a set of functions for creating Snapcraft images. Snap and Snapcraft is not used to perform these operations. ## The makeSnap Function {#ssec-pkgs-snapTools-makeSnap-signature} `makeSnap` takes a single named argument, `meta`. This argument mirrors [the upstream `snap.yaml` format](https://docs.snapcraft.io/snap-format) exactly. The `base` should not be specified, as `makeSnap` will force set it. Currently, `makeSnap` does not support creating GUI stubs. ## Build a Hello World Snap {#ssec-pkgs-snapTools-build-a-snap-hello} The following expression packages GNU Hello as a Snapcraft snap. ```{#ex-snapTools-buildSnap-hello .nix} let inherit (import <nixpkgs> { }) snapTools hello; in snapTools.makeSnap { meta = { name = "hello"; summary = hello.meta.description; description = hello.meta.longDescription; architectures = [ "amd64" ]; confinement = "strict"; apps.hello.command = "${hello}/bin/hello"; }; } ``` `nix-build` this expression and install it with `snap install ./result --dangerous`. `hello` will now be the Snapcraft version of the package. ## Build a Graphical Snap {#ssec-pkgs-snapTools-build-a-snap-firefox} Graphical programs require many more integrations with the host. This example uses Firefox as an example, because it is one of the most complicated programs we could package. ```{#ex-snapTools-buildSnap-firefox .nix} let inherit (import <nixpkgs> { }) snapTools firefox; in snapTools.makeSnap { meta = { name = "nix-example-firefox"; summary = firefox.meta.description; architectures = [ "amd64" ]; apps.nix-example-firefox = { command = "${firefox}/bin/firefox"; plugs = [ "pulseaudio" "camera" "browser-support" "avahi-observe" "cups-control" "desktop" "desktop-legacy" "gsettings" "home" "network" "mount-observe" "removable-media" "x11" ]; }; confinement = "strict"; }; } ``` `nix-build` this expression and install it with `snap install ./result --dangerous`. `nix-example-firefox` will now be the Snapcraft version of the Firefox package. The specific meaning behind plugs can be looked up in the [Snapcraft interface documentation](https://docs.snapcraft.io/supported-interfaces). </ins>

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.
Code change:
<ins> # pkgs.snapTools {#sec-pkgs-snapTools} `pkgs.snapTools` is a set of functions for creating Snapcraft images. Snap and Snapcraft is not used to perform these operations. ## The makeSnap Function {#ssec-pkgs-snapTools-makeSnap-signature} `makeSnap` takes a single named argument, `meta`. This argument mirrors [the upstream `snap.yaml` format](https://docs.snapcraft.io/snap-format) exactly. The `base` should not be specified, as `makeSnap` will force set it. Currently, `makeSnap` does not support creating GUI stubs. ## Build a Hello World Snap {#ssec-pkgs-snapTools-build-a-snap-hello} The following expression packages GNU Hello as a Snapcraft snap. ```{#ex-snapTools-buildSnap-hello .nix} let inherit (import <nixpkgs> { }) snapTools hello; in snapTools.makeSnap { meta = { name = "hello"; summary = hello.meta.description; description = hello.meta.longDescription; architectures = [ "amd64" ]; confinement = "strict"; apps.hello.command = "${hello}/bin/hello"; }; } ``` `nix-build` this expression and install it with `snap install ./result --dangerous`. `hello` will now be the Snapcraft version of the package. ## Build a Graphical Snap {#ssec-pkgs-snapTools-build-a-snap-firefox} Graphical programs require many more integrations with the host. This example uses Firefox as an example, because it is one of the most complicated programs we could package. ```{#ex-snapTools-buildSnap-firefox .nix} let inherit (import <nixpkgs> { }) snapTools firefox; in snapTools.makeSnap { meta = { name = "nix-example-firefox"; summary = firefox.meta.description; architectures = [ "amd64" ]; apps.nix-example-firefox = { command = "${firefox}/bin/firefox"; plugs = [ "pulseaudio" "camera" "browser-support" "avahi-observe" "cups-control" "desktop" "desktop-legacy" "gsettings" "home" "network" "mount-observe" "removable-media" "x11" ]; }; confinement = "strict"; }; } ``` `nix-build` this expression and install it with `snap install ./result --dangerous`. `nix-example-firefox` will now be the Snapcraft version of the Firefox package. The specific meaning behind plugs can be looked up in the [Snapcraft interface documentation](https://docs.snapcraft.io/supported-interfaces). </ins>

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.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I opened a PR here: Thanks in advance for reviewing :-)
Code change:
<ins> #!/usr/bin/env nix-shell #! nix-shell -i bash -p curl # We use this script to download local copies instead of using # fetchpatch because lmhouse/MINGW-packages-dev is constantly rebased # against msys2/MINGW-packages-dev and won't have stable commit hashes. name=Added-mcf-thread-model-support-from-mcfgthread.patch source=https://raw.githubusercontent.com/lhmouse/MINGW-packages-dev/master/mingw-w64-gcc-git dest=$(dirname "$0") for majorVersion in 6 7 8 9 10; do curl "$source/9000-gcc-$majorVersion-branch-$name"  > "$dest/$majorVersion/$name" done </ins>

Related discussion:
text: Describe the bug is when building for MinGW, however an equivalent GCC 10 patch file doesn't exist. I tried looking for a GCC 10 patch on the master branch of , but the folder that contained the patches no longer exists. GCC9 is still currently the default on master, but this will break everything under MinGW the next time staging-next is merged to master. See Support for was originally in To Reproduce Steps to reproduce the behavior: Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(kira): nixpkgs: Maintainer information:
It has been moved to to upstream migration. Neither of these repos is stable; their master branches are constantly rebased on upstream and force-pushed.
Code change:
# converts { a.b.c = 5; } to { "a.b".c = 5; } for toINI gitFlattenAttrs = let recurse = path: value: <del> if isAttrs value then </del> <ins> if isAttrs value && !lib.isDerivation value then </ins> lib.mapAttrsToList (name: value: recurse ([ name ] ++ path) value) value else if length path > 1 then { ${concatStringsSep "." (lib.reverseList (tail path))}.${head path} = value;

Related discussion:
text: hangs when given a derivation because of infinite recursion either error or treat it as a string, which all other generators seem to do <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
is there a context where a derivation would even be a valid input for this function? If not perhaps a simple fix would be to test for a derivation as input and simply throw a warning instead of continuing computation.
it shouldn't be possible to use derivation as a attrset for this function, but store paths could be useful which is similar to 's behavior
So this worked without error: I was able to reproduce the issue by just passing your example input above though, and in looks like nesting the derivation deeper also still causes the error. I guess we could map over the input at the start of the function and convert any unconverted derivations to strings before moving on. That should allow us to declare store paths and avoid this issue. Side note: you shouldn't have to restart your system to recover from the error condition; worked for me
I forgot SIGKILL existed. I removed the warning in the description
I have run into a very strange issue. I thought that the following patch should be all that is required to fix this: however even though I confirmed in repl that the conditional evaluates to false when passed `"${hello}", the codepath guarded by the conditional still seems to run anyway and fails with the following error: to add to the confusion, if I push the value one level deeper then it works fine:
i don't think ini support values at top level, or maybe its just the ini generator?
ah okay, then I guess my change is completely ineffective. I'll keep iterating :laughing:
Code change:
mnc = callPackage ../tools/misc/mnc { }; <ins> mgmt = callPackage ../applications/system/mgmt {}; </ins> mprocs = callPackage ../tools/misc/mprocs { }; nominatim = callPackage ../servers/nominatim { };

Related discussion:
text: Project description mgmt: next generation config management! Metadata homepage URL: source URL: license: GNU3 platforms: unix, linux, darwin
After fixing up the mgmt make scripts , from !/bin/bash to !/usr/bin/env bash trying to build from 'nix-shell -p go git' git clone cd mgmt make path make deps make Building: mgmt, os/arch: linux-amd64, version: 0.0.21-90-g5c6a66e-dirty. go build runtime/cgo: copying /run/user/1000/go-build892927552/b057/pkg.a: open /nix/store/y2nrzzz2yz7k36xvwr7bbfx76cb8jg16-go-1.14.8/share/go/pkg/linuxamd64/runtime/cgo.a: read-only file system make: * [Makefile:175: build/mgmt-linux-amd64] Error 1 go env GO111MODULE="" GOARCH="amd64" GOBIN="/home/demo/gopath/bin/" GOCACHE="" GOENV="" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/demo/gopath/" GOPRIVATE="" GOPROXY=",direct" GOROOT="/nix/store/y2nrzzz2yz7k36xvwr7bbfx76cb8jg16-go-1.14.8/share/go" GOSUMDB="" GOTMPDIR="" GOTOOLDIR="/nix/store/y2nrzzz2yz7k36xvwr7bbfx76cb8jg16-go-1.14.
Code change:
mnc = callPackage ../tools/misc/mnc { }; <ins> mgmt = callPackage ../applications/system/mgmt {}; </ins> mprocs = callPackage ../tools/misc/mprocs { }; nominatim = callPackage ../servers/nominatim { };

Related discussion:
text: 8/share/go/pkg/tool/linuxamd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGOENABLED="1" GOMOD="" CGOCFLAGS="-g -O2" CGOCPPFLAGS="" CGOCXXFLAGS="-g -O2" CGOFFLAGS="-g -O2" CGOLDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/run/user/1000/go-build275716735=/tmp/go-build -gno-record-gcc-switches"
mgmt now compiles under a I'm going to need a little bit of help to turn this into a nix package, as i'm not too sure how to handle it , as there are buildgopackage, buildgomodule , vgo2nix etc etc . Any pointers welcomed. to avoid I had to remove the -i from the go build this seems to be related to this NixOS/nixpkgs golang/go to run
I marked this as stale due to inactivity. &rarr;
Code change:
"-X helm.sh/helm/v3/internal/version.gitCommit=${src.rev}" ]; <ins> preBuild = '' # set k8s version to client-go version, to match upstream K8S_MODULES_VER="$(go list -f '{{.Version}}' -m k8s.io/client-go)" K8S_MODULES_MAJOR_VER="$(($(cut -d. -f1 <<<"$K8S_MODULES_VER") + 1))" K8S_MODULES_MINOR_VER="$(cut -d. -f2 <<<"$K8S_MODULES_VER")" old_ldflags="''${ldflags}" ldflags="''${ldflags} -X helm.sh/helm/v3/pkg/lint/rules.k8sVersionMajor=''${K8S_MODULES_MAJOR_VER}" ldflags="''${ldflags} -X helm.sh/helm/v3/pkg/lint/rules.k8sVersionMinor=''${K8S_MODULES_MINOR_VER}" ldflags="''${ldflags} -X helm.sh/helm/v3/pkg/chartutil.k8sVersionMajor=''${K8S_MODULES_MAJOR_VER}" ldflags="''${ldflags} -X helm.sh/helm/v3/pkg/chartutil.k8sVersionMinor=''${K8S_MODULES_MINOR_VER}" ''; </ins> __darwinAllowLocalNetworking = true; preCheck = '' <ins> # restore ldflags for tests ldflags="''${old_ldflags}" </ins> # skipping version tests because they require dot git directory substituteInPlace cmd/helm/version_test.go  --replace "TestVersion" "SkipVersion"

Related discussion:
text: Helm defaults to a kubeVersion 1.20.0, which is 3 years old. Steps to reproduce the behavior: Would expect that helm defaults to a kubeVersion that is apart of the supported Kubernetes compatibility. helm 3.12 should support something similar to kubeVersion 1.25 accorsing to their version skew, The last version of helm to officially support 1.20 was 5 minor version ago Unclear where this default version is being defined. Downloading the corresponding binary directly from (example: ) does not encounter this issue <!-- 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]:
Great timing! I just ran into this issue not to long ago but I'm unsure how to resolve it. (On mobile so I'm going from memory) there is a hard coded version in the helm or something like that, that can be overridden at build time. Presumably the helm team does override it. We can of course override it as well but I'm unsure how we can keep it up to date. It would be a 1 line patch to fix it for now but my question is, is there an automated way to keep it at the same version as whatever the helm team uses
normally helm takes the k8s version from the go k8s client lib and increments the first part by 1 to arrive at the k8s version. On my current dev system the output is as following (debian sid) In go you can directly set via as the Makefile does, but it's not always clear that those things can just be overridden that easily. i'd prepare a patch but i've no idea on how to add some script execution into to fetch the variables :/
I am not sure how to add in script execution either. As a low tech eventual solution, opened a pull request to resolve the issue upstream.
Code change:
<ins> import ./make-test-python.nix ( { pkgs, ... }: { name = "turn-rs"; nodes = { server = { virtualisation.vlans = [ 1 ]; networking = { useNetworkd = true; useDHCP = false; firewall.enable = false; }; systemd.network.networks."01-eth1" = { name = "eth1"; networkConfig.Address = "10.0.0.1/24"; }; services.turn-rs = { enable = true; secretFile = pkgs.writeText "secret" '' USER_1_CREDS="foobar" ''; settings = { turn = { realm = "localhost"; interfaces = [ { transport = "udp"; bind = "127.0.0.1:3478"; external = "127.0.0.1:3478"; } { transport = "tcp"; bind = "127.0.0.1:3478"; external = "127.0.0.1:3478"; } ]; }; auth.static_credentials.user1 = "$USER_1_CREDS"; }; }; }; }; testScript = # python '' import json start_all() server.wait_for_unit('turn-rs.service') server.wait_for_open_port(3000, "127.0.0.1") info = server.succeed('curl http://localhost:3000/info') jsonInfo = json.loads(info) assert len(jsonInfo['interfaces']) == 2, f'Interfaces doesn't contain two entries:n{json.dumps(jsonInfo, indent=2)}' config = server.succeed('cat /run/turn-rs/config.toml') assert 'foobar' in config, f'Secrets are not properly injected:n{config}' ''; } ) </ins>

Related discussion:
text: Project description A pure rust implemented turn server. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: gpl-3.0 platforms: linux, windows Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: