juil. 10 18:39:18 apple gnome-remote-desktop-daemon[16112]: [18:39:18:988] [16112:000458c4] [WARN][com.freerdp.core.server] - [WTSReceiveChannelData]: unknown channelId 1006 ignored
juil. 10 18:39:30 apple xdg-desktop-por[286207]: Failed to create secret proxy: Erreur lors de l’appel de StartServiceByName pour org.freedesktop.secrets : Le délai d’attente est dépassé
juil. 10 18:39:30 apple xdg-desktop-por[286207]: No skeleton to export
juil. 10 18:39:30 apple /usr/libexec/gdm-wayland-session[286294]: discover_other_daemon: 1
juil. 10 18:39:30 apple /usr/libexec/gdm-wayland-session[285777]: dbus-daemon[285777]: [session uid=114 pid=285777 pidfd=5] Successfully activated service 'org.freedesktop.portal.Desktop'
juil. 10 18:39:34 apple gnome-remote-de[16112]: [DaemonSystem] Aborting handover, removing remote client with remote id /org/gnome/RemoteDesktop/Client/972001666
juil. 10 18:39:34 apple gnome-remote-desktop-daemon[16112]: [18:39:34:766] [16112:00003ef0] [ERROR][com.freerdp.core.peer] - [rdp_set_error_info]: ERRINFO_CB_CONNECTION_CANCELLED [0x00010409]
juil. 10 18:39:35 apple systemd[1]: systemd-localed.service: Deactivated successfully.
juil. 10 18:39:35 apple systemd[1]: systemd-hostnamed.service: Deactivated successfully.

Control: tags -1 + moreinfo

x-d-p tried to contact your implementation of the
org.freedesktop.secrets D-Bus interface (normally gnome-keyring or
KWallet), but didn't receive a reply to that request. x-d-p cannot solve
this: it will need to be fixed in either the implementation of
org.freedesktop.secrets, or some sort of desktop session infrastructure
around it.

What implementation of org.freedesktop.secrets did you expect it to be
using? This bug should be reassigned to whatever that implementation is.

Please describe the desktop environment you are using and how it is set
up, and please check the systemd Journal for messages regarding startup
of org.freedesktop.secrets, gnome-keyring or KWallet. They are likely to
appear in the period between 18:38:00 and 18:39:30 (perhaps earlier than
the part you quoted).

     smcv

Le 10/07/2025 à 19:58, Simon McVittie a écrit :

gnome-keyring

dh@apple ~ $ ls -l /etc/xdg/autostart/gnome*
-rw-r--r-- 1 root root 8877 20 mars  15:18 
/etc/xdg/autostart/gnome-keyring-pkcs11.desktop
-rw-r--r-- 1 root root 8341 20 mars  15:18 
/etc/xdg/autostart/gnome-keyring-secrets.desktop
-rw-r--r-- 1 root root 6825 20 mars  15:18 
/etc/xdg/autostart/gnome-keyring-ssh.desktop

gnome+wayland aside of cinnamon

apt install task-gnome-desktop

journalctl | grep gnome-keyring

