There is 1 open security issue in sid.
There is 1 open security issue in forky.
commit eab4f02ca72631b5277807c8cd1f14adfe6428fd
Author: Charles <charles05@canonical.com>
Date: Thu Jul 2 17:24:50 2026 +0100
changelog
commit 42c7bcb99161e7bef2a39b273d53a47c857399ef
Author: Charles <charles05@canonical.com>
Date: Thu Jul 2 17:30:13 2026 +0100
d/p: refresh
commit 7bfc365cb2ecb22ce03151cd175b9bb5516d1d89
Author: Charles <charles05@canonical.com>
Date: Thu Jul 2 17:29:54 2026 +0100
d/p/freerdp-3.25.patch: included upstream
commit fda356d6cce6dc2afda471a07050bb97cb8f1dd4
Merge: 465a2ae 964ebdb
Author: Charles <charles05@canonical.com>
Date: Thu Jul 2 17:24:50 2026 +0100
Update upstream source from tag 'upstream/50.2'
Update to upstream version '50.2'
with Debian dir e0f90fbe98e7ea40755b3f8e72fedf6b99ee6862
commit 964ebdbe7b780e3681dfcfdf493837e5da3c834c
Merge: 70d464f 60423c8
Author: Charles <charles05@canonical.com>
Date: Thu Jul 2 17:24:48 2026 +0100
New upstream version 50.2
commit 60423c896a54e3eacb65bd93167e91c1ce5e648c
Author: Jonas Ådahl <jadahl@gmail.com>
Date: Tue Jun 30 17:22:57 2026 +0200
build: Bump version to 50.2
Part-of: <https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/403>
commit 6e69457def51bcf0d5777503c341ff74bb2f1a07
Author: Jonas Ådahl <jadahl@gmail.com>
Date: Tue Jun 30 17:22:52 2026 +0200
Update NEWS
Part-of: <https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/403>
commit ad386844bad2e5316046505e2788fdf4090dca34
Author: Jonas Ådahl <jadahl@gmail.com>
Date: Tue Jun 30 17:22:15 2026 +0200
Revert "daemon-system: Simplify remote display reconnection handling"
This was not meant for GNOME 50.
This reverts commit 5230bf33fba09394a201b0acc114715b4da6c054.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/403>
commit 3e6cd009626ec0ae4c185235335da0effce4ca1e
Author: Jonas Ådahl <jadahl@gmail.com>
Date: Thu Jun 25 14:05:51 2026 +0200
throttler: Replace connecting to notify::closed to qdata callback
Using the notify::closed signal was insufficient since it was not
implicitly signalled when the socket was closed due to the last
reference to the object was released, meaning one needed to manually
emit it when appropriate. Replace this by storing enough state in the
already used qdata data bank to allow us to do the equivalent cleanup
when the socket is freed, which should be the same time that it is
closed in our case.
Closes: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/work_items/332
Part-of: <https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/402>
(cherry picked from commit ecd871dd679e3b68e79cd857aa32a04df1aec8ff)
commit 715e546be0b787bea8fe28cf270ac1cfd5171780
Author: Jonas Ådahl <jadahl@gmail.com>
Date: Thu Jun 25 22:27:27 2026 +0200
throttler: Add 'namespace' to throttler debug output
This makes it easier to grep.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/402>
(cherry picked from commit abbae36f89f600bd86289bb9c3bc884a846b21e0)
commit c14e09ef67e916ae83a4eddee6a56591078e78e0
Author: Victoria Niedzielska <victorian@gnome.org>
Date: Tue Jun 23 19:53:21 2026 +0000
Update Polish translation
commit c40b18b7cf7f4af59824f9db8f111d90a712056f
Author: Victoria Niedzielska <victorian@gnome.org>
Date: Tue Jun 23 19:30:03 2026 +0000
Update Polish translation
commit 12fb188a44f2e8301b8b5c2ad532bce96bd3a8c9
Author: Pascal Nowack <Pascal.Nowack@gmx.de>
Date: Tue Jun 2 07:51:13 2026 +0200
Revert "vk-device: Add API to get driver id"
This API is no longer needed.
This reverts commit ff77d66e034d504d43f1554913d88d5804abfbb4.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/401>
commit cf250ed00b2647f1fa263dd217ef1e80bca88487
Author: Pascal Nowack <Pascal.Nowack@gmx.de>
Date: Sat May 30 14:31:37 2026 +0200
Revert "rdp-render-context: Disable VA-API when using an AMD GPU"
The underlying issue that VA-API encoding did not work with AMD GPUs was
now finally found: The main issue was not on the mesa side, but inside
gnome-remote-desktop. gnome-remote-desktop did not concatenate all
bitstream segments together, but that is needed with the AMD driver, as
with AMD, each NALU has its own separate segments inside the output
buffer. With the Intel driver, this was not needed, as the Intel driver
put the whole bitstream into one segment.
Since VA-API does now work on AMD GPUs too, simply allow VA-API with AMD
GPUs again.
This reverts commit 3df6384a73c6aa3a76ffc382e6e74b2afc14284a.
See also: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/work_items/331
Part-of: <https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/401>
commit 6aa55031d1d0b48a6f28e37dacda63e98ea7058b
Author: Pascal Nowack <Pascal.Nowack@gmx.de>
Date: Sat May 30 14:35:19 2026 +0200
encode-session-vaapi: Concatenate bitstream segments when needed
While the Intel driver uses just one segment in the allocated output
buffer for the bitstream, the AMD driver does not. Instead, the AMD
driver divides the output buffer into multiple segments, each having
just one NAL unit. This is a problem for gnome-remote-desktop, as
gnome-remote-desktop tries to avoid buffer copies as much as possible,
as such copies take some time.
FreeRDP specifically requires one large chunk for the bitstream. For the
H.264 bitstream encoded with VA-API, gnome-remote-desktop tried so far
to refer to the mapped VA-API output buffer. But with the AMD driver
this is not possible, as only one piece (here: one of the NAL units) is
just in the first segment of the output buffer. The result is a
submitted bitstream, which cannot be fully decoded by the client.
To fix this issue, use the previously allocated dedicated bitstream
buffers to copy all bitstream segments into that one large buffer. This
large buffer is then used as the base for the bitstream submitted to the
client. As allocating such large buffers takes time, just acquire one
already allocated buffer instead of allocating such one large buffer for
every frame again and again. Since the contents of the mapped output
buffer may be cached, the copy operation is usually fast.
Closes: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/work_items/331
Part-of: <https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/401>
commit 7b419d2ab69b4522c76fa83b7d5747ead441e5c6
Author: Pascal Nowack <Pascal.Nowack@gmx.de>
Date: Tue Jun 2 06:30:14 2026 +0200
encode-session-vaapi: Allocate dedicated bitstream buffers for stream
The current architecture of the VA-API encode session assumes that the
bitstream buffer just contains one large chunk, as the underlying memory
was allocated in one piece too.
However, the driver may split that memory chunk internally into multiple
segments. This means, gnome-remote-desktop needs to recombine those
segments again when retrieving the bitstream. To be able to do that,
allocate multiple dedicated bitstream buffers for the stream. These will
be used in the next commit to actually recombine those segments.
Allocating such large buffers takes a significant amount of time, so do
that just once.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/401>
commit 69a95818d2744efdea6184a2fa969bb74d859f62
Author: Pascal Nowack <Pascal.Nowack@gmx.de>
Date: Sat May 30 16:00:22 2026 +0200
vk-image: Use dedicated allocation when preferred or required
When importing a dma-buf image, the Vulkan driver may prefer or even
require the VkImage to have a dedicated allocation. Reason for this is
usually better performance. To determine whether gnome-remote-desktop is
hitting such a case, use the VK_KHR_dedicated_allocation extension,
which is a core part of Vulkan 1.1 (and later).
Then, when hitting that case, simply add a VkMemoryDedicatedAllocateInfo
instance to the pNext chain of the vkAllocateMemory instance. mutter can
still change the contents when the image was already imported in
gnome-remote-desktop, so this change does not break existing behaviour.
This issue was reported by the Vulkan Validation layers when importing a
1280x720 sized BGRX dma-buf image on an AMD iGPU.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/401>
commit 2afaced792b91874eb71dc0d0338d295f844601c
Author: Pascal Nowack <Pascal.Nowack@gmx.de>
Date: Sun May 10 19:14:08 2026 +0200
build: Add support for FreeRDP 3.25.0
FreeRDP 3.25.0 introduced an API break on the client side, requiring the
test client to exchange the old authenticate callback with a revised
version. Since it is not possible to increase dependencies on the stable
branch, simply check the installed FreeRDP version at build time and use
the correct API depending on it.
As the API change only affects the test client, it should not matter if
a distribution decides to update FreeRDP to 3.25 or later when
gnome-remote-desktop was already built.
Closes: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/work_items/326
Part-of: <https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/401>
commit 5230bf33fba09394a201b0acc114715b4da6c054
Author: Joan Torres Lopez <joantolo@redhat.com>
Date: Mon May 25 17:22:34 2026 +0200
daemon-system: Simplify remote display reconnection handling
Remove the SetRemoteId API method and the logic that attempted to
keep our internal remote_id in sync with RemoteDisplays created by
external tools.
Instead of calling SetRemoteId on "foreign" RemoteDisplays, we
generate a dummy remote_id locally when a RemoteDisplay doesn't have
one. This dummy ID allows us to store the remote client in the hash
table and listen when "remote-id" is updated. A valid remoteClient
will be used once a valid remoteId is updated in GDM during remote
login.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/400>
commit 9b43b230865f2874cbe783a4a30bb0a45af0f6b4
Author: Christian Kirbach <christian.kirbach@gmail.com>
Date: Fri May 22 21:16:17 2026 +0000
Update German translation
commit b4dce06181139420ce9970a0f9d17682d621de57
Author: Flynn Peck <cirilla@tuta.io>
Date: Fri May 22 21:02:53 2026 +0000
Update Cornish translation
commit 10bbece7067de3370abc2cb1449b6a02ba02586e
Author: Antonio Marin <gnmer.6qxyg@slmail.me>
Date: Thu May 21 22:32:52 2026 +0000
Update Romanian translation
commit 4d0c12681f08986fa73475a33b3239a488989c73
Author: Vasil Pupkin <3abac@3a.by>
Date: Thu May 14 15:24:57 2026 +0000
Update Belarusian translation
commit 7ed3218a72e8f3cc22dc088516fd981947dbd613
Author: Danial Behzadi <dani.behzi@ubuntu.com>
Date: Fri May 1 10:49:42 2026 +0000
Update Persian translation
commit ac549feeaee573b1ba5350f991c2cffec6e85bd9
Author: Jose Riha <jose1711@gmail.com>
Date: Sun Apr 26 20:18:23 2026 +0000
Update Slovak translation
commit 9f1fa54d2cb7f05babc4f66b324b250dd7d21f34
Author: Nathan Follens <nfollens@gnome.org>
Date: Sun Apr 19 22:39:07 2026 +0000
Update Dutch translation
There is 1 open security issue in trixie.
You can find information about how to handle this issue in the security team's documentation.
There is 1 open security issue in bookworm.
You can find information about how to handle this issue in the security team's documentation.
Automatic checks made by the Debian l10n team found some issues with the translations contained in this package. You should check the l10n status report for more information.
Issues can be things such as missing translations, problematic translated strings, outdated PO files, unknown languages, etc.