Question:
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:

"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;


Question:
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:

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 {} +" )


Question:
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...

# 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)


Question:
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...

}; 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> ''; }


Question:
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...

}; 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> ''; }


Question: 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]:

, stdenv , buildPythonPackage , fetchPypi <ins> , setuptools </ins> , click , mock , pytestCheckHook


Question: 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]:

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`).


Question: 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]:

]; 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 ]; }; }


Question: 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]:

, buildPythonPackage , cachetools , cryptography <del> , fetchpatch </del> , fetchPypi , flask , freezegun


Question: 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]:

, 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 = {


Question: 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]:

pyopenssl ]; pyopenssl = [ <ins> cryptography </ins> pyopenssl ]; reauth = [


Question: 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]:

pytestCheckHook responses ] ++ passthru.optional-dependencies.aiohttp <del> # `cryptography` is still required on `aarch64-darwin` for `tests/crypt/*` ++ (if (stdenv.isDarwin && stdenv.isAarch64) then [ cryptography ] else passthru.optional-dependencies.enterprise_cert) </del> <ins> ++ passthru.optional-dependencies.enterprise_cert </ins> ++ passthru.optional-dependencies.reauth; pythonImportsCheck = [


Question: 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]:

buildPythonPackage rec { pname = "tensorboard"; <del> version = "2.15.1"; </del> <ins> version = "2.16.0"; </ins> format = "wheel"; <del> disabled = pythonOlder "3.6"; </del> <ins> disabled = pythonOlder "3.9"; </ins> src = fetchPypi { inherit pname version format; dist = "py3"; python = "py3"; <del> hash = "sha256-xGwdHPE6RYxCmGiniyUx2P9faCBY1p7AhAsLx6OPHA8="; </del> <ins> hash = "sha256-JjuQmiAJyzp52qar5kwXhcwxfCWlTk2y/stkKf/FTFg="; </ins> }; nativeBuildInputs = [


Question: 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]:

]; meta = with lib; { <ins> changelog = "https://github.com/tensorflow/tensorboard/blob/${version}/RELEASE.md"; </ins> description = "TensorFlow's Visualization Toolkit"; homepage = "https://www.tensorflow.org/"; license = licenses.asl20; <ins> mainProgram = "tensorboard"; </ins> maintainers = with maintainers; [ abbradar ]; }; }


Question:
Mentioned in , the bcc package can also be used as from python. This currently doesn't seem to work? If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
bcc doesn't depend on kernel anymore, so the second half of the comment you linked at isn't required and we can just move the package & add a compat alias. Technically you should already be able to use bcc as by magic'ing the correct site path, but I agree it's better to move it - patch welcome!

, makeWrapper , netperf , nixosTests <del> , python3 </del> <ins> , python3Packages </ins> , stdenv , zip }: <del> python3.pkgs.buildPythonApplication rec { </del> <ins> python3Packages.buildPythonApplication rec { </ins> pname = "bcc"; version = "0.31.0";


Question:
Mentioned in , the bcc package can also be used as from python. This currently doesn't seem to work? If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
bcc doesn't depend on kernel anymore, so the second half of the comment you linked at isn't required and we can just move the package & add a compat alias. Technically you should already be able to use bcc as by magic'ing the correct site path, but I agree it's better to move it - patch welcome!

./fix-deadlock-detector-import.patch ]; <del> propagatedBuildInputs = [ python3.pkgs.netaddr ]; </del> <ins> propagatedBuildInputs = [ python3Packages.netaddr ]; </ins> nativeBuildInputs = [ bison cmake flex llvmPackages.llvm.dev makeWrapper <del> python3.pkgs.setuptools </del> <ins> python3Packages.setuptools </ins> zip ];


Question:
Mentioned in , the bcc package can also be used as from python. This currently doesn't seem to work? If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
bcc doesn't depend on kernel anymore, so the second half of the comment you linked at isn't required and we can just move the package & add a compat alias. Technically you should already be able to use bcc as by magic'ing the correct site path, but I agree it's better to move it - patch welcome!

preInstall = '' # required for setuptool during install <del> export PYTHONPATH=$out/${python3.sitePackages}:$PYTHONPATH </del> <ins> export PYTHONPATH=$out/${python3Packages.python.sitePackages}:$PYTHONPATH </ins> ''; postInstall = '' mkdir -p $out/bin $out/share


Question:
Mentioned in , the bcc package can also be used as from python. This currently doesn't seem to work? If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
bcc doesn't depend on kernel anymore, so the second half of the comment you linked at isn't required and we can just move the package & add a compat alias. Technically you should already be able to use bcc as by magic'ing the correct site path, but I agree it's better to move it - patch welcome!

bbox = callPackage ../development/python-modules/bbox { }; <ins> bcc = toPythonModule (pkgs.bcc.override { python3Packages = self; }); </ins> bc-detect-secrets = callPackage ../development/python-modules/bc-detect-secrets { }; bc-jsonpath-ng = callPackage ../development/python-modules/bc-jsonpath-ng { };


Question:
Project description GitButler is a git client that lets you work on multiple branches at the same time. It allows you to quickly organize file changes into separate branches while still having them applied to your working directory. You can then push branches individually to your remote, or directly create pull requests. In a nutshell, it's a more flexible version of git add -p and git rebase -i, allowing you to efficiently multitask across branches. Metadata homepage URL: source URL: license: FSL-1.0-MIT platforms: linux, darwin
is also a Tauri app so the packaging is likely similar:
I'll work on this over the weekend, unless anyone has already started?
I don't think building from source is gonna be easy, precisely as we don't have done yet and this project uses pnpm workspaces. You can however wrap the Appimage though.
I've made Still draft. It does start the application, but clicking buttons results in problems on my system :sweatsmile: For a quick run: Update: it's now mostly working. The signin/login still gives an error and it's still unclear why. Also, I don't think I'll use gitbutler regularly atm, so it might be best if someone else wants to volunteer as maintainer of this package :sweatsmile:
I have made a PR that builds from source and has no issues with logging in (that just needed ).
Is this request open to contributions?
Would be best to wait for a while, if that PR goes abandoned, you can ask the author if it's okay to open another

fullName = "Unspecified free software license"; }; <ins> fsl11Mit = { fullName = "Functional Source License, Version 1.1, MIT Future License"; url = "https://fsl.software/FSL-1.1-MIT.template.md"; free = false; redistributable = true; }; </ins> ftl = { spdxId = "FTL"; fullName = "Freetype Project License";