juil. 10 17:41:26 apple systemd[2924]: Listening on
gnome-keyring-daemon.socket - GNOME Keyring daemon.
juil. 10 17:41:26 apple systemd[2924]: Started
gnome-keyring-daemon.service - GNOME Keyring daemon.
juil. 10 17:41:26 apple gnome-keyring-daemon[2975]:
GNOME_KEYRING_CONTROL=/run/user/1000/keyring
juil. 10 17:41:26 apple gnome-keyring-daemon[2975]: The Secret Service
was already initialized
juil. 10 17:41:26 apple gnome-keyring-daemon[3115]:
discover_other_daemon: 1
juil. 10 17:41:26 apple gnome-keyring-secrets.desktop[3115]:
discover_other_daemon: 1GNOME_KEYRING_CONTROL=/run/user/1000/keyring
juil. 10 17:41:26 apple gnome-keyring-d[2975]: The Secret Service was
already initialized
juil. 10 17:41:26 apple gnome-keyring-daemon[2975]: The PKCS#11
component was already initialized
juil. 10 17:41:26 apple gnome-keyring-d[2975]: The PKCS#11 component was
already initialized
juil. 10 17:41:26 apple gnome-keyring-daemon[3117]:
discover_other_daemon: 1
juil. 10 17:41:26 apple gnome-keyring-pkcs11.desktop[3117]:
discover_other_daemon: 1GNOME_KEYRING_CONTROL=/run/user/1000/keyring
juil. 10 17:41:26 apple gnome-keyring-daemon[3119]:
discover_other_daemon: 1
juil. 10 17:41:26 apple gnome-keyring-ssh.desktop[3119]:
discover_other_daemon: 1GNOME_KEYRING_CONTROL=/run/user/1000/keyring
juil. 10 17:41:26 apple gnome-keyring-ssh.desktop[3119]:
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
juil. 10 17:46:53 apple systemd[31544]: Listening on
gnome-keyring-daemon.socket - GNOME Keyring daemon.
juil. 10 17:46:54 apple systemd[31544]: Started
gnome-keyring-daemon.service - GNOME Keyring daemon.
juil. 10 17:46:54 apple gnome-keyring-daemon[32163]:
GNOME_KEYRING_CONTROL=/run/user/114/keyring
juil. 10 17:46:54 apple gnome-keyring-daemon[32163]: The Secret Service
was already initialized
juil. 10 17:46:54 apple gnome-keyring-daemon[32162]:
discover_other_daemon: 1
juil. 10 17:46:54 apple gnome-keyring-d[32163]: The Secret Service was
already initialized
juil. 10 17:51:54 apple gnome-keyring-daemon[32163]: The Secret Service
was already initialized
juil. 10 17:51:54 apple gnome-keyring-d[32163]: The Secret Service was
already initialized
juil. 10 17:51:54 apple gnome-keyring-daemon[57216]:
discover_other_daemon: 1
juil. 10 18:39:05 apple gnome-keyring-daemon[32163]: The Secret Service
was already initialized
juil. 10 18:39:05 apple gnome-keyring-daemon[286294]:
discover_other_daemon: 1
juil. 10 18:39:05 apple gnome-keyring-d[32163]: The Secret Service was
already initialized

journalctl |grep org.freedesktop.secrets

When I run systemctl --user --all I don't see any
org.freedesktop.secrets, seems normal as it should be activated by dbus

Thanks for taking care to this problem

Control: reassign -1 gnome-keyring

Reassigning to gnome-keyring for further investigation, then.

What does "gnome+wayland aside of cinnamon" mean? Do you mean that you
have both GNOME and Cinnamon installed, and you are logging in to a
GNOME (Wayland) session?

Please describe the system in sufficient detail that a developer would
be able to set up an equivalent system themselves.

grep for gnome-keyring is not sufficient, there could be other relevant
messages related to it that do not contain the word "gnome-keyring".

We will need to see all messages from systemd and/or dbus-daemon that
relate to GNOME Keyring - those messages might not mention the word
"gnome-keyring", they might describe it as "GNOME Keyring" or "Secret
Service" or some other term. Please quote the whole section of the
Journal while the system is trying to start gnome-keyring for you. You
can censor messages that contain private information or are clearly
irrelevant, but please indicate where you have done so.

If you are not in the adm group, you will need to run journalctl as
root to be able to see everything.

     smcv

Le 11/07/2025 à 13:59, Simon McVittie a écrit :
Exactly
I did it in reportbug. I'ts Linux Asahi Trixie system

Attached are the hole logs from boot time until after the timeout occurs
which is around 1 hour logs

Thanks for your support

What I should have asked at the beginning is:

Is there a user-visible symptom that you are reporting, like some
program crashing or taking a long time to start, that is in some way
related to the warning you have quoted?

Or can your bug report be summarized as "there is a warning in the
system log, and I don't think there should be any warnings at all"?

This is the special mini-session that is used for the gdm "greeter"
(login prompt), not part of a user's login session. It is normal that
this mini-session has limited functionality, and I would not expect
either gnome-keyring or xdg-desktop-portal to be usefully active in that
session.

(Perhaps that session should prevent these services from running at all.)

     smcv

