From xpra at zellners.com Sun Jul 4 19:59:30 2021 From: xpra at zellners.com (xpra at zellners.com) Date: Sun, 04 Jul 2021 11:59:30 -0700 Subject: [winswitch] Xpra - Test system works, production dies??? No server - but program runs??? Message-ID: <20210704115930.Horde.vnwT3wmzU63LZKLuPFBYQYN@lv-shared03.cpanelplatform.com> I am doing some setup for a program (java based, will provide more needed, but read on for now, please). I did a rebuild on a system, tested out Xpra (YES ***XPRA REPOS***, per site, Kubuntu 20.0.2 ESR $ xpra --version xpra v4.2-r0). Test system ran, and I was all pleased I could put this into production. Update the production system, and install XPRA (yes same version, same repo), no joy on that program, or even xclock! Xpra was installed in both cases step by step by the example at the very bottom of: https://github.com/Xpra-org/xpra/wiki/Download#-linux DISTRO=focal #install https support for apt (which may be installed already): sudo apt-get update sudo apt-get install apt-transport-https # add Xpra GPG key wget -q https://xpra.org/gpg.asc -O- | sudo apt-key add - # add Xpra repository sudo add-apt-repository "deb https://xpra.org/ $DISTRO main" # install Xpra package sudo apt-get update sudo apt-get install xpra Running xpra attach :100, client starts, and then I get output in the /var/....:100.log file out waiting 20 seconds, no server found, unknown server state etc.. Hardware is different between systems, no fancy video cards in either, both actually have some generic AMD sludge. These are not super current systems, the working system is probably 5-6+ years old, but maxed out in RAM, 6 core CPU etc.. XPRA and this works, so I was ready to get to work with it... The other, production, is a SoC type board (NOT A PI! AMD A10 based 4 core). The only think I can find that is different software wise is KERNELS Working: Linux xxxp6633w 5.8.0-55-generic #62~20.04.1-Ubuntu SMP Wed Jun 2 08:55:04 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux NON working Linux xxxxSDRBox 5.4.0-77-generic #86-Ubuntu SMP Thu Jun 17 02:35:03 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux Everything else between the two is the same for the OS. Both have had updates to be as current as the Canocial repos are offering in the OS. What debug logs do you need to track??? The funny thing is that the PROGRAM will RUN on the "NON 'WORKING' " system in that it operates as expected, but you can NOT CONNECT TO THE GUI via the new X server. Start up command: xpra start :100 --start=/home/X0/050a6/XXXX/bin/run-program Program name is obfuscated for reasons, I will provide privately, but not in public right now. I will provide more data as requested, and asked for, I am not dumping useless data to the list to sift through, I'd rather ask first, and provide the targeted data to resolve this hopefully. What data, logs, etc. would you like? Nothing jumps out at me as to what might be the difference other than the kernels... The program runs, it does its thing, you just can not connect to the GUI X Server from Xpra to control it. Thanks for your time and insight. From antoine at nagafix.co.uk Mon Jul 5 16:02:37 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 5 Jul 2021 22:02:37 +0700 Subject: [winswitch] Xpra - Test system works, production dies??? No server - but program runs??? In-Reply-To: <20210704115930.Horde.vnwT3wmzU63LZKLuPFBYQYN@lv-shared03.cpanelplatform.com> References: <20210704115930.Horde.vnwT3wmzU63LZKLuPFBYQYN@lv-shared03.cpanelplatform.com> Message-ID: (..) > Hardware is different between systems, no fancy video cards in either, > both actually have some generic AMD sludge. These are not super current > systems, the working system is probably 5-6+ years old, but maxed out in > RAM, 6 core CPU etc.. XPRA and this works, so I was ready to get to work > with it...? The other, production, is a SoC type board (NOT A PI! AMD > A10 based 4 core). > > The only think I can find that is different software wise is KERNELS > > Working: > Linux xxxp6633w 5.8.0-55-generic #62~20.04.1-Ubuntu SMP Wed Jun 2 > 08:55:04 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux > > NON working > Linux xxxxSDRBox 5.4.0-77-generic #86-Ubuntu SMP Thu Jun 17 02:35:03 UTC > 2021 x86_64 x86_64 x86_64 GNU/Linux > > > Everything else between the two is the same for the OS. Both have had > updates to be as current as the Canocial repos are offering in the OS. At this point, my guess is that something hardware related is hanging and we've just had a few reports of problems with the ffmpeg vaapi hardware accelerated encoder: https://github.com/Xpra-org/xpra/issues/3174 If that's the cause of your problem, you can run with: xpra start --env=XPRA_VAAPI=0 .... Or even skipping any codec with hardware access: xpra start --video-encoders=all,-ffmpeg,-nvenc Video encoders are the only components that access the hardware somewhat more directly than through generic OS APIs. > What debug logs do you need to track??? As always, the server log. Since I suspect that the codecs are the problem, the output of: xpra encoding > The funny thing is that the PROGRAM will RUN on the "NON 'WORKING' " > system in that it operates as expected, but you can NOT CONNECT TO THE > GUI via the new X server. That's because the X11 virtual framebuffer is running, and your program is happily running on it, but the xpra server has crashes or is unresponsive. Cheers, Antoine > Start up command: > xpra start :100 --start=/home/X0/050a6/XXXX/bin/run-program > > Program name is obfuscated for reasons, I will provide privately, but > not in public right now. > > I will provide more data as requested, and asked for, I am not dumping > useless data to the list to sift through, I'd rather ask first, and > provide the targeted data to resolve this hopefully. > > What data, logs, etc. would you like? > > Nothing jumps out at me as to what might be the difference other than > the kernels... The program runs, it does its thing, you just can not > connect to the GUI X Server from Xpra to control it. > > Thanks for your time and insight. > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users From xpra at zellners.com Tue Jul 6 17:52:55 2021 From: xpra at zellners.com (xpra at zellners.com) Date: Tue, 06 Jul 2021 09:52:55 -0700 Subject: [winswitch] Xpra - Test system works, production dies??? No server - but program runs??? In-Reply-To: References: <20210704115930.Horde.vnwT3wmzU63LZKLuPFBYQYN@lv-shared03.cpanelplatform.com> Message-ID: <20210706095255.Horde.rlNGpmEnL7yG5jj5rZrKUBI@lv-shared03.cpanelplatform.com> Quoting Antoine Martin via shifter-users : > and we've just had a few reports of problems with the ffmpeg vaapi > hardware accelerated encoder: > https://github.com/Xpra-org/xpra/issues/3174 > > If that's the cause of your problem, you can run with: > xpra start --env=XPRA_VAAPI=0 .... OK. Using that, solves *my* issue, but I would guess... maybe not for others and the best??? This is not optimal????? Especially with something that may have intensive graphics interactions, which is the case here in a few situations... So is this: XPRA? Kernel? underlying drivers for hardware???? Combination of this???? Just looking to get the best out of XPRA. Thanks. From xpra at zellners.com Tue Jul 6 18:00:19 2021 From: xpra at zellners.com (xpra at zellners.com) Date: Tue, 06 Jul 2021 10:00:19 -0700 Subject: [winswitch] Packaging note - *buntunu 20.04...at least Message-ID: <20210706100019.Horde.w-hJik7fQUm6qYyaeK90O_A@lv-shared03.cpanelplatform.com> Something you might want to make a dependency of the XPRA repo is python3-distutils That solves several issues/errors that come out when starting the server and client(s)... That might be a default in some earlier releases, but at least as of 20.04.2 ESR's its not on the ISO's. My two machines I working with right now are rebuilt recently and based on the ISO on the release...18.04 doesn't seem to have it either. Just some FYI and feedback.... Thanks. From antoine at nagafix.co.uk Sat Jul 10 04:18:28 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 10 Jul 2021 10:18:28 +0700 Subject: [winswitch] Xpra - Test system works, production dies??? No server - but program runs??? In-Reply-To: <20210706095255.Horde.rlNGpmEnL7yG5jj5rZrKUBI@lv-shared03.cpanelplatform.com> References: <20210704115930.Horde.vnwT3wmzU63LZKLuPFBYQYN@lv-shared03.cpanelplatform.com> <20210706095255.Horde.rlNGpmEnL7yG5jj5rZrKUBI@lv-shared03.cpanelplatform.com> Message-ID: <2be8a3d3-375f-8e84-cf86-8bef847065be@nagafix.co.uk> On 06/07/2021 23:52, xpra--- via shifter-users wrote: > > Quoting Antoine Martin via shifter-users > : > >> and we've just had a few reports of problems with the ffmpeg vaapi >> hardware accelerated encoder: >> https://github.com/Xpra-org/xpra/issues/3174 >> >> If that's the cause of your problem, you can run with: >> xpra start --env=XPRA_VAAPI=0 .... > > OK. Using that, solves *my* issue, but I would guess... maybe not for > others and the best??? I'm not sure what you mean. The NVENC encoder has also had a few problems in the past, the most common one being a slow startup with some professional multi GPU cards. But the ffmpeg vaapi codec is the only one that seems to causes crashes or hangs, which is why it is going to be turned off by default in 4.2.1: https://github.com/Xpra-org/xpra/commit/fb52a4b8e58eaa27df509e2286d16efcd0d93ae6 > This is not optimal????? Clearly not. > Especially with something that may have > intensive graphics interactions, which is the case here in a few > situations... Just to be clear: we're talking about video compression. You can still run any application you like, with or without opengl acceleration - as this is a different aspect. Hardware assisted video compression is only really needed to support high framerate and / or high resolutions. > So is this: > > XPRA? Unlikely but possible. And it could be a argued that the API is not very robust if it allows simple calls to completely lock up an application. (especially when those calls do work on other kernel / driver combinations) > Kernel? > underlying drivers for hardware???? Usually yes. > Combination of this???? Likely yes. But that's impossible for me to tell without more details. Feel free to create a ticket and attach your logs: https://github.com/Xpra-org/xpra/issues/new/choose > Just looking to get the best out of XPRA. For now, just turn off VAAPI. Cheers, Antoine > > Thanks. > > > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users From antoine at nagafix.co.uk Sat Jul 10 04:23:09 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 10 Jul 2021 10:23:09 +0700 Subject: [winswitch] Packaging note - *buntunu 20.04...at least In-Reply-To: <20210706100019.Horde.w-hJik7fQUm6qYyaeK90O_A@lv-shared03.cpanelplatform.com> References: <20210706100019.Horde.w-hJik7fQUm6qYyaeK90O_A@lv-shared03.cpanelplatform.com> Message-ID: <2e48ee7a-f45f-003c-f7ad-2bf062f615c4@nagafix.co.uk> On 07/07/2021 00:00, xpra--- via shifter-users wrote: > > Something you might want to make a dependency of the XPRA repo is > python3-distutils > > That solves several issues/errors that come out when starting the server > and client(s)... Can you please clarify what those issues are? The only one we're aware of is documented here: https://github.com/Xpra-org/xpra/pull/3177 TLDR: python distutils is no longer required in 4.2.1 Cheers, Antoine > That might be a default in some earlier releases, but at least as of > 20.04.2 ESR's its not on the ISO's. My two machines I working with right > now are rebuilt recently and based on the ISO on the release...18.04 > doesn't seem to have it either. > > Just some FYI and feedback.... Thanks. > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users From xpra at zellners.com Tue Jul 6 18:13:47 2021 From: xpra at zellners.com (xpra at zellners.com) Date: Tue, 06 Jul 2021 10:13:47 -0700 Subject: [winswitch] SSH CLI usage - prompt for password, NO keys! Message-ID: <20210706101347.Horde.6s8Wd6u-0UttB-pTE9tPhPN@lv-shared03.cpanelplatform.com> Trying to connect to the XPRA server via SSH, but running into issues that it seems to insist on SSH KEYS. I don't use those, thats my choice, I have my reasons, and don't want to derail this in to a debate on those. I can't seem to get XPRA to go this route, I've tried all kinds of formats and options xpra attach ssh://xpra at xpra:100 xpra attach ssh/xpra at xpra/100 xpra xpra_launcher No joy. ssh to the box, and X11 forward works...seems to be a hack kludge.... ssh -XCl xpra xprabox then xpra attach :100 I've looked at too many man pages, web sites, XPRA wiki and am clearly missing something to get this to ask for a password.... Any clues for idiots lost in the forest??? Thanks! From antoine at nagafix.co.uk Sat Jul 10 05:03:03 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 10 Jul 2021 11:03:03 +0700 Subject: [winswitch] SSH CLI usage - prompt for password, NO keys! In-Reply-To: <20210706101347.Horde.6s8Wd6u-0UttB-pTE9tPhPN@lv-shared03.cpanelplatform.com> References: <20210706101347.Horde.6s8Wd6u-0UttB-pTE9tPhPN@lv-shared03.cpanelplatform.com> Message-ID: <9b44d7d8-e60f-b6aa-3b61-d5198c2dfb29@nagafix.co.uk> On 07/07/2021 00:13, xpra--- via shifter-users wrote: > > Trying to connect to the XPRA server via SSH, but running into issues > that it seems to insist on SSH KEYS. It will try the keys it can find (and an ssh agent if you have one) then fallback to the password authentication - assuming that the server allows it. If you specify a password on the command line, it will try that first. You can also configure which authentication steps will be attempted, for password only: xpra attach --ssh=paramiko:auth=password > I don't use those, thats my choice, > I have my reasons, and don't want to derail this in to a debate on those. > > I can't seem to get XPRA to go this route, I've tried all kinds of > formats and options > > xpra attach ssh://xpra at xpra:100 > xpra attach ssh/xpra at xpra/100 > xpra I have amended the documentation to make this clearer: https://github.com/Xpra-org/xpra/blob/master/docs/Network/SSH.md We use the standard URI format (this is true for all connection modes, not just SSH): xpra attach ssh://USER:PASSWORD at HOST:PORT/DISPLAY > xpra_launcher > > No joy. Please always include the full error messages and output. You can run your client with "--debug ssh" to see more details on which step of the SSH connection it is failing at. > > ssh to the box, and X11 forward works...seems to be a hack kludge.... > > ssh -XCl xpra xprabox > then > xpra attach :100 Yes, that's a bad idea. You're using SSH X11 forwarding with xpra, the performance will be terrible. > I've looked at too many man pages, web sites, XPRA wiki and am clearly > missing something to get this to ask for a password.... > > Any clues for idiots lost in the forest??? Thanks! It should just work out of the box and prompt you for a password using pinentry or a dialog box, depending on your OS / DE and version in use. It may just be a trivial misconfiguration or missing dependency somewhere. Without further details, it's impossible to say. Depending on what OS you're running on, you can also switch to the older ssh backend: xpra attach --ssh="ssh" Cheers, Antoine From xpra at zellners.com Wed Jul 7 15:50:57 2021 From: xpra at zellners.com (xpra at zellners.com) Date: Wed, 07 Jul 2021 07:50:57 -0700 Subject: [winswitch] Error on disconect Message-ID: <20210707075057.Horde.pxZr7dWuhFIVOAKqyTL5pbo@lv-shared03.cpanelplatform.com> Getting the following error when disconnecting from a XPRA server 2021-07-06 23:25:19,020 audio playback stopping /usr/lib/python3/dist-packages/gi/overrides/Gtk.py:1632: Warning: g_object_ref: assertion 'G_IS_OBJECT (object)' failed return _Gtk_main(*args, **kwargs) Thats the last two lines of the log. Audio playback does work from the server, but get this on any disconnect. XPRA 4.02rc0 from XPRA repos, *buntu 20.04.2 on server and clients. Thanks! From antoine at nagafix.co.uk Sat Jul 10 05:14:19 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 10 Jul 2021 11:14:19 +0700 Subject: [winswitch] Error on disconect In-Reply-To: <20210707075057.Horde.pxZr7dWuhFIVOAKqyTL5pbo@lv-shared03.cpanelplatform.com> References: <20210707075057.Horde.pxZr7dWuhFIVOAKqyTL5pbo@lv-shared03.cpanelplatform.com> Message-ID: On 07/07/2021 21:50, xpra--- via shifter-users wrote: > > Getting the following error when disconnecting from a XPRA server > > > 2021-07-06 23:25:19,020 audio playback stopping Nothing to worry about here: you're disconnecting so the audio will also stop. > /usr/lib/python3/dist-packages/gi/overrides/Gtk.py:1632: Warning: > g_object_ref: assertion 'G_IS_OBJECT (object)' failed > ? return _Gtk_main(*args, **kwargs) This is completely unrelated to the audio playback and can safely be ignored. I have added this to the FAQ: https://github.com/Xpra-org/xpra/commit/3ee7856363071b4638548b68a0cda8f5245fc72a Cheers, Antoine > > Thats the last two lines of the log. > > Audio playback does work from the server, but get this on any disconnect. > > XPRA 4.02rc0 from XPRA repos, *buntu 20.04.2 on server and clients. > > Thanks! > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users From xpra at zellners.com Wed Jul 7 15:46:51 2021 From: xpra at zellners.com (xpra at zellners.com) Date: Wed, 07 Jul 2021 07:46:51 -0700 Subject: [winswitch] Packaging note - *buntunu 20.04...at least Message-ID: <20210707074651.Horde.KIqbJ5e9BLiLhssg1mb5ibA@lv-shared03.cpanelplatform.com> > Something you might want to make a dependency of the XPRA repo is > python3-distutils This is definitely a dependency to get a lot of things to work. After installing this, SSH works, as does the audio forwarding now. Also likely a good thing to add to the dependencies is: python3-dnsutils That will resolve no module "dns" errors. From antoine at nagafix.co.uk Sat Jul 10 05:49:51 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 10 Jul 2021 11:49:51 +0700 Subject: [winswitch] Packaging note - *buntunu 20.04...at least In-Reply-To: <20210707074651.Horde.KIqbJ5e9BLiLhssg1mb5ibA@lv-shared03.cpanelplatform.com> References: <20210707074651.Horde.KIqbJ5e9BLiLhssg1mb5ibA@lv-shared03.cpanelplatform.com> Message-ID: On 07/07/2021 21:46, xpra--- via shifter-users wrote: > > >> Something you might want to make a dependency of the XPRA repo is >> python3-distutils > > This is definitely a dependency to get a lot of things to work. > > After installing this, SSH works, Please always include the exact error messages. As it stands, I intend to release 4.2.1 soon without the distutils dependency which has been superseded, as per this link I sent earlier: https://github.com/Xpra-org/xpra/pull/3177 If this is a different problem, then please include the details so that I can make an informed decision on what packaging and code updates to include with 4.2.1 > as does the audio forwarding now. I was not aware that there were any problems with audio forwarding from any of your earlier posts. Only an unrelated GTK warning. > Also likely a good thing to add to the dependencies is: > > python3-dnsutils There is no such package, perhaps you mean python3-dnspython? https://github.com/Xpra-org/xpra/commit/116cfdb1737fd53971e6b1968df84ee29b6a59e6 > That will resolve no module "dns" errors. There is an option to use SSHFP DNS records for key verification: https://github.com/Xpra-org/xpra/issues/2097 But this is optional and not an error. You can turn it off with: xpra attach --ssh=paramiko:verifyhostkeydns=no Cheers, Antoine From totaam at xpra.org Sun Jul 11 07:20:35 2021 From: totaam at xpra.org (Antoine Martin) Date: Sun, 11 Jul 2021 13:20:35 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 4.2.1 - many fixes, some critical Message-ID: Hi, This update contains a large number of fixes in the areas of build and packaging, the proxy server, some specific platforms (MacOS and MS Windows), the networking layer, encodings, etc Some of these are critical: * proxy server fixes - big thanks to Vasyl Gello * MS Windows crashes during printer enumeration * ffmpeg codec crashes * webp encoder invalid memory access * SVG icon loading causing crashes The more detailed release notes can be found here: https://github.com/Xpra-org/xpra/releases/tag/v4.2.1 Downloads: https://github.com/Xpra-org/xpra/wiki/Download Cheers Antoine From dusan at dussan.org Tue Jul 13 07:35:53 2021 From: dusan at dussan.org (=?UTF-8?Q?Du=c5=a1an_Vejnovi=c4=8d?=) Date: Tue, 13 Jul 2021 08:35:53 +0200 Subject: [winswitch] Location of the run-xpra script Message-ID: <3249703c-e508-d276-28c5-7dcafdf3057f@dussan.org> Hello. I have a problem. When I run xpra as a user demo1, the run-xpra script is created in the folder /tmp/xpra. Only user demo1 has rights on that folder. However, if I run xpra as a user demo2, the run-xpra script is not created in the folder /tmp/xpra because the user demo2 has no rights on that folder. How could I change the location of the run-xpra script to make it in the demo2 user's home folder, e.g. in the ~/.xpra folder. Some more information: - xpra running on Debian 10 - running xpra version 4.2.1 - all default settings are unchanged - an example of how to run xpra xpra start:10000 --bind-tcp=0.0.0.0:10000 --tcp-auth=none --start-new-commands=yes --start="xterm" Thanks for the help. -- Du?an From mike at cchtml.com Tue Jul 13 00:01:12 2021 From: mike at cchtml.com (Michael Cronenworth) Date: Mon, 12 Jul 2021 18:01:12 -0500 Subject: [winswitch] RHEL/CentOS repo packages Message-ID: <9b03ce23-854f-5042-b735-93635138b2fe@cchtml.com> Hi Antoine, The 4.2.1/4.3 update has caused a conflict in the RHEL/CentOS repo. You have both 4.2.1 and 4.3 package versions out there, but not a complete set. 'python3-xpra-*' has 4.3, but no matching 'xpra-*' package set so there is a package dependency failure. This also causes problems if people want to pin on a branch. While you can pin a version in yum/dnf you can't pin on a branch without manually touching the version number with each branch release. One solution is one package repo per branch. Another is to inject the branch name into the package name. Thanks, Michael From antoine at nagafix.co.uk Tue Jul 13 18:17:42 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 14 Jul 2021 00:17:42 +0700 Subject: [winswitch] RHEL/CentOS repo packages In-Reply-To: <9b03ce23-854f-5042-b735-93635138b2fe@cchtml.com> References: <9b03ce23-854f-5042-b735-93635138b2fe@cchtml.com> Message-ID: <14af9d17-6da9-f1a1-09ea-221f99adb18f@nagafix.co.uk> On 13/07/2021 06:01, Michael Cronenworth via shifter-users wrote: > Hi Antoine, > > The 4.2.1/4.3 update has caused a conflict in the RHEL/CentOS repo. > > You have both 4.2.1 and 4.3 package versions out there, but not a > complete set. Yes, sorry about that. > 'python3-xpra-*' has 4.3, but no matching 'xpra-*' package set so there > is a package dependency failure. > > This also causes problems if people want to pin on a branch. While you > can pin a version in yum/dnf you can't pin on a branch without manually > touching the version number with each branch release. > > One solution is one package repo per branch. Another is to inject the > branch name into the package name. I've cleaned things up a bit. This should get you going again: dnf clean all Sorry about the hassle. Cheers, Antoine > > Thanks, > Michael From antoine at nagafix.co.uk Tue Jul 13 18:24:36 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 14 Jul 2021 00:24:36 +0700 Subject: [winswitch] Location of the run-xpra script In-Reply-To: <3249703c-e508-d276-28c5-7dcafdf3057f@dussan.org> References: <3249703c-e508-d276-28c5-7dcafdf3057f@dussan.org> Message-ID: <283cce34-5f42-fac1-ad4c-d4b726d599de@nagafix.co.uk> On 13/07/2021 13:35, Du?an Vejnovi? via shifter-users wrote: > Hello. > > I have a problem. When I run xpra as a user demo1, the run-xpra script > is created in the folder /tmp/xpra. Why is that? Are you using su to run xpra perhaps? > Only user demo1 has rights on that > folder. However, if I run xpra as a user demo2, the run-xpra script is > not created in the folder /tmp/xpra because the user demo2 has no rights > on that folder. How could I change the location of the run-xpra script > to make it in the demo2 user's home folder, e.g. in the ~/.xpra folder. Why do you care about having this run-xpra script? It is rarely used nowadays and xpra should work fine without it. > Some more information: > - xpra running on Debian 10 > - running xpra version 4.2.1 > - all default settings are unchanged > - an example of how to run xpra > xpra start:10000 --bind-tcp=0.0.0.0:10000 --tcp-auth=none > --start-new-commands=yes --start="xterm" The run-xpra script is normally created in $XDG_RUNTIME_DIR/xpra You should make sure that $XDG_RUNTIME_DIR exists and is writable when starting xpra for your users. A number of features will use this directory as base for locating and storing files. Alternatively, you could override XPRA_SCRIPT_BIN_DIRS for each user. (but I really don't recommend that) Cheers, Antoine > > > Thanks for the help. > -- Du?an From xpra at zellners.com Thu Jul 15 13:05:48 2021 From: xpra at zellners.com (xpra at zellners.com) Date: Thu, 15 Jul 2021 05:05:48 -0700 Subject: [winswitch] Packaging note - *buntunu 20.04...at least In-Reply-To: <2e48ee7a-f45f-003c-f7ad-2bf062f615c4@nagafix.co.uk> References: <20210706100019.Horde.w-hJik7fQUm6qYyaeK90O_A@lv-shared03.cpanelplatform.com> <2e48ee7a-f45f-003c-f7ad-2bf062f615c4@nagafix.co.uk> Message-ID: <20210715050548.Horde.yqNUwYy6DpG9R8AgPZr9qQ_@lv-shared03.cpanelplatform.com> Quoting Antoine Martin via shifter-users : > On 07/07/2021 00:00, xpra--- via shifter-users wrote: >> >> Something you might want to make a dependency of the XPRA repo is >> python3-distutils >> >> That solves several issues/errors that come out when starting the server >> and client(s)... > Can you please clarify what those issues are? > The only one we're aware of is documented here: > https://github.com/Xpra-org/xpra/pull/3177 The errors are that ssh connection or really any attempts to connect the XPRA SERVER will fail, as what ever protocol(s) are needed need what ever distutils provides to work. After reviewing the error messaage that XPRA LAUNCHER spit out.. that was the clue on distutils. AFTER apt-get install python3-distutils every thing starts working. SSH CLI, XPRA Launcher connections and all the 40+ various formats for SSH connections I tried all work ONCE distutils is installed. so its a dependency. > TLDR: python distutils is no longer required in 4.2.1 I will see what happens on another install which is bare thats been waiting for all this to shake out.. From xpra at zellners.com Thu Jul 15 13:22:22 2021 From: xpra at zellners.com (xpra at zellners.com) Date: Thu, 15 Jul 2021 05:22:22 -0700 Subject: [winswitch] Packaging note - *buntunu 20.04...at least In-Reply-To: References: <20210707074651.Horde.KIqbJ5e9BLiLhssg1mb5ibA@lv-shared03.cpanelplatform.com> Message-ID: <20210715052222.Horde.wp6TH0BMnoiv1jZdPrkIWXE@lv-shared03.cpanelplatform.com> Quoting Antoine Martin via shifter-users : > If this is a different problem, then please include the details so that > I can make an informed decision on what packaging and code updates to > include with 4.2.1 Since there is some huge delay on the ML, It appears that this decision is decided and/or issue corrected based on the posts... python3-distutils IS a DEPENDENCY IF to get SSH connections or any connection to the XPRA SERVER from the client be it CLI or XPRA LAUNCHER without it, any attempt to connect will fail. Don't matter what you try. It won't work. Connecting locally as I did via X11 forwarding as a test works. And yes its horrible in performance, didn't expect any thing less... it was means to find the issue. Outside my depth on C and/or any this other stuff. The "magic pill" to cure it was python3-distutils, now XPRA works as listed to connect. >> as does the audio forwarding now. > I was not aware that there were any problems with audio forwarding from Audio was not being forwarded, I did not consider it an issue for me as audio forwarding is irrelevant mostly for the situation, that it works, is a bonus. What ever XPRA uses to start somethings, above my pay grade, distutils is needed to be installed as after installing, things work 100% now. audio. xpra connections and using all the various formats of SSH commands I've seen and tried. > any of your earlier posts. Only an unrelated GTK warning. > >> Also likely a good thing to add to the dependencies is: >> >> python3-dnsutils > There is no such package, perhaps you mean python3-dnspython? > https://github.com/Xpra-org/xpra/commit/116cfdb1737fd53971e6b1968df84ee29b6a59e6 Thats probably it, I had utils on the brain... I didn't install it as SSHFP stuff is not of use to me, I don't use keys for my own reasons. > But this is optional and not an error. You can turn it off with: > xpra attach --ssh=paramiko:verifyhostkeydns=no Thanks, I will add that to my command, when I update that, don't need it, don't need the error. From steveg at nevets.com.au Sun Jul 18 13:13:42 2021 From: steveg at nevets.com.au (Steve Gatenby) Date: Sun, 18 Jul 2021 22:13:42 +1000 Subject: [winswitch] App Intermittant startup Message-ID: <3a314a08-b5ef-79bd-3d48-0bfd9e3737bb@nevets.com.au> I have a simple gui app. 1 button, 1 memo and timer. On running, it should update the memo entry each second with a status count. Works perfectly on standard systems (linux x64 gtk2), but fails regularly under docker with xpra. I am building the docker instance using the latest xpra from the repo I then run the following to open a terminal, and connect thru my browser (works perfectly) xpra start --bind-tcp=0.0.0.0:10000 --html=on --start=xterm --daemon=no --pulseaudio=no --webcam=no On running the test app from the terminal, I find it consistently fails to show the form for between 10 and 20 seconds. The app is running (logging 1 second counts to terminal), just nothing visual shows. The only xpra logging diff I can see is the 'broadway decoder initialized' line doesnt happen when it is waiting. I am trying to determine if the problem lies with the app, docker, xpra or a combination of all. I have a simple/small docker test I can supply, but dont wish to push files at people unless permission given :) Would really appreciate any insight / clues at all Regards - SteveG From antoine at nagafix.co.uk Sun Jul 18 15:47:41 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 18 Jul 2021 21:47:41 +0700 Subject: [winswitch] App Intermittant startup In-Reply-To: <3a314a08-b5ef-79bd-3d48-0bfd9e3737bb@nevets.com.au> References: <3a314a08-b5ef-79bd-3d48-0bfd9e3737bb@nevets.com.au> Message-ID: <5794d262-3bfb-8312-665c-653e48b92770@nagafix.co.uk> On 18/07/2021 19:13, Steve Gatenby via shifter-users wrote: > I have a simple gui app. 1 button, 1 memo and timer. > > On running, it should update the memo entry each second with a status > count. > > Works perfectly on standard systems (linux x64 gtk2), but fails > regularly under docker with xpra. > > I am building the docker instance using the latest xpra from the repo Which distribution? xpra version, etc. > I then run the following to open a terminal, and connect thru my browser > (works perfectly) > > xpra start --bind-tcp=0.0.0.0:10000 --html=on --start=xterm --daemon=no > --pulseaudio=no --webcam=no > > On running the test app from the terminal, I find it consistently fails > to show the form for between 10 and 20 seconds. The app is running > (logging 1 second counts to terminal), just nothing visual shows. > > The only xpra logging diff I can see is the 'broadway decoder > initialized' line doesnt happen when it is waiting. This log message means that the server is using an h264 video encoder (presumably for sending your application's screen updates) and that the browser is initializing its decoder to process this video stream. If the screen updates don't make it to the screen, you should at least be seeing the window frame. Or perhaps your application is meant to be frameless? In any case, you can disable video encoders from your server command line. I would recommend "--video-encoders=vpx" rather than "--video-encoders=none" so that the python client can still use video when needed. Or you can disable video mode from the html5 client's connect page. You have not specified your browser. We're not aware of any browsers failing on these h264 streams. > I am trying to determine if the problem lies with the app, docker, xpra > or a combination of all. > > I have a simple/small docker test I can supply, but dont wish to push > files at people unless permission given :) > > Would really appreciate any insight / clues at all Try with the python client. If the app shows as expected then the problem lies with the html5 client. Cheers, Antoine > > Regards - SteveG > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users From steveg at nevets.com.au Thu Jul 22 05:19:04 2021 From: steveg at nevets.com.au (Steve Gatenby) Date: Thu, 22 Jul 2021 14:19:04 +1000 Subject: [winswitch] Disable onscreen keyboard Message-ID: <3c5e9a01-a8e8-a12a-3d13-2f9934da91c9@nevets.com.au> Is it at all possible to start the xpra session with the Onscreen keyboard hidden (though still available thru the floating menu) ? eg: xpra start --start-child=xxxx --keyboard=hidden ??? Regards - SteveG From antoine at nagafix.co.uk Sat Jul 24 09:06:04 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 24 Jul 2021 15:06:04 +0700 Subject: [winswitch] Disable onscreen keyboard In-Reply-To: <3c5e9a01-a8e8-a12a-3d13-2f9934da91c9@nevets.com.au> References: <3c5e9a01-a8e8-a12a-3d13-2f9934da91c9@nevets.com.au> Message-ID: On 22/07/2021 11:19, Steve Gatenby via shifter-users wrote: > Is it at all possible to start the xpra session with the Onscreen > keyboard hidden (though still available thru the floating menu) ? > > eg: xpra start --start-child=xxxx --keyboard=hidden ??? The html5 client can be configured in a number of ways: * through the connect dialog page * through URL attributes * by editing the default-settings.txt file There was a bug that wrongly enabled the on-screen keyboard in all cases instead of just on mobile devices: https://github.com/Xpra-org/xpra-html5/issues/47 You can apply the trivial fix or wait for the next update. Cheers, Antoine > > Regards - SteveG > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users