Question:
consists mostly of syscalls (including ). There are even Ruby-specific workarounds. C/C++ would be a better language for the task. This should also reduce closure size and startup time of FHS-sandboxed apps (Ruby needs to load itself and its libraries from disk).
Can't we just use to setup the chroot?
I'm not sure if it's capable of doing all things that we need for this, but it should be worth checking. Can it run a container as a process (not as a systemd service), and can it be used not by a superuser?
needs root privileges. btw has C code to set them up, the rest is probably bash only?
D: A pity. Well, let's continue with the old plan then. Unfortunately we can't do much more in Bash than we already do because we need to do mounts in the same process we set the namespaces, in children necessary privileges are already gone. I'm not completely sure about this but I remember that when I tried to write this in Bash completely long time ago (using for setting up namespaces mounts and chroot were a problem.
How about using this one?
bind mounts, sysfs, tmpfs and procfs should be
I can confirm that these mounts are possible from using unprivileged lxc containers. But you cannot bind mount something from the host this way, because it needs to be done after . UPDATE: ok even that should be possible if the correct order is maintained: unshare -mount -chroot.
Oh, I should look at it! cc in case he's interested in this thread. I think that checks if the user is root -- that's why this doesn't work. This means that we need to call by ourselves... (I was going to hit "Comment" but you were faster ~_^) I expect that LXC containers do user maps such that you have UID 0 in new userns -- we, however, need to retain user uid.
why do we have to retain user id?
Multiple user apps use uid and username for their purposes -- we don't want to lie to them. I can't give a complete example (I remember that Steam breaks) but for example we have directories which apps can find based on uid.
I have another suggestion: the Go programming language. Bear in mind that I'm generally not a super big fan of Go (in fact, while I use Go extensively at work, I generally use Haskell for my personal projects); however, I think that a higher level, simple (in terms of specification) language would be conducive to maintenance and further development. The binaries should be pretty small, and the closure should be pretty small, too. I might give that a go (no pun intended) and see what we think.
Several possible issues: need native and then before any calls to pthreads (or you'll get or something close); I remember that Go has a runtime so there may be problems; need several syscalls which may not be readily available, namely , and others. In Ruby I import them from libc dynamically and redefine constants from C by hand, but doing this (especially redefining constants) is one of the reasons I want to move from Ruby in the first place. However these are only potential problems -- I don't know if they actually exist! I'm actually interested in how this turns out.
You cannot use clone() properly because of the language runtime. That's why docker uses a little C for that job.
Ah, you must be referring to this from : I'll need to give that a thorough reading before I understand why the runtime gets in the way (unless, perhaps, you have an explanation of why/how pthreads mucks things up).
Oh, I'm guessing that's probably stuff like this: Though, if there are other details, I'd love to hear them :smile:.
If you refer to my remark about fork and pthreads, it's actually 's limitation. You can look at how I workaround this in Ruby by calling imported instead of Ruby's builtin. You will know if you encounter it -- will just fail. I think the best way to find out is with an experiment. (notice that I don't know about Go runtime and haven't even used Go before, so, as I underline again, those might be non-issues)
Interesting. I referred to the , but I don't see any mention of failure when used with pthreads. I don't doubt you; I'd just like to know how all this stuff works.
No problem even if these were doubts ~^. From man page:
Ah, dunno why I didn't try reading the man page -- thanks for pointing that out :wink:.
Anybody done any more work on this? Also, this should probably be tagged with security, due to
a rewrite in a different language will not solve your grsecurity problems. I also do not see how the rewrite discussed here is related to security.
Anything related to grsecurity is security-related. A rewrite into a compiled language means that a setuid wrapper can be created, which means I don't have to run shit as root.
You can drop your privileges via right after you enter the environment as -- it's less convenient but you get roughly what you want.

<ins> #define _GNU_SOURCE #include <errno.h> #include <error.h> #define errorf(status, fmt, ...)                                                error_at_line(status, errno, __FILE__, __LINE__, fmt, ##__VA_ARGS__) #include <dirent.h> #include <ftw.h> #include <sched.h> #include <stdarg.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sysexits.h> #include <unistd.h> #include <sys/mount.h> #include <sys/stat.h> #include <sys/wait.h> char *env_whitelist[] = {"TERM", "DISPLAY", "XAUTHORITY", "HOME", "XDG_RUNTIME_DIR", "LANG", "SSL_CERT_FILE", "DBUS_SESSION_BUS_ADDRESS"}; char **env_build(char *names[], size_t len) { char *env, **ret = malloc((len + 1) * sizeof(char *)), **ptr = ret; for (size_t i = 0; i < len; i++) { if ((env = getenv(names[i]))) { if (asprintf(ptr++, "%s=%s", names[i], env) < 0) errorf(EX_OSERR, "asprintf"); } } *ptr = NULL; return ret; } struct bind { char *from; char *to; }; struct bind binds[] = {{"/", "host"},   {"/proc", "proc"}, {"/sys", "sys"}, {"/nix", "nix"}, {"/tmp", "tmp"},   {"/var", "var"}, {"/run", "run"}, {"/dev", "dev"},   {"/home", "home"}}; void bind(struct bind *bind) { DIR *src = opendir(bind->from); if (src) { if (closedir(src) < 0) errorf(EX_IOERR, "closedir"); if (mkdir(bind->to, 0755) < 0) errorf(EX_IOERR, "mkdir"); if (mount(bind->from, bind->to, "bind", MS_BIND | MS_REC, NULL) < 0) errorf(EX_OSERR, "mount"); } else { // https://github.com/NixOS/nixpkgs/issues/31104 if (errno != ENOENT) errorf(EX_OSERR, "opendir"); } } void spitf(char *path, char *fmt, ...) { va_list args; va_start(args, fmt); FILE *f = fopen(path, "w"); if (f == NULL) errorf(EX_IOERR, "spitf(%s): fopen", path); if (vfprintf(f, fmt, args) < 0) errorf(EX_IOERR, "spitf(%s): vfprintf", path); if (fclose(f) < 0) errorf(EX_IOERR, "spitf(%s): fclose", path); } int nftw_rm(const char *path, const struct stat *sb, int type, struct FTW *ftw) { if (remove(path) < 0) errorf(EX_IOERR, "nftw_rm"); return 0; } #define LEN(x) sizeof(x) / sizeof(*x) int main(int argc, char *argv[]) { if (argc < 2) { fprintf(stderr, "Usage: %s command [arguments...]n" "Requires Linux kernel >= 3.19 with CONFIG_USER_NS.n", argv[0]); exit(EX_USAGE); } char tmpl[] = "/tmp/chrootenvXXXXXX"; char *root = mkdtemp(tmpl); if (root == NULL) errorf(EX_IOERR, "mkdtemp"); // Don't make root private so that privilege drops inside chroot are possible: if (chmod(root, 0755) < 0) errorf(EX_IOERR, "chmod"); pid_t cpid = fork(); if (cpid < 0) errorf(EX_OSERR, "fork"); if (cpid == 0) { uid_t uid = getuid(); gid_t gid = getgid(); // If we are root, no need to create new user namespace. if (uid == 0) { if (unshare(CLONE_NEWNS) < 0) errorf(EX_OSERR, "unshare() failed: You may have an old kernel or have CLONE_NEWUSER disabled by your distribution security settings."); // Mark all mounted filesystems as slave so changes // don't propagate to the parent mount namespace. if (mount(NULL, "/", NULL, MS_REC | MS_SLAVE, NULL) < 0) errorf(EX_OSERR, "mount"); } else { // Create new mount and user namespaces. CLONE_NEWUSER // requires a program to be non-threaded. if (unshare(CLONE_NEWNS | CLONE_NEWUSER) < 0) errorf(EX_OSERR, "unshare"); // Map users and groups to the parent namespace. // setgroups is only available since Linux 3.19: spitf("/proc/self/setgroups", "deny"); spitf("/proc/self/uid_map", "%d %d 1", uid, uid); spitf("/proc/self/gid_map", "%d %d 1", gid, gid); } if (chdir(root) < 0) errorf(EX_IOERR, "chdir"); for (size_t i = 0; i < LEN(binds); i++) bind(&binds[i]); if (chroot(root) < 0) errorf(EX_OSERR, "chroot"); if (chdir("/") < 0) errorf(EX_OSERR, "chdir"); argv++; if (execvpe(*argv, argv, env_build(env_whitelist, LEN(env_whitelist))) < 0) errorf(EX_OSERR, "execvpe"); } int status; if (waitpid(cpid, &status, 0) < 0) errorf(EX_OSERR, "waitpid"); if (nftw(root, nftw_rm, getdtablesize(), FTW_DEPTH | FTW_MOUNT | FTW_PHYS) < 0) errorf(EX_IOERR, "nftw"); if (WIFEXITED(status)) return WEXITSTATUS(status); else if (WIFSIGNALED(status)) kill(getpid(), WTERMSIG(status)); return EX_OSERR; } </ins>


Question:
consists mostly of syscalls (including ). There are even Ruby-specific workarounds. C/C++ would be a better language for the task. This should also reduce closure size and startup time of FHS-sandboxed apps (Ruby needs to load itself and its libraries from disk).
Can't we just use to setup the chroot?
I'm not sure if it's capable of doing all things that we need for this, but it should be worth checking. Can it run a container as a process (not as a systemd service), and can it be used not by a superuser?
needs root privileges. btw has C code to set them up, the rest is probably bash only?
D: A pity. Well, let's continue with the old plan then. Unfortunately we can't do much more in Bash than we already do because we need to do mounts in the same process we set the namespaces, in children necessary privileges are already gone. I'm not completely sure about this but I remember that when I tried to write this in Bash completely long time ago (using for setting up namespaces mounts and chroot were a problem.
How about using this one?
bind mounts, sysfs, tmpfs and procfs should be
I can confirm that these mounts are possible from using unprivileged lxc containers. But you cannot bind mount something from the host this way, because it needs to be done after . UPDATE: ok even that should be possible if the correct order is maintained: unshare -mount -chroot.
Oh, I should look at it! cc in case he's interested in this thread. I think that checks if the user is root -- that's why this doesn't work. This means that we need to call by ourselves... (I was going to hit "Comment" but you were faster ~_^) I expect that LXC containers do user maps such that you have UID 0 in new userns -- we, however, need to retain user uid.
why do we have to retain user id?
Multiple user apps use uid and username for their purposes -- we don't want to lie to them. I can't give a complete example (I remember that Steam breaks) but for example we have directories which apps can find based on uid.
I have another suggestion: the Go programming language. Bear in mind that I'm generally not a super big fan of Go (in fact, while I use Go extensively at work, I generally use Haskell for my personal projects); however, I think that a higher level, simple (in terms of specification) language would be conducive to maintenance and further development. The binaries should be pretty small, and the closure should be pretty small, too. I might give that a go (no pun intended) and see what we think.
Several possible issues: need native and then before any calls to pthreads (or you'll get or something close); I remember that Go has a runtime so there may be problems; need several syscalls which may not be readily available, namely , and others. In Ruby I import them from libc dynamically and redefine constants from C by hand, but doing this (especially redefining constants) is one of the reasons I want to move from Ruby in the first place. However these are only potential problems -- I don't know if they actually exist! I'm actually interested in how this turns out.
You cannot use clone() properly because of the language runtime. That's why docker uses a little C for that job.
Ah, you must be referring to this from : I'll need to give that a thorough reading before I understand why the runtime gets in the way (unless, perhaps, you have an explanation of why/how pthreads mucks things up).
Oh, I'm guessing that's probably stuff like this: Though, if there are other details, I'd love to hear them :smile:.
If you refer to my remark about fork and pthreads, it's actually 's limitation. You can look at how I workaround this in Ruby by calling imported instead of Ruby's builtin. You will know if you encounter it -- will just fail. I think the best way to find out is with an experiment. (notice that I don't know about Go runtime and haven't even used Go before, so, as I underline again, those might be non-issues)
Interesting. I referred to the , but I don't see any mention of failure when used with pthreads. I don't doubt you; I'd just like to know how all this stuff works.
No problem even if these were doubts ~^. From man page:
Ah, dunno why I didn't try reading the man page -- thanks for pointing that out :wink:.
Anybody done any more work on this? Also, this should probably be tagged with security, due to
a rewrite in a different language will not solve your grsecurity problems. I also do not see how the rewrite discussed here is related to security.
Anything related to grsecurity is security-related. A rewrite into a compiled language means that a setuid wrapper can be created, which means I don't have to run shit as root.
You can drop your privileges via right after you enter the environment as -- it's less convenient but you get roughly what you want.

let buildFHSEnv = callPackage ./env.nix { }; in <del> args@{ name, runScript ? "bash", extraBindMounts ? [], extraInstallCommands ? "", meta ? {}, passthru ? {}, ... }: </del> <ins> args@{ name, runScript ? "bash", extraInstallCommands ? "", meta ? {}, passthru ? {}, ... }: </ins> let <del> env = buildFHSEnv (removeAttrs args [ "runScript" "extraBindMounts" "extraInstallCommands" "meta" "passthru" ]); </del> <ins> env = buildFHSEnv (removeAttrs args [ "runScript" "extraInstallCommands" "meta" "passthru" ]); </ins> <del> # Sandboxing script chroot-user = writeScript "chroot-user" '' #! ${ruby}/bin/ruby ${builtins.readFile ./chroot-user.rb} ''; </del> <ins> chrootenv = stdenv.mkDerivation { name = "chrootenv"; unpackPhase = "cp ${./chrootenv.c} chrootenv.c"; installPhase = "cp chrootenv $out"; makeFlags = [ "chrootenv" ]; }; </ins> init = run: writeScript "${name}-init" '' #! ${stdenv.shell}


Question:
consists mostly of syscalls (including ). There are even Ruby-specific workarounds. C/C++ would be a better language for the task. This should also reduce closure size and startup time of FHS-sandboxed apps (Ruby needs to load itself and its libraries from disk).
Can't we just use to setup the chroot?
I'm not sure if it's capable of doing all things that we need for this, but it should be worth checking. Can it run a container as a process (not as a systemd service), and can it be used not by a superuser?
needs root privileges. btw has C code to set them up, the rest is probably bash only?
D: A pity. Well, let's continue with the old plan then. Unfortunately we can't do much more in Bash than we already do because we need to do mounts in the same process we set the namespaces, in children necessary privileges are already gone. I'm not completely sure about this but I remember that when I tried to write this in Bash completely long time ago (using for setting up namespaces mounts and chroot were a problem.
How about using this one?
bind mounts, sysfs, tmpfs and procfs should be
I can confirm that these mounts are possible from using unprivileged lxc containers. But you cannot bind mount something from the host this way, because it needs to be done after . UPDATE: ok even that should be possible if the correct order is maintained: unshare -mount -chroot.
Oh, I should look at it! cc in case he's interested in this thread. I think that checks if the user is root -- that's why this doesn't work. This means that we need to call by ourselves... (I was going to hit "Comment" but you were faster ~_^) I expect that LXC containers do user maps such that you have UID 0 in new userns -- we, however, need to retain user uid.
why do we have to retain user id?
Multiple user apps use uid and username for their purposes -- we don't want to lie to them. I can't give a complete example (I remember that Steam breaks) but for example we have directories which apps can find based on uid.
I have another suggestion: the Go programming language. Bear in mind that I'm generally not a super big fan of Go (in fact, while I use Go extensively at work, I generally use Haskell for my personal projects); however, I think that a higher level, simple (in terms of specification) language would be conducive to maintenance and further development. The binaries should be pretty small, and the closure should be pretty small, too. I might give that a go (no pun intended) and see what we think.
Several possible issues: need native and then before any calls to pthreads (or you'll get or something close); I remember that Go has a runtime so there may be problems; need several syscalls which may not be readily available, namely , and others. In Ruby I import them from libc dynamically and redefine constants from C by hand, but doing this (especially redefining constants) is one of the reasons I want to move from Ruby in the first place. However these are only potential problems -- I don't know if they actually exist! I'm actually interested in how this turns out.
You cannot use clone() properly because of the language runtime. That's why docker uses a little C for that job.
Ah, you must be referring to this from : I'll need to give that a thorough reading before I understand why the runtime gets in the way (unless, perhaps, you have an explanation of why/how pthreads mucks things up).
Oh, I'm guessing that's probably stuff like this: Though, if there are other details, I'd love to hear them :smile:.
If you refer to my remark about fork and pthreads, it's actually 's limitation. You can look at how I workaround this in Ruby by calling imported instead of Ruby's builtin. You will know if you encounter it -- will just fail. I think the best way to find out is with an experiment. (notice that I don't know about Go runtime and haven't even used Go before, so, as I underline again, those might be non-issues)
Interesting. I referred to the , but I don't see any mention of failure when used with pthreads. I don't doubt you; I'd just like to know how all this stuff works.
No problem even if these were doubts ~^. From man page:
Ah, dunno why I didn't try reading the man page -- thanks for pointing that out :wink:.
Anybody done any more work on this? Also, this should probably be tagged with security, due to
a rewrite in a different language will not solve your grsecurity problems. I also do not see how the rewrite discussed here is related to security.
Anything related to grsecurity is security-related. A rewrite into a compiled language means that a setuid wrapper can be created, which means I don't have to run shit as root.
You can drop your privileges via right after you enter the environment as -- it's less convenient but you get roughly what you want.

passthru = passthru // { env = runCommand "${name}-shell-env" { shellHook = '' <del> ${lib.optionalString (extraBindMounts != []) ''export CHROOTENV_EXTRA_BINDS="${lib.concatStringsSep ":" extraBindMounts}:$CHROOTENV_EXTRA_BINDS"''} exec ${chroot-user} ${init "bash"} "$(pwd)" </del> <ins> exec ${chrootenv} ${init "bash"} "$(pwd)" </ins> ''; } '' echo >&2 ""


Question:
consists mostly of syscalls (including ). There are even Ruby-specific workarounds. C/C++ would be a better language for the task. This should also reduce closure size and startup time of FHS-sandboxed apps (Ruby needs to load itself and its libraries from disk).
Can't we just use to setup the chroot?
I'm not sure if it's capable of doing all things that we need for this, but it should be worth checking. Can it run a container as a process (not as a systemd service), and can it be used not by a superuser?
needs root privileges. btw has C code to set them up, the rest is probably bash only?
D: A pity. Well, let's continue with the old plan then. Unfortunately we can't do much more in Bash than we already do because we need to do mounts in the same process we set the namespaces, in children necessary privileges are already gone. I'm not completely sure about this but I remember that when I tried to write this in Bash completely long time ago (using for setting up namespaces mounts and chroot were a problem.
How about using this one?
bind mounts, sysfs, tmpfs and procfs should be
I can confirm that these mounts are possible from using unprivileged lxc containers. But you cannot bind mount something from the host this way, because it needs to be done after . UPDATE: ok even that should be possible if the correct order is maintained: unshare -mount -chroot.
Oh, I should look at it! cc in case he's interested in this thread. I think that checks if the user is root -- that's why this doesn't work. This means that we need to call by ourselves... (I was going to hit "Comment" but you were faster ~_^) I expect that LXC containers do user maps such that you have UID 0 in new userns -- we, however, need to retain user uid.
why do we have to retain user id?
Multiple user apps use uid and username for their purposes -- we don't want to lie to them. I can't give a complete example (I remember that Steam breaks) but for example we have directories which apps can find based on uid.
I have another suggestion: the Go programming language. Bear in mind that I'm generally not a super big fan of Go (in fact, while I use Go extensively at work, I generally use Haskell for my personal projects); however, I think that a higher level, simple (in terms of specification) language would be conducive to maintenance and further development. The binaries should be pretty small, and the closure should be pretty small, too. I might give that a go (no pun intended) and see what we think.
Several possible issues: need native and then before any calls to pthreads (or you'll get or something close); I remember that Go has a runtime so there may be problems; need several syscalls which may not be readily available, namely , and others. In Ruby I import them from libc dynamically and redefine constants from C by hand, but doing this (especially redefining constants) is one of the reasons I want to move from Ruby in the first place. However these are only potential problems -- I don't know if they actually exist! I'm actually interested in how this turns out.
You cannot use clone() properly because of the language runtime. That's why docker uses a little C for that job.
Ah, you must be referring to this from : I'll need to give that a thorough reading before I understand why the runtime gets in the way (unless, perhaps, you have an explanation of why/how pthreads mucks things up).
Oh, I'm guessing that's probably stuff like this: Though, if there are other details, I'd love to hear them :smile:.
If you refer to my remark about fork and pthreads, it's actually 's limitation. You can look at how I workaround this in Ruby by calling imported instead of Ruby's builtin. You will know if you encounter it -- will just fail. I think the best way to find out is with an experiment. (notice that I don't know about Go runtime and haven't even used Go before, so, as I underline again, those might be non-issues)
Interesting. I referred to the , but I don't see any mention of failure when used with pthreads. I don't doubt you; I'd just like to know how all this stuff works.
No problem even if these were doubts ~^. From man page:
Ah, dunno why I didn't try reading the man page -- thanks for pointing that out :wink:.
Anybody done any more work on this? Also, this should probably be tagged with security, due to
a rewrite in a different language will not solve your grsecurity problems. I also do not see how the rewrite discussed here is related to security.
Anything related to grsecurity is security-related. A rewrite into a compiled language means that a setuid wrapper can be created, which means I don't have to run shit as root.
You can drop your privileges via right after you enter the environment as -- it's less convenient but you get roughly what you want.

mkdir -p $out/bin cat <<EOF >$out/bin/${name} #! ${stdenv.shell} <del> ${lib.optionalString (extraBindMounts != []) ''export CHROOTENV_EXTRA_BINDS="${lib.concatStringsSep ":" extraBindMounts}:$CHROOTENV_EXTRA_BINDS"''} exec ${chroot-user} ${init runScript} "$(pwd)" "$@" </del> <ins> exec ${chrootenv} ${init runScript} "$(pwd)" "$@" </ins> EOF chmod +x $out/bin/${name} ${extraInstallCommands}


Question:
Steps to reproduce the behavior: build -L 'nixpkgs#curlie' <details</detailsNot a go developer. I think the issue is the same as . That requires a fix from upstream; I don't know whether this is the same, though, and my attempts to patch the build (and thus demonstrate it needs an upstream fix) have been unsuccessful. I used with the following patch. This resulted in the following error. I tried vendoring the derivation and adding the call to (using ) but at this point I hit the time limit I'd set to investigate this. Please run and paste the result.
You need to update vendorSha256, too. IF you get it working please create a PR.

<ins> diff --git a/go.mod b/go.mod index 660463a..5249458 100644 --- a/go.mod +++ b/go.mod @@ -2,7 +2,7 @@ module github.com/rs/curlie require ( golang.org/x/crypto v0.0.0-20180524125353-159ae71589f3 -	golang.org/x/sys v0.0.0-20191026070338-33540a1f6037 +	golang.org/x/sys v0.0.0-20211110154304-99a53858aa08 ) go 1.13 </ins>


Question:
Steps to reproduce the behavior: build -L 'nixpkgs#curlie' <details</detailsNot a go developer. I think the issue is the same as . That requires a fix from upstream; I don't know whether this is the same, though, and my attempts to patch the build (and thus demonstrate it needs an upstream fix) have been unsuccessful. I used with the following patch. This resulted in the following error. I tried vendoring the derivation and adding the call to (using ) but at this point I hit the time limit I'd set to investigate this. Please run and paste the result.
You need to update vendorSha256, too. IF you get it working please create a PR.

hash = "sha256-3EKxuEpFm+lp2myMfymYYY9boSXGOF2iAdjtGKnjJK0="; }; <del> vendorSha256 = "sha256-tYZtnD7RUurhl8yccXlTIvOxybBJITM+it1ollYJ1OI="; </del> <ins> patches = [ ./bump-golang-x-sys.patch ]; vendorSha256 = "sha256-VsPdMUfS4UVem6uJgFISfFHQEKtIumDQktHQFPC1muc="; </ins> ldflags = [ "-s" "-w" "-X main.version=${version}" ];


Question:
In GNOME keyboard shortcut settings, the list of categories based on and on my own experience with GNOME on other distros should be: Launchers Navigation Screenshots Sound and Media System Typing Universal Access Windows However, only the following categories are available: Launchers Screenshots Sound and Media System Typing Universal Access So I'm missing Navigation and Windows. Install gnome package and use GNOME. Open keyboard settings (press Super, type "keyboard", choose Keyboard). See the list of categories on the left panel. System: (NixOS: , Ubuntu/Fedora: , ...)Nix version: (run )Nixpkgs version: (run )
I am affected too. Moreover doesn't lock the screen.
I got that, too. Seems like that might be .
Another possible source of not working (if you're using GDM):
Apparently the Control Center derivation only provides some keybindings: the others are part of other packages like GNOME Shell or GPaste. The Control Center loads the bindings , basically using to locate them. But even explicitly passing the path does not make the Windows section appear – though, strace confirms the file being read. Edit: Nevermind, it looks like the navigation and windows keybindings come from .
Hey, have you somehow managed to get it to work using ? (Not quite sure how to interpret your edit). I tried messing around with that but so far I’ve only been able to break :
Try . The error you are seeing is caused by missing GNOME shell SCHEMAS, which will most likely be in the current variable.
It looks like the error I was seeing was related to fish shell not having setup properly and was failing even if I didn’t attempt to change anything. I switched to bash and that particular problem disappeared, however I am now getting a different error message: However, this schema seems to exist in mutter, so I sadly have no idea what is going on here:
Right, for that you also need to add share/gsettings/mutter-3.28.0 or something like that.
Thanks a ton! I finally got it to work using that!
I was able to get it to work using .
The mutter keybindings are not available in control center in NixOS when . Explicitly adding mutter to fixes it. Should mutter perhaps be to ?
I think adding it to dependencies of g-c-c is more in line with Nix. We can do it after we merge 3.32.

, gtk3, glib, glib-networking, gsettings-desktop-schemas , gnome-desktop, gnome-settings-daemon, gnome-online-accounts , vino, gnome-bluetooth, tracker, adwaita-icon-theme <del> , udisks2, gsound, libhandy, cups }: </del> <ins> , udisks2, gsound, libhandy, cups, mutter }: </ins> stdenv.mkDerivation rec { pname = "gnome-control-center";


Question:
In GNOME keyboard shortcut settings, the list of categories based on and on my own experience with GNOME on other distros should be: Launchers Navigation Screenshots Sound and Media System Typing Universal Access Windows However, only the following categories are available: Launchers Screenshots Sound and Media System Typing Universal Access So I'm missing Navigation and Windows. Install gnome package and use GNOME. Open keyboard settings (press Super, type "keyboard", choose Keyboard). See the list of categories on the left panel. System: (NixOS: , Ubuntu/Fedora: , ...)Nix version: (run )Nixpkgs version: (run )
I am affected too. Moreover doesn't lock the screen.
I got that, too. Seems like that might be .
Another possible source of not working (if you're using GDM):
Apparently the Control Center derivation only provides some keybindings: the others are part of other packages like GNOME Shell or GPaste. The Control Center loads the bindings , basically using to locate them. But even explicitly passing the path does not make the Windows section appear – though, strace confirms the file being read. Edit: Nevermind, it looks like the navigation and windows keybindings come from .
Hey, have you somehow managed to get it to work using ? (Not quite sure how to interpret your edit). I tried messing around with that but so far I’ve only been able to break :
Try . The error you are seeing is caused by missing GNOME shell SCHEMAS, which will most likely be in the current variable.
It looks like the error I was seeing was related to fish shell not having setup properly and was failing even if I didn’t attempt to change anything. I switched to bash and that particular problem disappeared, however I am now getting a different error message: However, this schema seems to exist in mutter, so I sadly have no idea what is going on here:
Right, for that you also need to add share/gsettings/mutter-3.28.0 or something like that.
Thanks a ton! I finally got it to work using that!
I was able to get it to work using .
The mutter keybindings are not available in control center in NixOS when . Explicitly adding mutter to fixes it. Should mutter perhaps be to ?
I think adding it to dependencies of g-c-c is more in line with Nix. We can do it after we merge 3.32.

# Thumbnailers (for setting user profile pictures) --prefix XDG_DATA_DIRS : "${gdk_pixbuf}/share" --prefix XDG_DATA_DIRS : "${librsvg}/share" <ins> # WM keyboard shortcuts --prefix XDG_DATA_DIRS : "${mutter}/share" </ins> ) for i in $out/share/applications/*; do substituteInPlace $i --replace "Exec=gnome-control-center" "Exec=$out/bin/gnome-control-center"


Question: On current , (4.2.4) group voice chat will be stuck on "connecting" forever, while private group voice works. This issue exists when connecting from different countries, using different account, with or without proxy, so it seems not really a "connection issue". a voice chat in a private group. it stuck on "connecting" phase forever. Successfully starts or joins a voice chat. chat and live stream are broken. (one to one) voice chat works without issues. 's version of telegram works. (Its font is broken though) Please run and paste the result.

{ lib, stdenv, fetchFromGitHub , pkg-config, cmake, ninja, yasm <del> , libjpeg, openssl, libopus, ffmpeg, alsa-lib, libpulseaudio, protobuf </del> <ins> , libjpeg, openssl_1_1, libopus, ffmpeg, alsa-lib, libpulseaudio, protobuf </ins> , openh264, usrsctp, libevent, libvpx , libX11, libXtst, libXcomposite, libXdamage, libXext, libXrender, libXrandr, libXi , glib, abseil-cpp, pcre, util-linuxMinimal, libselinux, libsepol, pipewire


Question: On current , (4.2.4) group voice chat will be stuck on "connecting" forever, while private group voice works. This issue exists when connecting from different countries, using different account, with or without proxy, so it seems not really a "connection issue". a voice chat in a private group. it stuck on "connecting" phase forever. Successfully starts or joins a voice chat. chat and live stream are broken. (one to one) voice chat works without issues. 's version of telegram works. (Its font is broken though) Please run and paste the result.

nativeBuildInputs = [ pkg-config cmake ninja yasm ]; buildInputs = [ <del> libjpeg openssl libopus ffmpeg alsa-lib libpulseaudio protobuf </del> <ins> libjpeg libopus ffmpeg alsa-lib libpulseaudio protobuf </ins> openh264 usrsctp libevent libvpx libX11 libXtst libXcomposite libXdamage libXext libXrender libXrandr libXi glib abseil-cpp pcre util-linuxMinimal libselinux libsepol pipewire


Question: On current , (4.2.4) group voice chat will be stuck on "connecting" forever, while private group voice works. This issue exists when connecting from different countries, using different account, with or without proxy, so it seems not really a "connection issue". a voice chat in a private group. it stuck on "connecting" phase forever. Successfully starts or joins a voice chat. chat and live stream are broken. (one to one) voice chat works without issues. 's version of telegram works. (Its font is broken though) Please run and paste the result.

propagatedBuildInputs = [ # Required for linking downstream binaries. <del> abseil-cpp openh264 usrsctp libevent libvpx </del> <ins> abseil-cpp openh264 usrsctp libevent libvpx openssl_1_1 </ins> ]; meta = with lib; {


Question:
Try building
Just ran into the same problem when updating my system flake. For bisecting purposes, nixpkgs was my previous (working) configuration. EDIT: bisection in progress, have to do some large builds now:
Excerpt from : which seems to be the change that breaks , so we probably need to file an upstream issue.
As a workaround, something like this should work:
Note that the downgrade would undo some security fixes; see PR ... which is also why we backported this problem to 22.05.
I see...I'll wait to re-enable qtile then
Depending on how much value you place on the failing test, something like this worked for me: Modifying the package in a general overlay triggered huge rebuilds for me, so I've just replaced it inside my derivation, which is what pulls in in my system configuration.
How would you modify the package with a general overlay? Something like this didn't work for me:
This global overlay works for me, without annoying rebuilds: Note, I'm using and this is imported in . I don't know if you can use it without modifications otherwise.
I have a similar setup, I have (minus the let bindings I have in my config): So I don't see the difference between our configs...
Somehow, the overlay proposed by worked. This reaches about the limits of my Nix knowledge, but maybe is required instead of simply ? Is the only difference I can notice.

]; # test_peer_interface hits a timeout <ins> # test_tcp_connection_with_forwarding fails due to dbus # creating unix socket anyway on v1.14.4 </ins> checkPhase = '' dbus-run-session --config-file=${dbus.daemon}/share/dbus-1/session.conf  ${python.interpreter} -m pytest -sv --cov=dbus_next  <del> -k "not test_peer_interface" </del> <ins> -k "not test_peer_interface and not test_tcp_connection_with_forwarding" </ins> ''; meta = with lib; {


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

</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


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

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


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

] 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 {


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

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


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

} ]; <ins> environment.systemPackages = [ mastodonTootctl ]; </ins> systemd.services.mastodon-init-dirs = { script = '' umask 077


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

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;


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

# Simple check tootctl commands # Check Mastodon version <del> server.succeed("su - mastodon -s /bin/sh -c 'mastodon-env tootctl version' | grep '${pkgs.mastodon.version}'") </del> <ins> server.succeed("mastodon-tootctl version | grep '${pkgs.mastodon.version}'") </ins> # Manage accounts <del> server.succeed("su - mastodon -s /bin/sh -c 'mastodon-env tootctl email_domain_blocks add example.com'") server.succeed("su - mastodon -s /bin/sh -c 'mastodon-env tootctl email_domain_blocks list' | grep 'example.com'") server.fail("su - mastodon -s /bin/sh -c 'mastodon-env tootctl email_domain_blocks list' | grep 'mastodon.local'") server.fail("su - mastodon -s /bin/sh -c 'mastodon-env tootctl accounts create alice --email=alice@example.com'") server.succeed("su - mastodon -s /bin/sh -c 'mastodon-env tootctl email_domain_blocks remove example.com'") server.succeed("su - mastodon -s /bin/sh -c 'mastodon-env tootctl accounts create bob --email=bob@example.com'") server.succeed("su - mastodon -s /bin/sh -c 'mastodon-env tootctl accounts approve bob'") server.succeed("su - mastodon -s /bin/sh -c 'mastodon-env tootctl accounts delete bob'") </del> <ins> server.succeed("mastodon-tootctl email_domain_blocks add example.com") server.succeed("mastodon-tootctl email_domain_blocks list | grep example.com") server.fail("mastodon-tootctl email_domain_blocks list | grep mastodon.local") server.fail("mastodon-tootctl accounts create alice --email=alice@example.com") server.succeed("mastodon-tootctl email_domain_blocks remove example.com") server.succeed("mastodon-tootctl accounts create bob --email=bob@example.com") server.succeed("mastodon-tootctl accounts approve bob") server.succeed("mastodon-tootctl accounts delete bob") </ins> # Manage IP access <del> server.succeed("su - mastodon -s /bin/sh -c 'mastodon-env tootctl ip_blocks add 192.168.0.0/16 --severity=no_access'") server.succeed("su - mastodon -s /bin/sh -c 'mastodon-env tootctl ip_blocks export' | grep '192.168.0.0/16'") server.fail("su - mastodon -s /bin/sh -c 'mastodon-env tootctl ip_blocks export' | grep '172.16.0.0/16'") </del> <ins> server.succeed("mastodon-tootctl ip_blocks add 192.168.0.0/16 --severity=no_access") server.succeed("mastodon-tootctl ip_blocks export | grep 192.168.0.0/16") server.fail("mastodon-tootctl ip_blocks export | grep 172.16.0.0/16") </ins> client.fail("curl --fail https://mastodon.local/about") <del> server.succeed("su - mastodon -s /bin/sh -c 'mastodon-env tootctl ip_blocks remove 192.168.0.0/16'") </del> <ins> server.succeed("mastodon-tootctl ip_blocks remove 192.168.0.0/16") </ins> client.succeed("curl --fail https://mastodon.local/about") server.shutdown()


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

, stdenv , fetchurl , appimageTools <ins> , appimage-run </ins> , makeWrapper <del> , electron </del> , git }:


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

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


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

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


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

# Darwin , gmp , libiconv <ins> , qemu </ins> , Carbon , AppKit


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

'' + 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


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

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


Question: To reproduce, here is an example: The related code is at Some nice to have: As suggested  should be something that can be accessible by everything and we are likely going to put our "" there and next we are going to import in basically every file. Adding to in is probably not a good idea since this is a desktop shell package you will end up having this variable everywhere, I imagine a treewide will be likely needed.

python3.pkgs.buildPythonApplication rec { pname = "sticky"; <del> version = "1.14"; </del> <ins> version = "1.16"; </ins> format = "other"; src = fetchFromGitHub { owner = "linuxmint"; repo = pname; rev = version; <del> hash = "sha256-7UZbCbzQ1ZrSzxTUdbA+wsH3p27qj/c/cM4GY/kzG6E="; </del> <ins> hash = "sha256-+opzjvSdGwwn1imNzSsfD9rfs4naSXzcMBJRPhKW2WM="; </ins> }; postPatch = ''


Question: To reproduce, here is an example: The related code is at Some nice to have: As suggested  should be something that can be accessible by everything and we are likely going to put our "" there and next we are going to import in basically every file. Adding to in is probably not a good idea since this is a desktop shell package you will end up having this variable everywhere, I imagine a treewide will be likely needed.

stdenv.mkDerivation rec { pname = "bulky"; <del> version = "2.8"; </del> <ins> version = "2.9"; </ins> src = fetchFromGitHub { owner = "linuxmint"; repo = "bulky"; rev = version; <del> hash = "sha256-DZjX4xPyA30TTyOX+VyGSY/FWPX2316CYImDWRma9r0="; </del> <ins> hash = "sha256-eCu7AgL4bzstu8vsqBJImRZm1qMVnnycuOShY5fB+C4="; </ins> }; nativeBuildInputs = [


Question: To reproduce, here is an example: The related code is at Some nice to have: As suggested  should be something that can be accessible by everything and we are likely going to put our "" there and next we are going to import in basically every file. Adding to in is probably not a good idea since this is a desktop shell package you will end up having this variable everywhere, I imagine a treewide will be likely needed.

-e s,/usr/share/locale,/run/current-system/sw/share/locale,g  {} + <del> sed "s|/usr/share/sounds|/run/current-system/sw/share/sounds|g" -i ./files/usr/share/cinnamon/cinnamon-settings/bin/SettingsWidgets.py sed "s|'python3'|'${pythonEnv.interpreter}'|g" -i ./files/usr/share/cinnamon/cinnamon-settings/bin/CinnamonGtkSettings.py sed "s|/usr/bin/cinnamon-screensaver-command|/run/current-system/sw/bin/cinnamon-screensaver-command|g"  -i ./files/usr/share/cinnamon/applets/menu@cinnamon.org/applet.js -i ./files/usr/share/cinnamon/applets/user@cinnamon.org/applet.js sed "s|"/usr/lib"|"${cinnamon-control-center}/lib"|g" -i ./files/usr/share/cinnamon/cinnamon-settings/bin/capi.py sed 's|"lspci"|"${pciutils}/bin/lspci"|g' -i ./files/usr/share/cinnamon/cinnamon-settings/modules/cs_info.py </del> <ins> # All optional and may introduce circular dependency. find ./files/usr/share/cinnamon/applets -type f -exec sed -i  -e '/^#/!s,/usr/bin,/run/current-system/sw/bin,g'  {} + </ins> <del> sed "s| cinnamon-session| ${cinnamon-session}/bin/cinnamon-session|g" -i ./files/usr/bin/cinnamon-session-cinnamon  -i ./files/usr/bin/cinnamon-session-cinnamon2d </del> <ins> pushd ./files/usr/share/cinnamon/cinnamon-settings substituteInPlace ./bin/capi.py                     --replace '"/usr/lib"' '"${cinnamon-control-center}/lib"' substituteInPlace ./bin/CinnamonGtkSettings.py      --replace "'python3'" "'${pythonEnv.interpreter}'" substituteInPlace ./bin/SettingsWidgets.py          --replace "/usr/share/sounds" "/run/current-system/sw/share/sounds" substituteInPlace ./bin/Spices.py                   --replace "msgfmt" "${gettext}/bin/msgfmt" substituteInPlace ./modules/cs_info.py              --replace "lspci" "${pciutils}/bin/lspci" popd </ins> <del> sed "s|msgfmt|${gettext}/bin/msgfmt|g" -i ./files/usr/share/cinnamon/cinnamon-settings/bin/Spices.py </del> <ins> sed "s| cinnamon-session| ${cinnamon-session}/bin/cinnamon-session|g" -i ./files/usr/bin/cinnamon-session-{cinnamon,cinnamon2d} </ins> patchShebangs src/data-to-c.pl '';


Question: To reproduce, here is an example: The related code is at Some nice to have: As suggested  should be something that can be accessible by everything and we are likely going to put our "" there and next we are going to import in basically every file. Adding to in is probably not a good idea since this is a desktop shell package you will end up having this variable everywhere, I imagine a treewide will be likely needed.

--prefix XDG_DATA_DIRS : "${gnome.caribou}/share" ) <ins> buildPythonPath "$out ${python3.pkgs.xapp}" # https://github.com/NixOS/nixpkgs/issues/200397 patchPythonScript $out/bin/cinnamon-spice-updater </ins> # https://github.com/NixOS/nixpkgs/issues/129946 <del> buildPythonPath "${python3.pkgs.xapp}" </del> patchPythonScript $out/share/cinnamon/cinnamon-desktop-editor/cinnamon-desktop-editor.py <ins> # Called as `pkexec cinnamon-settings-users.py`. wrapGApp $out/share/cinnamon/cinnamon-settings-users/cinnamon-settings-users.py </ins> ''; passthru = {


Question: To reproduce, here is an example: The related code is at Some nice to have: As suggested  should be something that can be accessible by everything and we are likely going to put our "" there and next we are going to import in basically every file. Adding to in is probably not a good idea since this is a desktop shell package you will end up having this variable everywhere, I imagine a treewide will be likely needed.

stdenvNoCC.mkDerivation rec { pname = "mint-cursor-themes"; <del> version = "1.0.1"; </del> <ins> version = "1.0.2"; </ins> src = fetchFromGitHub { owner = "linuxmint"; repo = pname; # They don't really do tags, this is just a named commit. <del> rev = "e17f8a4620827235dabbe5221bd0ee8c44dad0d5"; hash = "sha256-yLUmIVh884uDVkNil7qxf6t/gykipzBvPgzwmY3zvQk="; </del> <ins> rev = "d2c1428b499a347c291dafb13c89699fdbdd4be7"; hash = "sha256-i2Wf+OKwal9G5hkcAdmGSgX6txu1AHajqqPJdhpJoA0="; </ins> }; installPhase = ''


Question: To reproduce, here is an example: The related code is at Some nice to have: As suggested  should be something that can be accessible by everything and we are likely going to put our "" there and next we are going to import in basically every file. Adding to in is probably not a good idea since this is a desktop shell package you will end up having this variable everywhere, I imagine a treewide will be likely needed.

in stdenv.mkDerivation rec { pname = "warpinator"; <del> version = "1.6.2"; </del> <ins> version = "1.6.3"; </ins> src = fetchFromGitHub { owner = "linuxmint"; repo = pname; rev = version; <del> hash = "sha256-crGW1FBfTEiKqx981EzG414we4icyBv/keGtMlr8UFc="; </del> <ins> hash = "sha256-iCq2cwZgsq5/bJqjYuZ6dZLqz2nIpgHCrIQeMVxJNXY="; </ins> }; nativeBuildInputs = [


Question: To reproduce, here is an example: The related code is at Some nice to have: As suggested  should be something that can be accessible by everything and we are likely going to put our "" there and next we are going to import in basically every file. Adding to in is probably not a good idea since this is a desktop shell package you will end up having this variable everywhere, I imagine a treewide will be likely needed.

# Patch pastebin & inxi location sed "s|/usr/bin/pastebin|$out/bin/pastebin|" -i scripts/upload-system-info sed "s|'inxi'|'${inxi}/bin/inxi'|" -i scripts/upload-system-info <del> # Patch gtk3 module target dir substituteInPlace libxapp/meson.build  --replace "gtk3_dep.get_pkgconfig_variable('libdir')" "'$out'" </del> ''; <ins> # Fix gtk3 module target dir. Proper upstream solution should be using define_variable. PKG_CONFIG_GTK__3_0_LIBDIR = "${placeholder "out"}/lib"; </ins> meta = with lib; { homepage = "https://github.com/linuxmint/xapp"; description = "Cross-desktop libraries and common resources";


Question:
When running , I get Restarting the system did not help. Steps to reproduce the behavior: The program should launch without crashing. If applicable, add screenshots to help explain your problem.
Hello Thanks for reporting this issue, and sorry for breaking the nvtop package! I made a pull-request to fix nvtop: What do you think about this fix?
Thank you for your fast reaction ! The PR looks good to me. I hope it will get merged soon :)

, cudatoolkit , libdrm , ncurses <ins> , nvtop , testers , udev </ins> , addOpenGLRunpath , amd ? true , nvidia ? true <del> , udev </del> }: let pname-suffix = if amd && nvidia then "" else if amd then "-amd" else "-nvidia"; nvidia-postFixup = "addOpenGLRunpath $out/bin/nvtop"; <del> libPath = lib.makeLibraryPath [ libdrm ncurses ]; </del> <ins> libPath = lib.makeLibraryPath [ libdrm ncurses udev ]; </ins> amd-postFixup = '' patchelf  --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)"


Question:
When running , I get Restarting the system did not help. Steps to reproduce the behavior: The program should launch without crashing. If applicable, add screenshots to help explain your problem.
Hello Thanks for reporting this issue, and sorry for breaking the nvtop package! I made a pull-request to fix nvtop: What do you think about this fix?
Thank you for your fast reaction ! The PR looks good to me. I hope it will get merged soon :)

cmakeFlags = with lib; [ "-DCMAKE_BUILD_TYPE=Release" "-DBUILD_TESTING=ON" <ins> "-DUSE_LIBUDEV_OVER_LIBSYSTEMD=ON" </ins> ] ++ optional nvidia "-DNVML_INCLUDE_DIRS=${cudatoolkit}/include" ++ optional nvidia "-DNVML_LIBRARIES=${cudatoolkit}/targets/x86_64-linux/lib/stubs/libnvidia-ml.so" ++ optional (!amd) "-DAMDGPU_SUPPORT=OFF"


Question:
When running , I get Restarting the system did not help. Steps to reproduce the behavior: The program should launch without crashing. If applicable, add screenshots to help explain your problem.
Hello Thanks for reporting this issue, and sorry for breaking the nvtop package! I made a pull-request to fix nvtop: What do you think about this fix?
Thank you for your fast reaction ! The PR looks good to me. I hope it will get merged soon :)

doCheck = true; <ins> passthru = { tests.version = testers.testVersion { inherit version; package = nvtop; command = "nvtop --version"; }; }; </ins> meta = with lib; { description = "A (h)top like task monitor for AMD, Intel and NVIDIA GPUs"; longDescription = ''


Question:
pam_p11 causes login segfault in NixOS 22.11. GDM and Gnome lock screen are also affected. Steps to reproduce the behavior: to log in on the console or run `: Bug was not present in 22.05.
Reverting does not help.
Fixed by: Can someone with commit access apply this patch?
Can you open a pull request with that patch?
I hope that NixOS can be unbureaucratic enough that PRs are not required for this kind of patch.
It's generally preferred to do basically everything through PRs, so some basic CI checks can run & maintainers can be pinged automatically. We can just self-merge though. I created containing your diff and adding a comment for explanation.
This seems to be whats causing my 22.11-beta19 install on an Alder Lake 12700H (no gpu) to not boot into GDM. This is a pretty heinous issue that should be tested for. The graphical installer doesn't install Vim, WPA_Supplicant or anything useful for figuring out what went wrong, despite having Vim and WPA Supplicant available on the installation media/calamares.
Well I just did - you're welcome. That's what beta releases are for, aren't they?

enableParallelBuilding = true; <ins> passthru = { inherit openssl; }; </ins> meta = with lib; { description = "Small layer on top of PKCS#11 API to make PKCS#11 implementations easier"; homepage = "https://github.com/OpenSC/libp11";


Question:
pam_p11 causes login segfault in NixOS 22.11. GDM and Gnome lock screen are also affected. Steps to reproduce the behavior: to log in on the console or run `: Bug was not present in 22.05.
Reverting does not help.
Fixed by: Can someone with commit access apply this patch?
Can you open a pull request with that patch?
I hope that NixOS can be unbureaucratic enough that PRs are not required for this kind of patch.
It's generally preferred to do basically everything through PRs, so some basic CI checks can run & maintainers can be pinged automatically. We can just self-merge though. I created containing your diff and adding a comment for explanation.
This seems to be whats causing my 22.11-beta19 install on an Alder Lake 12700H (no gpu) to not boot into GDM. This is a pretty heinous issue that should be tested for. The graphical installer doesn't install Vim, WPA_Supplicant or anything useful for figuring out what went wrong, despite having Vim and WPA Supplicant available on the installation media/calamares.
Well I just did - you're welcome. That's what beta releases are for, aren't they?

<del> { lib, stdenv, fetchFromGitHub, autoreconfHook, pkg-config, openssl, libp11, pam, libintl }: </del> <ins> { lib, stdenv, fetchFromGitHub, autoreconfHook, pkg-config, libp11, pam, libintl }: </ins> stdenv.mkDerivation rec { pname = "pam_p11";


Question:
pam_p11 causes login segfault in NixOS 22.11. GDM and Gnome lock screen are also affected. Steps to reproduce the behavior: to log in on the console or run `: Bug was not present in 22.05.
Reverting does not help.
Fixed by: Can someone with commit access apply this patch?
Can you open a pull request with that patch?
I hope that NixOS can be unbureaucratic enough that PRs are not required for this kind of patch.
It's generally preferred to do basically everything through PRs, so some basic CI checks can run & maintainers can be pinged automatically. We can just self-merge though. I created containing your diff and adding a comment for explanation.
This seems to be whats causing my 22.11-beta19 install on an Alder Lake 12700H (no gpu) to not boot into GDM. This is a pretty heinous issue that should be tested for. The graphical installer doesn't install Vim, WPA_Supplicant or anything useful for figuring out what went wrong, despite having Vim and WPA Supplicant available on the installation media/calamares.
Well I just did - you're welcome. That's what beta releases are for, aren't they?

}; nativeBuildInputs = [ autoreconfHook pkg-config ]; <del> buildInputs = [ pam openssl libp11 ] </del> <ins> buildInputs = [ pam libp11.passthru.openssl libp11 ] </ins> ++ lib.optionals stdenv.isDarwin [ libintl ]; meta = with lib; {


Question:
pam_p11 causes login segfault in NixOS 22.11. GDM and Gnome lock screen are also affected. Steps to reproduce the behavior: to log in on the console or run `: Bug was not present in 22.05.
Reverting does not help.
Fixed by: Can someone with commit access apply this patch?
Can you open a pull request with that patch?
I hope that NixOS can be unbureaucratic enough that PRs are not required for this kind of patch.
It's generally preferred to do basically everything through PRs, so some basic CI checks can run & maintainers can be pinged automatically. We can just self-merge though. I created containing your diff and adding a comment for explanation.
This seems to be whats causing my 22.11-beta19 install on an Alder Lake 12700H (no gpu) to not boot into GDM. This is a pretty heinous issue that should be tested for. The graphical installer doesn't install Vim, WPA_Supplicant or anything useful for figuring out what went wrong, despite having Vim and WPA Supplicant available on the installation media/calamares.
Well I just did - you're welcome. That's what beta releases are for, aren't they?

++ lib.optionals stdenv.hostPlatform.isMusl [ argp-standalone ] ++ lib.optionals withJitterEntropy [ jitterentropy ] ++ lib.optionals withNistBeacon    [ curl jansson libxml2 ] <del> ++ lib.optionals withPkcs11        [ libp11 openssl ] </del> <ins> ++ lib.optionals withPkcs11        [ libp11 libp11.passthru.openssl ] </ins> ++ lib.optionals withRtlsdr        [ librtlsdr ]; enableParallelBuilding = true;


Question:
pam_p11 causes login segfault in NixOS 22.11. GDM and Gnome lock screen are also affected. Steps to reproduce the behavior: to log in on the console or run `: Bug was not present in 22.05.
Reverting does not help.
Fixed by: Can someone with commit access apply this patch?
Can you open a pull request with that patch?
I hope that NixOS can be unbureaucratic enough that PRs are not required for this kind of patch.
It's generally preferred to do basically everything through PRs, so some basic CI checks can run & maintainers can be pinged automatically. We can just self-merge though. I created containing your diff and adding a comment for explanation.
This seems to be whats causing my 22.11-beta19 install on an Alder Lake 12700H (no gpu) to not boot into GDM. This is a pretty heinous issue that should be tested for. The graphical installer doesn't install Vim, WPA_Supplicant or anything useful for figuring out what went wrong, despite having Vim and WPA Supplicant available on the installation media/calamares.
Well I just did - you're welcome. That's what beta releases are for, aren't they?

libow = callPackage ../development/libraries/libow { }; <del> libp11 = callPackage ../development/libraries/libp11 { }; </del> <ins> libp11 = callPackage ../development/libraries/libp11 { openssl = openssl_1_1; }; </ins> libpam-wrapper = callPackage ../development/libraries/libpam-wrapper { };


Question:
pam_p11 causes login segfault in NixOS 22.11. GDM and Gnome lock screen are also affected. Steps to reproduce the behavior: to log in on the console or run `: Bug was not present in 22.05.
Reverting does not help.
Fixed by: Can someone with commit access apply this patch?
Can you open a pull request with that patch?
I hope that NixOS can be unbureaucratic enough that PRs are not required for this kind of patch.
It's generally preferred to do basically everything through PRs, so some basic CI checks can run & maintainers can be pinged automatically. We can just self-merge though. I created containing your diff and adding a comment for explanation.
This seems to be whats causing my 22.11-beta19 install on an Alder Lake 12700H (no gpu) to not boot into GDM. This is a pretty heinous issue that should be tested for. The graphical installer doesn't install Vim, WPA_Supplicant or anything useful for figuring out what went wrong, despite having Vim and WPA Supplicant available on the installation media/calamares.
Well I just did - you're welcome. That's what beta releases are for, aren't they?

pam_mysql = callPackage ../os-specific/linux/pam_mysql { }; <del> pam_p11 = callPackage ../os-specific/linux/pam_p11 { openssl = openssl_1_1; }; </del> <ins> pam_p11 = callPackage ../os-specific/linux/pam_p11 { }; </ins> pam_pgsql = callPackage ../os-specific/linux/pam_pgsql { };


Question:
i3 has been updated to 4.13. I attempted to update our derivation but they switched to and I don't know how that works :) If somebody could update i3, I would really appreciate that. /cc maintainers
FYI, for to work it is sufficient to add to the (see ).
Thanks :) I think with the main i3 the issue was that the needed to change and I did not know what to set them to.
Yes, and indeed the and are already included with the source distribution for , but I had to add the for .

{ fetchurl, stdenv, which, pkgconfig, makeWrapper, libxcb, xcbutilkeysyms <del> , xcbutil, xcbutilwm, libstartup_notification, libX11, pcre, libev, yajl , xcb-util-cursor, coreutils, perl, pango, perlPackages, libxkbcommon </del> <ins> , xcbutil, xcbutilwm, xcbutilxrm, libstartup_notification, libX11, pcre, libev , yajl, xcb-util-cursor, coreutils, perl, pango, perlPackages, libxkbcommon </ins> , xorgserver, xvfb_run, dmenu, i3status }: stdenv.mkDerivation rec { name = "i3-${version}"; <del> version = "4.12"; </del> <ins> version = "4.13"; </ins> src = fetchurl { url = "http://i3wm.org/downloads/${name}.tar.bz2"; <del> sha256 = "1d3q3lgpjbkmcwzjhp0dfr0jq847silcfg087slcnj95ikh1r7p1"; </del> <ins> sha256 = "12ngz32swh9n85xy0cz1lq16aqi9ys5hq19v589q9a97wn1k3hcl"; </ins> }; <ins> nativeBuildInputs = [ which pkgconfig makeWrapper ]; </ins> buildInputs = [ <del> which pkgconfig makeWrapper libxcb xcbutilkeysyms xcbutil xcbutilwm libxkbcommon </del> <ins> libxcb xcbutilkeysyms xcbutil xcbutilwm xcbutilxrm libxkbcommon </ins> libstartup_notification libX11 pcre libev yajl xcb-util-cursor perl pango perlPackages.AnyEventI3 perlPackages.X11XCB perlPackages.IPCRun perlPackages.ExtUtilsPkgConfig perlPackages.TestMore perlPackages.InlineC xorgserver xvfb_run ]; <ins> configureFlags = [ "--disable-builddir" ]; enableParallelBuilding = true; </ins> postPatch = '' patchShebangs . '';


Question:
i3 has been updated to 4.13. I attempted to update our derivation but they switched to and I don't know how that works :) If somebody could update i3, I would really appreciate that. /cc maintainers
FYI, for to work it is sufficient to add to the (see ).
Thanks :) I think with the main i3 the issue was that the needed to change and I did not know what to set them to.
Yes, and indeed the and are already included with the source distribution for , but I had to add the for .

! grep -q '^not ok' testcases/latest/complete-run.log ''; <del> configurePhase = "makeFlags=PREFIX=$out"; </del> postInstall = '' wrapProgram "$out/bin/i3-save-tree" --prefix PERL5LIB ":" "$PERL5LIB" <del> mkdir -p $out/man/man1 cp man/*.1 $out/man/man1 </del> for program in $out/bin/i3-sensible-*; do sed -i 's/which/command -v/' $program done


Question:
i3 has been updated to 4.13. I attempted to update our derivation but they switched to and I don't know how that works :) If somebody could update i3, I would really appreciate that. /cc maintainers
FYI, for to work it is sufficient to add to the (see ).
Thanks :) I think with the main i3 the issue was that the needed to change and I did not know what to set them to.
Yes, and indeed the and are already included with the source distribution for , but I had to add the for .

meta = with stdenv.lib; { description = "A tiling window manager"; homepage    = "http://i3wm.org"; <del> maintainers = with maintainers; [ garbas modulistic ]; </del> <ins> maintainers = with maintainers; [ garbas modulistic fpletz ]; </ins> license     = licenses.bsd3; platforms   = platforms.all;


Question:
The srb2 assets are outdated. Steps to reproduce the behaviour: the game or run the command while in game The that the assets are being downloaded from hasn't been updated since 2020
I just noticed this pr, but it seems to have gone dead 3 months ago
closing as I'm making a new issue

<ins> diff --git a/CMakeLists.txt b/CMakeLists.txt index 915912af5..f5c2cf9cc 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -91,11 +91,6 @@ if("${CMAKE_HOST_SYSTEM_NAME}" STREQUAL Windows) endif() endif() else() -	CPMAddPackage( -		NAME Ccache.cmake -		GITHUB_REPOSITORY TheLartians/Ccache.cmake -		VERSION 1.2 -	) endif() # Dependencies -- 2.40.1 </ins>


Question:
The srb2 assets are outdated. Steps to reproduce the behaviour: the game or run the command while in game The that the assets are being downloaded from hasn't been updated since 2020
I just noticed this pr, but it seems to have gone dead 3 months ago
closing as I'm making a new issue

, stdenv , fetchurl , fetchFromGitHub <del> , substituteAll </del> , cmake , curl , nasm


Question:
The srb2 assets are outdated. Steps to reproduce the behaviour: the game or run the command while in game The that the assets are being downloaded from hasn't been updated since 2020
I just noticed this pr, but it seems to have gone dead 3 months ago
closing as I'm making a new issue

, SDL2 , SDL2_mixer , zlib <ins> , unzip , makeWrapper , makeDesktopItem , copyDesktopItems </ins> }: <del> let assets_version = "2.2.5"; assets = fetchurl { url = "https://github.com/mazmazz/SRB2/releases/download/SRB2_assets_220/srb2-${assets_version}-assets.7z"; sha256 = "1m9xf3vraq9nipsi09cyvvfa4i37gzfxg970rnqfswd86z9v6v00"; }; assets_optional = fetchurl { url = "https://github.com/mazmazz/SRB2/releases/download/SRB2_assets_220/srb2-${assets_version}-optional-assets.7z"; sha256 = "1j29jrd0r1k2bb11wyyl6yv9b90s2i6jhrslnh77qkrhrwnwcdz4"; }; in stdenv.mkDerivation rec { </del> <ins> stdenv.mkDerivation (finalAttrs: { </ins> pname = "srb2"; <del> version = "2.2.10"; </del> <ins> version = "2.2.11"; </ins> src = fetchFromGitHub { owner = "STJr"; repo = "SRB2"; <del> rev = "SRB2_release_${version}"; sha256 = "03388n094d2yr5si6ngnggbqhm8b2l0s0qvfnkz49li9bd6a81gg"; </del> <ins> rev = "SRB2_release_${finalAttrs.version}"; hash = "sha256-tyiXivJWjNnL+4YynUV6k6iaMs8o9HkHrp+qFj2+qvQ="; </ins> }; nativeBuildInputs = [ cmake nasm p7zip <ins> makeWrapper copyDesktopItems </ins> ]; buildInputs = [


Question:
The srb2 assets are outdated. Steps to reproduce the behaviour: the game or run the command while in game The that the assets are being downloaded from hasn't been updated since 2020
I just noticed this pr, but it seems to have gone dead 3 months ago
closing as I'm making a new issue

zlib ]; <ins> assets = stdenv.mkDerivation { pname = "srb2-data"; version = finalAttrs.version; nativeBuildInputs = [ unzip ]; src = fetchurl { url = "https://github.com/STJr/SRB2/releases/download/SRB2_release_${finalAttrs.version}/SRB2-v${lib.replaceStrings ["."] [""] finalAttrs.version}-Full.zip"; hash = "sha256-KsJIkCczD/HyIwEy5dI3zsHbWFCMBaCoCHizfupFoWM="; }; sourceRoot = "."; installPhase = '' mkdir -p $out/share/srb2 cp -r *pk3 *dta *dat models/ $out/share/srb2/ ''; }; </ins> cmakeFlags = [ <del> "-DSRB2_ASSET_DIRECTORY=/build/source/assets" </del> <ins> "-DSRB2_ASSET_DIRECTORY=${finalAttrs.assets}/share/srb2" </ins> "-DGME_INCLUDE_DIR=${game-music-emu}/include" "-DOPENMPT_INCLUDE_DIR=${libopenmpt.dev}/include" "-DSDL2_MIXER_INCLUDE_DIR=${lib.getDev SDL2_mixer}/include/SDL2" <del> "-DSDL2_INCLUDE_DIR=${lib.getDev SDL2}/include/SDL2" </del> <ins> "-DSDL2_INCLUDE_DIR=${lib.getDev SDL2.dev}/include/SDL2" </ins> ]; patches = [ <del> ./wadlocation.patch </del> <ins> # Fix unknown command "CPMAddPackage" by not using Ccache.cmake ./cmake.patch </ins> ]; <del> postPatch = '' substituteInPlace src/sdl/i_system.c  --replace '@wadlocation@' $out ''; </del> <ins> desktopItems = [ (makeDesktopItem rec { name = "Sonic Robo Blast 2"; exec = finalAttrs.pname; icon = finalAttrs.pname; comment = finalAttrs.meta.description; desktopName = name; genericName = name; categories = [ "Game" ]; }) ]; </ins> <del> preConfigure = '' 7z x ${assets} -o"/build/source/assets" -aos 7z x ${assets_optional} -o"/build/source/assets" -aos ''; </del> <ins> installPhase = '' mkdir -p $out/bin $out/share/applications $out/share/pixmaps $out/share/icons copyDesktopItems cp ../srb2.png $out/share/pixmaps/. cp ../srb2.png $out/share/icons/. </ins> <del> postInstall = '' mkdir $out/bin mv $out/lsdlsrb2-${version} $out/bin/srb2 </del> <ins> cp bin/lsdlsrb2 $out/bin/srb2 wrapProgram $out/bin/srb2 --set SRB2WADDIR "${finalAttrs.assets}/share/srb2" </ins> ''; meta = with lib; {


Question:
The srb2 assets are outdated. Steps to reproduce the behaviour: the game or run the command while in game The that the assets are being downloaded from hasn't been updated since 2020
I just noticed this pr, but it seems to have gone dead 3 months ago
closing as I'm making a new issue

homepage = "https://www.srb2.org/"; platforms = platforms.linux; license = licenses.gpl2Plus; <del> maintainers = with maintainers; [ zeratax ]; </del> <ins> maintainers = with maintainers; [ zeratax donovanglover ]; </ins> }; <del> } </del> <ins> }) </ins>


Question:
The srb2 assets are outdated. Steps to reproduce the behaviour: the game or run the command while in game The that the assets are being downloaded from hasn't been updated since 2020
I just noticed this pr, but it seems to have gone dead 3 months ago
closing as I'm making a new issue

<del> diff --git a/src/sdl/i_system.c b/src/sdl/i_system.c index 10c0747bf..861f00728 100644 --- a/src/sdl/i_system.c +++ b/src/sdl/i_system.c @@ -145,13 +145,7 @@ int TimeFunction(int requested_frequency); // Locations for searching the srb2.pk3 #if defined (__unix__) || defined(__APPLE__) || defined (UNIXCOMMON) -#define DEFAULTWADLOCATION1 "/usr/local/share/games/SRB2" -#define DEFAULTWADLOCATION2 "/usr/local/games/SRB2" -#define DEFAULTWADLOCATION3 "/usr/share/games/SRB2" -#define DEFAULTWADLOCATION4 "/usr/games/SRB2" -#define DEFAULTSEARCHPATH1 "/usr/local/games" -#define DEFAULTSEARCHPATH2 "/usr/games" -#define DEFAULTSEARCHPATH3 "/usr/local" +#define DEFAULTWADLOCATION1 "@wadlocation@" #elif defined (_WIN32) #define DEFAULTWADLOCATION1 "c:gamessrb2" #define DEFAULTWADLOCATION2 "gamessrb2" @@ -2812,34 +2806,6 @@ static const char *locateWad(void) if (((envstr = I_GetEnv("SRB2WADDIR")) != NULL) && isWadPathOk(envstr)) return envstr; -#ifndef NOCWD -	I_OutputMsg(",."); -	// examine current dir -	strcpy(returnWadPath, "."); -	if (isWadPathOk(returnWadPath)) -		return NULL; -#endif - - -#ifdef CMAKECONFIG -#ifndef NDEBUG -	I_OutputMsg(","CMAKE_ASSETS_DIR); -	strcpy(returnWadPath, CMAKE_ASSETS_DIR); -	if (isWadPathOk(returnWadPath)) -	{ -		return returnWadPath; -	} -#endif -#endif - -#ifdef __APPLE__ -	OSX_GetResourcesPath(returnWadPath); -	I_OutputMsg(",%s", returnWadPath); -	if (isWadPathOk(returnWadPath)) -	{ -		return returnWadPath; -	} -#endif // examine default dirs #ifdef DEFAULTWADLOCATION1 @@ -2884,16 +2850,7 @@ static const char *locateWad(void) if (isWadPathOk(returnWadPath)) return returnWadPath; #endif -#ifndef NOHOME -	// find in $HOME -	I_OutputMsg(",HOME"); -	if ((envstr = I_GetEnv("HOME")) != NULL) -	{ -		WadPath = searchWad(envstr); -		if (WadPath) -			return WadPath; -	} -#endif + #ifdef DEFAULTSEARCHPATH1 // find in /usr/local I_OutputMsg(", in:"DEFAULTSEARCHPATH1); </del>


Question:
Specifically systems with AVX but without BMI2 Same as this debian bug: They solved it by pulling the latest stable 2.35 patches: ;a=history;f=sysdeps/x86_64;hb=refs/heads/release/2.35/master For NixOS, one workaround is to install a NixOS system to a usb drive with microcode updates enabled, and use that for the installation. This is because for this series of CPUs (Haswell, 3rd/4th gen) the BMI2 instructions are via a microcode update. Rebuilding the iso with this overlay also works, but this is a mass-rebuild: The diff is produced like this: Where corresponds to 2.35-220 and corresponds to 2.35-163 (our previous state).
It was attempted to update glibc to the latest stable patches in , but this led to some issues.
A temporary fix without rebuilds would be via , I suppose. EDIT: or 22.05 release in the meantime, as I expect it shouldn't be affected and it's still supported for a few weeks. Real fix (taking more time, etc.): most likely update glibc to latest 2.35.x and somehow resolve the regression (and possibly others), and then backport to 22.11 as well.
Redoing update as PR for now.
The glibc update is contained in and channels now.

<del> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=2d7ed98add14f75041499ac189696c9bd3d757fe --- a/Makeconfig +++ b/Makeconfig @@ -43,6 +43,22 @@ else $(error objdir must be defined by the build-directory Makefile) endif +# Did we request 'make -s' run? "yes" or "no". +# Starting from make-4.4 MAKEFLAGS now contains long +# options like '--shuffle'. To detect presence of 's' +# we pick first word with short options. Long options +# are guaranteed to come after whitespace. We use '-' +# prefix to always have a word before long options +# even if no short options were passed. +# Typical MAKEFLAGS values to watch for: +#   "rs --shuffle=42" (silent) +#   " --shuffle" (not silent) +ifeq ($(findstring s, $(firstword -$(MAKEFLAGS))),) +silent-make := no +else +silent-make := yes +endif + # Root of the sysdeps tree. sysdep_dir := $(..)sysdeps export sysdep_dir := $(sysdep_dir) @@ -917,7 +933,7 @@ endif # umpteen zillion filenames along with it (we use `...' instead) # but we don't want this echoing done when the user has said # he doesn't want to see commands echoed by using -s. -ifneq	"$(findstring s,$(MAKEFLAGS))" ""	# if -s +ifeq ($(silent-make),yes)			# if -s +cmdecho	:= echo >/dev/null else						# not -s +cmdecho	:= echo --- a/Makerules +++ b/Makerules @@ -794,7 +794,7 @@ endif # Maximize efficiency by minimizing the number of rules. .SUFFIXES:	# Clear the suffix list.  We don't use suffix rules. # Don't define any builtin rules. -MAKEFLAGS := $(MAKEFLAGS)r +MAKEFLAGS := $(MAKEFLAGS) -r # Generic rule for making directories. %/: @@ -811,7 +811,7 @@ MAKEFLAGS := $(MAKEFLAGS)r .PRECIOUS: $(foreach l,$(libtypes),$(patsubst %,$(common-objpfx)$l,c)) # Use the verbose option of ar and tar when not running silently. -ifeq	"$(findstring s,$(MAKEFLAGS))" ""	# if not -s +ifeq ($(silent-make),no)			# if not -s verbose := v else	   					# -s verbose	:= --- a/elf/rtld-Rules +++ b/elf/rtld-Rules @@ -52,7 +52,7 @@ $(objpfx)rtld-libc.a: $(foreach dir,$(rtld-subdirs), mv -f $@T $@ # Use the verbose option of ar and tar when not running silently. -ifeq	"$(findstring s,$(MAKEFLAGS))" ""	# if not -s +ifeq ($(silent-make),no)			# if not -s verbose := v else						# -s verbose	:= </del>