Question:
Commit from updated the default version of the GNU Privacy Guard a.k.a. GPG to version 2.1. Unfortunately, this update broke the gpg-related tests of , , apparently because there is some subtle change in the behavior of the GPG 1.x compatibility layer (git-annex relies on rather than using gpg2 directly). To remedy that issue, I fixed to use version 2.0 in . This is no good solution, unfortunately, because now people who rely on `gnupg1' end up having a version of GnuPG 2.0 in their profile that cannot talk to the gpg-agent from version 2.1, which happens to be the one that's installed in the system by default. In it's current state, gpg1 does not work reliably in NIxOS. To work around this issue, I would suggest that we revert to version 2.0 until we've had time to figure out what exactly has changed between versions 2.1 and 2.0 and why this affects .
FYI: Another thing I came across, due to a broken clawsmail pgp, was that the handling of gpg-agent differs from version 2.0 . GnuPG 2.1 do not use GPGAGENTINFO anymore. Instead it search for the gpg-agent socket in
For now at least, setting GPGAGENTINFO to $ seems to make claws-mail work.

in optional (driver != null) ({ inherit name; driverName = name; } // driver)); assertions = <del> [ { assertion = !(config.programs.ssh.startAgent && cfg.startGnuPGAgent); message = '' The OpenSSH agent and GnuPG agent cannot be started both. Please choose between ‘programs.ssh.startAgent’ and ‘services.xserver.startGnuPGAgent’. ''; } { assertion = config.security.polkit.enable; </del> <ins> [ { assertion = config.security.polkit.enable; </ins> message = "X11 requires Polkit to be enabled (‘security.polkit.enable = true’)."; } ];


Question:
Commit from updated the default version of the GNU Privacy Guard a.k.a. GPG to version 2.1. Unfortunately, this update broke the gpg-related tests of , , apparently because there is some subtle change in the behavior of the GPG 1.x compatibility layer (git-annex relies on rather than using gpg2 directly). To remedy that issue, I fixed to use version 2.0 in . This is no good solution, unfortunately, because now people who rely on `gnupg1' end up having a version of GnuPG 2.0 in their profile that cannot talk to the gpg-agent from version 2.1, which happens to be the one that's installed in the system by default. In it's current state, gpg1 does not work reliably in NIxOS. To work around this issue, I would suggest that we revert to version 2.0 until we've had time to figure out what exactly has changed between versions 2.1 and 2.0 and why this affects .
FYI: Another thing I came across, due to a broken clawsmail pgp, was that the handling of gpg-agent differs from version 2.0 . GnuPG 2.1 do not use GPGAGENTINFO anymore. Instead it search for the gpg-agent socket in
For now at least, setting GPGAGENTINFO to $ seems to make claws-mail work.

gnupatch = callPackage ../tools/text/gnupatch { }; gnupg1orig = callPackage ../tools/security/gnupg/1.nix { }; gnupg1compat = callPackage ../tools/security/gnupg/1compat.nix { }; <del> # use config.packageOverrides if you prefer original gnupg1 gnupg1 = gnupg1compat; </del> <ins> gnupg1 = gnupg1compat;    # use config.packageOverrides if you prefer original gnupg1 </ins> gnupg20 = callPackage ../tools/security/gnupg/20.nix { }; <del> gnupg21 = lowPrio (callPackage ../tools/security/gnupg/21.nix { }); gnupg = gnupg20; </del> <ins> gnupg21 = callPackage ../tools/security/gnupg/21.nix { }; gnupg = gnupg21; </ins> gnuplot = callPackage ../tools/graphics/gnuplot { qt = qt4; };


Question:
repstopdf does not seem to be included anywhere in texlive or ghostscript. This means that texlive can't include .eps figures in pdf output.
Thanks!

ln -sv "$(realpath $s)" "$out/bin/$tName" # wrapped below done ) <ins> '' + # A hacky way to provide repstopdf #  * Copy is done to have a correct "$0" so that epstopdf enables the restricted mode #  * ./bin/repstopdf needs to be a symlink to be processed by wrapBin '' if [[ -e ./bin/epstopdf ]]; then cp $(realpath ./bin/epstopdf) ./share/texmf/scripts/repstopdf ln -s "$out"/share/texmf/scripts/repstopdf ./bin/repstopdf fi '' + # finish up the wrappers '' </ins> rm "$out"/bin/*-sys wrapBin '' + <ins> # Perform a small test to verify that the restricted mode get enabled when # needed (detected by checking if it disallows --gscmd) '' if [[ -e ./bin/epstopdf ]]; then echo "Testing restricted mode for {,r}epstopdf" ! (epstopdf --gscmd echo /dev/null 2>&1 || true) | grep forbidden (repstopdf --gscmd echo /dev/null 2>&1 || true) | grep forbidden fi '' + </ins> # TODO: a context trigger https://www.preining.info/blog/2015/06/debian-tex-live-2015-the-new-layout/ # http://wiki.contextgarden.net/ConTeXt_Standalone#Unix-like_platforms_.28Linux.2FMacOS_X.2FFreeBSD.2FSolaris.29


Question:
dvc () is version control system for "biggish" data and code It integrates with Git but offers a solution for managing and versioning big data sets that come with code commits. Related technology () are like git annex and git lfs. If nobody gets around to this, I may work on this later.
Need to first package the Python dependencies nanotime, grandalf and asciimatics dependencies.
The extra dependencies: These will need to be packaged as optional dependencies and provided as a separate alias. Something like and or something like that. What are some good suggestions for names? The and don't appear to be packaged.
Google cloud storage is packaged already here: However is still not packaged as is though. The pypi is:
Initial PR for azure-storage:
Inital PR for nanotime:
Initial PR for grandalf:
Initial PR for asciimatics:
For the smaller dependent packages that are unrelated it would have been preferred to group them in one pr.
However too late now :smile: so just to know in the future.
Yea that would have been better as I could have then worked on dvc commit as well, but now that all dependent packages are separated between different branches, that's not possible. So I'm just waiting for those to be merged to master.
Initial PR for dvc:

