* Application Setup on Trisquel @ 2017-10-24 18:12 Caleb Herbert 2017-10-24 21:16 ` Ludovic Courtès 2017-11-02 2:59 ` Mark H Weaver 0 siblings, 2 replies; 19+ messages in thread From: Caleb Herbert @ 2017-10-24 18:12 UTC (permalink / raw) To: help-guix [-- Attachment #1: Type: text/plain, Size: 1172 bytes --] Questions for Section 2.6.2 Name Service Switch * How do I run ncsd on Trisquel? * Should I get ncsd from APT or Guix? * How do I make sure ncsd is "listening on the /var/run/nscd/socket socket"? Questions for Section 2.6.3 X11 Fonts * Trisquel does not have xset * Should I get xset from APT or Guix? Setting Environment Variables The manual instructs users on foreign distros to export environment variables. Doing this in the shell makes the changes temporary. Where should these changes be made permanent? (It is bad practice to put environment variables in .bashrc.) Integration with Trisquel Is there a way to make Trisquel's GNOME and its main menu aware of programs installed with Guix? When to Use APT Which of the following should be installed by Guix, and which should be installed by APT? Is there a way to install everything with Guix? Packages marked with * indicate that APT may be needed for integration with the foreign system. mps-youtube youtube-dl youtube-dl-gui mumble hexchat gajim icecat password-store git onionshare tor* git-crypt ghc-pandoc fcitx fcitx-configtool hplip* redshift lilypond noweb texlive audacity stow ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Application Setup on Trisquel 2017-10-24 18:12 Application Setup on Trisquel Caleb Herbert @ 2017-10-24 21:16 ` Ludovic Courtès 2017-10-24 22:04 ` Caleb Herbert ` (2 more replies) 2017-11-02 2:59 ` Mark H Weaver 1 sibling, 3 replies; 19+ messages in thread From: Ludovic Courtès @ 2017-10-24 21:16 UTC (permalink / raw) To: Caleb Herbert; +Cc: help-guix Hi Caleb, "Caleb Herbert" <csh@bluehome.net> skribis: > Questions for Section 2.6.2 Name Service Switch > > * How do I run ncsd on Trisquel? > * Should I get ncsd from APT or Guix? You should get nscd from Trisquel, in its ‘nscd’ package. You’ll have more success asking Trisquel questions on Trisquel fora though. :-) > * How do I make sure ncsd is "listening on the /var/run/nscd/socket > socket"? You could run “lsof | grep nscd”, but it’s likely to be the case once nscd running. > Questions for Section 2.6.3 X11 Fonts > > * Trisquel does not have xset It surely has a package for it. > * Should I get xset from APT or Guix? Either way is fine. > Setting Environment Variables > > The manual instructs users on foreign distros to export environment > variables. Doing this in the shell makes the changes temporary. > Where should these changes be made permanent? (It is bad practice to > put environment variables in .bashrc.) /etc/profile would be the right place. > Integration with Trisquel > > Is there a way to make Trisquel's GNOME and its main menu aware of > programs installed with Guix? It should be possible, but I don’t know how. Anyone? > When to Use APT > > Which of the following should be installed by Guix, and which should > be installed by APT? Is there a way to install everything with Guix? > Packages marked with * indicate that APT may be needed for > integration with the foreign system. In general, you can install everything with Guix. However, for system services (nscd, sshd, etc.), you’ll usually want to use apt-get because that’ll not only install the package but also add the relevant service startup scripts. HTH! Ludo’. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Application Setup on Trisquel 2017-10-24 21:16 ` Ludovic Courtès @ 2017-10-24 22:04 ` Caleb Herbert 2017-10-26 17:54 ` Ludovic Courtès 2017-10-27 1:02 ` Chris Marusich 2017-10-24 23:33 ` Caleb Herbert 2017-10-25 0:36 ` Mikhail Kryshen 2 siblings, 2 replies; 19+ messages in thread From: Caleb Herbert @ 2017-10-24 22:04 UTC (permalink / raw) To: Ludovic Courtès; +Cc: help-guix [-- Attachment #1: Type: text/plain, Size: 576 bytes --] Ludovic Courtès <ludo@gnu.org> wrote .. > Hi Caleb, > > "Caleb Herbert" <csh@bluehome.net> skribis: Sal', Luchjo! > > The manual instructs users on foreign distros to export environment > > variables. Doing this in the shell makes the changes temporary. > > Where should these changes be made permanent? (It is bad practice to > > put environment variables in .bashrc.) > > /etc/profile would be the right place. Should this info be added to the manual? Following the instructions as-is leads to lost settings. Thanks for answering all my questions. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Application Setup on Trisquel 2017-10-24 22:04 ` Caleb Herbert @ 2017-10-26 17:54 ` Ludovic Courtès 2017-10-27 1:02 ` Chris Marusich 1 sibling, 0 replies; 19+ messages in thread From: Ludovic Courtès @ 2017-10-26 17:54 UTC (permalink / raw) To: Caleb Herbert; +Cc: help-guix "Caleb Herbert" <csh@bluehome.net> skribis: > Ludovic Courtès <ludo@gnu.org> wrote .. >> Hi Caleb, >> >> "Caleb Herbert" <csh@bluehome.net> skribis: > > Sal', Luchjo! > >> > The manual instructs users on foreign distros to export environment >> > variables. Doing this in the shell makes the changes temporary. >> > Where should these changes be made permanent? (It is bad practice to >> > put environment variables in .bashrc.) >> >> /etc/profile would be the right place. > > Should this info be added to the manual? Following the instructions > as-is leads to lost settings. Would you like to suggest a patch? The bottom line is that we don’t want to repeat what’s already in the Bash manual (see <https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html>), but we can definitely link to it. Thanks in advance, Ludo’. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Application Setup on Trisquel 2017-10-24 22:04 ` Caleb Herbert 2017-10-26 17:54 ` Ludovic Courtès @ 2017-10-27 1:02 ` Chris Marusich 1 sibling, 0 replies; 19+ messages in thread From: Chris Marusich @ 2017-10-27 1:02 UTC (permalink / raw) To: Caleb Herbert; +Cc: help-guix [-- Attachment #1: Type: text/plain, Size: 4312 bytes --] Hi Caleb! "Caleb Herbert" <csh@bluehome.net> writes: >> > The manual instructs users on foreign distros to export environment >> > variables. Doing this in the shell makes the changes temporary. >> > Where should these changes be made permanent? (It is bad practice to >> > put environment variables in .bashrc.) >> >> /etc/profile would be the right place. > > Should this info be added to the manual? Following the instructions > as-is leads to lost settings. Yes, I think we should add something like that. However, we should be careful not to provide overly specific instructions, since the answer to the question of "How do I permanently set environment variables the RIGHT way?" depends on many factors, and no single answer will be correct under all circumstances. Some (but not all) of the factors it can depend on are what distribution you're using, what your personal preferences are, what shell you're using, whether your shell is a "login" shell or not, whether your shell is a "non-interactive" shell or not, and even the whims of your graphical desktop environment [1]. The answer to that simple question is surprisingly complicated. In any case, we should encourage users to source $GUIX_PROFILE/etc/profile once. Perhaps we can add the following example and suggest that users copy it into an appropriate location, where it will (hopefully) be sourced only once (maybe suggest /etc/profile as one possible place to accomplish this?): --8<---------------cut here---------------start------------->8--- GUIX_PROFILE="$HOME/.guix-profile" if [[ -f "$GUIX_PROFILE/etc/profile" ]]; then source "$GUIX_PROFILE/etc/profile" fi --8<---------------cut here---------------end--------------->8--- We've discussed the topic of environment variables on foreign distros before, but nobody updated update the manual as a result [2]. Caleb, would you like to take a stab at updating the manual? I think it would make sense to add this information to the "Binary Installation" section, probably near where we tell the user to "source ‘etc/profile’ to augment ‘PATH’ and other relevant environment variables. The process for submitting a patch is described in the "Submitting Patches" section of the manual. I'm sure other new users would appreciate it! As for your other question - how to make GNOME discover programs installed via Guix in its menus etc. - I'm afraid that's also complicated. The method by which a particular graphical desktop environment finds installed applications can vary. In theory, if Guix installs programs in a way that conforms to the Free Desktop [3] specifications (in particular, the Desktop Entry Specification), then Guix-installed applications should be discoverable by desktop environments which follow those specifications, like GNOME. However, it's entirely possible that different distributions or desktop environments may interpret the specifications in slightly different, mutually incompatible ways [4]. As a result, it might unfortunately be necessary for users to modify their environment, in ways that are specific to their situation, in order to teach their environment how to discover Guix-installed programs. We also had a prior discussion about this topic, and it still might be an issue [5]. I'm not sure, since I don't use Ubuntu too frequently these days. I use GuixSD instead. Footnotes: [1] https://bugzilla.gnome.org/show_bug.cgi?id=736660 [2] https://lists.gnu.org/archive/html/help-guix/2017-05/msg00068.html [3] https://wiki.freedesktop.org/www/Specifications/ [4] For example, Ubuntu seems to require .desktop files to have their executable bit set, but the Desktop Entry Specification does not require this, so if Guix installs a .desktop file in the right place, but its executable bit happens to not be set, Ubuntu might not display it. One can imagine that maybe, some other distribution might some day declare that all .desktop files should NOT be executable, which would make it difficult to satisfy both distros' requirements. For details, see here: https://wiki.ubuntu.com/SecurityTeam/Policies#Execute-Permission_Bit_Required [5] https://lists.gnu.org/archive/html/guix-devel/2017-05/msg00104.html -- Chris [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Application Setup on Trisquel 2017-10-24 21:16 ` Ludovic Courtès 2017-10-24 22:04 ` Caleb Herbert @ 2017-10-24 23:33 ` Caleb Herbert 2017-10-24 23:44 ` Caleb Herbert 2017-10-25 0:36 ` Mikhail Kryshen 2 siblings, 1 reply; 19+ messages in thread From: Caleb Herbert @ 2017-10-24 23:33 UTC (permalink / raw) To: Ludovic Courtès; +Cc: help-guix [-- Attachment #1: Type: text/plain, Size: 2486 bytes --] Ludovic Courtès <ludo@gnu.org> wrote .. > You should get nscd from Trisquel, in its ‘nscd’ package. You’ll have > more success asking Trisquel questions on Trisquel fora though. :-) Done. > > * How do I make sure ncsd is "listening on the /var/run/nscd/socket > > socket"? > > You could run “lsof | grep nscd”, but it’s likely to be the case once > nscd running. It seems to be running. :-) root@leela:~# lsof | grep nscd | grep '\/var\/run\/' lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. nscd 2691 root 12u unix 0xffff8800361d4000 0t0 404213 /var/run/nscd/socket nscd 2691 2692 root 12u unix 0xffff8800361d4000 0t0 404213 /var/run/nscd/socket nscd 2691 2693 root 12u unix 0xffff8800361d4000 0t0 404213 /var/run/nscd/socket nscd 2691 2694 root 12u unix 0xffff8800361d4000 0t0 404213 /var/run/nscd/socket nscd 2691 2695 root 12u unix 0xffff8800361d4000 0t0 404213 /var/run/nscd/socket nscd 2691 2697 root 12u unix 0xffff8800361d4000 0t0 404213 /var/run/nscd/socket nscd 2691 2698 root 12u unix 0xffff8800361d4000 0t0 404213 /var/run/nscd/socket nscd 2691 2699 root 12u unix 0xffff8800361d4000 0t0 404213 /var/run/nscd/socket nscd 2691 2700 root 12u unix 0xffff8800361d4000 0t0 404213 /var/run/nscd/socket nscd 2691 2701 root 12u unix 0xffff8800361d4000 0t0 404213 /var/run/nscd/socket > > The manual instructs users on foreign distros to export environment > > variables. Doing this in the shell makes the changes temporary. > > Where should these changes be made permanent? (It is bad practice to > > put environment variables in .bashrc.) > > /etc/profile would be the right place. Is this correct? # echo 'export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale' >>/etc/p rofile # echo 'export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs"' >>/ etc/profile # echo 'export SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-c ertificates.crt"' >>/etc/profile # echo 'export GIT_SSL_CAINFO="$SSL_CERT_FILE"' >>/etc/profile # echo 'export CURL_CA_BUNDLE="$HOME/.guix-profile/etc/ssl/certs/ca- certificates.crt"' >>/etc/profile # echo 'source $HOME/.guix-profile/etc/profile' >>/etc/profile ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Application Setup on Trisquel 2017-10-24 23:33 ` Caleb Herbert @ 2017-10-24 23:44 ` Caleb Herbert 2017-10-26 17:52 ` Ludovic Courtès 0 siblings, 1 reply; 19+ messages in thread From: Caleb Herbert @ 2017-10-24 23:44 UTC (permalink / raw) To: Ludovic Courtès; +Cc: help-guix [-- Attachment #1: Type: text/plain, Size: 1048 bytes --] > > > The manual instructs users on foreign distros to export environment > > > variables. Doing this in the shell makes the changes temporary. > > > Where should these changes be made permanent? (It is bad practice to > > > put environment variables in .bashrc.) > > > > /etc/profile would be the right place. > > Is this correct? > > # echo 'export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale' >>/etc/p > rofile > # echo 'export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs"' >>/ > etc/profile > # echo 'export SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-c > ertificates.crt"' >>/etc/profile > # echo 'export GIT_SSL_CAINFO="$SSL_CERT_FILE"' >>/etc/profile > # echo 'export CURL_CA_BUNDLE="$HOME/.guix-profile/etc/ssl/certs/ca- > certificates.crt"' >>/etc/profile > # echo 'source $HOME/.guix-profile/etc/profile' >>/etc/profile I had to comment those lines in /etc/profile because Trisquel's display manager would return me to the login screen after entering my password. How do I make sure these environment variables are set? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Application Setup on Trisquel 2017-10-24 23:44 ` Caleb Herbert @ 2017-10-26 17:52 ` Ludovic Courtès 2017-10-26 20:05 ` Caleb Herbert 0 siblings, 1 reply; 19+ messages in thread From: Ludovic Courtès @ 2017-10-26 17:52 UTC (permalink / raw) To: Caleb Herbert; +Cc: help-guix "Caleb Herbert" <csh@bluehome.net> skribis: >> > > The manual instructs users on foreign distros to export environment >> > > variables. Doing this in the shell makes the changes temporary. >> > > Where should these changes be made permanent? (It is bad > practice to >> > > put environment variables in .bashrc.) >> > >> > /etc/profile would be the right place. >> >> Is this correct? >> >> # echo 'export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale' >>/etc/p >> rofile >> # echo 'export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs"' >>/ >> etc/profile >> # echo 'export SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-c >> ertificates.crt"' >>/etc/profile >> # echo 'export GIT_SSL_CAINFO="$SSL_CERT_FILE"' >>/etc/profile >> # echo 'export CURL_CA_BUNDLE="$HOME/.guix-profile/etc/ssl/certs/ca- >> certificates.crt"' >>/etc/profile >> # echo 'source $HOME/.guix-profile/etc/profile' >>/etc/profile > > I had to comment those lines in /etc/profile because Trisquel's > display manager would return me to the login screen after entering my > password. Does ~/.xsession-errors contain hints as to why this happened? > How do I make sure these environment variables are set? For the variables themselves, /etc/profile is a good thing, as discussed above. I’d probably move “source $HOME/.guix-profile/etc/profile” to ~/.bash_profile, though. But that’s really a shell question more than a Guix question, I think. HTH! Ludo’. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Application Setup on Trisquel 2017-10-26 17:52 ` Ludovic Courtès @ 2017-10-26 20:05 ` Caleb Herbert 0 siblings, 0 replies; 19+ messages in thread From: Caleb Herbert @ 2017-10-26 20:05 UTC (permalink / raw) To: Ludovic Courtès; +Cc: help-guix On Thu, 2017-10-26 at 10:52 -0700, Ludovic Courtès wrote: > "Caleb Herbert" <csh@bluehome.net> skribis: > > I had to comment those lines in /etc/profile because Trisquel's > > display manager would return me to the login screen after entering my > > password. The errors happened even when I commented the lines. I think the whole .profile was just written wrong. It came from my Slackware backup. > Does ~/.xsession-errors contain hints as to why this happened? I had to delete the entire .profile so my login works. .xsession-errors now says nothing interesting, AFAIK: cal@leela:~$ cat .xsession-errors Script for ibus started at run_im. Script for auto started at run_im. Script for default started at run_im. Script for ibus started at run_im. Script for auto started at run_im. Script for default started at run_im. GNOME's Alt+F2 launcher still doesn't know where Emacs is, but the main menu does. > I’d probably move “source $HOME/.guix-profile/etc/profile” to > ~/.bash_profile, though. That's what I've done. I think I'm going to keep it this way. > But that’s really a shell question more than a Guix question, I think. Sorry. It's hard to figure some things out sometimes. > HTH! What does this mean, anyway? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Application Setup on Trisquel 2017-10-24 21:16 ` Ludovic Courtès 2017-10-24 22:04 ` Caleb Herbert 2017-10-24 23:33 ` Caleb Herbert @ 2017-10-25 0:36 ` Mikhail Kryshen 2017-10-26 17:53 ` Ludovic Courtès 2 siblings, 1 reply; 19+ messages in thread From: Mikhail Kryshen @ 2017-10-25 0:36 UTC (permalink / raw) To: Ludovic Courtès, Caleb Herbert; +Cc: help-guix [-- Attachment #1: Type: text/plain, Size: 554 bytes --] Ludovic Courtès <ludo@gnu.org> writes: >> Is there a way to make Trisquel's GNOME and its main menu aware of >> programs installed with Guix? > > It should be possible, but I don’t know how. Anyone? I don't use Trisquel, but this works for GNOME in Fedora: ln -s ~/.guix-profile/share/applications ~/.local/share/applications/guix You might also want to copy or symlink application icons from ~/.guix-profile/share/icons to ~/.local/share/icons (don't know how to make them visible to GNOME with a single symlink) -- Mikhail [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 658 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Application Setup on Trisquel 2017-10-25 0:36 ` Mikhail Kryshen @ 2017-10-26 17:53 ` Ludovic Courtès 2017-10-27 3:29 ` Caleb Herbert 2017-11-08 6:39 ` Caleb Herbert 0 siblings, 2 replies; 19+ messages in thread From: Ludovic Courtès @ 2017-10-26 17:53 UTC (permalink / raw) To: Mikhail Kryshen; +Cc: Caleb Herbert, help-guix Mikhail Kryshen <mikhail@kryshen.net> skribis: > Ludovic Courtès <ludo@gnu.org> writes: > >>> Is there a way to make Trisquel's GNOME and its main menu aware of >>> programs installed with Guix? >> >> It should be possible, but I don’t know how. Anyone? > > I don't use Trisquel, but this works for GNOME in Fedora: > > ln -s ~/.guix-profile/share/applications ~/.local/share/applications/guix > > You might also want to copy or symlink application icons from > ~/.guix-profile/share/icons to ~/.local/share/icons > (don't know how to make them visible to GNOME with a single symlink) Excellent, good to know! Ludo’. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Application Setup on Trisquel 2017-10-26 17:53 ` Ludovic Courtès @ 2017-10-27 3:29 ` Caleb Herbert 2017-11-08 6:39 ` Caleb Herbert 1 sibling, 0 replies; 19+ messages in thread From: Caleb Herbert @ 2017-10-27 3:29 UTC (permalink / raw) To: Ludovic Courtès; +Cc: help-guix On Thu, 2017-10-26 at 10:53 -0700, Ludovic Courtès wrote: > Mikhail Kryshen <mikhail@kryshen.net> skribis: > > > Ludovic Courtès <ludo@gnu.org> writes: > > > >>> Is there a way to make Trisquel's GNOME and its main menu aware of > >>> programs installed with Guix? > >> > >> It should be possible, but I don’t know how. Anyone? > > > > I don't use Trisquel, but this works for GNOME in Fedora: > > > > ln -s ~/.guix-profile/share/applications ~/.local/share/applications/guix > > > > You might also want to copy or symlink application icons from > > ~/.guix-profile/share/icons to ~/.local/share/icons > > (don't know how to make them visible to GNOME with a single symlink) The first symlink works. The second does not. Also, I have my own icons in ~/.local/share/icons, so I'm not sure if I could use Stow to manage all those symlinks. Could I? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Application Setup on Trisquel 2017-10-26 17:53 ` Ludovic Courtès 2017-10-27 3:29 ` Caleb Herbert @ 2017-11-08 6:39 ` Caleb Herbert 2017-11-09 21:05 ` Chris Marusich 2017-11-12 13:02 ` Adonay Felipe Nogueira 1 sibling, 2 replies; 19+ messages in thread From: Caleb Herbert @ 2017-11-08 6:39 UTC (permalink / raw) To: Ludovic Courtès; +Cc: help-guix On Thu, 2017-10-26 at 10:53 -0700, Ludovic Courtès wrote: > Mikhail Kryshen <mikhail@kryshen.net> skribis: > > > Ludovic Courtès <ludo@gnu.org> writes: > > > >>> Is there a way to make Trisquel's GNOME and its main menu aware of > >>> programs installed with Guix? > >> > >> It should be possible, but I don’t know how. Anyone? > > > > I don't use Trisquel, but this works for GNOME in Fedora: > > > > ln -s ~/.guix-profile/share/applications ~/.local/share/applications/guix > > > > You might also want to copy or symlink application icons from > > ~/.guix-profile/share/icons to ~/.local/share/icons I have a better way. This did not work for me on Trisquel. My experience: Apps appeared in the main menu, but GNOME was not aware of them. Icons were missing, Emacs would never show up in "Open With", and I couldn't launch Mumble from Run Application (Alt+F2). Solution: https://trisquel.info/en/forum/guix-trisquel#comment-122789 (Thanks, ADFENO!) GNOME sees apps and icons now! Remaining hurdles: * Buttons don't show up, themes don't match: https://lut.im/g7za20HA8Z/U8CWURMKf3X0a1GI.png * Fcitx Mozc input method for Japanese does not work in Guix apps ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Application Setup on Trisquel 2017-11-08 6:39 ` Caleb Herbert @ 2017-11-09 21:05 ` Chris Marusich 2017-11-10 21:29 ` Caleb Herbert 2017-11-12 14:55 ` Adonay Felipe Nogueira 2017-11-12 13:02 ` Adonay Felipe Nogueira 1 sibling, 2 replies; 19+ messages in thread From: Chris Marusich @ 2017-11-09 21:05 UTC (permalink / raw) To: Caleb Herbert; +Cc: help-guix [-- Attachment #1: Type: text/plain, Size: 6207 bytes --] Caleb Herbert <csh@bluehome.net> writes: > On Thu, 2017-10-26 at 10:53 -0700, Ludovic Courtès wrote: >> Mikhail Kryshen <mikhail@kryshen.net> skribis: >> >> > Ludovic Courtès <ludo@gnu.org> writes: >> > >> >>> Is there a way to make Trisquel's GNOME and its main menu aware of >> >>> programs installed with Guix? >> >> >> >> It should be possible, but I don’t know how. Anyone? >> > >> > I don't use Trisquel, but this works for GNOME in Fedora: >> > >> > ln -s ~/.guix-profile/share/applications ~/.local/share/applications/guix >> > >> > You might also want to copy or symlink application icons from >> > ~/.guix-profile/share/icons to ~/.local/share/icons > > I have a better way. This did not work for me on Trisquel. > > My experience: Apps appeared in the main menu, but GNOME was not aware > of them. Icons were missing, Emacs would never show up in "Open With", > and I couldn't launch Mumble from Run Application (Alt+F2). > > Solution: > https://trisquel.info/en/forum/guix-trisquel#comment-122789 > (Thanks, ADFENO!) > > GNOME sees apps and icons now! This sounds very similar to https://lists.gnu.org/archive/html/help-guix/2017-05/msg00069.html in which the interaction between Guix-installed packages (emacs, in my case) and the XDG_DATA_DIRS environment variable caused the UI (including icons) to display incorrectly. It would be nice to solve this in general for Guix-installed applications on foreign distros. Do you have any ideas about how we can solve it? The Guix-installed emacs, in particular, has some wrapper scripts: --8<---------------cut here---------------start------------->8--- [0] marusich@garuda:~ $ cat $(readlink $(which emacs)) #!/gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/bash export XDG_DATA_DIRS="/gnu/store/llwrfx84y7qv00c5y1c6ys24x2i2xh0p-shared-mime-info-1.8/share:/gnu/store/qzmyyj0jx6n14vsffa66jgsnnvwhby3n-glib-2.52.3/share:/gnu/store/2zvqvqakdf03yqgix5qzn48ix7amkzi0-gtk+-3.22.21/share:/gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS" export GTK_PATH="/gnu/store/2zvqvqakdf03yqgix5qzn48ix7amkzi0-gtk+-3.22.21/lib/gtk-3.0${GTK_PATH:+:}$GTK_PATH" export GIO_EXTRA_MODULES="/gnu/store/qzmyyj0jx6n14vsffa66jgsnnvwhby3n-glib-2.52.3/lib/gio/modules${GIO_EXTRA_MODULES:+:}$GIO_EXTRA_MODULES" exec -a "$0" "/gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/bin/emacs-25.3" "$@" [0] marusich@garuda:~ $ cat /gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/bin/emacs-25.3 #!/gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/bash export XDG_DATA_DIRS="/gnu/store/llwrfx84y7qv00c5y1c6ys24x2i2xh0p-shared-mime-info-1.8/share:/gnu/store/qzmyyj0jx6n14vsffa66jgsnnvwhby3n-glib-2.52.3/share:/gnu/store/2zvqvqakdf03yqgix5qzn48ix7amkzi0-gtk+-3.22.21/share:/gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS" export GTK_PATH="/gnu/store/2zvqvqakdf03yqgix5qzn48ix7amkzi0-gtk+-3.22.21/lib/gtk-3.0${GTK_PATH:+:}$GTK_PATH" export GIO_EXTRA_MODULES="/gnu/store/qzmyyj0jx6n14vsffa66jgsnnvwhby3n-glib-2.52.3/lib/gio/modules${GIO_EXTRA_MODULES:+:}$GIO_EXTRA_MODULES" exec -a "$0" "/gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/bin/.emacs-25.3-real" "$@" [0] marusich@garuda:~ $ file /gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/bin/.emacs-25.3-real /gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/bin/.emacs-25.3-real: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/n6nvxlk2j8ysffjh3jphn1k5silnakh6-glibc-2.25/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped, with debug_info [0] marusich@garuda:~ $ --8<---------------cut here---------------end--------------->8--- In particular, note how the two wrapper scripts add (the same) store entries to the front of the existing XDG_DATA_DIRS environment variable. I was able to solve my emacs UI problem by removing the "/usr/share/" entry from XDG_DATA_DIRS. You were able to solve your problem by adding ${HOME}/.guix-profile/share to the front of XDG_DATA_DIRS and adding the foreign distro's XDG_DATA_DIRS (including "/usr/share/" to the end). I feel like these clues are pointing to something, but I'm not yet sure what. Do you have any good ideas? I think it's fine (although I wish it weren't necessary at all) to require users to customize their environment to enable all features of Guix-installed applications on a foreign distro (features like properly displayed icons, locales, etc.) . However, asking users to configure XDG_DATA_DIRS seems significantly more complicated, due to problems like these, and also like bug 26202: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26202 I really hope we can figure out a way to get things that rely on XDG_DATA_DIRS to work better out of the box. > Remaining hurdles: > * Buttons don't show up, themes don't match: > https://lut.im/g7za20HA8Z/U8CWURMKf3X0a1GI.png Could this be the same issue that I saw with emacs? I mentioned this above, but here's the link again: https://lists.gnu.org/archive/html/help-guix/2017-05/msg00069.html > * Fcitx Mozc input method for Japanese does not work in Guix apps Can you tell us more about your use case? Are you trying to install fcitx etc. via Guix, and then use it to type in Japanese within Guix-installed applications (do they use GTK, or something else)? Or did you install fcitx etc. using the foreign distro's package manager (e.g., apt-get), and now you are trying to use that IME to type in Japanese within Guix-installed apps? The interaction between an IME and its environment is tricky to get right and depends on a lot of factors, so I expect it might require a non-trivial amount of work to make it so that all Guix-installed apps will correctly make use of an IME that is installed and managed by the foreign distro. FWIW, I have been able to get Japanese input working in GuixSD in all apps using ibus and ibus-anthy. I haven't yet tried to get Japanese input working in Guix-installed applications on a foreign distro. -- Chris [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Application Setup on Trisquel 2017-11-09 21:05 ` Chris Marusich @ 2017-11-10 21:29 ` Caleb Herbert 2017-11-12 14:55 ` Adonay Felipe Nogueira 1 sibling, 0 replies; 19+ messages in thread From: Caleb Herbert @ 2017-11-10 21:29 UTC (permalink / raw) To: Chris Marusich; +Cc: help-guix On Thu, 2017-11-09 at 13:05 -0800, Chris Marusich wrote: > This sounds very similar to > > https://lists.gnu.org/archive/html/help-guix/2017-05/msg00069.html > > in which the interaction between Guix-installed packages (emacs, in my > case) and the XDG_DATA_DIRS environment variable caused the UI > (including icons) to display incorrectly. It would be nice to solve > this in general for Guix-installed applications on foreign distros. Do > you have any ideas about how we can solve it? I don't know how to solve it, but I tried what was done in that post, and it seemed to help. env -u XDG_DATA_DIRS icecat & env -u XDG_DATA_DIRS youtube-dl-gui & IceCat looked much better: http://bluehome.net/csh/screenshot/2017/11/10/icecatprofile http://bluehome.net/csh/screenshot/2017/11/10/icecatwindow youtube-dlG, however, looked the same: http://bluehome.net/csh/screenshot/2017/11/10/youtubedlgui > "/usr/share/" entry from XDG_DATA_DIRS. You were able to solve your > problem by adding ${HOME}/.guix-profile/share to the front of XDG_DATA_DIRS > and adding the foreign distro's XDG_DATA_DIRS (including "/usr/share/" > to the end). I feel like these clues are pointing to something, but I'm > not yet sure what. Do you have any good ideas? You'd have to ask ADFENO. I didn't think too much about the changes I made to my system. I just looked at his instructions, determined if they were harmless, and followed them. > displayed icons, locales, etc.) . However, asking users to configure > XDG_DATA_DIRS seems significantly more complicated, due to problems like > these, and also like bug 26202: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26202 I agree. I'm just a luser. I don't have a spare system to do experiments on, and I don't want to be doing experiments on my only device. > > Remaining hurdles: > > * Buttons don't show up, themes don't match: > > https://lut.im/g7za20HA8Z/U8CWURMKf3X0a1GI.png > > Could this be the same issue that I saw with emacs? Yes. > > * Fcitx Mozc input method for Japanese does not work in Guix apps > > Can you tell us more about your use case? Are you trying to install > fcitx etc. via Guix, and then use it to type in Japanese within > Guix-installed applications (do they use GTK, or something else)? No. I tried doing that, and Fcitx wouldn't run properly because it didn't like the fact that Trisquel had its own ibus running. > Or > did you install fcitx etc. using the foreign distro's package manager > (e.g., apt-get), and now you are trying to use that IME to type in > Japanese within Guix-installed apps? Yes, this is what I did. sudo apt install fcitx fcitx-mozc I can type Japanese in Trisquel apps, but not in Guix apps. Also, Trisquel's Fcitx will let me type Japanese but not any other language. Greek is available, but I still get "aoeu" when I switch to it. > The interaction between an IME and > its environment is tricky to get right and depends on a lot of factors, > so I expect it might require a non-trivial amount of work to make it so > that all Guix-installed apps will correctly make use of an IME that is > installed and managed by the foreign distro. I would gladly use Guix's Fcitx, because its Mozc is newer and lets you type もも (momo, "peach") to get 🍑 (":peach:"). But, as mentioned above, it doesn't play nice with Trisquel's ibus. > FWIW, I have been able to get Japanese input working in GuixSD in all > apps using ibus and ibus-anthy. ##japanese on Freenode says Anthy is abandoned, so they recommend Fcitx. Re GuixSD, I should take the hard drive out of my old laptop and install GuixSD to try it out. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Application Setup on Trisquel 2017-11-09 21:05 ` Chris Marusich 2017-11-10 21:29 ` Caleb Herbert @ 2017-11-12 14:55 ` Adonay Felipe Nogueira 2017-11-12 17:09 ` Adonay Felipe Nogueira 1 sibling, 1 reply; 19+ messages in thread From: Adonay Felipe Nogueira @ 2017-11-12 14:55 UTC (permalink / raw) To: help-guix I might have some information that might help understand how ${XDG_DATA_DIRS} interferes in case of GNU Guix in foreign distros. Reading the XDG Base Directory Specification ([1]): --8<---------------cut here---------------start------------->8--- [...] * Basics The XDG Base Directory Specification is based on the following concepts: - There is a single base directory relative to which user-specific data files should be written. This directory is defined by the environment variable $XDG_DATA_HOME [...] - There is a set of preference ordered base directories relative to which data files should be searched. This set of directories is defined by the environment variable $XDG_DATA_DIRS [...] * Environment variables $XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used [...] $XDG_DATA_DIRS defines the preference-ordered set of base directories to search for data files in addition to the $XDG_DATA_HOME base directory. The directories in $XDG_DATA_DIRS should be seperated with a colon ':'. If $XDG_DATA_DIRS is either not set or empty, a value equal to /usr/local/share/:/usr/share/ should be used. [...] The order of base directories denotes their importance; the first directory listed is the most important. When the same information is defined in multiple places the information defined relative to the more important base directory takes precedent. The base directory defined by $XDG_DATA_HOME is considered more important than any of the base directories defined by $XDG_DATA_DIRS. The base directory defined by $XDG_CONFIG_HOME is considered more important than any of the base directories defined by $XDG_CONFIG_DIRS [...] --8<---------------cut here---------------end--------------->8--- This, as far as I can understand means that $XDG_DATA_HOME (or assumed default value) is the user defined "data" directory. While $XDG_DATA_DIRS (or assumed default value) is a preference list that comes *after* $XDG_DATA_HOME. Inside the list, entries are sorted from "most preferred" to "last resort". The combination forms a preference queue, like so: XDG_DATA_HOME XDG_DATA_DIRS Where, if there are various values for the same information, the first appearance takes the lead, and the remaining conflicting values are discarded. The following quote taken from [1] contributes to this: --8<---------------cut here---------------start------------->8--- [...] * Referencing this specification Other specifications may reference this specification by specifying the location of a data file as $XDG_DATA_DIRS/subdir/filename. This implies that: - Such file should be installed to $datadir/subdir/filename with $datadir defaulting to /usr/share. - A user specific version of the data file may be created in $XDG_DATA_HOME/subdir/filename, taking into account the default value for $XDG_DATA_HOME if $XDG_DATA_HOME is not set. - Lookups of the data file should search for ./subdir/filename relative to all base directories specified by $XDG_DATA_HOME and $XDG_DATA_DIRS . If an environment variable is either not set or empty, its default value as defined by this specification should be used instead. [...] A specification that refers to $XDG_DATA_DIRS or $XDG_CONFIG_DIRS should define what the behaviour must be when a file is located under multiple base directories. It could, for example, define that only the file under the most important base directory should be used or, as another example, it could define rules for merging the information from the different files. [...] --8<---------------cut here---------------end--------------->8--- Note that from the last paragraph of the quote, one can see that each project is responsible for dealing with cases where a file *with the same relative path* is found in various entries in $XDG_DATA_DIRS (note that we are not talking about $XDG_DATA_HOME here). For example, suppose I have $XDG_DATA_DIRS *expanded* as follows: /home/adfeno/.guix-profile/share:/usr/share We see two entries here, and unfortunatelly, suppose I have two "gnome" icon themes, one in each entry: /home/adfeno/.guix-profile/share/icons/gnome /usr/share/icons/gnome Both have an "index.theme", so according to the Icon Theme Specification ([2]), the first (in "/home/adfeno/.guix-profile/share") should be used, as according to [2]: --8<---------------cut here---------------start------------->8--- [...] In at least one of the theme directories there must be a file called index.theme that describes the theme. The first index.theme found while searching the base directories in order is used. This file describes the general attributes of the theme. [...] --8<---------------cut here---------------end--------------->8--- Also according to [2], a fallback theme called "hicolor" is assumed in almost all cases and application authors should install at least a 48x48 icon in the "hicolor" icon theme. Additionaly, application authors can install a vector version of the icon, and also a theme-specific one (in another theme, different from "hicolor"). Personally, speaking, if I were to fiddle with merging a theme to avoid collisions, I would choose "hicolor" first. As for the per-application behavior on dealing with multiple data files of same "relative path" found while reading $XDG_DATA_DIRS, refer to [1] again where it says this is left to the application to decide. Now, let's dive in to some other issues, what if the attempt to change $XDG_DATA_DIRS doesn't take into account it's previous value? And what if that same person is using GNOME with GSettings/GLib-GIO? Well, then [3] happens. Remember that some components of GSettings/GLib-GIO also look for things inside $XDG_DATA_DIRS ([4]), and that unfortunatelly, some foreign system distributions have Xsession.d scripts that don't append things to $XDG_DATA_DIRS (as is the case in [3]). I would say that a long-term solution would be patching the Xsession.d files of these system distributions. A short-term one would instruct users to append using appropriate scripting manually in the shell's profile. Finally, I'm not a programmer, but I hope this helps clarify the interaction between $XDG_DATA_DIRS and GNU Guix on foreign system distributions. [1] <https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html>. [2] <https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html>. [3] <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26202>. [4] <https://developer.gnome.org/gio/stable/glib-compile-schemas.html>. Chris Marusich <cmmarusich@gmail.com> writes: > This sounds very similar to > > https://lists.gnu.org/archive/html/help-guix/2017-05/msg00069.html > > in which the interaction between Guix-installed packages (emacs, in my > case) and the XDG_DATA_DIRS environment variable caused the UI > (including icons) to display incorrectly. It would be nice to solve > this in general for Guix-installed applications on foreign distros. Do > you have any ideas about how we can solve it? > > The Guix-installed emacs, in particular, has some wrapper scripts: > > --8<---------------cut here---------------start------------->8--- > [0] marusich@garuda:~ > $ cat $(readlink $(which emacs)) > #!/gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/bash > export XDG_DATA_DIRS="/gnu/store/llwrfx84y7qv00c5y1c6ys24x2i2xh0p-shared-mime-info-1.8/share:/gnu/store/qzmyyj0jx6n14vsffa66jgsnnvwhby3n-glib-2.52.3/share:/gnu/store/2zvqvqakdf03yqgix5qzn48ix7amkzi0-gtk+-3.22.21/share:/gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS" > export GTK_PATH="/gnu/store/2zvqvqakdf03yqgix5qzn48ix7amkzi0-gtk+-3.22.21/lib/gtk-3.0${GTK_PATH:+:}$GTK_PATH" > export GIO_EXTRA_MODULES="/gnu/store/qzmyyj0jx6n14vsffa66jgsnnvwhby3n-glib-2.52.3/lib/gio/modules${GIO_EXTRA_MODULES:+:}$GIO_EXTRA_MODULES" > exec -a "$0" "/gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/bin/emacs-25.3" "$@" > [0] marusich@garuda:~ > $ cat /gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/bin/emacs-25.3 > #!/gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/bash > export XDG_DATA_DIRS="/gnu/store/llwrfx84y7qv00c5y1c6ys24x2i2xh0p-shared-mime-info-1.8/share:/gnu/store/qzmyyj0jx6n14vsffa66jgsnnvwhby3n-glib-2.52.3/share:/gnu/store/2zvqvqakdf03yqgix5qzn48ix7amkzi0-gtk+-3.22.21/share:/gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS" > export GTK_PATH="/gnu/store/2zvqvqakdf03yqgix5qzn48ix7amkzi0-gtk+-3.22.21/lib/gtk-3.0${GTK_PATH:+:}$GTK_PATH" > export GIO_EXTRA_MODULES="/gnu/store/qzmyyj0jx6n14vsffa66jgsnnvwhby3n-glib-2.52.3/lib/gio/modules${GIO_EXTRA_MODULES:+:}$GIO_EXTRA_MODULES" > exec -a "$0" "/gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/bin/.emacs-25.3-real" "$@" > [0] marusich@garuda:~ > $ file /gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/bin/.emacs-25.3-real > /gnu/store/0vvlz13k099ra6p0wrmrl99akbhflqqg-emacs-25.3/bin/.emacs-25.3-real: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/n6nvxlk2j8ysffjh3jphn1k5silnakh6-glibc-2.25/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped, with debug_info > [0] marusich@garuda:~ > $ > --8<---------------cut here---------------end--------------->8--- > > In particular, note how the two wrapper scripts add (the same) store > entries to the front of the existing XDG_DATA_DIRS environment > variable. I was able to solve my emacs UI problem by removing the > "/usr/share/" entry from XDG_DATA_DIRS. You were able to solve your > problem by adding ${HOME}/.guix-profile/share to the front of XDG_DATA_DIRS > and adding the foreign distro's XDG_DATA_DIRS (including "/usr/share/" > to the end). I feel like these clues are pointing to something, but I'm > not yet sure what. Do you have any good ideas? > > I think it's fine (although I wish it weren't necessary at all) to > require users to customize their environment to enable all features of > Guix-installed applications on a foreign distro (features like properly > displayed icons, locales, etc.) . However, asking users to configure > XDG_DATA_DIRS seems significantly more complicated, due to problems like > these, and also like bug 26202: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26202 > > I really hope we can figure out a way to get things that rely on > XDG_DATA_DIRS to work better out of the box. > > > Could this be the same issue that I saw with emacs? I mentioned this > above, but here's the link again: > > https://lists.gnu.org/archive/html/help-guix/2017-05/msg00069.html > > > Can you tell us more about your use case? Are you trying to install > fcitx etc. via Guix, and then use it to type in Japanese within > Guix-installed applications (do they use GTK, or something else)? Or > did you install fcitx etc. using the foreign distro's package manager > (e.g., apt-get), and now you are trying to use that IME to type in > Japanese within Guix-installed apps? The interaction between an IME and > its environment is tricky to get right and depends on a lot of factors, > so I expect it might require a non-trivial amount of work to make it so > that all Guix-installed apps will correctly make use of an IME that is > installed and managed by the foreign distro. > > FWIW, I have been able to get Japanese input working in GuixSD in all > apps using ibus and ibus-anthy. I haven't yet tried to get Japanese > input working in Guix-installed applications on a foreign distro. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Application Setup on Trisquel 2017-11-12 14:55 ` Adonay Felipe Nogueira @ 2017-11-12 17:09 ` Adonay Felipe Nogueira 0 siblings, 0 replies; 19+ messages in thread From: Adonay Felipe Nogueira @ 2017-11-12 17:09 UTC (permalink / raw) To: help-guix An addendum: as was pointed out the default values for $XDG_DATA_HOME and $XDG_DATA_DIRS are only assumed if these are unset. Besides, in the short-term solution that suggests appending values to $XDG_DATA_DIRS to the environment/shell's profile, I emphasize the need to do it manually. Solutions such as: --8<---------------cut here---------------start------------->8--- [Additional value.]:${XDG_DATA_DIRS:+:}${XDG_DATA_DIRS} --8<---------------cut here---------------end--------------->8--- Or even: --8<---------------cut here---------------start------------->8--- if [ $XDG_DATA_DIRS ] then export XDG_DATA_DIRS="[Additional value.]:$XDG_DATA_DIRS" else export XDG_DATA_DIRS="[Additional value.]" fi --8<---------------cut here---------------end--------------->8--- ... will both lead only to "[Additional value.]" inside $XDG_DATA_DIRS --- because the Xsession.d scripts that set the foreign distro's value for $XDG_DATA_DIRS are run *after* the environment/shell's profile is read and as far as I can tell, before the user logs in the desktop environemnt. Adonay Felipe Nogueira <adfeno@hyperbola.info> writes: > I might have some information that might help understand how > ${XDG_DATA_DIRS} interferes in case of GNU Guix in foreign distros. > > Reading the XDG Base Directory Specification ([1]): > > --8<---------------cut here---------------start------------->8--- > [...] > > * Basics > > The XDG Base Directory Specification is based on the following concepts: > > - There is a single base directory relative to which user-specific data > files should be written. This directory is defined by the environment > variable $XDG_DATA_HOME > > [...] > > - There is a set of preference ordered base directories relative to > which data files should be searched. This set of directories is > defined by the environment variable $XDG_DATA_DIRS > > [...] > > * Environment variables > > $XDG_DATA_HOME defines the base directory relative to which user > specific data files should be stored. If $XDG_DATA_HOME is either not > set or empty, a default equal to $HOME/.local/share should be used > > [...] > > $XDG_DATA_DIRS defines the preference-ordered set of base directories to > search for data files in addition to the $XDG_DATA_HOME base > directory. The directories in $XDG_DATA_DIRS should be seperated with a > colon ':'. > > If $XDG_DATA_DIRS is either not set or empty, a value equal to > /usr/local/share/:/usr/share/ should be used. > > [...] > > The order of base directories denotes their importance; the first > directory listed is the most important. When the same information is > defined in multiple places the information defined relative to the more > important base directory takes precedent. The base directory defined by > $XDG_DATA_HOME is considered more important than any of the base > directories defined by $XDG_DATA_DIRS. The base directory defined by > $XDG_CONFIG_HOME is considered more important than any of the base > directories defined by $XDG_CONFIG_DIRS > > [...] > --8<---------------cut here---------------end--------------->8--- > > > This, as far as I can understand means that $XDG_DATA_HOME (or assumed > default value) is the user defined "data" directory. While > $XDG_DATA_DIRS (or assumed default value) is a preference list that > comes *after* $XDG_DATA_HOME. Inside the list, entries are sorted from > "most preferred" to "last resort". > > The combination forms a preference queue, like so: > > XDG_DATA_HOME XDG_DATA_DIRS > > Where, if there are various values for the same information, the first > appearance takes the lead, and the remaining conflicting values are > discarded. The following quote taken from [1] contributes to this: > > --8<---------------cut here---------------start------------->8--- > [...] > > * Referencing this specification > > Other specifications may reference this specification by specifying the > location of a data file as $XDG_DATA_DIRS/subdir/filename. This implies > that: > > - Such file should be installed to $datadir/subdir/filename with > $datadir defaulting to /usr/share. > > - A user specific version of the data file may be created in > $XDG_DATA_HOME/subdir/filename, taking into account the default > value for $XDG_DATA_HOME if $XDG_DATA_HOME is not set. > > - Lookups of the data file should search for ./subdir/filename > relative to all base directories specified by $XDG_DATA_HOME and > $XDG_DATA_DIRS . If an environment variable is either not set or > empty, its default value as defined by this specification should be > used instead. > > [...] > > A specification that refers to $XDG_DATA_DIRS or $XDG_CONFIG_DIRS should > define what the behaviour must be when a file is located under multiple > base directories. It could, for example, define that only the file under > the most important base directory should be used or, as another example, > it could define rules for merging the information from the different > files. > > [...] > --8<---------------cut here---------------end--------------->8--- > > > Note that from the last paragraph of the quote, one can see that each > project is responsible for dealing with cases where a file *with the > same relative path* is found in various entries in $XDG_DATA_DIRS (note > that we are not talking about $XDG_DATA_HOME here). > > For example, suppose I have $XDG_DATA_DIRS *expanded* as follows: > > /home/adfeno/.guix-profile/share:/usr/share > > We see two entries here, and unfortunatelly, suppose I have two "gnome" > icon themes, one in each entry: > > /home/adfeno/.guix-profile/share/icons/gnome > /usr/share/icons/gnome > > Both have an "index.theme", so according to the Icon Theme Specification > ([2]), the first (in "/home/adfeno/.guix-profile/share") should be used, > as according to [2]: > > --8<---------------cut here---------------start------------->8--- > [...] > > In at least one of the theme directories there must be a file called > index.theme that describes the theme. The first index.theme found while > searching the base directories in order is used. This file describes the > general attributes of the theme. > > [...] > --8<---------------cut here---------------end--------------->8--- > > Also according to [2], a fallback theme called "hicolor" is assumed in > almost all cases and application authors should install at least a 48x48 > icon in the "hicolor" icon theme. Additionaly, application authors can > install a vector version of the icon, and also a theme-specific one (in > another theme, different from "hicolor"). Personally, speaking, if I > were to fiddle with merging a theme to avoid collisions, I would choose > "hicolor" first. > > As for the per-application behavior on dealing with multiple data files > of same "relative path" found while reading $XDG_DATA_DIRS, refer to [1] > again where it says this is left to the application to decide. > > Now, let's dive in to some other issues, what if the attempt to change > $XDG_DATA_DIRS doesn't take into account it's previous value? And what > if that same person is using GNOME with GSettings/GLib-GIO? > > Well, then [3] happens. > > Remember that some components of GSettings/GLib-GIO also look for things > inside $XDG_DATA_DIRS ([4]), and that unfortunatelly, some foreign > system distributions have Xsession.d scripts that don't append things to > $XDG_DATA_DIRS (as is the case in [3]). I would say that a long-term > solution would be patching the Xsession.d files of these system > distributions. A short-term one would instruct users to append using > appropriate scripting manually in the shell's profile. > > Finally, I'm not a programmer, but I hope this helps clarify the > interaction between $XDG_DATA_DIRS and GNU Guix on foreign system > distributions. > > [1] > <https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html>. > > [2] > <https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html>. > > [3] <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26202>. > > [4] <https://developer.gnome.org/gio/stable/glib-compile-schemas.html>. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Application Setup on Trisquel 2017-11-08 6:39 ` Caleb Herbert 2017-11-09 21:05 ` Chris Marusich @ 2017-11-12 13:02 ` Adonay Felipe Nogueira 1 sibling, 0 replies; 19+ messages in thread From: Adonay Felipe Nogueira @ 2017-11-12 13:02 UTC (permalink / raw) To: help-guix For the case of themes not matching and buttoms not showing up, perhaps one can try the suggestion I made to that same thread ([1]). [1] <https://listas.trisquel.info/pipermail/trisquel-users/2017-November/082712.html>. Caleb Herbert <csh@bluehome.net> writes: > I have a better way. This did not work for me on Trisquel. > > My experience: Apps appeared in the main menu, but GNOME was not aware > of them. Icons were missing, Emacs would never show up in "Open With", > and I couldn't launch Mumble from Run Application (Alt+F2). > > Solution: > https://trisquel.info/en/forum/guix-trisquel#comment-122789 > (Thanks, ADFENO!) > > GNOME sees apps and icons now! > > Remaining hurdles: > * Buttons don't show up, themes don't match: > https://lut.im/g7za20HA8Z/U8CWURMKf3X0a1GI.png > * Fcitx Mozc input method for Japanese does not work in Guix apps -- - https://libreplanet.org/wiki/User:Adfeno - Palestrante e consultor sobre /software/ livre (não confundir com gratis). - "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar instantaneamente comigo no endereço abaixo. - Contato: https://libreplanet.org/wiki/User:Adfeno#vCard - Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft Office, MP3, MP4, WMA, WMV. - Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF (apenas sem DRM), PNG, TXT, WEBM. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Application Setup on Trisquel 2017-10-24 18:12 Application Setup on Trisquel Caleb Herbert 2017-10-24 21:16 ` Ludovic Courtès @ 2017-11-02 2:59 ` Mark H Weaver 1 sibling, 0 replies; 19+ messages in thread From: Mark H Weaver @ 2017-11-02 2:59 UTC (permalink / raw) To: Caleb Herbert; +Cc: help-guix "Caleb Herbert" <csh@bluehome.net> writes: > * Trisquel does not have xset On Debian-derived systems, 'xset' is part of the 'x11-xserver-utils' package. I found this by visiting: https://packages.debian.org/file:xset or see the "Search the contents of packages" section of https://packages.debian.org/ Mark ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2017-11-12 17:09 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-10-24 18:12 Application Setup on Trisquel Caleb Herbert 2017-10-24 21:16 ` Ludovic Courtès 2017-10-24 22:04 ` Caleb Herbert 2017-10-26 17:54 ` Ludovic Courtès 2017-10-27 1:02 ` Chris Marusich 2017-10-24 23:33 ` Caleb Herbert 2017-10-24 23:44 ` Caleb Herbert 2017-10-26 17:52 ` Ludovic Courtès 2017-10-26 20:05 ` Caleb Herbert 2017-10-25 0:36 ` Mikhail Kryshen 2017-10-26 17:53 ` Ludovic Courtès 2017-10-27 3:29 ` Caleb Herbert 2017-11-08 6:39 ` Caleb Herbert 2017-11-09 21:05 ` Chris Marusich 2017-11-10 21:29 ` Caleb Herbert 2017-11-12 14:55 ` Adonay Felipe Nogueira 2017-11-12 17:09 ` Adonay Felipe Nogueira 2017-11-12 13:02 ` Adonay Felipe Nogueira 2017-11-02 2:59 ` Mark H Weaver
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).