jiebi/CodeConvo huggingface dataset:
Code change:
When one installs mastodon via the following minimal config: Then there is no obvious way to run tootctl. or any other login user doesn't have the executable by default, nor can this be enabled in an obvious way. is not a login user, so can't (and shouldn't?) log in as and execute . Steps to reproduce the behavior: mastodon as per minimal config above ... nope. ... nope. ... nope. ... nope. Any of: a setting such that is installed for that user an explanation in the docs what to do as a login user (probably bad idea?) Workaround: CC
I think upstream intends only to be run by the mastodon user. My way for doing that is just running and continuing in that shell. The reason why doesn't work is probably because sudo inherits PATH from the user you are coming from? I'm not sure I understand the concept of a login user enough. How would mastodon become a login user and why would that be a bad idea?
In the mastodon docs, it is described the following way: But is not possible, it gives the error They do recommend (which is what I meant by it shouldn't be a login user), but still they seem to do something different than nixos does. Maybe that's fine, and it would be helpful to document this somewhere, so people don't spend a long time trying to find it out.
This is default for almost all service users because they have no login shell. Use ` This is wrong. Sudo resets all path like variables like PATH and PYTHON PATH. Also inheriting needs to be turned on explicitly and PATH mist always ve inherited explicitly. Other services like nextcloud include a wrapper that sudos to the right user. This should be for mastodon, too.
Sounds like a good solution. Then we could make the command globally available.
That isn't? I would have expected that it is very similar to nextcloud-occ.
No currently it is only available to the mastodon user, so tootctl never gets called as the wrong user.
There is a hack in the nixos nextcloud-occ script that automatically sudoes if called by a different user. This could be adapted to tootctl I think.
Yes, this should be adapted. Changing the mastodon to a login user would not be the correct fix.

Related discussion:
text: </listitem> <listitem> <para> <ins> <literal>services.mastodon</literal> gained a tootctl wrapped named <literal>mastodon-tootctl</literal> similar to <literal>nextcloud-occ</literal> which can be executed from any user and switches to the configured mastodon user with sudo and sources the environment variables. </para> </listitem> <listitem> <para> </ins> A new <literal>virtualisation.rosetta</literal> module was added to allow running <literal>x86_64</literal> binaries through
Code change:
When one installs mastodon via the following minimal config: Then there is no obvious way to run tootctl. or any other login user doesn't have the executable by default, nor can this be enabled in an obvious way. is not a login user, so can't (and shouldn't?) log in as and execute . Steps to reproduce the behavior: mastodon as per minimal config above ... nope. ... nope. ... nope. ... nope. Any of: a setting such that is installed for that user an explanation in the docs what to do as a login user (probably bad idea?) Workaround: CC
I think upstream intends only to be run by the mastodon user. My way for doing that is just running and continuing in that shell. The reason why doesn't work is probably because sudo inherits PATH from the user you are coming from? I'm not sure I understand the concept of a login user enough. How would mastodon become a login user and why would that be a bad idea?
In the mastodon docs, it is described the following way: But is not possible, it gives the error They do recommend (which is what I meant by it shouldn't be a login user), but still they seem to do something different than nixos does. Maybe that's fine, and it would be helpful to document this somewhere, so people don't spend a long time trying to find it out.
This is default for almost all service users because they have no login shell. Use ` This is wrong. Sudo resets all path like variables like PATH and PYTHON PATH. Also inheriting needs to be turned on explicitly and PATH mist always ve inherited explicitly. Other services like nextcloud include a wrapper that sudos to the right user. This should be for mastodon, too.
Sounds like a good solution. Then we could make the command globally available.
That isn't? I would have expected that it is very similar to nextcloud-occ.
No currently it is only available to the mastodon user, so tootctl never gets called as the wrong user.
There is a hack in the nixos nextcloud-occ script that automatically sudoes if called by a different user. This could be adapted to tootctl I think.
Yes, this should be adapted. Changing the mastodon to a login user would not be the correct fix.

Related discussion:
text: - The module for the application firewall `opensnitch` got the ability to configure rules. Available as [services.opensnitch.rules](#opt-services.opensnitch.rules) <ins> - `services.mastodon` gained a tootctl wrapped named `mastodon-tootctl` similar to `nextcloud-occ` which can be executed from any user and switches to the configured mastodon user with sudo and sources the environment variables. </ins> - A new `virtualisation.rosetta` module was added to allow running `x86_64` binaries through [Rosetta](https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment) inside virtualised NixOS guests on Apple silicon. This feature works by default with the [UTM](https://docs.getutm.app/) virtualisation [package](https://search.nixos.org/packages?channel=unstable&show=utm&from=0&size=1&sort=relevance&type=packages&query=utm).
Code change:
When one installs mastodon via the following minimal config: Then there is no obvious way to run tootctl. or any other login user doesn't have the executable by default, nor can this be enabled in an obvious way. is not a login user, so can't (and shouldn't?) log in as and execute . Steps to reproduce the behavior: mastodon as per minimal config above ... nope. ... nope. ... nope. ... nope. Any of: a setting such that is installed for that user an explanation in the docs what to do as a login user (probably bad idea?) Workaround: CC
I think upstream intends only to be run by the mastodon user. My way for doing that is just running and continuing in that shell. The reason why doesn't work is probably because sudo inherits PATH from the user you are coming from? I'm not sure I understand the concept of a login user enough. How would mastodon become a login user and why would that be a bad idea?
In the mastodon docs, it is described the following way: But is not possible, it gives the error They do recommend (which is what I meant by it shouldn't be a login user), but still they seem to do something different than nixos does. Maybe that's fine, and it would be helpful to document this somewhere, so people don't spend a long time trying to find it out.
This is default for almost all service users because they have no login shell. Use ` This is wrong. Sudo resets all path like variables like PATH and PYTHON PATH. Also inheriting needs to be turned on explicitly and PATH mist always ve inherited explicitly. Other services like nextcloud include a wrapper that sudos to the right user. This should be for mastodon, too.
Sounds like a good solution. Then we could make the command globally available.
That isn't? I would have expected that it is very similar to nextcloud-occ.
No currently it is only available to the mastodon user, so tootctl never gets called as the wrong user.
There is a hack in the nixos nextcloud-occ script that automatically sudoes if called by a different user. This could be adapted to tootctl I think.
Yes, this should be adapted. Changing the mastodon to a login user would not be the correct fix.

Related discussion:
text: ] else [] ) env)))); <del> mastodonEnv = pkgs.writeShellScriptBin "mastodon-env" '' </del> <ins> mastodonTootctl = pkgs.writeShellScriptBin "mastodon-tootctl" '' #! ${pkgs.runtimeShell} </ins> set -a export RAILS_ROOT="${cfg.package}" source "${envFile}" source /var/lib/mastodon/.secrets_env <del> eval -- "$@" </del> <ins> sudo=exec if [[ "$USER" != ${cfg.user} ]]; then sudo='exec /run/wrappers/bin/sudo -u ${cfg.user} --preserve-env' fi $sudo ${cfg.package}/bin/tootctl "$@" </ins> ''; in {
Code change:
When one installs mastodon via the following minimal config: Then there is no obvious way to run tootctl. or any other login user doesn't have the executable by default, nor can this be enabled in an obvious way. is not a login user, so can't (and shouldn't?) log in as and execute . Steps to reproduce the behavior: mastodon as per minimal config above ... nope. ... nope. ... nope. ... nope. Any of: a setting such that is installed for that user an explanation in the docs what to do as a login user (probably bad idea?) Workaround: CC
I think upstream intends only to be run by the mastodon user. My way for doing that is just running and continuing in that shell. The reason why doesn't work is probably because sudo inherits PATH from the user you are coming from? I'm not sure I understand the concept of a login user enough. How would mastodon become a login user and why would that be a bad idea?
In the mastodon docs, it is described the following way: But is not possible, it gives the error They do recommend (which is what I meant by it shouldn't be a login user), but still they seem to do something different than nixos does. Maybe that's fine, and it would be helpful to document this somewhere, so people don't spend a long time trying to find it out.
This is default for almost all service users because they have no login shell. Use ` This is wrong. Sudo resets all path like variables like PATH and PYTHON PATH. Also inheriting needs to be turned on explicitly and PATH mist always ve inherited explicitly. Other services like nextcloud include a wrapper that sudos to the right user. This should be for mastodon, too.
Sounds like a good solution. Then we could make the command globally available.
That isn't? I would have expected that it is very similar to nextcloud-occ.
No currently it is only available to the mastodon user, so tootctl never gets called as the wrong user.
There is a hack in the nixos nextcloud-occ script that automatically sudoes if called by a different user. This could be adapted to tootctl I think.
Yes, this should be adapted. Changing the mastodon to a login user would not be the correct fix.

Related discussion:
text: description = lib.mdDoc '' User under which mastodon runs. If it is set to "mastodon", that user will be created, otherwise it should be set to the <del> name of a user created elsewhere.  In both cases, `mastodon` and a package containing only the shell script `mastodon-env` will be added to the user's package set. To run a command from `mastodon` such as `tootctl` with the environment configured by this module use `mastodon-env`, as in: `mastodon-env tootctl accounts create newuser --email newuser@example.com` </del> <ins> name of a user created elsewhere. In both cases, the `mastodon` package will be added to the user's package set and a tootctl wrapper to system packages that switches to the configured account and load the right environment. </ins> ''; type = lib.types.str; default = "mastodon";
Code change:
When one installs mastodon via the following minimal config: Then there is no obvious way to run tootctl. or any other login user doesn't have the executable by default, nor can this be enabled in an obvious way. is not a login user, so can't (and shouldn't?) log in as and execute . Steps to reproduce the behavior: mastodon as per minimal config above ... nope. ... nope. ... nope. ... nope. Any of: a setting such that is installed for that user an explanation in the docs what to do as a login user (probably bad idea?) Workaround: CC
I think upstream intends only to be run by the mastodon user. My way for doing that is just running and continuing in that shell. The reason why doesn't work is probably because sudo inherits PATH from the user you are coming from? I'm not sure I understand the concept of a login user enough. How would mastodon become a login user and why would that be a bad idea?
In the mastodon docs, it is described the following way: But is not possible, it gives the error They do recommend (which is what I meant by it shouldn't be a login user), but still they seem to do something different than nixos does. Maybe that's fine, and it would be helpful to document this somewhere, so people don't spend a long time trying to find it out.
This is default for almost all service users because they have no login shell. Use ` This is wrong. Sudo resets all path like variables like PATH and PYTHON PATH. Also inheriting needs to be turned on explicitly and PATH mist always ve inherited explicitly. Other services like nextcloud include a wrapper that sudos to the right user. This should be for mastodon, too.
Sounds like a good solution. Then we could make the command globally available.
That isn't? I would have expected that it is very similar to nextcloud-occ.
No currently it is only available to the mastodon user, so tootctl never gets called as the wrong user.
There is a hack in the nixos nextcloud-occ script that automatically sudoes if called by a different user. This could be adapted to tootctl I think.
Yes, this should be adapted. Changing the mastodon to a login user would not be the correct fix.

Related discussion:
text: } ]; <ins> environment.systemPackages = [ mastodonTootctl ]; </ins> systemd.services.mastodon-init-dirs = { script = '' umask 077
Code change:
When one installs mastodon via the following minimal config: Then there is no obvious way to run tootctl. or any other login user doesn't have the executable by default, nor can this be enabled in an obvious way. is not a login user, so can't (and shouldn't?) log in as and execute . Steps to reproduce the behavior: mastodon as per minimal config above ... nope. ... nope. ... nope. ... nope. Any of: a setting such that is installed for that user an explanation in the docs what to do as a login user (probably bad idea?) Workaround: CC
I think upstream intends only to be run by the mastodon user. My way for doing that is just running and continuing in that shell. The reason why doesn't work is probably because sudo inherits PATH from the user you are coming from? I'm not sure I understand the concept of a login user enough. How would mastodon become a login user and why would that be a bad idea?
In the mastodon docs, it is described the following way: But is not possible, it gives the error They do recommend (which is what I meant by it shouldn't be a login user), but still they seem to do something different than nixos does. Maybe that's fine, and it would be helpful to document this somewhere, so people don't spend a long time trying to find it out.
This is default for almost all service users because they have no login shell. Use ` This is wrong. Sudo resets all path like variables like PATH and PYTHON PATH. Also inheriting needs to be turned on explicitly and PATH mist always ve inherited explicitly. Other services like nextcloud include a wrapper that sudos to the right user. This should be for mastodon, too.
Sounds like a good solution. Then we could make the command globally available.
That isn't? I would have expected that it is very similar to nextcloud-occ.
No currently it is only available to the mastodon user, so tootctl never gets called as the wrong user.
There is a hack in the nixos nextcloud-occ script that automatically sudoes if called by a different user. This could be adapted to tootctl I think.
Yes, this should be adapted. Changing the mastodon to a login user would not be the correct fix.

Related discussion:
text: inherit (cfg) group; }; }) <del> (lib.attrsets.setAttrByPath [ cfg.user "packages" ] [ cfg.package mastodonEnv pkgs.imagemagick ]) </del> <ins> (lib.attrsets.setAttrByPath [ cfg.user "packages" ] [ cfg.package pkgs.imagemagick ]) </ins> ]; users.groups.${cfg.group}.members = lib.optional cfg.configureNginx config.services.nginx.user;
Code change:
When exporting the graph, logseq throws a permission exception. Steps to reproduce the behavior: a new graph a few pages them public ()) the graph The graph should successfully export and opening it should show a read-only view of the graph. The logseq documentation itself is an example thereof. If applicable, add screenshots to help explain your problem. Bug was first reported in the original repo When running the AppImage with it's fine because it's extracted into , but when the app is in then it won't work because of the read-only status. I tested the flatpak version because I suspected the same problem would occur, but the directories are mounted read-write in a read-only volume. So, 2 options exist as I see it: fix it upstream, but I don't know Clojure nor Electron start the AppImage with instead of extracting it Please run and paste the result.

Related discussion:
text: , stdenv , fetchurl , appimageTools <ins> , appimage-run </ins> , makeWrapper <del> , electron </del> , git }:
Code change:
When exporting the graph, logseq throws a permission exception. Steps to reproduce the behavior: a new graph a few pages them public ()) the graph The graph should successfully export and opening it should show a read-only view of the graph. The logseq documentation itself is an example thereof. If applicable, add screenshots to help explain your problem. Bug was first reported in the original repo When running the AppImage with it's fine because it's extracted into , but when the app is in then it won't work because of the read-only status. I tested the flatpak version because I suspected the same problem would occur, but the directories are mounted read-write in a read-only volume. So, 2 options exist as I see it: fix it upstream, but I don't know Clojure nor Electron start the AppImage with instead of extracting it Please run and paste the result.

