Change:
<title>Citrix Workspace</title> <para> <del> <note> <para> Please note that the <literal>citrix_receiver</literal> package has been deprecated since its development was <link xlink:href="https://docs.citrix.com/en-us/citrix-workspace-app.html">discontinued by upstream</link> and has been replaced by <link xlink:href="https://www.citrix.com/products/workspace-app/">the citrix workspace app</link>. </para> </note> <link xlink:href="https://www.citrix.com/products/receiver/">Citrix Receiver</link> and <link xlink:href="https://www.citrix.com/products/workspace-app/">Citrix Workspace App</link> are a remote desktop viewers which provide access to <link xlink:href="https://www.citrix.com/products/xenapp-xendesktop/">XenDesktop</link> installations. </del> <ins> The <link xlink:href="https://www.citrix.com/products/workspace-app/">Citrix Workspace App</link> is a remote desktop viewer which provides access to <link xlink:href="https://www.citrix.com/products/xenapp-xendesktop/">XenDesktop</link> installations. </ins> </para> <section xml:id="sec-citrix-base"> <title>Basic usage</title> <para> <del> The tarball archive needs to be downloaded manually as the license agreements of the vendor for <link xlink:href="https://www.citrix.com/downloads/citrix-receiver/">Citrix Receiver</link> or <link xlink:href="https://www.citrix.de/downloads/workspace-app/linux/workspace-app-for-linux-latest.html">Citrix Workspace</link> need to be accepted first. Then run <command>nix-prefetch-url file://$PWD/linuxx64-$version.tar.gz</command>. With the archive available in the store the package can be built and installed with Nix. </del> <ins> The tarball archive needs to be downloaded manually as the license agreements of the vendor for <link xlink:href="https://www.citrix.de/downloads/workspace-app/linux/workspace-app-for-linux-latest.html">Citrix Workspace</link> needs to be accepted first. Then run <command>nix-prefetch-url file://$PWD/linuxx64-$version.tar.gz</command>. With the archive available in the store the package can be built and installed with Nix. </ins> </para> <ins> </section> </ins> <del> <warning> <title>Caution with <command>nix-shell</command> installs</title> <para> It's recommended to install <literal>Citrix Receiver</literal> and/or <literal>Citrix Workspace</literal> using <literal>nix-env -i</literal> or globally to ensure that the <literal>.desktop</literal> files are installed properly into <literal>$XDG_CONFIG_DIRS</literal>. Otherwise it won't be possible to open <literal>.ica</literal> files automatically from the browser to start a Citrix connection. </para> </warning> </del> <ins> <section xml:id="sec-citrix-selfservice"> <title>Citrix Selfservice</title> <para> The <link xlink:href="https://support.citrix.com/article/CTX200337">selfservice</link> is an application managing Citrix desktops and applications. Please note that this feature only works with at least <package>citrix_workspace_20_06_0</package> and later versions. </para> <para> In order to set this up, you first have to <link xlink:href="https://its.uiowa.edu/support/article/102186">download the <literal>.cr</literal> file from the Netscaler Gateway</link>. After that you can configure the <command>selfservice</command> like this: <screen> <prompt>$ </prompt>storebrowse -C ~/Downloads/receiverconfig.cr <prompt>$ </prompt>selfservice </screen> </para> </ins> </section> <section xml:id="sec-citrix-custom-certs"> <title>Custom certificates</title> <para> <del> The <literal>Citrix Workspace App</literal> in <literal>nixpkgs</literal> trust several certificates <link xlink:href="https://curl.haxx.se/docs/caextract.html">from the Mozilla database</link> by default. However several companies using Citrix might require their own corporate certificate. On distros with imperative packaging these certs can be stored easily in <link xlink:href="https://developer-docs.citrix.com/projects/receiver-for-linux-command-reference/en/13.7/"><literal>$ICAROOT</literal></link>, however this directory is a store path in <literal>nixpkgs</literal>. In order to work around this issue the package provides a simple mechanism to add custom certificates without rebuilding the entire package using <literal>symlinkJoin</literal>: </del> <ins> The <literal>Citrix Workspace App</literal> in <literal>nixpkgs</literal> trusts several certificates <link xlink:href="https://curl.haxx.se/docs/caextract.html">from the Mozilla database</link> by default. However several companies using Citrix might require their own corporate certificate. On distros with imperative packaging these certs can be stored easily in <link xlink:href="https://developer-docs.citrix.com/projects/receiver-for-linux-command-reference/en/13.7/"><literal>$ICAROOT</literal></link>, however this directory is a store path in <literal>nixpkgs</literal>. In order to work around this issue the package provides a simple mechanism to add custom certificates without rebuilding the entire package using <literal>symlinkJoin</literal>: </ins> <programlisting> <![CDATA[with import <nixpkgs> { config.allowUnfree = true; }; let extraCerts = [ ./custom-cert-1.pem ./custom-cert-2.pem /* ... */ ]; in

