* nongnu/packages/editors (vscodium): Update to 1.85.2.24019.
[origin]: Download correct binary for different architectures.
[supported-systems]: List all supported architectures.
Signed-off-by: John Kehayias <john.kehayias@protonmail.com>
* nonguix/multiarch-container.scm (make-container-wrapper): Use
ngc-preserved-env.
Signed-off-by: John Kehayias <john.kehayias@protonmail.com>
Co-authored-by: John Kehayias <john.kehayias@protonmail.com>
In order to be able to use WiFi chip in P14s ThinkPad, the mt7921e module is
required. This commit enables it in kernels that do have it.
I originally implemented this using a list of additional option, same way
%default-extra-linux-options is done. However I quickly realized that
approach is not suitable for hardware enablement. The older versions do not
support the same drivers as the newer ones.
Solution is to create a new procedure that generates the list for a specific
kernel version and use it as a default value for #:configs.
* nongnu/packages/linux.scm (nonguix-extra-linux-options): New procedure.
(corrupt-linux): Use it as default value for #:configs.
Signed-off-by: Jonathan Brielmaier <jonathan.brielmaier@web.de>
Following the project's conventions, replace the λ symbol with the lambda
keyword.
* nongnu/packages/mozilla.scm (firefox-esr)
[arguments]<#:phases>['patch-SpeechDispatcherService.cpp]: Use lambda.
Signed-off-by: John Kehayias <john.kehayias@protonmail.com>
Upstream added linux-libre@6.7 in 95a3aaf7ad37bb0717f2c9e3faf6f636b586d133 but
it is not yet the default.
* nongnu/packages/linux.scm (linux-6.7): New variable.
Guix project seems to prefer using lambda over λ. Express that preference for
Geiser users by setting the geiser-insert-actual-lambda variable to nil. In
the 0.31 version it will affect how geiser-insert-lambda works, making it
insert lambda string (instead of the current λ.
* .dir-locals.el (nil): Add geiser-insert-actual-lambda set to nil.
Signed-off-by: Jonathan Brielmaier <jonathan.brielmaier@web.de>
Basic fix for #237.
This allows exposing other directories or drives to the nonguix container, for
example to add additional library locations to Steam, by setting
$GUIX_SANDBOX_EXTRA_SHARES.
* nonguix/multiarch-container.scm (make-container-wrapper): Use environment
variable $GUIX_SANDBOX_EXTRA_SHARES to pass extra directories to share with
the container.
* nongnu/packages/linux.scm (%default-extra-linux-options,config->string):
Move into make-linux-xanmod.
(make-linux-xanmod): Adjust comments.
Move the base kernel produced by customize-linux out of let form.
[native-inputs]: Use prepend instead of append.
Signed-off-by: Jonathan Brielmaier <jonathan.brielmaier@web.de>
* nongnu/packages/linux.scm (make-linux-xanmod-source): Patch upstream linux
source instead of downloading the auto-generated tarball from GitLab.
(make-linux-xanmod)[arguments]<#:phases>: Delete 'remove-localversion, moved
to snippet.
(linux-xanmod-source,linux-xanmod-lts-source): Adjust accordingly.
Signed-off-by: Jonathan Brielmaier <jonathan.brielmaier@web.de>
* nongnu/packages/productivity.scm (anytype): Update to 0.37.3;
[arguments]<phases>: avoid hardcoding the icon path in anytype.desktop.
Signed-off-by: Jonathan Brielmaier <jonathan.brielmaier@web.de>
Fixes#303.
Previously LD_LIBRARY_PATH was being set before the container was launched,
which could cause issues on some foreign distros where this alters what is
loaded from an FHS structure. This was only meant to be set inside the
container, though this didn't cause any issues on a Guix System.
* nonguix/multiarch-container.scm (make-container-wrapper): Move setting
LD_LIBRARY_PATH from here ...
(make-internal-script): ... to here.
Fixes#277.
See discussion in above issue for details and some education on what went
wrong here. In short, we didn't capture the needed (guix build utils) module
in the container script. On a Guix System this didn't cause any problems as
guix modules are found through set Guile environment variables. But on a
foreign distro these weren't set without hacky workarounds. This prevented
Steam from launching with a "no code for module" error.
* nonguix/multiarch-container.scm (make-container-wrapper)[make-container-wrapper]:
Use 'with-imported-modules' for (guix build utils).
The binary-unpack phase suffered from a problem for unknown binary file
extensions, see: !336 (comment 1709385147) . This patch fixes the
incorrect behavior by effectively restoring the state of the directory
tree before the phase.
* nonguix/build/binary-build-system.scm (binary-unpack): Restore the
environment as it was before this phase.
* nongnu/packages/clojure.scm (clj-kondo)[arguments]: No longer delete
'binary-unpack phase.
* nongnu/packages/game-development.scm (libsteam)[arguments]: dito.
Signed-off-by: Jonathan Brielmaier <jonathan.brielmaier@web.de>
* nongnu/packages/game-client.scm (heroic-client, heroic-extra-client-libs,
heroic-container, heroic-nvidia-container, heroic, heroic-nvidia): New
variables.
* nonguix/multi-arch-container.scm (make-container-wrapper): Preserve "^SSL_"
for heroic to use curl.
(make-internal-script): Add symlink for "/usr/share/glib-2.0".
Steam installs .desktop files that refer to an executable called `steam'.
Installing steam-nvidia as the `steam-nvidia' executable breaks this, which
means Steam cannot be launched from its desktop icon. This also applies to
.desktop files for individual games generated by Steam, when they are copied
from `<ngc-sandbox-home>/.local/share/applications/'.
Fix this by always installing Steam's wrapper executable as `steam'. We add a
new field using "binary" to keep things shorter.
This has the downside that the `steam' and `steam-nvidia' packages cannot be
installed in the same profile, but likely people wouldn't want to do this
anyway.
Fixes#294.
* nongnu/packages/steam-client.scm (steam-nvidia-container)[binary-name]:
Specify for compatibility with .desktop files.
* nonguix/multiarch-container.scm (<nonguix-container>)[binary-name,
ngc-binary-name]: New field and accessor.
(nonguix-container->package): Use it to set correct executable name.
(make-internal-script): Use it in message.
Co-authored-by: John Kehayias <john.kehayias@protonmail.com>
Signed-off-by: John Kehayias <john.kehayias@protonmail.com>
