jiebi/CodeConvo huggingface dataset:
Code change:
fails to build on aarch64-darwin due to failing tests due to a sandbox issue. See also: Tests should pass, allowing the package build to succeed. none listed for pytest-django specifically, for django in general Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
In a case like this, would disabling these tests be appropriate? They seem to only need access to -- is that permissible in a sandboxed build?
Future self: this was fixed by adding , which seems to currently have zero mentions in the nixpkgs manual (or the nixos manual) or Defined in nix: It adds to the sandbox-exec call.

Related discussion:
text: "test_settings_restored" ]; <ins> __darwinAllowLocalNetworking = true; </ins> meta = with lib; { description = "py.test plugin for testing of Django applications"; homepage = "https://pytest-django.readthedocs.org/en/latest/";
Code change:
Project description Metadata homepage URL: source URL: license: bsd3 platforms: unix, linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Related discussion:
text: <ins> { lib , buildGoModule , fetchFromGitHub }: buildGoModule rec { pname = "golink"; version = "0-unstable-2024-01-26"; src = fetchFromGitHub { owner = "tailscale"; repo = "golink"; # https://github.com/tailscale/golink/issues/104 rev = "d9de913fb174ec2569a15b6e2dbe5cb6e4a0a853"; hash = "sha256-w6jRbajEQkOrBqxDnQreSmSB5DNL9flWjloShiIBM+M="; }; vendorHash = "sha256-R/o3csZC/M9nm0k5STL7AhbG5J4LtdxqKaVjM/9ggW8="; ldflags = [ "-s" "-w" ]; meta = with lib; { description = "A private shortlink service for tailnets"; homepage = "https://github.com/tailscale/golink"; license = licenses.bsd3; maintainers = with maintainers; [ fab ]; mainProgram = "golink"; }; } </ins>
Code change:
Steps to reproduce the behavior: the following : the flake: cc Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Oddly enough, (the original PR ) actually fails as well. Result of run on x86_64-linux <details<summary1 package failed to build:</summary<ul<licemu</li</ul</details

Related discussion:
text: { lib, stdenv, fetchFromGitHub <ins> , fetchpatch </ins> , addOpenGLRunpath , wrapGAppsHook , cmake
Code change:
Steps to reproduce the behavior: the following : the flake: cc Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Oddly enough, (the original PR ) actually fails as well. Result of run on x86_64-linux <details<summary1 package failed to build:</summary<ul<licemu</li</ul</details

Related discussion:
text: # > The following imported targets are referenced, but are missing: # > SPIRV-Tools-opt ./cmakelists.patch <ins> # Remove on next release # https://github.com/cemu-project/Cemu/pull/1076 (fetchpatch { url = "https://github.com/cemu-project/Cemu/commit/72aacbdcecc064ea7c3b158c433e4803496ac296.patch"; hash = "sha256-x+ZVqXgGRSv0VYwJAX35C1p7PnmCHS7iEO+4k8j0/ug="; }) </ins> ]; nativeBuildInputs = [
Code change:
Unable to launch gplates on NixOS. A shared object file appears to be missing. Steps to reproduce the behavior: : gplates is expected to launch and be usable. N/A N/A No listed maintainers on Nix Packages but was the last to touch the source for this application. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Probably adding to and/or adding to might help, but I'm too tired to debug tonight. I'll look into it in the next few days.
Thank you, I was reading about the first option you suggested being a potential fix. I'll see if I can wrap my head around doing it on my own as well this week, though I don't have a lot of experience contributing to projects likes this.

Related discussion:
text: , gmp , libGL , libGLU <ins> , libSM </ins> , mpfr , proj , python3
Code change:
Unable to launch gplates on NixOS. A shared object file appears to be missing. Steps to reproduce the behavior: : gplates is expected to launch and be usable. N/A N/A No listed maintainers on Nix Packages but was the last to touch the source for this application. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Probably adding to and/or adding to might help, but I'm too tired to debug tonight. I'll look into it in the next few days.
Thank you, I was reading about the first option you suggested being a potential fix. I'll see if I can wrap my head around doing it on my own as well this week, though I don't have a lot of experience contributing to projects likes this.

Related discussion:
text: gmp libGL libGLU <ins> libSM </ins> mpfr proj python
Code change:
Hardening gives old Clang flags that it cannot handle and fails. A same problem, I imagine, would arise with old GCC versions. A possible solution is to list somewhere what hardening methods are supported and use the list when deciding what hardening to apply. For example: a file : an error. Nixpkgs version: (run ) Sandboxing enabled: (run ) yes

Related discussion:
text: clang_38 = llvmPackages_38.clang; clang_37 = llvmPackages_37.clang; clang_35 = wrapCC llvmPackages_35.clang; <del> clang_34 = wrapCC llvmPackages_34.clang; </del> <ins> clang_34 = (wrapCC llvmPackages_34.clang).override { # Default cc-wrapper's hardening flags don't work with clang-3.4, # so just remove it entirely for this wrapper. extraBuildCommands = '' :> $out/nix-support/add-hardening.sh ''; }; </ins> clang-tools = callPackage ../development/tools/clang-tools { };
Code change:
In the NixOS gitlab module, the fleet of Gitlab component services is strongly coupled to the (local) postgresql and – via sidekiq – to Redis. On a systemd unit dependency level, this happens via a relationship and causes the other services to be stopped and (re)started when just one of them is instructed to do so. Unfortunately, there can be several edge cases where the system ends up with not all of the components being in the desired state (mostly up). Steps to reproduce the behavior: This issue is a subtle race condition, so I choose to describe the general problematic setup instead of trying to engineer a reproducer: I've encountered a situation where both and where restarted (stop and start) at system switch time due to changed configuration. This triggered Gitlab to be stopped as well. Unfortunately the service(s) was in its startup (Activating) phase and stayed inactive. The expectation is that Gitlab comes back after the dependency restart. Instead of continuing to tune the strongly-tied, evermore complex inter-service dependencies I propose to decouple postgresql and redis from the rest of the gitlab services. I'll open a WIP pr on this. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Here's my proposal on reducing the coupling between DBs and the rest of gitlab, currently with failing tests unfortunately:

Related discussion:
text: systemd.services.gitlab-db-config = { after = [ "gitlab-config.service" "gitlab-postgresql.service" "postgresql.service" ]; <del> bindsTo = [ "gitlab-config.service" ] ++ optional (cfg.databaseHost == "") "postgresql.service" ++ optional databaseActuallyCreateLocally "gitlab-postgresql.service"; </del> <ins> wants = optional (cfg.databaseHost == "") "postgresql.service" ++ optional databaseActuallyCreateLocally "gitlab-postgresql.service"; bindsTo = [ "gitlab-config.service" ]; </ins> wantedBy = [ "gitlab.target" ]; partOf = [ "gitlab.target" ]; serviceConfig = {
Code change:
In the NixOS gitlab module, the fleet of Gitlab component services is strongly coupled to the (local) postgresql and – via sidekiq – to Redis. On a systemd unit dependency level, this happens via a relationship and causes the other services to be stopped and (re)started when just one of them is instructed to do so. Unfortunately, there can be several edge cases where the system ends up with not all of the components being in the desired state (mostly up). Steps to reproduce the behavior: This issue is a subtle race condition, so I choose to describe the general problematic setup instead of trying to engineer a reproducer: I've encountered a situation where both and where restarted (stop and start) at system switch time due to changed configuration. This triggered Gitlab to be stopped as well. Unfortunately the service(s) was in its startup (Activating) phase and stayed inactive. The expectation is that Gitlab comes back after the dependency restart. Instead of continuing to tune the strongly-tied, evermore complex inter-service dependencies I propose to decouple postgresql and redis from the rest of the gitlab services. I'll open a WIP pr on this. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Here's my proposal on reducing the coupling between DBs and the rest of gitlab, currently with failing tests unfortunately:

Related discussion:
text: "gitlab-db-config.service" ]; bindsTo = [ <del> "redis-gitlab.service" </del> "gitlab-config.service" "gitlab-db-config.service" <del> ] ++ optional (cfg.databaseHost == "") "postgresql.service"; </del> <ins> ]; wants = [ "redis-gitlab.service" ] ++ optional (cfg.databaseHost == "") "postgresql.service"; </ins> wantedBy = [ "gitlab.target" ]; partOf = [ "gitlab.target" ]; environment = gitlabEnv // (optionalAttrs cfg.sidekiq.memoryKiller.enable {
Code change:
In the NixOS gitlab module, the fleet of Gitlab component services is strongly coupled to the (local) postgresql and – via sidekiq – to Redis. On a systemd unit dependency level, this happens via a relationship and causes the other services to be stopped and (re)started when just one of them is instructed to do so. Unfortunately, there can be several edge cases where the system ends up with not all of the components being in the desired state (mostly up). Steps to reproduce the behavior: This issue is a subtle race condition, so I choose to describe the general problematic setup instead of trying to engineer a reproducer: I've encountered a situation where both and where restarted (stop and start) at system switch time due to changed configuration. This triggered Gitlab to be stopped as well. Unfortunately the service(s) was in its startup (Activating) phase and stayed inactive. The expectation is that Gitlab comes back after the dependency restart. Instead of continuing to tune the strongly-tied, evermore complex inter-service dependencies I propose to decouple postgresql and redis from the rest of the gitlab services. I'll open a WIP pr on this. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Here's my proposal on reducing the coupling between DBs and the rest of gitlab, currently with failing tests unfortunately:

Related discussion:
text: "gitlab-db-config.service" ]; bindsTo = [ <del> "redis-gitlab.service" </del> "gitlab-config.service" "gitlab-db-config.service" <del> ] ++ optional (cfg.databaseHost == "") "postgresql.service"; </del> <ins> ]; wants = [ "redis-gitlab.service" ] ++ optional (cfg.databaseHost == "") "postgresql.service"; </ins> requiredBy = [ "gitlab.target" ]; partOf = [ "gitlab.target" ]; environment = gitlabEnv;
Code change:
In the NixOS gitlab module, the fleet of Gitlab component services is strongly coupled to the (local) postgresql and – via sidekiq – to Redis. On a systemd unit dependency level, this happens via a relationship and causes the other services to be stopped and (re)started when just one of them is instructed to do so. Unfortunately, there can be several edge cases where the system ends up with not all of the components being in the desired state (mostly up). Steps to reproduce the behavior: This issue is a subtle race condition, so I choose to describe the general problematic setup instead of trying to engineer a reproducer: I've encountered a situation where both and where restarted (stop and start) at system switch time due to changed configuration. This triggered Gitlab to be stopped as well. Unfortunately the service(s) was in its startup (Activating) phase and stayed inactive. The expectation is that Gitlab comes back after the dependency restart. Instead of continuing to tune the strongly-tied, evermore complex inter-service dependencies I propose to decouple postgresql and redis from the rest of the gitlab services. I'll open a WIP pr on this. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Here's my proposal on reducing the coupling between DBs and the rest of gitlab, currently with failing tests unfortunately:

Related discussion:
text: gitlab.systemctl("start gitlab-backup.service") gitlab.wait_for_unit("gitlab-backup.service") gitlab.wait_for_file("${nodes.gitlab.services.gitlab.statePath}/backup/dump_gitlab_backup.tar") <del> gitlab.systemctl("stop postgresql.service gitlab.target") </del> <ins> gitlab.systemctl("stop postgresql.service gitlab-config.service gitlab.target") </ins> gitlab.succeed( "find ${nodes.gitlab.services.gitlab.statePath} -mindepth 1 -maxdepth 1 -not -name backup -execdir rm -r {} +" )
Code change:
Steps to reproduce the behavior: /run/current-system/bin/switch-to-configuration test Does not crash system/systemd This can be reproduced using this test in sops-nix: Edit to have this change <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Related to
It seems like it's reusing the same loop device when mounting the new overlay...

Related discussion:
text: # this should not run because /etc is mounted via a systemd mount unit # instead. To a large extent this mimics what composefs does. Because # it's relatively simple, however, we avoid the composefs dependency. <del> if [[ ! $IN_NIXOS_SYSTEMD_STAGE1 ]]; then </del> <ins> # Since this script is not idempotent, it should not run when etc hasn't # changed. if [[ ! $IN_NIXOS_SYSTEMD_STAGE1 ]] && [[ "${config.system.build.etc}/etc" != "$(readlink -f /run/current-system/etc)" ]]; then </ins> echo "remounting /etc..." tmpMetadataMount=$(mktemp --directory)
Code change:
Steps to reproduce the behavior: /run/current-system/bin/switch-to-configuration test Does not crash system/systemd This can be reproduced using this test in sops-nix: Edit to have this change <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Related to
It seems like it's reusing the same loop device when mounting the new overlay...

Related discussion:
text: }; testScript = '' <del> machine.succeed("findmnt --kernel --type overlay /etc") machine.fail("stat /etc/newgen") </del> <ins> with subtest("/etc is mounted as an overlay"): machine.succeed("findmnt --kernel --type overlay /etc") </ins> <del> machine.succeed("/run/current-system/specialisation/new-generation/bin/switch-to-configuration switch") </del> <ins> with subtest("switching to the same generation"): machine.succeed("/run/current-system/bin/switch-to-configuration test") </ins> <del> assert machine.succeed("cat /etc/newgen") == "newgen" </del> <ins> with subtest("switching to a new generation"): machine.fail("stat /etc/newgen") machine.succeed("/run/current-system/specialisation/new-generation/bin/switch-to-configuration switch") assert machine.succeed("cat /etc/newgen") == "newgen" </ins> ''; }
Code change:
Steps to reproduce the behavior: /run/current-system/bin/switch-to-configuration test Does not crash system/systemd This can be reproduced using this test in sops-nix: Edit to have this change <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Related to
It seems like it's reusing the same loop device when mounting the new overlay...

Related discussion:
text: }; testScript = '' <del> machine.succeed("findmnt --kernel --type overlay /etc") machine.fail("stat /etc/newgen") machine.succeed("echo -n 'mutable' > /etc/mutable") </del> <ins> with subtest("/etc is mounted as an overlay"): machine.succeed("findmnt --kernel --type overlay /etc") </ins> <del> machine.succeed("/run/current-system/specialisation/new-generation/bin/switch-to-configuration switch") </del> <ins> with subtest("switching to the same generation"): machine.succeed("/run/current-system/bin/switch-to-configuration test") </ins> <del> assert machine.succeed("cat /etc/newgen") == "newgen" assert machine.succeed("cat /etc/mutable") == "mutable" </del> <ins> with subtest("switching to a new generation"): machine.fail("stat /etc/newgen") machine.succeed("echo -n 'mutable' > /etc/mutable") machine.succeed("/run/current-system/specialisation/new-generation/bin/switch-to-configuration switch") assert machine.succeed("cat /etc/newgen") == "newgen" assert machine.succeed("cat /etc/mutable") == "mutable" </ins> ''; }
Code change:
Package name: Latest released version: 2.27.0 <!-- Search your package here: --- Current version on the unstable channel: 2.21.0 Current version on the stable/release channel: 2.21.0 <!-- 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]:

