On 11/03/2023 23:11, Mario Marietto wrote:
----> I don't think that the host OS matters much.
I think it's because of the package management. Ubuntu uses as default
one (old) version,debian another one even older and so on. And this
explains why I'm using an old version full of bugs.
-----> 3.1 is not a supported version, it is well out of date.
this is the version used by ubuntu 22.04 that I've used. I'm very sad
that it uses such an old version. And I upgrade the packages often. So
what should I do to use the newest version ? recompile it from source on
the host and guest os ?
https://github.com/Xpra-org/xpra/wiki/Download#-for-debian-based-distributions
------> A common workaround for this is to pre-start xpra or even just
the virtual framebuffer.
Can you point me to the webpage where it is explained how to do that ?
thanks.
The simplest form:
`Xvfb :100`
Will start a vfb on display :100
Then you can start xpra using this display later:
xpra start :100
------> If it is the application(s), I would first try with something
very fast
and reliable like an `xterm`.
Can you point me to the webpage where it is explained how to do that,too
? thanks.
`xpra start --start=xterm`
Cheers
Antoine
On Fri, Mar 10, 2023 at 11:25 AM Antoine Martin via shifter-users
<shifter-users@lists.devloop.org.uk
<mailto:shifter-users@lists.devloop.org.uk>> wrote:
Posts unrelated to the release announcements should be using a separate
thread.
On 08/03/2023 00:48, Mario Marietto via shifter-users wrote:
> Hello.
>
> I would like to integrate Ubuntu,Fedora,Arch or maybe some other
distro
> into one single,homogeneous and flexible operating (OS) context.
Go with Fedora.
Ubuntu and Debian have too many unfixable problems and Arch is not an
officially supported distro.
> I would
> like to use Ubuntu (22.04) as the host OS
I don't think that the host OS matters much.
> and the rest of the OSes
> (Fedora,Arch) will be virtualized within different virtual
machines (I
> don't want to use containers,I know that they are a better
choice,but I
> want to understand if a virtual machine is good anyway when it is
very well
> configured). The idea is also to use qemu + kvm with the
nographic and no
> vga options enabled,without virt-manager or boxes. I don't want
to open and
> close the virtual machine graphical interface every time I want
to run an
> application.
That makes sense.
> I find it much more comfortable if I can run every application
> and command within one only terminal by premising,for example,a
letter
> indicating to which distribution the command or application
belongs to. Or
> I could tell xpra to open the fedora or the arch linux terminal.
For sure
> it will be much faster to configure,but it has less scenic effect.
>
> So. I've installed Fedora 37 on a qemu-kvm VM and I've installed
xpra on
> Ubuntu and on Fedora. As you can see below,when I invoke firefox
from the
> Fedora VM (that has IP = 192.168.122.156),it starts correctly :
>
>
> ziomario@Z390-AORUS-PRO-DEST:~$ xpra start
ssh://marietto@192.168.122.156 <mailto:marietto@192.168.122.156>
> --start=firefox
>
> Warning: vendor 'Intel' is greylisted,
> you may want to turn off OpenGL if you encounter bugs
> 2023-03-07 18:26:52,384 Xpra GTK3 X11 client version 3.1 64-bit
3.1 is not a supported version, it is well out of date.
> 2023-03-07 18:26:52,454 running on Linux Ubuntu 22.04 jammy
> 2023-03-07 18:26:52,454 window manager is 'Xfwm4'
> 2023-03-07 18:26:52,465 opencv not found:
> 2023-03-07 18:26:52,465 No module named 'cv2'
> 2023-03-07 18:26:52,465 webcam forwarding is disabled
> 2023-03-07 18:26:52,677 GStreamer version 1.20.3 for Python
3.10.6 64-bit
> 2023-03-07 18:26:52,733 No OpenGL_accelerate module loaded: No
module named
> 'OpenGL_accele
> rate'
> 2023-03-07 18:26:52,881 Warning: vendor 'Intel' is greylisted,
> 2023-03-07 18:26:52,881 you may want to turn off OpenGL if you
encounter
> bugs
> 2023-03-07 18:26:52,979 OpenGL enabled with Mesa Intel(R) UHD
Graphics 630
> (CFL GT2)
> 2023-03-07 18:26:52,989 Connected (version 2.0, client OpenSSH_8.8)
> 2023-03-07 18:26:53,129 loaded RSA private key from
> '/home/ziomario/.ssh/id_rsa'
> 2023-03-07 18:26:53,141 Authentication (publickey) successful!
> 2023-03-07 18:26:53,407 keyboard settings: rules=evdev, model=pc105,
> layout=it
> 2023-03-07 18:26:53,585 desktop size is 3840x1080 with 1 screen:
> 2023-03-07 18:26:53,585 :0.0 (1016x286 mm - DPI: 96x95) workarea:
> 3840x1044
> 2023-03-07 18:26:53,585 AOC HDMI-1 1920x1080 (598x336 mm -
DPI: 81x81)
> 2023-03-07 18:26:53,585 PHL HDMI-2-0 1920x1080 at 1920x0
(598x336 mm -
> DPI: 81x81)
> 2023-03-07 18:27:03,895 unknown packet type: setting-change
> 2023-03-07 18:27:08,033 enabled remote logging
> 2023-03-07 18:27:08,033 Xpra X11 seamless server version 4.4 32-bit
4.4 is also well out of date.
> 2023-03-07 18:27:08,034 running on unknown
> 2023-03-07 18:27:08,220 server does not support xi input devices
> 2023-03-07 18:27:08,220 server uses: xtest
>
>
> The problem is that firefox takes 6 or more seconds to appear.
And it's not
> the only one that's so slow. Every application that I try to run
is very
> slow.
It's not clear to me if it is Firefox that is too slow to start or the
xpra session.
You can see what the xpra server does on startup in the server log file.
A lot of work as gone into making the server faster to start:
https://github.com/Xpra-org/xpra/issues/2341
<https://github.com/Xpra-org/xpra/issues/2341>
But the time it takes to start the virtual framebuffer is beyond our
control and this can take many seconds, especially with older versions.
A common workaround for this is to pre-start xpra or even just the
virtual framebuffer.
If it is the application(s), I would first try with something very fast
and reliable like an `xterm`.
Slow application startup is usually caused by dbus timeouts or missing
daemons.
ie: not having `gnome-keyring-daemon` slows down `gnome-terminal`:
https://github.com/Xpra-org/xpra/issues/3109
<https://github.com/Xpra-org/xpra/issues/3109>
> You can imagine that is not good if I want to integrate
> Ubuntu,Fedora,Arch or maybe some other distro into one
single,homogeneous
> and flexible operating (OS) context. When I want to run an
application, I
> expect it to start as fast as it would if it were installed
locally. Is
> that goal achievable ?
Yes.
Just be aware that it is preferable to use a single xpra session per
application, which makes it harder to pre-launch xpra sessions in
advance. Advanced setups use pre-launched session pools for that.
Cheers,
Antoine
> Il giorno mar 7 mar 2023 alle ore 10:55 Antoine Martin via
shifter-users <
> shifter-users@lists.devloop.org.uk
<mailto:shifter-users@lists.devloop.org.uk>> ha scritto:
>
>> Hi,
>>
>> Hopefully, this will be the final release from the 3.1.x LTS+1
branch
>> which will be replaced by a new v5 LTS branch before too long.
>> This release includes all the fixes that had accumulated over
the past 9
>> months.
>>
>> Unlike previous releases from this branch, support for all platforms
>> should be in good shape and there are packages for almost every
>> supported distribution - even those that only support Python 3,
which is
>> quickly becoming the norm.
>> There are also builds for many of the RHEL 8.x and 9.x clones,
and some
>> arm64 builds too - though those may take a few more days to build.
>>
>> The most serious fixes affected focus issues and a clipboard
regression
>> on MS Windows which was introduced in 3.1.3.
>> There are also many new workarounds for new, broken or misconfigured
>> system libraries and environments.
>>
>> As always, the MS Windows and MacOS binary bundles have the most
library
>> updates, with new OpenSSL 3, GStreamer, ffmpeg, etc.
>> Anyone still stuck on this LTS branch should upgrade.
>>
>> The more detailed release notes can be found here:
>> https://github.com/Xpra-org/xpra/releases/tag/v3.1.4
<https://github.com/Xpra-org/xpra/releases/tag/v3.1.4>
>>
>> Downloads:
>> https://github.com/Xpra-org/xpra/wiki/Download
<https://github.com/Xpra-org/xpra/wiki/Download>
>>
>> Cheers,
>> Antoine
>> _______________________________________________
>> shifter-users mailing list
>> shifter-users@lists.devloop.org.uk
<mailto:shifter-users@lists.devloop.org.uk>
>> https://lists.devloop.org.uk/mailman/listinfo/shifter-users
<https://lists.devloop.org.uk/mailman/listinfo/shifter-users>
>>
>
>
_______________________________________________
shifter-users mailing list
shifter-users@lists.devloop.org.uk
<mailto:shifter-users@lists.devloop.org.uk>
https://lists.devloop.org.uk/mailman/listinfo/shifter-users
<https://lists.devloop.org.uk/mailman/listinfo/shifter-users>
--
Mario.
_______________________________________________
shifter-users mailing list
shifter-users@lists.devloop.org.uk
https://lists.devloop.org.uk/mailman/listinfo/shifter-users
