Re: Automation & Systematization sprint in Berlin in late April

2024-02-29 Thread Nate Graham
Quick update on this. the dates are now locked in, but we're still 
finalizing a venue in Berlin. More information will be provided as it 
becomes available.


Thanks for your patience here, everyone!

Nate




On 1/31/24 16:26, Nate Graham wrote:

Hello folks!

I'd like to gauge interest in an in-person sprint supporting the 
Automation & Systematization goal. Right now we are targeting Berlin on 
April 19th - April 24th. KDE e.V. has budget available to help with 
travel and lodging costs.


This will be a triple-threat sprint, with the Accessibility and 
Sustainability sprints co-located. People interested in multiple topics 
will be able to jump between them if they want.


Topics for the Automation & Systematization sprint might include:
- Writing tests
- Fixing failing tests
- Making tests mandatory to pass
- Documenting how to write good tests
- Updating outdated documentation
- Transition documentation to code (e.g. making kdesrc-build or the new 
kde-builder tool do more itself, so we don't have to write so much about 
it in our documentation)

- Make a push for enabling clang-format for more repos
- Make a push to put release notes in AppStream metadata
- Improve our AppStream CI job to require or recommend more things
- Make a CI job to enforce as much of the onboarding/new repo checklist 
as possible, and make enabling it be a part of the process


These are just ideas; the folks who attend will be the ones who guide 
the agenda.


Let me know if you're interested so I can get a sense of the level of 
attendance!



Nate


Re: APIs for persistent remote access and headless/hybrid sessions

2024-02-29 Thread Erik Jensen
> We are definitely interested in working in this area. We have a lot of
> the proposed core infrastructure that's listed in that proposed
> specification; pipewire, creation of virtual screens, libei access is
> coming soon. It's "just" a case of gluing everything together.

That's great to hear!

> The current portal API is expanding with a concept of tokens to allow
> creation of streams without user prompts and access. I was hoping this
> would suffice if it was coupled with some mechanism to get these
> tokens ahead of time?

That should work as long as there is a mechanism to provision the
tokens in an automated fashion that grants access to virtual monitor
configuration and clipboard in addition to capture and input
injection. (One of our use cases is being able to set up CRD during
the automated provisioning process for a VM, so the user can connect
immediately after provisioning.) Indeed, since our remote assistance
flow will be using the Portal APIs in any event, having less
divergence would not be unwelcome. (The proposed dedicated API still
uses PipeWire and libei, though, so it wouldn't be a big deal either
way.)

I could imagine a flow that looks like the following:
 * The remote desktop tool connects to the login manager on the system
bus using some TBD API.
 * The two negotiate an authentication method. (Graphical greeter,
username & password, PAM conversation, Kerberos, et cetera.)
 * If a graphical greeter is negotiated, a token is provided to the
remote desktop tool to connect to it. (How? Is an implementation of
the needed portal interfaces provided by the greeter on the system
DBUS, protected by the token?)
 * When the user logs in, a shared token is passed to the desktop
environment that is being started in or transitioned to headless mode.
 * The login manager provides the remote desktop tool with the token
and some kind of handle to the resulting session.
 * The remote desktop tool spins up a process running as the target
user, which uses the token to connect to the compositor via the Portal
APIs on the user bus.
 * The remote desktop tool hands off the connection from the system
process to the new user process.

(Note that I'm not 100% on how everything works, so apologies if any
aspects of that don't make sense.)

That said, there are enough differences between the current Portal API
use case and what is wanted by a persistent remote access tool that I
can definitely see the argument for a separate API like that proposed
by Jonas Ã…dahl. E.g., having methods to modify the monitory layout in
the Portal API that are in practice only used via persistent remote
access tools via a token and which users would rarely, if ever, want
to grant via the UI to ephemeral remote assistance tools feels weird.
Having a separate API that's only available in headless mode would
also help persistent remote access tools ensure that the connection
wasn't visible from the local workstation.

> Does Chrome Remote Desktop provide the server part that runs on the
> client computer? Or is it using some network API to connect to talk to
> the existing gnome/kde remote-desktop server?

Chrome Remote Desktop provides its own server components. It uses
WebRTC to establish a direct peer-to-peer connection between the
process running on the host machine (the machine being remotely
accessed) and a web-based client running in the user's web browser on
the client machine.


Re: APIs for persistent remote access and headless/hybrid sessions

2024-02-29 Thread David Edmundson
Hello,

Thanks for reaching out and keeping us in the loop. It's better now
than after something has been implemented.

We are definitely interested in working in this area. We have a lot of
the proposed core infrastructure that's listed in that proposed
specification; pipewire, creation of virtual screens, libei access is
coming soon. It's "just" a case of gluing everything together.

The current portal API is expanding with a concept of tokens to allow
creation of streams without user prompts and access. I was hoping this
would suffice if it was coupled with some mechanism to get these
tokens ahead of time?

Does Chrome Remote Desktop provide the server part that runs on the
client computer? Or is it using some network API to connect to talk to
the existing gnome/kde remote-desktop server?

David


KDIff3 Craft CI for MacOS broken

2024-02-29 Thread Michael Reeves
Does anyone have insight as to why this is happeing:


/Resources/qml/org/kde/i18n/localeData/libki18nlocaledataqmlplugin.dylib']
succeeded with exit code 0
Library dependency
'/Users/gitlab/ws/builds/GZwHuM5x/0/sdk/kdiff3/macos-arm-clang/build/extragear/kdiff3/archive/Applications/KDE/kdiff3.app/Contents/Frameworks/libKF6I18nLocaleData.6.dylib'
does not exist
/Users/gitlab/ws/builds/GZwHuM5x/0/sdk/kdiff3/macos-arm-clang/build/extragear/kdiff3/archive/Applications/KDE/kdiff3.app/Contents/Resources/qml/org/kde/i18n/localeData/libki18nlocaledataqmlplugin.dylib:
Failed to add library dependency
'/Users/gitlab/ws/builds/GZwHuM5x/0/sdk/kdiff3/macos-arm-clang/build/extragear/kdiff3/archive/Applications/KDE/kdiff3.app/Contents/Frameworks/libKF6I18nLocaleData.6.dylib'
into bundle
Action: package for extragear/kdiff3:1.11 FAILED