> No, just some kind of ABI thing, but I doubt xrdp upstream already
> even guarantees stable ABIs for 0.x releases.
We xrdp team already have already started effort for ABI stability but
could not strictly guarantee yet. It is almost stable since July 2021
however, we haven't started taking care
Hi, xrdp developer and FreeBSD package maintainer here.
As far as I looked xrdp & xorg package, xorgxrdp package is the issue.
Update xorgxrdp to the latest 0.9.19 and build against xrdp 0.9.21.1.
The it should work. When updating xrdp package in furure, to 0.9.23 for
example, also update
I think you'll need some more information. v0.9.7, v0.9.8, v0.9.9 have
this bug. The upcoming v0.9.10 includes this fix. I know Debian hardly
apply version update except unstable so I want you to consider applying
this fix to the branches such as stable-bpo. The original issue #1315 is
reported by
Package: xrdp
Version: 0.9.9-1
Severity: normal
Tags: patch upstream
Hi,
I'm a xrdp upstream developer. A debian user reported a issue to we
upstream [1]. The issue is new session doesn't start correctly after
sesman got SIGUP due to sesman bug.
When sesman got SIGHUP, sesman reloads config
Well, the third and only correct solution would be xrdp getting its own
mechanism for dropping prvileges, so it could read the key as root and
then drop to the xrdp user.
You have a point. Running daemon under user privilege is a good practice
if root privilege is actually unnecessary. xrdp
Hi Jacco, Dominik, and other maintainers,
I am an upstream xrdp developer. I also encountered this issue.
If my issue and your issue is same, probably the reason you can't connect is
certificate's private key is not accessible byxrdp daemon. Please check your
private key permission.
In Debian,
6 matches
Mail list logo
