unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: dan <i@dan.games>
Cc: guix-devel@gnu.org
Subject: Re: Should wsl-boot-program create XDG_RUNTIME_DIR?
Date: Tue, 15 Nov 2022 16:13:31 -0500	[thread overview]
Message-ID: <8735ajncp0.fsf@gmail.com> (raw)
In-Reply-To: <6bad140c-7237-06dd-02d8-3d4968abf09f@dan.games> (dan's message of "Mon, 7 Nov 2022 14:00:51 +0800")

Hi Dan,

dan <i@dan.games> writes:

> Hello guix,
>
> Even since the WSL image was pushed to master branch, I've been
> spending time experimenting with it.  It almost runs smoothly, unless
> two points:
>
> 1. when logged in, there is a warning says:
>> warning: XDG_RUNTIME_DIR doesn't exists, on-first-login script won't
>   execute anything.  You can check if xdg runtime directory exists,
>   XDG_RUNTIME_DIR variable is set to appropriate value and manually
>   execute the script by running '$HOME/.guix-home/on-first-login'
>
> The value of $XDG_RUNTIME_DIR is /run/user/$UID, and the /run/user
> directory is empty.  I believe the /run directory is created on WSL's
> side, and there is a step remounting it[1].
>
> This also makes home shepherd services unusable.  Although I could
> manually create the directory, perhaps it's better if we could just do
> the work within `wsl-boot-program', a wrapper for the login shell to
> work properly on WSL.

If it breaks a valid use case as it seems to be, it should be handled by
Guix.  A similar problem was fixed for the etc/guix-install.sh installer
script; it now defines a default value for XDG_RUNTIME_DIR and others in
its sys_create_init_profile function.

> 2. WSLg is usable, but the mesa in guix repo doesn't build with d3d12
> gallium driver[2]. So when opening up a GUI software in guix on WSL,
> in renders through llvmpipe (using CPU not GPU).
>
> I'm not sure if building mesa with d3d12 driver enabled by default is
> a good idea, or maybe we could create a new package?

A variant package would mean rebuilding many things, so if we want to
support this use case it seems we'd have to enable d3d12 in our main
mesa package and see what are the costs of doing so (increased disk
space?  new dependencies?).

-- 
Thanks,
Maxim


  reply	other threads:[~2022-11-15 21:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-07  6:00 Should wsl-boot-program create XDG_RUNTIME_DIR? dan
2022-11-15 21:13 ` Maxim Cournoyer [this message]
2022-11-16  3:00   ` John Kehayias
2022-11-16  3:45     ` dan
2022-11-16  5:09       ` John Kehayias
  -- strict thread matches above, loose matches on Subject: below --
2022-11-07  6:06 dan
2022-11-07  6:09 dan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8735ajncp0.fsf@gmail.com \
    --to=maxim.cournoyer@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=i@dan.games \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).