Le 11/07/2025 à 16:11, Simon McVittie a écrit :
That's the logs I get when I try to connect to gnome-remote-desktop. On
the client I'm asked to enter user, password and domain, once done I get
a blank screen and those logs appear on the server. Client software was
gnome-connections or remmina an MBA M1 running as well Asahi Linux, same
result with remmina from a 22.04 Ubuntu client.
As user I'm UID 1000 connected to the GUI and 114 is the one from
gdm-wayland-session

Control: retitle -1 gnome-remote-desktop: blank screen after connecting to Mac Mini M2
Control: reassign -1 gnome-remote-desktop
Control: affects -1 + asahi-platform
Control: severity -1 normal
with gnome-remote-desktop and the result is a blank screen", please
start with that. Package maintainers cannot know that you are using
gnome-remote-desktop unless you tell us!

Please try upgrading to the remote desktop server to
gnome-remote-desktop 48.1-4 (currently in unstable but not in testing)
which is known to fix a bad interaction with newer versions of Mesa,
then reboot the remote desktop server and try connecting to it again.

If that is not successful, please describe the steps to reproduce the
problem you are seeing, without assuming that the package maintainers
know everything about your computer. You must have done some
configuration to make your computer offer remote desktop access -
please describe how you achieved that. The reason I ask for this is
that there is more than one way to use gnome-remote-desktop.

Remote-controlling a GNOME system with gnome-remote-desktop is not the
typical configuration: the typical configuration is to plug in a screen
and keyboard, and use it locally. You also seem to be using
gnome-remote-desktop in a less-common way where you are creating a
"headless" UI session, rather than sharing an existing GUI session.

If you are reporting a bug and you want it to be solvable, please always
start with:

- what you did (how you configured the system), and especially anything
   that you did that is unusual, like:
     - installing on Apple hardware using an unofficial version of Debian;
     - using gnome-remote-desktop rather than a locally connected screen
       and keyboard
- what you expected to happen
- what actually happened

The warning message logged by xdg-desktop-portal does not necessarily
have anything to do with you seeing a blank screen. It is potentially
useful information, but also potentially misleading, so we should start
by getting the full facts.

So let's start again: if you had provided that information at the
beginning, what would you have said?

Also please note that the "Bananas" port for Apple M1/M2 hardware is not
an official part of Debian, and relies on components that are not part
of Debian. I don't know how much of it is expected to work, and probably
some of it is known not to be ready at the moment. If you are not
already an experienced Debian user, I would recommend trying it on x86
hardware (like an old laptop) first.

Because gnome-remote-desktop interacts with video rendering, it is
dependent on the unofficial kernel and Mesa graphics stack provided by
"Bananas", which is not part of Debian.

Other log messages that could be particularly relevant include:
...

(note for cc'd maintainers: there is a more full log in a previous
message on the bug)

     smcv

Le 11/07/2025 à 17:56, Simon McVittie a écrit :
If you read carefully the logs I sended at the time I opened this bug,
g-r-d is clearly mentioned as well as the linux kernel version
indicating asahi

This after trying remmina from Ubuntu 24.04.

dh@apple ~ $ systemctl status gnome-remote-desktop
● gnome-remote-desktop.service - GNOME Remote Desktop
      Loaded: loaded
(/usr/lib/systemd/system/gnome-remote-desktop.service; enabled; preset:
enabled)
      Active: active (running) since Fri 2025-07-11 18:16:49 CEST; 7min ago
  Invocation: 80894c50e6d846c49cdab9a709139bf6
    Main PID: 810 (gnome-remote-de)
       Tasks: 4 (limit: 4508)
      Memory: 40M (peak: 45.6M)
         CPU: 42ms
      CGroup: /system.slice/gnome-remote-desktop.service
              └─810 /usr/libexec/gnome-remote-desktop-daemon --system

