├── README.org └── flatpaks.org /README.org: -------------------------------------------------------------------------------- 1 | #+TITLE: GUIX Shell examples 2 | #+OPTIONS: toc:2 3 | #+STARTUP: show3levels 4 | 5 | Running a [[https://guix.gnu.org/][GNU Guix]] system as main operating system generally works for me. However, I have the requirement to run some software that is not available in Guix. Although it's generally possible (but not the Guix-way) to create packages from proprietary software, where source code is unavailable, creating a Guix package is not trivial or not feasible in some cases. 6 | 7 | I use this file to describe and finally extract my frequently used Guix shell calls into separate script files to my ~$HOME/.local/bin/~ directory (which is part of my ~$PATH~), by using the ~org-babel-tangle-file~ function of Emacs's wonderful [[https://orgmode.org/][org mode]]. 8 | 9 | * Java on Guix 10 | :PROPERTIES: 11 | #+PROPERTY: header-args:shell :results output verbatim :exports both :tangle no :eval never-export 12 | :END: 13 | 14 | I had some problems when I tried to build or run Java programs on my [[https://guix.gnu.org/][GNU Guix]] system. As with other OSs and Linuxes, Java frequently needs some special attention, since there are Java programs that rely on specific Java versions. Although backwards compatibility is possible in general, there are cases where an application refuses (sometimes by intention) to run on an outdated or a too new Java version. Therefore, it frequently becomes necessary to switch between different Java versions in order to run different programs. 15 | This is where the beauty of guix shell comes into play. We don't switch between different installed Java versions, but we define the individual environment, in which a Java program feels comfortable. The downside is, that we have to figure out, how the environment should look like for each program. The results of my attempts to define specific environments are documented here. I'm aware that maybe I am the only person in the world trying to run some of the examples on a GNU Guix system. However, the examples may serve to let others understand which tweaks can be helpful. 16 | 17 | ** Java versions in GNU Guix 18 | 19 | In GNU Guix there is a broad range of versions of Open Source Java implementations, namely JDKs (Java Development Kits) and their respective JREs (Java Runtime Environments) available. 20 | 21 | Versions (9+) of OpenJDK are available via package ~openjdk~. As of [2023-11-11 Sat], these are: 22 | 23 | #+begin_src shell :exports both 24 | guix show openjdk | grep version 25 | #+end_src 26 | 27 | #+RESULTS: 28 | | version: | 21 | 29 | | version: | 20 | 30 | | version: | 19.0.2 | 31 | | version: | 18.0.2 | 32 | | version: | 17.0.5 | 33 | | version: | 16.0.2 | 34 | | version: | 15.0.9 | 35 | | version: | 14.0.2 | 36 | | version: | 13.0.13 | 37 | | version: | 12.33 | 38 | | version: | 11.0.17 | 39 | | version: | 10.46 | 40 | | version: | 9.181 | 41 | 42 | The available ~icedtea~ packages are: 43 | 44 | #+begin_src shell :exports both 45 | guix show icedtea | grep version 46 | #+end_src 47 | 48 | #+RESULTS: 49 | | version: | 3.19.0 | 50 | | version: | 2.6.13 | 51 | 52 | Java 1.8 is provided by the package ~icedtea~ version 3.19.0: 53 | 54 | #+begin_src shell :prologue "exec 2>&1" :epilogue ":" :exports both 55 | guix shell icedtea@3.19.0 -- java -version 56 | #+end_src 57 | 58 | #+RESULTS: 59 | : openjdk version "1.8.0_292" 60 | : OpenJDK Runtime Environment (IcedTea 3.19.0) (guix build 1.8.0_292-b10) 61 | : OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode) 62 | 63 | Java 1.7 is provided in the package ~icedtea~ version 2.6.13: 64 | 65 | #+begin_src shell :prologue "exec 2>&1" :epilogue ":" :exports both 66 | guix shell icedtea@2.6.13 -- java -version 67 | #+end_src 68 | 69 | #+RESULTS: 70 | : java version "1.7.0_171" 71 | : OpenJDK Runtime Environment (IcedTea 2.6.13) (linux-gnu build 1.7.0_171-b02) 72 | : OpenJDK 64-Bit Server VM (build 24.171-b02, mixed mode) 73 | 74 | 75 | Unfortunately, in most cases it is not sufficient to just install a recent version of OpenJDK. Furthermore this does not allow for different versions to exist in parallel. A simple ~guix shell~ with the appropriate package added, does also not suffice, as the following examples demonstrate. Especially with desktop programs additional tweaks are required. 76 | 77 | However, a basic shell with OpenJDK 21 (JDK) is started with: 78 | #+begin_src shell :shebang #!/bin/sh :tangle ~/.local/bin/guix-shell-java21.sh 79 | export JAVA_HOME=$(guix build openjdk@21 | grep "\-jdk$") 80 | guix shell openjdk@21:jdk 81 | #+end_src 82 | 83 | A basic shell with OpenJDK 21 (JDK) and FHS is started with: 84 | #+begin_src shell :shebang #!/bin/sh :tangle ~/.local/bin/guix-shell-java21-fhs.sh 85 | export JAVA_HOME=$(guix build openjdk@21 | grep "\-jdk$") 86 | guix shell \ 87 | --container --emulate-fhs --network \ 88 | --share=$HOME --preserve=$JAVA_HOME \ 89 | coreutils openjdk@21:jdk 90 | #+end_src 91 | 92 | ** DONE Building Java Programs 93 | 94 | Maven version in GNU Guix is 3.8.6. (Some) Tested projects require Java 17. Guix's ~maven@3.8.6~ does not like (aka run with) Guix's ~openjdk@17.0.5~. Therefore, I downloaded a recent Maven version from Maven's homepage, extracted it and added the binary to my ~$PATH~. I added ~--preserve='^PATH$~ and the package ~openjdk@17.0.5:jdk~ to a container shell and was then able to use that downloaded Maven version inside the container. So far so good. 95 | I was not really happy with that, therefore I decided to add a [[https://maven.apache.org/wrapper/][Maven Wrapper]] to the project, I needed a recent Maven version for. I used the maven container shell created as described above, but you can do this even without having Maven installed at all. So I don't use my downloaded Maven version anymore. 96 | It's probably generally a good idea to add wrapper scripts to your projects' sources like ~mvnw~ or ~gradlew~. These scripts fetch from the internet some defined version of Maven and Gradle respectively and you don't need to install these build systems locally in you operating system. That way the source defines, the build environment (e.g. the version of maven to use). However, this is not the Guix way, since you never know for sure the contents of the blobs, these wrapper download from the internet. On the other side, these build systems are designed to load the dependencies of the projects as binary blobs from internet like [[https://mvnrepository.com/]] anyways. So you never really know for sure, what you are downloading and running with the integration tests the build systems run. 97 | 98 | *** Building CARiSMA with Maven 99 | - CARiSMA (https://github.com/CARiSMA-Tool/carisma-tool) requires Java 17+ [2023-11-10 Fri] 100 | - CARiSMA (now) includes a Maven wrapper script, therefore local installation of a specific Maven version became unnecessary. 101 | - The Maven wrapper script ~mvnw~ complains about ~JAVA_HOME~, if not set. 102 | - Build succeeds with the following shell: 103 | 104 | #+begin_src shell :shebang #!/bin/sh :tangle ~/.local/bin/guix-shell-java17-mvnw.sh 105 | export JAVA_HOME=$(guix build openjdk@17.0.5 | grep "\-jdk$") 106 | cd ~/git/carisma-tool 107 | guix shell openjdk@17.0.5:jdk -- ./mvnw clean verify 108 | #+end_src 109 | 110 | *** Building Camunda BPM with Maven 111 | - Tested with 7.20.0 from git [2023-11-10 Fri] 112 | - Camunda BPM 7.20.0 requires Java version 11 or 17 [https://docs.camunda.org/manual/7.20/introduction/supported-environments/#java-runtime] 113 | - Camunda needs ~libstdc++~, which is made available to a container shell via ~-e '(list (@@ (gnu packages commencement) gcc) "lib")'~. 114 | - According to podiki in IRC chat, this is a temporary workaround (https://logs.guix.gnu.org/guix/2023-11-09.log) to add the previous ~lib~ output of ~gcc~ package, which is in transition to a new package ~gcc-toolchain~. 115 | - The corresponding issue is https://issues.guix.gnu.org/63393 116 | - Maven wrapper likes to use ~which~, therefore it's added to the container. Additionally the Maven Wrapper warns about ~JAVA_HOME~ not being set, therefore just set it like in the following example. 117 | - Camunda needs ~bash~ executable to build, therefore it's added to the container. 118 | - The maven wrapper script does run without FHS, but Camunda BPM tries to start a node.js server which seems to not work without FHS. 119 | - Camunda BPM 7.20.0 builds (tests skipped) with Maven using the following shell: [2023-11-10 Fri]: 120 | 121 | #+begin_src shell 122 | export JAVA_HOME=$(guix build openjdk@17.0.5 | grep "\-jdk$") 123 | cd ~/git/camunda-bpm-platform 124 | guix shell \ 125 | --container --emulate-fhs --network \ 126 | --preserve='^JAVA_HOME$' \ 127 | -e '(list (@@ (gnu packages commencement) gcc) "lib")' \ 128 | coreutils openjdk@17.0.5:jdk which bash \ 129 | -- ./mvnw clean package -DskipTests 130 | #+end_src 131 | 132 | *** Building EDC with Gradle 133 | - Clone the [[https://github.com/eclipse-edc/Connector][Eclipse Dataspace Connector]] : ~git clone git@github.com:eclipse-edc/Connector.git~ 134 | - EDC needs Java 17+ (https://github.com/eclipse-edc/docs/blob/main/developer/handbook.md) 135 | - EDC contains a Gradle Wrapper Script, so no local Gradle installation is required. 136 | - EDC needs ~xargs~, which is shipped with package ~findutils~ 137 | - Gradle throws an error, if ~sed~ is not available 138 | 139 | #+begin_src shell 140 | export JAVA_HOME=$(guix build openjdk@17.0.5 | grep "\-jdk$") 141 | cd ~/git/Connector 142 | guix shell \ 143 | --container --emulate-fhs --network \ 144 | --preserve='^JAVA_HOME$' \ 145 | coreutils openjdk@17.0.5:jdk findutils sed \ 146 | -- ./gradlew clean build 147 | #+end_src 148 | 149 | ** Running Java Programs 150 | *** TODO JabRef 151 | [[https://www.jabref.org/][JabRef]] is also available as flatpak, but I preferred to create a Guix shell for it. So I downloaded and extracted a recent version. This is the file I wanted to run: 152 | 153 | #+begin_src shell :exports both 154 | ls -l ~/Applications/JabRef-5.11/bin/JabRef 155 | file ~/Applications/JabRef-5.11/bin/JabRef 156 | #+end_src 157 | 158 | #+RESULTS: 159 | : -rwxr-xr-x 1 flake users 18568 Oct 22 01:05 /home/flake/Applications/JabRef-5.11/bin/JabRef 160 | : /home/flake/Applications/JabRef-5.11/bin/JabRef: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=6d790541a31635bd38177b4f4d70bcdf422eb827, not stripped 161 | 162 | But this does not work as expected: 163 | 164 | #+begin_src shell :prologue "exec 2>&1" :epilogue ":" :exports both 165 | guix shell openjdk@17.0.5 -- ~/Applications/JabRef-5.11/bin/JabRef 166 | #+end_src 167 | 168 | #+RESULTS: 169 | : guix shell: error: /home/flake/Applications/JabRef-5.11/bin/JabRef: command not found 170 | 171 | Running in a container that complies with the File Hierarchy System (FHS) solves the issue for me. However the container needs additional information and programs to smoothly run JabRef. 172 | 173 | - Without ~xdg-user-dirs~, JabRef complains: 174 | #+begin_src 175 | ERROR: Error while executing xdg-user-dir: java.io.IOException: Cannot run program "xdg-user-dir": error=2, No such file or directory 176 | #+end_src 177 | So I added ~xdg-user-dirs~ to the container and preserved ~XDG_~ environment variables. 178 | - To open links in an external program, JabRef uses ~xdg-open~. Therefore I added ~xdg-utils~. 179 | - I added ~ungoogled-chromium~ to allow JabRef to open internet URLs. Since I am on Wayland, I configured my own chromium profile to use Wayland. JabRef itself runs as X11 application in XWayland. That's why I had to add both environments (Wayland and X) to the container. 180 | 181 | #+begin_src shell :shebang #!/bin/sh :tangle ~/.local/bin/guix-shell-jabref.sh 182 | 183 | guix shell \ 184 | --container --emulate-fhs --network \ 185 | --preserve='^DBUS_' --expose=/var/run/dbus \ 186 | --preserve='^XDG_|^WAYLAND_DISPLAY$' --expose=/run/user \ 187 | --preserve='^DISPLAY$' --expose=/dev/dri --expose=/sys/dev --expose=/sys/devices \ 188 | --share=$HOME \ 189 | coreutils gtk+ openjdk@17.0.5 xdg-utils xdg-user-dirs ungoogled-chromium \ 190 | -- ~/Applications/JabRef-5.11/bin/JabRef 191 | 192 | #+end_src 193 | 194 | **** Remaining issue 195 | 196 | When I want to open a URL from within JabRef, a new chromium window is opened instead of opening a new tab in an already running chromium instance. 197 | 198 | *If you have any solution for these, please let me know.* 199 | 200 | *** TODO Eclipse 201 | Eclipse is also available as flatpak, but I prefer to use a Guix Shell. 202 | 203 | - Eclipse ships its own JDK. Therefore, a local JDK installation is not necessary for running Eclipse. However, current Elipse (2025-03) ships with a jdk 21 and I need OpenJDK 21 for some projects. Therefore, I add OpenJDK 21 to the container shell. 204 | - On a normal GNU Guix system that does not comply to File Hierarchy Standard (FHS), running the binary ~eclipse~ gives a "command not found". One way to solve this, is to run a container shell with ~--emulate-fhs~ parameter. 205 | - Eclipse complains about missing ~libz.so.1~, therefore, I added ~zlib~ to the shell container. 206 | - Eclipse complains about missing ~swt-pi3~. This is solved by adding package ~gtk+~. 207 | - Eclipse needs ~$DISPLAY~ for X11/XWayland or ~$XDG_~ and ~$WAYLAND_DISPLAY~ for Wayland. 208 | - Eclipse complains "Cannot spawn a message bus without a machine-id: Unable to load /gnu/store/...-glib-2.72.3/var/lib/dbus/machine-id or /etc/machine-id:". This is solved by preserving ~$DBUS_~ environment variables and exposing ~/var/run/dbus~. 209 | - In order to let Eclipse connect to accessibility bus, I expose ~/run/user~ to the container. Alternatively you could set ~NO_AT_BRIDGE=1~ to tell Eclipse to not try to access the accessibility bus. 210 | - Eclipse needs WebKit bindings as integrated web browser and for previewing markdown files (and possibly other things). This is solved by adding ~webkitgtk~. Still, Online Help is not available, it results in a window with the message "WebKit encountered a problem". 211 | - During work with Eclipse, some auto completion feature did not work. Instead I got the message ".../.node/node-v18.17.1-linux-x64/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory". 212 | As of [2023-11-09 Thu] a workaround is necessary to add ~libstdc++~ to the shell: The output ~lib~ of ~gcc~ is not available anymore (due to an ongoing transition of package ~gcc~ to ~gcc-toolchain~). One can still add the relevant output via ~-e '(list (@@ (gnu packages commencement) gcc) "lib")'~ . 213 | (According to podiki in IRC chat, this is a temporary workaround (https://logs.guix.gnu.org/guix/2023-11-09.log). Otherwise adding ~gcc-toolchain:lib~ to the packages could be sufficient. See also https://issues.guix.gnu.org/63393) 214 | 215 | **** Eclipse in X11 / XWayland 216 | 217 | #+begin_src shell :shebang #!/bin/sh :tangle ~/.local/bin/guix-shell-eclipse-modeling-2025-03-R-x11.sh 218 | guix shell \ 219 | --container --emulate-fhs --network \ 220 | --share=$HOME --share=/tmp \ 221 | --preserve='^DISPLAY$' --expose=/dev \ 222 | --preserve='^DBUS_' --expose=/var/run/dbus \ 223 | --preserve='^JAVA_HOME$' \ 224 | --expose=/run/user \ 225 | -e '(list (@@ (gnu packages commencement) gcc) "lib")' \ 226 | coreutils zlib gtk+ webkitgtk openjdk@21:jdk webkitgtk librewolf hicolor-icon-theme xcursor-themes \ 227 | -- ~/Applications/eclipse/eclipse-modeling-2025-03-R/eclipse 228 | #+end_src 229 | 230 | **** Eclipse native on Wayland 231 | It is assumed, that ~DBUS_SESSION_BUS_ADDRESS~, ~XDG_RUNTIME_DIR~ and ~WAYLAND_DISPLAY~ are set correctly after launching your compositor. 232 | 233 | #+begin_src shell :shebang #!/bin/sh :tangle ~/.local/bin/guix-shell-eclipse-modeling-2025-03-R-wayland.sh 234 | guix shell \ 235 | --container --emulate-fhs --network \ 236 | --share=$HOME --share=/tmp \ 237 | --preserve='^WAYLAND_DISPLAY$|^XDG_RUNTIME_DIR$' \ 238 | --preserve='^DBUS_' --expose=/var/run/dbus \ 239 | --preserve='^JAVA_HOME$' \ 240 | --expose=/run \ 241 | -e '(list (@@ (gnu packages commencement) gcc) "lib")' \ 242 | coreutils zlib gtk+ webkitgtk openjdk@21:jdk webkitgtk librewolf hicolor-icon-theme xcursor-themes \ 243 | -- ~/Applications/eclipse/eclipse-modeling-2025-03-R/eclipse 244 | #+end_src 245 | 246 | When running as Wayland app, dialog windows (e.g. the startup splash screen) are not set to floating. 247 | 248 | **** Remaining issues while running Eclipse 249 | - An empty window with the message "WebKit encountered a problem" is shown when opening online help 250 | - When running as Wayland app, dialog windows (e.g. the startup splash screen) are not set to floating. 251 | - "(process:256): GLib-GIO-ERROR **: 14:22:45.702: Settings schema 'org.gnome.system.proxy' is not installed" (when opening Eclipse Help Contents) 252 | - "Failed to load cursor theme Adwaita" is shown at startup. 253 | 254 | *If you have any solution for these, please let me know.* 255 | 256 | *** DONE neo4j 257 | 258 | [[https://neo4j.com/][Neo4J Community Edition]] does not make any problems. This is how things should work. Just [[https://neo4j.com/deployment-center/#community][download]] the community edition of neo4j, extract it and run. If a recent OpenJDK is installed, you don't need a shell. Otherwise: 259 | 260 | #+begin_src shell :shebang #!/bin/sh :tangle no 261 | guix shell openjdk@21.0.2 \ 262 | -- ~/Applications/neo4j/bin/neo4j-admin $@ 263 | #+end_src 264 | 265 | *** TODO neo4j desktop 266 | I didn't manage to get neo4j desktop to run in guix. This is my latest shell, I tried with: 267 | 268 | #+begin_src shell 269 | guix shell --container --network --emulate-fhs \ 270 | --preserve='^DBUS_' --expose=/var/run/dbus \ 271 | --preserve='^DISPLAY$' --expose=/dev/dri --expose=/sys/dev --expose=/sys/devices \ 272 | -e '(list (@@ (gnu packages commencement) gcc) "lib")' \ 273 | --share=$HOME --share=/tmp \ 274 | zlib coreutils glib nss atkmm cups libdrm gtk+ alsa-lib mit-krb5 libsecret 275 | #+end_src 276 | 277 | I get an error 278 | 279 | *** DONE Astah (obsolete) 280 | 281 | **** Astah 10.x 282 | - [[https://astah.net/products/astah-professional/][Astah]] 10.0.0 finally runs with modern JDKs, e.g. OpenJDK 21 283 | - I created a package definition and it's made available in my personal [[https://github.com/nuthub/nutguix][Guix channel]]. There was some additional effort required to apply a faculty license to the software. 284 | - It seems that Astah 10.0.0 does not need ~_JAVA_AWT_WM_NONREPARENTING=1~ anymore. 285 | 286 | **** Astah 9.x 287 | - [[https://astah.net/products/astah-professional/][Astah]] 9.1.0 (and also 9.2.0) needed Java [1.8.0_372,1.9). Guix's Java 1.8 version is 1.8.0_292. You can tell Astah to relax the version check by adding the parameter ~-nojvchk~ to the command. 288 | - Without setting ~_JAVA_AWT_WM_NONREPARENTING=1~ Astah does not show any content in its window. 289 | 290 | This shell I used for version 9 of astah is obsolete. Since 10.0.0, I just can run astah-pro, as long as a recent OpenJDK is installed. 291 | #+begin_src shell :tangle no 292 | export _JAVA_AWT_WM_NONREPARENTING=1 293 | guix shell icedtea@3.19.0 \ 294 | -- /home/flake/Applications/astah_professional/astah -nojvchk 295 | #+end_src 296 | 297 | * DONE TOR Browser 298 | 299 | - adopted from https://guix.gnu.org/en/blog/2023/the-filesystem-hierarchy-standard-comes-to-guix-containers/ 300 | 301 | ** on X11 / XWayland 302 | #+begin_src shell 303 | cd ~/Applications/tor-browser 304 | guix shell \ 305 | --container --emulate-fhs --network \ 306 | --share=$HOME \ 307 | --preserve='^DISPLAY$' --expose=/dev \ 308 | --preserve='^DBUS_' --expose=/var/run/dbus \ 309 | --expose=/run/user \ 310 | -e '(list (@@ (gnu packages commencement) gcc) "lib")' \ 311 | coreutils zlib gtk+ webkitgtk alsa-lib bash dbus-glib file grep gtk+ libcxx pciutils sed 312 | #+end_src 313 | 314 | ** on Wayland 315 | #+begin_src shell :tangle ~/.local/bin/guix-shell-tor-browser.sh :shebang #!/bin/sh 316 | cd ~/Applications/tor-browser 317 | guix shell \ 318 | --container --emulate-fhs --network \ 319 | --share=$HOME \ 320 | --preserve='^WAYLAND_DISPLAY$|^XDG_RUNTIME_DIR$' --expose=$XDG_RUNTIME_DIR \ 321 | --preserve='^DBUS_' --expose=/var/run/dbus \ 322 | -e '(list (@@ (gnu packages commencement) gcc) "lib")' \ 323 | alsa-lib bash coreutils dbus-glib file grep gtk+ libcxx pciutils sed \ 324 | -- ./start-tor-browser.desktop -v 325 | #+end_src 326 | 327 | * DONE Draw IO 328 | I downloaded the AppImage from draw.io's [[https://github.com/jgraph/drawio-desktop/releases/][github release page]] and extracted it, renamed the directory and created a link with, e.g.: 329 | 330 | #+begin_src shell 331 | guix shell --container --network --emulate-fhs \ 332 | --share=$HOME \ 333 | zlib coreutils \ 334 | -- ./drawio-x86_64-22.1.2.AppImage --appimage-extract 335 | mv squashfs-root ~/Applications/drawio-x86_64-22.1.2 336 | cd ~/Applications 337 | ln -s drawio-x86_64-22.1.2 drawio 338 | #+end_src 339 | 340 | You could also run a shell with ~...AppImage --appimage-extract-and-run~, but this would extract the AppImage each time you invoke the drawio shell. 341 | 342 | ** on X11 343 | #+begin_src shell :tangle ~/.local/bin/guix-shell-drawio.sh :shebang #!/bin/sh 344 | guix shell --container --network --emulate-fhs \ 345 | --share=$HOME \ 346 | --preserve='^DISPLAY$' --expose=/dev/dri --expose=/sys/dev --expose=/sys/devices \ 347 | --preserve='^DBUS_' --expose=/var/run/dbus \ 348 | --development ungoogled-chromium \ 349 | -e '(list (@@ (gnu packages commencement) gcc) "lib")' \ 350 | zlib coreutils \ 351 | -- ~/Applications/drawio/AppRun $@ 352 | #+end_src 353 | 354 | ** on Wayland 355 | 356 | #+begin_src shell 357 | guix shell --container --network --emulate-fhs \ 358 | --share=$HOME \ 359 | --preserve='^WAYLAND_DISPLAY$|^XDG_' --expose=$XDG_RUNTIME_DIR \ 360 | --preserve='^DBUS_' --expose=/var/run/dbus \ 361 | --development ungoogled-chromium \ 362 | -e '(list (@@ (gnu packages commencement) gcc) "lib")' \ 363 | zlib coreutils \ 364 | -- ~/Applications/drawio/AppRun $@ 365 | #+end_src 366 | 367 | * General hints on containers for desktop programs 368 | 369 | ** X11 / XWayland / Wayland 370 | If you are on an X11 server or you intend to run a program in a container on Wayland that does not run natively on Wayland, and therefore needs to run on XWayland, you need to: 371 | 372 | #+begin_src shell 373 | --preserve='^DISPLAY$' --expose=/dev/dri --expose=/sys/dev --expose=/sys/devices 374 | #+end_src 375 | 376 | If you intend to run a program in a container natively on Wayland you need to: 377 | 378 | #+begin_src shell 379 | --preserve='^WAYLAND_DISPLAY$|^XDG_' --expose=$XDG_RUNTIME_DIR 380 | #+end_src 381 | 382 | ** DBUS 383 | If you need access to running DBUS session(s), you need to: 384 | 385 | #+begin_src shell 386 | --preserve='^DBUS_' --expose=/var/run/dbus 387 | #+end_src 388 | * Additional Information 389 | - https://guix.gnu.org/manual/en/html_node/Invoking-guix-shell.html 390 | - https://guix.gnu.org/en/blog/2021/from-guix-environment-to-guix-shell/ 391 | - https://guix.gnu.org/cookbook/en/html_node/Guix-Containers.html 392 | - https://www.futurile.net/2023/04/29/guix-shell-virtual-environments-containers/ 393 | -------------------------------------------------------------------------------- /flatpaks.org: -------------------------------------------------------------------------------- 1 | * Spotify 2 | 3 | Spotify is available as proprietary, binary package only. Therefore it won't make it into GNU Guix, but maybe someone will package it for nonguix some day. Until then, it can be installed via flatpak. Installing and runnning Spotify as flatpak is straight forward as described on [[https://flathub.org/apps/com.spotify.Client][Flathub]]: 4 | 5 | #+BEGIN_SRC shell 6 | flatpak install flathub com.spotify.Client 7 | flatpak run com.spotify.Client 8 | #+END_SRC 9 | 10 | To run the Spotify from flatpak as wayland app (not via xwayland), add the following parameters to the command: ~--enable-features=WaylandWindowDecorations --ozone-platform=wayland~. 11 | 12 | You can define an alias in .aliases, to launch spotify as native wayland app: 13 | #+BEGIN_SRC shell 14 | alias spotify="flatpak --user run com.spotify.Client --command=spotify --enable-features=WaylandWindowDecorations --ozone-platform=wayland %u" 15 | #+END_SRC 16 | 17 | Additionally, you should the parameters in the .desktop file ~~/.local/share/flatpak/exports/share/applications/com.spotify.Client.desktop~ that is installed by flatpak. The relevant line looks as follows: 18 | 19 | #+begin_src desktop 20 | Exec=flatpak run --branch=stable --arch=x86_64 --command=spotify --file-forwarding com.spotify.Client --enable-features=WaylandWindowDecorations --ozone-platform=wayland @@u %U @@ 21 | #+end_src 22 | 23 | Unfortunately, no ~app_id~ is set, therefore it's difficult to create window rules in sway, for example. 24 | 25 | --------------------------------------------------------------------------------