<ins> { lib , python3Packages , fetchFromGitHub , enableGoogle ? false , enableAWS ? false , enableAzure ? false , enableSSH ? false }: with python3Packages; buildPythonApplication rec { pname = "dvc"; version = "0.24.3"; # PyPi only has wheel src = fetchFromGitHub { owner = "iterative"; repo = "dvc"; rev = version; sha256 = "1wqq4i23hppilp20fx5a5nj93xwf3wwwr2f8aasvn6jkv2l22vpl"; }; propagatedBuildInputs = [ ply configparser zc_lockfile future colorama configobj networkx pyyaml GitPython setuptools nanotime pyasn1 schema jsonpath_rw requests grandalf asciimatics distro appdirs ] ++ lib.optional enableGoogle google_cloud_storage ++ lib.optional enableAWS boto3 ++ lib.optional enableAzure azure-storage-blob ++ lib.optional enableSSH paramiko; # tests require access to real cloud services # nix build tests have to be isolated and run locally doCheck = false; patches = [ ./dvc-daemon.patch ]; postPatch = '' substituteInPlace dvc/daemon.py --subst-var-by dvc "$out/bin/dcv" ''; meta = with lib; { description = "Version Control System for Machine Learning Projects"; license = licenses.asl20; homepage = https://dvc.org; maintainers = with maintainers; [ cmcdragonkai ]; }; } </ins>


Question:
dvc () is version control system for "biggish" data and code It integrates with Git but offers a solution for managing and versioning big data sets that come with code commits. Related technology () are like git annex and git lfs. If nobody gets around to this, I may work on this later.
Need to first package the Python dependencies nanotime, grandalf and asciimatics dependencies.
The extra dependencies: These will need to be packaged as optional dependencies and provided as a separate alias. Something like and or something like that. What are some good suggestions for names? The and don't appear to be packaged.
Google cloud storage is packaged already here: However is still not packaged as is though. The pypi is:
Initial PR for azure-storage:
Inital PR for nanotime:
Initial PR for grandalf:
Initial PR for asciimatics:
For the smaller dependent packages that are unrelated it would have been preferred to group them in one pr.
However too late now :smile: so just to know in the future.
Yea that would have been better as I could have then worked on dvc commit as well, but now that all dependent packages are separated between different branches, that's not possible. So I'm just waiting for those to be merged to master.
Initial PR for dvc:

<ins> diff --git a/dvc/daemon.py b/dvc/daemon.py index 1d67a37..7ce6fde 100644 --- a/dvc/daemon.py +++ b/dvc/daemon.py @@ -67,14 +67,8 @@ def daemon(args): Args: args (list): list of arguments to append to `dvc daemon` command. """ -    cmd = [sys.executable] -    if not is_binary(): -        cmd += ['-m', 'dvc'] -    cmd += ['daemon', '-q'] + args - -    env = fix_env() -    file_path = os.path.abspath(inspect.stack()[0][1]) -    env['PYTHONPATH'] = os.path.dirname(os.path.dirname(file_path)) +    cmd = [ "@dvc@" , "daemon", "-q"] + args +    env = None logger.debug("Trying to spawn '{}' with env '{}'".format(cmd, env)) </ins>


Question:
dvc () is version control system for "biggish" data and code It integrates with Git but offers a solution for managing and versioning big data sets that come with code commits. Related technology () are like git annex and git lfs. If nobody gets around to this, I may work on this later.
Need to first package the Python dependencies nanotime, grandalf and asciimatics dependencies.
The extra dependencies: These will need to be packaged as optional dependencies and provided as a separate alias. Something like and or something like that. What are some good suggestions for names? The and don't appear to be packaged.
Google cloud storage is packaged already here: However is still not packaged as is though. The pypi is:
Initial PR for azure-storage:
Inital PR for nanotime:
Initial PR for grandalf:
Initial PR for asciimatics:
For the smaller dependent packages that are unrelated it would have been preferred to group them in one pr.
However too late now :smile: so just to know in the future.
Yea that would have been better as I could have then worked on dvc commit as well, but now that all dependent packages are separated between different branches, that's not possible. So I'm just waiting for those to be merged to master.
Initial PR for dvc:

duperemove = callPackage ../tools/filesystems/duperemove { }; <ins> dvc = callPackage ../applications/version-management/dvc { }; dvc-with-remotes = callPackage ../applications/version-management/dvc { enableGoogle = true; enableAWS = true; enableAzure = true; enableSSH = true; }; </ins> dylibbundler = callPackage ../tools/misc/dylibbundler { }; dynamic-colors = callPackage ../tools/misc/dynamic-colors { };


Question:
Anyone want to collaborate? I will try my hand at packaging it in a bit, and will probably add it to the wayland/windowmanager overlay I'm maintaining along with a nixpkgs PR if I get it working. Arcan "Arcan - [Display Server, Multimedia Framework, Game Engine] -"Desktop Engine" http://arcan-" Durden "Desktop Environment for Arcan "
I've succeeded in building and running Arcan and Durden. works but I'm sure there are things in the closure that don't belong (X11?). I started with Void Linux's dependency list and kept adding things cmake complained about until it built. Getting it running was challenging because it depends on a bunch of environment variables being set correctly and neither the error messages or the documentation are all that clear. It also wants its binary to be SUID. Here's what I've been doing while working on the package and figuring out how to run the binary: From a virtual terminal: Here are my settings for the environment variables: I created all the directories in $HOME which are referenced in the variables. I don't have a package for Durden. I installed it by cloning it off github and then making a symbolic link to its subdirectory from . I'm running this on a laptop with Intel graphics, and have been working on it in a virtual terminal with my x session left running in another. The one time I switched back to xserver without killing arcan first, it hung my laptop.
That is great to hear thank you for sharing. I'm pretty occupied right now with some traveling, but I'll try to take a look at this soon. Thank you for writing it up though, I'm sure someone will stumble on that and be thankful too! EDIT: oops, I thought this was on a different repo, I probably would've worded this differently otherwise. Either way, still excited to see this. :)
I've and am typing this in Firefox running in an X server in a window on Arcan. The package definition builds an executable called and you can invoke it from a shell prompt in a Durden window to run it. To run a second instance, use . To start an application or window manager in the X server from a shell prompt, set first as in . It doesn't automatically detect when its window size changes, but works. The font path part of the derivation isn't right. I made two attempts at making it work and left them both in the derivation. The code in puts a font path into the configure flag provided for that purpose, but the resulting executable can't find the fonts. The other chunk of code in links fonts into the derivation, and that part gets the truetype fonts to work but not the bitmap fonts. I'm happy to run so I stopped there, but someone who knows more about X fonts than me should take a look.
I was curious about the various Arcan tools (clipboard, image viewer, network proxy, wayland bridge) so I packaged them. There had been a lot of change in the tools directory between the last release and master, so I packaged the tools from master. So the latest commit in adds , and several child packages under . I haven't figured out how to get the Wayland bridge to work, but I wasn't using Wayland before this so may be missing something obvious. I have been running and with Durden on my laptop for about a week now and am finding it very usable and stable.
Hey there and Wish I had found this thread earlier. I had a go at packaging Arcan at . It builds, however it still has some rough edges at runtime (most glaringly, mouse and keyboard don't work if not running as root - addressing that now). I'm going to study what the two of you have discovered so far, and maybe we can join forces in bringing this very interesting piece of software to the Nix ecosystem.
Hey I've just updated with a commit to make it build more recent versions of and . I've had no problems with but the recent litters the screen with mouse cursor trails. It would be great to get it running not as root so keep us posted on your progress.
To get the keyboard and mouse to work when not running as root, just add the user running to the group.
thanks, that worked! I brushed the dust off my Arcan/Nix code just to try out your suggestion. Now I have Arcan, its core utilities and the example compositors (except which fails to find something or other) running on my system, including a terminal - one more thing to run besides , , or in a vanilla console! Neat! I skipped the whole overlays thing and ended up with a file that can be submitted to Nixpkgs (or imported into ). Guess I should share that part of my config as a gist or something before submitting a PR? Or is there something missing, as might be suggested by Food for thought a.k.a. "and then what?": Port my i3 keys to a fork of Durden, ripping some features from Prio to finally organize my daily terminal-browser-devtools grind in a sane way :grin: We have a powerful engine on our hands and a whole lot of Lua ricing to do. Would be cool if some logic from can be ported over to an environment outside X.
Gist: (Sure is cool how Durden and Prio have different mouse capture behavior btw)
I marked this as stale due to inactivity. →
There is still some good progress over at the gist.
I found this while looking into a new project (, ) posted to today. (By same developers as arcan, and uses arcan, so I was curious if we had it packaged.) Just cross-referencing on the off-chance it helps anyone here. I'll also add this to the gist.

<ins> { lib , stdenv , fetchFromGitHub , SDL2 , cmake , espeak , ffmpeg , file , freetype , harfbuzz , leptonica , libGL , libX11 , libXau , libXcomposite , libXdmcp , libXfixes , libdrm , libffi , libusb1 , libuvc , libvlc , libvncserver , libxcb , libxkbcommon , luajit , makeWrapper , mesa , openal , pkg-config , sqlite , tesseract , valgrind , wayland , wayland-protocols , xcbutil , xcbutilwm , xz , buildManPages ? true, ruby }: let # TODO: investigate vendoring, especially OpenAL # WARN: vendoring of OpenAL is required for running arcan_lwa # INFO: maybe it needs leaveDotGit, but it is dangerous/impure letoram-openal-src = fetchFromGitHub { owner = "letoram"; repo = "openal"; rev = "1c7302c580964fee9ee9e1d89ff56d24f934bdef"; hash = "sha256-InqU59J0zvwJ20a7KU54xTM7d76VoOlFbtj7KbFlnTU="; }; in stdenv.mkDerivation rec { pname = "arcan"; version = "0.6.1pre1+unstable=2021-07-07"; src = fetchFromGitHub { owner = "letoram"; repo = "arcan"; rev = "f3341ab94b32d02f3d15c3b91a512b2614e950a5"; hash = "sha256-YBtRA5uCk4tjX3Bsu5vMkaNaCLRlM6HVQ53sna3gDsY="; }; postUnpack = '' ( cd $sourceRoot/external/git/ cp -a ${letoram-openal-src}/ openal/ chmod --recursive 744 openal/ ) ''; # TODO: work with upstream in order to get rid of these hardcoded paths postPatch = '' substituteInPlace ./src/platform/posix/paths.c  --replace "/usr/bin" "$out/bin"  --replace "/usr/share" "$out/share" substituteInPlace ./src/CMakeLists.txt --replace "SETUID" "# SETUID" ''; nativeBuildInputs = [ cmake makeWrapper pkg-config ] ++ lib.optionals buildManPages [ ruby ]; buildInputs = [ SDL2 espeak ffmpeg file freetype harfbuzz leptonica libGL libX11 libXau libXcomposite libXdmcp libXfixes libdrm libffi libusb1 libuvc libvlc libvncserver libxcb libxkbcommon luajit mesa openal sqlite tesseract valgrind wayland wayland-protocols xcbutil xcbutilwm xz ]; # INFO: According to the source code, the manpages need to be generated before # the configure phase preConfigure = lib.optionalString buildManPages '' (cd doc; ruby docgen.rb mangen) ''; cmakeFlags = [ "-DBUILD_PRESET=everything" # The upstream project recommends tagging the distribution "-DDISTR_TAG=Nixpkgs" "-DENGINE_BUILDTAG=${version}" "-DHYBRID_SDL=on" "-DSTATIC_OPENAL=off" "../src" ]; hardeningDisable = [ "format" ]; meta = with lib; { homepage = "https://arcan-fe.com/"; description = "Combined Display Server, Multimedia Framework, Game Engine"; longDescription = '' Arcan is a portable and fast self-sufficient multimedia engine for advanced visualization and analysis work in a wide range of applications e.g. game development, real-time streaming video, monitoring and surveillance, up to and including desktop compositors and window managers. ''; license = with licenses; [ bsd3 gpl2Plus lgpl2Plus ]; maintainers = with maintainers; [ AndersonTorres ]; platforms = platforms.unix; }; } </ins>


Question:
Anyone want to collaborate? I will try my hand at packaging it in a bit, and will probably add it to the wayland/windowmanager overlay I'm maintaining along with a nixpkgs PR if I get it working. Arcan "Arcan - [Display Server, Multimedia Framework, Game Engine] -"Desktop Engine" http://arcan-" Durden "Desktop Environment for Arcan "
I've succeeded in building and running Arcan and Durden. works but I'm sure there are things in the closure that don't belong (X11?). I started with Void Linux's dependency list and kept adding things cmake complained about until it built. Getting it running was challenging because it depends on a bunch of environment variables being set correctly and neither the error messages or the documentation are all that clear. It also wants its binary to be SUID. Here's what I've been doing while working on the package and figuring out how to run the binary: From a virtual terminal: Here are my settings for the environment variables: I created all the directories in $HOME which are referenced in the variables. I don't have a package for Durden. I installed it by cloning it off github and then making a symbolic link to its subdirectory from . I'm running this on a laptop with Intel graphics, and have been working on it in a virtual terminal with my x session left running in another. The one time I switched back to xserver without killing arcan first, it hung my laptop.
That is great to hear thank you for sharing. I'm pretty occupied right now with some traveling, but I'll try to take a look at this soon. Thank you for writing it up though, I'm sure someone will stumble on that and be thankful too! EDIT: oops, I thought this was on a different repo, I probably would've worded this differently otherwise. Either way, still excited to see this. :)
I've and am typing this in Firefox running in an X server in a window on Arcan. The package definition builds an executable called and you can invoke it from a shell prompt in a Durden window to run it. To run a second instance, use . To start an application or window manager in the X server from a shell prompt, set first as in . It doesn't automatically detect when its window size changes, but works. The font path part of the derivation isn't right. I made two attempts at making it work and left them both in the derivation. The code in puts a font path into the configure flag provided for that purpose, but the resulting executable can't find the fonts. The other chunk of code in links fonts into the derivation, and that part gets the truetype fonts to work but not the bitmap fonts. I'm happy to run so I stopped there, but someone who knows more about X fonts than me should take a look.
I was curious about the various Arcan tools (clipboard, image viewer, network proxy, wayland bridge) so I packaged them. There had been a lot of change in the tools directory between the last release and master, so I packaged the tools from master. So the latest commit in adds , and several child packages under . I haven't figured out how to get the Wayland bridge to work, but I wasn't using Wayland before this so may be missing something obvious. I have been running and with Durden on my laptop for about a week now and am finding it very usable and stable.
Hey there and Wish I had found this thread earlier. I had a go at packaging Arcan at . It builds, however it still has some rough edges at runtime (most glaringly, mouse and keyboard don't work if not running as root - addressing that now). I'm going to study what the two of you have discovered so far, and maybe we can join forces in bringing this very interesting piece of software to the Nix ecosystem.
Hey I've just updated with a commit to make it build more recent versions of and . I've had no problems with but the recent litters the screen with mouse cursor trails. It would be great to get it running not as root so keep us posted on your progress.
To get the keyboard and mouse to work when not running as root, just add the user running to the group.
thanks, that worked! I brushed the dust off my Arcan/Nix code just to try out your suggestion. Now I have Arcan, its core utilities and the example compositors (except which fails to find something or other) running on my system, including a terminal - one more thing to run besides , , or in a vanilla console! Neat! I skipped the whole overlays thing and ended up with a file that can be submitted to Nixpkgs (or imported into ). Guess I should share that part of my config as a gist or something before submitting a PR? Or is there something missing, as might be suggested by Food for thought a.k.a. "and then what?": Port my i3 keys to a fork of Durden, ripping some features from Prio to finally organize my daily terminal-browser-devtools grind in a sane way :grin: We have a powerful engine on our hands and a whole lot of Lua ricing to do. Would be cool if some logic from can be ported over to an environment outside X.
Gist: (Sure is cool how Durden and Prio have different mouse capture behavior btw)
I marked this as stale due to inactivity. →
There is still some good progress over at the gist.
I found this while looking into a new project (, ) posted to today. (By same developers as arcan, and uses arcan, so I was curious if we had it packaged.) Just cross-referencing on the off-chance it helps anyone here. I'll also add this to the gist.

<ins> { callPackage, lib, pkgs }: rec { # Dependencies espeak = pkgs.espeak-ng; ffmpeg = pkgs.ffmpeg-full; harfbuzz = pkgs.harfbuzzFull; # Arcan arcan = callPackage ./arcan.nix { }; arcan-wrapped = callPackage ./wrapper.nix { }; xarcan = callPackage ./xarcan.nix { }; # Appls durden = callPackage ./durden.nix { }; durden-wrapped = callPackage ./wrapper.nix { name = "durden-wrapped"; appls = [ durden ]; }; pipeworld = callPackage ./pipeworld.nix { }; pipeworld-wrapped = callPackage ./wrapper.nix { name = "pipeworld-wrapped"; appls = [ pipeworld ]; }; prio = callPackage ./prio.nix { }; prio-wrapped = callPackage ./wrapper.nix { name = "prio-wrapped"; appls = [ prio ]; }; # One Expression to SymlinkJoin Them All everyone-wrapped = callPackage ./wrapper.nix { name = "everyone-wrapped"; appls = [ durden pipeworld prio ]; }; } </ins>


Question:
Anyone want to collaborate? I will try my hand at packaging it in a bit, and will probably add it to the wayland/windowmanager overlay I'm maintaining along with a nixpkgs PR if I get it working. Arcan "Arcan - [Display Server, Multimedia Framework, Game Engine] -"Desktop Engine" http://arcan-" Durden "Desktop Environment for Arcan "
I've succeeded in building and running Arcan and Durden. works but I'm sure there are things in the closure that don't belong (X11?). I started with Void Linux's dependency list and kept adding things cmake complained about until it built. Getting it running was challenging because it depends on a bunch of environment variables being set correctly and neither the error messages or the documentation are all that clear. It also wants its binary to be SUID. Here's what I've been doing while working on the package and figuring out how to run the binary: From a virtual terminal: Here are my settings for the environment variables: I created all the directories in $HOME which are referenced in the variables. I don't have a package for Durden. I installed it by cloning it off github and then making a symbolic link to its subdirectory from . I'm running this on a laptop with Intel graphics, and have been working on it in a virtual terminal with my x session left running in another. The one time I switched back to xserver without killing arcan first, it hung my laptop.
That is great to hear thank you for sharing. I'm pretty occupied right now with some traveling, but I'll try to take a look at this soon. Thank you for writing it up though, I'm sure someone will stumble on that and be thankful too! EDIT: oops, I thought this was on a different repo, I probably would've worded this differently otherwise. Either way, still excited to see this. :)
I've and am typing this in Firefox running in an X server in a window on Arcan. The package definition builds an executable called and you can invoke it from a shell prompt in a Durden window to run it. To run a second instance, use . To start an application or window manager in the X server from a shell prompt, set first as in . It doesn't automatically detect when its window size changes, but works. The font path part of the derivation isn't right. I made two attempts at making it work and left them both in the derivation. The code in puts a font path into the configure flag provided for that purpose, but the resulting executable can't find the fonts. The other chunk of code in links fonts into the derivation, and that part gets the truetype fonts to work but not the bitmap fonts. I'm happy to run so I stopped there, but someone who knows more about X fonts than me should take a look.
I was curious about the various Arcan tools (clipboard, image viewer, network proxy, wayland bridge) so I packaged them. There had been a lot of change in the tools directory between the last release and master, so I packaged the tools from master. So the latest commit in adds , and several child packages under . I haven't figured out how to get the Wayland bridge to work, but I wasn't using Wayland before this so may be missing something obvious. I have been running and with Durden on my laptop for about a week now and am finding it very usable and stable.
Hey there and Wish I had found this thread earlier. I had a go at packaging Arcan at . It builds, however it still has some rough edges at runtime (most glaringly, mouse and keyboard don't work if not running as root - addressing that now). I'm going to study what the two of you have discovered so far, and maybe we can join forces in bringing this very interesting piece of software to the Nix ecosystem.
Hey I've just updated with a commit to make it build more recent versions of and . I've had no problems with but the recent litters the screen with mouse cursor trails. It would be great to get it running not as root so keep us posted on your progress.
To get the keyboard and mouse to work when not running as root, just add the user running to the group.
thanks, that worked! I brushed the dust off my Arcan/Nix code just to try out your suggestion. Now I have Arcan, its core utilities and the example compositors (except which fails to find something or other) running on my system, including a terminal - one more thing to run besides , , or in a vanilla console! Neat! I skipped the whole overlays thing and ended up with a file that can be submitted to Nixpkgs (or imported into ). Guess I should share that part of my config as a gist or something before submitting a PR? Or is there something missing, as might be suggested by Food for thought a.k.a. "and then what?": Port my i3 keys to a fork of Durden, ripping some features from Prio to finally organize my daily terminal-browser-devtools grind in a sane way :grin: We have a powerful engine on our hands and a whole lot of Lua ricing to do. Would be cool if some logic from can be ported over to an environment outside X.
Gist: (Sure is cool how Durden and Prio have different mouse capture behavior btw)
I marked this as stale due to inactivity. →
There is still some good progress over at the gist.
I found this while looking into a new project (, ) posted to today. (By same developers as arcan, and uses arcan, so I was curious if we had it packaged.) Just cross-referencing on the off-chance it helps anyone here. I'll also add this to the gist.

<ins> { lib , stdenv , fetchFromGitHub }: stdenv.mkDerivation rec { pname = "durden"; version = "0.6.1+unstable=2021-06-25"; src = fetchFromGitHub { owner = "letoram"; repo = pname; rev = "fb618fccc57a68b6ce933b4df5822acd1965d591"; hash = "sha256-PovI837Xca4wV0g0s4tYUMFGVUDf+f8HcdvM1+0aDxk="; }; installPhase = '' runHook preInstall mkdir -p ${placeholder "out"}/share/arcan/appl/ cp -a ./durden ${placeholder "out"}/share/arcan/appl/ runHook postInstall ''; meta = with lib; { homepage = "https://durden.arcan-fe.com/"; description = "Reference Desktop Environment for Arcan"; longDescription = '' Durden is a desktop environment for the Arcan Display Server. It serves both as a reference showcase on how to take advantage of some of the features in Arcan, and as a very competent entry to the advanced-user side of the desktop environment spectrum. ''; license = licenses.bsd3; maintainers = with maintainers; [ AndersonTorres ]; platforms = platforms.all; }; } </ins>


Question:
Anyone want to collaborate? I will try my hand at packaging it in a bit, and will probably add it to the wayland/windowmanager overlay I'm maintaining along with a nixpkgs PR if I get it working. Arcan "Arcan - [Display Server, Multimedia Framework, Game Engine] -"Desktop Engine" http://arcan-" Durden "Desktop Environment for Arcan "
I've succeeded in building and running Arcan and Durden. works but I'm sure there are things in the closure that don't belong (X11?). I started with Void Linux's dependency list and kept adding things cmake complained about until it built. Getting it running was challenging because it depends on a bunch of environment variables being set correctly and neither the error messages or the documentation are all that clear. It also wants its binary to be SUID. Here's what I've been doing while working on the package and figuring out how to run the binary: From a virtual terminal: Here are my settings for the environment variables: I created all the directories in $HOME which are referenced in the variables. I don't have a package for Durden. I installed it by cloning it off github and then making a symbolic link to its subdirectory from . I'm running this on a laptop with Intel graphics, and have been working on it in a virtual terminal with my x session left running in another. The one time I switched back to xserver without killing arcan first, it hung my laptop.
That is great to hear thank you for sharing. I'm pretty occupied right now with some traveling, but I'll try to take a look at this soon. Thank you for writing it up though, I'm sure someone will stumble on that and be thankful too! EDIT: oops, I thought this was on a different repo, I probably would've worded this differently otherwise. Either way, still excited to see this. :)
I've and am typing this in Firefox running in an X server in a window on Arcan. The package definition builds an executable called and you can invoke it from a shell prompt in a Durden window to run it. To run a second instance, use . To start an application or window manager in the X server from a shell prompt, set first as in . It doesn't automatically detect when its window size changes, but works. The font path part of the derivation isn't right. I made two attempts at making it work and left them both in the derivation. The code in puts a font path into the configure flag provided for that purpose, but the resulting executable can't find the fonts. The other chunk of code in links fonts into the derivation, and that part gets the truetype fonts to work but not the bitmap fonts. I'm happy to run so I stopped there, but someone who knows more about X fonts than me should take a look.
I was curious about the various Arcan tools (clipboard, image viewer, network proxy, wayland bridge) so I packaged them. There had been a lot of change in the tools directory between the last release and master, so I packaged the tools from master. So the latest commit in adds , and several child packages under . I haven't figured out how to get the Wayland bridge to work, but I wasn't using Wayland before this so may be missing something obvious. I have been running and with Durden on my laptop for about a week now and am finding it very usable and stable.
Hey there and Wish I had found this thread earlier. I had a go at packaging Arcan at . It builds, however it still has some rough edges at runtime (most glaringly, mouse and keyboard don't work if not running as root - addressing that now). I'm going to study what the two of you have discovered so far, and maybe we can join forces in bringing this very interesting piece of software to the Nix ecosystem.
Hey I've just updated with a commit to make it build more recent versions of and . I've had no problems with but the recent litters the screen with mouse cursor trails. It would be great to get it running not as root so keep us posted on your progress.
To get the keyboard and mouse to work when not running as root, just add the user running to the group.
thanks, that worked! I brushed the dust off my Arcan/Nix code just to try out your suggestion. Now I have Arcan, its core utilities and the example compositors (except which fails to find something or other) running on my system, including a terminal - one more thing to run besides , , or in a vanilla console! Neat! I skipped the whole overlays thing and ended up with a file that can be submitted to Nixpkgs (or imported into ). Guess I should share that part of my config as a gist or something before submitting a PR? Or is there something missing, as might be suggested by Food for thought a.k.a. "and then what?": Port my i3 keys to a fork of Durden, ripping some features from Prio to finally organize my daily terminal-browser-devtools grind in a sane way :grin: We have a powerful engine on our hands and a whole lot of Lua ricing to do. Would be cool if some logic from can be ported over to an environment outside X.
Gist: (Sure is cool how Durden and Prio have different mouse capture behavior btw)
I marked this as stale due to inactivity. →
There is still some good progress over at the gist.
I found this while looking into a new project (, ) posted to today. (By same developers as arcan, and uses arcan, so I was curious if we had it packaged.) Just cross-referencing on the off-chance it helps anyone here. I'll also add this to the gist.

<ins> { lib , stdenv , fetchFromGitHub }: stdenv.mkDerivation rec { pname = "pipeworld"; version = "0.0.0+unstable=2021-05-27"; src = fetchFromGitHub { owner = "letoram"; repo = pname; rev = "c26df9ca0225ce2fd4f89e7ec59d4ab1f94a4c2e"; hash = "sha256-RkDAbM1q4o61RGPLPLXHLvbvClp+bfjodlWgUGoODzA="; }; installPhase = '' runHook preInstall mkdir -p ${placeholder "out"}/share/arcan/appl/ cp -a ./pipeworld ${placeholder "out"}/share/arcan/appl/ runHook postInstall ''; meta = with lib; { homepage = "https://github.com/letoram/pipeworld"; description = "Dataflow 'spreadsheet' desktop environment"; longDescription = '' Pipeworld is a zooming dataflow tool and desktop heavily inspired by userland. It is built using the arcan desktop engine. It combines the programmable processing of shell scripts and pipes, the interactive visual addressing/programming model of spread sheets, the scenegraph- and interactive controls-, IPC- and client processing- of display servers into one model with zoomable tiling window management. It can be used as a standalone desktop of its own, or as a normal application within another desktop as a 'substitute' for your normal terminal emulator. ''; license = licenses.bsd3; maintainers = with maintainers; [ AndersonTorres ]; platforms = platforms.all; }; } </ins>


Question:
Anyone want to collaborate? I will try my hand at packaging it in a bit, and will probably add it to the wayland/windowmanager overlay I'm maintaining along with a nixpkgs PR if I get it working. Arcan "Arcan - [Display Server, Multimedia Framework, Game Engine] -"Desktop Engine" http://arcan-" Durden "Desktop Environment for Arcan "
I've succeeded in building and running Arcan and Durden. works but I'm sure there are things in the closure that don't belong (X11?). I started with Void Linux's dependency list and kept adding things cmake complained about until it built. Getting it running was challenging because it depends on a bunch of environment variables being set correctly and neither the error messages or the documentation are all that clear. It also wants its binary to be SUID. Here's what I've been doing while working on the package and figuring out how to run the binary: From a virtual terminal: Here are my settings for the environment variables: I created all the directories in $HOME which are referenced in the variables. I don't have a package for Durden. I installed it by cloning it off github and then making a symbolic link to its subdirectory from . I'm running this on a laptop with Intel graphics, and have been working on it in a virtual terminal with my x session left running in another. The one time I switched back to xserver without killing arcan first, it hung my laptop.
That is great to hear thank you for sharing. I'm pretty occupied right now with some traveling, but I'll try to take a look at this soon. Thank you for writing it up though, I'm sure someone will stumble on that and be thankful too! EDIT: oops, I thought this was on a different repo, I probably would've worded this differently otherwise. Either way, still excited to see this. :)
I've and am typing this in Firefox running in an X server in a window on Arcan. The package definition builds an executable called and you can invoke it from a shell prompt in a Durden window to run it. To run a second instance, use . To start an application or window manager in the X server from a shell prompt, set first as in . It doesn't automatically detect when its window size changes, but works. The font path part of the derivation isn't right. I made two attempts at making it work and left them both in the derivation. The code in puts a font path into the configure flag provided for that purpose, but the resulting executable can't find the fonts. The other chunk of code in links fonts into the derivation, and that part gets the truetype fonts to work but not the bitmap fonts. I'm happy to run so I stopped there, but someone who knows more about X fonts than me should take a look.
I was curious about the various Arcan tools (clipboard, image viewer, network proxy, wayland bridge) so I packaged them. There had been a lot of change in the tools directory between the last release and master, so I packaged the tools from master. So the latest commit in adds , and several child packages under . I haven't figured out how to get the Wayland bridge to work, but I wasn't using Wayland before this so may be missing something obvious. I have been running and with Durden on my laptop for about a week now and am finding it very usable and stable.
Hey there and Wish I had found this thread earlier. I had a go at packaging Arcan at . It builds, however it still has some rough edges at runtime (most glaringly, mouse and keyboard don't work if not running as root - addressing that now). I'm going to study what the two of you have discovered so far, and maybe we can join forces in bringing this very interesting piece of software to the Nix ecosystem.
Hey I've just updated with a commit to make it build more recent versions of and . I've had no problems with but the recent litters the screen with mouse cursor trails. It would be great to get it running not as root so keep us posted on your progress.
To get the keyboard and mouse to work when not running as root, just add the user running to the group.
thanks, that worked! I brushed the dust off my Arcan/Nix code just to try out your suggestion. Now I have Arcan, its core utilities and the example compositors (except which fails to find something or other) running on my system, including a terminal - one more thing to run besides , , or in a vanilla console! Neat! I skipped the whole overlays thing and ended up with a file that can be submitted to Nixpkgs (or imported into ). Guess I should share that part of my config as a gist or something before submitting a PR? Or is there something missing, as might be suggested by Food for thought a.k.a. "and then what?": Port my i3 keys to a fork of Durden, ripping some features from Prio to finally organize my daily terminal-browser-devtools grind in a sane way :grin: We have a powerful engine on our hands and a whole lot of Lua ricing to do. Would be cool if some logic from can be ported over to an environment outside X.
Gist: (Sure is cool how Durden and Prio have different mouse capture behavior btw)
I marked this as stale due to inactivity. →
There is still some good progress over at the gist.
I found this while looking into a new project (, ) posted to today. (By same developers as arcan, and uses arcan, so I was curious if we had it packaged.) Just cross-referencing on the off-chance it helps anyone here. I'll also add this to the gist.

<ins> { lib , stdenv , fetchFromGitHub }: stdenv.mkDerivation rec { pname = "prio"; version = "0.0.0+unstable=2018-09-13"; src = fetchFromGitHub { owner = "letoram"; repo = pname; rev = "c3f97491339d15f063d6937d5f89bcfaea774dd1"; hash = "sha256-Idv/duEYmDk/rO+TI8n+FY3VFDtUEh8C292jh12BJuM="; }; installPhase = '' runHook preInstall mkdir -p ${placeholder "out"}/share/arcan/appl/prio cp -a ./* ${placeholder "out"}/share/arcan/appl/prio runHook postInstall ''; meta = with lib; { homepage = "https://github.com/letoram/prio"; description = "Plan9- Rio like Window Manager for Arcan"; license = licenses.bsd3; maintainers = with maintainers; [ AndersonTorres ]; platforms = platforms.all; }; } </ins>


Question:
Anyone want to collaborate? I will try my hand at packaging it in a bit, and will probably add it to the wayland/windowmanager overlay I'm maintaining along with a nixpkgs PR if I get it working. Arcan "Arcan - [Display Server, Multimedia Framework, Game Engine] -"Desktop Engine" http://arcan-" Durden "Desktop Environment for Arcan "
I've succeeded in building and running Arcan and Durden. works but I'm sure there are things in the closure that don't belong (X11?). I started with Void Linux's dependency list and kept adding things cmake complained about until it built. Getting it running was challenging because it depends on a bunch of environment variables being set correctly and neither the error messages or the documentation are all that clear. It also wants its binary to be SUID. Here's what I've been doing while working on the package and figuring out how to run the binary: From a virtual terminal: Here are my settings for the environment variables: I created all the directories in $HOME which are referenced in the variables. I don't have a package for Durden. I installed it by cloning it off github and then making a symbolic link to its subdirectory from . I'm running this on a laptop with Intel graphics, and have been working on it in a virtual terminal with my x session left running in another. The one time I switched back to xserver without killing arcan first, it hung my laptop.
That is great to hear thank you for sharing. I'm pretty occupied right now with some traveling, but I'll try to take a look at this soon. Thank you for writing it up though, I'm sure someone will stumble on that and be thankful too! EDIT: oops, I thought this was on a different repo, I probably would've worded this differently otherwise. Either way, still excited to see this. :)
I've and am typing this in Firefox running in an X server in a window on Arcan. The package definition builds an executable called and you can invoke it from a shell prompt in a Durden window to run it. To run a second instance, use . To start an application or window manager in the X server from a shell prompt, set first as in . It doesn't automatically detect when its window size changes, but works. The font path part of the derivation isn't right. I made two attempts at making it work and left them both in the derivation. The code in puts a font path into the configure flag provided for that purpose, but the resulting executable can't find the fonts. The other chunk of code in links fonts into the derivation, and that part gets the truetype fonts to work but not the bitmap fonts. I'm happy to run so I stopped there, but someone who knows more about X fonts than me should take a look.
I was curious about the various Arcan tools (clipboard, image viewer, network proxy, wayland bridge) so I packaged them. There had been a lot of change in the tools directory between the last release and master, so I packaged the tools from master. So the latest commit in adds , and several child packages under . I haven't figured out how to get the Wayland bridge to work, but I wasn't using Wayland before this so may be missing something obvious. I have been running and with Durden on my laptop for about a week now and am finding it very usable and stable.
Hey there and Wish I had found this thread earlier. I had a go at packaging Arcan at . It builds, however it still has some rough edges at runtime (most glaringly, mouse and keyboard don't work if not running as root - addressing that now). I'm going to study what the two of you have discovered so far, and maybe we can join forces in bringing this very interesting piece of software to the Nix ecosystem.
Hey I've just updated with a commit to make it build more recent versions of and . I've had no problems with but the recent litters the screen with mouse cursor trails. It would be great to get it running not as root so keep us posted on your progress.
To get the keyboard and mouse to work when not running as root, just add the user running to the group.
thanks, that worked! I brushed the dust off my Arcan/Nix code just to try out your suggestion. Now I have Arcan, its core utilities and the example compositors (except which fails to find something or other) running on my system, including a terminal - one more thing to run besides , , or in a vanilla console! Neat! I skipped the whole overlays thing and ended up with a file that can be submitted to Nixpkgs (or imported into ). Guess I should share that part of my config as a gist or something before submitting a PR? Or is there something missing, as might be suggested by Food for thought a.k.a. "and then what?": Port my i3 keys to a fork of Durden, ripping some features from Prio to finally organize my daily terminal-browser-devtools grind in a sane way :grin: We have a powerful engine on our hands and a whole lot of Lua ricing to do. Would be cool if some logic from can be ported over to an environment outside X.
Gist: (Sure is cool how Durden and Prio have different mouse capture behavior btw)
I marked this as stale due to inactivity. →
There is still some good progress over at the gist.
I found this while looking into a new project (, ) posted to today. (By same developers as arcan, and uses arcan, so I was curious if we had it packaged.) Just cross-referencing on the off-chance it helps anyone here. I'll also add this to the gist.

<ins> { arcan , makeWrapper , symlinkJoin , appls ? [ ] , name ? "arcan-wrapped" }: symlinkJoin rec { inherit name; paths = appls ++ [ arcan ]; nativeBuildInputs = [ makeWrapper ]; postBuild = '' for prog in ${placeholder "out"}/bin/*; do wrapProgram $prog  --prefix PATH ":" "${placeholder "out"}/bin"  --set ARCAN_APPLBASEPATH "${placeholder "out"}/share/arcan/appl/"  --set ARCAN_BINPATH "${placeholder "out"}/bin/arcan_frameserver"  --set ARCAN_LIBPATH "${placeholder "out"}/lib/"  --set ARCAN_RESOURCEPATH "${placeholder "out"}/share/arcan/resources/"  --set ARCAN_SCRIPTPATH "${placeholder "out"}/share/arcan/scripts/"  --set ARCAN_STATEBASEPATH "$HOME/.arcan/resources/savestates/" done ''; } # TODO: set ARCAN_FONTPATH to a set of fonts that can be provided in a parameter </ins>


Question:
Anyone want to collaborate? I will try my hand at packaging it in a bit, and will probably add it to the wayland/windowmanager overlay I'm maintaining along with a nixpkgs PR if I get it working. Arcan "Arcan - [Display Server, Multimedia Framework, Game Engine] -"Desktop Engine" http://arcan-" Durden "Desktop Environment for Arcan "
I've succeeded in building and running Arcan and Durden. works but I'm sure there are things in the closure that don't belong (X11?). I started with Void Linux's dependency list and kept adding things cmake complained about until it built. Getting it running was challenging because it depends on a bunch of environment variables being set correctly and neither the error messages or the documentation are all that clear. It also wants its binary to be SUID. Here's what I've been doing while working on the package and figuring out how to run the binary: From a virtual terminal: Here are my settings for the environment variables: I created all the directories in $HOME which are referenced in the variables. I don't have a package for Durden. I installed it by cloning it off github and then making a symbolic link to its subdirectory from . I'm running this on a laptop with Intel graphics, and have been working on it in a virtual terminal with my x session left running in another. The one time I switched back to xserver without killing arcan first, it hung my laptop.
That is great to hear thank you for sharing. I'm pretty occupied right now with some traveling, but I'll try to take a look at this soon. Thank you for writing it up though, I'm sure someone will stumble on that and be thankful too! EDIT: oops, I thought this was on a different repo, I probably would've worded this differently otherwise. Either way, still excited to see this. :)
I've and am typing this in Firefox running in an X server in a window on Arcan. The package definition builds an executable called and you can invoke it from a shell prompt in a Durden window to run it. To run a second instance, use . To start an application or window manager in the X server from a shell prompt, set first as in . It doesn't automatically detect when its window size changes, but works. The font path part of the derivation isn't right. I made two attempts at making it work and left them both in the derivation. The code in puts a font path into the configure flag provided for that purpose, but the resulting executable can't find the fonts. The other chunk of code in links fonts into the derivation, and that part gets the truetype fonts to work but not the bitmap fonts. I'm happy to run so I stopped there, but someone who knows more about X fonts than me should take a look.
I was curious about the various Arcan tools (clipboard, image viewer, network proxy, wayland bridge) so I packaged them. There had been a lot of change in the tools directory between the last release and master, so I packaged the tools from master. So the latest commit in adds , and several child packages under . I haven't figured out how to get the Wayland bridge to work, but I wasn't using Wayland before this so may be missing something obvious. I have been running and with Durden on my laptop for about a week now and am finding it very usable and stable.
Hey there and Wish I had found this thread earlier. I had a go at packaging Arcan at . It builds, however it still has some rough edges at runtime (most glaringly, mouse and keyboard don't work if not running as root - addressing that now). I'm going to study what the two of you have discovered so far, and maybe we can join forces in bringing this very interesting piece of software to the Nix ecosystem.
Hey I've just updated with a commit to make it build more recent versions of and . I've had no problems with but the recent litters the screen with mouse cursor trails. It would be great to get it running not as root so keep us posted on your progress.
To get the keyboard and mouse to work when not running as root, just add the user running to the group.
thanks, that worked! I brushed the dust off my Arcan/Nix code just to try out your suggestion. Now I have Arcan, its core utilities and the example compositors (except which fails to find something or other) running on my system, including a terminal - one more thing to run besides , , or in a vanilla console! Neat! I skipped the whole overlays thing and ended up with a file that can be submitted to Nixpkgs (or imported into ). Guess I should share that part of my config as a gist or something before submitting a PR? Or is there something missing, as might be suggested by Food for thought a.k.a. "and then what?": Port my i3 keys to a fork of Durden, ripping some features from Prio to finally organize my daily terminal-browser-devtools grind in a sane way :grin: We have a powerful engine on our hands and a whole lot of Lua ricing to do. Would be cool if some logic from can be ported over to an environment outside X.
Gist: (Sure is cool how Durden and Prio have different mouse capture behavior btw)
I marked this as stale due to inactivity. →
There is still some good progress over at the gist.
I found this while looking into a new project (, ) posted to today. (By same developers as arcan, and uses arcan, so I was curious if we had it packaged.) Just cross-referencing on the off-chance it helps anyone here. I'll also add this to the gist.

<ins> { lib , stdenv , fetchFromGitHub , arcan , audit , dbus , epoxy , fontutil , libGL , libX11 , libXau , libXdmcp , libXfont2 , libdrm , libgcrypt , libmd , libselinux , libtirpc , libxcb , libxkbfile , libxshmfence , mesa , meson , nettle , ninja , openssl , pixman , pkg-config , systemd , xcbutil , xcbutilwm , xkbcomp , xkeyboard_config , xorgproto , xtrans }: stdenv.mkDerivation rec { pname = "xarcan"; version = "0.6.0+unstable=2021-06-14"; src = fetchFromGitHub { owner = "letoram"; repo = pname; rev = "98d28a5f2c6860bb191fbc1c9e577c18e4c9a9b7"; hash = "sha256-UTIVDKnYD/q0K6G7NJUKh1tHcqnsuiJ/cQxWuPMJ2G4="; }; nativeBuildInputs = [ meson ninja pkg-config ]; buildInputs = [ arcan audit dbus epoxy fontutil libGL libX11 libXau libXdmcp libXfont2 libdrm libgcrypt libmd libselinux libtirpc libxcb libxkbfile libxshmfence mesa nettle openssl pixman systemd xcbutil xcbutilwm xkbcomp xkeyboard_config xorgproto xtrans ]; configureFlags = [ "--disable-int10-module" "--disable-static" "--disable-xnest" "--disable-xorg" "--disable-xvfb" "--disable-xwayland" "--enable-glamor" "--enable-glx" "--enable-ipv6" "--enable-kdrive" "--enable-record" "--enable-xarcan" "--enable-xcsecurity" "--with-xkb-bin-directory=${xkbcomp}/bin" "--with-xkb-output=/tmp" "--with-xkb-path=${xkeyboard_config}/share/X11/xkb" ]; meta = with lib; { homepage = "https://github.com/letoram/letoram"; description = "Patched Xserver that bridges connections to Arcan"; longDescription = '' xarcan is a patched X server with a KDrive backend that uses the arcan-shmif to map Xlib/Xcb/X clients to a running arcan instance. It allows running an X session as a window under Arcan. ''; license = licenses.mit; maintainers = with maintainers; [ AndersonTorres ]; platforms = platforms.all; }; } </ins>


Question:
Anyone want to collaborate? I will try my hand at packaging it in a bit, and will probably add it to the wayland/windowmanager overlay I'm maintaining along with a nixpkgs PR if I get it working. Arcan "Arcan - [Display Server, Multimedia Framework, Game Engine] -"Desktop Engine" http://arcan-" Durden "Desktop Environment for Arcan "
I've succeeded in building and running Arcan and Durden. works but I'm sure there are things in the closure that don't belong (X11?). I started with Void Linux's dependency list and kept adding things cmake complained about until it built. Getting it running was challenging because it depends on a bunch of environment variables being set correctly and neither the error messages or the documentation are all that clear. It also wants its binary to be SUID. Here's what I've been doing while working on the package and figuring out how to run the binary: From a virtual terminal: Here are my settings for the environment variables: I created all the directories in $HOME which are referenced in the variables. I don't have a package for Durden. I installed it by cloning it off github and then making a symbolic link to its subdirectory from . I'm running this on a laptop with Intel graphics, and have been working on it in a virtual terminal with my x session left running in another. The one time I switched back to xserver without killing arcan first, it hung my laptop.
That is great to hear thank you for sharing. I'm pretty occupied right now with some traveling, but I'll try to take a look at this soon. Thank you for writing it up though, I'm sure someone will stumble on that and be thankful too! EDIT: oops, I thought this was on a different repo, I probably would've worded this differently otherwise. Either way, still excited to see this. :)
I've and am typing this in Firefox running in an X server in a window on Arcan. The package definition builds an executable called and you can invoke it from a shell prompt in a Durden window to run it. To run a second instance, use . To start an application or window manager in the X server from a shell prompt, set first as in . It doesn't automatically detect when its window size changes, but works. The font path part of the derivation isn't right. I made two attempts at making it work and left them both in the derivation. The code in puts a font path into the configure flag provided for that purpose, but the resulting executable can't find the fonts. The other chunk of code in links fonts into the derivation, and that part gets the truetype fonts to work but not the bitmap fonts. I'm happy to run so I stopped there, but someone who knows more about X fonts than me should take a look.
I was curious about the various Arcan tools (clipboard, image viewer, network proxy, wayland bridge) so I packaged them. There had been a lot of change in the tools directory between the last release and master, so I packaged the tools from master. So the latest commit in adds , and several child packages under . I haven't figured out how to get the Wayland bridge to work, but I wasn't using Wayland before this so may be missing something obvious. I have been running and with Durden on my laptop for about a week now and am finding it very usable and stable.
Hey there and Wish I had found this thread earlier. I had a go at packaging Arcan at . It builds, however it still has some rough edges at runtime (most glaringly, mouse and keyboard don't work if not running as root - addressing that now). I'm going to study what the two of you have discovered so far, and maybe we can join forces in bringing this very interesting piece of software to the Nix ecosystem.
Hey I've just updated with a commit to make it build more recent versions of and . I've had no problems with but the recent litters the screen with mouse cursor trails. It would be great to get it running not as root so keep us posted on your progress.
To get the keyboard and mouse to work when not running as root, just add the user running to the group.
thanks, that worked! I brushed the dust off my Arcan/Nix code just to try out your suggestion. Now I have Arcan, its core utilities and the example compositors (except which fails to find something or other) running on my system, including a terminal - one more thing to run besides , , or in a vanilla console! Neat! I skipped the whole overlays thing and ended up with a file that can be submitted to Nixpkgs (or imported into ). Guess I should share that part of my config as a gist or something before submitting a PR? Or is there something missing, as might be suggested by Food for thought a.k.a. "and then what?": Port my i3 keys to a fork of Durden, ripping some features from Prio to finally organize my daily terminal-browser-devtools grind in a sane way :grin: We have a powerful engine on our hands and a whole lot of Lua ricing to do. Would be cool if some logic from can be ported over to an environment outside X.
Gist: (Sure is cool how Durden and Prio have different mouse capture behavior btw)
I marked this as stale due to inactivity. →
There is still some good progress over at the gist.
I found this while looking into a new project (, ) posted to today. (By same developers as arcan, and uses arcan, so I was curious if we had it packaged.) Just cross-referencing on the off-chance it helps anyone here. I'll also add this to the gist.

gtk = gtk2; }; <ins> arcan = recurseIntoAttrs (callPackage ../desktops/arcan { callPackage = newScope pkgs.arcan; }); </ins> xfce = recurseIntoAttrs (callPackage ../desktops/xfce { }); xrandr-invert-colors = callPackage ../applications/misc/xrandr-invert-colors { };


Question:
Data that was once config and recorded on doesn't get updated when the configuration changes. This is a violation of purity. And more than that, it's very surprising when trying to install, hesitating between pgsql and sqlite, and struggling before understanding that the configuration doesn't get used anyway :p cc
that's a bit tough. We have a unit, that's supposed to do the installation. We use the command to install nextcloud (passing the configured database and adminpass settings as command parameters). This CLI generates , and installs nextcloud. The script checks the presence of , and skips installation on following starts. If you now change configuration from the module, we won't run the install command again, as the config file already exists, and assumes nextcloud is already installed.
Hmm… Maybe it would be possible to generate the somewhere in the store, and symlink to it? This way the next time runs it can in addition check whether points to the correct store path. Now, I don't really know what exactly does, so maybe it's not actually possible to do this because eg. one would need to re-run on certain configuration changes? In which case it'd be hard :/ but at least we can maybe make fail or something like that, so that the issue is at least noisy?
I don't recommend to do this, I just tried that (after upgrading one of my personal systems) and this tries to recreate a database schema which can end in very bad results. Unfortunately I doubt that this will work properly, nextcloud wants to merge this during the runtime. E.g. it adds a after a successful or adds trusted domains when running the corresponding command. I'm using this as well now and hitting these issues, unfortunately I don't have useful ideas either ATM, but I'm happy to discuss better solutions :)
Nextcloud edits it's in a lot of different places, so having it generated through Nix currently isn't possible. digs into that already, I a comments about our use case here too.
to avoid other people running into the reconfiguration issue for now, what about documenting that, maybe in ?
That's certainly a good thing to do. If nobody else wants to take over, I'd volunteer to do this during the next week as investing time on improving the nextcloud module is one item on my todo list :) I was aware of being stateful, but thanks a lot for linking the corresponding ticket! I'll have a look at this as soon as I have sufficient time to :)
In the light of this issue, what's the correct way to upgrade nextcloud to a new major version? Do I just pull a newer , upgrade my system and hope that the systemd job will do the right thing?
The service runs an that should apply all changes like database migrations needed for the new Nextcloud version (beware, downgrades aren't possible). As long as you let Nextcloud do its job, you shouldn't get that much issues. IMHO the actual problem here is the configuration of the software within Nix(OS).
just a simple question (could not come to a conclusion after the lengthy thread) but I recently updated my nextcloud via nixops deploy and the update disabled the calendar module. Did I mess up or is that expected ? any way to configure this from nix ?
Assuming that you installed the calendar module via the UI, it is installed in . The beginning of my config reads: So in principle nextcloud can edit the apps installed via the web interface (otherwise you couldn't install them via the interface in the first place).
I don't think there's anything actionable here - the nextcloud nixos module is limited by how Nextcloud (imperatively) manages its configuration. The current state is properly documented in , and we raised our concerns to upstream in - closing this issue, feel free to reopen if there's more to be done.
I think one actionable item would be to have the nextcloud service fail with an explicit error if the configuration being used is not compatible with the configuration defined in the .nix. At least the user would be warned in practice that configuration is not really applied, and not only by the manual that they are relatively unlikely to actually read. Reopening for now, feel free to reclose if you think that's not a reasonable “solution” :)
The problem is we don't know whether the configuration on disk containing database connection information () differs from the one that would be generated through an installation via - we don't render the configuration on our own, but the installer writes it out as a side-effect. If I'm not missing something obvious, checking configuration changes would translate to parsing/evaluating on every nextcloud startup as an , comparing every "interesting" key with the one provided through nixos configuration, and eventually then bailing out if they differ. I'm not sure if that's a road we'd like to go and keep up to date, while the underlying bug is a missing distinction between configuration and state upstream…
Since upstream mixes state and config it's questionable whether their configuration format is somehow supposed to be backwards-compatible (as it's only supposed to be used internally by Nextcloud). Hence I'm afraid that this will make i.e. upgrades even harder in case of configuration changes, so :-1: from me. As the issues are documented in the manual now, folks are warned and I think that this is a better option in contrast to adding more complexity to . I suggest we either close this for the reasons already stated or wait for an appropriate upstream fix.
I really don't feel good having stuff in that's actually a disguised command line… :/ Something that would sound nicer to me would be an executable that the user would have to manually run, and a bare-bones module that does not handle setup or configuration and just makes sure that the systemd unit is setup. At least the error is obvious (enabling the module without having run the executable would fail), all module options actually mean something, and the impure operation is made explicit. Either that or, similar to , rename all the options so it's explicit that they're used only for initial configuration. Would one of these solutions make sense to you?
Me neither, but currently we don't have much choice… I really like the fact that we can set up the Nextcloud instance in an unattended fashion, without having to worry about manual setting things up. I really don't want to end with more imperative setup steps than necessary. In theory, we could move some of the options in to to make it more obvious what isn't applied continuously. But TBH, I'd rather like to see the state/config mixing fixed upstream than having to introduce more mental complexity here, especially if this gets fixed and we end up with both incarnations. Really, this issue only occurs while a user changes nextcloud database parameters (mostly while tweaking his initial setup), and not having read the module documentation, where the behaviour is documented. What about adding the following (subtile) log statement, to point users to the docs when they peek into the logs while things are not working as expected?
I agree that the log statement is the minimum we can do, and would at least give a hint about the way in which things are broken. Now, I guess the reason we're kind of disagreeing on the path forward is that you're much more hopeful than me that nextcloud will ever fix its stuff -- I'm assuming it'll get fixed in years at best (and even then…) -- and if it's in years then I'd much rather live with for years then spend a year deprecating it by making it conflict with new options than try to live with from now on and have users fail to understand what is going on. Now urhm, I'm investigating the module a bit deeper, and… is there any reason we can't put the database configuration etc. in ? We could then refresh on each activation, and it should be enough? If we have a way to couple it with something that automatically runs iff the database is not ready yet then the setup would actually be… almost perfect?
After having a deeper look at the sources ( at github, (6 commits ahead of v16.0.0RC1)) I guess that this should be possible (I didn't test it yet though). Configs will be loaded from using PHP's function[1] while all files ending with will be taken into account. Hence works as all config arrays will be merged together. This config will be loaded at [2] and is available as which is then used in the DI container[3]. If I understand the code correctly, I assume that it should be possible to render all config options in as config files found by glob will override values from [4]. [4]
Nice catch! This might indeed be possible - we should make very sure that config overrides work the way we think they will - seems to write the merged configuration, and not just the overrides (and merging this with other config in the wrong order can lead to wonderfully weird to debug issues) ;-) While I'd still prefer nextcloud splitting config and state properly, and being able to cope with read-only (base) config - it might be a direction worth exploring. What do you think?
Well, for the record it was actually idea :sweat_smile: I guess so, all the stuff from is also in my at the moment. I'll probably have sufficient time next weekend to check if I can trigger such a case. I can't promise that, but unless anybody beats me, I can hopefully prepare a fix for this :)
Did you gain some new insights on this?
Unfortunately not... I was pretty busy back then. But as this only requires some fiddling in the module and no patching of the actual package, the change shouldn't be too painful, so if you'd like to take over... :sweat_smile:
there's with a fix now :)

The <literal>tomcat-connector</literal> <literal>httpd.extraSubservice</literal> has been removed from nixpkgs. </para> </listitem> <ins> <listitem> <para> It's now possible to change configuration in <link linkend="opt-services.nextcloud.enable">services.nextcloud</link> after the initial deploy since all config parameters are persisted in an additional config file generated by the module. Previously core configuration like database parameters were set using their imperative installer after creating <literal>/var/lib/nextcloud</literal>. </para> </listitem> </ins> </itemizedlist> </section> </section>


Question:
Data that was once config and recorded on doesn't get updated when the configuration changes. This is a violation of purity. And more than that, it's very surprising when trying to install, hesitating between pgsql and sqlite, and struggling before understanding that the configuration doesn't get used anyway :p cc
that's a bit tough. We have a unit, that's supposed to do the installation. We use the command to install nextcloud (passing the configured database and adminpass settings as command parameters). This CLI generates , and installs nextcloud. The script checks the presence of , and skips installation on following starts. If you now change configuration from the module, we won't run the install command again, as the config file already exists, and assumes nextcloud is already installed.
Hmm… Maybe it would be possible to generate the somewhere in the store, and symlink to it? This way the next time runs it can in addition check whether points to the correct store path. Now, I don't really know what exactly does, so maybe it's not actually possible to do this because eg. one would need to re-run on certain configuration changes? In which case it'd be hard :/ but at least we can maybe make fail or something like that, so that the issue is at least noisy?
I don't recommend to do this, I just tried that (after upgrading one of my personal systems) and this tries to recreate a database schema which can end in very bad results. Unfortunately I doubt that this will work properly, nextcloud wants to merge this during the runtime. E.g. it adds a after a successful or adds trusted domains when running the corresponding command. I'm using this as well now and hitting these issues, unfortunately I don't have useful ideas either ATM, but I'm happy to discuss better solutions :)
Nextcloud edits it's in a lot of different places, so having it generated through Nix currently isn't possible. digs into that already, I a comments about our use case here too.
to avoid other people running into the reconfiguration issue for now, what about documenting that, maybe in ?
That's certainly a good thing to do. If nobody else wants to take over, I'd volunteer to do this during the next week as investing time on improving the nextcloud module is one item on my todo list :) I was aware of being stateful, but thanks a lot for linking the corresponding ticket! I'll have a look at this as soon as I have sufficient time to :)
In the light of this issue, what's the correct way to upgrade nextcloud to a new major version? Do I just pull a newer , upgrade my system and hope that the systemd job will do the right thing?
The service runs an that should apply all changes like database migrations needed for the new Nextcloud version (beware, downgrades aren't possible). As long as you let Nextcloud do its job, you shouldn't get that much issues. IMHO the actual problem here is the configuration of the software within Nix(OS).
just a simple question (could not come to a conclusion after the lengthy thread) but I recently updated my nextcloud via nixops deploy and the update disabled the calendar module. Did I mess up or is that expected ? any way to configure this from nix ?
Assuming that you installed the calendar module via the UI, it is installed in . The beginning of my config reads: So in principle nextcloud can edit the apps installed via the web interface (otherwise you couldn't install them via the interface in the first place).
I don't think there's anything actionable here - the nextcloud nixos module is limited by how Nextcloud (imperatively) manages its configuration. The current state is properly documented in , and we raised our concerns to upstream in - closing this issue, feel free to reopen if there's more to be done.
I think one actionable item would be to have the nextcloud service fail with an explicit error if the configuration being used is not compatible with the configuration defined in the .nix. At least the user would be warned in practice that configuration is not really applied, and not only by the manual that they are relatively unlikely to actually read. Reopening for now, feel free to reclose if you think that's not a reasonable “solution” :)
The problem is we don't know whether the configuration on disk containing database connection information () differs from the one that would be generated through an installation via - we don't render the configuration on our own, but the installer writes it out as a side-effect. If I'm not missing something obvious, checking configuration changes would translate to parsing/evaluating on every nextcloud startup as an , comparing every "interesting" key with the one provided through nixos configuration, and eventually then bailing out if they differ. I'm not sure if that's a road we'd like to go and keep up to date, while the underlying bug is a missing distinction between configuration and state upstream…
Since upstream mixes state and config it's questionable whether their configuration format is somehow supposed to be backwards-compatible (as it's only supposed to be used internally by Nextcloud). Hence I'm afraid that this will make i.e. upgrades even harder in case of configuration changes, so :-1: from me. As the issues are documented in the manual now, folks are warned and I think that this is a better option in contrast to adding more complexity to . I suggest we either close this for the reasons already stated or wait for an appropriate upstream fix.
I really don't feel good having stuff in that's actually a disguised command line… :/ Something that would sound nicer to me would be an executable that the user would have to manually run, and a bare-bones module that does not handle setup or configuration and just makes sure that the systemd unit is setup. At least the error is obvious (enabling the module without having run the executable would fail), all module options actually mean something, and the impure operation is made explicit. Either that or, similar to , rename all the options so it's explicit that they're used only for initial configuration. Would one of these solutions make sense to you?
Me neither, but currently we don't have much choice… I really like the fact that we can set up the Nextcloud instance in an unattended fashion, without having to worry about manual setting things up. I really don't want to end with more imperative setup steps than necessary. In theory, we could move some of the options in to to make it more obvious what isn't applied continuously. But TBH, I'd rather like to see the state/config mixing fixed upstream than having to introduce more mental complexity here, especially if this gets fixed and we end up with both incarnations. Really, this issue only occurs while a user changes nextcloud database parameters (mostly while tweaking his initial setup), and not having read the module documentation, where the behaviour is documented. What about adding the following (subtile) log statement, to point users to the docs when they peek into the logs while things are not working as expected?
I agree that the log statement is the minimum we can do, and would at least give a hint about the way in which things are broken. Now, I guess the reason we're kind of disagreeing on the path forward is that you're much more hopeful than me that nextcloud will ever fix its stuff -- I'm assuming it'll get fixed in years at best (and even then…) -- and if it's in years then I'd much rather live with for years then spend a year deprecating it by making it conflict with new options than try to live with from now on and have users fail to understand what is going on. Now urhm, I'm investigating the module a bit deeper, and… is there any reason we can't put the database configuration etc. in ? We could then refresh on each activation, and it should be enough? If we have a way to couple it with something that automatically runs iff the database is not ready yet then the setup would actually be… almost perfect?
After having a deeper look at the sources ( at github, (6 commits ahead of v16.0.0RC1)) I guess that this should be possible (I didn't test it yet though). Configs will be loaded from using PHP's function[1] while all files ending with will be taken into account. Hence works as all config arrays will be merged together. This config will be loaded at [2] and is available as which is then used in the DI container[3]. If I understand the code correctly, I assume that it should be possible to render all config options in as config files found by glob will override values from [4]. [4]
Nice catch! This might indeed be possible - we should make very sure that config overrides work the way we think they will - seems to write the merged configuration, and not just the overrides (and merging this with other config in the wrong order can lead to wonderfully weird to debug issues) ;-) While I'd still prefer nextcloud splitting config and state properly, and being able to cope with read-only (base) config - it might be a direction worth exploring. What do you think?
Well, for the record it was actually idea :sweat_smile: I guess so, all the stuff from is also in my at the moment. I'll probably have sufficient time next weekend to check if I can trigger such a case. I can't promise that, but unless anybody beats me, I can hopefully prepare a fix for this :)
Did you gain some new insights on this?
Unfortunately not... I was pretty busy back then. But as this only requires some fiddling in the module and no patching of the actual package, the change shouldn't be too painful, so if you'd like to take over... :sweat_smile:
there's with a fix now :)

systemd.services = { "nextcloud-setup" = let <ins> c = cfg.config; writePhpArrary = a: "[${concatMapStringsSep "," (val: ''"${toString val}"'') a}]"; </ins> overrideConfig = pkgs.writeText "nextcloud-config.php" '' <?php <ins> ${optionalString (c.dbpassFile != null) '' function nix_read_pwd() { $file = "${c.dbpassFile}"; if (!file_exists($file)) { throw new RuntimeException(sprintf( "Cannot start Nextcloud, dbpass file %s set by NixOS doesn't exist!", $file )); } return trim(file_get_contents($file)); } ''} </ins> $CONFIG = [ 'apps_paths' => [ [ 'path' => '${cfg.home}/apps', 'url' => '/apps', 'writable' => false ],


Question:
Data that was once config and recorded on doesn't get updated when the configuration changes. This is a violation of purity. And more than that, it's very surprising when trying to install, hesitating between pgsql and sqlite, and struggling before understanding that the configuration doesn't get used anyway :p cc
that's a bit tough. We have a unit, that's supposed to do the installation. We use the command to install nextcloud (passing the configured database and adminpass settings as command parameters). This CLI generates , and installs nextcloud. The script checks the presence of , and skips installation on following starts. If you now change configuration from the module, we won't run the install command again, as the config file already exists, and assumes nextcloud is already installed.
Hmm… Maybe it would be possible to generate the somewhere in the store, and symlink to it? This way the next time runs it can in addition check whether points to the correct store path. Now, I don't really know what exactly does, so maybe it's not actually possible to do this because eg. one would need to re-run on certain configuration changes? In which case it'd be hard :/ but at least we can maybe make fail or something like that, so that the issue is at least noisy?
I don't recommend to do this, I just tried that (after upgrading one of my personal systems) and this tries to recreate a database schema which can end in very bad results. Unfortunately I doubt that this will work properly, nextcloud wants to merge this during the runtime. E.g. it adds a after a successful or adds trusted domains when running the corresponding command. I'm using this as well now and hitting these issues, unfortunately I don't have useful ideas either ATM, but I'm happy to discuss better solutions :)
Nextcloud edits it's in a lot of different places, so having it generated through Nix currently isn't possible. digs into that already, I a comments about our use case here too.
to avoid other people running into the reconfiguration issue for now, what about documenting that, maybe in ?
That's certainly a good thing to do. If nobody else wants to take over, I'd volunteer to do this during the next week as investing time on improving the nextcloud module is one item on my todo list :) I was aware of being stateful, but thanks a lot for linking the corresponding ticket! I'll have a look at this as soon as I have sufficient time to :)
In the light of this issue, what's the correct way to upgrade nextcloud to a new major version? Do I just pull a newer , upgrade my system and hope that the systemd job will do the right thing?
The service runs an that should apply all changes like database migrations needed for the new Nextcloud version (beware, downgrades aren't possible). As long as you let Nextcloud do its job, you shouldn't get that much issues. IMHO the actual problem here is the configuration of the software within Nix(OS).
just a simple question (could not come to a conclusion after the lengthy thread) but I recently updated my nextcloud via nixops deploy and the update disabled the calendar module. Did I mess up or is that expected ? any way to configure this from nix ?
Assuming that you installed the calendar module via the UI, it is installed in . The beginning of my config reads: So in principle nextcloud can edit the apps installed via the web interface (otherwise you couldn't install them via the interface in the first place).
I don't think there's anything actionable here - the nextcloud nixos module is limited by how Nextcloud (imperatively) manages its configuration. The current state is properly documented in , and we raised our concerns to upstream in - closing this issue, feel free to reopen if there's more to be done.
I think one actionable item would be to have the nextcloud service fail with an explicit error if the configuration being used is not compatible with the configuration defined in the .nix. At least the user would be warned in practice that configuration is not really applied, and not only by the manual that they are relatively unlikely to actually read. Reopening for now, feel free to reclose if you think that's not a reasonable “solution” :)
The problem is we don't know whether the configuration on disk containing database connection information () differs from the one that would be generated through an installation via - we don't render the configuration on our own, but the installer writes it out as a side-effect. If I'm not missing something obvious, checking configuration changes would translate to parsing/evaluating on every nextcloud startup as an , comparing every "interesting" key with the one provided through nixos configuration, and eventually then bailing out if they differ. I'm not sure if that's a road we'd like to go and keep up to date, while the underlying bug is a missing distinction between configuration and state upstream…
Since upstream mixes state and config it's questionable whether their configuration format is somehow supposed to be backwards-compatible (as it's only supposed to be used internally by Nextcloud). Hence I'm afraid that this will make i.e. upgrades even harder in case of configuration changes, so :-1: from me. As the issues are documented in the manual now, folks are warned and I think that this is a better option in contrast to adding more complexity to . I suggest we either close this for the reasons already stated or wait for an appropriate upstream fix.
I really don't feel good having stuff in that's actually a disguised command line… :/ Something that would sound nicer to me would be an executable that the user would have to manually run, and a bare-bones module that does not handle setup or configuration and just makes sure that the systemd unit is setup. At least the error is obvious (enabling the module without having run the executable would fail), all module options actually mean something, and the impure operation is made explicit. Either that or, similar to , rename all the options so it's explicit that they're used only for initial configuration. Would one of these solutions make sense to you?
Me neither, but currently we don't have much choice… I really like the fact that we can set up the Nextcloud instance in an unattended fashion, without having to worry about manual setting things up. I really don't want to end with more imperative setup steps than necessary. In theory, we could move some of the options in to to make it more obvious what isn't applied continuously. But TBH, I'd rather like to see the state/config mixing fixed upstream than having to introduce more mental complexity here, especially if this gets fixed and we end up with both incarnations. Really, this issue only occurs while a user changes nextcloud database parameters (mostly while tweaking his initial setup), and not having read the module documentation, where the behaviour is documented. What about adding the following (subtile) log statement, to point users to the docs when they peek into the logs while things are not working as expected?
I agree that the log statement is the minimum we can do, and would at least give a hint about the way in which things are broken. Now, I guess the reason we're kind of disagreeing on the path forward is that you're much more hopeful than me that nextcloud will ever fix its stuff -- I'm assuming it'll get fixed in years at best (and even then…) -- and if it's in years then I'd much rather live with for years then spend a year deprecating it by making it conflict with new options than try to live with from now on and have users fail to understand what is going on. Now urhm, I'm investigating the module a bit deeper, and… is there any reason we can't put the database configuration etc. in ? We could then refresh on each activation, and it should be enough? If we have a way to couple it with something that automatically runs iff the database is not ready yet then the setup would actually be… almost perfect?
After having a deeper look at the sources ( at github, (6 commits ahead of v16.0.0RC1)) I guess that this should be possible (I didn't test it yet though). Configs will be loaded from using PHP's function[1] while all files ending with will be taken into account. Hence works as all config arrays will be merged together. This config will be loaded at [2] and is available as which is then used in the DI container[3]. If I understand the code correctly, I assume that it should be possible to render all config options in as config files found by glob will override values from [4]. [4]
Nice catch! This might indeed be possible - we should make very sure that config overrides work the way we think they will - seems to write the merged configuration, and not just the overrides (and merging this with other config in the wrong order can lead to wonderfully weird to debug issues) ;-) While I'd still prefer nextcloud splitting config and state properly, and being able to cope with read-only (base) config - it might be a direction worth exploring. What do you think?
Well, for the record it was actually idea :sweat_smile: I guess so, all the stuff from is also in my at the moment. I'll probably have sufficient time next weekend to check if I can trigger such a case. I can't promise that, but unless anybody beats me, I can hopefully prepare a fix for this :)
Did you gain some new insights on this?
Unfortunately not... I was pretty busy back then. But as this only requires some fiddling in the module and no patching of the actual package, the change shouldn't be too painful, so if you'd like to take over... :sweat_smile:
there's with a fix now :)

${optionalString cfg.caching.apcu "'memcache.local' => 'OCMemcacheAPCu',"} 'log_type' => 'syslog', 'log_level' => '${builtins.toString cfg.logLevel}', <del> ${optionalString (cfg.config.overwriteProtocol != null) "'overwriteprotocol' => '${cfg.config.overwriteProtocol}',"} </del> <ins> ${optionalString (c.overwriteProtocol != null) "'overwriteprotocol' => '${c.overwriteProtocol}',"} ${optionalString (c.dbname != null) "'dbname' => '${c.dbname}',"} ${optionalString (c.dbhost != null) "'dbhost' => '${c.dbhost}',"} ${optionalString (c.dbport != null) "'dbport' => '${toString c.dbport}',"} ${optionalString (c.dbuser != null) "'dbuser' => '${c.dbuser}',"} ${optionalString (c.dbtableprefix != null) "'dbtableprefix' => '${toString c.dbtableprefix}',"} ${optionalString (c.dbpass != null) "'dbpassword' => '${c.dbpass}',"} ${optionalString (c.dbpassFile != null) "'dbpassword' => nix_read_pwd(),"} 'dbtype' => '${c.dbtype}', 'trusted_domains' => ${writePhpArrary c.extraTrustedDomains}, </ins> ]; ''; occInstallCmd = let <del> c = cfg.config; adminpass = if c.adminpassFile != null then ''"$(<"${toString c.adminpassFile}")"'' else ''"${toString c.adminpass}"''; </del> dbpass = if c.dbpassFile != null then ''"$(<"${toString c.dbpassFile}")"'' else if c.dbpass != null then ''"${toString c.dbpass}"'' else null; <ins> adminpass = if c.adminpassFile != null then ''"$(<"${toString c.adminpassFile}")"'' else ''"${toString c.adminpass}"''; </ins> installFlags = concatStringsSep " n    " (mapAttrsToList (k: v: "${k} ${toString v}") { "--database" = ''"${c.dbtype}"'';