Related discussion:
text: installPhase = '' runHook preInstall <del> mkdir -p $out/bin $out/share/${pname} $out/share/applications cp -a ${appimageContents}/{locales,resources} $out/share/${pname} </del> <ins> mkdir -p $out/bin $out/share/${pname} $out/share/applications $out/share/${pname}/resources/app/icons cp -a ${appimageContents}/resources/app/icons/logseq.png $out/share/${pname}/resources/app/icons/logseq.png </ins> cp -a ${appimageContents}/Logseq.desktop $out/share/applications/${pname}.desktop <del> # remove the `git` in `dugite` because we want the `git` in `nixpkgs` chmod +w -R $out/share/${pname}/resources/app/node_modules/dugite/git chmod +w $out/share/${pname}/resources/app/node_modules/dugite rm -rf $out/share/${pname}/resources/app/node_modules/dugite/git chmod -w $out/share/${pname}/resources/app/node_modules/dugite </del> <ins> # set the env "LOCAL_GIT_DIRECTORY" for dugite so that we can use the git in nixpkgs makeWrapper ${appimage-run}/bin/appimage-run $out/bin/logseq  --set "LOCAL_GIT_DIRECTORY" ${git}  --add-flags ${src} # Make the desktop entry run the app using appimage-run </ins> substituteInPlace $out/share/applications/${pname}.desktop  <del> --replace Exec=Logseq Exec=${pname}  </del> <ins> --replace Exec=Logseq "Exec=$out/bin/logseq"  </ins> --replace Icon=Logseq Icon=$out/share/${pname}/resources/app/icons/logseq.png runHook postInstall ''; <del> postFixup = '' # set the env "LOCAL_GIT_DIRECTORY" for dugite so that we can use the git in nixpkgs makeWrapper ${electron}/bin/electron $out/bin/${pname}  --set "LOCAL_GIT_DIRECTORY" ${git}  --add-flags $out/share/${pname}/resources/app ''; </del> passthru.updateScript = ./update.sh; meta = with lib; {
Code change:
When exporting the graph, logseq throws a permission exception. Steps to reproduce the behavior: a new graph a few pages them public ()) the graph The graph should successfully export and opening it should show a read-only view of the graph. The logseq documentation itself is an example thereof. If applicable, add screenshots to help explain your problem. Bug was first reported in the original repo When running the AppImage with it's fine because it's extracted into , but when the app is in then it won't work because of the read-only status. I tested the flatpak version because I suspected the same problem would occur, but the directories are mounted read-write in a read-only volume. So, 2 options exist as I see it: fix it upstream, but I don't know Clojure nor Electron start the AppImage with instead of extracting it Please run and paste the result.

