jiebi/CodeConvo huggingface dataset:
Change:
listenString = { addr, port, ssl, extraParameters ? [], ... }: "listen ${addr}:${toString port} " + optionalString ssl "ssl " <del> + optionalString vhost.http2 "http2 " </del> <ins> + optionalString (ssl && vhost.http2) "http2 " </ins> + optionalString vhost.default "default_server " + optionalString (extraParameters != []) (concatStringsSep " " extraParameters) + ";";

Discussion:
broke all of my nginx vhosts that serve content on port 80 and do not automatically redirect the client to port 443. This includes all of my sites that use auto-ACME renewal from Let's Encrypt. Listen directives that used to look like this: now look like this: Clients such as and the Let's Encrypt certbot don't seem to support/expect http2 on port 80. To confirm that this is the issue, I've disabled the nginx NixOS module from nixpkgs master and replaced it with a version identical to the NixOS module prior to , and port 80 vhosts work again. [edit for clarity]
Looks like this is as simple as changing http2 to default to false in or setting it yourself in your vhost block. Is there a way we can make this default to true if we're using SSL and default to false if we're not but not override it like the previous functionality?
I feel like the simplest way to support this would be to have a separate setting to specifically indicate whether you want http2 where . I'm not aware of any major browser that supports HTTP/2 without encryption, so for most users a listen directive without ssl but with http2 is highly undesirable. Given that consideration, having to put an extra option in each vhost when http2 is wanted without encryption does not seem unreasonable. I would do something like
Change:
sed -e '/^FILE:@bazel_gazelle_go_repository_tools.*/d' -i $bazelOut/external/@*.marker ''; <del> sha256 = "1ck1rsg5msd77abs889nl2n2i3jlah4d4vjz5wbsb3jyhzn8n5ny"; </del> <ins> sha256 = "01d4m4kb2mhz8fxl9apzsdq0pd7i79w3q49x51rwa524caml9zfv"; </ins> }; buildAttrs = { <ins> inherit patches; </ins> preBuild = '' patchShebangs . <del> # tell rules_go to use the Go binary found in the PATH sed -e 's:go_register_toolchains():go_register_toolchains(go_version = "host"):g' -i WORKSPACE </del> ''; installPhase = ''

Discussion:
I can't build bazel-watcher on the latest master <details<summaryShell session</summary</detailsPlease run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): channels(kalbasit): channels(yl): nixpkgs: cc
Change:
wantedBy = [] ++ optional (container.autoStart) "multi-user.target"; after = [ "docker.service" "docker.socket" ] ++ mkAfter; requires = after; <ins> path = [ pkgs.docker ]; preStart = '' docker rm -f ${name} || true ${optionalString (container.imageFile != null) '' docker load -i ${container.imageFile} ''} ''; postStop = "docker rm -f ${name} || true"; </ins> serviceConfig = { ExecStart = concatStringsSep " n  " ([ "${pkgs.docker}/bin/docker run"

Discussion:
Describe the bug The docker-containers systemd services set strings for systemd options that can accept a list, like ExecStopPost and ExecStartPre: In my case I'd like to append an unrelated poststop task (a sqlite vacuum). If the options were set to lists I could just have my command merged, but because they're strings I need to mkForce and copy in the upstream commands. To Reproduce Create a config like: This results in an error: " has conflicting definitions". Expected behavior Multiple poststop declarations in the resulting unit, like what happens with Additional context This is vaguely related to , which also has to do with making more flexible. Metadata system: host os: multi-user?: sandbox: version: channels(simon): nixpkgs: Maintainer information:
I believe 's attributes get put into the unit file verbatim. This would also be a systemd.services issue, not a Docker one. Have you tried
I'm not sure it's a systemd issue: it already seems to support using lists, but docker-containers doesn't make use of them. doesn't seem to help. It results in being set as well, so causes the same error. To clarify, I'm proposing something like this: That would let docker-containers users who want to append other tasks avoid copying in the upstream config and overriding it:
I stumbled across this issue when trying to add something to . You are right about not being useful, but you solution requires a change in the systemd definition (where I do not know whether it might break something). It also makes the section less of a direct mapping between the unit file and the option. In my opinion, the correct solution would be to move the values for to the mergable options . Note that this fix should not interact with the two other proposed changes and
Unfortunately, it is not universal advice, as it won't work if there is already defined.
is defined for all containers that are created with , due to In my opinion, the value for should be moved to and to . These options allow composing. I'll prepare a pull request to fix this when I have a bit of time (I think it will be ready in ~4-5 hours).
Change:
{ fetchurl, fetchpatch, lib, stdenv, zlib, openssl, libuuid, pkg-config, bzip2 }: stdenv.mkDerivation rec { <del> version = "20201230"; </del> <ins> version = "20231119"; </ins> pname = "libewf"; src = fetchurl { url = "https://github.com/libyal/libewf/releases/download/${version}/libewf-experimental-${version}.tar.gz"; <del> hash = "sha256-10r4jPzsA30nHQzjdg/VkwTG1PwOskwv8Bra34ZPMgc="; </del> <ins> hash = "sha256-7AjUEaXasOzJV9ErZK2a4HMTaqhcBbLKd8M+A5SbKrc="; </ins> }; <del> patches = [ # fix build with OpenSSL 3.0 (fetchpatch { url = "https://github.com/libyal/libewf/commit/033ea5b4e5f8f1248f74a2ec61fc1be183c6c46b.patch"; hash = "sha256-R4+NO/91kiZP48SJyVF9oYjKCg1h/9Kh8/0VOEmJXPQ="; }) ]; </del> nativeBuildInputs = [ pkg-config ]; buildInputs = [ zlib openssl libuuid ] ++ lib.optionals stdenv.isDarwin [ bzip2 ];

Discussion:
Package name: libewf Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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:
dontGzipMan = true; # already compressed passthru = { <del> pythonSourceRoot = "${src.name}/bindings/python"; </del> <ins> pythonSourceRoot = "notmuch-${version}/bindings/python"; </ins> inherit version; };

Discussion:
Steps to reproduce the behavior: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc maybe system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Change:
}: python3.pkgs.buildPythonApplication rec { pname = "salt"; <del> version = "3003.3"; </del> <ins> version = "3003.4"; </ins> src = python3.pkgs.fetchPypi { inherit pname version; <del> sha256 = "pvnIyLXiYA6oYgtKZzcd4XYRvrT42X5LubCzCKN+0eI="; </del> <ins> sha256 = "53uAjlG0HX5Jae4VWIrAT9DbmzPfonEPVEGNfrOHJM0="; </ins> }; propagatedBuildInputs = with python3.pkgs; [

Discussion:
are you on top of this?
Thanks for the heads up, yeah, just waited for the GitHub releases to appear. I’ll create a PR soon.
Change:
version = "26.3"; sha256 = "119ldpk7sgn9jlpyngv5y4z3i7bb8q3xp4p0qqi7i5nq39syd42d"; patches = [ <del> ./clean-env-26.patch </del> ./tramp-detect-wrapped-gvfsd-26.patch ]; })

Discussion:
Describe the bug In NixOS 20.09, Emacs now has the output of gtk+ in its closure, which in turn causes it to pull in stuff like mesa-drivers (424 MiB): This caused the closure size of Emacs to increase from 339 MiB in NixOS 20.03 to 1324 MiB in 20.09. Metadata NixOS 20.09..
cc
This was reverted in
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
, zlib , microsoft-gsl , iconv <del> , gtest </del> , protobuf_21 , pythonSupport ? true }:

Discussion:
Meaningful errors Full logs: system: host os: multi-user?: sandbox: version: channels(root): channels(jarrod): nixpkgs: Source file with issue:  I tried to locate where is defined, but was unable to.
Edited the issue and I'm not sure if GitHub retroactively sends notifications, so pardon the double-mention:
Will be fixed by .
Change:
libfm-qt = libfm-qt_1_4; inherit (pkgs.libsForQt5) qtbase qtsvg qttools libdbusmenu; }; <ins> qtermwidget_1_4 = callPackage ./qtermwidget { version = "1.4.0"; lxqt-build-tools = lxqt-build-tools_0_13; inherit (pkgs.libsForQt5) qtbase qttools; }; </ins> preRequisitePackages = [ kdePackages.kwindowsystem # provides some QT plugins needed by lxqt-panel

Discussion:
Steps to reproduce the behavior: virt-manager-qt on 24.05 (or, I assume, unstable) Full log: Bisecting the build yields from as the first bad commit. It updates from to . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Relevant upstream commit:
Change:
rootpw = "notapassword"; declarativeContents."dc=example" = dbContents; }; <ins> users.ldap = ldapClientConfig; </ins> }; }) { inherit system pkgs; };

