Usage of xpra on windows

Coming from #110, I tried the following on MSYS2:
First, start a GUI app on top of a xpra server inside a container and bind it to a TCP port:
# ./x11docker -it --user=root -- -p <IP_ADDRESS>:8086:8080 -- ghdl/ext:gtk-ide bash
...
root@f7909b85975c:~# apt install -y xpra
...
root@f7909b85975c:~# pip3 install websockify
...
root@f7909b85975c:~# xpra start --start=gtkwave --bind-tcp=<IP_ADDRESS>:8080

Warning: running as root
root@f7909b85975c:~# Entering daemon mode; any further errors will be reported to:
  /tmp/XDG_RUNTIME_DIR/xpra/S2138.log
Actual display used: :0
Actual log file name is now: /tmp/XDG_RUNTIME_DIR/xpra/:0.log

Then, download an xpra client for windows (https://xpra.org/dists/windows/Xpra-Client-x86_64_2.4.3-r21365.zip). Either by opening Xpra-Launcher.exe and clicking Connect or opening Xpra.exe directly, I can connet to root@localhost:8086 (without passowrd). The GUI shows as a new window in my desktop. Cool!
This is the log of the server:
root@f7909b85975c:/tmp# cat  /tmp/XDG_RUNTIME_DIR/xpra/:0.log
2019-01-31 17:48:19,252 cannot access python uinput module:
2019-01-31 17:48:19,252  No module named uinput

X.Org X Server 1.20.3
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
Current Operating System: Linux f7909b85975c 4.9.125-linuxkit #1 SMP Fri Sep 7 08:20:28 UTC 2018 x86_64
Kernel command line: BOOT_IMAGE=/boot/kernel console=ttyS0 page_poison=1 vsyscall=emulate panic=1 root=/dev/sr0 text
Build Date: 25 October 2018  06:15:23PM
xorg-server 2:1.20.3-1 (https://www.debian.org/support)
Current version of pixman: 0.36.0
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(++) Log file: "/tmp/XDG_RUNTIME_DIR/xpra/Xorg.S2138.log", Time: Thu Jan 31 17:48:20 2019
(++) Using config file: "/etc/xpra/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
2019-01-31 17:48:23,959 Warning: failed to create socket directory '/run/user/0/xpra'
2019-01-31 17:48:23,959  [Errno 2] No such file or directory: '/run/user/0/xpra'
2019-01-31 17:48:23,959 Warning: cannot create socket '/run/user/0/xpra/f7909b85975c-0':
2019-01-31 17:48:23,959  [Errno 2] No such file or directory
2019-01-31 17:48:23,960  /run/user does not exist
2019-01-31 17:48:23,960 created unix domain socket: /run/xpra/f7909b85975c-0
/bin/sh: 1: dbus-launch: not found
dbus-launch failed to start using command 'dbus-launch --close-stderr':

 exit code is 127

2019-01-31 17:48:24,963 Warning: menu forwarding is disabled:
2019-01-31 17:48:24,963  cannot load dbus helper: org.freedesktop.DBus.Error.Spawn.ExecFailed: /usr/bin/dbus-launch terminated abnorma
lly without any error message
2019-01-31 17:48:24,993 pointer device emulation using XTest
2019-01-31 17:48:25,514  OpenGL is supported on this display
2019-01-31 17:48:25,555 html server unavailable, cannot find websockify module
2019-01-31 17:48:25,567 dbus server error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/xpra/server/dbus/dbus_common.py", line 12, in dbus_exception_wrap
    v = fn()
  File "/usr/lib/python2.7/dist-packages/xpra/x11/server.py", line 1302, in make_dbus_server
    return X11_DBUS_Server(self, os.environ.get("DISPLAY", "").lstrip(":"))
  File "/usr/lib/python2.7/dist-packages/xpra/server/dbus/dbus_server.py", line 38, in __init__
    bus = init_session_bus()
  File "/usr/lib/python2.7/dist-packages/xpra/dbus/common.py", line 22, in init_session_bus
    _session_bus = dbus.SessionBus(private=private)
  File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 211, in __new__
    mainloop=mainloop)
  File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 100, in __new__
    bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
  File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 122, in __new__
    bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: /usr/bin/dbus-launch terminated abnormally without any error message
2019-01-31 17:48:25,568 Error setting up server dbus instance:
2019-01-31 17:48:25,568   org.freedesktop.DBus.Error.Spawn.ExecFailed
2019-01-31 17:48:25,568   /usr/bin/dbus-launch terminated abnormally without any error message
2019-01-31 17:48:25,571 Warning: failed to load or register our dbus notifications forwarder:
2019-01-31 17:48:25,571  org.freedesktop.DBus.Error.Spawn.ExecFailed: /usr/bin/dbus-launch terminated abnormally without any error mes
sage
2019-01-31 17:48:25,571  if you do not have a dedicated dbus session for this xpra instance,
2019-01-31 17:48:25,571  use the 'notifications=no' option
2019-01-31 17:48:25,590 Warning: webcam forwarding is disabled
2019-01-31 17:48:25,590  the virtual video directory '/sys/devices/virtual/video4linux' was not found
2019-01-31 17:48:25,590  make sure that the 'v4l2loopback' kernel module is installed and loaded
2019-01-31 17:48:25,590 found 0 virtual video devices for webcam forwarding
2019-01-31 17:48:25,596 Warning: cannot load dbus helper:
2019-01-31 17:48:25,596  org.freedesktop.DBus.Error.Spawn.ExecFailed: /usr/bin/dbus-launch terminated abnormally without any error mes
sage
2019-01-31 17:48:25,670 Warning: failed to load the mdns publisher
2019-01-31 17:48:25,670  No module named avahi
2019-01-31 17:48:25,670  either fix your installation or use the 'mdns=no' option
2019-01-31 17:48:25,670 xpra X11 version 2.4.3-r21350M 64-bit
2019-01-31 17:48:25,670  uid=0 (root), gid=0 (root)
2019-01-31 17:48:25,670  running with pid 2142 on Linux debian buster/sid
2019-01-31 17:48:25,671  connected to X11 display :0 with 24 bit colors
2019-01-31 17:48:25,776 xpra is ready.
2019-01-31 17:48:26,306 7.8GB of system memory

GTKWave Analyzer v3.3.99 (w)1999-2019 BSI

GTKWAVE | Use the -h, --help command line flags to display help.
2019-01-31 17:57:12,378 New tcp connection received from <IP_ADDRESS>:33068 on <IP_ADDRESS>:8080
2019-01-31 17:57:12,381 Handshake complete; enabling connection
2019-01-31 17:57:12,391 dbus server error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/xpra/server/dbus/dbus_common.py", line 12, in dbus_exception_wrap
    v = fn()
  File "/usr/lib/python2.7/dist-packages/xpra/server/source/dbus_mixin.py", line 29, in make_dbus_server
    return DBUS_Source(self, os.environ.get("DISPLAY", "").lstrip(":"))
  File "/usr/lib/python2.7/dist-packages/xpra/server/dbus/dbus_source.py", line 36, in __init__
    session_bus = init_session_bus()
  File "/usr/lib/python2.7/dist-packages/xpra/dbus/common.py", line 22, in init_session_bus
    _session_bus = dbus.SessionBus(private=private)
  File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 211, in __new__
    mainloop=mainloop)
  File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 100, in __new__
    bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
  File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 122, in __new__
    bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: /usr/bin/dbus-launch terminated abnormally without any error message
2019-01-31 17:57:12,392 Error setting up client dbus instance:
2019-01-31 17:57:12,392   org.freedesktop.DBus.Error.Spawn.ExecFailed
2019-01-31 17:57:12,392   /usr/bin/dbus-launch terminated abnormally without any error message
2019-01-31 17:57:12,392  automatic picture encoding enabled, also available:
2019-01-31 17:57:12,392   h264, vp9, vp8, png, png/P, png/L, webp, rgb24, rgb32, jpeg, h265, mpeg1, mpeg2
2019-01-31 17:57:12,393 Warning: the python netifaces package is missing
2019-01-31 17:57:12,394 Python/Gtk2 Microsoft Windows 10 aero client version 2.4.3-r21365 64-bit
2019-01-31 17:57:12,394  connected from 'DESKTOP-E1ER43H' as 'root' - 'eine'
2019-01-31 17:57:12,468 setting key repeat rate from client: 500ms delay / 33ms interval
2019-01-31 17:57:12,469 setting keyboard layout to 'gb'
2019-01-31 17:57:12,492  client root window size is 3840x1080 with 1 display:
2019-01-31 17:57:12,492   Default (1016x285 mm - DPI: 96x96) workarea: 3840x1040
2019-01-31 17:57:12,492     DISPLAY1 1920x1080 (480x270 mm - DPI: 101x101) workarea: 1920x1040
2019-01-31 17:57:12,492     DISPLAY2 1920x1080 at 1920x0 (480x270 mm - DPI: 101x101) workarea: 1920x1040
2019-01-31 17:57:12,525 server virtual display now set to 3840x1080
2019-01-31 17:57:12,543 client @01.422 Xpra X11 server version 2.4.3-r21350 64-bit
2019-01-31 17:57:12,544 client @01.437  running on Linux debian buster/sid
2019-01-31 17:57:12,554 DPI set to 45 x 25 (wanted 96 x 96)
2019-01-31 17:57:12,554  you may experience scaling problems, such as huge or small fonts, etc
2019-01-31 17:57:12,555  to fix this issue, try the dpi switch, or use a patched Xorg dummy driver
2019-01-31 17:57:14,391 Warning: sanitizing invalid gtk selection
2019-01-31 17:57:14,391  format=-0x2d6a69e0, type=0x55e72be9e6a0, length=-0x1

Bugs/issues:

[x] cannot access python uinput module. Seems not to be relevant
[x] html server unavailable, cannot find websockify module. This is surprising because I did install it explicitly. Does xpra user python2 instead of python3? Yes, xpra server requires python2. See https://packages.debian.org/buster/xpra and https://xpra.org/trac/wiki/News
Multiple dbus related errors. On the one hand, it is not enabled when the container is started. On the other hand, there might be some missing packages in the image.

[x] dbus-launch: not found
[x] dbus server error
[x] if you do not have a dedicated dbus session for this xpra instance, use the 'notifications=no' option Fixed by adding the option

[x] Warning: webcam forwarding is disabled, the virtual video directory '/sys/devices/virtual/video4linux' was not found, make sure that the 'v4l2loopback' kernel module is installed and loaded. found 0 virtual video devices for webcam forwarding Fixed by adding --webcam=no
[x] failed to load the mdns publisher. No module named avahi. either fix your installation or use the 'mdns=no' option Fixed by adding the option
[X] python netifaces package is missing Fixed by installing it with pip (not pip3)
[ ] The log of the GUI app is mixed with the log of xpra.

The server can be stopped with:
xpra stop :0

This will close the GUI app, xpra and the xorg server.

NOTE: Since no display number was specified, and because no other xorg server was running in the container, :0 was used automatically.

However, if the GUI app is closed graphically, both xpra and xorg will keep running.
Open questions:

How can the GUI app be started again and attached to the running server?
Is it possible to start multiple apps (windows) with a single xpra/xorg server without desktop mode?
Is it possible to optionally close xpra/xorg automatically if all the windows are closed?

How does this fit with x11docker? As explained in the context of #110, I do not have a clear understanding about how is xpra used. According to https://xpra.org/trac/wiki/Usage/Docker and after the test above, I assume that:

