search for: 1.0.90

Hi, The fact that apparently the last tigervnc update from upstream was missed triggered me to check for missing updates and packages in 6.3. Here are my results. Sorry for any false positives that might have crept in, but note that some of the 6_x updates actually are updates and not a parsing error. And perhaps an occasional false positive due to having to compare upstream SRPMS vs downstream

After v1.0 is released, I can finally get back to sane version numbers. But any comments on which one is better: a) Postfix-style: "1.1.UNSTABLE.YYYYMMDD" -> 1.1.0 (stable) b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable) With a) style the releases could be done by simply copying a nightly snapshot to releases/ directory and announcing the changes since the last

Hello Community, I encountered an error while running "xm console domU". Here is the running script: # xm console domU xenconsole: Could not read tty from store: No such file or directory I googled and found out that this issue is mostly result from forgetting starting xenconsole service. However, after I started xenconsole, the issue is still there. Please see: #

See this bug for background information: https://bugzilla.redhat.com/show_bug.cgi?id=1350465 Thanks: Tomáš Golembiovský --- v2v/virt-v2v.pod | 38 ++++++++++++++++++++++++++------------ 1 file changed, 26 insertions(+), 12 deletions(-) diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod index e68d75cf8..0943bf305 100644 --- a/v2v/virt-v2v.pod +++ b/v2v/virt-v2v.pod @@ -1909,18 +1909,32 @@ that

See this bug for background information: https://bugzilla.redhat.com/show_bug.cgi?id=1350465 --- v2v/virt-v2v.pod | 39 +++++++++++++++++++++++++++------------ 1 file changed, 27 insertions(+), 12 deletions(-) diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod index e68d75cf8..93d1a9ecd 100644 --- a/v2v/virt-v2v.pod +++ b/v2v/virt-v2v.pod @@ -1909,18 +1909,33 @@ that guest through the RHV-M UI,

If the connection is not local, paths of disks will refer to the remote host, which were mistakenly handled as local paths (in the best case failing to open a non-existing disk, and in the worst case opening a different disk!). In case the disks are remote resources like ssh or ceph, nothing guarantees that the hostname can be reached from the local machine, or even that it is actually the same on

Hopefully this time ...