Related discussion:
text: , stdenv , buildPythonPackage , fetchPypi <ins> , setuptools </ins> , click , mock , pytestCheckHook
Code change:
Package name: Latest released version: 2.27.0 <!-- Search your package here: --- Current version on the unstable channel: 2.21.0 Current version on the stable/release channel: 2.21.0 <!-- 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]:

Related discussion:
text: buildPythonPackage rec { pname = "google-auth-oauthlib"; <del> version = "1.1.0"; format = "setuptools"; </del> <ins> version = "1.2.0"; pyproject = true; </ins> disabled = pythonOlder "3.6"; src = fetchPypi { inherit pname version; <del> hash = "sha256-g+qMOwiB5FN5C6/0RI6KYRKsh3jR3p2gtoAQuEOTevs="; </del> <ins> hash = "sha256-KS0tN4M0nysHNKCgIHseHjIqwZPCwJ2PfGE/t8xQHqg="; </ins> }; <ins> nativeBuildInputs = [ setuptools ]; </ins> propagatedBuildInputs = [ google-auth requests-oauthlib ]; <ins> passthru.optional-dependencies = { tool = [ click ]; }; </ins> nativeCheckInputs = [ <del> click </del> mock pytestCheckHook <del> ]; </del> <ins> ] ++ passthru.optional-dependencies.tool; </ins> disabledTests = lib.optionals stdenv.isDarwin [ # This test fails if the hostname is not associated with an IP (e.g., in `/etc/hosts`).
Code change:
Package name: Latest released version: 2.27.0 <!-- Search your package here: --- Current version on the unstable channel: 2.21.0 Current version on the stable/release channel: 2.21.0 <!-- 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]:

Related discussion:
text: ]; meta = with lib; { <ins> changelog = "https://github.com/googleapis/google-auth-library-python-oauthlib/blob/v${version}/CHANGELOG.md"; </ins> description = "Google Authentication Library: oauthlib integration"; homepage = "https://github.com/GoogleCloudPlatform/google-auth-library-python-oauthlib"; license = licenses.asl20; <ins> mainProgram = "google-oauthlib-tool"; </ins> maintainers = with maintainers; [ terlar ]; }; }
Code change:
Package name: Latest released version: 2.27.0 <!-- Search your package here: --- Current version on the unstable channel: 2.21.0 Current version on the stable/release channel: 2.21.0 <!-- 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]:

Related discussion:
text: , buildPythonPackage , cachetools , cryptography <del> , fetchpatch </del> , fetchPypi , flask , freezegun
Code change:
Package name: Latest released version: 2.27.0 <!-- Search your package here: --- Current version on the unstable channel: 2.21.0 Current version on the stable/release channel: 2.21.0 <!-- 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]:

Related discussion:
text: , requests , responses , rsa <del> , six , urllib3 </del> <ins> , setuptools </ins> }: buildPythonPackage rec { pname = "google-auth"; <del> version = "2.21.0"; format = "setuptools"; </del> <ins> version = "2.27.0"; pyproject = true; </ins> <del> disabled = pythonOlder "3.6"; </del> <ins> disabled = pythonOlder "3.7"; </ins> src = fetchPypi { inherit pname version; <del> hash = "sha256-so6ASOV3J+fPDlvY5ydrISrvR2ZUoJURNUqoJ1O0XGY="; </del> <ins> hash = "sha256-6GOlbMwtjvqD33qAJyYB5DSH+ppyijdiBchsJqrvqCE="; </ins> }; <del> patches = [ # Although the migration to urllib3-2.0.0 is incomplete, # the discussion in the following PR has addressed the concerns. # https://github.com/googleapis/google-auth-library-python/pull/1290 (fetchpatch { name = "support-urllib3_2.patch"; url = "https://github.com/googleapis/google-auth-library-python/commit/9ed006d02d7c9de3e6898ee819648c2fd3367c1d.patch"; hash = "sha256-64g0GzZeyO8l/s1jqfsogr8pTOBbG9xfp/UeVZNA4q8="; includes = [ "google/auth/transport/urllib3.py" ]; }) </del> <ins> nativeBuildInputs = [ setuptools </ins> ]; propagatedBuildInputs = [ cachetools pyasn1-modules rsa <del> six urllib3 </del> ]; passthru.optional-dependencies = {