From idallen at idallen.ca Sun May 6 05:31:09 2018 From: idallen at idallen.ca (Ian! D. Allen) Date: Sun, 6 May 2018 00:31:09 -0400 Subject: [winswitch] expired gpg key Message-ID: <20180506043109.GA10089@home.idallen.ca> #?apt update Err:5 http://winswitch.org xenial Release.gpg The following signatures were invalid: KEYEXPIRED 1525416977 KEYEXPIRED 1525416977 KEYEXPIRED 1525416977 W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://winswitch.org xenial Release: The following signatures were invalid: KEYEXPIRED 1525416977 KEYEXPIRED 1525416977 KEYEXPIRED 1525416977 W: Failed to fetch http://winswitch.org/dists/xenial/Release.gpg The following signatures were invalid: KEYEXPIRED 1525416977 KEYEXPIRED 1525416977 KEYEXPIRED 1525416977 W: Some index files failed to download. They have been ignored, or old ones used instead. -- | Ian! D. Allen, BA, MMath - idallen at idallen.ca - Ottawa, Ontario, Canada | Home: http://idallen.com/ Contact Improv Dance: http://contactimprov.ca/ | College professor (Free/Libre GNU+Linux) at: http://teaching.idallen.com/ | Defend digital freedom: http://eff.org/ and have fun: http://fools.ca/ From antoine at nagafix.co.uk Sun May 6 14:50:51 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 6 May 2018 20:50:51 +0700 Subject: [winswitch] expired gpg key In-Reply-To: <20180506043109.GA10089@home.idallen.ca> References: <20180506043109.GA10089@home.idallen.ca> Message-ID: <8d167ac0-8fa4-b64d-283b-18fea9ba9998@nagafix.co.uk> On 06/05/18 11:31, Ian! D. Allen via shifter-users wrote: > #?apt update > > Err:5 http://winswitch.org xenial Release.gpg > The following signatures were invalid: KEYEXPIRED 1525416977 KEYEXPIRED 1525416977 KEYEXPIRED 1525416977 I have extended the expiry date of the key used for signing the packages. To get the updated key, run this command: apt-key adv --keyserver keys.gnupg.net --recv-keys F18AD6BB This should also work: apt-get install dirmngr apt-get adv --fetch-keys https://xpra.org/gpg.asc For RPM based distributions like CentOS and Fedora, try: rpm --import https://xpra.org/gpg.asc Longer term, we would like to move to a different, stronger key, owned by the project rather than individual. But this will have to do for now. Cheers Antoine > > W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://winswitch.org xenial Release: The following signatures were invalid: KEYEXPIRED 1525416977 KEYEXPIRED 1525416977 KEYEXPIRED 1525416977 > W: Failed to fetch http://winswitch.org/dists/xenial/Release.gpg The following signatures were invalid: KEYEXPIRED 1525416977 KEYEXPIRED 1525416977 KEYEXPIRED 1525416977 > W: Some index files failed to download. They have been ignored, or old ones used instead. From antoine at nagafix.co.uk Wed May 9 04:55:17 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 9 May 2018 10:55:17 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 2.3 Message-ID: <230f4b8b-7c43-df12-1bc1-a342d94cb453@nagafix.co.uk> Hi, The most significant changes in this release are: * authentication now supports multiple modules per socket type, with many new modules: tcp wrappers, kerberos, gss, ldap, u2f and more * private pulseaudio server per session to prevent audio leaking * network performance and congestion management improvements * notification icons and actions, also used to expose our own warnings * http server and html5 client: flexible server, system tray forwarding * client: signal forwarding, OS integration, multi-screen support, etc * faster jpeg and webp painting with opengl client, better vsync support * shadow servers: multi-window mode, cursor handling For more details, including links to the documentation and tickets, see: http://xpra.org/trac/wiki/News#a2.3ImportantFeatures The source: https://xpra.org/src/ Downloads: http://xpra.org/trac/wiki/Download Cheers Antoine From antoine at nagafix.co.uk Thu May 10 17:23:05 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 10 May 2018 23:23:05 +0700 Subject: [winswitch] expired gpg key In-Reply-To: <8d167ac0-8fa4-b64d-283b-18fea9ba9998@nagafix.co.uk> References: <20180506043109.GA10089@home.idallen.ca> <8d167ac0-8fa4-b64d-283b-18fea9ba9998@nagafix.co.uk> Message-ID: On 06/05/18 20:50, Antoine Martin via shifter-users wrote: > On 06/05/18 11:31, Ian! D. Allen via shifter-users wrote: >> #?apt update >> >> Err:5 http://winswitch.org xenial Release.gpg >> The following signatures were invalid: KEYEXPIRED 1525416977 KEYEXPIRED 1525416977 KEYEXPIRED 1525416977 > I have extended the expiry date of the key used for signing the > packages. To get the updated key, run this command: > apt-key adv --keyserver keys.gnupg.net --recv-keys F18AD6BB > > This should also work: > apt-get install dirmngr > apt-get adv --fetch-keys https://xpra.org/gpg.asc This should read "apt-key" instead of "apt-get": apt-key adv --fetch-keys https://xpra.org/gpg.asc Cheers Antoine > > For RPM based distributions like CentOS and Fedora, try: > rpm --import https://xpra.org/gpg.asc > > Longer term, we would like to move to a different, stronger key, owned > by the project rather than individual. > But this will have to do for now. > > Cheers > Antoine > >> >> W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://winswitch.org xenial Release: The following signatures were invalid: KEYEXPIRED 1525416977 KEYEXPIRED 1525416977 KEYEXPIRED 1525416977 >> W: Failed to fetch http://winswitch.org/dists/xenial/Release.gpg The following signatures were invalid: KEYEXPIRED 1525416977 KEYEXPIRED 1525416977 KEYEXPIRED 1525416977 >> W: Some index files failed to download. They have been ignored, or old ones used instead. > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From ajs1 at cam.ac.uk Fri May 11 16:05:21 2018 From: ajs1 at cam.ac.uk (Anthony Stone) Date: Fri, 11 May 2018 16:05:21 +0100 Subject: [winswitch] xpra: unable to start sessions Message-ID: <1fe705ef-b93f-ab9d-c791-ae5718415186@cam.ac.uk> Hello Antoine, I'm having a lot of trouble trying to start xpra sessions over an ssh connection. The attached file gives some details. This has only started to be a problem recently, I think since xpra 2.3 was installed on the server. Is there an incompatibility between v2.2.6 and v2.3? Any suggestions welcome. Thanks, Anthony -------------- next part -------------- Unsuccesful attempts to start xpra sessions. Until recently I have been able to connect without any trouble using $ xpra start ssh/whirligig/100 --start=gnome-terminal & Recent attempts have been unsuccessful. After restarting both machines, I attempted twice to start an xpra session on whirligig (the server) from redwing (the client), using the command $ xpra start ssh/whirligig --start=gnome-terminal & This failed: Error: displayfd failed did not provide a display number using displayfd xpra initialization error: failed to identify the new server display! 2018-05-11 15:43:26,658 Error: failed to receive anything, not an xpra server? 2018-05-11 15:43:26,658 could also be the wrong protocol, username, password or port 2018-05-11 15:43:26,658 Connection lost If I used my usual command: $ xpra start ssh/whirligig/100 --start=gnome-terminal & This too failed: cannot find live server for display :100 2018-05-11 15:35:39,845 Error: failed to receive anything, not an xpra server? 2018-05-11 15:35:39,845 could also be the wrong protocol, username, password or port 2018-05-11 15:35:39,846 Connection lost In an ssh session on the server (whirligig) after the first two attempts, I found the following: $ xpra list Found the following xpra sessions: /run/user/1013/xpra: LIVE session at :2 LIVE session at :4 /home/ajs1/.xpra: LIVE session at :2 LIVE session at :4 /run/xpra: LIVE session at :2 LIVE session at :4 $ ps -ef | grep xpra ajs1 27502 1 0 May10 ? 00:00:02 /usr/bin/python /usr/bin/xpra start :100 --chdir=/home/ajs1 --video-decoders=all --packet-encoders=rencode, bencode, yaml --start=gnome-terminal --start-env=#avoid Ubuntu's global menu, which is a mess and cannot be forwarded: --start-env=UBUNTU_MENUPROXY= --start-env=QT_X11_NO_NATIVE_MENUBAR=1 --start-env=#fix for MainSoft's MainWin buggy window management: --start-env=MWNOCAPTURE=true --start-env=MWNO_RIT=true --start-env=MWWM=allwm --start-env=#force GTK3 applications to use X11 so we can intercept them: --start-env=GDK_BACKEND=x11 --env=XPRA_PROXY_START_UUID=07e25f9c7a9144c7b5ddb5c0b44c951c --video-encoders=all --bind=auto --encodings=h264,vp9,vp8,mpeg4,mpeg4+mp4,h264+mp4,vp8+webm,vp9+webm,png,webp,rgb,rgb24,rgb32,jpeg,h265,jpeg2000 --compressors=lz4, lzo, zlib --csc-modules=all --attach=no --start-via-proxy=no --daemon=yes --systemd-run=no --uid=1013 --gid=1013 ajs1 27597 27502 0 May10 ? 00:00:00 pulseaudio --start -n --daemonize=false --system=false --exit-idle-time=-1 --load=module-suspend-on-idle --load=module-null-sink sink_name="Xpra-Speaker" sink_properties=device.description="Xpra\ Speaker" --load=module-null-sink sink_name="Xpra-Microphone" sink_properties=device.description="Xpra\ Microphone" --load=module-native-protocol-unix socket=/run/user/1013/xpra/pulse-:100/pulse/native --load=module-dbus-protocol --load=module-x11-publish --log-level=2 --log-target=stderr root 29136 1 0 06:41 ? 00:00:00 /usr/bin/python /usr/bin/xpra proxy :14500 --daemon=no --bind-tcp=0.0.0.0:14500 --tcp-auth=sys --ssl-cert=/etc/xpra/ssl-cert.pem --ssl=on --bind=/run/xpra/system --auth=peercred --socket-dirs=/run/xpra --socket-permissions=666 --log-dir=/var/log --pidfile=/run/xpra.pid --debug= ajs1 30694 1 0 15:15 ? 00:00:00 /usr/bin/python /usr/bin/xpra start --start=gnome-terminal --encodings=h264,vp9,vp8,mpeg4,mpeg4+mp4,h264+mp4,vp8+webm,vp9+webm,png,webp,rgb,rgb24,rgb32,jpeg,h265,jpeg2000 --env=XPRA_PROXY_START_UUID=7d0122c63e634307a5bf09e0bb141fa6 --daemon=yes --systemd-run=no --displayfd=5 --start-via-proxy=no ajs1 30897 30694 0 15:16 ? 00:00:00 pulseaudio --start -n --daemonize=false --system=false --exit-idle-time=-1 --load=module-suspend-on-idle --load=module-null-sink sink_name="Xpra-Speaker" sink_properties=device.description="Xpra\ Speaker" --load=module-null-sink sink_name="Xpra-Microphone" sink_properties=device.description="Xpra\ Microphone" --load=module-native-protocol-unix socket=/run/user/1013/xpra/pulse-:2/pulse/native --load=module-dbus-protocol --load=module-x11-publish --log-level=2 --log-target=stderr ajs1 31634 1 0 15:16 ? 00:00:00 /usr/bin/python /usr/bin/xpra start --start=gnome-terminal --encodings=h264,vp9,vp8,mpeg4,mpeg4+mp4,h264+mp4,vp8+webm,vp9+webm,png,webp,rgb,rgb24,rgb32,jpeg,h265,jpeg2000 --env=XPRA_PROXY_START_UUID=8a3978040530489487867538e2cbe44e --daemon=yes --systemd-run=no --displayfd=5 --start-via-proxy=no ajs1 31678 31634 0 15:16 ? 00:00:00 pulseaudio --start -n --daemonize=false --system=false --exit-idle-time=-1 --load=module-suspend-on-idle --load=module-null-sink sink_name="Xpra-Speaker" sink_properties=device.description="Xpra\ Speaker" --load=module-null-sink sink_name="Xpra-Microphone" sink_properties=device.description="Xpra\ Microphone" --load=module-native-protocol-unix socket=/run/user/1013/xpra/pulse-:4/pulse/native --load=module-dbus-protocol --load=module-x11-publish --log-level=2 --log-target=stderr ajs1 32472 32392 0 15:23 pts/10 00:00:00 grep xpra but attempts to attach to these also failed. $ uname -a Linux whirligig 4.4.0-124-generic #148-Ubuntu SMP Wed May 2 13:00:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux $ xpra --version xpra v2.3-r19255 On the client (redwing): $ uname -a Linux Redwing 4.4.0-124-generic #148-Ubuntu SMP Wed May 2 13:00:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux $ xpra --version xpra v2.2.6-r18968 Trying to start a session directly on the server, as suggested in the tutorial: $ xpra start :100 --start-child=gnome-terminal & [1] 570 $ 2018-05-11 15:34:46,732 server failure: disconnected before the session could be established 2018-05-11 15:34:46,732 server requested disconnect: server error (failed to start a new session) Warning: cannot use the system proxy for 'start' subcommand, unknown general failure more information may be available in your system log Entering daemon mode; any further errors will be reported to: /run/user/1013/xpra/:100.log From antoine at nagafix.co.uk Wed May 23 13:30:36 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 23 May 2018 19:30:36 +0700 Subject: [winswitch] xpra: unable to start sessions In-Reply-To: <1fe705ef-b93f-ab9d-c791-ae5718415186@cam.ac.uk> References: <1fe705ef-b93f-ab9d-c791-ae5718415186@cam.ac.uk> Message-ID: > I'm having a lot of trouble trying to start xpra sessions over an ssh > connection. The attached file gives some details. This has only started > to be a problem recently, I think since xpra 2.3 was installed on the > server. Is there an incompatibility between v2.2.6 and v2.3? No, see: https://www.xpra.org/trac/wiki/Versions#Compatibility > $ xpra start ssh/whirligig/100 --start=gnome-terminal & I believe I saw it fail once, but I have been unable to reproduce the problem since. > but attempts to attach to these also failed. Please always include the full command lines used and their output. Your sample log also includes output from previously backgrounded commands, which makes things more difficult to follow. > Any suggestions welcome. I would try to get the basics working first, without using remote start: * directly on the "whirligig" server: xpra start :100 --start=xterm * verify the session is accessible: xpra info :100 * then connect from the client: xpra attach ssh://whirligig/100 If that works, then you can try the all-in-one: xpra start ssh://whirligig/100 --start=xterm And maybe you will need to add --start-via-proxy=no. It should fallback to not using the proxy if it cannot be reached. In your outout, I see: (..) xpra proxy :14500 --daemon=no --bind-tcp=0.0.0.0:14500 ... So you have a proxy server running. But I'm not sure how you got it running in the first place since there seems to be a systemd packaging bug in the Ubuntu 16.04 packages. Cheers Antoine From antoine at nagafix.co.uk Sun May 27 09:11:44 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 27 May 2018 15:11:44 +0700 Subject: [winswitch] gofundme for xpra server upgrade In-Reply-To: <244617ab-e19a-384a-0fcc-1669d5ac022c@nagafix.co.uk> References: <244617ab-e19a-384a-0fcc-1669d5ac022c@nagafix.co.uk> Message-ID: Hi, Many thanks for your support! The funding goal had been reached 2 months ago already, but we haven't done much progress since then on the hardware purchase front. The machine hosting xpra.org suffered a complete kernel lockup earlier this week, which served as a strong reminder that this single point of failure is a real danger to the project. Instead of hosting the buildbot in a data-center, we are likely to host it somewhere closer, which will facilitate maintenance, backups, upgrades, etc This will also reduce costs (the CPU doesn't need to fit in a 1U case) and risks: the xpra.org will only host the wiki and package repositories. Should this server get completely wiped out, it should be much quicker to restore things back to normal. This transition will take a while, so please bear with us. Cheers Antoine On 07/11/17 22:00, Antoine Martin wrote: > Hi, > > The xpra build system needs an upgrade, so if you can donate something > towards the new hardware please see: > https://www.gofundme.com/xpra-server-upgrade > > There is a temporary link on the xpra homepage near the bottom: > https://xpra.org/ > (there is a PGP signed link) > I am unable to sign this email with PGP because some email servers would > then bounce the post (thanks yahoo). > > On the subject of mailing list posts, some may have missed the messages > about the two critical updates from 2 weeks ago as the mail server had > been moved to a new hosting facility but the reverse-dns records had not > been updated yet. > Here they are again: > http://lists.devloop.org.uk/pipermail/shifter-users/2017-October/002027.html > http://lists.devloop.org.uk/pipermail/shifter-users/2017-October/002028.html > > Cheers > Antoine > From antoine at nagafix.co.uk Tue May 29 19:26:13 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 30 May 2018 01:26:13 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 2.3.1 Message-ID: <74b60fa7-f723-d763-fa9f-ebd39309a8a0@nagafix.co.uk> Hi, This update fixes a large number of issues in many different areas. None of the fixes are really critical, not even the "readonly mode bypass" which is more of an annoyance than a security issue, and not many are recent regressions, but all put together they do make this a rather large bug fix release. Updating is strongly recommended. Release notes: * fix CentOS / RHEL rpm dependencies for ldap authentication * fix spurious notifications warning * fix unsynced X11 context access to DPI (potential crash or warnings) * fix compilation warning in ffmpeg compatibility shim * fix filename extension check in launcher * fix h264 decoding in html5 client * fix menu stacking level in html5 client * fix focus issues with html5 client * fix socket error race condition during shutdown * fix scroll encoding errors on images with modified rowstride * fix desktop and shadow servers xinerama sizing issues * fix pixel encoding errors at low pixel depths * fix pixel-depth 8 wrongly rejected for start-desktop mode * fix colour encoding at pixel-depth 8 * fix systemd warnings and packaging on Ubuntu 16.04 * fix html5 client errors with audio debugging enabled * fix readonly mode bypass * fix client failure on servers without a valid desktop size * fix VNC connection handling of authentication * fix scary X11 desktop server warning with VNC clients * fix error in video debug logging * fix nvfbc errors during cleanup after initialization failures * fix client launcher not exiting on close * fix RFB clients causing sessions to be locked * fix rare deadlocks in exception handler * fix MacOS deprecation warnings * fix screen capture test script * fix CUDA DLL packaging * fix named-pipe errors with MS Windows Python3 and 64-bit builds * fix MinGW path detection issues * fix potential mmap leak with Python3 builds * fix screen update errors when XShm is disabled * silence GCC warnings when compiling NvFBC on MS Windows * increase default bandwidth congestion tolerance * remove duplicated DLLs from MS Windows Python3 builds * allow debugging via environment variables for all categories * don't prompt for the ssh password if we already have it * honour CFLAGS and LDFLAGS env vars * remove duplicated encoding from vpx encoder * add workaround for distributions shipping unpatched distutils * increase unit test failure timeout The source: https://xpra.org/src/ Downloads: http://xpra.org/trac/wiki/Download Cheers Antoine From matteo.ipri at arpm.co Tue May 29 23:27:58 2018 From: matteo.ipri at arpm.co (Matteo Ipri) Date: Wed, 30 May 2018 00:27:58 +0200 Subject: [winswitch] [xpra] HTML5 client: open link clicked on remote machine in local browser Message-ID: Hi all, First of all, thanks for this amazing tool! While doing some experiments with xpra, I found myself in the situation where a GUI app running in a remote virtual machine presents me a link to a website. If I click on that link, obviously, the default browser on the remote machine is launched and the website is opened. I would like to have those links to open on my local browser where I am running the xpra HTML5 client. Is there a way to do this? Just wondering, since I have almost no experience in this programming fields: maybe setting the xpra server on the remote machine as default browser and having the server sending the command to open such link to the HTML5 client... Thanks for your attention, Matteo Ipri From antoine at nagafix.co.uk Wed May 30 04:30:47 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 30 May 2018 10:30:47 +0700 Subject: [winswitch] [xpra] HTML5 client: open link clicked on remote machine in local browser In-Reply-To: References: Message-ID: <134308b9-fa79-064c-116c-23c26a207b7f@nagafix.co.uk> On 30/05/18 05:27, Matteo Ipri via shifter-users wrote: > Hi all, > First of all, thanks for this amazing tool! > > While doing some experiments with xpra, I found myself in the situation > where a GUI app running in a remote virtual machine presents me a link to a > website. If I click on that link, obviously, the default browser on the > remote machine is launched and the website is opened. > I would like to have those links to open on my local browser where I am > running the xpra HTML5 client. > Is there a way to do this? Yes, see: https://xpra.org/trac/ticket/1726#comment:2 Cheers Antoine > Just wondering, since I have almost no experience in this programming > fields: maybe setting the xpra server on the remote machine as default > browser and having the server sending the command to open such link to the > HTML5 client... > Thanks for your attention, > > Matteo Ipri > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From matteo.ipri at arpm.co Wed May 30 13:14:05 2018 From: matteo.ipri at arpm.co (Matteo Ipri) Date: Wed, 30 May 2018 14:14:05 +0200 Subject: [winswitch] [xpra] HTML5 client: open link clicked on remote machine in local browser In-Reply-To: <134308b9-fa79-064c-116c-23c26a207b7f@nagafix.co.uk> References: <134308b9-fa79-064c-116c-23c26a207b7f@nagafix.co.uk> Message-ID: On Wed, May 30, 2018 at 5:30 AM, Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > > On 30/05/18 05:27, Matteo Ipri via shifter-users wrote: > > Hi all, > > First of all, thanks for this amazing tool! > > > > While doing some experiments with xpra, I found myself in the situation > > where a GUI app running in a remote virtual machine presents me a link to a > > website. If I click on that link, obviously, the default browser on the > > remote machine is launched and the website is opened. > > I would like to have those links to open on my local browser where I am > > running the xpra HTML5 client. > > Is there a way to do this? > Yes, see: > https://xpra.org/trac/ticket/1726#comment:2 > > Cheers > Antoine Thanks! I tried it but I can not make it work. I typed $ xdg-open https://www.google.com in a xterm window running on the remote machine, accessed via the HTML5 xpra client running in Chromium on my local PC. Apparently nothing happened, but looking at the logs on the remote machine I found this 2018-05-30 11:59:48,465 New unix-domain connection received on /home/jovyan/.xpra/b58813db02a7-0 2018-05-30 11:59:48,466 Warning: remote end does not accept URLs How can I add the open-url=yes option to the HTML5 client? I started xpra with the following command $ xpra start \ --daemon=no \ --bind-tcp=0.0.0.0:8888 \ --html=on \ --ssl=off \ --bandwidth-limit=500kbps \ --bell=no \ --pulseaudio=no \ --webcam=no \ --mdns=no \ --system-tray=no \ --clipboard-direction=both \ --file-transfer=yes \ --forward-xdg-open=yes \ --start=xterm \ --xvfb="Xvfb -dpi 96 -noreset -nolisten tcp +extension GLX +extension RANDR +extension RENDER +extension Composite -screen 0 1600x900x24+32" I run a reverse proxy with TLS termination in front of xpra. I run xpra v2.3-r19255 since I can not install the latest version. Whenever I try to do an "apt-get update" I get: W: GPG error: http://winswitch.org artful Release: The following signatures were invalid: BADSIG 18ADB31CF18AD6BB Antoine Martin E: The repository 'http://winswitch.org artful Release' is not signed. W: GPG error: https://xpra.org artful Release: The following signatures were invalid: BADSIG 18ADB31CF18AD6BB Antoine Martin E: The repository 'https://xpra.org artful Release' is not signed. I tried both repositories alone, together, with http, with https... I also tried adding the updated keys using all solutions provided here: https://winswitch.org/trac/ticket/304 and here: http://lists.devloop.org.uk/pipermail/shifter-users/2018-May/002122.html Any suggestion? Thank you very much again. From antoine at nagafix.co.uk Wed May 30 17:10:57 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 30 May 2018 23:10:57 +0700 Subject: [winswitch] [xpra] HTML5 client: open link clicked on remote machine in local browser In-Reply-To: References: <134308b9-fa79-064c-116c-23c26a207b7f@nagafix.co.uk> Message-ID: >> > I would like to have those links to open on my local browser where I am >> > running the xpra HTML5 client. >> > Is there a way to do this? >> Yes, see: >> https://xpra.org/trac/ticket/1726#comment:2 > > Thanks! I tried it but I can not make it work. > > I typed > > $ xdg-open https://www.google.com > > in a xterm window running on the remote machine, accessed via the HTML5 > xpra client running in Chromium on my local PC. > Apparently nothing happened, but looking at the logs on the remote > machine I found this > > 2018-05-30 11:59:48,465 New unix-domain connection received on > /home/jovyan/.xpra/b58813db02a7-0 > 2018-05-30 11:59:48,466 Warning: remote end does not accept URLs > > How can I add the open-url=yes option to the HTML5 client? Sorry, I completely missed the part where you had said that you wanted to use the HTML5 client for this. This feature had only been implemented in the python client until now. For the HTML5 client, please try: https://xpra.org/trac/ticket/1862#comment:2 And add comments there. > I started xpra with the following command > $ xpra start \ > --daemon=no \ > --bind-tcp=0.0.0.0:8888 \ > --html=on \ > --ssl=off \ > --bandwidth-limit=500kbps \ > --bell=no \ > --pulseaudio=no \ > --webcam=no \ > --mdns=no \ > --system-tray=no \ > --clipboard-direction=both \ > --file-transfer=yes \ > --forward-xdg-open=yes \ > --start=xterm \ > --xvfb="Xvfb -dpi 96 -noreset -nolisten tcp +extension GLX +extension > RANDR +extension RENDER +extension Composite -screen 0 1600x900x24+32" If you are using this switch to use a specific initial resolution, there are easier ways, see: http://xpra.org/trac/ticket/1132#comment:1 > I run a reverse proxy with TLS termination in front of xpra. I hope the proxy is fast. The websocket connections degrade pretty quickly when any measurable latency is added. > I run xpra v2.3-r19255 since I can not install the latest version. > Whenever I try to do an "apt-get update" I get: > > W: GPG error: http://winswitch.org artful Release: The following > signatures were invalid: BADSIG 18ADB31CF18AD6BB Antoine Martin > > > E: The repository 'http://winswitch.org artful Release' is not signed. > W: GPG error: https://xpra.org artful Release: The following signatures > were invalid: BADSIG 18ADB31CF18AD6BB Antoine Martin > > > E: The repository 'https://xpra.org artful Release' is not signed. > > I tried both repositories alone, together, with http, with https... > I also tried adding the updated keys using all solutions provided here: > https://winswitch.org/trac/ticket/304 > and here: > http://lists.devloop.org.uk/pipermail/shifter-users/2018-May/002122.html > > Any suggestion? Oops sorry. I overwrote the GPG key with the old one by mistake, and half the repositories still had the old Release file.. So much fail. Try again and things should just work. Cheers, Antoine > > Thank you very much again. From matteo.ipri at arpm.co Wed May 30 22:34:24 2018 From: matteo.ipri at arpm.co (Matteo Ipri) Date: Wed, 30 May 2018 23:34:24 +0200 Subject: [winswitch] [xpra] HTML5 client: open link clicked on remote machine in local browser In-Reply-To: References: <134308b9-fa79-064c-116c-23c26a207b7f@nagafix.co.uk> Message-ID: PS: maybe some of my replies/questions are out of topic. Where is the best place to make such discussions? On Wed, May 30, 2018 at 6:10 PM, Antoine Martin wrote: > > How can I add the open-url=yes option to the HTML5 client? > Sorry, I completely missed the part where you had said that you wanted > to use the HTML5 client for this. > This feature had only been implemented in the python client until now. > For the HTML5 client, please try: > https://xpra.org/trac/ticket/1862#comment:2 > And add comments there. Thank you very much. I am reinstalling xpra now enabling the beta repository, too. I'll test and I will comment below the ticket. If I should install from source, I will try it, too. > > I started xpra with the following command > > $ xpra start \ > > --daemon=no \ > > --bind-tcp=0.0.0.0:8888 \ > > --html=on \ > > --ssl=off \ > > --bandwidth-limit=500kbps \ > > --bell=no \ > > --pulseaudio=no \ > > --webcam=no \ > > --mdns=no \ > > --system-tray=no \ > > --clipboard-direction=both \ > > --file-transfer=yes \ > > --forward-xdg-open=yes \ > > --start=xterm \ > > --xvfb="Xvfb -dpi 96 -noreset -nolisten tcp +extension GLX +extension > > RANDR +extension RENDER +extension Composite -screen 0 1600x900x24+32" > If you are using this switch to use a specific initial resolution, there > are easier ways, see: > http://xpra.org/trac/ticket/1132#comment:1 Thanks for the tip! Yes, I need to specify the initial resolution, otherwise windows of launched apps are waaaay too big. I'll try the solution with environment variable. (XPRA_DEFAULT_VFB_RESOLUTION=1600x900) I also used that switch because I understood from the wiki that I have to use that switch to benefit of the pros of Xdummy, but maybe I got it wrong... I was trying to get the best performance running xpra on Amazon Web Services EC2 instance without dedicated GPU. > > I run a reverse proxy with TLS termination in front of xpra. > I hope the proxy is fast. The websocket connections degrade pretty > quickly when any measurable latency is added. Yes, I discovered this myself. I am investigating ways to change my virtual network. Thanks for the advice anyway! :-) > > Any suggestion? > Oops sorry. I overwrote the GPG key with the old one by mistake, and > half the repositories still had the old Release file.. So much fail. > Try again and things should just work. Yes, now it works on my PC running Arch Linux, too. Thank you very much for the quick fix! > Cheers, > Antoine Thank you very very much again! From antoine at nagafix.co.uk Thu May 31 12:26:23 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 31 May 2018 18:26:23 +0700 Subject: [winswitch] [xpra] HTML5 client: open link clicked on remote machine in local browser In-Reply-To: References: <134308b9-fa79-064c-116c-23c26a207b7f@nagafix.co.uk> Message-ID: <93d70f76-58fe-db05-b3bc-c2ae75c69bfc@nagafix.co.uk> On 31/05/18 04:34, Matteo Ipri wrote: > PS: maybe some of my replies/questions are out of topic. Where is the > best place to make such discussions? They're all related to xpra so this is the right place. (snip) >> > I started xpra with the following command >> > $ xpra start \ >> > --daemon=no \ >> > --bind-tcp=0.0.0.0:8888 \ >> > --html=on \ >> > --ssl=off \ >> > --bandwidth-limit=500kbps \ >> > --bell=no \ >> > --pulseaudio=no \ >> > --webcam=no \ >> > --mdns=no \ >> > --system-tray=no \ >> > --clipboard-direction=both \ >> > --file-transfer=yes \ >> > --forward-xdg-open=yes \ >> > --start=xterm \ >> > --xvfb="Xvfb -dpi 96 -noreset -nolisten tcp +extension GLX +extension >> > RANDR +extension RENDER +extension Composite -screen 0 1600x900x24+32" >> If you are using this switch to use a specific initial resolution, there >> are easier ways, see: >> http://xpra.org/trac/ticket/1132#comment:1 > > Thanks for the tip! > Yes, I need to specify the initial resolution, otherwise windows of > launched apps are waaaay too big. The vfb size will be adjusted when the client connects. You can wait until that point to start the apps, then they will use the correct vfb size. See --start-after-connect=yourapp > I'll try the solution with environment variable. > (XPRA_DEFAULT_VFB_RESOLUTION=1600x900) > I also used that switch because I understood from the wiki that I have > to use that switch to benefit of the pros of Xdummy, but maybe I got it > wrong... Yes you did: you're not using Xdummy if you specify --xvfb=Xvfb ... You will be using Xvfb! The default Ubuntu 17.10 installation should be using Xdummy already out of the box, without needing to modify anything. Cheers, Antoine > I was trying to get the best performance running xpra on Amazon Web > Services EC2 instance without dedicated GPU. > >> > I run a reverse proxy with TLS termination in front of xpra. >> I hope the proxy is fast. The websocket connections degrade pretty >> quickly when any measurable latency is added. > > Yes, I discovered this myself. I am investigating ways to change my > virtual network. Thanks for the advice anyway! :-) > >> > Any suggestion? >> Oops sorry. I overwrote the GPG key with the old one by mistake, and >> half the repositories still had the old Release file.. So much fail. >> Try again and things should just work. > > Yes, now it works on my PC running Arch Linux, too. > Thank you very much for the quick fix! > >> Cheers, >> Antoine > > Thank you very very much again! >