Related discussion:
text: lilo = callPackage ../tools/misc/lilo { }; <del> logseq = callPackage ../applications/misc/logseq { electron = electron_20; }; </del> <ins> logseq = callPackage ../applications/misc/logseq { }; </ins> natls = callPackage ../tools/misc/natls { };
Code change:
On my M1 Mac, with homebrew-installed libvirt / qemu-system-aarch64, I'm able to run the VM defined in the config below without issue. However with libvirt / qemu installed via nix, I get: Some possibly related discussion . Looking at the , they're explicitly setting ; adding this seems to resolve the issue: I'm not sure whether disabling those failing tests is a reasonable thing to do. Steps to reproduce the behavior: to in A clear and concise description of what you expected to happen. Should run without , like it does with homebrew. Please run and paste the result.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
FWIW, I also encountered this issue, and have to use the following workaround: And -ing the efi firmware & vars manually. Fixing this bug can lead to great user experience: virt-manager can work out of box.
Where did you get ?

Related discussion:
text: # Darwin , gmp , libiconv <ins> , qemu </ins> , Carbon , AppKit
Code change:
On my M1 Mac, with homebrew-installed libvirt / qemu-system-aarch64, I'm able to run the VM defined in the config below without issue. However with libvirt / qemu installed via nix, I get: Some possibly related discussion . Looking at the , they're explicitly setting ; adding this seems to resolve the issue: I'm not sure whether disabling those failing tests is a reasonable thing to do. Steps to reproduce the behavior: to in A clear and concise description of what you expected to happen. Should run without , like it does with homebrew. Please run and paste the result.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
FWIW, I also encountered this issue, and have to use the following workaround: And -ing the efi firmware & vars manually. Fixing this bug can lead to great user experience: virt-manager can work out of box.
Where did you get ?