Discussion:
Describe the bug citrixworkspace: Makes only , not other apps from the suite, avalibale on Manually running other apps (such as ) fails due to missing libraries Other applications in the suite (e.g. ) have similar linking issues To Reproduce Steps to reproduce the behavior: via and that from the package is not on the directly from /nix/store path produces: running . It starts, but some actions (e.g. adding the account) fail due to similar linking issues Expected behavior Other apps from the suite (, ) should be able to start. Additional context I don't have access to the system right now to paste the below information, but if something is essential, please let me know and I'll try my best to get it into the issue. Note that having seems like it's not enough in some situations. In my case, the browser doesn't even download the file, it launches the Citrix Receiver for Web / HTML5 in another tab. on the other hand launches it as a native desktop app, so for me looks like I need working at the minimum, likely as well and other apps from the suite might be needed underneath. More details here: The poster in the link above is using version , on my end I worked with the latest . The post in the link above has this issue: which happens on my end as well. Adding to and doing what doronbehar suggested , i.e. solves the above, but then it complains about . The version I have in my /nix/store is 2.6 and I was not sure how to install 2.4 as well. On my end, this: is not an issue - I'm able to start fine. However I cannot test due to not having to test with (see above). Since other apps (e.g. ) are able to start, but break later, I cannot confirm is actually fully working. Notify maintainers Metadata I don't have access to the system right now to paste the below information, but if something is essential, please let me know and I'll try my best to get it into the issue. Please run and paste the result.

Maintainer information:
Yes, this is an expected error, before this executable is usable on NixOS, we have to modify the ELF header accordingly: I use with a file almost daily and didn't encounter any issues btw. I'll try to fix it soon, but I can't promise that I can test everything properly, so before we'll push this fix to master, I'll probably need your help with testing :)
Thanks for a quick reply Yep, figured as much. The only thing is I saw the seems to be finding all executables, so I was not sure why only was touched instead of all executables in the suite. Unless the issue is that doesn't have the necessary dependencies, so patchelf doesn't replace all. New and not very familiar with NixOs and patchelf, so obviously I'm missing something :) I'll try my best to help with this. Let me know what the best way to proceed is when you get a chance.
No worries. isn't the friendliest thing when learning packaging with Nix(OS) :) Yes. Will ping you as soon as the PR is ready.
would you mind testing ?
Sure, should I follow docs to do that? I.e. something along the lines of:
Probably not: you don't want to rebuild your system on a slightly outdated master branch. Just check out my branch, build citrix locally and test it :)
OK, so something like: Or did you mean something like Using nix-shell for package development 
I don't recommend to checkout another nixpkgs. How about something like this:
Thanks this seems to be mostly working. and work fine from what I see. starts, but runs into this issue: Let me know if I can help with troubleshooting this somehow. I've managed to connect in using , so at least there's a workable solution - maybe worth including this into as well.
Was there any output from the tool? Have you tried e.g. removing temporarily? And, from which dir and as which user did you run it?
Whenever I start it (without ), I just get this: The GUI is displayed, but it just displays "Citrix Receiver" and the spinner that spins forever after printing that in the console. Removing it did not help. Tried from these: Same outcome. Using my normal user ( in ).

Looking at the stacktrace, it looks like it's failing while trying to launch a WebKit browser. Not sure if there's anything else that WebKit requires on top of everything else.
:+1: This happened while you were just starting ? Can you remove again and check if any daemons (like the AuthDaemon) are running ()? If that's the case, please kill those processes first and then run again. Plesae note that this only works if this autodiscovery of your Netscaler Gateway is enabled (IIRC, may be wrong though). To test the selfservice you should(tm) be able to do something like this:
Yeah. I mean I set up the store beforehand with , but after it's set up I just start and it (potentially after asking me for credentials) just outputs the assert error and then spins there forever. Sure: results in the same error as before:
Hmm, that means that there's now window asking for your credentials? Did Citrix ask to accept the EULA on the startup (should happen whenver is removed)? Which desktop env are you on? While you're at it, you could try to check with WireShark whether there's some citrix-related traffic and check and for suspicious things. Btw, just in case, do you need some special certs to access the netscaler gateway in the browser?
Yeah. The error comes after the credentials are inputted. If I kill it after it starts spinning and re-run, it will not ask for credentials again since it caches them, but will still print the error and enter the spinning state. Yes. Xfce. Nothing in either or is output after starting . With , I can see DNS and HTTP requests every now and then towards the addresses in Beacons in . Nothing popped out as suspicious. When completely disabling the wired interface (), I get the error: but I still get the Glib error in console and GUI hangs spinning. No. I have a xubuntu installation where citrix is working fine. It's on the same box where I'm troubleshooting this. I'll try to see if there's something different there and report back. Perhaps the error is a red-herring and something else is going on.
Sorry, forgot to ask another question: is there anything interesting in ?

