| 2021-05-27 07:59:23 |
bugproxy |
bug |
|
|
added bug |
| 2021-05-27 07:59:26 |
bugproxy |
tags |
|
architecture-s39064 bugnameltc-192826 severity-medium targetmilestone-inin--- |
|
| 2021-05-27 07:59:27 |
bugproxy |
ubuntu: assignee |
|
Skipper Bug Screeners (skipper-screen-team) |
|
| 2021-05-27 07:59:31 |
bugproxy |
affects |
ubuntu |
linux (Ubuntu) |
|
| 2021-05-27 09:48:34 |
Andrew Cloke |
bug task added |
|
ubuntu-z-systems |
|
| 2021-05-27 09:48:50 |
Andrew Cloke |
ubuntu-z-systems: importance |
Undecided |
Medium |
|
| 2021-05-27 10:20:53 |
Marius Hillenbrand |
bug |
|
|
added subscriber Marius Hillenbrand |
| 2021-05-31 07:02:49 |
Frank Heimes |
ubuntu-z-systems: assignee |
|
Skipper Bug Screeners (skipper-screen-team) |
|
| 2021-05-31 07:03:24 |
Frank Heimes |
affects |
linux (Ubuntu) |
tigervnc (Ubuntu) |
|
| 2021-05-31 07:10:05 |
Frank Heimes |
tags |
architecture-s39064 bugnameltc-192826 severity-medium targetmilestone-inin--- |
architecture-s39064 bugnameltc-192826 severity-medium targetmilestone-inin--- universe |
|
| 2021-09-19 16:25:40 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~fheimes/ubuntu/+source/tigervnc/+git/tigervnc/+merge/408847 |
|
| 2021-09-19 16:50:21 |
Frank Heimes |
attachment added |
|
tigervnc debdiff (impish) https://bugs.launchpad.net/ubuntu/+source/tigervnc/+bug/1929790/+attachment/5526289/+files/debdiff_lp1929790_tigervnc_impish.patch |
|
| 2021-09-19 20:17:14 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~fheimes/ubuntu/+source/tigervnc/+git/tigervnc/+merge/408848 |
|
| 2021-09-19 20:22:54 |
Ubuntu Foundations Team Bug Bot |
tags |
architecture-s39064 bugnameltc-192826 severity-medium targetmilestone-inin--- universe |
architecture-s39064 bugnameltc-192826 patch severity-medium targetmilestone-inin--- universe |
|
| 2021-09-19 20:23:01 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2021-09-20 05:00:10 |
Frank Heimes |
attachment added |
|
tigervnc debdiff (hirsute) https://bugs.launchpad.net/ubuntu/+source/tigervnc/+bug/1929790/+attachment/5526371/+files/debdiff_lp1929790_tigervnc_hirsute.patch |
|
| 2021-09-20 06:00:20 |
Frank Heimes |
ubuntu-z-systems: status |
New |
In Progress |
|
| 2021-09-20 06:00:25 |
Frank Heimes |
tigervnc (Ubuntu): status |
New |
In Progress |
|
| 2021-09-20 06:16:37 |
Frank Heimes |
tags |
architecture-s39064 bugnameltc-192826 patch severity-medium targetmilestone-inin--- universe |
architecture-s39064 bugnameltc-192826 patch severity-medium targetmilestone-inin--- ubuntu-sponsors universe |
|
| 2021-09-20 06:20:26 |
Frank Heimes |
description |
---Problem Description---
TigerVNC 1.11.0 contains a regression that causes vncviewer to display
incorrect colors when vncviewer and X11 server use different endianness (e.g.,
when using X11 forwarding via SSH between an x86-64 desktop and a Linux system
on s390x). The regression was originally reported in github issue
https://github.com/TigerVNC/tigervnc/issues/1073 and fixed in github pull
request https://github.com/TigerVNC/tigervnc/pull/1084
The regression caused vncviewer to always use the system byte order for pixel
values instead of the byte order required by the X11 display. With the fix,
vncviewer queries the X11 display for the required byte order.
As of now, the fix has not made it into a release yet. Please consider
backporting the fix (upstream commit 7ab92639848). I confirmed that this commit
cleanly applies on top of release 1.11.0 and fixes the regression.
---uname output---
Linux s390x
Machine Type = x15
---Debugger---
A debugger is not configured
---Steps to Reproduce---
See also https://github.com/TigerVNC/tigervnc/issues/1252
- From a Linux x86 system, connect to a Linux system on s390x via SSH with X forwarding
- Start a Xvnc session on that Linux system
tigervncserver :0 -geometry 800x600 -depth 32
- Start vncviewer on the same Linux system
xtigervncviewer :0
- On vncviewer's window on your origin X session, observe incorrect colors.
- Optionally, start X11 programs such as xlogo, xclock, or xeyes to make the problem obvious
- Optionally, connect to the vnc session directly (i.e., with a vnc client on the origin system) to compare
Userspace tool common name: vncviewer
The userspace tool has the following bit modes: 64-bit
Userspace rpm: tigervnc-viewer
Userspace tool obtained from project website: na |
SRU Justification:
==================
[Impact]
* TigerVNC 1.11.0 contains a (pixel order) regression that causes
vncviewer to display incorrect colors when vncviewer and X11 server
use different endianness
(e.g. when using X11 forwarding via SSH between an amd64 desktop
and a Linux on s390x).
* The regression was originally reported in github issue
https://github.com/TigerVNC/tigervnc/issues/1073
and fixed in github pull request
https://github.com/TigerVNC/tigervnc/pull/1084
* The issue got fixed by a respin of the
ARGB runtime XImage byteorder selection.
[Test Plan]
* Setup two systems with different endianness, ideally:
a (little endian) Ubuntu (Desktop) system (amd64) and
a (big endian) Ubuntu (Server) system (s390x)
* Install tigervnc-standalone-server and tigervnc-xorg-extension on the s390x
and tigervnc-vieweron the amd64 system (incl. all dependencies).
* now start the server with: vncserver
* run the client: xtigervncviewer <server-IP>:1
* detailed instructions how to reproduce the bug
* The issue results in the display of wrong colors, 'similar' to:
https://github.com/TigerVNC/tigervnc/issues/738
[Where problems could occur]
* An onerousness patch would maybe not solve the endian problem
and wrong colors (maybe different) still exist,
* or in worst case it may have an impact on system combinations
that use the same endianness.
* The latter one is very unlikely, since there is only line 126
that enters to code that handles the endianness.
* And the fix here is a respin of the original runtime ARGB
selection pull request, hence one that worked already before.
* And the changes are very limited and only cover 3 lines
of a single if/else statement in vncviewer/Surface_X11.cxx
[Other Info]
* The reported issue is a regression that got (upstream) introduced into 1.10.
* It is fixed be code that is known to work and that was tested on different
platforms.
* The patch is upstream accepted with v1.11.90 since Aug 28, 2020,
* hence it's highly like no longer needed once Debian/Ubuntu pick up
the next upstream version, since it's fixed with > 1.10.
* Patched tigervnc versions are available for impish and hirsute via the PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1929790
* And the issue was in detail discussed upstream at:
https://github.com/TigerVNC/tigervnc/issues/1073
https://github.com/TigerVNC/tigervnc/pull/1084
__________
---Problem Description---
TigerVNC 1.11.0 contains a regression that causes vncviewer to display
incorrect colors when vncviewer and X11 server use different endianness (e.g.,
when using X11 forwarding via SSH between an x86-64 desktop and a Linux system
on s390x). The regression was originally reported in github issue
https://github.com/TigerVNC/tigervnc/issues/1073 and fixed in github pull
request https://github.com/TigerVNC/tigervnc/pull/1084
The regression caused vncviewer to always use the system byte order for pixel
values instead of the byte order required by the X11 display. With the fix,
vncviewer queries the X11 display for the required byte order.
As of now, the fix has not made it into a release yet. Please consider
backporting the fix (upstream commit 7ab92639848). I confirmed that this commit
cleanly applies on top of release 1.11.0 and fixes the regression.
---uname output---
Linux s390x
Machine Type = x15
---Debugger---
A debugger is not configured
---Steps to Reproduce---
See also https://github.com/TigerVNC/tigervnc/issues/1252
- From a Linux x86 system, connect to a Linux system on s390x via SSH with X forwarding
- Start a Xvnc session on that Linux system
tigervncserver :0 -geometry 800x600 -depth 32
- Start vncviewer on the same Linux system
xtigervncviewer :0
- On vncviewer's window on your origin X session, observe incorrect colors.
- Optionally, start X11 programs such as xlogo, xclock, or xeyes to make the problem obvious
- Optionally, connect to the vnc session directly (i.e., with a vnc client on the origin system) to compare
Userspace tool common name: vncviewer
The userspace tool has the following bit modes: 64-bit
Userspace rpm: tigervnc-viewer
Userspace tool obtained from project website: na |
|
| 2021-09-20 08:14:28 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Impish |
|
| 2021-09-20 08:14:28 |
Christian Ehrhardt |
bug task added |
|
tigervnc (Ubuntu Impish) |
|
| 2021-09-20 08:14:28 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Hirsute |
|
| 2021-09-20 08:14:28 |
Christian Ehrhardt |
bug task added |
|
tigervnc (Ubuntu Hirsute) |
|
| 2021-09-20 08:14:35 |
Christian Ehrhardt |
tigervnc (Ubuntu Hirsute): status |
New |
In Progress |
|
| 2021-09-20 15:09:29 |
Frank Heimes |
description |
SRU Justification:
==================
[Impact]
* TigerVNC 1.11.0 contains a (pixel order) regression that causes
vncviewer to display incorrect colors when vncviewer and X11 server
use different endianness
(e.g. when using X11 forwarding via SSH between an amd64 desktop
and a Linux on s390x).
* The regression was originally reported in github issue
https://github.com/TigerVNC/tigervnc/issues/1073
and fixed in github pull request
https://github.com/TigerVNC/tigervnc/pull/1084
* The issue got fixed by a respin of the
ARGB runtime XImage byteorder selection.
[Test Plan]
* Setup two systems with different endianness, ideally:
a (little endian) Ubuntu (Desktop) system (amd64) and
a (big endian) Ubuntu (Server) system (s390x)
* Install tigervnc-standalone-server and tigervnc-xorg-extension on the s390x
and tigervnc-vieweron the amd64 system (incl. all dependencies).
* now start the server with: vncserver
* run the client: xtigervncviewer <server-IP>:1
* detailed instructions how to reproduce the bug
* The issue results in the display of wrong colors, 'similar' to:
https://github.com/TigerVNC/tigervnc/issues/738
[Where problems could occur]
* An onerousness patch would maybe not solve the endian problem
and wrong colors (maybe different) still exist,
* or in worst case it may have an impact on system combinations
that use the same endianness.
* The latter one is very unlikely, since there is only line 126
that enters to code that handles the endianness.
* And the fix here is a respin of the original runtime ARGB
selection pull request, hence one that worked already before.
* And the changes are very limited and only cover 3 lines
of a single if/else statement in vncviewer/Surface_X11.cxx
[Other Info]
* The reported issue is a regression that got (upstream) introduced into 1.10.
* It is fixed be code that is known to work and that was tested on different
platforms.
* The patch is upstream accepted with v1.11.90 since Aug 28, 2020,
* hence it's highly like no longer needed once Debian/Ubuntu pick up
the next upstream version, since it's fixed with > 1.10.
* Patched tigervnc versions are available for impish and hirsute via the PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1929790
* And the issue was in detail discussed upstream at:
https://github.com/TigerVNC/tigervnc/issues/1073
https://github.com/TigerVNC/tigervnc/pull/1084
__________
---Problem Description---
TigerVNC 1.11.0 contains a regression that causes vncviewer to display
incorrect colors when vncviewer and X11 server use different endianness (e.g.,
when using X11 forwarding via SSH between an x86-64 desktop and a Linux system
on s390x). The regression was originally reported in github issue
https://github.com/TigerVNC/tigervnc/issues/1073 and fixed in github pull
request https://github.com/TigerVNC/tigervnc/pull/1084
The regression caused vncviewer to always use the system byte order for pixel
values instead of the byte order required by the X11 display. With the fix,
vncviewer queries the X11 display for the required byte order.
As of now, the fix has not made it into a release yet. Please consider
backporting the fix (upstream commit 7ab92639848). I confirmed that this commit
cleanly applies on top of release 1.11.0 and fixes the regression.
---uname output---
Linux s390x
Machine Type = x15
---Debugger---
A debugger is not configured
---Steps to Reproduce---
See also https://github.com/TigerVNC/tigervnc/issues/1252
- From a Linux x86 system, connect to a Linux system on s390x via SSH with X forwarding
- Start a Xvnc session on that Linux system
tigervncserver :0 -geometry 800x600 -depth 32
- Start vncviewer on the same Linux system
xtigervncviewer :0
- On vncviewer's window on your origin X session, observe incorrect colors.
- Optionally, start X11 programs such as xlogo, xclock, or xeyes to make the problem obvious
- Optionally, connect to the vnc session directly (i.e., with a vnc client on the origin system) to compare
Userspace tool common name: vncviewer
The userspace tool has the following bit modes: 64-bit
Userspace rpm: tigervnc-viewer
Userspace tool obtained from project website: na |
SRU Justification:
==================
[Impact]
* TigerVNC 1.11.0 contains a (pixel order) regression that causes
vncviewer to display incorrect colors when vncviewer and X11 server
use different endianness
(e.g. when using X11 forwarding via SSH between an amd64 desktop
and a Linux on s390x).
* The regression was originally reported in github issue
https://github.com/TigerVNC/tigervnc/issues/1073
and fixed in github pull request
https://github.com/TigerVNC/tigervnc/pull/1084
* The issue got fixed by a respin of the
ARGB runtime XImage byteorder selection.
[Test Plan]
* Setup two systems with different endianness, ideally:
a (little endian) Ubuntu (Desktop) system (amd64) and
a (big endian) Ubuntu (Server) system (s390x)
* Install tigervnc-standalone-server and tigervnc-xorg-extension on the s390x
and tigervnc-vieweron the amd64 system (incl. all dependencies).
* now start the server with: vncserver
* run the client: xtigervncviewer <server-IP>:1
* detailed instructions how to reproduce the bug
* The issue results in the display of wrong colors, 'similar' to:
https://github.com/TigerVNC/tigervnc/issues/738
* Another (regression) test will be using both,
server and client, on amd64 only.
[Where problems could occur]
* An onerousness patch would maybe not solve the endian problem
and wrong colors (maybe different) still exist,
* or in worst case it may have an impact on system combinations
that use the same endianness.
* The latter one is very unlikely, since there is only line 126
that enters to code that handles the endianness.
* And the fix here is a respin of the original runtime ARGB
selection pull request, hence one that worked already before.
* And the changes are very limited and only cover 3 lines
of a single if/else statement in vncviewer/Surface_X11.cxx
[Other Info]
* The reported issue is a regression that got (upstream) introduced into 1.10.
* It is fixed be code that is known to work and that was tested on different
platforms.
* The patch is upstream accepted with v1.11.90 since Aug 28, 2020,
* hence it's highly like no longer needed once Debian/Ubuntu pick up
the next upstream version, since it's fixed with > 1.10.
* Patched tigervnc versions are available for impish and hirsute via the PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1929790
* And the issue was in detail discussed upstream at:
https://github.com/TigerVNC/tigervnc/issues/1073
https://github.com/TigerVNC/tigervnc/pull/1084
__________
---Problem Description---
TigerVNC 1.11.0 contains a regression that causes vncviewer to display
incorrect colors when vncviewer and X11 server use different endianness (e.g.,
when using X11 forwarding via SSH between an x86-64 desktop and a Linux system
on s390x). The regression was originally reported in github issue
https://github.com/TigerVNC/tigervnc/issues/1073 and fixed in github pull
request https://github.com/TigerVNC/tigervnc/pull/1084
The regression caused vncviewer to always use the system byte order for pixel
values instead of the byte order required by the X11 display. With the fix,
vncviewer queries the X11 display for the required byte order.
As of now, the fix has not made it into a release yet. Please consider
backporting the fix (upstream commit 7ab92639848). I confirmed that this commit
cleanly applies on top of release 1.11.0 and fixes the regression.
---uname output---
Linux s390x
Machine Type = x15
---Debugger---
A debugger is not configured
---Steps to Reproduce---
See also https://github.com/TigerVNC/tigervnc/issues/1252
- From a Linux x86 system, connect to a Linux system on s390x via SSH with X forwarding
- Start a Xvnc session on that Linux system
tigervncserver :0 -geometry 800x600 -depth 32
- Start vncviewer on the same Linux system
xtigervncviewer :0
- On vncviewer's window on your origin X session, observe incorrect colors.
- Optionally, start X11 programs such as xlogo, xclock, or xeyes to make the problem obvious
- Optionally, connect to the vnc session directly (i.e., with a vnc client on the origin system) to compare
Userspace tool common name: vncviewer
The userspace tool has the following bit modes: 64-bit
Userspace rpm: tigervnc-viewer
Userspace tool obtained from project website: na |
|
| 2021-09-20 15:10:07 |
Frank Heimes |
description |
SRU Justification:
==================
[Impact]
* TigerVNC 1.11.0 contains a (pixel order) regression that causes
vncviewer to display incorrect colors when vncviewer and X11 server
use different endianness
(e.g. when using X11 forwarding via SSH between an amd64 desktop
and a Linux on s390x).
* The regression was originally reported in github issue
https://github.com/TigerVNC/tigervnc/issues/1073
and fixed in github pull request
https://github.com/TigerVNC/tigervnc/pull/1084
* The issue got fixed by a respin of the
ARGB runtime XImage byteorder selection.
[Test Plan]
* Setup two systems with different endianness, ideally:
a (little endian) Ubuntu (Desktop) system (amd64) and
a (big endian) Ubuntu (Server) system (s390x)
* Install tigervnc-standalone-server and tigervnc-xorg-extension on the s390x
and tigervnc-vieweron the amd64 system (incl. all dependencies).
* now start the server with: vncserver
* run the client: xtigervncviewer <server-IP>:1
* detailed instructions how to reproduce the bug
* The issue results in the display of wrong colors, 'similar' to:
https://github.com/TigerVNC/tigervnc/issues/738
* Another (regression) test will be using both,
server and client, on amd64 only.
[Where problems could occur]
* An onerousness patch would maybe not solve the endian problem
and wrong colors (maybe different) still exist,
* or in worst case it may have an impact on system combinations
that use the same endianness.
* The latter one is very unlikely, since there is only line 126
that enters to code that handles the endianness.
* And the fix here is a respin of the original runtime ARGB
selection pull request, hence one that worked already before.
* And the changes are very limited and only cover 3 lines
of a single if/else statement in vncviewer/Surface_X11.cxx
[Other Info]
* The reported issue is a regression that got (upstream) introduced into 1.10.
* It is fixed be code that is known to work and that was tested on different
platforms.
* The patch is upstream accepted with v1.11.90 since Aug 28, 2020,
* hence it's highly like no longer needed once Debian/Ubuntu pick up
the next upstream version, since it's fixed with > 1.10.
* Patched tigervnc versions are available for impish and hirsute via the PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1929790
* And the issue was in detail discussed upstream at:
https://github.com/TigerVNC/tigervnc/issues/1073
https://github.com/TigerVNC/tigervnc/pull/1084
__________
---Problem Description---
TigerVNC 1.11.0 contains a regression that causes vncviewer to display
incorrect colors when vncviewer and X11 server use different endianness (e.g.,
when using X11 forwarding via SSH between an x86-64 desktop and a Linux system
on s390x). The regression was originally reported in github issue
https://github.com/TigerVNC/tigervnc/issues/1073 and fixed in github pull
request https://github.com/TigerVNC/tigervnc/pull/1084
The regression caused vncviewer to always use the system byte order for pixel
values instead of the byte order required by the X11 display. With the fix,
vncviewer queries the X11 display for the required byte order.
As of now, the fix has not made it into a release yet. Please consider
backporting the fix (upstream commit 7ab92639848). I confirmed that this commit
cleanly applies on top of release 1.11.0 and fixes the regression.
---uname output---
Linux s390x
Machine Type = x15
---Debugger---
A debugger is not configured
---Steps to Reproduce---
See also https://github.com/TigerVNC/tigervnc/issues/1252
- From a Linux x86 system, connect to a Linux system on s390x via SSH with X forwarding
- Start a Xvnc session on that Linux system
tigervncserver :0 -geometry 800x600 -depth 32
- Start vncviewer on the same Linux system
xtigervncviewer :0
- On vncviewer's window on your origin X session, observe incorrect colors.
- Optionally, start X11 programs such as xlogo, xclock, or xeyes to make the problem obvious
- Optionally, connect to the vnc session directly (i.e., with a vnc client on the origin system) to compare
Userspace tool common name: vncviewer
The userspace tool has the following bit modes: 64-bit
Userspace rpm: tigervnc-viewer
Userspace tool obtained from project website: na |
SRU Justification:
==================
[Impact]
* TigerVNC 1.11.0 contains a (pixel order) regression that causes
vncviewer to display incorrect colors when vncviewer and X11 server
use different endianness
(e.g. when using X11 forwarding via SSH between an amd64 desktop
and a Linux on s390x).
* The regression was originally reported in github issue
https://github.com/TigerVNC/tigervnc/issues/1073
and fixed in github pull request
https://github.com/TigerVNC/tigervnc/pull/1084
* The issue got fixed by a respin of the
ARGB runtime XImage byteorder selection.
[Test Plan]
* Setup two systems with different endianness, ideally:
a (little endian) Ubuntu (Desktop) system (amd64) and
a (big endian) Ubuntu (Server) system (s390x)
* Install tigervnc-standalone-server and tigervnc-xorg-extension on the s390x
and tigervnc-vieweron the amd64 system (incl. all dependencies).
* now start the server with: vncserver
* run the client: xtigervncviewer <server-IP>:1
* detailed instructions how to reproduce the bug
* The issue results in the display of wrong colors, 'similar' to:
https://github.com/TigerVNC/tigervnc/issues/738
* Another (regression) test will be using both,
tigervnc server and client, on amd64 only.
[Where problems could occur]
* An onerousness patch would maybe not solve the endian problem
and wrong colors (maybe different) still exist,
* or in worst case it may have an impact on system combinations
that use the same endianness.
* The latter one is very unlikely, since there is only line 126
that enters to code that handles the endianness.
* And the fix here is a respin of the original runtime ARGB
selection pull request, hence one that worked already before.
* And the changes are very limited and only cover 3 lines
of a single if/else statement in vncviewer/Surface_X11.cxx
[Other Info]
* The reported issue is a regression that got (upstream) introduced into 1.10.
* It is fixed be code that is known to work and that was tested on different
platforms.
* The patch is upstream accepted with v1.11.90 since Aug 28, 2020,
* hence it's highly like no longer needed once Debian/Ubuntu pick up
the next upstream version, since it's fixed with > 1.10.
* Patched tigervnc versions are available for impish and hirsute via the PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1929790
* And the issue was in detail discussed upstream at:
https://github.com/TigerVNC/tigervnc/issues/1073
https://github.com/TigerVNC/tigervnc/pull/1084
__________
---Problem Description---
TigerVNC 1.11.0 contains a regression that causes vncviewer to display
incorrect colors when vncviewer and X11 server use different endianness (e.g.,
when using X11 forwarding via SSH between an x86-64 desktop and a Linux system
on s390x). The regression was originally reported in github issue
https://github.com/TigerVNC/tigervnc/issues/1073 and fixed in github pull
request https://github.com/TigerVNC/tigervnc/pull/1084
The regression caused vncviewer to always use the system byte order for pixel
values instead of the byte order required by the X11 display. With the fix,
vncviewer queries the X11 display for the required byte order.
As of now, the fix has not made it into a release yet. Please consider
backporting the fix (upstream commit 7ab92639848). I confirmed that this commit
cleanly applies on top of release 1.11.0 and fixes the regression.
---uname output---
Linux s390x
Machine Type = x15
---Debugger---
A debugger is not configured
---Steps to Reproduce---
See also https://github.com/TigerVNC/tigervnc/issues/1252
- From a Linux x86 system, connect to a Linux system on s390x via SSH with X forwarding
- Start a Xvnc session on that Linux system
tigervncserver :0 -geometry 800x600 -depth 32
- Start vncviewer on the same Linux system
xtigervncviewer :0
- On vncviewer's window on your origin X session, observe incorrect colors.
- Optionally, start X11 programs such as xlogo, xclock, or xeyes to make the problem obvious
- Optionally, connect to the vnc session directly (i.e., with a vnc client on the origin system) to compare
Userspace tool common name: vncviewer
The userspace tool has the following bit modes: 64-bit
Userspace rpm: tigervnc-viewer
Userspace tool obtained from project website: na |
|
| 2021-09-20 16:43:39 |
Frank Heimes |
merge proposal unlinked |
https://code.launchpad.net/~fheimes/ubuntu/+source/tigervnc/+git/tigervnc/+merge/408848 |
|
|
| 2021-09-20 16:44:08 |
Frank Heimes |
merge proposal unlinked |
https://code.launchpad.net/~fheimes/ubuntu/+source/tigervnc/+git/tigervnc/+merge/408847 |
|
|
| 2021-09-20 18:11:42 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~fheimes/ubuntu/+source/tigervnc/+git/tigervnc/+merge/408899 |
|
| 2021-09-20 18:53:48 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~fheimes/ubuntu/+source/tigervnc/+git/tigervnc/+merge/408903 |
|
| 2021-09-20 19:01:12 |
Frank Heimes |
attachment removed |
tigervnc debdiff (impish) https://bugs.launchpad.net/ubuntu/+source/tigervnc/+bug/1929790/+attachment/5526289/+files/debdiff_lp1929790_tigervnc_impish.patch |
|
|
| 2021-09-20 19:01:35 |
Frank Heimes |
attachment removed |
tigervnc debdiff (hirsute) https://bugs.launchpad.net/ubuntu/+source/tigervnc/+bug/1929790/+attachment/5526371/+files/debdiff_lp1929790_tigervnc_hirsute.patch |
|
|
| 2021-09-20 19:02:34 |
Frank Heimes |
attachment added |
|
debdiff impish (updated) https://bugs.launchpad.net/ubuntu/+source/tigervnc/+bug/1929790/+attachment/5526537/+files/debdiff_lp1929790_tigervnc_impish.patch |
|
| 2021-09-20 19:03:02 |
Frank Heimes |
attachment added |
|
debdiff hirsute (updated) https://bugs.launchpad.net/ubuntu/+source/tigervnc/+bug/1929790/+attachment/5526538/+files/debdiff_lp1929790_tigervnc_hirsute.patch |
|
| 2021-09-20 19:08:12 |
bugproxy |
attachment added |
|
tigervnc debdiff (impish) https://bugs.launchpad.net/bugs/1929790/+attachment/5526554/+files/debdiff_lp1929790_tigervnc_impish.patch |
|
| 2021-09-20 19:08:14 |
bugproxy |
attachment added |
|
tigervnc debdiff (hirsute) https://bugs.launchpad.net/bugs/1929790/+attachment/5526555/+files/debdiff_lp1929790_tigervnc_hirsute.patch |
|
| 2021-09-21 06:34:47 |
Mathew Hodson |
tigervnc (Ubuntu Hirsute): importance |
Undecided |
Medium |
|
| 2021-09-21 06:34:49 |
Mathew Hodson |
tigervnc (Ubuntu Impish): importance |
Undecided |
Medium |
|
| 2021-09-21 09:01:15 |
Frank Heimes |
tigervnc (Ubuntu Hirsute): status |
In Progress |
Fix Committed |
|
| 2021-09-21 09:01:20 |
Frank Heimes |
tigervnc (Ubuntu Hirsute): status |
Fix Committed |
In Progress |
|
| 2021-09-21 09:01:24 |
Frank Heimes |
tigervnc (Ubuntu Impish): status |
In Progress |
Fix Committed |
|
| 2021-09-21 10:33:19 |
Launchpad Janitor |
tigervnc (Ubuntu Impish): status |
Fix Committed |
Fix Released |
|
| 2021-09-22 11:49:53 |
Robie Basak |
tigervnc (Ubuntu Hirsute): status |
In Progress |
Fix Committed |
|
| 2021-09-22 11:49:54 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2021-09-22 11:49:56 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2021-09-22 11:49:58 |
Robie Basak |
tags |
architecture-s39064 bugnameltc-192826 patch severity-medium targetmilestone-inin--- ubuntu-sponsors universe |
architecture-s39064 bugnameltc-192826 patch severity-medium targetmilestone-inin--- ubuntu-sponsors universe verification-needed verification-needed-hirsute |
|
| 2021-09-22 12:51:03 |
Robie Basak |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2021-09-24 10:06:01 |
Frank Heimes |
tags |
architecture-s39064 bugnameltc-192826 patch severity-medium targetmilestone-inin--- ubuntu-sponsors universe verification-needed verification-needed-hirsute |
architecture-s39064 bugnameltc-192826 patch severity-medium targetmilestone-inin--- universe verification-done verification-done-hirsute |
|
| 2021-09-24 10:06:13 |
Frank Heimes |
ubuntu-z-systems: status |
In Progress |
Fix Committed |
|
| 2021-09-29 17:57:56 |
Launchpad Janitor |
tigervnc (Ubuntu Hirsute): status |
Fix Committed |
Fix Released |
|
| 2021-09-29 17:58:00 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2021-09-29 18:43:00 |
Frank Heimes |
ubuntu-z-systems: status |
Fix Committed |
Fix Released |
|
| 2022-02-07 12:59:53 |
bugproxy |
tags |
architecture-s39064 bugnameltc-192826 patch severity-medium targetmilestone-inin--- universe verification-done verification-done-hirsute |
architecture-s39064 bugnameltc-192826 patch severity-medium targetmilestone-inin2104 universe verification-done verification-done-hirsute |
|