juil. 11 18:16:48 apple systemd[1]: Starting
gnome-remote-desktop.service - GNOME Remote Desktop...
juil. 11 18:16:49 apple gnome-remote-de[810]: Init TPM credentials
failed because No TPM device found, using GKeyFile as fallback
juil. 11 18:16:49 apple systemd[1]: Started gnome-remote-desktop.service
- GNOME Remote Desktop.
juil. 11 18:17:04 apple gnome-remote-de[810]: RDP server started
juil. 11 18:17:45 apple gnome-remote-de[810]: [RDP] Client did not
advertise support for the Graphics Pipeline, closing connection
juil. 11 18:17:45 apple gnome-remote-de[810]: [RDP] Network or
intentional disconnect, stopping session
juil. 11 18:17:45 apple gnome-remote-desktop-daemon[810]: [18:17:45:387]
[810:00001e20] [ERROR][com.freerdp.api] -
[rdp_peer_handle_state_demand_active]:
[CONNECTION_STATE_CAPABILITIES_EXCHANGE_DEMAND_ACTIVE]
freerdp_peer::Capabilities() callback failed
juil. 11 18:17:45 apple gnome-remote-desktop-daemon[810]: [18:17:45:387]
[810:00001e20] [ERROR][com.freerdp.core.transport] -
[transport_check_fds]: transport_check_fds: transport->ReceiveCallback()
- STATE_RUN_FAILED [-1]

Test trom MBA M1 under Trixie Asahi Linux ask me to enter credentials
and then got a blankscreen. Attached you will fing logs from this second
attempt.

install xtask-cinnamon-desktop
tried X11vnc wich was working

Now knowing that trixie is Wayland only, I installed gnome
install xtask-gnome-desktop

 From here nothing more that trying to connect from 2 others notebook in
RDP knowing that Debian removed VNC from g-r-d
I tried wayvnc+wayfire and could not get it work, always getting "wayvnc
virtual pointer protocol not supported by compositor"
Sure. On this computer I installed X11Vnc, Meshcentral and Rustdesk, all
running well under X11. Rustdesk is running also under Wayland
If you tell it, I believe you. I didn't do anything more that the steps
above as far as I remember.
Trying to use g-r-d finish with a blank screen on the client and those
are the logs I see (those sended on original message)

I use Asahi/Linux Debian on an MBA M1 since 2 and  a half year, was
under bookworm at first, now Ttrixie. If you check actual stand of
bananas, a debian-installer is existing. I'm connected to the team via
#debian-bananas and doing some tests -I'm not the only one- for them. So
no, will not change to x86-hardware. Anyway, I write this message and
all others before with a Dell XPS 13 7390 Ubuntu 24.04

If you really fill that this case shouldn't be, feel free to close this
bug, I can live with.

Thanks for your help

To clarify, a monitor, keyboard and mouse are connected to the mini M2

Hi all.

I'll get to this bug when I find some time to see if there's any
indication that it affects our port and not parts of the stack which are
in Debian. Until then please note that

no, we don't have a debian-installer. In the context of reporting bugs
to Debian proper, e.g. by using the BTS, there is one and only
debian-installer, and that does not support Apple Silicon. The Bananas
Team has *an* installer, which is not the debian-installer, that uses
custom packages, including the kernel, to install Debian on Apple
machines. For more details see [1].

Will get back to this,

Cheers (for now)

[1] https://lists.debian.org/debian-devel/2025/06/msg00241.html

Hi all,

I'm afraid I can't reproduce this bug on an M1 Mac Mini and on an M1 Pro
MacBookPro. Using the same kernel and mesa drivers as the submitter, I
successfully started gnome-remote-desktop (48.1-2) on both, connected from the
other using both remmina and gnome-connections and controlled the desktop
remotely. Both systems run GNOME 48. The only time I saw a blank screen was
when the server was sleeping.

This doesn't exclude something may be off with M2s, but I have no indication
currently that M2s should have different behavior. I'll ask someone from the
Team with an M2 to check this out.


Cheers!

After a re-installation from scratch problem disappear, g-r-d is working.

Seems that apt install task-gnome-desktop don't do the complete job.

Le 11/07/2025 à 17:56, Simon McVittie a écrit :

Control: affects -1 - asahi-platform
is missing when installing gnome via task-gnome-desktop.


P.S.: Simon, in the future feel free to tell our users to get in touch
with us directly if you think a bug may only affect our port. I don't
want to bother you with the details, but we have our own non-BTS bug
trackers four our out-of-archive packages. asahi-platform only tracks
packages in Debian proper, we're not using it as a catch-all
pseudo-package. But of course, if you nonetheless need to catch our eye
I understand it and will not be offended :-) Thanks for all the work!