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
On 5/26/21 8:44 AM, Terry Barnaby via shifter-users wrote:
Are you sure that hardware based H264/HEVC encoder/decoder usage license is not
covered by the manufacturer/supplier of the hardware codecs ?
Sorry, I was reading your message as "does my hardware allow me to freely use
codecs" so
On 5/26/21 8:17 AM, Terry Barnaby via shifter-users wrote:
As a slight aside to this. My "dnf install xpra" from the Fedora33 repositories +
rpmfusion + fedora-cisco-openh264 repositories does in fact have h264 and h265
support. So I presume the Fedora33 standard ffmpeg is being extended to
On 5/26/21 8:24 AM, Antoine Martin via shifter-users wrote:
Disabling the
codecs at build time is not enough if we want to be pedantic.
Let's digress a bit more then: why not?
As someone who has worked with patented software and seen what Fedora Legal (a.k.a.
Red Hat Legal) requires for
On 5/26/21 7:43 AM, Antoine Martin via shifter-users wrote:
For the sake of completeness, this is not 100% accurate: ffmpeg can be
built under the GPL license and without the nonfree codecs.
xpra's ffmpeg encoder which we are discussing in this thread can be
enabled without those.
Whether that's
On 5/26/21 2:52 AM, Terry Barnaby via shifter-users wrote:
Is there any reason why the Fedora system packages should be so different ? I can
see they wouldn't be so up-to-date but I would have thought the Fedora maintainer
would take the upstream as close as possible. It would be a better user
On 2/23/21 9:36 AM, Antoine Martin via shifter-users wrote:
You may want to run your proxy with "-d network" or even "-d all" and
see if anything comes up.
I'll try.
Are you certain that this problems occurs after a certain amount of time
rather than an amount of connections?
It could be a
Hi,
After about a week the Xpra Proxy stops responding to connection requests. The last
time was 6 days. This issue has occurred multiple times. Trying to connect a web
browser to port 14500 results in a time out. Trying to use openssl s_client
:14500 results in a timeout. The port on the
On 1/4/21 11:34 PM, Antoine Martin via shifter-users wrote:
Thanks for the report, this regression has been fixed:
https://xpra.org/trac/changeset/28306
You can just run `yum update` to get updated packages with this fix.
Thank you for the quick fix. That fixed the issue and it is now running.
On 12/31/20 7:09 AM, Antoine Martin via shifter-users wrote:
Hi,
This release fixes a large number of bugs but none of them are critical,
so there is no urgency to update if you were not affected.
That said, quite a few of the issues which have been fixed greatly
enhance the user experience.
On 12/8/20 11:56 PM, Antoine Martin via shifter-users wrote:
I believe that the "client connection lost" messages shown here can only
come from a proxy server. Are you running via a proxy server?
And if so, have you tried without? The proxy server log may well have
the details you need (run "-d
On 11/30/20 11:29 PM, Antoine Martin via shifter-users wrote:
Does this also occur if you connect a regular python client to the same
session?
I have not tried it yet, so I installed the 4.0.5 Windows client. After a few
minutes the thick client also disconnects. In this instance I was using
Hi,
I have had an issue with Xpra dropping and reconnecting sessions while using
applications inside the web browser client. I have experienced this for several
months and logs do not show a reason. Currently I'm using Xpra 4.0.5.
I can leave a session open for hours without reconnect
On 11/24/20 8:56 AM, Antoine Martin via shifter-users wrote:
Try replacing "--tcp-auth=$TCP_AUTH" with "--wss-auth=sys"
We could make this the default too I guess - though it may be confusing
to see an auth option defined for a socket type that isn't used by default.
Setting wss-auth allows
On 11/24/20 8:11 AM, Antoine Martin via shifter-users wrote:
Version 4.0.5 is the latest stable release.
Beta builds can be found here:
https://xpra.org/beta/
Once the fix is verified, please comment in that ticket and I will
backport this change to the stable versions.
Duh. :(
I tested the
On 10/23/20 4:05 AM, Antoine Martin via shifter-users wrote:
Right.
Based on your request, I have just added a simple way to make this work:
https://www.xpra.org/trac/ticket/2914
You can grab the latest centos8 beta builds which have this change
already included.
I tested this today using the
On 10/23/20 4:05 AM, Antoine Martin via shifter-users wrote:
Right.
Based on your request, I have just added a simple way to make this work:
https://www.xpra.org/trac/ticket/2914
You can grab the latest centos8 beta builds which have this change
already included.
Great! Thank you!
Hi,
I'm using the Xpra 4.x packages from the official Xpra repo on RHEL 8. I'm also
using the provided systemd socket and service. This enables the listening socket at
port 14500 to respond to plain TCP and SSL requests. I would like to disable support
for plain TCP, but I do not see a
On 3/12/20 10:34 AM, Antoine Martin wrote:
So, you're using the connect.html form, but with what options?
They are not terminating with the HTML5 client. The checkboxes for
"Terminate server..." are grey, but checked.
(maybe they should not be checked)
The "terminate .." options are only
On 3/12/20 9:32 AM, Antoine Martin wrote:
One final issue: Sessions are not closing when the user disconnects.
I am using 'xpra proxy --bind-tcp=0.0.0.0:port --html=on --tcp-auth=pam
--exit-with-client=yes --terminate-children=yes
"exit-with-client" is not honoured by the proxy server,
On 3/11/20 11:02 PM, Antoine Martin wrote:
That's odd, the module is present with a default 64-bit CentOS 7
installation of python2-xpra-server-3.0.6-0.r25195:
ls -la /usr/lib64/python2.7/site-packages/xpra/server/pam.so
You can test that it imports successfully with:
python -c "from
On 3/10/20 11:05 PM, Antoine Martin wrote:
The xpra proxy can do pretty much the same thing. ie as root:
xpra proxy --bind-tcp=0.0.0.0:1 --tcp-auth=sys
Then you can authenticate as individual unix users on that proxy and
request a new sessions.
Thanks! This is what I was looking for. It's
On 3/9/20 7:06 AM, Antoine Martin via shifter-users wrote:
Do you want them to be able to start new sessions or only connect to
existing ones?
They need to start their own sessions. Currently a single Xpra session starts under
a single user so things like gnome-terminal or IDEs start in the
Hi,
Is there an existing product or workflow that someone has created to handle multiple
users logging in through the HTML5 interface? I would like to have each user logging
in to their own Xpra instance.
The only way I see to do it now is start up Xpra for each user, but this seems
24 matches
Mail list logo