Related discussion:
text: '' + optionalString isDarwin '' sed -i '/qemucapabilitiestest/d' tests/meson.build sed -i '/vircryptotest/d' tests/meson.build <ins> sed -i '/domaincapstest/d' tests/meson.build sed -i '/qemufirmwaretest/d' tests/meson.build sed -i '/qemuvhostusertest/d' tests/meson.build </ins> '' + optionalString (isDarwin && isx86_64) '' sed -i '/qemucaps2xmltest/d' tests/meson.build sed -i '/qemuhotplugtest/d' tests/meson.build
Code change:
On my M1 Mac, with homebrew-installed libvirt / qemu-system-aarch64, I'm able to run the VM defined in the config below without issue. However with libvirt / qemu installed via nix, I get: Some possibly related discussion . Looking at the , they're explicitly setting ; adding this seems to resolve the issue: I'm not sure whether disabling those failing tests is a reasonable thing to do. Steps to reproduce the behavior: to in A clear and concise description of what you expected to happen. Should run without , like it does with homebrew. Please run and paste the result.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
FWIW, I also encountered this issue, and have to use the following workaround: And -ing the efi firmware & vars manually. Fixing this bug can lead to great user experience: virt-manager can work out of box.
Where did you get ?

Related discussion:
text: (cfg "runstatedir" "/run") (cfg "init_script" (if isDarwin then "none" else "systemd")) <ins> (cfg "qemu_datadir" (if isDarwin then "${qemu}/share/qemu" else "")) </ins> (feat "apparmor" isLinux) (feat "attr" isLinux)