Discussion:
The system-wide LDAP client configuration in is ignored by Openldap client programs. Steps to reproduce the behavior: settings into via or any other Openldap client Openldap client programs should obey the system-wide configuration file in . strace shows it's reading the example configuration from the package instead: Since commit the openldap package no longer passes to configure, it only passes to make instead. Please run and paste the result.
It seems a bit dodgy, but this might be a solution: plus corresponding changes to all the packages and tests that refer to . I'm just rebuilding a gazillion packages on my system from source, so I can check if that works properly...
you probably meant to ping and instead
Oops, sorry about that. I forgot that the maintainer handles listed in the package do not necessarily correspond to their Github usernames.
I realised that changing is probably unwise. Not only does it break some other packages (like python-ldap) and some Nixos tests, it will also break any users who have configured slapd to refer to the schemas under , as I myself have: And changing is not necessary to fix the bug anyway. It seems that the approach of passing differently in compile and install works. I'll send a PR for it.
Change:
stdenv.mkDerivation rec { pname = "elinks"; <del> version = "0.15.1"; </del> <ins> version = "0.16.0"; </ins> src = fetchFromGitHub { owner = "rkd77"; repo = "felinks"; rev = "v${version}"; <del> sha256 = "sha256-9OEi4UF/4/IRtccJou3QuevQzWjA6PuU5IVlT7qqGZ0="; </del> <ins> sha256 = "sha256-4+V1j78sjs3/6SnVLO34jCcNuegpZan8Ykd8Gy0vc3k="; </ins> }; buildInputs = [

Discussion:
<!-- 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: elinks <!-- 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: 0.15.1 desired version: 0.16.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers:
Thank you for bringing this to my attention :-) I just submitted a corresponding pull request, .
Change:
install -m 444 -D nselib/data/passwords.lst $out/share/wordlists/nmap.lst ''; <ins> postFixup = lib.optionalString stdenv.isDarwin '' install_name_tool -change liblinear.so.5 ${liblinear.out}/lib/liblinear.5.dylib $out/bin/nmap ''; </ins> makeFlags = lib.optionals (stdenv.buildPlatform != stdenv.hostPlatform) [ "AR=${stdenv.cc.bintools.targetPrefix}ar" "RANLIB=${stdenv.cc.bintools.targetPrefix}ranlib"

Discussion:
Trying to run doesn't work at all and fails with: displays: A temporary workaround is to install liblinear from homebrew and rename it to . nixpkgs (unstable) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This is probably related to but liblinear is found correctly on Linux:
Another workaround:
Change:
# similar to interpreters/python/default.nix <del> { stdenv, lib, callPackage, fetchurl }: </del> <ins> { stdenv, lib, callPackage, fetchurl, fetchpatch }: </ins> let dsoPatch51 = fetchurl { url = "https://projects.archlinux.org/svntogit/packages.git/plain/trunk/lua-arch.patch?h=packages/lua51";

Discussion:
, (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives.
Still no new release from upstream. Looks like the discussion sort of fizzled out: Ubuntu and RHEL apply a patch for this, see for example:
Should be backported as well.
Looks like the patch was applied to unstable and backported to 19.09. Can we close this issue?
Change:
buildPythonPackage rec { pname = "loguru"; <del> # No release since Jan 2022, only master is compatible with Python 3.11 # https://github.com/Delgan/loguru/issues/740 version = "unstable-2023-01-20"; </del> <ins> version = "0.7.0"; </ins> format = "setuptools"; <del> disabled = pythonOlder "3.5"; </del> <ins> disabled = pythonOlder "3.7"; </ins> src = fetchFromGitHub { owner = "Delgan"; repo = pname; <del> rev = "07f94f3c8373733119f85aa8b9ca05ace3325a4b"; hash = "sha256-lMGyQbBX3z6186ojs/iew7JMrG91ivPA679T9r+7xYw="; </del> <ins> rev = "refs/tags/${version}"; hash = "sha256-JwhJPX58KrPdX237L43o77spycLAVFv3K9njJiRK30Y="; </ins> }; <del> propagatedBuildInputs = lib.optionals (pythonOlder "3.7") [ aiocontextvars ]; </del> nativeCheckInputs = [ pytestCheckHook colorama

Discussion:
Package name: loguru Latest released version: 0.7.0 <!-- Search your package here: --- Current version on the unstable channel: 2023-01-20 Current version on the stable/release channel: 2023-01-20 <!-- 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.
Change:
<ins> # Debugging Nix Expressions {#sec-debug} Nix is a unityped, dynamic language, this means every value can potentially appear anywhere. Since it is also non-strict, evaluation order and what ultimately is evaluated might surprise you. Therefore it is important to be able to debug nix expressions. In the `lib/debug.nix` file you will find a number of functions that help (pretty-)printing values while evaluation is running. You can even specify how deep these values should be printed recursively, and transform them on the fly. Please consult the docstrings in `lib/debug.nix` for usage information. </ins>

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.
I'm working on this one.
Change:
systemd.services.docker = { wantedBy = optional cfg.enableOnBoot "multi-user.target"; <ins> requires = [ "docker.socket" ]; </ins> environment = proxy_env; serviceConfig = { Type = "notify";

Discussion:
Describe the bug Apparently this bug was already caught in the original PR , but for some reason the fix got later reverted in The error message from systemd is: To Reproduce Expected behavior docker should start Additional context fixes it Notify maintainers Metadata Please run and paste the result.
See reason for the fix: This issue was originally caused by build misconfiguration (Moby build flags in wrong place perhaps).
Unable to reproduce this on my system with following configuration:
Just tried with an explicit , this fixes the issue. Looking at logs of : This happened the first time it tried to start docker. I think this is a race in startup, docker starts before the socket, prevents from starting, then start fails with this error. According to systemd docs: So perhaps we just need to add a line to ?
Seems like this is exactly the case.
Change:
<del> { stdenv, lib, buildPackages, buildGoPackage, fetchFromGitHub, installShellFiles }: </del> <ins> { stdenv, lib, buildPackages, buildGoModule, fetchFromGitHub, installShellFiles }: let isCrossBuild = stdenv.hostPlatform != stdenv.buildPlatform; </ins> <del> let isCrossBuild = stdenv.hostPlatform != stdenv.buildPlatform; in buildGoPackage rec { </del> <ins> in buildGoModule rec { </ins> pname = "stern"; <del> version = "1.11.0"; goPackagePath = "github.com/wercker/stern"; </del> <ins> version = "1.13.1"; </ins> src = fetchFromGitHub { <del> owner = "wercker"; </del> <ins> owner = "stern"; </ins> repo = "stern"; <del> rev = version; sha256 = "0xndlq0ks8flzx6rdd4lnkxpkbvdy9sj1jwys5yj7p989ls8by3n"; </del> <ins> rev = "v${version}"; sha256 = "0fj6a52wb0jv5bz2j2wq3ljnlxnsj9bg3kbzgkz0vh0b63zyn782"; </ins> }; <del> deleteVendor = true; goDeps = ./deps.nix; </del> <ins> vendorSha256 = "14nrdaaby74bjbk777hr82p0ybzk3spc59lbrjn9z0q3hc0p4vaf"; </ins> nativeBuildInputs = [ installShellFiles ]; <ins> buildFlagsArray = [ "-ldflags=-s -w -X github.com/stern/stern/cmd.version=${version}" ]; </ins> postInstall = <del> let stern = if isCrossBuild then buildPackages.stern else "$out"; in </del> <ins> let stern = if isCrossBuild then buildPackages.stern else "$out"; in </ins> '' for shell in bash zsh; do ${stern}/bin/stern --completion $shell > stern.$shell

Discussion:
We should replace the discontinued source with the more active fork . wrecker/stern hasn't received any commits since 2019. The maintainer of stern doesn't work at wercker anymore, and it seems no one else there is maintaining it (wercker/stern). The community has since moved to stern/stern with improvements to the original source. Project description Multi pod and container log tailing for Kubernetes Metadata homepage URL: source URL: license: Apache-2.0 platforms: unix
Change:
<ins> diff --git a/CMakeLists.txt b/CMakeLists.txt index c9f73ce96..d14ffeed9 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -339,13 +339,13 @@ macro(run_vk_xml_generate dependency output) endmacro() # Define macro used for generating header files containing commit IDs for external dependencies -macro(run_external_revision_generate source_dir symbol_name output) +macro(run_external_revision_generate rev_file symbol_name output) add_custom_command(OUTPUT ${output} # NOTE: If you modify this call to use --rev_file instead of --git_dir (to read the commit ID from a file instead of # parsing from a Git repository), you probably also want to add the revision file to the list of DEPENDS on the # subsequent line (to ensure that the script is re-run when the revision file is modified). -    COMMAND ${PYTHON_CMD} ${SCRIPTS_DIR}/external_revision_generator.py --git_dir ${source_dir} -s ${symbol_name} -o ${output} -    DEPENDS ${SCRIPTS_DIR}/external_revision_generator.py ${source_dir}/.git/HEAD ${source_dir}/.git/index +    COMMAND ${PYTHON_CMD} ${SCRIPTS_DIR}/external_revision_generator.py --rev_file ${rev_file} -s ${symbol_name} -o ${output} +    DEPENDS ${SCRIPTS_DIR}/external_revision_generator.py ${rev_file} ) endmacro() </ins>

Discussion:
Tried to make a system upgrade, got this: Obviously, upgrade can't be completed. have in . run Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
This looks like the offending line: This could be related to what file system you are using?
Actually this looks like unrelated to glslang. Works on master:
Change:
popd ''; <ins> # use --suffix here to ensure we don't shadow /run/wrappers/bin/fusermount, # as the setuid wrapper is required to use gocryptfs as non-root on NixOS </ins> postInstall = '' wrapProgram $out/bin/gocryptfs  <del> --prefix PATH : ${lib.makeBinPath [ fuse ]} </del> <ins> --suffix PATH : ${lib.makeBinPath [ fuse ]} </ins> ln -s $out/bin/gocryptfs $out/bin/mount.fuse.gocryptfs '';

Discussion:
gocryptfs fails to mount a volume as non-root/without sudo as a non-root user: gocryptfs should mount volumes without needing sudo, as normal user fuse as input to the package, and it to in a wrapper. I assume that in older builds is grabbed from my , which would be . The wrapper in has the setuid bit set, while the binary in the package does not; I assume this is the source of the problem. Running the wrapped binary directly () mounts the volume without problems. system: host os: multi-user?: sandbox: version: channels(root): channels(d): nixpkgs: Maintainer information:
cc
The solution is to postfix fuse instead of prefix
What do you mean by postfix fuse?
I meant use --suffix instead of --prefix here
Can you please try the proposed fix above and report back if that fixes the issue?
Thanks, yes, it solves my issue. I was also able to mount via the option with the fix applied, so I went ahead and opened a PR at
Change:
akvcam = callPackage ../os-specific/linux/akvcam { }; <del> amdgpu-pro = callPackage ../os-specific/linux/amdgpu-pro { libffi = pkgs.libffi.overrideAttrs (orig: rec { version = "3.3"; src = fetchurl { url = "https://github.com/libffi/libffi/releases/download/v${version}/${orig.pname}-${version}.tar.gz"; sha256 = "0mi0cpf8aa40ljjmzxb7im6dbj45bb0kllcd09xgmp834y9agyvj"; }; }); }; </del> <ins> amdgpu-pro = callPackage ../os-specific/linux/amdgpu-pro { }; </ins> apfs = callPackage ../os-specific/linux/apfs { };

Discussion:
Steps to reproduce the behavior: libffi-3.3 Fails as a dependency of amdgpu-pro Please run and paste the result.
Both and build fine for me. does fail.
Oh:
I would say the problem is not in , but in . Proposed the possible fix as
/cc
Change:
# when adding a new linux version kernelPatches.cpu-cgroup-v2."4.11" kernelPatches.modinst_arg_list_too_long <ins> # https://github.com/NixOS/nixpkgs/issues/42755 # Remove these xen-netfront patches once they're included in # upstream! Fixes https://github.com/NixOS/nixpkgs/issues/42755 kernelPatches.xen-netfront_fix_mismatched_rtnl_unlock kernelPatches.xen-netfront_update_features_after_registering_netdev </ins> ]; };

Discussion:
Network access works well on a new instance booted from the stable AMIs listed on the website, but after running and rebooting the instance, it is broken. More specifically, the host can no longer send packets with an MSS larger than 3836. two EC2 instances from one of the 18.03 AMIs in the same VPC one of them latest stable with and reboot the security group to allow internal VPC communication on the host without the updates and on the updated one As I was writing this, I dug a bit deeper and found out that this is a bug introduced in the 4.14.37 release of the kernel. It is fixed in master (commit and possibly .) Applying those patches to the 4.14.51 kernel in stable fixes this issue for me.
Fix is now backported to 18.03.