A dummy X server is started on the host, and it is shared with the container.
Applications inside the container know nothing about xpra, they just connect to the X server that is shared from the host.
An xpra client is started on the host, which shows the content of the dummy X server on the host.

So:

There are not two instances of xpra running (as in my example).
That's why this note is shown in the xpra wiki: It has no dependencies inside of docker images..

If the assumptions above are correct, the following example is not valid for my use case: https://github.com/mviereck/x11docker/wiki/Remote-access-with-SSH#ssh-with-xpra. It is not valid because it is assumed that the host OS in the server is GNU/Linux. So, command x11docker --xvfb --display=30 --showenv x11docker/lxde pcmanfm will try to create a dummy X server with xvfb, and connect a container to it. Unfortunately, xvfb is not available on MSYS2.
I see two alternatives here:

Add a comment in https://github.com/mviereck/x11docker/wiki/Remote-access-with-SSH#ssh-with-xpra, explaining that a real X server is required on Windows. This means that --xvfb needs to be removed. As a result, the GUI apps will be seen on the server.

In this context, setting up a service on the server to allow a connection from a external client might be out of the scope of x11docker. I.e., x11docker provides Xenv, but it is up to the user to start the xpra server on windows.

If --xvfb is used on windows, create the dummy X server in a sibling container. This would not require an X server on the host, since an xpra client would suffice (see xpra shadow at https://xpra.org/trac/wiki/Usage). Pseudocode:

- User command: x11docker --xvfb --display=30 --showenv x11docker/lxde pcmanfm
- If on windows:
  - read Xenv < <(x11docker -t -p <HOST_PORT>:<CONTAINER_PORT> x11docker/xvfb sh -c "x11docker --xvfb --display=30 --showenv <no_container>")
  - env $Xenv x11docker x11docker/lxde pcmanfm
- Show info for the user to connect with an xpra client: <user>@localhost:<HOST_PORT>

The second option is based on how x11docker-gui behaves when kaptain is not installed on the host. I find it to be a really neat solution.
EDIT
I think that the comments above also apply to example https://github.com/mviereck/x11docker/wiki/Container-applications-running-in-Browser-with-HTML5#html5-with-xpra. I.e., xvfb is required on the host.
Furthermore, I think that these pages describe a similar procedure:

https://github.com/mviereck/x11docker/wiki/Wayland-on-MS-Windows#wayland-on-ms-windows
https://github.com/mviereck/x11docker/wiki/Custom-access-to-new-X-server#custom-access-to-new-x-server

I tried with alpine as the base image:
FROM python:2-alpine

RUN apk update \
 && apk add dbus-x11 lz4-dev lzo-dev pulseaudio-utils gcc musl-dev linux-headers \
 && pip install lz4 python-lzo websockify netifaces \
 && apk add xpra

# https://bugs.alpinelinux.org/issues/8741
RUN sed -i.bak 's#\(config \).*buildozer.*xorg\.conf#\1/etc/xpra/xorg.conf#g' /etc/xpra/conf.d/55_server_x11.conf \
  && rm /etc/xpra/conf.d/55_server_x11.conf.bak

It is half the size of the one based on buster (460MB vs 1GB). The xpra server works, and applications started in the same container can be used with a client on the host. However, other containers cannot use the X server. I think this is because some default settings (see xorg.conf and 55_server_x11.conf above) might be different from those on Debian. Alpine is security-oriented, indeed.

/bin/sh: 1: dbus-launch: not found

If you don't want to have a dbus server, try:
--dbus-launch=no
(I've added this to the FAQ)

cannot access python uinput module

Harmless, only used for virtualizing specialized input devices:
See https://xpra.org/trac/wiki/FAQ

xvfb is not available on MSYS2

Since you are using MSYS2, you may be interested in installing xpra as an MSYS2 package rather than an EXE installer, this should be available upstream soon - download the PKGBUILD for now:
https://xpra.org/trac/ticket/1883
(and be aware of the caveats in this ticket: some of the MSYS2 packages need fixing)

If --xvfb is used on windows, create the dummy X server in a sibling container.
This would not require an X server on the host, since an xpra client would suffice (see xpra shadow at https://xpra.org/trac/wiki/Usage).

Related to this, I don't see the difference between xpra start :0 --use-display --bind-tcp=<IP_ADDRESS>:10000 and xpra shadow :0 --bind-tcp=<IP_ADDRESS>:10000. Do you know if there is any?

The difference is huge.
xpra start will give you seamless mode and it is efficient.
xpra shadow will export one window for each monitor, and it is not efficient.
If you have an X11 server available, use xpra start --use-display, not shadow.

WARNING: no 'numpy' module, HyBi protocol will be slower.

Also in FAQ.
In the next release (2.5), we're completely getting rid of websockify:
https://xpra.org/trac/ticket/2121
So things will work better / faster, and without warnings.

You can try to run your xpra container with x11docker --vcxsrv and run xpra with --use-display. Not sure if the result is useable, but may be worth a try.

I would be very interested in hearing the results.

DISPLAY=:0 gtkwave

Always try to avoid doing things this way.
The environment will not include the various things xpra sets up when starting applications.
Either use xpra start --start=gtkwave, or after the xpra server is started ask it to start new commands with: xpra control :0 start gtkwave
(you can also do the same thing via the server's dbus control channel)
Note: you may need to configure your xpra server to allow new commands to be started with --start-new-commands=yes, this option was added later so it defaults to false.

@totaam, first off, thanks and congratulations. I had not realized that you are a maintainer/developer of xpra. That's such a great tool.

If you don't want to have a dbus server, try:
--dbus-launch=no
(I've added this to the FAQ)

Frankly, I don't really know if I want it or not. I'd rather support it, in case it makes sense. I see that it can be useful for multiple applications running in the same container. But the use case here is xpra in a container and multiple applications in one or many different containers. Therefore, dbus might only make sense if I can actually share it. Hope @mviereck can provide some thoughts.
Anyway, on the alpine based image, where I added dbus-x11, no error is shown because of dbus-launch. This error is shown instead:
cannot load dbus helper: No module named dbus
...
Error setting up server dbus instance:
  No module named dbus

I tried --dbus-launch=no but it makes no difference. I'll need to have a better look at it.

Since you are using MSYS2, you may be interested in installing xpra as an MSYS2 package rather than an EXE installer, this should be available upstream soon - download the PKGBUILD for now:
xpra.org/trac/ticket/1883
(and be aware of the caveats in this ticket: some of the MSYS2 packages need fixing)

I'm not sure about it being the best alternative for my use case. I want to avoid installing dependencies on the host (besides docker and a shell). Hence, the portable client provided (which is 200MB) is a quite good solution. It is twice the size of vcxsrv, but it is ok, considering xpra does encoding/decoding.
I had a look at the MSYS2 package and it relies on gtk3, which requires 355MB to be installed. The python2 variant requires python2-pygtk (400MB). I don't want to install those on the host. I use docker containers for that. Indeed, the alpine container with xpra is 466MB.
However, I see that it might be useful in different contexts to have xpra available through MSYS2. E.g., to launch an xpra server on the windows host (without docker). So, if you want the package to be tested, I can give it a try.

The difference is huge.
xpra start will give you seamless mode and it is efficient.
xpra shadow will export one window for each monitor, and it is not efficient.
If you have an X11 server available, use xpra start --use-display, not shadow.

I thought that shadow might be an alias for start --use-display. But after your comment and (@mviereck's), I am using xpra start. Certainly, I am not using --use-display for now, until I guess how to integrate the PoC with x11docker.

In the next release (2.5), we're completely getting rid of websockify: xpra.org/trac/ticket/2121
So things will work better / faster, and without warnings.

That's good news. On alpine, the error about HyBi is not shown, but the module is not found:
html server unavailable, cannot find websockify module

You can try to run your xpra container with x11docker --vcxsrv and run xpra with --use-display. Not sure if the result is useable, but may be worth a try.

I would be very interested in hearing the results.

I'll give it a try.

Always try to avoid doing things this way. The environment will not include the various things xpra sets up when starting applications. Either use xpra start --start=gtkwave, or after the xpra server is started ask it to start new commands with: xpra control :0 start gtkwave

That was just an example, but I do need to start the applications without xpra. That's because xpra is not available in the containers where the apps are executed. The scheme is the following:
                                              (xvfb/xorg server)
                                                (xpra server)               (portable win)
docker-for-win    <-> /tmp/.X11-unix <-> :0 <-> x11docker/xpra  <-> 8080 <-> xpra client                                    |
(alpine vm on hv)                         |
                                          |<-> app/container_1
                                          |<-> app/container_2
                                          |<-> app/container_3

Only x11docker/xpra contains xpra. Neither the host nor any of the other containers have xpra installed. The client can be used on the host, or on any other machine with access to it. So, there is a single connection between xpra and the apps: the X socket.
Is it possible to print those parameters that xpra sets, so that the environment in the app containers can be generated properly and it behaves as close to what xpra expects as possible?

You can try to run your xpra container with x11docker --vcxsrv and run xpra with --use-display. Not sure if the result is useable, but may be worth a try.

I would be very interested in hearing the results.

# ./x11docker -i --user=root -- -p "$XPRA_PORT:$XPRA_PORT" -- x11docker/xpra sh
x11docker note: Failed to check for sshd. ps -p not supported.

x11docker note: Using X server option --vcxsrv

x11docker note: Per default x11docker stores its cache files on drive C:.
  docker setup may not allow to share files from drive C:.
  If startup fails with an 'access denied' error,
  please either allow access to drive C: or specify a custom folder for cache
  storage with option '--cachebasedir D:/some/cache/folder'.
  Same issue can occur with option '--home'.
  Use option '--homebasedir D:/some/home/folder' in that case.

x11docker note: Windows firewall settings can forbid application access
  to the X server. If no application window appears, but no obvious error
  is shown, please check your firewall settings. Compare issue #108 on github.

x11docker WARNING: Found custom DOCKER_RUN_OPTIONS.
  x11docker will add them to 'docker run' command
  without a check for validity or security. Found options:
   '-p' '8080:8080'

x11docker WARNING: Option --user=root: Adding some capabilities to allow
  some root privileges in container that x11docker would drop otherwise.

x11docker note: Did not find container init system 'tini'.
  This is a bug in your distributions docker package.
  Normally, docker provides init system tini as '/usr/bin/docker-init'.

  x11docker uses tini for clean process handling and fast container shutdown.
  To provide tini yourself, please download tini-static:
    https://github.com/krallin/tini/releases/download/v0.18.0/tini-static
  Store it in one of:
    /home/eine/.local/share/x11docker/
    /usr/local/share/x11docker/

~ # echo $DISPLAY
<IP_ADDRESS>:100
~ # ls -la /tmp/.X11-unix/
total 8
drwxrwxrwt    2 root     0             4096 Feb  1 07:31 .
drwxrwxrwt    1 root     0             4096 Feb  1 07:31 ..
lrwxrwxrwx    1 root     0                5 Feb  1 07:31 X100 -> /X100
~ # xpra start $DISPLAY --use-display --bind-tcp=<IP_ADDRESS>:8080 --dbus-proxy=no --webcam=no --mdns=no --notifications=no --daemon=no

Warning: running as root
error running (['xprop', '-display', '<IP_ADDRESS>:100', '-root', '_XPRA_UINPUT_ID'],),{'stderr': -1, 'stdout': -1}: [Errno 2] No such fi
le or directory

** (process:83): WARNING **: 07:33:19.917: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'

** (process:83): WARNING **: 07:33:19.917: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'

** (process:83): WARNING **: 07:33:19.918: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
2019-02-01 07:33:19,978 Warning: failed to create socket directory '/run/user/0/xpra'
2019-02-01 07:33:19,978  [Errno 2] No such file or directory: '/run/user/0/xpra'
2019-02-01 07:33:19,978 Warning: cannot create socket '/run/user/0/xpra/50daeaa16548-<IP_ADDRESS>:100':
2019-02-01 07:33:19,978  [Errno 2] No such file or directory
2019-02-01 07:33:19,978  /run/user does not exist
2019-02-01 07:33:19,979 created unix domain socket: /root/.xpra/50daeaa16548-<IP_ADDRESS>:100
2019-02-01 07:33:19,979 created unix domain socket: /run/xpra/50daeaa16548-<IP_ADDRESS>:100
2019-02-01 07:33:19,986 X11 extension Composite not available
2019-02-01 07:33:19,986 Xpra 'start' subcommand runs as a compositing manager
2019-02-01 07:33:19,986  it cannot use a display which lacks the XComposite extension!
2019-02-01 07:33:19,987 closing tcp socket <IP_ADDRESS>:8080
2019-02-01 07:33:19,987 removing socket /root/.xpra/50daeaa16548-<IP_ADDRESS>:100
2019-02-01 07:33:19,987 removing socket /run/xpra/50daeaa16548-<IP_ADDRESS>:100

Nowadays, many desktop applications expect a dbus server to be available.
They may or may not always handle the missing dbus server well..

Will look further into it, then.

For this one, you need python-dbus since xpra is written in python.

Indeed. The package is named py-dbus on alpine. However, if installed, a different error is shown. See log below.

For the record, you can probably trim it down to less than 100MB by removing features you may not need: printing, audio, nvenc + numpy, opengl, etc

Do you mean by building the binaries myself or by removing dlls and executables from the portable tarball?

FYI: the mswindows EXE you downloaded is made using those same MSYS2 packages, we just trim it down and remove all the bits we don't actually need.

Is there any reference about how do you trim it down? It would be very interesting to have a 100MB client package which does not need all those deps. It is ok if those are just build dependencies, tho.

You can execute env from an xterm running within xpra.
Most, but not all, settings can be found in /etc/xpra/conf.d/60_server.conf.
(ie: some input method stuff is configured at runtime)

html server unavailable, cannot find websockify module

For more debug logging, try: -d websocket,http.
It's likely that python-websockify is not installed, or not correctly installed, or is the wrong version (too old, or unreleased).

xpra start :0 --bind-tcp=<IP_ADDRESS>:8080 --dbus-proxy=no --webcam=no --mdns=no --notifications=no --daemon=no -d websockify,http produces the same output as without -d websockify,http. See log below:

NOTE: Docker image python:2-alpine

~ # apk update && apk add xpra musl-dev gcc dbus-x11 py2-netifaces && pip install websockify
...
~ # sed -i.bak 's#\(config \).*buildozer.*xorg\.conf#\1/etc/xpra/xorg.conf#g' /etc/xpra/conf.d/55_server_x11.conf && rm /etc/xpra/conf.d/55_server_x11.conf.bak

~ # xpra start :0 --bind-tcp=<IP_ADDRESS>:8080 --dbus-proxy=no --webcam=no --mdns=no --notifications=no --daemon=no
Warning: running as root
WARNING: low display number: 0
 You are attempting to run the xpra server against a low X11 display number: ':0'.
 This is generally not what you want.
 You should probably use a higher display number just to avoid any confusion (and also this warning message).
2019-02-01 08:39:03,625 cannot access python uinput module:
2019-02-01 08:39:03,625  No module named uinput

X.Org X Server 1.19.6
Release Date: 2017-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.14.39-0-vanilla x86_64 Alpine Linux
Current Operating System: Linux ab7891869bd7 4.9.125-linuxkit #1 SMP Fri Sep 7 08:20:28 UTC 2018 x86_64
Kernel command line: BOOT_IMAGE=/boot/kernel console=ttyS0 page_poison=1 vsyscall=emulate panic=1 root=/dev/sr0 text
Build Date: 29 October 2018  06:33:45PM

Current version of pixman: 0.34.0
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(++) Log file: "/tmp/XDG_RUNTIME_DIR/xpra/Xorg.:0.log", Time: Fri Feb  1 08:39:03 2019
(++) Using config file: "/etc/xpra/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"

** (process:104): WARNING **: 08:39:06.413: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'

** (process:104): WARNING **: 08:39:06.413: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'

** (process:104): WARNING **: 08:39:06.413: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
2019-02-01 08:39:06,452 Warning: failed to create socket directory '/run/user/0/xpra'
2019-02-01 08:39:06,453  [Errno 2] No such file or directory: '/run/user/0/xpra'
2019-02-01 08:39:06,453 Warning: cannot create socket '/run/user/0/xpra/ab7891869bd7-0':
2019-02-01 08:39:06,453  [Errno 2] No such file or directory
2019-02-01 08:39:06,454  /run/user does not exist
2019-02-01 08:39:06,454 created unix domain socket: /root/.xpra/ab7891869bd7-0
2019-02-01 08:39:06,455 created unix domain socket: /run/xpra/ab7891869bd7-0
process 115: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/etc/machine-id": No such fi
le or directory
See the manual page for dbus-uuidgen to correct this issue.
  D-Bus not compiled with backtrace support so unable to print a backtrace
dbus-launch failed to start using command 'dbus-launch --close-stderr':

 exit code is -6

2019-02-01 08:39:08,231 Warning: menu forwarding is disabled:
2019-02-01 08:39:08,231  cannot load dbus helper: No module named dbus
2019-02-01 08:39:08,245 Warning: zlib is the only compressor enabled
2019-02-01 08:39:08,245  install and enable lzo or lz4 support for better performance
2019-02-01 08:39:08,367 pointer device emulation using XTest
2019-02-01 08:39:08,746 html server unavailable, cannot find websockify module
2019-02-01 08:39:08,747 Error setting up server dbus instance:
2019-02-01 08:39:08,747  No module named dbus
2019-02-01 08:39:08,751 pulseaudio not started: 'pulseaudio' command not found

Warning: running as root
Warning: failed to import GStreamer 1.x:
 No module named gi
2019-02-01 08:39:09,050 Error: failed to query sound subsystem:
2019-02-01 08:39:09,051  query did not return any data
2019-02-01 08:39:09,055 xpra X11 version 2.2.6-r18970 64-bit
2019-02-01 08:39:09,056  uid=0, gid=0
2019-02-01 08:39:09,056  running with pid 104 on Linux
2019-02-01 08:39:09,056  connected to X11 display :0 with 24 bit colors
2019-02-01 08:39:09,168 xpra is ready.
2019-02-01 08:39:09,169 7.8GB of system memory

~ # apk add py-dbus
(1/2) Installing dbus-glib (0.108-r1)
(2/2) Installing py-dbus (1.2.0-r2)

Warning: running as root
WARNING: low display number: 0
 You are attempting to run the xpra server against a low X11 display number: ':0'.
 This is generally not what you want.
 You should probably use a higher display number just to avoid any confusion (and also this warning message).
2019-02-01 08:42:21,049 cannot access python uinput module:
2019-02-01 08:42:21,049  No module named uinput

X.Org X Server 1.19.6
Release Date: 2017-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.14.39-0-vanilla x86_64 Alpine Linux
Current Operating System: Linux ab7891869bd7 4.9.125-linuxkit #1 SMP Fri Sep 7 08:20:28 UTC 2018 x86_64
Kernel command line: BOOT_IMAGE=/boot/kernel console=ttyS0 page_poison=1 vsyscall=emulate panic=1 root=/dev/sr0 text
Build Date: 29 October 2018  06:33:45PM

Current version of pixman: 0.34.0
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(++) Log file: "/tmp/XDG_RUNTIME_DIR/xpra/Xorg.:0.log", Time: Fri Feb  1 08:42:21 2019
(++) Using config file: "/etc/xpra/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"

** (process:138): WARNING **: 08:42:23.796: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'

** (process:138): WARNING **: 08:42:23.796: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'

** (process:138): WARNING **: 08:42:23.796: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
2019-02-01 08:42:23,832 Warning: failed to create socket directory '/run/user/0/xpra'
2019-02-01 08:42:23,832  [Errno 2] No such file or directory: '/run/user/0/xpra'
2019-02-01 08:42:23,833 Warning: cannot create socket '/run/user/0/xpra/ab7891869bd7-0':
2019-02-01 08:42:23,833  [Errno 2] No such file or directory
2019-02-01 08:42:23,833  /run/user does not exist
2019-02-01 08:42:23,835 created unix domain socket: /root/.xpra/ab7891869bd7-0
2019-02-01 08:42:23,835 created unix domain socket: /run/xpra/ab7891869bd7-0
process 149: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/etc/machine-id": No such fi
le or directory
See the manual page for dbus-uuidgen to correct this issue.
  D-Bus not compiled with backtrace support so unable to print a backtrace
dbus-launch failed to start using command 'dbus-launch --close-stderr':

 exit code is -6

process 138: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/etc/machine-id": No such fi
le or directory
See the manual page for dbus-uuidgen to correct this issue.
  D-Bus not compiled with backtrace support so unable to print a backtrace
Aborted

Do you mean by building the binaries myself or by removing dlls and executables from the portable tarball?

Either would work. Building yourself might be easier.
Note: the windows installer is not a tarball, so you would have to re-pack the installer afterwards.

Is there any reference about how do you trim it down?

There is a bit of information scattered in various tickets.
The key thing is to turn things off during the build: ./setup.py --without-webcam --without-printing --without-nvenc etc..
Then some further trimming may be needed.

I need to execute dbus-uuidgen

Hmm. I've seen this before. I consider this to be a distro mis-packaging issue.
IMHO, you shouldn't have to run things by hand to use a software when packaged properly.

Warning: zlib is the only compressor enabled
 install and enable lzo or lz4 support for better performance

Performance will be absolutely dreadful unless you also use --compress=0.

produces the same output as without -d websocket,http

That's odd, but:

xpra X11 version 2.2.6-r18970 64-bit

Since you're running an outdated / unsupported version, that's possible.

Note: the windows installer is not a tarball, so you would have to re-pack the installer afterwards.

Sorry, I did mean the zipfile, not tarball. I have not used the installer.

The key thing is to turn things off during the build: ./setup.py --without-webcam --without-printing --without-nvenc etc..

Thanks.

Hmm. I've seen this before. I consider this to be a distro mis-packaging issue.
IMHO, you shouldn't have to run things by hand to use a software when packaged properly.

Well, since alpine is not really designed for desktop apps, dbus might not be the most loved package...

Performance will be absolutely dreadful unless you also use --compress=0.

It happens the same as with websockify. The packages are installed. You can see in https://github.com/alpinelinux/aports/blob/master/community/xpra/APKBUILD#L12 that both py2-lz4 and py2-numpy are installed with xpra. However, numpy is compiled again when pip install websockify is executed, and lz4 is ignored (not found).

Since you're running an outdated / unsupported version, that's possible.

That's because the base image is still based on alpine3.8. They might update soon: https://github.com/docker-library/python/pull/375
Meanwhile, I'll update the package.

It happens the same as with websockify. The packages are installed.

They might just be too old:

python-lz4 has had a few gratuitous incompatible changes between versions - not sure what the minimal requirements are
websockify: we require 0.7 or later IIRC

@totaam, I think you might have skipped this comment: https://github.com/mviereck/x11docker/issues/117#issuecomment-459622186

They might just be too old:

With this dockerfile:
FROM python:2-alpine

# Use alpine version 3.9 instead of 3.8
RUN sed -i.bak 's#3\.8#3\.9#g' /etc/apk/repositories \
 && rm /etc/apk/repositories.bak

RUN apk update \
 && apk add xpra musl-dev py-dbus gcc dbus-x11 py2-netifaces pulseaudio pulseaudio-utils \
 && pip install websockify \
 && dbus-uuidgen --ensure

# https://bugs.alpinelinux.org/issues/8741
RUN sed -i.bak 's#\(config \).*buildozer.*xorg\.conf#\1/etc/xpra/xorg.conf#g' /etc/xpra/conf.d/55_server_x11.conf \
 && rm /etc/xpra/conf.d/55_server_x11.conf.bak

these are the versions:

Packages:
xpra: 2.4.2 (was 2.2.6 in 3.8)
py-lz4: 2.1.2 (was 2.0.1 in 3.8)
py-numpy: 1.15.4 (was 1.14.3 in 3.8)
pip
numpy: 1.16.1
websockify: 0.8.0

and this is the output:
~ # xpra start :0 --bind-tcp=<IP_ADDRESS>:8080 --dbus-proxy=no --webcam=no --mdns=no --notifications=no --daemon=no
...
2019-02-01 12:28:48,555 Error: cannot enable SSH socket upgrades:
2019-02-01 12:28:48,555  No module named paramiko
2019-02-01 12:28:48,556 cannot access python uinput module:
2019-02-01 12:28:48,556  No module named uinput
...
(++) Using config file: "/etc/xpra/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
2019-02-01 12:28:51,528 Warning: failed to create socket directory '/run/user/0/xpra'
2019-02-01 12:28:51,528  [Errno 2] No such file or directory: '/run/user/0/xpra'
2019-02-01 12:28:51,529 Warning: cannot create socket '/run/user/0/xpra/b510efa3b625-0':
2019-02-01 12:28:51,529  [Errno 2] No such file or directory
2019-02-01 12:28:51,529  /run/user does not exist
2019-02-01 12:28:51,530 created unix domain socket: /run/xpra/b510efa3b625-0
2019-02-01 12:28:53,463 pointer device emulation using XTest
2019-02-01 12:28:53,807 Warning: OpenGL support check failed:
2019-02-01 12:28:53,807  OpenGL is not supported
2019-02-01 12:28:53,855 html server unavailable, cannot find websockify module
2019-02-01 12:28:54,119 pulseaudio server started with pid 105
2019-02-01 12:28:54,119  private server socket path:
2019-02-01 12:28:54,119  '/tmp/XDG_RUNTIME_DIR/xpra/pulse-0/pulse/native'
W: [pulseaudio] main.c: This program is not intended to be run as root (unless --system is specified).
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such fil
e or directory
W: [pulseaudio] authkey.c: Failed to open cookie file '/root/.config/pulse/cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to load authentication key '/root/.config/pulse/cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to open cookie file '/root/.pulse-cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to load authentication key '/root/.pulse-cookie': No such file or directory
E: [pulseaudio] ltdl-bind-now.c: Failed to open module module-x11-publish.so: Error loading shared library module-x11-publish.so: No s
uch file or directory
E: [pulseaudio] module.c: Failed to open module "module-x11-publish".

Warning: running as root
Warning: failed to import GStreamer 1.x:
 No module named gi
2019-02-01 12:28:54,450 Error: failed to query sound subsystem:
2019-02-01 12:28:54,450  query did not return any data
2019-02-01 12:28:54,546 xpra X11 version 2.4.2-r21077 64-bit
2019-02-01 12:28:54,546  uid=0, gid=0
2019-02-01 12:28:54,546  running with pid 85 on Linux
2019-02-01 12:28:54,546  connected to X11 display :0 with 24 bit colors
2019-02-01 12:28:54,666 7.8GB of system memory
2019-02-01 12:28:54,667 xpra is ready.

So, the problem with lz4 is gone. However, it still cannot find websockify. Also, now it complains about OpeGL, which it did not before.
The errors about pulseaudio were not shown earlier because it was not installed. Anyway, those are not relevant ATM.
If I run xpra start -d websocket,http now, I get some debug output:
2019-02-01 12:44:14,053 init_html_proxy(..) options: tcp_proxy=, html='auto'
2019-02-01 12:44:14,053 init_html_proxy(..) html=None
2019-02-01 12:44:14,057 WEBSOCKIFY_NUMPY=False
2019-02-01 12:44:14,058 importing WebSocketConnection
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/xpra/server/server_core.py", line 450, in init_html_proxy
    from xpra.server.websocket import WebSocketConnection
  File "/usr/lib/python2.7/site-packages/xpra/server/websocket.py", line 28, in <module>
    from websockify.websocket import WebSocketRequestHandler    #@Reimport
ImportError: No module named websockify.websocket
2019-02-01 12:44:14,063 html server unavailable, cannot find websockify module
2019-02-01 12:44:14,063 found html5 client in '/usr/share/xpra/www'

About the fix after installing dbus. It should not be required, because it is done twice:

https://github.com/alpinelinux/aports/blob/master/main/dbus/dbus.post-install#L3
https://github.com/alpinelinux/aports/blob/master/main/dbus/dbus.initd#L15

However, for some reason post-install and pre-install script fail. So, dbus is installed, but not properly configured. Furthermore, dbus.initd is copied to /etc/init.d/dbus (https://github.com/alpinelinux/aports/blob/master/main/dbus/APKBUILD#L55), but it seems not to be executed. Interesting...

@totaam Thank you for looking at this!
Re: DBus:
x11docker supports dbus in container with some additional setup. However, unless it is a must-have, I would not use it. For the record:

To run DBus, x11docker provides option --dbus-system. But it recently has a timeout issue I could not fix. So I don't recommend this option.
DBus will run well if installing an init system in container like OpenRC or runit. x11docker supports them with --openrc  and --runit
It might be possible to share DBus across multiple containers if they share the same network namespace set with docker run option --net=somenetwork. But it might not be worth the effort.

The errors about pulseaudio were not shown earlier because it was not installed.

You can add --pulseaudio=no.

You can try to run your xpra container with x11docker --vcxsrv and run xpra with --use-display. Not sure if the result is useable, but may be worth a try.

I would be very interested in hearing the results.

It seems that xpra accepts :DISPLAY and ssh:HOST:DISPLAY as valid formats. But not HOST:DISPLAY, which is the one set by x11docker.

VcXsrv is accessable only over IP but not with a unix socket. So DISPLAY has the format IP:DISPLAYNUMBER. It seems xpra server does not support X over IP yet. Regular X setups on Linux always provide a unix socket. Maybe xpra server could handle this special case if it regards this unusual way to access X.

2019-02-01 12:28:53,855 html server unavailable, cannot find websockify module
websockify: 0.8.0

That should have worked:
$ rpm -q python2-websockify
python2-websockify-0.8.0-10.fc29.noarch
$ python -c "from websockify.websocket import \
WebSocketRequestHandler;print(WebSocketRequestHandler)"
websockify.websocket.WebSocketRequestHandler

Also, now it complains about OpenGL, which it did not before.

That's because it probably didn't check before and now it does.
You can ignore that if your X11 applications don't need OpenGL.

So DISPLAY has the format IP:DISPLAYNUMBER. It seems xpra server does not support X over IP yet. Regular X setups on Linux always provide a unix socket. Maybe xpra server could handle this special case if it regards this unusual way to access X.

This is unusual, but it should work. In fact, I'm pretty sure that it used to work.
Let me fix that.

Hmm. I've seen this before. I consider this to be a distro mis-packaging issue.
IMHO, you shouldn't have to run things by hand to use a software when packaged properly.

Well, since alpine is not really designed for desktop apps, dbus might not be the most loved package...

However, for some reason post-install and pre-install script fail. So, dbus is installed, but not properly configured. Furthermore, dbus.initd is copied to /etc/init.d/dbus (alpinelinux/aports:main/dbus/APKBUILD@master#L55), but it seems not to be executed. Interesting...

Some of the issues were actually my fault. I did not docker build all the tests. Sometimes I executed x11docker -i --user=root -- -p "$XPRA_PORT:$XPRA_PORT" -- python:2-alpine sh and then installed and executed commands interactively. The problem is that I was not using --cap-default, and that's why some pre-install and post-install scripts failed. So @totaam, there is nothing wrong with the dbus package on alpine.
I now installed everything with docker build. If I start x11docker -it --user=root -- -p 8080:8080 -- x11docker/xpra sh, /var/lib/dbus/machine-id exits, because it was created in the post-install script. But /etc/machine-id does not exist. This one should be set if /etc/init.d/dbus was executed. Since the shebang in the script is openrc-run I assume I need to install openrc.
I built the image again, including openrc. However, the script seems not to be started. I.e., nothing is triggering it. According to https://github.com/mviereck/x11docker/wiki/Init-systems-in-docker:-tini,-systemd,-SysVinit,-runit,-OpenRC-and-elogind#systemd-sysvinit-runit-openrc, I think that this is only useful if xpra is the first command executed in the container.  However, unless it is a must-have, I would not use it.

I think I won't in the end, because in my use case apps will be executed in different containers. However, I think it can be useful in other contexts where applications are installed on top of x11docker/xpra.

DBus will run well if installing an init system in container like OpenRC or runit. x11docker supports them with --openrc and --runit

Even if dbus is not used in the end, does having the init system inside the container provide any benefit to x11docker?

Re: X server setup, finding free display number and creating a cookie:
Have a look at wiki: Extended Xephyr script. It covers all this topics in a small script.

I will. Thanks.

That's because it probably didn't check before and now it does.
You can ignore that if your X11 applications don't need OpenGL.

It did check it. However, I was using debian, not alpine: https://github.com/mviereck/x11docker/issues/117#issuecomment-459533597
I fixed it now by installing py-opengl and mesa-dri-swrast.

2019-02-01 12:28:53,855 html server unavailable, cannot find websockify module
websockify: 0.8.0

That should have worked:

The test command does work, indeed. See below:
~ # xpra start :0 --bind-tcp=<IP_ADDRESS>:8080 --webcam=no --mdns=no --notifications=no --dbus-proxy=no --dbus-launch=no --pulseaudio=no --daemon=no
...
2019-02-02 10:56:06,469 Error: cannot enable SSH socket upgrades:
2019-02-02 10:56:06,469  No module named paramiko
...
(++) Using config file: "/etc/xpra/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
2019-02-02 10:56:09,199 created unix domain socket: /run/xpra/0d41f56470c2-0
2019-02-02 10:56:09,255 pointer device emulation using XTest
2019-02-02 10:56:09,572   OpenGL is supported on this display
2019-02-02 10:56:09,621 html server unavailable, cannot find websockify module

Warning: running as root
Warning: failed to import GStreamer 1.x:
 No module named gi
2019-02-02 10:56:09,931 Error: failed to query sound subsystem:
2019-02-02 10:56:09,931  query did not return any data
2019-02-02 10:56:10,020 xpra X11 version 2.4.2-r21077 64-bit
2019-02-02 10:56:10,021  uid=0, gid=0
2019-02-02 10:56:10,021  running with pid 80 on Linux
2019-02-02 10:56:10,021  connected to X11 display :0 with 24 bit colors
2019-02-02 10:56:10,132 xpra is ready.
...
~ # python -c "from websockify.websocket import \
> WebSocketRequestHandler;print(WebSocketRequestHandler)"
websockify.websocket.WebSocketRequestHandler

Nevertheless, I don't know if it is worth spending effort on this issue, since it is going to be dropped. You said it will be done in the next release (2.5). I see that last releases have been published every 4-5 months, so I expect that it won't be out until Q2. Is there any schedule? I see december in https://xpra.org/trac/roadmap, but I believe that it is wrong.
Moreover, websockify depends on numy. Although I install 1.15.4 through the package manager, pip insists in building it again (1.16.1). Building it requires gcc and musl-dev. Will xpra get rid of numpy too? Or will it still be required?

The missing (or not recognized?) Composite extension is probably the reason why xpra fails.
@1138-4EB Please try the following:
Run x11docker with --vcxsrv --gpu. That adds VcXsrv options -wgl +iglx.

I get the same result:
# ./x11docker -i --vcxsrv --gpu --user=root --cap-default -- -p "8080:8080" -- x11docker/xpra sh
...
# xpra start $DISPLAY --use-display --bind-tcp=<IP_ADDRESS>:8080 --webcam=no --mdns=no --notifications=no --dbus-proxy=no --dbus-launch=no --pulseaudio=no --daemon=no
Warning: running as root
2019-02-02 12:22:16,014 Error: cannot enable SSH socket upgrades:
2019-02-02 12:22:16,014  No module named paramiko
error running (['xprop', '-display', '<IP_ADDRESS>:100', '-root', '_XPRA_UINPUT_ID'],),{'stderr': -1, 'stdout': -1}: [Errno 2] No such fi
le or directory
2019-02-02 12:22:16,107 Warning: failed to create socket directory '/run/user/0/xpra'
2019-02-02 12:22:16,107  [Errno 2] No such file or directory: '/run/user/0/xpra'
2019-02-02 12:22:16,108 Warning: cannot create socket '/run/user/0/xpra/1855ae177797-<IP_ADDRESS>:100':
2019-02-02 12:22:16,108  [Errno 2] No such file or directory
2019-02-02 12:22:16,108  /run/user does not exist
2019-02-02 12:22:16,109 created unix domain socket: /run/xpra/1855ae177797-<IP_ADDRESS>:100
2019-02-02 12:22:16,114 X11 extension Composite not available
2019-02-02 12:22:16,115 Xpra 'start' subcommand runs as a compositing manager
2019-02-02 12:22:16,115  it cannot use a display which lacks the XComposite extension!

I tried after unset LIBGL_ALWAYS_INDIRECT too. No difference.

x11docker could also add +extension Composite. I am not sure if VcXsrv handles that well.

I tried adding it to line x11docker#L2977. But it does not change.

Even if dbus is not used in the end, does having the init system inside the container provide any benefit to x11docker?

As being said in the wiki:

Init in container solves the zombie reaping issue.

Without zombie reaping the container can crash at some point, after hours or after month. As default x11docker uses tini / docker-init, but unfortunately it is not available everywhere. --openrc is a good alternative for alpine images. Let's discuss further upcoming init questions in a separate ticket as they are not related to xpra.

It seems that the problem with Composite might be a case-sensitiveness issue. After changing 2977 to: yes) Xcommand="$Xcommand -wgl +iglx +extension COMPOSITE", the output is different:

Yes, sorry, I should have said it. In recent X versions the name changed from Composite to COMPOSITE. As a workaround x11docker sets for other X options +extension Composite +extension COMPOSITE. One succeeds, one fails. It is ok for X to fail loading an extension, it is not fatal, so don't worry about failing MIT_SHM and XVideo.

Invalid MIT-MAGIC-COOKIE-1

That is odd because the cookie works otherwise. Try disabling cookie authentication with --no-auth.

@mviereck, the problem with the cookie was exceptional I think. See second edit above. I think that I might be missing some packages, such as xf86-input-mouse.

Let's discuss further upcoming init questions in a separate ticket as they are not related to xpra.

Agree.

It looks like xpra server succeeds now to take over VcXsrv. Could you try to run something and connect with xpra client? It might succeed with xpra client but could show damaged content in VcXsrv windows.
xpra can preserve the content in VcXsrv windows:

       --sync-xvfb=DELAY
              The  windows  are  normally only displayed on the client(s), they are not painted on the virtual display.  Some applications like screen recorders may want to capture the window contents, you
              can use this option to enable painting with a configurable delay (in milliseconds).  Warning: this extra painting is expensive and quite slow, which is why it is not enabled by default.

It looks like xpra server succeeds now to take over VcXsrv.

No really sure about it. When xpra server starts xpra X11 version 2.4.2-r21077 64-bit and xpra is ready. are printed to the log. None of them is shown here.
Moreover, I can see that some processes are running in the background, but I cannot stop xpra:
~ # xpra stop $DISPLAY
xpra initialization error:
 unknown format for display name: <IP_ADDRESS>:100
~ # xpra list
Found the following xpra sessions:
/run/xpra:
        UNKNOWN session at :<IP_ADDRESS>:100
Re-probing unknown sessions in: /run/xpra
        UNKNOWN session at :<IP_ADDRESS>:100 (cleaned up)
~ # xpra list
No xpra sessions found
~ # top
Mem: 5036060K used, 3109780K free, 1156K shrd, 134348K buff, 4025876K cached
CPU:   0% usr   0% sys   0% nic  99% idle   0% io   0% irq   0% sirq
Load average: 0.00 0.00 0.00 2/434 114
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
   95    88 root     S    63064   1%   2   0% {xpra} /usr/bin/python2 /usr/bin/xpra opengl
   88     1 root     S    52632   1%   0   0% {xpra} /usr/bin/python2 /usr/bin/xpra start <IP_ADDRESS>:100 --use-display --bind-tcp=0.0.0
   93     1 root     S     2632   0%   0   0% dbus-launch --autolaunch 4f1001ca5507811c0deb1fd85c556f5c --binary-syntax --close-stderr
    1     0 root     S     1592   0%   0   0% sh
  114     1 root     R     1524   0%   2   0% top
   94     1 root     S     1372   0%   2   0% /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session

Could you try to run something and connect with xpra client? It might succeed with xpra client but could show damaged content in VcXsrv windows.

It does not work. Vcxsrv is taking 30% of the CPU. And the icon in the task bar does not respond to the right-click (which provides a contextual menu shown the number of clients, allowing to open the log, etc.).
When I exit, the container is properly closed (I can see it with docker ps -a from another terminal), but the X server needs some time to close.
I also tried to start the container, start xterm to check that vcxsrv is working as expected, and run xpra start while xterm is open. As soon as xpra starts, xterm freezes: (Not Responding). At some point xterm: fatal IO error 104 (Connection reset by peer) or KillClient on X server "<IP_ADDRESS>:100".

xpra can preserve the content in VcXsrv windows:

I restarted the container and tried xpra with --sync-xvfb=500. No difference.

ok, at this point I have no idea. Maybe VcXsrv is just not compatible to xpra. Maybe it cannot handle +extension COMPOSITE well. @totaam might have an idea, though.
As you can successfully use Xvfb/Xdummy in container, it might not be worth to debug this further. It could have been a possibility to add some GPU support, though.

Try running xpra with -d x11 or even -d all.

~ # xpra start $DISPLAY --use-display --bind-tcp=<IP_ADDRESS>:8080 --webcam=no --mdns=no --notifications=no --dbus-proxy=no --dbus-launch=n
o --pulseaudio=no -d all

Warning: running as root
2019-02-02 18:01:45,368 get_enabled_encoders(['rencode', 'bencode', 'yaml']) enabled=['rencode', 'bencode']
~ # Entering daemon mode; any further errors will be reported to:
  /tmp/XDG_RUNTIME_DIR/xpra/<IP_ADDRESS>:100.log
cat /tmp/XDG_RUNTIME_DIR/xpra/<IP_ADDRESS>:100.log
2019-02-02 18:01:45,373 import paramiko
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/xpra/scripts/server.py", line 467, in create_sockets
    import paramiko
ImportError: No module named paramiko
2019-02-02 18:01:45,375 Error: cannot enable SSH socket upgrades:
2019-02-02 18:01:45,375  No module named paramiko
2019-02-02 18:01:45,375 setting up SSL sockets:
2019-02-02 18:01:45,375 setting up SSH sockets:
2019-02-02 18:01:45,375 setting up https / wss (secure websockets):
2019-02-02 18:01:45,375 setting up TCP sockets: ('<IP_ADDRESS>', 8080)
2019-02-02 18:01:45,376 <socket._socketobject object at 0x7fa494650980>.bind(('<IP_ADDRESS>', 8080))
2019-02-02 18:01:45,376 tcp: <IP_ADDRESS>:8080 : <module 'socket' from '/usr/lib/python2.7/socket.pyc'>
2019-02-02 18:01:45,376 setting up UDP sockets:
2019-02-02 18:01:45,376 setting up http / ws (websockets):
2019-02-02 18:01:45,376 setting up rfb sockets:
2019-02-02 18:01:45,376 setting up vsock sockets:
2019-02-02 18:01:45,376 env={'PYTHONIOENCODING': 'UTF-8', 'MWNO_RIT': 'true', 'XDG_CURRENT_DESKTOP': 'Xpra', 'XDG_SESSION_TYPE': 'x11'
, 'QT_IM_MODULE': 'xim', 'USER': 'root', 'HOME': '/root', 'LIBGL_ALWAYS_INDIRECT': '1', 'PATH': '/usr/local/bin:/usr/local/sbin:/usr/l
ocal/bin:/usr/sbin:/usr/bin:/sbin:/bin', 'MWWM': 'allwm', 'DISPLAY': '<IP_ADDRESS>:100', 'LANG': 'C.UTF-8', 'TERM': 'xterm', 'SHELL': '/b
in/sh', 'container': 'docker', 'XAUTHORITY': '/x11docker/Xclientcookie', 'SHLVL': '2', 'PYTHON_PIP_VERSION': '19.0.1', 'XPRA_XSHM': '0
', 'MWNOCAPTURE': 'true', 'XMODIFIERS': '@im=none', 'XPRA_LOG_DIR': '/tmp/XDG_RUNTIME_DIR/xpra', 'IMSETTINGS_MODULE': 'none', 'GPG_KEY
': 'C01E1CAD5EA2C4F0B8E3571504C367C218ADD4FF', 'XDG_RUNTIME_DIR': '/tmp/XDG_RUNTIME_DIR', 'DISABLE_IMSETTINGS': '1', 'NO_AT_BRIDGE': '
1', 'QT_X11_NO_NATIVE_MENUBAR': '1', 'TZ': 'UTC-01', 'PYTHON_VERSION': '2.7.15', 'GTK_IM_MODULE': 'xim', 'UBUNTU_MENUPROXY': '', 'OLDP
WD': '/tmp', 'HOSTNAME': '50baea70a402', 'PWD': '/root', 'CKCON_X11_DISPLAY': '<IP_ADDRESS>:100'}
2019-02-02 18:01:45,378 looking for '_XPRA_UINPUT_ID' on display '<IP_ADDRESS>:100' with XAUTHORITY='/x11docker/Xclientcookie'
error running (['xprop', '-display', '<IP_ADDRESS>:100', '-root', '_XPRA_UINPUT_ID'],),{'stderr': -1, 'stdout': -1}: [Errno 2] No such fi
le or directory
2019-02-02 18:01:45,380 Popen(['xprop', '-display', '<IP_ADDRESS>:100', '-root', '_XPRA_UINPUT_ID'])=(-1, '', '')
2019-02-02 18:01:45,467 setup_local_sockets: bind=['auto']
2019-02-02 18:01:45,467 sockpaths(<IP_ADDRESS>:100)=['/run/user/0/xpra/50baea70a402-<IP_ADDRESS>:100', '/run/xpra/50baea70a402-<IP_ADDRESS>:100
'] (uid=0, gid=0)
2019-02-02 18:01:45,467 state(/run/user/0/xpra/50baea70a402-<IP_ADDRESS>:100)=DEAD
2019-02-02 18:01:45,468 creating sockdir=/run/user/0/xpra, kwargs={}
2019-02-02 18:01:45,468 Warning: failed to create socket directory '/run/user/0/xpra'
2019-02-02 18:01:45,468  [Errno 2] No such file or directory: '/run/user/0/xpra'
2019-02-02 18:01:45,468 state(/run/xpra/50baea70a402-<IP_ADDRESS>:100)=DEAD
2019-02-02 18:01:45,468 creating sockdir=/run/xpra, kwargs={'mode': 509}
2019-02-02 18:01:45,468 sockets in unknown state: []
2019-02-02 18:01:45,468 state(/run/user/0/xpra/50baea70a402-<IP_ADDRESS>:100)=DEAD
2019-02-02 18:01:45,468 state(/run/xpra/50baea70a402-<IP_ADDRESS>:100)=DEAD
2019-02-02 18:01:45,468 socket creation error
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/xpra/server/socket_util.py", line 377, in setup_local_sockets
    sock, cleanup_socket = create_unix_domain_socket(sockpath, sperms)
  File "/usr/lib/python2.7/site-packages/xpra/server/socket_util.py", line 41, in create_unix_domain_socket
    listener.bind(sockpath)
  File "/usr/lib/python2.7/socket.py", line 228, in meth
    return getattr(self._sock,name)(*args)
error: [Errno 2] No such file or directory
2019-02-02 18:01:45,470 Warning: cannot create socket '/run/user/0/xpra/50baea70a402-<IP_ADDRESS>:100':
2019-02-02 18:01:45,470  [Errno 2] No such file or directory
2019-02-02 18:01:45,471  /run/user does not exist
2019-02-02 18:01:45,471 created unix domain socket: /run/xpra/50baea70a402-<IP_ADDRESS>:100
2019-02-02 18:01:45,471 setting up local sockets: [(('unix-domain', <socket._socketobject object at 0x7fa4930b5050>, '/run/xpra/50baea
70a402-<IP_ADDRESS>:100'), <function cleanup_socket at 0x7fa4931c18c0>)]
2019-02-02 18:01:45,471 unix-domain /run/xpra/50baea70a402-<IP_ADDRESS>:100 : <socket._socketobject object at 0x7fa4930b5050>
2019-02-02 18:01:45,475 Missing property _XPRA_DBUS_PID (u32)
2019-02-02 18:01:45,475 Missing property DBUS_SESSION_BUS_ADDRESS (latin1)
2019-02-02 18:01:45,476 Missing property DBUS_SESSION_BUS_PID (u32)
2019-02-02 18:01:45,477 Missing property DBUS_SESSION_BUS_WINDOW_ID (u32)
2019-02-02 18:01:45,477 retrieved existing dbus attributes
2019-02-02 18:01:45,477 dbus attributes: pid=None, env={}
2019-02-02 18:01:45,477 env={'PYTHONIOENCODING': 'UTF-8', 'MWNO_RIT': 'true', 'XPRA_XDG_OPEN_SERVER_SOCKET': '/run/xpra/50baea70a402-1
<IP_ADDRESS>:100', 'XDG_CURRENT_DESKTOP': 'Xpra', 'XDG_SESSION_TYPE': 'x11', 'QT_IM_MODULE': 'xim', 'USER': 'root', 'HOME': '/root', 'LIBG
L_ALWAYS_INDIRECT': '1', 'PATH': '/usr/lib/xpra:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin', 'MWWM':
'allwm', 'DISPLAY': '<IP_ADDRESS>:100', 'LANG': 'C.UTF-8', 'TERM': 'xterm', 'SHELL': '/bin/sh', 'container': 'docker', 'XAUTHORITY': '/x1
1docker/Xclientcookie', 'SHLVL': '2', 'PYTHON_PIP_VERSION': '19.0.1', 'XPRA_XSHM': '0', 'MWNOCAPTURE': 'true', 'XMODIFIERS': '@im=none
', 'XPRA_LOG_DIR': '/tmp/XDG_RUNTIME_DIR/xpra', 'IMSETTINGS_MODULE': 'none', 'GPG_KEY': 'C01E1CAD5EA2C4F0B8E3571504C367C218ADD4FF', 'X
DG_RUNTIME_DIR': '/tmp/XDG_RUNTIME_DIR', 'DISABLE_IMSETTINGS': '1', 'NO_AT_BRIDGE': '1', 'QT_X11_NO_NATIVE_MENUBAR': '1', 'TZ': 'UTC-0
1', 'PYTHON_VERSION': '2.7.15', 'GTK_IM_MODULE': 'xim', 'UBUNTU_MENUPROXY': '', 'OLDPWD': '/tmp', 'HOSTNAME': '50baea70a402', 'PWD': '
/root', 'CKCON_X11_DISPLAY': '<IP_ADDRESS>:100'}
2019-02-02 18:01:45,477 X11 extension Composite event_base=0
2019-02-02 18:01:45,478 found X11 extension Composite with version 0.2
2019-02-02 18:01:45,480 XShmQueryExtension()=False
2019-02-02 18:01:45,480 Warning: no XShm support on display <IP_ADDRESS>:100
2019-02-02 18:01:45,480 X11 extension DAMAGE event_base=90
2019-02-02 18:01:45,480 found X11 extension DAMAGE with version 1.0
2019-02-02 18:01:45,480 X11 extension Composite event_base=0
2019-02-02 18:01:45,480 found X11 extension Composite with version 0.2
2019-02-02 18:01:45,481 pointer grab constants: {0: 'NotifyNormal', 1: 'NotifyGrab', 2: 'NotifyUngrab', 3: 'NotifyWhileGrabbed'}
2019-02-02 18:01:45,481 detail constants: {0: 'NotifyAncestor', 1: 'NotifyVirtual', 2: 'NotifyInferior', 3: 'NotifyNonlinear', 4: 'Not
ifyNonlinearVirtual', 5: 'NotifyPointer', 6: 'NotifyPointerRoot', 7: 'NotifyDetailNone'}
2019-02-02 18:01:45,509 ewmh selection owner for WM_S0: 0
2019-02-02 18:01:45,509 compositing window manager _NEW_WM_CM_S0: 0
2019-02-02 18:01:45,510 _NET_SUPPORTING_WM_CHECK for screen 0: None (root=0x36c)
2019-02-02 18:01:45,510 X11 extension XShape event_base=64
2019-02-02 18:01:45,510 found X11 extension XShape with version 1.1
2019-02-02 18:01:45,511 displayHasXShape()=True
2019-02-02 18:01:45,511 XShape=True
2019-02-02 18:01:45,513 XRRQueryExtension()=1
2019-02-02 18:01:45,513 found XRandR extension
2019-02-02 18:01:45,513 found XRandR extension version 1.6
2019-02-02 18:01:45,513 found 1 config sizes
2019-02-02 18:01:45,516 successfully loaded socket C library from libc.so.6
2019-02-02 18:01:45,523 ServerBaseClass(<class 'xpra.server.server_core.ServerCore'>, <class 'xpra.server.mixins.server_base_controlco
mmands.ServerBaseControlCommands'>, <class 'xpra.server.mixins.clipboard_server.ClipboardServer'>, <class 'xpra.server.mixins.audio_se
rver.AudioServer'>, <class 'xpra.server.mixins.fileprint_server.FilePrintServer'>, <class 'xpra.server.mixins.mmap_server.MMAP_Server'
>, <class 'xpra.server.mixins.input_server.InputServer'>, <class 'xpra.server.mixins.child_command_server.ChildCommandServer'>, <class
 'xpra.server.mixins.encoding_server.EncodingServer'>, <class 'xpra.server.mixins.logging_server.LoggingServer'>, <class 'xpra.server.
mixins.networkstate_server.NetworkStateServer'>, <class 'xpra.server.mixins.display_manager.DisplayManager'>, <class 'xpra.server.mixi
ns.window_server.WindowServer'>)
2019-02-02 18:01:45,524 GTKServerBase.__init__()
2019-02-02 18:01:45,524 ServerCore.__init__()
2019-02-02 18:01:45,525 server uuid is bdd2d1978cd0425e84b69e051695923a
2019-02-02 18:01:45,525 file transfer: init_attributes('yes', 10, 'yes', 'no', 'yes', None, True)
2019-02-02 18:01:45,525 file transfer attributes={'open-files-ask': False, 'open-url': True, 'file-ask-timeout': 3600, 'open-files': F
alse, 'file-size-limit': 10, 'file-transfer': True, 'file-chunks': 65536, 'file-transfer-ask': False, 'printing-ask': False, 'open-url
-ask': False, 'printing': True}
2019-02-02 18:01:45,526 ServerBase.__init__()
2019-02-02 18:01:45,526 server uuid is bdd2d1978cd0425e84b69e051695923a
2019-02-02 18:01:45,527 initializing packet handlers
2019-02-02 18:01:45,527 init_virtual_devices({}) got pointer=None, touchpad=None
2019-02-02 18:01:45,527 pointer device emulation using XTest
2019-02-02 18:01:45,527 Warning: XTest extension is missing
2019-02-02 18:01:45,528 XFixesQueryExtension version present: True
2019-02-02 18:01:45,528 XFixesQueryExtension event base=86, error base=139
2019-02-02 18:01:45,528 Error: keyboard and mouse disabled
2019-02-02 18:01:45,528 randr=True
2019-02-02 18:01:45,529 _XPRA_RANDR_EXACT_SIZE=None
2019-02-02 18:01:45,530 get_xrr_screen_sizes()=[(3840, 1080)]
2019-02-02 18:01:45,530 randr=True, exact size=True
2019-02-02 18:01:45,530 randr enabled: True
2019-02-02 18:01:45,530 get_default_cursor=[1920, 540, 16, 16, 7, 7, 1, '\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\
xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xf
f\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\xff\xff\
xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xf
f\x00\x00\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\xff\
xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x0
0\xff\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\
xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x0
0\x00\xff\xff\xff\xff\xff\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\
xff\xff\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\
x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\
x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\
x00\x00\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\
xff\x00\x00\x00\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\
x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xf
f\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\
x00\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x0
0\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\
x00\x00\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x0
0\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\
xff\x00\x00\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\xf
f\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\
x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\x00\x00\xff\xff\xff\xff\xff\x00\x00\x00\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00\x00\xff\x00\x00\x00\xff\x00\
x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\
xff\xff\xff\xff', '']
~ #

@totaam xpra succeeds to use Xwin from Cygwin/X. See report of @1138-4EB  in #122.
Xwin is quite similar to VcXsrv, and x11docker calls them with the same command line options.
Both X servers are connected over IP with DISPLAY = IP:DISPLAYNUMBER.

@1138-4EB Are you still working on this? Otherwise we could close this and other related tickets for now and reopen them if they are of interest again.

Feel free to re-open if this is of interest again.

@1138-4EB Are you still working on this? Otherwise we could close this and other related tickets for now and reopen them if they are of interest again.

I'm sorry I missed this comment. I've been quite busy lately, so it is ok to close these issues for now. Nonetheless, I created a project with all of them (https://github.com/users/1138-4EB/projects/2), to make it is easier to come back later.


[RB26] antenna_offset Parameter missing

Hello,
The parameter antenna_offset is missing in the parameter.py of the rb26. I locally added the parameter by myself with the same value of the rb27 in the corresponding parameter.py so far.
Without this fix the Webinterface of the nicegui would only load a white page and the logger would output the following:
rosys_1         | 2024-05-07 10:52:38.128 [ERROR] nicegui/app/app.py:118: 'antenna_offset'
rosys_1         | Traceback (most recent call last):
rosys_1         |   File "/app/nicegui/client.py", line 287, in safe_invoke
rosys_1         |     result = func(self) if len(inspect.signature(func).parameters) == 1 else func()
rosys_1         |                                                                              ^^^^^^
rosys_1         |   File "/app/main.py", line 16, in startup
rosys_1         |     system = System()
rosys_1         |              ^^^^^^^^
rosys_1         |   File "/app/field_friend/system.py", line 27, in __init__
rosys_1         |     self.field_friend = FieldFriendHardware()
rosys_1         |                         ^^^^^^^^^^^^^^^^^^^^^
rosys_1         |   File "/app/field_friend/hardware/field_friend_hardware.py", line 40, in __init__
rosys_1         |     self.ANTENNA_OFFSET: float = config_params['antenna_offset']
rosys_1         |                                  ~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
rosys_1         | KeyError: 'antenna_offset'

While testing we discovered a bug, where the RTK point of the Robot was set to the position of the main antenna and not the centre of the Robot. This offset fixed the probelm. When adding the offset to the configs we seem to have missed the config for rb26. The offset was addet in commit 859eff2 .


Maybe finally fix generating dependencies

Revert "Revert "This seems to generate dependencies in the POM file.""
This reverts commit ba14c444c3f6741c7d9f96315a2bb20786858840.
Revert "Revert "Remove non GTNH deps from the generated pom.  Cleans up a lot of noisy deps anyway.""
This reverts commit 286a547090f8328d2fac0e0b576813c7fbe6cb13.


Description of kiali_urls. Kiali URL to cluster name mapping.

Issue https://github.com/kiali/kiali/issues/6243

Server PR https://github.com/kiali/kiali/pull/6452

@hhovsepy can you also remove these settings as they are no longer present in the kiali server config and no longer valid:
                      autodetect_secrets:
                        description: "Settings to allow cluster secrets to be auto-detected. Secrets must exist in the Kiali deployment namespace."
                        type: object
                        properties:
                          enabled:
                            description: "If true then remote cluster secrets will be autodetected during the installation of the Kiali Server Deployment. Any remote cluster secrets found in the Kiali deployment namespace will be mounted to the Kiali Server's file system. If false, you can still manually specify the remote cluster secret information in the 'clusters' setting if you wish to utilize multicluster features."
                            type: boolean
                          label:
                            description: "The name and value of a label that exists on all remote cluster secrets. Default is 'kiali.io/multiCluster=true'."
                            type: string
                      clusters:
                        description: "A list of clusters that the Kiali Server can access. You need to specify the remote clusters here if 'autodetect_secrets.enabled' is false."
                        type: array
                        items:
                          type: object
                          properties:
                            name:
                              description: "The name of the cluster."
                              type: string
                            secret_name:
                              description: "The name of the secret that contains the credentials necessary to connect to the remote cluster. This secret must exist in the Kiali deployment namespace."
                              type: string

can you also remove these settings as they are no longer present in the kiali server config and no longer valid

no, these are very important. This is how the operator sets up the kiali remote cluster secrets. don't remove these :)
https://github.com/kiali/kiali-operator/blob/80385928d04147aa8e0f424537c9cc9ceae5153e/roles/default/kiali-deploy/tasks/main.yml#L722-L736
https://github.com/kiali/kiali-operator/blob/80385928d04147aa8e0f424537c9cc9ceae5153e/roles/default/kiali-deploy/templates/openshift/deployment.yaml#L125-L129

they are no longer present in the kiali server config

We actually don't put them in the Kiali Config object because they aren't used by the server at all - these are one of the few settings that are for the operator (and helm charts) only - i.e. used only for installation. The Server never uses these settings so that is why they aren't in the Config object.

We actually don't put them in the Kiali Config object because they aren't used by the server at all - these are one of the few settings that are for the operator (and helm charts) only - i.e. used only for installation. The Server never uses these settings so that is why they aren't in the Config object.

Ah alright that makes sense. I'm always unsure of which configuration on the CR is just for the operator and which is for the kiali config.

I'm always unsure of which configuration on the CR is just for the operator and which is for the kiali config.

This is why I try to always make the Config object match the CR - only because its confusing ("why is this in the CR but not in the Config object).
I actually went against my instincts when I did not include these secret/cluster settings in the Config object. I convinced myself it was the right thing to do because these settings are essentially useless to the server - the server should never have a reason to look up their values.

This is why I try to always make the Config object match the CR - only because its confusing if they don't match ("why is this in the CR but not in the Config object?").

Well if there's ever a Kiali v2 with some breaking changes, perhaps we can separate the two on the CR. Something like
  spec:
    kialiConfig: ...
    deployment: ...
    otherCRFieldNotRelatedToConfig: ...


--fail-fast argument not works with command line

Expected Behavior
If i set --fail-fast argument in command line, test task parameter failFast value must be set to 'true'
Current Behavior
Now, when i try to run grade tasks:
gradle clean build --fail-fast -i

i have error:
FAILURE: Build failed with an exception.

* What went wrong:
Problem configuring task :build from command line.
> Unknown command-line option '--fail-fast'.

If i set in build.gradle test parameter:
test {
    failFast = true
}

all works fine

Duplicate of https://github.com/gradle/gradle/issues/2032
You'll have to list the test task explicitly if you want to give it options, e.g: gradle build test --fail-fast

You can also specify a custom property doFailFast, like this:
gradle clean build -PdoFailFast -i

Then you just read that in build.gradle:
test {
    failFast = rootProject.hasProperty("myFailFast")
}


Pipenv fails to install yamlfmt (due to ruamel.ordereddict ) (Python 3.6.8)

Possible duplicate of #2275 which was closed despite the original opener saying the issue wasn't resolved.
With pip 18.1 (python 3.6)
pip install yamlfmt
works fine while with pipenv 2018.11.26 ,
pipenv install yamlfmt
gives issues about installing ruamel.ordereddict:
                      ^', "    ordereddict.c:974:10: error: use of undeclared identifier '_PyThreadState_Current'", '            &_PyThreadState_Current);', '             ^', '    ordereddict.c:1581:47: error: too many arguments to function call, expected 2, have 3', '                                                  &missing_str);', '                                                  ^~~~~~~~~~~~', "    /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/include/python3.7m/object.h:507:12: note: '_PyObject_LookupSpecial' declared here", '    PyAPI_FUNC(PyObject *) _PyObject_LookupSpecial(PyObject *, _Py_Identifier *);', '               ^', "    ordereddict.c:1650:15: warning: comparison of integers of different signs: 'Py_ssize_t' (aka 'long') and 'unsigned long' [-Wsign-compare]", '            if (s > sizeof(recycle_on_stack)) {', '                ~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~', "    ordereddict.c:2858:13: error: no member named 'ma_table' in 'PyDictObject'", '        if (mp->ma_table != mp->ma_smalltable)', '            ~~  ^', "    ordereddict.c:2858:29: error: no member named 'ma_smalltable' in 'PyDictObject'", '        if (mp->ma_table != mp->ma_smalltable)', '                            ~~  ^', "    ordereddict.c:2859:26: error: no member named 'ma_mask' in 'PyDictObject'", '            res = res + (mp->ma_mask + 1) * sizeof(PyOrderedDictEntry);', '                         ~~  ^', '    2 warnings and 5 errors generated.', "    error: command 'clang' failed with exit status 1", '    ', '    ----------------------------------------']
[pipenv.exceptions.InstallError]: ['Failed building wheel for ruamel.ordereddict', 'Command "/Users/bprin/.local/share/virtualenvs/test-dxQmuQn2/bin/python3.7 -u -c "import setuptools, tokenize;__file__=\'/private/var/folders/cr/smds0c8x225gnbb3cc9lcsxm0000gn/T/pip-install-2mq0sd2c/ruamel.ordereddict/setup.py\';f=getattr(tokenize, \'open\', open)(__file__);code=f.read().replace(\'\\r\\n\', \'\\n\');f.close();exec(compile(code, __file__, \'exec\'))" install --record /private/var/folders/cr/smds0c8x225gnbb3cc9lcsxm0000gn/T/pip-record-nq7r2yyq/install-record.txt --single-version-externally-managed --compile --install-headers /Users/bprin/.local/share/virtualenvs/test-dxQmuQn2/bin/../include/site/python3.7/ruamel.ordereddict" failed with error code 1 in /private/var/folders/cr/smds0c8x225gnbb3cc9lcsxm0000gn/T/pip-install-2mq0sd2c/ruamel.ordereddict/']
ERROR: ERROR: Package installation

This is a bug in ruamel.ordereddict. https://bitbucket.org/ruamel/ordereddict/issues/8/build-failures-with-python36


implement @trace for

you are the real mvp
Tho I mean everyone here really also is the mvp too <3

As a high level comment. Is there a good way to add MLIR emission tests?
E.g. It would be great to do something which checks that the hlo generated by a given for loop exactly [or perhaps llvm filechek style] matches some given MLIR

We have an example of this here for enzyme/llvm https://github.com/EnzymeAD/Enzyme.jl/blob/main/test/codegen/allocator.jl

We have an example of this here for enzyme/llvm https://github.com/EnzymeAD/Enzyme.jl/blob/main/test/codegen/allocator.jl

Nice, it would be great to have FileCheck as part of a LLVM_full_jll or something so we write everything in the Julia test suite.

CI seem to be crashing within the new tests, I will investigate


Rancher Desktop as a Rancher Shell extension

[ ] Rancher Shell needs to operate when offline
Rancher Shell needs to be able to function without any backend. There's no guarantee that Kubernetes will be enabled at any point when running Rancher Desktop. All core Rancher Desktop functionality should behave as it does today when a backend doesn't exist.
We had previously produced a prototype for this behavior in PR #7852.

[ ] Customized layout for Rancher Desktop (Needs Review)
Previously, we anticipated that Rancher Shell would need a custom layout to accommodate Rancher Desktop. This might still be true as we work to implement the redesigned navigation. We need to devise a plan that will allow us to accommodate Rancher Desktop for the short term.
For more information, see PR #8000.

[ ] Communication patterns with Shell
W need to determine the communication patterns between Rancher Desktop and Rancher Shell. This includes defining the API endpoints, data formats, and any additional protocols or conventions required for interaction.

[ ] Handling route collisions and child routes
We need to address the issue of route collisions and child routes when integrating Rancher Desktop with Rancher Shell. This involves ensuring that the routing system can handle potential conflicts and maintain proper functionality in both projects.

We will track work to support this effort in #9216


fix: use a better approach to adding helm repos

to reuse the helmfile templating for user/pwd values

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign jstrachan
You can assign the PR to them by writing /assign @jstrachan in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/approve

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: jstrachan
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [jstrachan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Fix an issue where foliage painting doesn't work for tileset actor

Fixes #411
Foliage editor shoot ray into the world to detect brush position and place instances accordingly. However, it only detects collision for ECC_WorldStatic. The code the raycast can be found here https://github.com/EpicGames/UnrealEngine/blob/c3caf7b6bf12ae4c8e09b606f10a09776b4d1f38/Engine/Source/Editor/FoliageEdit/Private/FoliageEdMode.cpp#L1040.
When we change bUseDefaultCollision to be false, all our components have ECC_WorldDynamic, so it stops working with foliage

Thanks for the pull request @baothientran!

:heavy_check_mark: Signed CLA found.

Reviewers, don't forget to make sure that:

[ ] Cesium for Unreal Samples works.

Thanks @baothientran!


Rancher 1.6.11 upgraded status not being picked up by traefik

Do you want to request a feature or report a bug?
Bug
What did you do?
I have a service with 1 nginx container without health check on it. When I press upgrade, and it gets upgraded status, traefik doesn't catch it, and in dashboard I can see old container IP, so the server return Service Unavailable error.
What did you expect to see?
Working service after upgraded status and new container start.
What did you see instead?
New container not being picked up by traefik and received a Service Unavailable error when trying to navigate to the container label host.
Output of traefik version: (What version of Traefik are you using?)

I have a rancher 1.6.11 with 6 debian 9 hosts. Traefik version is v.2.0.5, started up as global container on all 6 hosts with open port 80.
CLI Flags (No TOML/YAML file is passed):
--providers.rancher=true
--providers.rancher.exposedByDefault=false
--providers.rancher.enableServiceHealthFilter=true
--providers.rancher.intervalPoll=false

Hello @maxifom,
I can not reproduce your issue. If I upgrade a service and keep it in state "upgraded", my Traefik picks up the new container IP and routing still work.
Can you please give me your service definition? When do you see the "old" container ip?
Thanks.

I dk what the issue was, but now I checked again, and everything seems to be in order, container upgraded status handled successfully.


How can i start this project?

Hello, I try to start with this project.
But I can not build this source using TrueStudio 9.2  or sw4stm32!
please help me

Hi,
What errors do you get when using SW4STM32?

The project is already changed to CubeIDE.
I've updated the README. Sorry for the confusion.

@kisvegabor Thank you! I will try to start with CubeIDE!

@kisvegabor @embeddedt
Hi I try to start project usgint CubeIDE! But I failed to start.
My working environment

windows 10 64bit
CubeIDE 1.3.0
Debug Mode

I find "Debug" configuration is missing in the CubeIDE and Release configure has Absolute path like that "-I"/home/kisvegabor/stm32_workspace_2/stm32_lvgl/inc" -I"/home/kisvegabor/stm32_workspace_2/stm32_lvgl/Utilities/STM32F429I-Discovery"" in Realease/src/subdir.mk.
I try to run this project again after change Include path!
I find 2 point of my failer

Do you have the IOC file for this?

No, we don't have an IOC file for this yet. :slightly_frowning_face:
Bt it'd be great to have one. So if you are working on it contribution would be very welcome!


Guidance for migrating from MessagePack to MemoryPack

Is there some guidance somewhere how to migrate from MessagePack to MemoryPack?
What are the functional differences and what features of MessagePack do not work in MemoryPack anymore?

No automatic migrating, etc. is provided, so please look at the respective documentation to make your decision.
If you are using MessagePack-CSharp, you probably only need to change the attribute in your type definition, since the APIs are similar.
If you are just communicating from C# type to C# type, the functionality may not be much different.
The major difference is the binary format.
MessagePack can dump data only as a primitive array or DIctionary, like JSON, and can also use other language parsers to convert to JSON.
However, MemoryPack has a limitation that it cannot parse without a C# type definition. This restriction is similar to that of protobufs.
Due to format differences, MemoryPack also does not support deserialization to dynamic types.
Also, the current MessagePack-CSharp does not seem to have a Source Generator, but it is planned for the next major version.


PSP location and CMakeLists

Just upgrading some cFS mods we make in the lab with the software bus to this cFS build, but I've been running into some new pathing issues.
Notably, in case anyone else gets hung up on it, I have some CMake fail to finds:
ln 41 in global_function.cmake reads:
get_filename_component(MISSION_SOURCE_DIR "${CMAKE_SOURCE_DIR}/cFS/cFE" ABSOLUTE)
From this repo "psp" belongs to "cFS" but, this seems problematic in arch_build.cmake ln 26
include_directories(${MISSION_SOURCE_DIR}/psp/fsw/shared)
Also: "cFE" v "cfe" as the submodule in names sometimes gets in the way

Could you add links to the code you are referring to?  I don't see it matching what's currently in the repo, where the only reference to get_filename_component in global_function.cmake in the cFE master branch is:
https://github.com/nasa/cFE/blob/99038d5446aec902e8cdbe14d762a86ea4e19e1c/cmake/global_functions.cmake#L65
It looks like there is a similar line to what you describe at:
https://github.com/nasa/cFE/blob/8811c92094512975e14fd545df355705141560b2/cmake/mission_build.cmake#L38-L41
or
https://github.com/nasa/cFE/blob/8811c92094512975e14fd545df355705141560b2/cmake/mission_build.cmake#L148-L152
but these all work fine for me.  What exactly is your issue?
Not clear what your issue with the include_directories line is?  What about this doesn't work?
Note I think your 3rd issue has already been solved, current .gitmodule lines:
https://github.com/nasa/cFS/blob/d42368f4b6a48df09d42a1a24a13609c8b325ffe/.gitmodules#L1-L4

Heya,
Sorry looking at 6.6.0 is on my todo list this week. I just had to jump
over to a few other projects before coming back around. I will let you know
how it goes!
Thanks,
Chris M.
On Fri, Aug 23, 2019, 10:25 AM skliper<EMAIL_ADDRESS>wrote:

Any updates on the issues?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/nasa/cFS/issues/5?email_source=notifications&email_token=AGZWVZDRQFHO4TGSD5RPGCLQF7XPDA5CNFSM4IK4GUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5ALVQI#issuecomment-524335809,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGZWVZEAK53DQF3R7PTKJ53QF7XPDANCNFSM4IK4GUJQ
.

Unable to recreate issue and likely against old code base.  Feel free to reopen if issue can be recreated and version information identified.


Riddler

Hello,
May i know where can i obtain riddler username?

You do that by registering at: https://riddler.io/auth/register
Your username is the email you sign up with.

it`s disabled, any other option ?!

Yes sir riddler registrartion is closed any other option?


Problems when switching to landscape and back

Our sticky list header isn't positioned correctly and leaves empty space to the right if we switch to landscape view. Anyone else having this issue and might have a possible fix?

Feel free to post screenshots/sample repo that reproduces the issue.

https://trello-attachments.s3.amazonaws.com/5561b2b593c167e25f11f7c5/1280x768/c66a758506be2c76dba63fdc6cf0d43e/Screenshot_2015-05-24-07-13-29.png  Here is the issue

Can't really visualize how its supposed to look... But if you put up a
sample repo I'll be happy to help.
On May 24, 2015 1:38 PM, "Raahul"<EMAIL_ADDRESS>wrote:

https://trello-attachments.s3.amazonaws.com/5561b2b593c167e25f11f7c5/1280x768/c66a758506be2c76dba63fdc6cf0d43e/Screenshot_2015-05-24-07-13-29.png
Here is the issue
—
Reply to this email directly or view it on GitHub
https://github.com/timehop/sticky-headers-recyclerview/issues/50#issuecomment-105046826
.

I have the same issue, it doesn't adjust layouts when the orientation changes and it also doesn't switch layouts if there different resource folders/files for orientation changes

Sample repo please!
On May 26, 2015 5:56 PM, "ericlw"<EMAIL_ADDRESS>wrote:

I have the same issue, it doesn't adjust layouts when the orientation
changes and it also doesn't switch layouts if there different resource
folders/files for orientation changes
—
Reply to this email directly or view it on GitHub
https://github.com/timehop/sticky-headers-recyclerview/issues/50#issuecomment-105706393
.

example https://dl.dropboxusercontent.com/u/27608349/stickyheadersglitch.jpg
On the left is desired behavior, in original orientation, on the right is the second orientation, with the overwritten headers.
This applies if you start in landscape and switch to portrait as well.

Is this still an issue? If so, please fork the sample project and modify it so the issue can be reproduced or create a test that fails and we'll fix it.

you can add this to your project to fix it
@Override
public void onConfigurationChanged(Configuration newConfig) {
super.onConfigurationChanged(newConfig);
mRoot.post(new Runnable() {
@Override
public void run() {
mStickyRecyclerHeadersDecoration.invalidateHeaders();
}
});
}

I solved the issue by adding a delay for the invalidateHeaders() method,
headersDecoration = new StickyRecyclerHeadersDecoration(myRecyclerAdapter);

...

 myRecyclerAdapter.registerAdapterDataObserver(new RecyclerView.AdapterDataObserver() {
            @Override
            public void onChanged() {
                headersRunnable.run();
            }
        });

and
Runnable headersRunnable = new Runnable() {
        @Override
        public void run() {
            mRecyclerView.postDelayed(this, 100);
            headersDecoration.invalidateHeaders();
        }
    };

@lolevsky thats very interesting. Im having a similar issue in the app im working on. unfortunately we are not working with sticky-headers-recyclerview but with the deprecated https://github.com/eowise/recyclerview-stickyheaders.

@amylinn Thanks for posting this!

@amylinn @lolevsky
Create:
    private Handler handler = new Handler();

Adapter:
        this.adapter.registerAdapterDataObserver(new AdapterDataObserver() {
            @Override
            public void onChanged() {
                handler.post(new HeaderFixRunnable(recyclerView, headersDecor));
            }
        });

Runnable:
    private static final class HeaderFixRunnable implements Runnable {

        private final WeakReference<RecyclerView> recyclerViewWeakReference;
        private final WeakReference<StickyRecyclerHeadersDecoration> headersDecorWeakReference;

        public HeaderFixRunnable(final RecyclerView recyclerView, final StickyRecyclerHeadersDecoration headersDecor) {
            this.recyclerViewWeakReference = new WeakReference<>(recyclerView);
            this.headersDecorWeakReference = new WeakReference<>(headersDecor);
        }

        @Override
        public void run() {
            final RecyclerView recyclerView = this.recyclerViewWeakReference.get();
            final StickyRecyclerHeadersDecoration headersDecor = this.headersDecorWeakReference.get();
            if (recyclerView != null && headersDecor != null) {
                recyclerView.postDelayed(this, DRAW_DELAY);
                headersDecor.invalidateHeaders();
            }
        }
    }

Destroy:
    @Override
    public void onDestroyView() {
        this.handler.removeCallbacksAndMessages(null);

        super.onDestroyView();
    }

Based off: https://techblog.badoo.com/blog/2014/08/28/android-handler-memory-leaks/