A few data points: I've enabled tracing for selfservice and diffed the tracings between two versions (xubuntu that's working and nixos that's not). Aside from timing, they seem the same to me, so that did not yield anything useful. The xubuntu installation has citrix 19.10.0.15 (manually installed I think by just downloading official citrix build). However it's 1) working fine 2) not logging the GLib error in question. on the xubuntu version yields a much shorter list of libraries (29) than in this build (118). Notably, is absent in xubuntu version. I'll see if I can install the latest citrix on xubuntu and test with that, since it might not be related to this build at all (e.g. might be something I can reproduce in stock citrix 20.04).
First of all thanks a lot for your patience and the detailed information you provided! You may want to try out out then. So unless this is a 20.04 regression (which would be the case if from Nix works fine), we can be fairly sure that the GLib error is the culprit. I'll try to investigate during the next days after I got an answer from you :) This is probably due to the -hack. This was needed because some executables needed libraries that aren't loaded in the ELF (IIRC). I'll see if the error may be related to one of those. While you're at it, can you please check which version of OpenSSL is used (i.e. 1.0.2 or 1.1) for Citrix on XUbuntu?
Hey, I should be thanking you! :) This version is slightly worse: When run out of gdb, this is printed: and then it segfaults as per above. It doesn't even get to the GUI spinning part like 20.04 (though it briefly shows the GUI). For some reason, clearing out makes a difference the first time: it behaves like 20.04, i.e. it displays only the GLib error and the GUI just spins. On each subsequent start, it behaves as above. , and from this version work fine, so again it's only that seems to be the issue.

Note also that won't start due to: In 20.04 it was starting and behaving the same as . Well that's old...
Frankly, I'm not sure what's going on with glib here. didn't help either. IIRC you are fairly experienced with those desktop components. In case you have time to, it would be awesome if you could take a look at , the issues we have are reported in this issue, starting at . also CCing who may know something about this package I don't know.
Sorry, cannot debug further at the moment.
So, this is the backtrace with debugging symbols from : Indeed this is related to . However, I'm slightly confused, according to the upstream docs (https://developer-), the strings between their dialog lib and the application should(tm) be utf8-encoded. Unfortunately I couldn't retrieve any information about the argument-values from due to missing symbols. I guess that this is somehow related to missing debug symbols from all Citrix libraries (I locally declared to make sure that those would've been retained). I have to mention that I already went down several rabbit-holes in the past weeks because of that and debugging this is beginning to eat too much of my time, so I'll have to step down a bit from investigating this for now, sorry! In case someone else wants to take over, I'm totally fine with this (commiters can also push to my -branch), otherwise I'll restart working on this in a few days or weeks. the question is, how we want to proceed here. A few other features like and do work now, so if that's sufficient for you, we could merge the PR as-is and open an issue about the issue. Otherwise, the best solution for now would be to use a VM, unfortunately.
Does not look like the debug symbols are included. Did you install the packages having to ? relies on environment variable which sets to so you need to install the packages to be linked there.
In my particular case is a nice to have and not critical now that I have working, so if you are fine with that then yeah absolutely I'm all good with pushing this as-is to master and opening a separate issue for part - or even not opening an issue if you don't want to spend more time on it, totally understandable. Thanks for helping me so far, very grateful!

Especially since I'm just starting with NixOS, having help like this was really important, so kudos!
can you recheck with 20.06? I cannot reproduce the glib error there anymore.
Sorry for the delay - agreed, I've re-built using the latest you pushed to the branch and from Citrix Workspace 20.06 (Jun 30, 2020 release) seems to be working fine with that, so looks to me that all is resolved at this point. Thanks again for your help with this!
That's great to hear! I just updated the documentation to note that should only be used currently with . Unfortunately, I found another issue: (we need ) is deprecated (). I'm currently looking for a solution and will push this to the PR's branch. After that I'd ask you to do a final review to make sure we didn't miss anything and then we can finally merge this and resolve this issue.
So I've tested with the latest: is working as expected, however is not: Note that the previous version works fine (though there's no link in ): Both runs with cleaned-up . Not sure if anything changed related to that - are you able to repro on your end?
should be fixed now :)
Just built and tested , now all apps in are starting fine so !