from:"Joachim Falk"

Bug#1027288: [Pkg-tigervnc-devel] Bug#1027288: tigervnc-common: orphaned alternatives (vncpasswd, vncpasswd.1.gz)

2022-12-30 Thread Joachim Falk


Hi Jakub,

Am 29.12.22 um 21:59 schrieb Jakub Wilk:

Package: tigervnc-common
Version: 1.12.0+dfsg-7

tigervnc-common used to install alternatives for "vncpasswd" and 
"vncpasswd.1.gz". Now it no longer does, but it didn't clean up the old ones:

    $ file /usr/bin/vncp* /usr/share/man/man*/vncp* | grep -w broken
    /usr/bin/vncpasswd: broken symbolic link to 
/etc/alternatives/vncpasswd
    /usr/share/man/man1/vncpasswd.1.gz: broken symbolic link to 
/etc/alternatives/vncpasswd.1.gz


tigervncpasswd moved to tigervnc-tools.

Normally, tigervnc-tools should auto install on upgrade from TigerVNC 1.11.

Maybe you upgraded with

apt upgrade --no-install-recommends

Or only had tigervnc-common installed without anything else from TigerVNC?

Best,

Joachim


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008268: bullseye-pu: package tigervnc/1.11.0+dfsg-2

2022-03-25 Thread Joachim Falk

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-tigervnc-de...@lists.alioth.debian.org, joachim.f...@gmx.de

[ Reason ]

This proposed update fixes two regressions:

(i) https://bugs.launchpad.net/ubuntu/+source/tigervnc/+bug/1929790

 * 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.

(ii) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004395

  Den tors 20 jan. 2022 14:06code0815  skrev:

  Dear Maintainers,

  I'm using debian bullseye and facing a bug, that is present inside the
  tigervnc-standalone-server packages 1.11.0+dfsg-2, 1.11.0+dfsg-3. The
  bug does affect the Gnome environment, so that a gnome-session is not
  started properly, when started through tigervncserver@.service. So the
  bug makes tigervnc-standalone-server unuseable, if a user does want to
  use a Gnome-Session inside TigerVNC.

  This bug does not come up anymore, if I do install tigervnc-1.12 from
  the TigerVNC developers source packages. The bug does affect Ubuntu
  21.10, too. It seems to me, that all 1.11 versions - not debian based
  only - are affected.

  Thanks in advance!

  code0815

In this process, I also fixed two typos in the tigervncserver man page.

[ Impact ]
The first regression is minor. It only triggers in corner cases.
The second regression is more severe if one wants to use 
tigervncserver@.service.

[ Tests ]
Package has been tested by being used in our lab for two month.

[ Risks ]
First regression is fixed by a backported upstream patch that also has
been applied for Ubuntu 21.04. Second regression is fixed by a one
liner.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]

First regression got fixed by a respin of the ARGB runtime XImage byteorder 
selection.
Second regression is fixed by switching the PAM session used by
tigervnc-standalone-server to be interactive instead of noninteractive.
diff -Nru tigervnc-1.11.0+dfsg/debian/changelog 
tigervnc-1.11.0+dfsg/debian/changelog
--- tigervnc-1.11.0+dfsg/debian/changelog   2021-03-22 22:21:28.0 
+0100
+++ tigervnc-1.11.0+dfsg/debian/changelog   2022-01-26 18:59:24.0 
+0100
@@ -1,3 +1,17 @@
+tigervnc (1.11.0+dfsg-2+deb11u1) bullseye; urgency=medium
+
+  [ John Martin ]
+  * TigerVNC 1.11.0 contains a regression that causes vncviewer to display
+incorrect colors when vncviewer and X11 server use different endianness.
+(LP: #1929790)
+
+  [ Joachim Falk ]
+  * Fixed typo in tigervncserver man page (Closes: #1003715).
+  * Fixed gnome desktop start up when using tigervncserver@.service.
+(Closes: #1004395)
+
+ -- Joachim Falk   Wed, 26 Jan 2022 18:59:24 +0100
+
 tigervnc (1.11.0+dfsg-2) unstable; urgency=medium

   [ Joachim Falk ]
diff -Nru tigervnc-1.11.0+dfsg/debian/helpers/etc/pam.d/tigervnc 
tigervnc-1.11.0+dfsg/debian/helpers/etc/pam.d/tigervnc
--- tigervnc-1.11.0+dfsg/debian/helpers/etc/pam.d/tigervnc  2020-10-06 
21:57:07.0 +0200
+++ tigervnc-1.11.0+dfsg/debian/helpers/etc/pam.d/tigervnc  2022-01-26 
18:59:24.0 +0100
@@ -2,4 +2,4 @@

 @include common-auth
 @include common-account
-@include common-session-noninteractive
+@include common-session
diff -Nru 
tigervnc-1.11.0+dfsg/debian/helpers/usr/share/man/man1/tigervncserver.1 
tigervnc-1.11.0+dfsg/debian/helpers/usr/share/man/man1/tigervncserver.1
--- tigervnc-1.11.0+dfsg/debian/helpers/usr/share/man/man1/tigervncserver.1 
2021-02-22 18:20:50.0 +0100
+++ tigervnc-1.11.0+dfsg/debian/helpers/usr/share/man/man1/tigervncserver.1 
2022-01-26 18:59:24.0 +0100
@@ -11,7 +11,7 @@
 .\"
 .TH tigervncserver 1 "Jan 13th, 2021" "TigerVNC 1.11.0" "Virtual Network 
Computing"
 .SH NAME
-tigervncserver \- start or stop a TigerVNC standaloe server
+tigervncserver \- start or stop a TigerVNC standalone server
 .SH SYNOPSIS
 .
 .B tigervncserver
@@ -75,7 +75,7 @@
 .RB [ \-cleanstale ]
 .
 .br
-.B x0tigervncserver -version
+.B tigervncserver -version
 .
 .SH DESCRIPTION
 .B tigervncserver\fP is used to start a TigerVNC (Virtual Network Computing)
diff -Nru 
tigervnc-1.11.0+dfsg/debian/patches/backport/0001-Update-Surface_X11.cxx.patch 
tigervnc-1.11.0+dfsg/debian/patches/backport/0001-Update-Surface_X11.cxx.patch
--- 
tigervnc-1.11.0+dfsg/

Bug#1004395: tigervnc-standalone-server: Gnome desktop does not start when using tigervncserver@.service

2022-01-26 Thread joachim . falk

Package: tigervnc-standalone-server
Version: 1.11.0+dfsg-2
Severity: important
Tags: patch
X-Debbugs-Cc: code0...@mailbox.org, joachim.f...@gmx.de

Den tors 20 jan. 2022 14:06code0815  skrev:
> Dear Maintainers,
>
> I'm using debian bullseye and facing a bug, that is present inside the
> tigervnc-standalone-server packages 1.11.0+dfsg-2, 1.11.0+dfsg-3. The
> bug does affect the Gnome environment, so that a gnome-session is not
> started properly, when started through tigervncserver@.service. So the
> bug makes tigervnc-standalone-server unuseable, if a user does want to
> use a Gnome-Session inside TigerVNC.
>
> This bug does not come up anymore, if I do install tigervnc-1.12 from
> the TigerVNC developers source packages. The bug does affect Ubuntu
> 21.10, too. It seems to me, that all 1.11 versions - not debian based
> only - are affected.

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-11-amd64 (SMP w/16 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tigervnc-standalone-server depends on:
ii  libaudit1   1:3.0-2
ii  libbsd0 0.11.3-1
ii  libc6   2.31-13+deb11u2
ii  libfile-readbackwards-perl  1.05-2
ii  libgcrypt20 1.8.7-6
ii  libgl1  1.3.2-1
ii  libgnutls30 3.7.1-5
ii  libjpeg62-turbo 1:2.0.6-4
ii  libpam0g1.4.0-9+deb11u1
ii  libpixman-1-0   0.40.0-1
ii  libselinux1 3.1-3
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.3-6
ii  libunwind8  1.3.2-2
ii  libxau6 1:1.0.9-1
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.4-1
ii  perl5.32.1-4+deb11u2
hi  tigervnc-common 1.11.0+dfsg-2
ii  x11-xkb-utils   7.7+5
ii  xauth   1:1.1-1
ii  xkb-data2.29-2
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages tigervnc-standalone-server recommends:
ii  libgl1-mesa-dri20.3.5-1
ii  x11-xserver-utils  7.7+8
ii  xfonts-base1:1.0.5

Versions of packages tigervnc-standalone-server suggests:
ii  xfonts-100dpi1:1.0.4+nmu1.1
ii  xfonts-75dpi 1:1.0.4+nmu1.1
ii  xfonts-scalable  1:1.0.3-1.2

-- Configuration Files:
/etc/tigervnc/vncserver.users changed [not included]

-- no debconf information
diff --git a/debian/helpers/etc/pam.d/tigervnc 
b/debian/helpers/etc/pam.d/tigervnc
index 68c261a..3e42c5c 100644
--- a/debian/helpers/etc/pam.d/tigervnc
+++ b/debian/helpers/etc/pam.d/tigervnc
@@ -2,4 +2,4 @@

 @include common-auth
 @include common-account
-@include common-session-noninteractive
+@include common-session

Bug#1004366: tigervnc-standalone-server: Use of uninitialized value in string eq at Config.pm line 401

2022-01-25 Thread joachim . falk

Package: tigervnc-standalone-server
Version: 1.11.0+dfsg-2
Severity: minor
Tags: patch
X-Debbugs-Cc: joachim.f...@gmx.de

Cosmetic error in case ~/.vnc/config contains at least one of

AlwaysShared = 0
NeverShared = 0

Then, tigervncserver commands will result in

Use of uninitialized value in string eq at /usr/share/perl5/TigerVNC/Config.pm 
line 414,  line 4.
Use of uninitialized value in string eq at /usr/share/perl5/TigerVNC/Config.pm 
line 401,  line 5.

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-11-amd64 (SMP w/16 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tigervnc-standalone-server depends on:
ii  libaudit1   1:3.0-2
ii  libbsd0 0.11.3-1
ii  libc6   2.31-13+deb11u2
ii  libfile-readbackwards-perl  1.05-2
ii  libgcrypt20 1.8.7-6
ii  libgl1  1.3.2-1
ii  libgnutls30 3.7.1-5
ii  libjpeg62-turbo 1:2.0.6-4
ii  libpam0g1.4.0-9+deb11u1
ii  libpixman-1-0   0.40.0-1
ii  libselinux1 3.1-3
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.3-6
ii  libunwind8  1.3.2-2
ii  libxau6 1:1.0.9-1
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.4-1
ii  perl5.32.1-4+deb11u2
hi  tigervnc-common 1.11.0+dfsg-2
ii  x11-xkb-utils   7.7+5
ii  xauth   1:1.1-1
ii  xkb-data2.29-2
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages tigervnc-standalone-server recommends:
ii  libgl1-mesa-dri20.3.5-1
ii  x11-xserver-utils  7.7+8
ii  xfonts-base1:1.0.5

Versions of packages tigervnc-standalone-server suggests:
ii  xfonts-100dpi1:1.0.4+nmu1.1
ii  xfonts-75dpi 1:1.0.4+nmu1.1
ii  xfonts-scalable  1:1.0.3-1.2

-- Configuration Files:
/etc/tigervnc/vncserver.users changed [not included]

-- no debconf information
From 58104c25bf2c592609e6ba7ead84082261117e47 Mon Sep 17 00:00:00 2001
From: Joachim Falk 
Date: Wed, 24 Mar 2021 22:03:19 +0100
Subject: [PATCH] Fixed warnings use of uninitialized value in string eq at
 /usr/share/perl5/TigerVNC/Config.pm line 401 or 414.

---
 debian/helpers/usr/share/perl5/TigerVNC/Config.pm | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/debian/helpers/usr/share/perl5/TigerVNC/Config.pm 
b/debian/helpers/usr/share/perl5/TigerVNC/Config.pm
index 1644b3b..dfdb0d2 100644
--- a/debian/helpers/usr/share/perl5/TigerVNC/Config.pm
+++ b/debian/helpers/usr/share/perl5/TigerVNC/Config.pm
@@ -398,7 +398,8 @@ sub getOptionParseTable($$) {
   if (@_ == 2) {
 if ($_[1] eq '' || $_[1] eq '1') {
   &{$override}('shared', 'never');
-} elsif ($options->{'shared'} eq 'never') {
+} elsif (defined($options->{'shared'}) &&
+ $options->{'shared'} eq 'never') {
   &{$override}('shared', undef);
 }
   } elsif (defined $options->{'shared'}) {
@@ -411,7 +412,8 @@ sub getOptionParseTable($$) {
   if (@_ == 2) {
 if ($_[1] eq '' || $_[1] eq '1') {
   &{$override}('shared', 'always');
-} elsif ($options->{'shared'} eq 'always') {
+} elsif (defined($options->{'shared'}) &&
+ $options->{'shared'} eq 'always') {
   &{$override}('shared', undef);
 }
   } elsif (defined $options->{'shared'}) {
--
2.30.2

Bug#1004365: tigervnc-standalone-server: Use of uninitialized value $usedDisplay in concatenation at Wrapper.pm line 297

2022-01-25 Thread joachim . falk

Package: tigervnc-standalone-server
Version: 1.11.0+dfsg-2
Severity: minor
Tags: patch
X-Debbugs-Cc: joachim.f...@gmx.de

Cosmetic error when creating a VNC server running on a port outside the
range of 5900 - 5999 and then using tigervncserver -list to show all
running instances.

Follow the below steps to reproduce the bug:

...]$ tigervncserver -xstartup /usr/bin/xterm :5877 --

New Xtigervnc server 'flummy.local:11777 (joachim)' on port 11777 for display 
:5877.
Use xtigervncviewer -SecurityTypes X509Plain -X509CA 
/home/joachim/.vnc/flummy.local-SrvCert.pem flummy.local:11777 to connect to 
the VNC server.

...]$ tigervncserver -list
Use of uninitialized value $usedDisplay in concatenation (.) or string at 
/usr/share/perl5/TigerVNC/Wrapper.pm line 297.
Use of uninitialized value $usedDisplay in concatenation (.) or string at 
/usr/share/perl5/TigerVNC/Wrapper.pm line 300.
Use of uninitialized value $usedDisplay in concatenation (.) or string at 
/usr/share/perl5/TigerVNC/Wrapper.pm line 300.

TigerVNC server sessions:

X DISPLAY # RFB PORT #  PROCESS ID  SERVER
:5877   11777   898549  Xtigervnc

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-11-amd64 (SMP w/16 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tigervnc-standalone-server depends on:
ii  libaudit1   1:3.0-2
ii  libbsd0 0.11.3-1
ii  libc6   2.31-13+deb11u2
ii  libfile-readbackwards-perl  1.05-2
ii  libgcrypt20 1.8.7-6
ii  libgl1  1.3.2-1
ii  libgnutls30 3.7.1-5
ii  libjpeg62-turbo 1:2.0.6-4
ii  libpam0g1.4.0-9+deb11u1
ii  libpixman-1-0   0.40.0-1
ii  libselinux1 3.1-3
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.3-6
ii  libunwind8  1.3.2-2
ii  libxau6 1:1.0.9-1
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.4-1
ii  perl5.32.1-4+deb11u2
hi  tigervnc-common 1.11.0+dfsg-2
ii  x11-xkb-utils   7.7+5
ii  xauth   1:1.1-1
ii  xkb-data2.29-2
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages tigervnc-standalone-server recommends:
ii  libgl1-mesa-dri20.3.5-1
ii  x11-xserver-utils  7.7+8
ii  xfonts-base1:1.0.5

Versions of packages tigervnc-standalone-server suggests:
ii  xfonts-100dpi1:1.0.4+nmu1.1
ii  xfonts-75dpi 1:1.0.4+nmu1.1
ii  xfonts-scalable  1:1.0.3-1.2

-- Configuration Files:
/etc/tigervnc/vncserver.users changed [not included]

-- no debconf information
From e294924ba45618051f3e058a6a2fde1a6a7fc4f1 Mon Sep 17 00:00:00 2001
From: Joachim Falk 
Date: Sun, 16 Jan 2022 01:55:06 +0100
Subject: [PATCH] Fixed tigervncserver -list for servers not using a rfbport
 from range 5900 - 5999.

Use of uninitialized value $usedDisplay in concatenation (.) or string at 
/usr/share/perl5/TigerVNC/Wrapper.pm line 353.
Use of uninitialized value $usedDisplay in concatenation (.) or string at 
/usr/share/perl5/TigerVNC/Wrapper.pm line 356
---
 debian/helpers/usr/share/perl5/TigerVNC/Wrapper.pm | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/debian/helpers/usr/share/perl5/TigerVNC/Wrapper.pm 
b/debian/helpers/usr/share/perl5/TigerVNC/Wrapper.pm
index 6d9e1f4..f52e754 100644
--- a/debian/helpers/usr/share/perl5/TigerVNC/Wrapper.pm
+++ b/debian/helpers/usr/share/perl5/TigerVNC/Wrapper.pm
@@ -294,12 +294,15 @@ sub runningVncServers {
 $rfbport = $nr;
 $usedDisplay = $nr - 5900 if $nr >= 5900 && $nr <= 5999;
   }
-  my $name= "$HOSTFQDN:$usedDisplay";
   my $client  = undef;
   my $server  = "Xtigervnc";
-  my $DISPLAY = -e "/tmp/.X11-unix/X${usedDisplay}"
-? ":${usedDisplay}"
-: "$HOSTFQDN:${usedDisplay}";
+  my ($name, $DISPLAY) = (undef, undef);
+  if (defined $usedDisplay) {
+$name= "$HOSTFQDN:$usedDisplay";
+$DISPLAY = -e "/tmp/.X11-unix/X${usedDisplay}"
+  ? ":${usedDisplay}"
+  : "$HOSTFQDN:${usedDisplay}";
+  }
   {
 my $logFile = desktopLog($options, $nr);
 my $logFileFh   = File::ReadBackwards->new($logFile);
--
2.34.1

Bug#1000871: [Pkg-tigervnc-devel] Bug#1000871: tigervnc-standalone-server: server fails to start

2022-01-13 Thread Joachim Falk



Hi All,

On 12/1/21 18:49, Celejar wrote:
>>> Primarily the segfault,

as far as I can tell, tigervnc does not segfault. The problem is that the
xfce session segfaults and terminates early. Moreover, default for tigervnc
is on session termination to kill the VNC server.

Try

  tigervncserver -autokill no

to prevent this. Moreover, try

  tigervncserver -xstartup /usr/bin/xterm --

to get a simple X terminal going in the VNC server.
Note the --. Otherwise /usr/bin/xterm will be started with
the session argument, i.e., startxfce4 in your case.
By the way, this is not the standard configuration. Someone
must have edited some configuration files to specify the xfce
session.

Best,

Joachim

Bug#1000871: [Pkg-tigervnc-devel] Bug#1000871: tigervnc-standalone-server: server fails to start

2022-01-13 Thread Joachim Falk


Hi All,

On 12/1/21 18:49, Celejar wrote:
>>> Primarily the segfault,

as far as I can tell, tigervnc does not segfault. The problem is that the
xfce session segfaults and terminates early. Moreover, default for tigervnc
is on session termination to kill the VNC server.

Try

  tigervncserver -autokill no

to prevent this. Moreover, try

  tigervncserver -xstartup /usr/bin/xterm --

to get a simple X terminal going in the VNC server.
Note the --. Otherwise /usr/bin/xterm will be started with
the session argument, i.e., startxfce4 in your case.
By the way, this is not the standard configuration. Someone
must have edited some configuration files to specify the xfce
session.

Best,

Joachim


OpenPGP_signature
Description: OpenPGP digital signature

Bug#985790: unblock: tigervnc/1.11.0+dfsg-2

2021-03-23 Thread Joachim Falk

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pkg-tigervnc-de...@lists.alioth.debian.org

Please unblock package tigervnc

[ Reason ]
Fix for bug #985614.

[ Impact ]
Sharing a VNC session is not possible.

[ Tests ]
I applied the bug fix from upstream and tested that this fixes
the reported bug #985614.

[ Risks ]
TigerVNC is a leaf package, the changes are not complex, and
the applied patch has already been tested by upstream.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock tigervnc/1.11.0+dfsg-2
diff -Nru tigervnc-1.11.0+dfsg/debian/changelog 
tigervnc-1.11.0+dfsg/debian/changelog
--- tigervnc-1.11.0+dfsg/debian/changelog   2021-02-22 18:19:01.0 
+0100
+++ tigervnc-1.11.0+dfsg/debian/changelog   2021-03-22 22:21:28.0 
+0100
@@ -1,3 +1,11 @@
+tigervnc (1.11.0+dfsg-2) unstable; urgency=medium
+
+  [ Joachim Falk ]
+  * Properly handle boolean configuration values in tigervnc-standalone-server
+(Closes: #985614).
+
+ -- Joachim Falk   Mon, 22 Mar 2021 22:21:54 +0100
+
 tigervnc (1.11.0+dfsg-1) unstable; urgency=medium

   [ Joachim Falk ]
diff -Nru 
tigervnc-1.11.0+dfsg/debian/helpers/usr/share/perl5/TigerVNC/Config.pm 
tigervnc-1.11.0+dfsg/debian/helpers/usr/share/perl5/TigerVNC/Config.pm
--- tigervnc-1.11.0+dfsg/debian/helpers/usr/share/perl5/TigerVNC/Config.pm  
2021-02-21 15:24:17.0 +0100
+++ tigervnc-1.11.0+dfsg/debian/helpers/usr/share/perl5/TigerVNC/Config.pm  
2021-03-22 13:46:46.0 +0100
@@ -402,7 +402,7 @@
   &{$override}('shared', undef);
 }
   } elsif (defined $options->{'shared'}) {
-return $options->{'shared'} eq 'never';
+return $options->{'shared'} eq 'never' ? 1 : 0;
   } else {
 return undef;
   }
@@ -415,7 +415,7 @@
   &{$override}('shared', undef);
 }
   } elsif (defined $options->{'shared'}) {
-return $options->{'shared'} eq 'always';
+return $options->{'shared'} eq 'always' ? 1 : 0;
   } else {
 return undef;
   }
diff -Nru 
tigervnc-1.11.0+dfsg/debian/patches/0300-fix-Xtigervnc-boolparam-parsing.patch 
tigervnc-1.11.0+dfsg/debian/patches/0300-fix-Xtigervnc-boolparam-parsing.patch
--- 
tigervnc-1.11.0+dfsg/debian/patches/0300-fix-Xtigervnc-boolparam-parsing.patch  
1970-01-01 01:00:00.0 +0100
+++ 
tigervnc-1.11.0+dfsg/debian/patches/0300-fix-Xtigervnc-boolparam-parsing.patch  
2021-03-22 13:58:35.0 +0100
@@ -0,0 +1,142 @@
+Description: Tolerate specifying -BoolParam 0 and similar
+ .
+ This is needed by vncserver which doesn't know which parameters are boolean,
+ and it cannot use the -Param=Value form as that isn't tolerated by the Xorg
+ code.
+ .
+ This patch is upstream commit 38c6848b30cb1908171f2b4628e345fbf6727b39
+Author: Pierre Ossman 
+
+diff --git a/unix/vncserver/vncserver.in b/unix/vncserver/vncserver.in
+index 25fbbd31..261b258f 100755
+--- a/unix/vncserver/vncserver.in
 b/unix/vncserver/vncserver.in
+@@ -107,7 +107,7 @@ $default_opts{rfbwait} = 3;
+ $default_opts{rfbauth} = "$vncUserDir/passwd";
+ $default_opts{rfbport} = $vncPort;
+ $default_opts{fp} = $fontPath if ($fontPath);
+-$default_opts{pn} = "";
++$default_opts{pn} = undef;
+
+ # Load user-overrideable system defaults
+ LoadConfig($vncSystemConfigDefaultsFile);
+@@ -242,13 +242,13 @@ push(@cmd, "@CMAKE_INSTALL_FULL_BINDIR@/Xvnc", 
":$displayNumber");
+
+ foreach my $k (sort keys %config) {
+   push(@cmd, "-$k");
+-  push(@cmd, $config{$k}) if $config{$k};
++  push(@cmd, $config{$k}) if defined($config{$k});
+   delete $default_opts{$k}; # file options take precedence
+ }
+
+ foreach my $k (sort keys %default_opts) {
+   push(@cmd, "-$k");
+-  push(@cmd, $default_opts{$k}) if $default_opts{$k};
++  push(@cmd, $default_opts{$k}) if defined($default_opts{$k});
+ }
+
+ warn "\nNew '$desktopName' desktop is $host:$displayNumber\n\n";
+@@ -291,7 +291,7 @@ sub LoadConfig {
+   # current config file being loaded defined the logical opposite 
setting
+   # (NeverShared vs. AlwaysShared, etc etc).
+   $toggle = lc($1); # must normalize key case
+-  $config{$toggle} = $k;
++  $config{$toggle} = undef;
+ }
+   }
+   close(IN);
+diff --git a/unix/xserver/hw/vnc/RFBGlue.cc b/unix/xserver/hw/vnc/RFBGlue.cc
+index f108fae4..7c32bea8 100644
+--- a/unix/xserver/hw/vnc/RFBGlue.cc
 b/unix/xserver/hw/vnc/RFBGlue.cc
+@@ -143,6 +143,22 @@ const char* vncGetParamDesc(const char *name)
+   return param->getDescription();
+ }
+
++int vncIsParamBool(const char *name)
++{
++  VoidParameter *param;
++  BoolParameter *bparam;
++
++  p

Bug#985000: Merge request for nfs-utils to fix bugs #985000 and #985002

2021-03-11 Thread Joachim Falk

Hi All,

Am 07.03.21 um 08:40 schrieb Salvatore Bonaccorso:
> Hi Felix,
>
> On Sat, Mar 06, 2021 at 11:26:36PM -0800, Felix Lechner wrote:
>> Hi Salvatore,
>>
>> On Sat, Mar 6, 2021 at 2:15 AM Joachim Falk  wrote:
>>>
>>> I have a merge request open on nfs-utils.
>>
>> I would like to second this request, please. I filed (or patched) some
>> of these bugs, but someone downgraded them from the RC level. They are
>> on my list of open items for bullseye: I plan to potentially upgrade
>> the severities again, after consulting with the release team. Your
>> input would be much appreciated. Thanks!
>>
>> Thank you, Joachim, for advancing these grave issues in a helpful way!
>
> Can you check which ones the release team accepts as potentially to be
> be fixed at this stage of the release, and then we really can aim to
> take those.

can we get some more bugs fixed? I created bug reports for two more problems
that were fixed in my previous merge request. Moreover, there is now a merge 
request
( https://salsa.debian.org/kernel-team/nfs-utils/-/merge_requests/7 ) 
exclusively to
fix those bugs. The patches are one or two liners and, hence, should be 
uncontroversial.
The merge request should cleanly apply to the current master.

Best,

Joachim

OpenPGP_signature
Description: OpenPGP digital signature

Bug#913531: Recheck

2021-03-11 Thread Joachim Falk

Heads up, this is still present in Debian bullseye with gdm3 version 3.38.2.1-1.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985002: nfs-common: Degraded system state if nfs-common installed and /etc/krb5.keytab present

2021-03-11 Thread Joachim Falk

Package: nfs-common
Version: 1:1.3.4-4
Severity: normal
Tags: patch
X-Debbugs-Cc: felix.lech...@lease-up.com

The nfs-client.target requires the auth-rpcgss-module.service, which in
turn requires rpc-svcgssd.service. However, the rpc.svcgssd daemon is
not needed for an NFS client, even when using Kerberos security.
Moreover, starting this daemon with its default configuration will fail
when no nfs/@REALM principal is in the kerberos keytab. Thus,
resulting in a degraded system state for NFS client configurations
without nfs/@REALM principal in the kerberos keytab. However, this
is a perfectly valid NFS client configuration as the nfs/@REALM
principal is not required for mounting NFS file systems. This is even
the case when Kerberos security is enabled for the mount!

Note that installing the gssproxy packed hides this problem as this
disables the rpc-svcgssd.service.

-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
-- /etc/default/nfs-common --
SMNOTIFYARGS=""
RPCIDMAPDARGS=""
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=
NEED_GSSD=
RPCGSSDOPTS=
-- /etc/idmapd.conf --
[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
Domain = jfalk.de
Local-Realms = JFAD.JFALK.DE
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
-- /etc/fstab --
nfs.jfalk.de:/home  /home   nfs4
sec=krb5p,nodev,nosuid,noatime,async0   0
nfs.jfalk.de:/local /local  nfs4
sec=krb5p,nodev,nosuid,noatime,async0   0
nfs.jfalk.de:/opt   /optnfs4
sec=krb5p,nodev,nosuid,noatime,async0   0
# the auto mounter map /etc/auto.nfs handles these
#nfs.jfalk.de:/bulk-data/bulk-data  nfs4
sec=krb5p,nodev,nosuid,noatime,async0   0
-- /proc/mounts --
nfs.jfalk.de:/local /local nfs4 
rw,nosuid,nodev,noatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5p,clientaddr=192.168.192.128,local_lock=none,addr=192.168.194.37
 0 0
nfs.jfalk.de:/opt /opt nfs4 
rw,nosuid,nodev,noatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5p,clientaddr=192.168.192.128,local_lock=none,addr=192.168.194.37
 0 0
nfs.jfalk.de:/home /home nfs4 
rw,nosuid,nodev,noatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5p,clientaddr=192.168.192.128,local_lock=none,addr=192.168.194.37
 0 0
/etc/auto.nfs /var/autofs/nfs autofs 
rw,relatime,fd=6,pgrp=1106,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=12280
 0 0

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (520, 'testing'), (500, 'testing-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-4-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nfs-common depends on:
ii  adduser 3.118
ii  keyutils1.6.1-2
ii  libc6   2.31-9
ii  libcap2 1:2.44-1
ii  libcom-err2 1.46.1-1
ii  libdevmapper1.02.1  2:1.02.175-2.1
ii  libevent-2.1-7  2.1.12-stable-1
ii  libgssapi-krb5-21.18.3-4
ii  libkeyutils11.6.1-2
ii  libkrb5-3   1.18.3-4
ii  libmount1   2.36.1-7
ii  libnfsidmap20.25-6
ii  libtirpc3   1.3.1-1
ii  libwrap07.6.q-31
ii  lsb-base11.1.0
ii  rpcbind 1.2.5-9
ii  ucf 3.0043

Versions of packages nfs-common recommends:
pn  python  

Versions of packages nfs-common suggests:
pn  open-iscsi  
pn  watchdog

-- Configuration Files:
/etc/default/nfs-common changed:
SMNOTIFYARGS=""
RPCIDMAPDARGS=""
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=
NEED_GSSD=
RPCGSSDOPTS=


-- no debconf information
Description: The rpc.svcgssd daemon is not needed for an NFS client, even
 when using Kerberos security. Moreover, starting this daemon with its
 default configuration will fail when no nfs/@REALM principal is in
 the krb5.keytab. Furthermore, the nfs/@REALM principal is unneeded
 for an NFS client configuration. Thus, resulting in a degraded system
 state for NFS client configurations without nfs/@REALM principal
 in the krb5.keytab.
Author: Joachim Falk 

Index: pkg-nfs-utils/systemd/auth-rpcgss-module.service
===
--- pkg-nfs-utils.orig/systemd/auth-rpcgss-module.service   2020-09-04 
10:04:07.018816047 +0200
+++ pkg-nfs-utils/systemd/auth-rpcgss-module.service2020-09-04 
10:04:25.586617690 +0200
@@

Bug#985000: nfs-common: auth-rpcgss-module.service fails inside Linux containers (LXC)

2021-03-11 Thread Joachim Falk

Package: nfs-common
Version: 1:1.3.4-5
Severity: important
Tags: patch
X-Debbugs-Cc: joachim.f...@gmx.de, felix.lech...@lease-up.com

To fix this problem, the auth_rpcgss kernel module must only be loaded
if it is not already loaded. Otherwise, the auth-rpcgss-module service
will fail inside a Linux container as the loading of kernel modules is
forbidden for the container. Thus, the "/sbin/modprobe -q auth_rpcgss"
call will fail even if the auth_rpcgss kernel module was already loaded.
This has been testesd with kmod up to version 28-1 (current in bullseye
as of 2021-03-11). This situation occurs when the container host already
loaded the auth_rpcgss kernel module to enable kerberized NFS service
for its containers.

-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
151   udp  40401  mountd
151   tcp  58455  mountd
152   udp  49124  mountd
152   tcp  60609  mountd
153   udp  47861  mountd
153   tcp  51113  mountd
133   tcp   2049  nfs
134   tcp   2049  nfs
1002273   tcp   2049
133   udp   2049  nfs
1002273   udp   2049
1000211   udp  47640  nlockmgr
1000213   udp  47640  nlockmgr
1000214   udp  47640  nlockmgr
1000211   tcp  33781  nlockmgr
1000213   tcp  33781  nlockmgr
1000214   tcp  33781  nlockmgr
-- /etc/default/nfs-common --
SMNOTIFYARGS=""
RPCIDMAPDARGS=""
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=
NEED_GSSD=
RPCGSSDOPTS=
-- /etc/idmapd.conf --
[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
Domain = jfalk.de
Local-Realms = JFAD.JFALK.DE
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
-- /etc/fstab --
nfs.jfalk.de:/home  /home   nfs4
sec=krb5p,nodev,nosuid,noatime,async0   0
nfs.jfalk.de:/local /local  nfs4
sec=krb5p,nodev,nosuid,noatime,async0   0
nfs.jfalk.de:/opt   /optnfs4
sec=krb5p,nodev,nosuid,noatime,async0   0
nfs.jfalk.de:/bulk-data /bulk-data  nfs4
sec=krb5p,nodev,nosuid,noatime,async0   0

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (520, 'testing'), (500, 'testing-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-14-amd64 (SMP w/16 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nfs-common depends on:
ii  adduser 3.118
ii  keyutils1.6.1-2
ii  libc6   2.31-9
ii  libcap2 1:2.44-1
ii  libcom-err2 1.46.1-1
ii  libdevmapper1.02.1  2:1.02.175-2.1
ii  libevent-2.1-7  2.1.12-stable-1
ii  libgssapi-krb5-21.18.3-4
ii  libkeyutils11.6.1-2
ii  libkrb5-3   1.18.3-4
ii  libmount1   2.36.1-7
ii  libnfsidmap20.25-6
ii  libtirpc3   1.3.1-1
ii  libwrap07.6.q-31
ii  lsb-base11.1.0
ii  rpcbind 1.2.5-9
ii  ucf 3.0043

Versions of packages nfs-common recommends:
pn  python  

Versions of packages nfs-common suggests:
pn  open-iscsi  
pn  watchdog

Versions of packages nfs-kernel-server depends on:
ii  keyutils  1.6.1-2
ii  libblkid1 2.36.1-7
ii  libc6 2.31-9
ii  libcap2   1:2.44-1
ii  libsqlite3-0  3.34.1-3
ii  libtirpc3 1.3.1-1
ii  libwrap0  7.6.q-31
ii  lsb-base  11.1.0
ii  netbase   6.2
ii  ucf   3.0043

-- no debconf information
Description: Only try to load the auth_rpcgss kernel module if it is not
 already loaded. Otherwise, the auth-rpcgss-module service might fail inside a
 Linux container where the loading of kernel modules is forbidden for the
 container. In this case, the "/sbin/modprobe -q auth_rpcgss" call will fail
 even if the auth_rpcgss kernel module was already loaded. This has been testesd
 with kmod up to version 27+20200310-2. This situation occurs when the container
 host already loaded the auth_rpcgss kernel module to enable kerberized NFS
 service for its containers.
Author: Joachim Falk 

--- a/systemd/auth-rpcgss-module.service.orig   2020-08-26 19:17:27.761451866 
+0200
+++ b/systemd/auth-rpcgss-module.service2020-08-26 19:18:16.988795354 
+0200
@@ -13,4 +13,4 @@

 [Service]
 Type=oneshot
-ExecStart=/sbin/modprobe -q auth_rpcgss
+ExecStart=/bin/sh -c '( /sbin/lsmod | grep -q "^auth_rpcgss\\>" ) || 
/sbin/modprobe -q auth_rpcgss'
Description: Only try to load the auth_rpcgss kernel module if it is not
 alre

Bug#984826: tigervnc-standalone-server: Unable to init server: Could not connect: Connection refused

2021-03-08 Thread Joachim Falk

Am 8. März 2021 23:30:11 MEZ schrieb Matthias Klein :
>Am Mon, 8 Mar 2021 22:44:37 +0100
>schrieb Joachim Falk :
>
>> Hi Matthias,
>> 
>> I tried to replicate the problem, but could start the mate desktop
>> just fine. I will attache my configuration. I used
>
>Hi Joachim,
>
>Thanks a lot for your help!
>
>> Can you try to start something simpler to determine where exactly the
>> problem is? Use something like: tigervncserver --localhost no
>> --xstartup /usr/bin/xterm This should get you a VNC session running a
>> simple xterm.
>
>The call tigervncserver --localhost no --xstartup /usr/bin/xterm
>started an xterm and the MATE desktop in the background.
>
>After that I tried some variants in the ~/xstartup file. I got the
>original content from the internet, and didn't really understand it.
>
>The following variant works:
>unset SESSION_MANAGER
>unset DBUS_SESSION_BUS_ADDRESS
>/usr/bin/mate-session
>
>That means instead of "exec /usr/bin/mate-session &" I now use
>"/usr/bin/mate-session" in the last line.
>
>Do you have any idea why the original call doesn't work anymore, and
>what is the difference between the calls?
>
>Many greetings,
>Matthias

In 1.11, autokill is enabled on default. If autokill is enabled, then the 
Xtigervnc server is killed when the xstartup script terminates. If you use 
"/usr/bin/mate-session &", then the xstartup script will immediately terminates 
because the mate desktop is started in the background, that is what the & does. 
Removing the & will start the mate desktop in the foreground, which means the 
xstartup script will only terminate after you have logged out of the desktop.
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#984826: tigervnc-standalone-server: Unable to init server: Could not connect: Connection refused

2021-03-08 Thread Joachim Falk

Hi Matthias,

I tried to replicate the problem, but could start the mate desktop just fine.
I will attache my configuration. I used

apt install mate-core

and used the default configuration in /etc/tigervnc. Moreover, I have

[bash joachim@xerstin:~]$ ls -la ~/.vnc/
drwxrwxr-x   2 joachim joachimg  4096  8. Mär 22:19 .
drwxr-x--x 187 joachim joachimg 20480  8. Mär 22:29 ..
-rw-rw-r--   1 joachim joachimg  6098  8. Mär 22:28 alpha.jfalk.de:5901.log
-rw-rw-r--   1 joachim joachimg 6  8. Mär 22:19 alpha.jfalk.de:5901.pid
-rw---   1 joachim joachimg 8  8. Mär 22:12 passwd
-rwxr-xr-x   1 joachim joachimg91  8. Mär 22:10 xstartup

[bash joachim@xerstin:~]$ cat .vnc/xstartup
#! /bin/sh
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
exec /usr/bin/mate-session

I used the following command to start.
[bash joachim@alpha:~]$ tigervncserver --localhost no

New Xtigervnc server 'alpha.jfalk.de:1 (joachim)' on port 5901 for display :1.
Use xtigervncviewer -SecurityTypes VncAuth,TLSVnc -passwd 
/home/joachim/.vnc/passwd alpha.jfalk.de:1 to connect to the VNC server.

I used tigervncserver --list to confirm that the server is running.
[bash joachim@alpha:~]$ tigervncserver --list

TigerVNC server sessions:

X DISPLAY # RFB PORT #  PROCESS ID  SERVER
:1  590129417   Xtigervnc

Moreover, connecting to alpha.jfalk.de:1 with a VNC viewer gets me the mate 
desktop environment.

Can you try to start something simpler to determine where exactly the problem 
is?
Use something like: tigervncserver --localhost no --xstartup /usr/bin/xterm
This should get you a VNC session running a simple xterm.

Best,

Joachim


vnc-configs.tgz
Description: application/compressed-tar


OpenPGP_signature
Description: OpenPGP digital signature

Bug#846950: Merge request for nfs-utils to fix bugs #846950, #849942, #849608

2021-03-06 Thread Joachim Falk

Hi Salvatore,

I have a merge request 
(https://salsa.debian.org/kernel-team/nfs-utils/-/merge_requests/5) open
on nfs-utils. This merge request was marked as WIP due to possible porting to 
nfs-utils 2.4.1.
However, as bullseye froze softly, a switch to nfs-utils 2.4.1 seems unlikely. 
I CCed all the
fixed bugs asking for feedback, unfortunately there was almost no response. 
However, the patched
nfs-utils 1:1.3.4-5~RC5 has run on my machines for half a year now without any 
issues.

Hence, would you consider applying the merge request as is to fix these bugs. 
Explanation and
fixed issues are described below:

  * debian/nfs-utils_env.sh: Correctly propagate RPCGSSDOPTS from
/etc/default/nfs-common to rpc-gssd.service. Even though RPCGSSDOPTS
was not documented or explicitly exposed in /etc/default/nfs-common,
it’s used by the init script and there are people that have been
relying on this for a while. (Closes: #846950)
  * Replace hardcoded keytab check in rpc-gssd.service with NEED_GSSD and
auto detection of kerberized NFS mounts in /etc/fstab. Auto detection
logic is in the nfs-utils_need_gssd_check.sh script. (Closes: #849608)
  * Fix kerberized NFS service inside Linux containers when the container
host loads the auth_rpcgss kernel module to enable kerberized NFS
service for its containers.
  * Replace hardcoded keytab check in rpc-svcgssd.service with NEED_SVCGSSD
and auto detection of kerberized NFS exports in /etc/exports. Auto
detection logic is in the nfs-utils_need_svcgssd_check.sh script.
(Closes: #849942)
  * Replace hardcoded keytab check in auth-rpcgss-module.service with
NEED_GSSD and auto detection of kerberized NFS mounts in /etc/fstab as
well as NEED_SVCGSSD and auto detection of kerberized NFS exports in
/etc/exports. Auto detection logic is in the scripts
nfs-utils_need_gssd_check.sh and nfs-utils_need_svcgssd_check.sh.
(Closes: #849942, #849608)
  * Only start the rpc-svcgssd.service when the nfs-kernel-server.service is
requested. The rpc.svcgssd daemon is not needed for an NFS client, even
when using Kerberos security. Moreover, starting this daemon with its
default configuration will fail when no nfs/@REALM principal is in
the krb5.keytab. Furthermore, the nfs/@REALM principal is unneeded
for an NFS client configuration. Thus, resulting in a degraded system
state for NFS client configurations without nfs/@REALM principal in
the krb5.keytab.

With kind Regards,

Joachim Falk



OpenPGP_signature
Description: OpenPGP digital signature

Bug#971392: buster-pu: package tigervnc/1.9.0+dfsg-3+deb10u3

2020-09-29 Thread Joachim Falk

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Security fix for CVE-2020-26117 as detailed in bug #971272.

-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-9-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru tigervnc-1.9.0+dfsg/debian/changelog 
tigervnc-1.9.0+dfsg/debian/changelog
--- tigervnc-1.9.0+dfsg/debian/changelog2020-06-16 21:36:31.0 
+0200
+++ tigervnc-1.9.0+dfsg/debian/changelog2020-09-29 20:21:20.0 
+0200
@@ -1,3 +1,13 @@
+tigervnc (1.9.0+dfsg-3+deb10u3) buster; urgency=high
+
+  [ Joachim Falk ]
+  * Properly store certificate exceptions in native and java VNC viewer. The
+VNC viewers stored the certificate exceptions as authorities, meaning that
+the owner of a certificate could impersonate any server after a client had
+added an exception. This is issue CVE-2020-26117 (Closes: #971272).
+
+ -- Joachim Falk   Tue, 29 Sep 2020 20:21:20 +0200
+
 tigervnc (1.9.0+dfsg-3+deb10u2) buster; urgency=medium

   [ Joachim Falk ]
diff -Nru tigervnc-1.9.0+dfsg/debian/patches/CVE-2020-26117.patch 
tigervnc-1.9.0+dfsg/debian/patches/CVE-2020-26117.patch
--- tigervnc-1.9.0+dfsg/debian/patches/CVE-2020-26117.patch 1970-01-01 
01:00:00.0 +0100
+++ tigervnc-1.9.0+dfsg/debian/patches/CVE-2020-26117.patch 2020-09-29 
20:21:20.0 +0200
@@ -0,0 +1,460 @@
+Description: Properly store certificate exceptions in native and java VNC 
viewer.
+ They stored the certificates as authorities, meaning that the owner of a
+ certificate could impersonate any server after a client had added an 
exception.
+Author: Pierre Ossman  and Brian P. Hinz 

+Abstract:
+ Properly store certificate exceptions
+ .
+ . git commit b30f10c681ec87720cff85d490f67098568a9cba
+ .
+ The previous method stored the certificates as authorities, meaning that
+ the owner of that certificate could impersonate any server it wanted
+ after a client had added an exception.
+ .
+ Handle this more properly by only storing exceptions for specific
+ hostname/certificate combinations, the same way browsers or SSH does
+ things.
+ .
+ . git commit f029745f63ac7d22fb91639b2cb5b3ab56134d6e
+ .
+ Like the native viewer, the Java viewer didn't store certificate
+ exceptions properly. Whilst not as bad as the native viewer, it still
+ failed to check that a stored certificate wouldn't be maliciously used
+ for another server. In practice this can in most cases be used to
+ impersonate another server.
+ .
+ Handle this like the native viewer by storing exceptions for a specific
+ hostname/certificate combination.
+ .
+ This issue is CVE-2020-26117.
+
+Index: pkg-tigervnc/common/rfb/CSecurityTLS.cxx
+===
+--- pkg-tigervnc.orig/common/rfb/CSecurityTLS.cxx
 pkg-tigervnc/common/rfb/CSecurityTLS.cxx
+@@ -232,22 +232,6 @@ void CSecurityTLS::setParam()
+ if (*cafile && 
gnutls_certificate_set_x509_trust_file(cert_cred,cafile,GNUTLS_X509_FMT_PEM) < 
0)
+   throw AuthFailureException("load of CA cert failed");
+
+-/* Load previously saved certs */
+-char *homeDir = NULL;
+-int err;
+-if (getvnchomedir() == -1)
+-  vlog.error("Could not obtain VNC home directory path");
+-else {
+-  CharArray caSave(strlen(homeDir) + 19 + 1);
+-  sprintf(caSave.buf, "%sx509_savedcerts.pem", homeDir);
+-  delete [] homeDir;
+-
+-  err = gnutls_certificate_set_x509_trust_file(cert_cred, caSave.buf,
+-   GNUTLS_X509_FMT_PEM);
+-  if (err < 0)
+-vlog.debug("Failed to load saved server certificates from %s", 
caSave.buf);
+-}
+-
+ if (*crlfile && 
gnutls_certificate_set_x509_crl_file(cert_cred,crlfile,GNUTLS_X509_FMT_PEM) < 0)
+   throw AuthFailureException("load of CRL failed");
+
+@@ -272,7 +256,10 @@ void CSecurityTLS::checkSession()
+   const gnutls_datum_t *cert_list;
+   unsigned int cert_list_size = 0;
+   int err;
++
++  char *homeDir;
+   gnutls_datum_t info;
++  size_t len;
+
+   if (anon)
+ return;
+@@ -315,13 +302,13 @@ void CSecurityTLS::checkSession()
+ throw AuthFailureException("decoding of certificate failed");
+
+   if (gnutls_x509_crt_check_hostname(crt, client->getServerName()) == 0) {
+-char buf[255];
++CharArray text;
+ vlog.debug("hostname mismatch");
+-snprintf(buf, sizeof(buf), "Hostname (%s) does not match any certificate, 
"
+- "do you want t

Bug#971272: tigervnc-viewer: VNC viewer certificate exceptions are mistakenly handled as certificate authorities

2020-09-28 Thread Joachim Falk

Package: tigervnc-viewer
Version: 1.7.0+dfsg-1
Severity: normal
Tags: upstream

 The VNC viewer mistakenly handles certificate exceptions as
 certificate authorities. Thus, the owner of a certificate, for
 which an exception was added, can impersonate any VNC server.

 This is issue CVE-2020-26117.

-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-9-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tigervnc-viewer depends on:
ii  libc6  2.28-10
ii  libfltk-images1.3  1.3.4-9
ii  libfltk1.3 1.3.4-9
ii  libgcc11:8.3.0-6
ii  libgnutls303.6.7-4+deb10u5
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libstdc++6 8.3.0-6
ii  libx11-6   2:1.6.7-1+deb10u1
ii  libxext6   2:1.3.3-1+b2
ii  libxrender11:0.9.10-1
ii  zlib1g 1:1.2.11.dfsg-1

tigervnc-viewer recommends no packages.

Versions of packages tigervnc-viewer suggests:
ii  tigervnc-common  1.10.1+dfsg-8~bpo10+1

-- no debconf information

Bug#846950: Fixes for bugs #846950, #849942, #849608

2020-09-21 Thread Joachim Falk

Hi all,

I hopefully fixed these bugs in my Debian bullseye package. Could you
all test 1:1.3.4-5~RC5. This can be found for AMD64 under

deb http://www.jfalk.de homebrew-bullseye patched recompiled selfmade

If you use another architecture, you have to compile from source.
The source for the fixes can be found in the following git repository:

git clone https://salsa.debian.org:jfalk-guest/nfs-utils.git -b jfalk

Hopefully, we can convince the Debian kernel team to merge these changes
into the nfs-utils Debian package in time for the Debian bullseye release.

nfs-utils (1:1.3.4-5~RC5) UNRELEASED; urgency=medium

  [ Joachim Falk ]
  * debian/nfs-utils_env.sh: Correctly propagate RPCGSSDOPTS from
/etc/default/nfs-common to rpc-gssd.service. Even though RPCGSSDOPTS
was not documented or explicitly exposed in /etc/default/nfs-common,
it’s used by the init script and there are people that have been
relying on this for a while. (Closes: #846950)
  * Replace hardcoded keytab check in rpc-gssd.service with NEED_GSSD and
auto detection of kerberized NFS mounts in /etc/fstab. Auto detection
logic is in the nfs-utils_need_gssd_check.sh script. (Closes: #849608)
  * Fix kerberized NFS service inside Linux containers when the container
host loads the auth_rpcgss kernel module to enable kerberized NFS
service for its containers.
  * Replace hardcoded keytab check in rpc-svcgssd.service with NEED_SVCGSSD
and auto detection of kerberized NFS exports in /etc/exports. Auto
detection logic is in the nfs-utils_need_svcgssd_check.sh script.
(Closes: #849942)
  * Replace hardcoded keytab check in auth-rpcgss-module.service with
NEED_GSSD and auto detection of kerberized NFS mounts in /etc/fstab as
well as NEED_SVCGSSD and auto detection of kerberized NFS exports in
/etc/exports. Auto detection logic is in the scripts
nfs-utils_need_gssd_check.sh and nfs-utils_need_svcgssd_check.sh.
(Closes: #849942, #849608)
  * Only start the rpc-svcgssd.service when the nfs-kernel-server.service is
requested. The rpc.svcgssd daemon is not needed for an NFS client, even
when using Kerberos security. Moreover, starting this daemon with its
default configuration will fail when no nfs/@REALM principal is in
the krb5.keytab. Furthermore, the nfs/@REALM principal is unneeded
for an NFS client configuration. Thus, resulting in a degraded system
state for NFS client configurations without nfs/@REALM principal in
the krb5.keytab.

 -- Joachim Falk   Fri, 04 Sep 2020 10:28:49 +0200

Best,

Joachim



signature.asc
Description: OpenPGP digital signature

Bug#965143: sssd-ad: Login issues with SSSD 2.3 for AD back end

2020-07-18 Thread Joachim Falk

Package: sssd-ad
Version: 2.3.0-2
Followup-For: Bug #965143

I might have a related issue with logins for AD accounts. I fixed
ndr_pull_security_ace to again correctly parse GPOs in the AD back end.
Without this fix, SSS_PAM_ACCT_MGMT fails for pam_sss, and users can not log
in. A symptom of the bug is the following line in the log:
  "[ad_gpo_parse_sd] (0x0020): Failed to pull security descriptor"

Patch is attached.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (520, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sssd-ad depends on:
ii  libc6 2.30-8
ii  libdhash1 0.6.1-2
ii  libini-config50.6.1-2
ii  libldap-2.4-2 2.4.50+dfsg-1
ii  libldb2   2:2.1.4-2
ii  libpopt0  1.18-1
ii  libsasl2-22.1.27+dfsg-2
ii  libsmbclient  2:4.12.5+dfsg-3
ii  libsss-idmap0 2.3.0-2
ii  libtalloc22.3.1-1
ii  libtevent00.10.2-1
ii  samba-libs2:4.12.5+dfsg-3
ii  sssd-ad-common2.3.0-2
ii  sssd-common   2.3.0-2
ii  sssd-krb5-common  2.3.0-2

sssd-ad recommends no packages.

Versions of packages sssd-ad suggests:
pn  adcli  

-- no debconf information
Author: Joachim Falk 
Description: In sssd 2.3.0, ndr_pull_security_ace_object_ctr was migrated
 from
   level = ndr_pull_get_switch_value(ndr, r);
 to
   #ifdef SMB_HAS_NEW_NDR_PULL_STEAL_SWITCH
 NDR_CHECK(ndr_pull_steal_switch_value(ndr, r, ));
   #else
 level = ndr_pull_steal_switch_value(ndr, r);
   #endif
 In the case of SMB_HAS_NEW_NDR_PULL_STEAL_SWITCH, this will fail if
 ndr_pull_set_switch_value is not previously used to set a switch value.
 However, ndr_pull_security_ace does not do this in the case of NDR_BUFFERS.
 This patch corrects this oversight.
 .
 Without this patch, the sssd AD back end can not correctly parse GPOs. As a
 result, SSS_PAM_ACCT_MGMT fails for pam_sss, and users can not log in. A
 symptom of the bug is the following line in the log:
 "[ad_gpo_parse_sd] (0x0020): Failed to pull security descriptor"

Index: pkg-sssd/src/providers/ad/ad_gpo_ndr.c
===
--- pkg-sssd.orig/src/providers/ad/ad_gpo_ndr.c
+++ pkg-sssd/src/providers/ad/ad_gpo_ndr.c
@@ -317,6 +317,7 @@ ndr_pull_security_ace(struct ndr_pull *n
 ndr->offset += pad;
 }
 if (ndr_flags & NDR_BUFFERS) {
+NDR_CHECK(ndr_pull_set_switch_value(ndr, >object, r->type));
 NDR_CHECK(ndr_pull_security_ace_object_ctr
   (ndr, NDR_BUFFERS, >object));
 }

Bug#963024: buster-pu: package tigervnc/1.9.0+dfsg-3+deb10u2

2020-07-09 Thread Joachim Falk

Hi Adam,

Am 09.07.20 um 21:44 schrieb Adam D. Barratt:
> Control: tags -1 + confirmed
>
> [SNIP]
>
> Please go ahead.

I just have uploaded tigervnc/1.9.0+dfsg-3+deb10u2 to proposed-updates.

Best,

Joachim



signature.asc
Description: OpenPGP digital signature

Bug#963024: buster-pu: package tigervnc/1.9.0+dfsg-3+deb10u2

2020-06-17 Thread Joachim Falk

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

The tigervnc-standalone-server/1.9.0+dfsg-3+deb10u1 package is affected
by a bug in libunwind8 (Bug: #923962) exhibited on architectures arm64,
armel, and armhf that makes it unusable (Bug: #932499) on those architectures.

As a workaround, the proposed update tigervnc/1.9.0+dfsg-3+deb10u2
disables building against libunwind on exactly these three architectures.
Other architectures are not affected by the proposed update.

-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 4.19.0-9-arm64 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru tigervnc-1.9.0+dfsg/debian/changelog 
tigervnc-1.9.0+dfsg/debian/changelog
--- tigervnc-1.9.0+dfsg/debian/changelog2020-01-23 19:03:00.0 
+0100
+++ tigervnc-1.9.0+dfsg/debian/changelog2020-06-16 21:36:31.0 
+0200
@@ -1,3 +1,11 @@
+tigervnc (1.9.0+dfsg-3+deb10u2) buster; urgency=medium
+
+  [ Joachim Falk ]
+  * Don't use libunwind for armel, armhf, and arm64 as this library is buggy
+(bug #923962) on those architectures (Closes: #932499).
+
+ -- Joachim Falk   Tue, 16 Jun 2020 21:36:31 +0200
+
 tigervnc (1.9.0+dfsg-3+deb10u1) buster; urgency=high
 
   [ Joachim Falk ]
diff -Nru tigervnc-1.9.0+dfsg/debian/control tigervnc-1.9.0+dfsg/debian/control
--- tigervnc-1.9.0+dfsg/debian/control  2020-01-23 19:02:50.0 +0100
+++ tigervnc-1.9.0+dfsg/debian/control  2020-06-16 21:36:31.0 +0200
@@ -54,7 +54,8 @@
  libaudit-dev [linux-any],
  libdrm-dev (>= 2.4.89) [!hurd-i386],
  libgl1-mesa-dev (>= 9.2),
- libunwind-dev [amd64 arm64 armel armhf hppa i386 ia64 mips64 mips64el mipsel 
powerpc powerpcspe ppc64 ppc64el sh4],
+# Don't use libunwind for armel, armhf, and arm64 as this library is buggy 
(bug #923962) on those architectures.
+ libunwind-dev [amd64 hppa i386 ia64 mips64 mips64el mipsel powerpc powerpcspe 
ppc64 ppc64el sh4],
  libxmuu-dev (>= 1:0.99.1),
  libxext-dev (>= 1:0.99.1),
  libx11-dev (>= 2:1.6),
diff -Nru tigervnc-1.9.0+dfsg/debian/rules tigervnc-1.9.0+dfsg/debian/rules
--- tigervnc-1.9.0+dfsg/debian/rules2020-01-23 19:02:51.0 +0100
+++ tigervnc-1.9.0+dfsg/debian/rules2020-06-16 21:36:31.0 +0200
@@ -25,6 +25,7 @@
 
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/cmake.mk
+include /usr/share/dpkg/architecture.mk
 
 # Do our complex patch dance first! After that quilt patch system can proceed!
 clean:: unpatch
@@ -192,7 +193,7 @@
 #-include /usr/share/xserver-xorg/configure_flags.mk
 #xserver_confflags := $(shell echo '$(xserver_confflags)' | sed 
's/--with-builderstring="[^"]*"//')
 
-XORG_DEBIAN_CONFIGURE_FLAGS = \
+XORG_DEBIAN_CONFIGURE_FLAGS := \
$(filter-out \
--prefix=% \
--mandir=% \
@@ -214,6 +215,14 @@
, $(xserver_confflags) \
)
 
+# Don't use libunwind for armel, armhf, and arm64 as this library is buggy
+# (bug #923962) on those architectures.
+ifneq (,$(filter $(DEB_HOST_ARCH), armel armhf arm64))
+   DEB_CONFIGURE_EXTRA_FLAGS += --disable-libunwind
+   XORG_DEBIAN_CONFIGURE_FLAGS := \
+   $(filter-out --enable-libunwind, $(XORG_DEBIAN_CONFIGURE_FLAGS))
+endif
+
 # Next step is run configure script. It is very difficult use correct 
parameters.
 # You should use same parameters as used in your distribution X server and add
 # --disable-xvfb --disable-xnest --disable-xorg

Bug#932499: Workaround for TigerVNC on aarch64

2020-06-02 Thread Joachim Falk

Hi RussianNeuroMancer,

Am 31.05.20 um 14:31 schrieb russianneuroman...@ya.ru:
> Hi, Joachim!
> 
> Is there a chance you could apply workaround for aarch64 described in latest 
> message of this thread?
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932499
there is now a fix for this committed to the master branch.
(Repo https://salsa.debian.org/debian-remote-team/tigervnc.git)
Please build from source for arm64 and maybe armel and armhf
and report back.

Best,

Joachim



signature.asc
Description: OpenPGP digital signature

Bug#949853: stretch-pu: package tigervnc/1.7.0+dfsg-7+deb9u1

2020-01-25 Thread Joachim Falk

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Security fixes for CVE-2019-15691, CVE-2019-15692, CVE-2019-15693,
CVE-2019-15694, and CVE-2019-15695 as detailed in bug #947428.

-- System Information:
Debian Release: 9.11
  APT prefers oldstable
  APT policy: (990, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru tigervnc-1.7.0+dfsg/debian/changelog 
tigervnc-1.7.0+dfsg/debian/changelog
--- tigervnc-1.7.0+dfsg/debian/changelog2017-04-09 16:38:13.0 
+0200
+++ tigervnc-1.7.0+dfsg/debian/changelog2020-01-18 19:30:42.0 
+0100
@@ -1,3 +1,11 @@
+tigervnc (1.7.0+dfsg-7+deb9u1) stretch; urgency=high
+
+  [ Joachim Falk ]
+  * Fix CVE-2019-15691, CVE-2019-15692, CVE-2019-15693, CVE-2019-15694, and
+CVE-2019-15695 (Closes: #947428)
+
+ -- Joachim Falk   Sat, 18 Jan 2020 19:30:42 +0100
+
 tigervnc (1.7.0+dfsg-7) unstable; urgency=high

   [ Joachim Falk ]
diff -Nru tigervnc-1.7.0+dfsg/debian/patches/CVE-2019-15691.patch 
tigervnc-1.7.0+dfsg/debian/patches/CVE-2019-15691.patch
--- tigervnc-1.7.0+dfsg/debian/patches/CVE-2019-15691.patch 1970-01-01 
01:00:00.0 +0100
+++ tigervnc-1.7.0+dfsg/debian/patches/CVE-2019-15691.patch 2020-01-18 
19:30:42.0 +0100
@@ -0,0 +1,116 @@
+From d61a767d6842b530ffb532ddd5a3d233119aad40 Mon Sep 17 00:00:00 2001
+From: Pierre Ossman 
+Date: Tue, 10 Sep 2019 11:05:48 +0200
+Subject: [PATCH] Make ZlibInStream more robust against failures
+
+Move the checks around to avoid missing cases where we might access
+memory that is no longer valid. Also avoid touching the underlying
+stream implicitly (e.g. via the destructor) as it might also no
+longer be valid.
+
+A malicious server could theoretically use this for remote code
+execution in the client.
+
+Issue found by Pavel Cheremushkin from Kaspersky Lab
+---
+ common/rdr/ZlibInStream.cxx | 13 +++--
+ common/rdr/ZlibInStream.h   |  2 +-
+ common/rfb/CMsgReader.cxx   |  3 ++-
+ common/rfb/SMsgReader.cxx   |  3 ++-
+ common/rfb/TightDecoder.cxx |  3 ++-
+ common/rfb/zrleDecode.h |  3 ++-
+ 6 files changed, 16 insertions(+), 11 deletions(-)
+
+Index: pkg-tigervnc/common/rdr/ZlibInStream.cxx
+===
+--- pkg-tigervnc.orig/common/rdr/ZlibInStream.cxx
 pkg-tigervnc/common/rdr/ZlibInStream.cxx
+@@ -52,16 +52,16 @@ int ZlibInStream::pos()
+   return offset + ptr - start;
+ }
+
+-void ZlibInStream::removeUnderlying()
++void ZlibInStream::flushUnderlying()
+ {
+   ptr = end = start;
+-  if (!underlying) return;
+
+   while (bytesIn > 0) {
+ decompress(true);
+ end = start; // throw away any data
+   }
+-  underlying = 0;
++
++  setUnderlying(NULL, 0);
+ }
+
+ void ZlibInStream::reset()
+@@ -90,7 +90,7 @@ void ZlibInStream::init()
+ void ZlibInStream::deinit()
+ {
+   assert(zs != NULL);
+-  removeUnderlying();
++  setUnderlying(NULL, 0);
+   inflateEnd(zs);
+   delete zs;
+   zs = NULL;
+@@ -100,8 +100,6 @@ int ZlibInStream::overrun(int itemSize,
+ {
+   if (itemSize > bufSize)
+ throw Exception("ZlibInStream overrun: max itemSize exceeded");
+-  if (!underlying)
+-throw Exception("ZlibInStream overrun: no underlying stream");
+
+   if (end - ptr != 0)
+ memmove(start, ptr, end - ptr);
+@@ -127,6 +125,9 @@ int ZlibInStream::overrun(int itemSize,
+
+ bool ZlibInStream::decompress(bool wait)
+ {
++  if (!underlying)
++throw Exception("ZlibInStream overrun: no underlying stream");
++
+   zs->next_out = (U8*)end;
+   zs->avail_out = start + bufSize - end;
+
+Index: pkg-tigervnc/common/rdr/ZlibInStream.h
+===
+--- pkg-tigervnc.orig/common/rdr/ZlibInStream.h
 pkg-tigervnc/common/rdr/ZlibInStream.h
+@@ -38,7 +38,7 @@ namespace rdr {
+ virtual ~ZlibInStream();
+
+ void setUnderlying(InStream* is, int bytesIn);
+-void removeUnderlying();
++void flushUnderlying();
+ int pos();
+ void reset();
+
+Index: pkg-tigervnc/common/rfb/TightDecoder.cxx
+===
+--- pkg-tigervnc.orig/common/rfb/TightDecoder.cxx
 pkg-tigervnc/common/rfb/TightDecoder.cxx
+@@ -340,7 +340,8 @@ void TightDecoder::decodeRect(const Rect
+
+ zis[streamId].readBytes(netbuf, dataSize);
+
+-zis[streamId].removeUnderlying();
++zis[streamId].flushUnderlying();
++zis[streamId].setUnderlying(NULL, 0);
+ delete ms;
+
+ bufptr = netbuf;
+Index: pkg-tigervnc/common/rfb/zrleDecode.h
+===
+--- pkg-tigervnc.orig/common/rfb/zrleDecode.h
 pkg-t

Bug#949852: buster-pu: package tigervnc/1.9.0+dfsg-3+deb10u1

2020-01-25 Thread Joachim Falk

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Security fixes for CVE-2019-15691, CVE-2019-15692, CVE-2019-15693, 
CVE-2019-15694, and CVE-2019-15695
as detailed in bug #947428.

(please explain the reason for this update here)

-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru tigervnc-1.9.0+dfsg/debian/changelog 
tigervnc-1.9.0+dfsg/debian/changelog
--- tigervnc-1.9.0+dfsg/debian/changelog2018-12-01 22:51:29.0 
+0100
+++ tigervnc-1.9.0+dfsg/debian/changelog2020-01-23 19:03:00.0 
+0100
@@ -1,3 +1,11 @@
+tigervnc (1.9.0+dfsg-3+deb10u1) buster; urgency=high
+
+  [ Joachim Falk ]
+  * Fix CVE-2019-15691, CVE-2019-15692, CVE-2019-15693, CVE-2019-15694, and
+CVE-2019-15695 (Closes: #947428)
+
+ -- Joachim Falk   Thu, 23 Jan 2020 19:03:00 +0100
+
 tigervnc (1.9.0+dfsg-3) unstable; urgency=medium

   [ Joachim Falk ]
diff -Nru tigervnc-1.9.0+dfsg/debian/patches/CVE-2019-15691.patch 
tigervnc-1.9.0+dfsg/debian/patches/CVE-2019-15691.patch
--- tigervnc-1.9.0+dfsg/debian/patches/CVE-2019-15691.patch 1970-01-01 
01:00:00.0 +0100
+++ tigervnc-1.9.0+dfsg/debian/patches/CVE-2019-15691.patch 2020-01-23 
19:02:50.0 +0100
@@ -0,0 +1,116 @@
+From d61a767d6842b530ffb532ddd5a3d233119aad40 Mon Sep 17 00:00:00 2001
+From: Pierre Ossman 
+Date: Tue, 10 Sep 2019 11:05:48 +0200
+Subject: [PATCH] Make ZlibInStream more robust against failures
+
+Move the checks around to avoid missing cases where we might access
+memory that is no longer valid. Also avoid touching the underlying
+stream implicitly (e.g. via the destructor) as it might also no
+longer be valid.
+
+A malicious server could theoretically use this for remote code
+execution in the client.
+
+Issue found by Pavel Cheremushkin from Kaspersky Lab
+---
+ common/rdr/ZlibInStream.cxx | 13 +++--
+ common/rdr/ZlibInStream.h   |  2 +-
+ common/rfb/CMsgReader.cxx   |  3 ++-
+ common/rfb/SMsgReader.cxx   |  3 ++-
+ common/rfb/TightDecoder.cxx |  3 ++-
+ common/rfb/zrleDecode.h |  3 ++-
+ 6 files changed, 16 insertions(+), 11 deletions(-)
+
+Index: pkg-tigervnc/common/rdr/ZlibInStream.cxx
+===
+--- pkg-tigervnc.orig/common/rdr/ZlibInStream.cxx
 pkg-tigervnc/common/rdr/ZlibInStream.cxx
+@@ -52,16 +52,16 @@ int ZlibInStream::pos()
+   return offset + ptr - start;
+ }
+
+-void ZlibInStream::removeUnderlying()
++void ZlibInStream::flushUnderlying()
+ {
+   ptr = end = start;
+-  if (!underlying) return;
+
+   while (bytesIn > 0) {
+ decompress(true);
+ end = start; // throw away any data
+   }
+-  underlying = 0;
++
++  setUnderlying(NULL, 0);
+ }
+
+ void ZlibInStream::reset()
+@@ -90,7 +90,7 @@ void ZlibInStream::init()
+ void ZlibInStream::deinit()
+ {
+   assert(zs != NULL);
+-  removeUnderlying();
++  setUnderlying(NULL, 0);
+   inflateEnd(zs);
+   delete zs;
+   zs = NULL;
+@@ -100,8 +100,6 @@ int ZlibInStream::overrun(int itemSize,
+ {
+   if (itemSize > bufSize)
+ throw Exception("ZlibInStream overrun: max itemSize exceeded");
+-  if (!underlying)
+-throw Exception("ZlibInStream overrun: no underlying stream");
+
+   if (end - ptr != 0)
+ memmove(start, ptr, end - ptr);
+@@ -127,6 +125,9 @@ int ZlibInStream::overrun(int itemSize,
+
+ bool ZlibInStream::decompress(bool wait)
+ {
++  if (!underlying)
++throw Exception("ZlibInStream overrun: no underlying stream");
++
+   zs->next_out = (U8*)end;
+   zs->avail_out = start + bufSize - end;
+
+Index: pkg-tigervnc/common/rdr/ZlibInStream.h
+===
+--- pkg-tigervnc.orig/common/rdr/ZlibInStream.h
 pkg-tigervnc/common/rdr/ZlibInStream.h
+@@ -38,7 +38,7 @@ namespace rdr {
+ virtual ~ZlibInStream();
+
+ void setUnderlying(InStream* is, int bytesIn);
+-void removeUnderlying();
++void flushUnderlying();
+ int pos();
+ void reset();
+
+Index: pkg-tigervnc/common/rfb/TightDecoder.cxx
+===
+--- pkg-tigervnc.orig/common/rfb/TightDecoder.cxx
 pkg-tigervnc/common/rfb/TightDecoder.cxx
+@@ -340,7 +340,8 @@ void TightDecoder::decodeRect(const Rect
+
+ zis[streamId].readBytes(netbuf, dataSize);
+
+-zis[streamId].removeUnderlying();
++zis[streamId].flushUnderlying();
++zis[streamId].setUnderlying(NULL, 0);
+ delete ms;
+
+ bufptr = netbuf;
+Index: pkg-tigervnc/common/rfb/zrleDecode.h
+===
+--- pkg-tige

Bug#929410: [Pkg-tigervnc-devel] Bug#929410: RANDR extension not present

2019-07-21 Thread Joachim Falk

Hi Ola and Mike,

Am 21.07.19 um 14:01 schrieb Mike Gabriel:
> Hi Ola,
> 
> On  So 21 Jul 2019 11:17:31 CEST, Ola Lundqvist wrote:
> 
>> Hi Joachim
>>
>> Thank you. Thinking of this some more we actually did not have this package
>> at all in old stable. Did we have RANDR support in the other vnc packages?
>>
>> // Ola
> 
> AFAIR, VNC in Debian hadn't had RandR (i.e. resizing of the VNC session 
> window resizes the Xvnc server geometry), so far.
no, we already have that in Xtigervnc (i.e., tigervnc-standalone-server). 
However, x0tigervncserver
(i.e., tigervnc-scraping-server) needs libxrandr-dev at compile time to enable 
RANDR support. It uses
RANDR to resize the real Xorg server for which it provides the VNC server.

> The Cendio people have that feature enabled for years, also X2Go's x2goagent 
> (and the new x2gokdrive Xserver) have that feature. A really must have thing, 
> in fact.
> 
> Greets,
> Mike




signature.asc
Description: OpenPGP digital signature

Bug#929410: [Pkg-tigervnc-devel] Bug#929410: Bug#929410: RANDR extension not present

2019-07-18 Thread Joachim Falk

Hi Ola,

Am 30.06.19 um 19:04 schrieb Ola Lundqvist:
> Hi
> 
> It is too late for buster. Deadline has passed more than a week ago. If I had 
> been faster maybe it had been possible.
> 
> Maybe we can get it to a point release. Do you know how much changes there 
> are between 1.9.0+dfsg-3 and the one you mentioned?
> It seems to fall in the criteria to fix regression against current stable.
should fit. Debdiff attached. There are three minor bugs fixed 929410, 932264, 
and 905905. Only code change is a
different WM_CLASS for xtigervncviewer. Moreover, xrandr libraries are now 
enabled. Thus, additional code will be active
in x0tigervncserver.

Best,

Joachim

diff -Nru tigervnc-1.9.0+dfsg/debian/changelog tigervnc-1.9.0+dfsg/debian/changelog
--- tigervnc-1.9.0+dfsg/debian/changelog	2018-12-01 22:51:29.0 +0100
+++ tigervnc-1.9.0+dfsg/debian/changelog	2019-07-18 17:59:04.0 +0200
@@ -1,3 +1,16 @@
+tigervnc (1.9.0+dfsg-4~RC3) UNRELEASED; urgency=medium
+
+  [ Joachim Falk ]
+  * Fix gnome shell integration of xtigervncviewer by updating
+xtigervncviewer.desktop and WM_CLASS of xtigervncviewer. (Closes: #905905)
+  * Added missing dependencies to enable RANDR support in x0tigervncserver,
+i.e., tigervnc-scraping-server. Also ensure that dropping these
+dependencies will lead to a fatal build error in the future. (Closes: #929410)
+  * Bumped version number in Debian provided man pages to TigerVNC 1.9
+(Closes: #932264).
+
+  -- Joachim Falk   Thu, 18 Jul 2019 17:57:33 +0200
+
 tigervnc (1.9.0+dfsg-3) unstable; urgency=medium
 
   [ Joachim Falk ]
diff -Nru tigervnc-1.9.0+dfsg/debian/control tigervnc-1.9.0+dfsg/debian/control
--- tigervnc-1.9.0+dfsg/debian/control	2018-12-01 22:51:29.0 +0100
+++ tigervnc-1.9.0+dfsg/debian/control	2019-06-15 20:50:33.0 +0200
@@ -24,6 +24,7 @@
  libpam0g-dev,
  libxft-dev,
  libxcursor-dev,
+ libxrandr-dev,
  libwrap0-dev,
  libfltk1.3-dev (>= 1.3.3),
  xorg-server-source (>= 2:1.20),
diff -Nru tigervnc-1.9.0+dfsg/debian/helpers/usr/share/man/man1/tigervncserver.1 tigervnc-1.9.0+dfsg/debian/helpers/usr/share/man/man1/tigervncserver.1
--- tigervnc-1.9.0+dfsg/debian/helpers/usr/share/man/man1/tigervncserver.1	2018-12-01 22:50:28.0 +0100
+++ tigervnc-1.9.0+dfsg/debian/helpers/usr/share/man/man1/tigervncserver.1	2019-07-18 17:53:14.0 +0200
@@ -1,4 +1,4 @@
-.TH tigervncserver 1 "Jan 5th, 2017" "TigerVNC 1.7" "Virtual Network Computing"
+.TH tigervncserver 1 "Jul 18th, 2019" "TigerVNC 1.9" "Virtual Network Computing"
 .SH NAME
 tigervncserver \- start or stop a TigerVNC server
 .SH SYNOPSIS
diff -Nru tigervnc-1.9.0+dfsg/debian/helpers/usr/share/man/man5/vnc.conf.5x tigervnc-1.9.0+dfsg/debian/helpers/usr/share/man/man5/vnc.conf.5x
--- tigervnc-1.9.0+dfsg/debian/helpers/usr/share/man/man5/vnc.conf.5x	2018-12-01 22:50:28.0 +0100
+++ tigervnc-1.9.0+dfsg/debian/helpers/usr/share/man/man5/vnc.conf.5x	2019-07-18 17:52:52.0 +0200
@@ -9,7 +9,7 @@
 .\" License as specified in the file COPYING that comes with the
 .\" Debian GNU/Linux distribution.
 .\"
-.TH vnc.conf 5x "Jan 5th, 2017" "TigerVNC 1.7" "Virtual Network Computing"
+.TH vnc.conf 5x "Jul 18th, 2019" "TigerVNC 1.9" "Virtual Network Computing"
 .SH NAME
 vnc.conf \- configuration file for Virtual Network Computing
 .SH SYNOPSIS
diff -Nru tigervnc-1.9.0+dfsg/debian/patches/0175-xtigervncviewer-WM_CLASS.patch tigervnc-1.9.0+dfsg/debian/patches/0175-xtigervncviewer-WM_CLASS.patch
--- tigervnc-1.9.0+dfsg/debian/patches/0175-xtigervncviewer-WM_CLASS.patch	1970-01-01 01:00:00.0 +0100
+++ tigervnc-1.9.0+dfsg/debian/patches/0175-xtigervncviewer-WM_CLASS.patch	2019-06-15 14:11:27.0 +0200
@@ -0,0 +1,16 @@
+Description: Update WM_CLASS to correspond to the one given in the xtigervncviewer.desktop file
+Author: Joachim Falk
+
+Index: pkg-tigervnc/vncviewer/vncviewer.cxx
+===
+--- pkg-tigervnc.orig/vncviewer/vncviewer.cxx
 pkg-tigervnc/vncviewer/vncviewer.cxx
+@@ -197,7 +197,7 @@ static void init_fltk()
+ 
+   // Proper Gnome Shell integration requires that we set a sensible
+   // WM_CLASS for the window.
+-  Fl_Window::default_xclass("vncviewer");
++  Fl_Window::default_xclass("TigerVNC Viewer");
+ 
+   // Set the default icon for all windows.
+ #ifdef WIN32
diff -Nru tigervnc-1.9.0+dfsg/debian/patches/series tigervnc-1.9.0+dfsg/debian/patches/series
--- tigervnc-1.9.0+dfsg/debian/patches/series	2018-12-01 22:51:29.0 +0100
+++ tigervnc-1.9.0+dfsg/debian/patches/series	2019-06-15 14:11:27.0 +0200
@@ -1,5 +1,6 @@
 0102-fix-spelling-error-in-manpages-to-shutup-lintian.patch
 0151-make-cmake-enable-options-mandatory-if-turned-on.patch
+0175-xtigervncviewer-WM_CLASS.patch
 # rework/0200-

Bug#929410: [Pkg-tigervnc-devel] Bug#929410: Bug#929410: RANDR extension not present

2019-06-15 Thread Joachim Falk

Hi Ola,

Am 26.05.19 um 21:54 schrieb Ola Lundqvist:
> Hi
> 
> Thank you for the report. I cannot reproduce the problem on Debian stable 
> with version 1.7.0.
> I do not have a system running sid right now.

I could reproduce this on buster. Fix is integrated in 1.9.0+dfsg-4~RC2 which 
is present
on salsa in the master branch. Maybe you or Mike can release this so we might 
still hit the buster
release with the bug fix.

Best,

Joachim



signature.asc
Description: OpenPGP digital signature

Bug#927310: libvirt-daemon: LXC container shut down, e.g., virsh -c lxc:// shutdown , is ignored

2019-04-17 Thread Joachim Falk

Package: libvirt-daemon
Version: 5.0.0-2
Severity: grave
Tags: patch
Justification: renders package unusable

Dear maintainer,

LXC container shut down is ignore. Amongst others, this will induce
a hang on host shut down as the libvirt daemon waits 3 minutes per
active container for shut down. Relevant patches from upstram are

>From 64eca3d5e30030147383bc63eba77e723563d4e2 Mon Sep 17 00:00:00 2001
From: Michal Privoznik 
Date: Fri, 25 Jan 2019 12:37:53 +0100
Subject: [PATCH 1/2] virinitctl: Expose fifo paths and allow caller to chose one

So far the virInitctlSetRunLevel() is fully automatic. It finds
the correct fifo to use to talk to the init and it will set the
desired runlevel. Well, callers (so far there is just one) will
need to inspect the fifo a bit just before the runlevel is set.
Therefore, expose the internal list of fifos and also allow
caller to explicitly use one.

Signed-off-by: Michal Privoznik 
Reviewed-by: Erik Skultety 

>From 94fce255461ad6bf0366dd4428921d7d41ba1a8f Mon Sep 17 00:00:00 2001
From: Michal Privoznik 
Date: Fri, 25 Jan 2019 12:42:54 +0100
Subject: [PATCH 2/2] lxc: Don't reboot host on virDomainReboot

If the container is really a simple one (init is just bash and
the whole root is passed through) then virDomainReboot and
virDomainShutdown will talk to the actual init within the host.
Therefore, 'virsh shutdown $dom' will result in shutting down the
host. True, at that point the container is shut down too but
looks a bit harsh to me.

The solution is to check if the init inside the container is or
is not the same as the init running on the host.

Signed-off-by: Michal Privoznik 
Reviewed-by: Erik Skultety 

>From 14b6a1854fb4c02c5fb2f51679f8ff099f28f53c Mon Sep 17 00:00:00 2001
From: Maxim Kozin 
Date: Wed, 6 Mar 2019 21:39:11 +0300
Subject: [PATCH] lxc: Try harder to stop/reboot containers

If shutting down a container via setting the runlevel fails, the
control jumps right onto endjob label and doesn't even try
sending the signal. If flags allow it, we should try both
methods.

Signed-off-by: Maxim Kozin 
Signed-off-by: Michal Privoznik 

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libvirt-daemon depends on:
ii  libacl1 2.2.53-4
ii  libapparmor12.13.2-10
ii  libaudit1   1:2.8.4-2
ii  libavahi-client30.7-4+b1
ii  libavahi-common30.7-4+b1
ii  libblkid1   2.33.1-0.1
ii  libc6   2.28-8
ii  libcap-ng0  0.7.9-2
ii  libcurl3-gnutls 7.64.0-2
ii  libdbus-1-3 1.12.12-1
ii  libdevmapper1.02.1  2:1.02.155-2
ii  libfuse22.9.9-1
ii  libgcc1 1:8.3.0-6
ii  libgnutls30 3.6.6-2
ii  libnetcf1   1:0.2.8-1+b2
ii  libnl-3-200 3.4.0-1
ii  libnl-route-3-200   3.4.0-1
ii  libnuma12.0.12-1
ii  libparted2  3.2-24
ii  libpcap0.8  1.8.1-6
ii  libpciaccess0   0.14-1
ii  libsasl2-2  2.1.27+dfsg-1
ii  libselinux1 2.8-1+b1
ii  libssh2-1   1.8.0-2.1
ii  libudev1241-3
hi  libvirt05.0.0-2
ii  libxenmisc4.11  4.11.1+26-g87f51bf366-3
ii  libxenstore3.0  4.11.1+26-g87f51bf366-3
ii  libxentoollog1  4.11.1+26-g87f51bf366-3
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libyajl22.1.0-3

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.4+dfsg1-7+b3
ii  netcat-openbsd  1.195-2
ii  qemu-kvm1:3.1+dfsg-7

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster  
pn  libvirt-daemon-driver-storage-rbd  
pn  libvirt-daemon-driver-storage-zfs  
hi  libvirt-daemon-system  5.0.0-2
ii  numad  0.5+20150602-5

-- no debconf information
>From 64eca3d5e30030147383bc63eba77e723563d4e2 Mon Sep 17 00:00:00 2001
From: Michal Privoznik 
Date: Fri, 25 Jan 2019 12:37:53 +0100
Subject: [PATCH 1/2] virinitctl: Expose fifo paths and allow caller to chose
 one

So far the virInitctlSetRunLevel() is fully automatic. It finds
the correct fifo to use to talk to the init and it will set the
desired runlevel. Well, callers (so far there is just one) will
need to inspect the fifo a bit just before the runlevel is set.
Therefore, expose the internal list of fifos and also allow
caller to explicitly use one.

Signed-off-by: Michal Privoznik 
Reviewed-by: Erik Skultety 
---
 src/libvirt_private.syms |  1 +
 src/lxc/lxc_driver.c |  2 +-
 src/util/virinitctl.c| 67 ++--
 src/util/virinitctl.h|  6 +++-
 4 files changed, 50 insertions(+), 26 deletions(-)

Index: libvirt/src/libvirt_private.syms

Bug#926999: libvirt-daemon: LXC container cannot be killed, e.g., virsh -c lxc:// destroy , if cgroup backend v2 missing.

2019-04-13 Thread Joachim Falk

Package: libvirt-daemon
Version: 5.0.0-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Joachim Falk 
To: Debian Bug Tracking System 
Subject: libvirt-daemon: LXC container cannot be killed, e.g., virsh -c lxc:// 
destroy , if cgroup backend v2 missing.
Message-ID: <155514522514.793.7421956223092571453.report...@buster.jfalk.de>
X-Mailer: reportbug 7.5.2
Date: Sat, 13 Apr 2019 10:47:05 +0200

Package: libvirt-daemon
Version: 5.0.0-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear maintainer,

there is a problem with killing LXC containers when only one cgroup
backend is available. Cgroup backend v2 is not available on the default
install of libvirt-daemon-system and, thus, killing LXC containers
fails. This seemes to be fixed by upstream with commit

  401030499bfb03b182da14f7e00f4a82beab9a8e

==
>From 401030499bfb03b182da14f7e00f4a82beab9a8e Mon Sep 17 00:00:00 2001
From: Michal Privoznik 
Date: Thu, 24 Jan 2019 17:20:58 +0100
Subject: [PATCH] vircgroup: Try harder to kill cgroup

Prior to rewrite of cgroup code we only had one backend to try.
After the rewrite the virCgroupBackendGetAll() returns both
backends (for v1 and v2). However, not both have to really be
present on the system which results in killRecursive callback
failing which in turn might mean we won't try the other backend.

At the same time, this function reports no error as it should.
==

This commit is also part of upstream version 5.1.0. Hence, a bump to a
newer upstream should also fix the issue.

Symptoms of the problem are as follows in /var/log/libvirt/libvirtd.log:

2019-04-13 08:10:17.708+: 532: debug : virLXCDomainObjBeginJob:108 : 
Starting job: modify
2019-04-13 08:10:17.708+: 532: debug : virLXCProcessStop:831 : Stopping VM 
name=flummy pid=701 reason=2
2019-04-13 08:10:17.708+: 532: debug : virCgroupKillPainfully:2647 : 
cgroup=0x7f5f38005c50 path=
2019-04-13 08:10:17.708+: 532: debug : virCgroupKillRecursive:2617 : 
group=0x7f5f38005c50 path= signum=15
2019-04-13 08:10:17.708+: 532: debug : virCgroupKillPainfully:2658 : 
Iteration 0 rc=-1
2019-04-13 08:10:17.708+: 532: debug : virCgroupKillPainfully:2665 : 
Complete -1
2019-04-13 08:10:17.708+: 532: info : virObjectNew:248 : OBJECT_NEW: 
obj=0x7f5f24001b20 classname=virDomainEventLifecycle
2019-04-13 08:10:17.708+: 532: debug : virLXCDomainObjEndJob:146 : Stopping 
job: modify

You have to enable debugging to get these logs, i.e.,

--- libvirtd.conf.orig  2019-03-30 19:43:46.110699728 +0100
+++ libvirtd.conf   2019-03-30 19:47:37.306130440 +0100
@@ -389,6 +389,7 @@
 # rest of the util code:
 #
 #log_filters="1:qemu 1:libvirt 4:object 4:json 4:event 1:util"
+log_filters="3:remote 4:event 3:json 3:rpc 1:*"

 # Logging outputs:
 # An output is one of the places to save logging information
@@ -411,7 +412,7 @@
 # e.g. to log all warnings and errors to syslog under the libvirtd ident:
 #log_outputs="3:syslog:libvirtd"
 #
-
+log_outputs="1:file:/var/log/libvirt/libvirtd.log 3:syslog:libvirtd"

 ##########
 #

Best,

Joachim Falk

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libvirt-daemon depends on:
ii  libacl1 2.2.53-4
ii  libapparmor12.13.2-10
ii  libaudit1   1:2.8.4-2
ii  libavahi-client30.7-4+b1
ii  libavahi-common30.7-4+b1
ii  libblkid1   2.33.1-0.1
ii  libc6   2.28-8
ii  libcap-ng0  0.7.9-2
ii  libcurl3-gnutls 7.64.0-2
ii  libdbus-1-3 1.12.12-1
ii  libdevmapper1.02.1  2:1.02.155-2
ii  libfuse22.9.9-1
ii  libgcc1 1:8.3.0-5
ii  libgnutls30 3.6.6-2
ii  libnetcf1   1:0.2.8-1+b2
ii  libnl-3-200 3.4.0-1
ii  libnl-route-3-200   3.4.0-1
ii  libnuma12.0.12-1
ii  libparted2  3.2-24
ii  libpcap0.8  1.8.1-6
ii  libpciaccess0   0.14-1
ii  libsasl2-2  2.1.27+dfsg-1
ii  libselinux1 2.8-1+b1
ii  libssh2-1   1.8.0-2.1
ii  libudev1241-3
ii  libvirt05.0.0-1
ii  libxenmisc4.11  4.11.1+26-g87f51bf366-3
ii  libxenstore3.0  4.11.1+26-g87f51bf366-3
ii  libxentoollog1  4.11.1+26-g87f51bf366-3
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libyajl22.1.0-3

Versions of packages libvirt-daemon recommends:
ii  libx

Bug#913531: gdm3: Keyboard layout order given by XKBLAYOUT in /etc/default/keyboard is ignored if us layout present.

2018-11-11 Thread Joachim Falk

Package: gdm3
Version: 3.30.1-1
Severity: normal
Tags: l10n

Dear Debian maintainer of gdm3,

there is a problem with gdm3 on a fresh buster netinstall. If multiple keyboard 
layouts are
selected, e.g., de,us or fr,us, in /etc/default/keyboard like

# KEYBOARD CONFIGURATION FILE

# Consult the keyboard(5) manual page.

XKBMODEL="pc105"
XKBLAYOUT="de,us"
XKBVARIANT=""
XKBOPTIONS=""

BACKSPACE="guess"

then gdm3 will always start with the us layout even if de or fr is present 
first.
However, XKBLAYOUT="de,fr" or XKBLAYOUT="fr,de" work as expected and GDM3, 
respectively,
starts with a german or french layout.


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.45-1
ii  adduser   3.118
ii  dconf-cli 0.30.0-1
ii  dconf-gsettings-backend   0.30.0-1
ii  debconf [debconf-2.0] 1.5.69
ii  gir1.2-gdm-1.03.30.1-1
ii  gnome-session [x-session-manager] 3.30.1-1
ii  gnome-session-bin 3.30.1-1
ii  gnome-settings-daemon 3.30.1.2-1
ii  gnome-shell   3.30.1-2
ii  gnome-terminal [x-terminal-emulator]  3.30.2-1
ii  gsettings-desktop-schemas 3.28.1-1
ii  konsole [x-terminal-emulator] 4:18.04.0-1
ii  kwin-x11 [x-window-manager]   4:5.13.5-1+b1
ii  libaccountsservice0   0.6.45-1
ii  libaudit1 1:2.8.4-2
ii  libc6 2.27-8
ii  libcanberra-gtk3-00.30-6
ii  libcanberra0  0.30-6
ii  libgdk-pixbuf2.0-02.38.0+dfsg-6
ii  libgdm1   3.30.1-1
ii  libglib2.0-0  2.58.1-2
ii  libglib2.0-bin2.58.1-2
ii  libgtk-3-03.24.1-2
ii  libkeyutils1  1.5.9-9.3
ii  libpam-modules1.1.8-3.8
ii  libpam-runtime1.1.8-3.8
ii  libpam-systemd239-11
ii  libpam0g  1.1.8-3.8
ii  librsvg2-common   2.40.20-3
ii  libselinux1   2.8-1+b1
ii  libsystemd0   239-11
ii  libwrap0  7.6.q-27
ii  libx11-6  2:1.6.7-1
ii  libxau6   1:1.0.8-1+b2
ii  libxcb1   1.13.1-1
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  9.20170808
ii  mutter [x-window-manager] 3.30.1-2
ii  plasma-workspace [x-session-manager]  4:5.13.5-1+b1
ii  policykit-1   0.105-21
ii  procps2:3.3.15-2
ii  ucf   3.0038
ii  x11-common1:7.7+19
ii  x11-xserver-utils 7.7+8
ii  xfce4-session [x-session-manager] 4.12.1-6
ii  xfce4-terminal [x-terminal-emulator]  0.8.7.4-2
ii  xfwm4 [x-window-manager]  4.12.5-1

Versions of packages gdm3 recommends:
ii  at-spi2-core2.30.0-4
ii  desktop-base9.0.7
ii  x11-xkb-utils   7.7+4
ii  xserver-xephyr  2:1.20.3-1
ii  xserver-xorg1:7.7+19
ii  zenity  3.30.0-1

Versions of packages gdm3 suggests:
pn  gnome-orca
pn  libpam-fprintd
ii  libpam-gnome-keyring  3.28.2-1

-- debconf information:
* shared/default-x-display-manager: gdm3
  gdm3/daemon_name: /usr/sbin/gdm3

Bug#911712: [Pkg-tigervnc-devel] Bug#911712: tigervnc: diff for NMU version 1.9.0+dfsg-1.1

2018-10-28 Thread Joachim Falk

Hi Christoph,

On 28.10.18 11:53, Christoph Biedl wrote:
> tags 911712 + patch
> tags 911712 + pending
> user debian-rele...@lists.debian.org
> usertags -1 + bsp-2018-10-de-karlsruhe
> thanks
> 
> Dear maintainer,
> 
> I've prepared a NMU for tigervnc (versioned as 1.9.0+dfsg-1.1) and will
> upload it to DELAYED/5 in a moment. Please feel free to tell me if I
> should delay it longer.
I have prepared 1.9.0+dfsg-2 integrating the fix as well as a bug fix for
the missing icons and desktop file.

@Yaroslav or @Mike, can you upload. Please replace
1.9.0+dfsg-2~RC3 with 1.9.0+dfsg-2 and release to unstable.

Regards,

Joachim Falk




signature.asc
Description: OpenPGP digital signature

Bug#901327: [Pkg-tigervnc-devel] Bug#901327: tigervnc: FTBFS: Hunk #1 FAILED

2018-06-25 Thread Joachim Falk

Hi Clint,

Am 24.06.2018 um 22:08 schrieb Clint Adams:
> On Mon, Jun 11, 2018 at 05:21:00PM +0300, Niko Tyni wrote:
>>   touch debian/stamp-patched
>>   /usr/bin/make -f debian/rules update-config
>>   make[1]: Entering directory '/<>/tigervnc-1.7.0+dfsg'
>>   make[1]: 'update-config' is up to date.
>>   make[1]: Leaving directory '/<>/tigervnc-1.7.0+dfsg'
>>   cd ./unix/xserver && \
>> { tar --strip-components 1 -xvJf /usr/src/xorg-server.tar.xz | \
>> sed -e 's@^[^/]*/@@' > .apply-patches-unify-xorg-and-vnc-tree.files; 
>> } && \
>> touch .apply-patches-unify-xorg-and-vnc-tree.stamp
>>   cd ./unix/xserver && { \
>>  patch --no-backup-if-mismatch -p1 < 
>> /<>/tigervnc-1.7.0+dfsg/debian/xserver119.patch && \
>>  touch .apply-patches-vnc-patch-xorg.stamp; \
>>   }
>>   patching file configure.ac
>>   Hunk #2 succeeded at 1778 (offset -86 lines).
>>   Hunk #3 succeeded at 1817 (offset -86 lines).
>>   Hunk #4 succeeded at 2036 (offset -87 lines).
>>   Hunk #5 succeeded at 2571 (offset -126 lines).
>>   patching file hw/Makefile.am
>>   patching file mi/miinitext.c
>>   Hunk #1 FAILED at 114.
>>   Hunk #2 succeeded at 109 (offset -129 lines).
>>   1 out of 2 hunks FAILED -- saving rejects to file mi/miinitext.c.rej
>>   patching file include/os.h
>>   Hunk #1 succeeded at 633 (offset 12 lines).
>>   make: *** [debian/rules:129: 
>> unix/xserver/.apply-patches-vnc-patch-xorg.stamp] Error 1
> 
> Why is patchsys-quilt.mk being used with a 3.0 (quilt) source package?
might be due to legacy reasons. We once had patches in debian/patches that
patched the xorg sources. However, these patches could only be applied
after the xorg sources were unpacked from xorg-server-source. Hence, quilt
patch applicated had to be delayed until xorg-server-source unpacking
was complete.

> 
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-tigervnc-devel
> 




signature.asc
Description: OpenPGP digital signature

Bug#877780: [Pkg-tigervnc-devel] Bug#877780: new upstream (1.8)

2018-05-14 Thread Joachim Falk

Hi Gianfranco,

Am 14.05.2018 um 11:54 schrieb Gianfranco Costamagna:
> On Thu, 5 Oct 2017 17:16:31 +0200 Daniel Baumann 
> <daniel.baum...@progress-linux.org> wrote:
>> Package: tigervnc
>> Severity: wishlist
>>
>> Hi,
>>
>> it would be nice if you could upgrade tigervnc to the current upstream
>> release (1.8).
>>
> 
> hello, ping?
there is a draft deb in https://salsa.debian.org/debian-remote-team/tigervnc.

> 
> G.
> 
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-tigervnc-devel

Regards

Joachim Falk
-- 
Dr.-Ing. Joachim Falk, Department of Computer Science 12
University of Erlangen-Nuremberg, D-91058 Erlangen / Germany
Tel. +49-9131-85-25143, Fax +49-9131-85-25149



signature.asc
Description: OpenPGP digital signature

Bug#891906: tigervnc-standalone-server: Fails to interpret comand line parameters

2018-05-02 Thread Joachim Falk

Hi Georg,

I can't reproduce this. It would fail to interpret the display number after an
unknown option, i.e., tigervncserver -kill -flummy :12, but not with 
tigervncserver -kill :12.
Can you test with the provided script and attach the output?

Regards

Joachim Falk
#! /usr/bin/perl
# vim: set sw=2 sts=2 ts=8 syn=perl expandtab:
#
# vncserver - wrapper script to start an X VNC server.
#
# Copyright (C) 2004-2017 Joachim Falk <joachim.f...@gmx.de>
# Please report all errors to Joachim Falk and not to OL.
#
# This file is based on a vncserver script provided by:
#
#  Copyright (C) 2004 Ola Lundqvist <o...@debian.org>
#  Copyright (C) 2004 Marcus Brinkmann <marcus.brinkm...@ruhr-uni-bochum.de>
#  Copyright (C) 2004 Dirk Eddelbuettel <e...@debian.org>
#  Copyright (C) 2002-2003 RealVNC Ltd.
#  Copyright (C) 1999 AT Laboratories Cambridge.  All Rights Reserved.
#  Copyright (C) 1997, 1998 Olivetti & Oracle Research Laboratory
#
# This is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This software is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this software; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307,
# USA.

package config;

#
#
# I thank Manoj for the code below. All errors are mine, though.
#
# readConfigFile reads in a config file and sets variables according to it.
#

sub readConfigFile {
  my ( $ConfigFile ) = @_;
  
  eval { do "$ConfigFile"; };
  if ($@) {
print STDERR "$PROG: Error parsing config file, $@";
  }
  
#  my $lineno = 0;
#  while (<$cf>) {
#chomp;
#$lineno++;
#s/\#.*//og;
#next if /^\s*$/og;
#$_ .= ";" unless /;\s*$/;
#if (/^\s*([^=]+)\s*=\s*(\S.*)$/o) {
#  my $ret = eval "$1=$2";
#  if ($@) {
#   print STDERR "$PROG: Error parsing config file $ConfigFile at line 
$lineno!\n";
#  }
#}
#  }
}

package main;

use strict;
use warnings;

use File::Path;
use File::Spec;
use File::Basename qw(dirname basename);
use DirHandle;
use File::stat;
use IO::File;
use Socket;
use Getopt::Long;
use Time::HiRes qw(usleep);
use Errno qw(:POSIX);
use POSIX ":sys_wait_h";

use vars qw($HOST $HOSTFQDN $USER $PROG %CMDS);

#
# Set global constants
#

# Get the program name
$PROG = basename($0);

sub installPackageError {
  my ($package) = @_;
  print STDERR "\tPlease install the $package package, i.e., sudo apt-get 
install $package.\n";
  exit 1;
}

sub getCommand {
  my ($cmd) = @_;
  return $CMDS{$cmd} if defined $CMDS{$cmd};
  print STDERR "$PROG: Couldn't find \"$cmd\" on your PATH.\n";
  ("tigervnc-common") if $cmd eq 'tigervncpasswd';
  ("openssl") if $cmd eq 'openssl';
  ("x11-utils") if $cmd eq 'xdpyinfo';
  exit 1;
}

#
# Routine to make sure we're operating in a sane environment.
#
sub sanityCheck {
  # Get install base bin dir
  my $binbase = dirname(File::Spec->rel2abs($0));

  #
  # Check we have all the commands we'll need on the path.
  #
  %CMDS = ();
cmd:
  foreach my $cmd ("hostname","xauth","Xtigervnc") {
foreach my $dir ($binbase, split(/:/,$ENV{PATH})) {
  my $fqcmd = File::Spec->catfile($dir, $cmd);
  if (-x $fqcmd) {
$CMDS{$cmd} = $fqcmd;
next cmd;
  }
}
print STDERR "$PROG: Couldn't find \"$cmd\" on your PATH.\n";
exit 1;
  }
  # These commands are optional.
  foreach my $cmd ("tigervncpasswd", "openssl", "xdpyinfo") {
foreach my $dir ($binbase, split(/:/,$ENV{PATH})) {
  my $fqcmd = File::Spec->catfile($dir, $cmd);
  if (-x $fqcmd) {
$CMDS{$cmd} = $fqcmd;
  }
}
  }
  #
  # Check the HOME environment variable is set
  #
  if (!defined($ENV{HOME})) {
print STDERR "$PROG: The HOME environment variable is not set.\n";
exit 1;
  }
}

sub readConfigFile {
  my $options = shift;
  
  # Add aliases of ::config to %$options
  foreach my $key (keys %$options) {
no strict 'refs';
*{"config::$key"} = \$options->{$key};
  }
  foreach my $ConfigFile (@_) {
next unless -f $ConfigFile; 
config::readConfigFile( $ConfigFile );
  }
#  foreach my $key (keys %$options) {
#if ( defined $config::{$key} &&
# defined *{$config::{$key}}{SCALAR} ) {
#  $options->{$key} = ${*{$config::{$key}}{SCALAR}};
#

Bug#859141: [Pkg-tigervnc-devel] Bug#859141: Bug#859141: tigervnc-standalone-server: Wrapper script is unreasonably intolerant of slightly slow or busy systems

2017-04-09 Thread Joachim Falk

Hi Ola,

Am 09.04.2017 um 21:11 schrieb Ola Lundqvist:
> Hi Matthew
> 
> Thank you for the report. We will have a look into this. An increase of this 
> timeout would be good I guess.

this has already been done.

Changelog snippet from 1.7.0+dfsg-7

"The tigervncserver wrapper script gives up and kills the server it
 just started if it doesn't have its VNC-TCP and X11-unix sockets up and
 running within a second. However, if a machine is a bit bogged down,
 this can prevent starting the server at all, for no good reason.
 Thus, the timeout has been increased to 30 seconds. (Closes: #859141)

Regards,
Joachim Falk





signature.asc
Description: OpenPGP digital signature

Bug#855845: [Pkg-tigervnc-devel] Bug#855845: Bug#855845: Bug#855845: tigervnc-viewer: Option -LowColourLevel doesn't seem functional

2017-04-07 Thread Joachim Falk

Hi Ola and Celelibi,

Am 01.03.2017 um 17:44 schrieb Ola Lundqvist:
> Hi
> 
> I see. Point taken.
> 
> / Ola
> 
> Sent from a phone
> 
> Den 1 mar 2017 14:27 skrev "Celelibi" <celel...@gmail.com 
> <mailto:celel...@gmail.com>>:
> 
> 2017-02-28 23:07 UTC+01:00, Ola Lundqvist <o...@debian.org 
> <mailto:o...@debian.org>>:
> > Is it possible to set a lower color level on the server side? Or do you
> > want this on only certain clients?
> > I'm quite sure you can set the color depth on the server side.
this seems to be just bad documentation. Please use

xtigervncviewer -FullColor=0 -LowColorLevel=0 : to get it working.
However, the -LowColorLevel in isolation does indeed have no impact.

> It is probably possible to set the clolor level on the server, but I
> would like to set it myself depending on where I connect
> from.Especially because I'm better than vnc at determining whether the
> connection is slow or fast.

Regards,

Joachim Falk



signature.asc
Description: OpenPGP digital signature

Bug#854879: unblock: tigervnc/1.7.0+dfsg-6

2017-02-11 Thread Joachim Falk

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package tigervnc. The latest release in unstable fixes
two bugs:

- Applied upstream patch [PATCH] Fix -inetd not working with xserver >=
  1.19. (Closes: #852633)
- Fix server side cursor support for Xorg server >= 1.19. (Closes: #852639)

The patch to fix 852633 is also used in Fedora 25 to fix the same
problem (https://bugzilla.redhat.com/show_bug.cgi?id=1408724) and
committed by 712cf8673d6e57442f41636e44020f5e1839c7f8 into upstream.
Fedora 25 uses the same configuration of TigerVNC, i.e., A patched
TigerVNC 1.7.0 release to add compatibility for Xorg server == 1.19, as
is used in debian stretch. Thus, the patch to close #852633 is already
well tested.

The fix to close #852639 is more urgent as, otherwise, tigervnc as
present in debian stretch is unable to correctly work with clients only
supporting the RFB 3.3 protocol specification. The problem stems from
the fact that tigervnc does not propagate the mouse pointer position to
draw a mouse cursor on the server side, i.e., by the Xorg server, in the
code path to support the Xorg server >= 1.19. In clients supporting RFB
protocol version > 3.3 this problem is hidden, as RFB 3.7 introduced
client side cursor drawing. Fortunately, this can be fixed quite easily
by copying the code snippet responsible for propagating the cursor
position from the code path for Xorg server < 1.19 into the code path
for Xorg server >= 1.19.

unblock tigervnc/1.7.0+dfsg-6

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru tigervnc-1.7.0+dfsg/debian/changelog 
tigervnc-1.7.0+dfsg/debian/changelog
--- tigervnc-1.7.0+dfsg/debian/changelog2017-02-04 01:55:24.0 
+0100
+++ tigervnc-1.7.0+dfsg/debian/changelog2017-02-09 23:51:56.0 
+0100
@@ -1,3 +1,14 @@
+tigervnc (1.7.0+dfsg-6) unstable; urgency=high
+
+  [ Joachim Falk ]
+  * Fix server side cursor support for Xorg server >= 1.19. Closes: #852639
+  * Applied upstream patch [PATCH] Fix -inetd not working with xserver >=
+1.19. Closes: #852633.
+  * Fixed documentation of default value for -depth option in tigervncserver
+man page.
+
+ -- Ola Lundqvist <o...@debian.org>  Thu, 09 Feb 2017 23:51:56 +0100
+
 tigervnc (1.7.0+dfsg-5) unstable; urgency=medium
 
   [ Ola Lundqvist ]
diff -Nru 
tigervnc-1.7.0+dfsg/debian/helpers/usr/share/man/man1/tigervncserver.1 
tigervnc-1.7.0+dfsg/debian/helpers/usr/share/man/man1/tigervncserver.1
--- tigervnc-1.7.0+dfsg/debian/helpers/usr/share/man/man1/tigervncserver.1  
2017-01-28 21:05:18.0 +0100
+++ tigervnc-1.7.0+dfsg/debian/helpers/usr/share/man/man1/tigervncserver.1  
2017-02-09 23:44:12.0 +0100
@@ -137,8 +137,8 @@
 .
 .TP
 .B \-depth \fIdepth\fP
-Specify the pixel depth in bits of the desktop to be created. Default is 16,
-other possible values are 8, 15 and 24 - anything else is likely to cause
+Specify the pixel depth in bits of the desktop to be created. Default is 24,
+other possible values are 8, 15 and 16 - anything else is likely to cause
 strange behavior by applications.
 .
 .TP
diff -Nru tigervnc-1.7.0+dfsg/debian/patches/fix-xorg1.19-inetd-mode.patch 
tigervnc-1.7.0+dfsg/debian/patches/fix-xorg1.19-inetd-mode.patch
--- tigervnc-1.7.0+dfsg/debian/patches/fix-xorg1.19-inetd-mode.patch
1970-01-01 01:00:00.0 +0100
+++ tigervnc-1.7.0+dfsg/debian/patches/fix-xorg1.19-inetd-mode.patch
2017-02-09 23:44:12.0 +0100
@@ -0,0 +1,42 @@
+From 712cf8673d6e57442f41636e44020f5e1839c7f8 Mon Jan 9 16:03:30 2017 +0100
+Author: Hans de Goede <hdego...@redhat.com>
+Date: Mon Jan 9 16:03:30 2017 +0100
+Subject: [PATCH] Fix -inetd not working with xserver >= 1.19
+
+xserver 1.19's OsInit will create a pollfd, followed by checking if fd 2 /
+stderr is writable and if it is not, replacing fd 2 with /dev/null.
+
+Since we close stderr in inetd mode to avoid xserver messages being send
+to the client as vnc data, the pollfd becomes fd 2, only to be replaced
+by /dev/null since a pollfd is not writable.
+
+This commit fixes this by opening /dev/null directly after the close(2),
+avoiding that the pollfd becomes fd 2.
+
+Alan Coopersmith: Change to use dup2() for atomic switch of fd
+
+Signed-off-by: Hans de Goede <hdego...@redhat.com>
+
+diff --git a/unix/xserver/hw/vnc/xvnc.c b/unix/xserver/hw/vnc/xvnc.c
+index c5b684de..ef30d69a 100644
+--- a/unix/xserver/hw/vnc/xvnc.c
 b/unix/xserver/hw/vnc/xvnc.c
+@@ -572,9 +572,17 @@ ddxProcessArgument(int argc, char *argv[], int i)
+ 
+ if (strcmp(argv[i], "-inetd") == 0)
+ {
++  int nullfd;
++
+   dup2(0,3);
+

Bug#852639: [Pkg-tigervnc-devel] Bug#852639: tigervnc-standalone-server: mouse pointer stuck in upper left corner

2017-02-06 Thread Joachim Falk

Hi all,

Am 05.02.2017 um 23:27 schrieb Joachim Falk:
> Hi Ola,
> 
> Am 05.02.2017 um 22:39 schrieb Ola Lundqvist:
>> Hi
>>
> || For context:
>>> So, it seems to be a regression with the combination of Xorg 1.19 in stretch
>>> and the VNC patch to it. Ola, where did you get this patch? If I remember
>>> correctly, Xorg 1.19 is not officially supported for TigerVNC 1.7.
>> I think it was from this source:
>> https://lists.x.org/archives/xorg-devel/2016-October/051482.html
> I have just checked. We have the same patch as is provided by
> tigervnc master. We also seem to apply all patches from tigervnc
> master intending to get Xorg 1.19 going. Next, one should check
> if this is also a regression with tigervnc master concerning
> buggy remote cursor support with the Xorg 1.19 server.
I have just backported a relevant patch from master. This should
fix the problem. Please test the preview debs under the following URL:
  https://xamane.jfalk.de/dists/homebrew-stretch/selfmade/binary-amd64
The fix should be in tigervnc-standalone-server_1.7.0+dfsg-7_amd64.deb.

Regards,
Joachim Falk




signature.asc
Description: OpenPGP digital signature

Bug#852639: [Pkg-tigervnc-devel] Bug#852639: Bug#852639: tigervnc-standalone-server: mouse pointer stuck in upper left corner

2017-02-05 Thread Joachim Falk

Hi Ola,

Am 05.02.2017 um 22:39 schrieb Ola Lundqvist:
> Hi
> 
|| For context:
>> So, it seems to be a regression with the combination of Xorg 1.19 in stretch
>> and the VNC patch to it. Ola, where did you get this patch? If I remember
>> correctly, Xorg 1.19 is not officially supported for TigerVNC 1.7.
> I think it was from this source:
> https://lists.x.org/archives/xorg-devel/2016-October/051482.html
I have just checked. We have the same patch as is provided by
tigervnc master. We also seem to apply all patches from tigervnc
master intending to get Xorg 1.19 going. Next, one should check
if this is also a regression with tigervnc master concerning
buggy remote cursor support with the Xorg 1.19 server.

Regards,
Joachim Falk



signature.asc
Description: OpenPGP digital signature

Bug#852633: [Pkg-tigervnc-devel] Bug#852633: tigervnc-standalone-server: The -once option is no more honored

2017-02-05 Thread Joachim Falk

Hi Christophe,

Am 25.01.2017 um 21:56 schrieb Christophe Lohr:
> Package: tigervnc-standalone-server
> Version: 1.7.0+dfsg-2
> Severity: normal
> Tags: upstream
> 
> Dear Maintainer,
>   Please accept my apologies. The recent issue I'm facing is not due to the 
> -once option but more probably caused by the -inetd option (I use both for 
> the typical "inetd" scenario).
this should now be fixed. Please test the preview debs under the following URL:
  https://xamane.jfalk.de/dists/homebrew-stretch/selfmade/binary-amd64
The fix should be in tigervnc-standalone-server_1.7.0+dfsg-6_amd64.deb.

> So, you can cancel this ticket.
> Sorry for the inconvenience.
The ticket has been renamed appropriately.

> Best regards.
> Christophe

Regards,
Joachim Falk




signature.asc
Description: OpenPGP digital signature

Bug#852639: [Pkg-tigervnc-devel] Bug#852639: tigervnc-standalone-server: mouse pointer stuck in upper left corner

2017-02-05 Thread Joachim Falk

Hi all,

Am 04.02.2017 um 20:42 schrieb Aaro Koskinen:
> Hi,
> 
> On Sat, Feb 04, 2017 at 03:31:27PM +0100, Joachim Falk wrote:
>> I have investigated this some more. I assume you used the code from
>> https://github.com/zohead/fbvnc for fbvnc.
> 
> Yes, with some local fixes.
> 
>> With this code, I can reproduce the bug. I assume the problem is that fbvnc
>> does not support a vncviewer local cursor and Xtigervnc needs local cursor
>> handling by the VNC client application. I do not know if this is a regression
>> in Xtigervnc.
> 
> I don't think RFB 3.3 clients need to implement any local cursor support.
I also don't think so. Moreover, it does work for the TigerVNC backport
to debian jessie.

 Am 04.02.2017 um 21:05 schrieb Joachim Falk: =======
Hi all,

Am 09.01.2017 um 17:50 schrieb Joachim Falk:
> Hi all,
>
> Am 09.01.2017 um 16:33 schrieb Yaroslav Halchenko:
>>
>> On Sat, 07 Jan 2017, Ola Lundqvist wrote:
>>
>>> Hi all TigerVNC maintainers
>>
>>> I just want you to know that I have now uploaded a vnc4 and tightvnc
>>> source package that are just transitional packages to tigervnc.
>>
>>> So now there is no going back.
>>
>> Linus bless us all!  thank you Ola.  That is a pity that we don't have
>> an easy backport of tigervnc for e.g. jessie ATM -- I can't really give
>> it a "real life" testing since most of the servers I am using VNC on run
>> on debian stable
> I might take a look at a backport.
I just finished the backport to jessie.

Am 30.01.2017 um 03:45 schrieb Martin Dorey:
>
> Sorry to make such a meal of such a trivial nugget, but I want to convey how 
> little I understand.
> Now, if you'll excuse me, I'm off to try to similarly brutalize the old 
> Jessie packaging of tigervnc 1.6.0,
> if I still have it lying around, to see if I can get back in to :0 on the 
> server that I actually care about...
Maybe try the backport

I have mirrored my debs to https://xamane.jfalk.de/dists/homebrew-jessie

Regards,
Joachim Falk
=

So, it seems to be a regression with the combination of Xorg 1.19 in stretch
and the VNC patch to it. Ola, where did you get this patch? If I remember
correctly, Xorg 1.19 is not officially supported for TigerVNC 1.7.

> What's interesting that server is chaging/drawing the cursor shape properly
> e.g. when moving the mouse over uxterm or doing other actions, it's just that
> the location is frozen.
> 
>>> This works fine with tightvnc on both arm64 and armhf using older Debian
>>> rootfs. But unfortunately that does not seem to be an option anymore.
>> However, I can not even get this working with tightvncserver under stretch.
>> Here the connection from fbvnc gets a garbled image from the Xtightvnc 
>> server.
Maybe you can post the changes to fbvnc somewhere, so that we test with the 
same code?

> I have it working fine.
> 
> A.
> 

Regards,
Joachim Falk



signature.asc
Description: OpenPGP digital signature

Bug#852639: [Pkg-tigervnc-devel] Bug#852639: tigervnc-standalone-server: mouse pointer stuck in upper left corner

2017-02-04 Thread Joachim Falk

Dear all,

Am 26.01.2017 um 21:24 schrieb Aaro Koskinen:
> Hi,
> 
> On Thu, Jan 26, 2017 at 02:14:36PM +0100, Ola Lundqvist wrote:
>> For my understanding. How do you connect to the server?
> 
> I'm connecting from a remote host with ssh port forwarding and using
> fbvnc client.
I have investigated this some more. I assume you used the code from
https://github.com/zohead/fbvnc for fbvnc. With this code, I can
reproduce the bug. I assume the problem is that fbvnc does not
support a vncviewer local cursor and Xtigervnc needs local cursor handling
by the VNC client application. I do not know if this is a regression
in Xtigervnc.

> This works fine with tightvnc on both arm64 and armhf using older Debian
> rootfs. But unfortunately that does not seem to be an option anymore.
However, I can not even get this working with tightvncserver under stretch.
Here the connection from fbvnc gets a garbled image from the Xtightvnc server.

> A.
> 
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-tigervnc-devel
> 




signature.asc
Description: OpenPGP digital signature

Bug#851842: [Pkg-tigervnc-devel] Bug#851842: Bug#851842: tigervnc-xorg-extension - libvnc.so fails to load with undefined symbol: gnutls_bye

2017-02-02 Thread Joachim Falk

Hi all,

Am 30.01.2017 um 03:45 schrieb Martin Dorey:
> On Fri, 20 Jan 2017 22:10:29 +0100 Ola Lundqvist  > wrote:
>> I have now been able to reproduce the problem. It is not solved by
>> merely adding more dependencies. I have to look further to find the
>> cause of the problem.
> 
> Hey Ola,
> 
> I think I can help.  First, though, I'm delighted to see that your ITP for 
> tigervnc went through for Stretch.  But is that still a default -depth of 32 
> I see - how are the poor users going to work out that they need to try -depth 
> 24, per the warning in man xtigervnc, to get their, eg Java, text rendered 
> properly?  Anyway, I think the problem here has the same cause as the similar 
> one described by:
I have tested -depth 32 with some applications and it really is a problem, 
i.e., VMware workstation bugs out with this setting.
I think we should switch the default to -depth 24.

> 
> https://github.com/TigerVNC/tigervnc/issues/294: unable to load libvnc.so 
> after installing 1.5.x or 1.6.0
> 
> I had another great experience with tigervnc-standalone-server this weekend, 
> which lets me connect to Gnome 3 over a metro area as if I were in the 
> office, in contrast to vino, where I have to tolerate several megabits per 
> second of background traffic when idle, making interactivity unusably slow.  
> Thus I wanted to replace vino with tigervnc-xorg-extension on the :0 of my 
> just-upgraded-to-Jessie server.  I faced:
> 
> [238863.164] (EE) Failed to load /usr/lib/xorg/modules/extensions/libvnc.so: 
> /usr/lib/xorg/modules/extensions/libvnc.so: undefined symbol: 
> gnutls_transport_set_ptr2
> 
> ... which looks exactly like part of upstream's problem.  On a Stretch 
> system, with Debian's (yay!) native packaging, I see the gnutls_bye symptom 
> instead.  If I rebuild your Sid packaging, from apt-get source tigervnc, with:
> 
> mad@shuttle:~/tigervnc-1.7.0+dfsg$ dpkg-buildpackage -nc -uc -us
> 
> ... then apply upstream's patch, in my so very crude fashion, using what I 
> think, having looked it up, is the shiniest flavor of Ubuntu that upstream 
> supports:
> 
> mad@shuttle:~/tigervnc-1.7.0+dfsg$ (cd unix/xserver && patch -p1 < 
> ../../contrib/packages/deb/ubuntu-xenial/debian/xorg-source-patches/debian_libtool.patch)
> checking file ltmain.sh
> Hunk #1 succeeded at 7893 (offset 3 lines).
> checking file ltmain.sh
> Hunk #1 succeeded at 7571 (offset 3 lines).
> checking file m4/libtool.m4
> Hunk #1 succeeded at 4947 (offset 11 lines).
> Hunk #2 succeeded at 5009 (offset 14 lines).
> Hunk #3 succeeded at 5784 (offset 17 lines).
> mad@shuttle:~/tigervnc-1.7.0+dfsg$ 
> 
> As you see, I get a reasonably clean application, but libvnc.so didn't 
> rebuild when I repeated the dpkg-buildpackage command.  Oh, for the simple 
> days, when dependencies were complete and "make" was all you needed!  Just 
> removing the .so got me a build failure, causing more sadly grey-bearded 
> head-shaking, but removing the .la and .lai files too:
> 
> mad@shuttle:~/tigervnc-1.7.0+dfsg$ find . -name libvnc.* | xargs rm
> mad@shuttle:~/tigervnc-1.7.0+dfsg$
> 
> ... then repeating the dpkg-buildpackage command got me a 
> ./debian/tigervnc-xorg-extension/usr/lib/xorg/modules/extensions/libvnc.so 
> that, when used to replace 
> /usr/lib/xorg/modules/extensions/libvnc.so, effaces the (EE) error from 
> wherever ls -l /proc/$(pidof Xorg)/fd told me that the squirrels had buried 
> Xorg.0.log.  xdpyinfo now happily reports:
> 
> mad@shuttle:~$ xdpyinfo | grep VNC
> VNC-EXTENSION
> mad@shuttle:~$ 
> 
> Sorry to make such a meal of such a trivial nugget, but I want to convey how 
> little I understand.  Now, if you'll excuse me, I'm off to try to similarly 
> brutalize the old Jessie packaging of tigervnc 1.6.0, if I still have it 
> lying around, to see if I can get back in to :0 on the server that I actually 
> care about...
> 
> 
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-tigervnc-devel
> 




signature.asc
Description: OpenPGP digital signature

Bug#849996: tigervncserver doesn't work

2017-01-03 Thread Joachim Falk

Am 03.01.2017 um 19:04 schrieb Daniel Baumann:
> Hi,
> 
> yes, that fixes the problem I mentioned, thanks.
> 
> however, after doing this:
> 
> ---snip---
> daniel@daniel:~$ tigervncserver
> 
> New 'X-daniel' desktop at :1 on machine daniel
> 
> Starting applications specified in /etc/X11/Xvnc-session
> Log file is /home/daniel/.vnc/daniel:1.log
> 
> 
> Use xtigervncviewer -SecurityTypes VncAuth -passwd
> /home/daniel/.vnc/passwd :1 to connect to the vnc server.
> 
> daniel@daniel:~$
> ---snap---
> 
> nothing apparently happened (i've installed tigervnc on a system that
> has nothing installed, except tigervnc-{common,standalone-serveR} (plus
> their depends) and ssh.
Well you have no desktop installed. Try for a simple xterm.

tigervncserver :nn -- /usr/bin/xterm

Then use xtigervncviewer :nn to check if you can connect.


> 
> the log looks like this:
> 
> ---snip---
> Xvnc TigerVNC 1.7.0 - built Jan  3 2017 13:08:23
> Copyright (C) 1999-2016 TigerVNC Team and many others (see README.txt)
> See http://www.tigervnc.org for information on TigerVNC.
> Underlying X server release 1190, The X.Org Foundation
> 
> 
> Tue Jan  3 17:49:42 2017
>  vncext:  VNC extension running!
>  vncext:  Listening for VNC connections on local interface(s), port 5901
>  vncext:  created VNC server for screen 0
> XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":1"
>   after 172 requests (171 known processed) with 0 events remaining.
> Killing Xtigervnc process ID 17787... success!
> ---snap---
> 
> let me know if you need any more information, etc.
> 
> Regards,
> Daniel

Regards,
Joachim Falk




signature.asc
Description: OpenPGP digital signature

Bug#850054: [Pkg-tigervnc-devel] Bug#850054: /usr/bin/tigervncserver: label error in sanity check

2017-01-03 Thread Joachim Falk

Dear Peter,

I have a fix for this and many other minor things. Can you test
an RC for tigervnc 1.7.0+dfsg-2? Find the debs under

http://xamane.jfalk.de/dists/homebrew-stretch/selfmade/binary-amd64

Regards,
Joachim Falk



signature.asc
Description: OpenPGP digital signature

Bug#849996: Release?

2017-01-03 Thread Joachim Falk

Hi Ola,

Am 03.01.2017 um 13:04 schrieb Ola Lundqvist:
> Hi
> 
> Just want to check if your changes are ready for release? We have a new RC 
> bug that I would like to fix asap.
hopefully yes. It works on my system now.

> / Ola
> 
> Sent from a phone

Regards,
Joachim Falk




signature.asc
Description: OpenPGP digital signature

Bug#849996: [Pkg-tigervnc-devel] Bug#849996: tigervncserver doesn't work

2017-01-03 Thread Joachim Falk

Dear Daniel,

Am 03.01.2017 um 00:06 schrieb Daniel Baumann:
> Package: tigervnc
> Version: 1.7.0+dfsg-1
> Severity: serious
> 
> Hi,
> 
> thanks for fixing #849963, however, tighervncserver still just doesn't
> work at all for me:

I have a fix for this and many other minor things. Can you test
an RC for tigervnc 1.7.0+dfsg-2? Find the debs under

http://xamane.jfalk.de/dists/homebrew-stretch/selfmade/binary-amd64

> daniel@daniel:~$ tigervncserver
> Exiting subroutine via next at /usr/bin/tigervncserver line 129.
> Exiting subroutine via next at /usr/bin/tigervncserver line 129.
> Label not found for "next cmd" at /usr/bin/tigervncserver line 129.
> daniel@daniel:-$
> 
> Regards,
> Daniel
> 
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-tigervnc-devel

Regards,
Joachim Falk



signature.asc
Description: OpenPGP digital signature

Bug#849963: [Pkg-tigervnc-devel] Bug#849963: tigervnc-standalone-server: Syntax error in /usr/bin/tigervncserver

2017-01-02 Thread Joachim Falk

Dear Maik,

Am 02.01.2017 um 18:22 schrieb Maik Zumstrull:
> Package: tigervnc-standalone-server
> Version: 1.7.0-2
> Severity: normal
> 
> 
> In line 705, in the code path for the -fg option, the script does:
> 
> system $cmd[0] (@cmd);
> 
> This will lead to a "Can't use string as a subroutine ref" error with
> current Perl releases. The correct syntax is
I am on it. I am also in the process of updating our start
script for proper X509None, X509Vnc, X509Plain support. I will
see if we can auto generate a certificate for such uses if not
already present or specified on the command line.

> 
> system { $cmd[0] } (@cmd);
> 
> or
> 
> system { $cmd[0] } @cmd;
> 
> The final parentheses are optional but not harmful. The braces are very
> not optional. In defense of the author, the Perl documentation for
> "system" doesn't indicate this at all; it's in the documentation for the
> related "exec" function.
> 
> ___
> Pkg-tigervnc-devel mailing list
> pkg-tigervnc-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-tigervnc-devel
> 

Regards,
Joachim Falk



signature.asc
Description: OpenPGP digital signature

Bug#846950: It is not only RPCSVCGSSDOPTS but also RPCGSSDOPTS that is not correctly propagated

2017-01-01 Thread Joachim Falk

Dear all,

both RPCSVCGSSDOPTS and RPCGSSDOPTS from /etc/default/nfs-common are not 
correctly propagated
into /run/sysconfig/nfs-utils by /usr/lib/systemd/scripts/nfs-utils_env.sh.

I have attached a patch for nfs-utils_env.sh. Note that
RPCSVCGSSDOPTS must be propagated to SVCGSSDARGS and
not to RPCSVCGSSDARGS. Simply look into /lib/systemd/system/rpc-svcgssd.service
where SVCGSSDARGS is used as argument for rpc.svcgssd.

Moreover, this still dos not allow one to override the keytab setting as 
/etc/krb5.keytab
is hardcoded in multiple ConditionPathExists conditions in the systemd service 
files.
Hence, a symlink for /etc/krb5.keytab must be used.

With kind regards,
Joachim Falk
--- nfs-utils_env.sh.orig	2016-12-23 22:43:59.816660950 +0100
+++ nfs-utils_env.sh	2016-12-23 23:27:20.266394604 +0100
@@ -12,12 +12,12 @@
 echo RPCNFSDARGS=\"$RPCNFSDOPTS ${RPCNFSDCOUNT:-8}\"
 echo RPCMOUNTDARGS=\"$RPCMOUNTDOPTS\"
 echo STATDARGS=\"$STATDOPTS\"
-echo RPCSVCGSSDARGS=\"$RPCSVCGSSDOPTS\"
+echo SVCGSSDARGS=\"$RPCSVCGSSDOPTS\"
+echo SMNOTIFYARGS=\"$SMNOTIFYARGS\"
+echo RPCIDMAPDARGS=\"$RPCIDMAPDARGS\"
+echo GSSDARGS=\"$RPCGSSDOPTS\"
 } > /run/sysconfig/nfs-utils
 
 # the following are supported by the systemd units, but not exposed in default files
-# echo SMNOTIFYARGS=\"$SMNOTIFYARGS\"
-# echo RPCIDMAPDARGS=\"$RPCIDMAPDARGS\"
-# echo RPCGSSDARGS=\"$RPCGSSDARGS\"
 # echo BLKMAPDARGS=\"$BLKMAPDARGS\"
 # echo GSS_USE_PROXY=\"$GSS_USE_PROXY\"
# To apply settings to systemd service units execute the following commands:
# systemctl restart nfs-config (this will update /run/sysconfig/nfs-utils)
# systemctl restart nfs-utils (this will apply /run/sysconfig/nfs-utils)

# The following two settings are only respected by the systemd nfs services 
units.
# See the !!!PATCHED!!! /usr/lib/systemd/scripts/nfs-utils_env.sh and the 
associated services
# /lib/systemd/system/nfs-config.service
# /lib/systemd/system/nfs-idmapd.service
# /lib/systemd/system/nfs-utils.service
# /lib/systemd/system/rpc-gssd.service
# /lib/systemd/system/rpc-svcgssd.service
# /lib/systemd/system/rpc-statd.service
# /lib/systemd/system/rpc-statd-notify.service
# /lib/systemd/system/auth-rpcgss-module.service
SMNOTIFYARGS=""
RPCIDMAPDARGS=""

# If you do not set values for the NEED_ options, they will be attempted
# autodetected; this should be sufficient for most people. Valid alternatives
# for the NEED_ options are "yes" and "no".

# Do you want to start the statd daemon? It is not needed for NFSv4.
NEED_STATD=

# Options for rpc.statd.
#   Should rpc.statd listen on a specific port? This is especially useful
#   when you have a port-based firewall. To use a fixed port, set this
#   this variable to a statd argument like: "--port 4000 --outgoing-port 4001".
#   For more information, see rpc.statd(8) or http://wiki.debian.org/SecuringNFS
STATDOPTS=

# Do you want to start the idmapd daemon? It is only needed for NFSv4.
NEED_IDMAPD=yes

# Do you want to start the gssd daemon? It is required for Kerberos mounts.
NEED_GSSD=yes

RPCGSSDOPTS="-k /etc/krb5/krb5.keytab"
#RPCGSSDOPTS="-vvv -rrr -k /etc/krb5/krb5.keytab" # comment in for debugging


signature.asc
Description: OpenPGP digital signature

Bug#654924: TigerVNC: Include as official package?

2015-11-03 Thread Joachim Falk

Hi Andreas,

Am 02.11.2015 um 17:32 schrieb Yaroslav Halchenko:>
> On Mon, 02 Nov 2015, Andreas Tscharner wrote:
>
>> Hello World,
>
>> The package seems to have been finished on July 1st, 2012, but has
>> not yet been included into the official package repository?
>> What is wrong with it?
>
> that old version was rejected, primarily for demand to reuse xorg
> sources available in the archive.  We have fixed for that a while back,
> but didn't have someone to make final the final push.
we have a working version of TigerVNC 1.4.3 for debian jessie using
the system xorg sources via the xorg-server-source debian package.
However, I haven't forward ported this package to debian stretch
(i.e., testing) and haven't upgraded to TigerVNC 1.5.x. I only
recently got around to installing a stretch image.

> I did upload some
> snapshot package to neurodebian
>
http://neuro.debian.net/pkgs/tigervnc-standalone-server.html#binary-pkg-tigervnc-standalone-server
> but didn't have time to look to finalize for upload to debian proper:
> verify licenses and either it would build now with current xorg in the
> archive
>
> So if you are keen to help
> http://git.debian.org/?p=pkg-tigervnc/pkg-tigervnc.git
> is out there!

Regards
Joachim Falk



signature.asc
Description: OpenPGP digital signature

Bug#785356: xrdp Oh no! Something has gone wrong. is back

2015-05-25 Thread Joachim Falk

Hi Bernhard and Joachim,

Am 24.05.2015 um 18:58 schrieb Bernhard Übelacker:
 Hello Joachim,
 just another small addition to the workaround:
 There already exists a more debian like package of Xtigervnc.
 
 With this version there are still some issues:
 - this version does not provide the Xvnc link
I have fixed this. I also updated to tigervnc 1.4.3.

 - gnome still tries to do maximum resolution / monitors.xml needs adjustment
I don't think that falls into the responsibility of the tigervnc package.

 
 Following are the commands to build that version.
 
 mkdir tigervnc; cd tigervnc
 git clone git://anonscm.debian.org/pkg-tigervnc/pkg-tigervnc.git
 cd pkg-tigervnc/
 dpkg-buildpackage -b
 cd ..
 su
 dpkg -i tigervnc-standalone-server_1.4.1-1_i386.deb 
 tigervnc-common_1.4.1-1_i386.deb
 update-alternatives --install /usr/bin/Xvnc Xvnc /usr/bin/Xtigervnc 0
 # is needed, because unfortunately tigervnc-standalone-server 
 does not provide the Xvnc link, but xrdp relies on it.
 # make sure vnc4server or tightvncserver is not installed
I bumped the priority of my alternatives such that they should now
override the ones provided by tightvncserver and vnc4server.

 exit
 
 Kind regards,
 Bernhard

Regards
Joachim



signature.asc
Description: OpenPGP digital signature

Bug#771241: Patch

2015-03-04 Thread Joachim Falk

Dear all,

I can reproduce this. Moreover, this has already been patched upstream.
I have backported the patch. Please apply by integrating
17-upstream-POLLRDHUP-handling-error-fix.patch into your debian package!

Regards
Joachim Falk
Description: Fix Backported premature data truncation problem due to over eager POLLRDHUP handling.
Origin: upstream; https://www.stunnel.org/pipermail/stunnel-users/2014-November/004860.html
Last-Update: 2015-03-04

Index: stunnel4-5.06/src/client.c
===
--- stunnel4-5.06.orig/src/client.c	2014-10-15 22:55:07.0 +0200
+++ stunnel4-5.06/src/client.c	2015-03-04 23:27:01.052295381 +0100
@@ -515,6 +515,11 @@
 int write_wants_read=0, write_wants_write=0;
 /* actual conditions on file descriptors */
 int sock_can_rd, sock_can_wr, ssl_can_rd, ssl_can_wr;
+#ifdef USE_WIN32
+unsigned long bytes;
+#else
+int bytes;
+#endif
 
 c-sock_ptr=c-ssl_ptr=0;
 
@@ -810,32 +815,44 @@
 }
 
 /** check for hangup conditions */
-if(s_poll_rdhup(c-fds, c-sock_rfd-fd)) {
-s_log(LOG_INFO, Read socket closed (hangup));
+/* http://marc.info/?l=linux-manm=128002066306087 */
+/* readsocket() must be the last sock_rfd operation before FIONREAD */
+if(sock_open_rd  s_poll_rdhup(c-fds, c-sock_rfd-fd) 
+(ioctlsocket(c-sock_rfd-fd, FIONREAD, bytes) || !bytes)) {
+s_log(LOG_INFO, Read socket closed (read hangup));
 sock_open_rd=0;
 }
-if(s_poll_hup(c-fds, c-sock_wfd-fd)) {
+if(sock_open_wr  s_poll_hup(c-fds, c-sock_wfd-fd)) {
 if(c-ssl_ptr) {
 s_log(LOG_ERR,
-Write socket closed (hangup) with %d unsent byte(s),
+Write socket closed (write hangup) with %d unsent byte(s),
 c-ssl_ptr);
 longjmp(c-err, 1); /* reset the socket */
 }
-s_log(LOG_INFO, Write socket closed (hangup));
+s_log(LOG_INFO, Write socket closed (write hangup));
 sock_open_wr=0;
 }
-if(s_poll_hup(c-fds, c-ssl_rfd-fd) ||
-s_poll_hup(c-fds, c-ssl_wfd-fd)) {
+/* SSL_read() must be the last ssl_rfd operation before FIONREAD */
+if(!(SSL_get_shutdown(c-ssl)SSL_RECEIVED_SHUTDOWN) 
+s_poll_rdhup(c-fds, c-ssl_rfd-fd) 
+(ioctlsocket(c-ssl_rfd-fd, FIONREAD, bytes) || !bytes)) {
 /* hangup - buggy (e.g. Microsoft) peer:
  * SSL socket closed without close_notify alert */
+s_log(LOG_INFO, SSL socket closed (read hangup));
+SSL_set_shutdown(c-ssl,
+SSL_get_shutdown(c-ssl)|SSL_RECEIVED_SHUTDOWN);
+}
+if(!(SSL_get_shutdown(c-ssl)SSL_SENT_SHUTDOWN) 
+s_poll_hup(c-fds, c-ssl_wfd-fd)) {
 if(c-sock_ptr || write_wants_write) {
 s_log(LOG_ERR,
-SSL socket closed (hangup) with %d unsent byte(s),
+SSL socket closed (write hangup) with %d unsent byte(s),
 c-sock_ptr);
 longjmp(c-err, 1); /* reset the socket */
 }
-s_log(LOG_INFO, SSL socket closed (hangup));
-SSL_set_shutdown(c-ssl, SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN);
+s_log(LOG_INFO, SSL socket closed (write hangup));
+SSL_set_shutdown(c-ssl,
+SSL_get_shutdown(c-ssl)|SSL_SENT_SHUTDOWN);
 }
 
 /** check write shutdown conditions */


signature.asc
Description: OpenPGP digital signature

Bug#774400: apt-xapian-index: Missing dependency on python-support package providing the required update-python-modules command

2015-01-01 Thread Joachim Falk

Package: apt-xapian-index
Version: 0.47
Severity: minor
Tags: patch

Dear Maintainer,

the apt-xapian-index.postinst script uses update-python-modules, but you
are missing a dependency on python-support which provides this command.
This might have come about due to fixing bug #537376. Please add the
package dependency and all should be well. Otherwise, an install of
apt-xapian-index without an installed python-support package will fail
in the post install configuration phase.

Regards,
Joachim Falk

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-rhel6.4-openvz-042stab084_17 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages apt-xapian-index depends on:
ii  python 2.7.8-2
ii  python-apt 0.9.3.11
ii  python-debian  0.1.25
ii  python-xapian  1.2.19-1
pn  python:any none

apt-xapian-index recommends no packages.

Versions of packages apt-xapian-index suggests:
pn  app-install-data  none
pn  python-xdgnone

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654924: Package ready, upload rights required

2012-07-01 Thread Joachim Falk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OK people,

the package seems to be ready, for wheezy and squeeze, c.f.,

  http://xiao.jfalk.de/~joachim/tigervnc

I have tested it and have a tigervnc server running in my
Wheezy/testing install. It also builds on SID. We now
require upload rights or a sponsor. I am not to knowledgeable
how this works. Anybody here want to comment or sponsor?
It is kind of urgent as the freeze was on 30.6.2012.

Regards,
Joachim Falk
- -- 
Joachim Falk joachim.f...@gmx.de

You can always tell a really good idea by the enemies it makes.
  --programmers' axiom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP8IUmAAoJEIjUIAk+3OYM50MP/3LuwcKOzE2HhdaTvmG+2vbW
6gRkWOXNFZySrsGLkIJibi9xmp/fn7C3LTH0BeU0BxOpgK1pnYtlJegrYI8u/Xor
TTCam5Rw2nZZTGVf4O9Wu2Q49hcwCzxztevCSgz/8zODtZyR0mWdsyiEg6G57x3z
ZKSwybqEQSGD41tknKXo/1OwOsPKbKOi4/S8Hk2L2NKTjumPf011VNrifl6dKsdR
sSnsYhozSUHAsZ+xMpZTv8upCGixTeTPan43y5qzQSZzrLbDSavz/5IfdDa+GAnT
Nkr7aIqWxhNUZMZZikybZDNgjmUl0VKtYkVX5UcwAlWUd3r2JT7sX0zIVyOy/Dbm
G9LdpVuGHCROEAWyzuWnXjY2ZwKCILHJxlIzMGAsk7Dm91ZulH1Yc6WimMiZuGn6
T6lyJx5XQgBjvrDRIej3zB8CgEidEvVrFLdGM7xCwhxt06zMv77xF2LhJqCbZpU5
XlgkGqLfoSQhsg+uT1EvMFc4s5OFJS8VhEV5cMbItBBSyUlyTAEz/hxfojgDw3n9
k1RwtDLxwQ4AqiNTHvRsnJ4fZmXaCSBriS4z1WgLqVJ07OXXY4S/nNXyIV749Bsh
C6oxr3WtugauJ2cmrjbBFp35bPTnrEYVrx0t1Y3G9HEH2jEn/kHSmH+yBXulHcSq
xNhmL+xRqK7Q/V0vuqvh
=Uaap
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654924: Inclusion of TigerVNC sources

2012-04-08 Thread Joachim Falk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Mike, Ola,

Am 07.04.2012 22:37, schrieb Ola Lundqvist:
 Mike Gabriel wrote:

 Hi Joachim,
 
 On Sa 07 Apr 2012 22 tel:201222:10:26 CEST Joachim Falk wrote: 
[SNIP]
 The git subproject is hardcoded to this version. Of course if
 you built for wheezy the subproject should be changed to pick up
 the xorg version of wheezy. Furthermore, the symlink xserver.patch
 has to be adjusted accordingly.
 
 As we prepare packages for Debian wheezy and have to move the package 
 into unstable first, we have to use Xorg from unstable.

 You do not necessarily need to use the same, even though it is a good
 starting point. As you can see from vnc4 I still use xfree, not even
 xorg...
Well, you also have disabled vnc.so. If you don't use the current X11
server of the distribution, then a working vnc.so is not guaranteed.
Well, we also could investigate to build vnc.so and only vnc.so against
the installed xserver-xorg-dev.

Regards,
Joachim

P.S.: I created a squeeze-backports branch

- -- 
Joachim Falk joachim.f...@gmx.de

You can always tell a really good idea by the enemies it makes.
  --programmers' axiom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPgW7mAAoJEIjUIAk+3OYMaowP/i/ZGI/403QJD2WUnu+d+FGd
xfQ0fvukXA5sGb/3sMrS32PkAgjVASpTXYLtO7TA7X7PEZil7k2JtYEi6rtfV9IG
QVp4pEQpIUzgpoBocsWSijt7VV5tp32HE3KM09cvmcawsZ1R95mwSg+wi713mwWc
peM74NSGKYFGkcPqemDdyNrBkBMrUVd9ygye3S+Xl9DAEhdWAaAOcpYaAfpemFZj
zFlyu8mpAdKRreCNe8aj5J+8hPnWvGwbiCJMHLVVL+JjpDAwX8zbhC5nCS9d8nOX
O0GQRzIvBpo11vS0BHYs6+DhbMcTvd5kO6uNAqagHy7Yogsm9OU9xAMPu8iv1dVd
9vDW5th1mBm7Jr/0OBm9fvqxMYWXCRi+yolM2G2EkKlfDIjU3wJUBqMRaT5cCQ3P
gw/zD5lYRAxt32PiYpaCUh8jEC3B/Jbig+0pf1XKBVTe8fC4rNQ6pzYejK/khwbV
RflUR6KI7bLwDeFoK+44RO8tzivG58pVeVaJEMROfxMtGo8hvcz2UVhJMUc7bi5u
FCfPru7AYkQN8pIPJHlqxrhWMTIYppv481YDH2zOavxGkdR+IdwMTC3i25yiK9LQ
pjQxSXRupDrnlMZbJipmo1sxaeSLgg+DA2SdITtrP2D60+F3nFskMqZFYtpAUb/G
X3vQEwhIsSpMf61PWdrh
=kPBY
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654924: Inclusion of TigerVNC sources

2012-04-08 Thread Joachim Falk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Mike, Ola

Am 08.04.2012 17:06, schrieb Ola Lundqvist:
 Hi Mike

 Mike Gabriel wrote:
 Joachim Falk wrote:
 Well, you also have disabled vnc.so. If you don't use the current
 X11 server of the distribution, then a working vnc.so is not
 guaranteed. Well, we also could investigate to build vnc.so and
 only vnc.so against the installed xserver-xorg-dev.

 This is a question I have right from the beginning... Do we really
 need the xorg-server code in the package??? Can we not build against
 Xorg's -dev packages in Debian instead? I have been involved in
 providing packages for NX server where we face a very similar
 situation. NX server is currently rejected by Debian as it comes
 with an old and unpatched (no security patches applied that have
 been applied to Xorg since 6.9) X11 source tree.
 If you can build it against xorg dev package that would be
 very good.
 
 For vnc4 and tightvnc it is not possible due to various
 reasons, but for tigervnc I do not know.
 
 For vnc.so I think it should be possible,
It should be possible, but it will require hackery of
tigervnc/unix/xserver/hw/vnc/Makefile.am

 but to build a Xvnc binary I do not know.
nope. That is not possible:

- From xorg-server/configure.ac:
==
#
# XSERVER_LIBS is the set of in-tree libraries which all servers
# require.
# XSERVER_SYS_LIBS is the set of out-of-tree libraries which all servers
# require.
#
XSERVER_CFLAGS=${XSERVER_CFLAGS} ${XSERVERCFLAGS_CFLAGS}
XSERVER_LIBS=$DIX_LIB $MI_LIB $OS_LIB
XSERVER_SYS_LIBS=${XSERVERLIBS_LIBS} ${SYS_LIBS} ${LIBS}
AC_SUBST([XSERVER_LIBS])
AC_SUBST([XSERVER_SYS_LIBS])

- From tigervnc/unix/xserver/hw/vnc/Makefile.am:
==

bin_PROGRAMS = Xvnc

man1_MANS = Xvnc.man

Xvnc_SOURCES = xvnc.cc \
$(top_srcdir)/Xi/stubs.c $(top_srcdir)/mi/miinitext.c \
$(top_srcdir)/fb/fbcmap_mi.c buildtime.c = USES IN TREE SOURCES

nodist_Xvnc_SOURCES = fbrop.h fb.h pixman.h

Xvnc_CPPFLAGS = $(XVNC_CPPFLAGS) -DTIGERVNC -DNO_MODULE_EXTS \
-UHAVE_CONFIG_H \
-DXFree86Server -DVENDOR_RELEASE=$(VENDOR_RELEASE) \
-DVENDOR_STRING=\$(VENDOR_STRING)\ -I$(TIGERVNC_SRCDIR)/common \
-I$(top_srcdir)/include ${XSERVERLIBS_CFLAGS} -I$(includedir)

Xvnc_LDADD = $(XVNC_LIBS) libvnccommon.la $(COMMON_LIBS) \
$(XSERVER_LIBS) $(XSERVER_SYS_LIBS) $(XVNC_SYS_LIBS) -lX11
= USES IN TREE LIBS THAT ARE NOT INSTALLED

Xvnc_LDFLAGS = $(LD_EXPORT_SYMBOLS_FLAG)

So, as we require the Xserver in tree anyway, I did not bother to
build vnc.so against xserver-xorg-dev.

Regards,
Joachim
- -- 
Joachim Falk joachim.f...@gmx.de

You can always tell a really good idea by the enemies it makes.
  --programmers' axiom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPgcJ3AAoJEIjUIAk+3OYMiVEP/i4cCAHLJdXwtTyf7jT1gg3e
9IOado7j80uelzCS6eE1T9TdvSZzLlSwErJHc3yuQ/+ik5nBxTjtkJoz4601bVPp
Qdt+nDanl5cHBYoCrEObvjjXnNrPqsao3XvCiWrnXCqqu1ZPnvqOICTlcXIQwSLo
w5gMMUD0GLvZ6MNIiNUlZSBeP7arYgSIPx44vMeoKq/5Ulpa9XADsITxL84xPjW+
s5d6/it+f6Sxi5bWFVdUTdW1VTqheC8rUrlkpu6OpP8xmgy+1Bz5h0yizhm7BBh8
YAqmKZm/g+IvWlb40P5YqlTS7qVLcG6PfUYkcKIB+vaDfGNxzBHNRpiDIo8Vg2SI
X/VYUu4Nb7Ow1N5pykhudSuTQ1PlHWXMTaYU0egZQyBT/4JUfM0NNF5dFQKCcAKD
cKIDuch3XXeqmWl/x/dNdrHe/6kE9FCW5CZunHzzFYqLyI76bcRxUNLfc+hz7qRU
IXN3S0VKyjeCtKzNVJntnHBIqiJ7G389EZyqPW06MTAftRwvt37XINmrI74dqWPJ
HSgTfLAwHIFridxX9m6M7HgPGO32CFf4QRA1RkcAbe8qsEyZrJoEHBgbN6ClzhDl
6PrHQiqeMalsQWqP1+OJvXBHeLQDxxLjSj5/rZAU6VWTz9D1JPyx5ABJNf1BwXTv
8HV4qq10jwyDY7NE8yV4
=c1mi
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654924: Inclusion of TigerVNC sources

2012-04-07 Thread Joachim Falk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 07.04.2012 14:18, schrieb Mike Gabriel:
 Hi Joachim,
 
 I have look at the package more closely and several thing come to my
 mind...
 
  1. Do we need a package upload sponsor? I have one
 (p...@debian.org, Debian Edu)
Ola, I guess you still have the contacts for Debian proper?
  2. We have to include full TigerVNC source in the package.
 People have to be
 able to download the tigervnc source via our provided package
Yes. The final package should have a .orig.tgz including the tigervnc
sources and the xorg deb packages.
  3. (I am currently playing with source code inclusion...)
  4. The xorg-server download before build has to be automatic...
I am not sure if we are allowed to do such a thing in the build process.
  5. The /debian/copyright file is from XOrg, the TigerVNC stuff is
 missing...
Yes.
  6. All Lintian issues have to be fixed before upload to Debian...
  7. We really should make the package build-able with git-buildpackage
 (using pristine-tar and source format ,,3.0 (quilt)'').
I am not sure how customizable git-buildpackage is. We really have two
upstreams the tigervnc stuff and the xorg debian packages.
 So far for now, will be AFK and enjoy the great weather during the
 afternoon. More tonight.
Have fun.
 
 Joachim, you have done a great job with the packaging!!! Are you
 available on some IRC or Jabber channel??? On irc.debian.org my nick is
 m1k3. Via Jabber you can contact me as mike.gabr...@jabber.ccc.de.
You should have my authorization.
 
 Greets+thanks,
 Mike

Regards,
Joachim
- -- 
Joachim Falk joachim.f...@gmx.de

You can always tell a really good idea by the enemies it makes.
  --programmers' axiom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPgFi9AAoJEIjUIAk+3OYMoKwP/R71axpmQ1SIYKtEISOvZ6bh
kHL+WPASc5+y7dBWYO1k5yTge8zwrljYnbI2dW0dRj2Nslaa2fWwdHrfUFH6SoMs
innWm8f6Sg5ALhxob8oJ6+RpCHHw+iD6fryac/nUWJuBXcJVEYTX/ogQ2VUWc7c7
kNLAaNbqCKmaqxpiYQeh4lkiPHpklTJnoYdeg9zaHuc6Va8UjDKtPnQen8we5CB0
KQbb2w4F+fJUsB3JDkaXzwFDwcK5RPv3vYJ7guMBE1lAU4MJhMyJSKrMXSP0+6kN
PpfTkgohoYKBPRH45Jj1iLKqmx8YLY6Wwq/1vG47EWYekWZdu7quxxBcPwVQgFzA
ZtoXBXzGWjWCLGg2qiRzIJchax71nf0DZPSDauCI3uCg80hkphp0ndbxGdXbIAnF
Mwxyc8e926cWzl068cF5NASwJUo66S55T6fpP44H9ZOY97RnWVn/e6Nl4KQpPFHA
WhRzBPS052ZfevMQV6dJ3xQOwxFiO2WCd0Nx4k/2vO+c0Er4Iovuf8usVI034XXE
Y+/dlFWP8ZYQ7aQnDJCDVeAsuC8QUF740jL6LXaNHnqJ9uFUF9bFZCo1OceSB+6b
7BPL8kGcyqKwdBvA0CkQ4iEsF6LpFlhmy/pqVfOFd4z8jGZ3+12K5p98/1dsiIKZ
7Iw/rTPs2ZKzqkGJ3+Eg
=QUhO
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654924: Inclusion of TigerVNC sources

2012-04-07 Thread Joachim Falk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 07.04.2012 21:20, schrieb Mike Gabriel:
 Hi all,
 
 On Sa 07 Apr 2012 17:51:28 CEST Yaroslav Halchenko wrote:
 

 On Sat, 07 Apr 2012, Joachim Falk wrote:
  I have look at the package more closely and several thing come to my
  mind...

   1. Do we need a package upload sponsor? I have one
  (p...@debian.org, Debian Edu)
 Ola, I guess you still have the contacts for Debian proper?

 or just me (if time permits to be the first ;) )

   7. We really should make the package build-able with git-buildpackage
  (using pristine-tar and source format ,,3.0 (quilt)'').
 I am not sure how customizable git-buildpackage is. We really have two
 upstreams the tigervnc stuff and the xorg debian packages.

 just craft get-orig-sources rule for debian/rules which would create the
 target .tar.gz (or actually multiple ones, e.g. .orig.tar.gz and
 .xorg.tar.gz  since 3.0 (quilt) supports it; but afaik git-buildpackage
 doesn't natively support multiple source tarballs yet... although I
 recall using it somehow...).  Then you just pristine-tar that beast
 
 I am currently working on the get-orig-sources stanza to obtain proper
 orig.tar.gz files for TigerVNC and Xorg. These orig tarballs I will then
 pristine-tar and import to an upstream branch in our pkg-tigervnc.git
 project.
 
 This part will then be able to replace fetch-subprojects.sh.
Ok, I also commit some changes you might find useful to implement
get-orig-source, please pull. I also changed to pkg version to
1.2.0+X1.7.7_14-2 as per Ola's suggestion to also include the xserver
version we use.

 
 Greets,
 Mike
 

Regards,
Joachim Falk
- -- 
Joachim Falk joachim.f...@gmx.de

You can always tell a really good idea by the enemies it makes.
  --programmers' axiom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPgJXVAAoJEIjUIAk+3OYM8JoP/AkNyoVbdA/qYGbVJjUeCJC0
TdncOs4aOAmJv7rX7zCo093kjU3hbq6BpcfdaFn5XAHB4JJHnqnYuj5B8zs5yJci
ud3hfsY9Q+s8BbPVN5/RWhEqAq8qO/P6nzsL42Mg8VQJqDEXNM33NQS9NF6xanP8
X8hHbXeN5/aAPTZYopLzruagJNOSSmztnWsTD4XK56fhWNQDEXY3t5Pc/waYahB8
qhcp/BloNYN8bjbHQFgjeG3i9xuc/GkGO0UfR7rtcK1WZp8gqW8llQxCD0FhyWd9
a7s4RCUYZZ5cUi0j8iX4sBwXHsmd89RH7L+xF4MUZSFb/VNVydqcm/ZQYGkn+Nj/
n00V484/A14HOn2cJwpVo2Yx2aX8fZnWVeBrBZgcw5ah5cp+b9mpg4fZWoaFgsti
i7x856YwJ39Ci209egbAo4n8PT7nebqQsNmkSELjqaUHD49Jx0prpiIeYDqlNuCX
bauLsNGt99wv1i2zboiiM4lXjgeRb8X4VzcT/i5NvHFkUmN8HLNUwiL00QHId1Zx
DJqT4raWhjXu06MNwpPZ2XQ51lugC6RpEHV5/VptmGOxAumbE4ERrDCjZoDjr+2U
5wQXeW5r/gMjiCCEXGCbo2afGRGXON2v0NKIjLTYeYKrmaFL2UeTMqBGW5vByITi
jNq7IFbnKQEwVszp2S8m
=pXVF
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654924: Inclusion of TigerVNC sources

2012-04-07 Thread Joachim Falk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 07.04.2012 22:05, schrieb Mike Gabriel:
 Hi Joachim,
 
 On Sa 07 Apr 2012 21:30:42 CEST Joachim Falk wrote:
 
 Ok, I also commit some changes you might find useful to implement
 get-orig-source, please pull. I also changed to pkg version to
 1.2.0+X1.7.7_14-2 as per Ola's suggestion to also include the xserver
 version we use.
 
 Are you sure, that we import xorg-server 2:1.7.7-14?
 
 If I look at my xorg-server checkout, I see 2:1.11.4-2.
 
 Greets,
 Mike
 


object 869682effd2abbd48c47653e63d451e24666830a
type commit
tag xorg-server-2_1.7.7-14
tagger Julien Cristau jcris...@debian.org 1319927200 +0200

Tagging upload of xorg-server 2:1.7.7-14 to squeeze.


The git subproject is hardcoded to this version. Of course if
you built for wheezy the subproject should be changed to pick up
the xorg version of wheezy. Furthermore, the symlink xserver.patch
has to be adjusted accordingly.

Regards,
Joachim
- -- 
Joachim Falk joachim.f...@gmx.de

You can always tell a really good idea by the enemies it makes.
  --programmers' axiom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPgJ8nAAoJEIjUIAk+3OYMRXEQAISKbK58NscoK1UG58yYk5M4
wM6GH16mRg8VR89TAAmX9NKGRuvjZmL+y2wHeNachK6fQXRrI9wVsGEuWgNee/pC
8s1n13Eq/M90/461+3pkSL2MHx9ExiPKy5mr1lkEAwPre31kf1LIFA6+3y7ZRTsV
Mibd6IcbYVr+bJ99Jp/meG3zZdItCmz4DHySC28OkpC4RBUL16NIRyCRDqP3W6OJ
8x5V7uiY0WgELcNINmWH5ej7A0mw1qk7RyCg4bu+fLhom0Dxv2YIXD2hmOXVrAUj
jKq4X8i4x/eI//MtYd+EYPSF6bNpkjLTr/LQMUhf4deT2+Yq2eN9pHalm7wki8uR
q5TeCf8QET7zLWe4JbkBAM3FJ3frObhjkr2LltP/kDld50yGK15fNMZEsEZyBuod
elhzU+XHzUoX4J37rmcyNjqaPkaEHQjvCbfaKHHpmUiF4+Lqgcn9QBNSO8WjUXjp
e0R2Y6yOax2USw3SIGWefr/W6X622a6WhqTCoEwaUmDeWn8jy4V+53ACKfRWAEft
uwUNA+5THpd4CCeeERYW8rYVIAuqGkT5AW2DhnNSrJPeBZ4RQtDcxUCjbMPgBTPM
kvJnmFdispx+DIh+MN96SjraSu93SjmdeGYW+o2kzia/WnAqCwEfiNaQDB12dvWX
SNwJ6X4x7ZPXUubM402G
=cHRZ
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654924: Alioth Projekt genehmigt

2012-04-06 Thread Joachim Falk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 06.04.2012 18:38, schrieb Mike Gabriel:
 Hi Joachim, Yaroslav,

 On Fr 06 Apr 2012 16:16:13 CEST Joachim Falk wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Am 04.04.2012 02:34, schrieb Yaroslav Halchenko:
 awesome!

 would you mind opening up read-only access to the world?
 Should be open. You can also use
   git clone http://xiao.jfalk.de/~joachim/tigervnc/tigervnc.git
 It should have the same version as the alioth git repo.

 Between, I have updated to tigervnc 1.2.0.

 I have tested latest stuff in Git, please do a pull on master branch on
 Alioth, I have committed some build-deps.

 However, build fails (on squeeze _and_ sid)... See below...

 Any ideas?
Yes. You have a more paranoid build environment than me, i.e., -Wformat
- -Wformat-security -Werror=format-security.
And the compiler caught a security violation. Format string is not
constant but some (maybe user) input.

  } catch (rdr::Exception e) {
vlog.error(e.str());
fl_alert(e.str());
exit_vncviewer();
return;
  }

http://www.fltk.org/doc-1.3/group__group__comdlg.html

fl_alert(e.str()); = fl_alert(%s, e.str()); = that should work


 Mike

 quote
 [ 96%] Built target translations
 /usr/bin/make -f vncviewer/CMakeFiles/vncviewer.dir/build.make
 vncviewer/CMakeFiles/vncviewer.dir/depend
 make[3]: Entering directory
 `/home/mike/tmp/tigervnc.b/obj-x86_64-linux-gnu'
 cd /home/mike/tmp/tigervnc.b/obj-x86_64-linux-gnu  /usr/bin/cmake -E
 cmake_depends Unix Makefiles /home/mike/tmp/tigervnc.b/tigervnc
 /home/mike/tmp/tigervnc.b/tigervnc/vncviewer
 /home/mike/tmp/tigervnc.b/obj-x86_64-linux-gnu
 /home/mike/tmp/tigervnc.b/obj-x86_64-linux-gnu/vncviewer
 /home/mike/tmp/tigervnc.b/obj-x86_64-linux-gnu/vncviewer/CMakeFiles/vncviewer.dir/DependInfo.cmake
 --color=
 Scanning dependencies of target vncviewer
 make[3]: Leaving directory `/home/mike/tmp/tigervnc.b/obj-x86_64-linux-gnu'
 /usr/bin/make -f vncviewer/CMakeFiles/vncviewer.dir/build.make
 vncviewer/CMakeFiles/vncviewer.dir/build
 make[3]: Entering directory
 `/home/mike/tmp/tigervnc.b/obj-x86_64-linux-gnu'
 /usr/bin/cmake -E cmake_progress_report
 /home/mike/tmp/tigervnc.b/obj-x86_64-linux-gnu/CMakeFiles
 [ 96%] Building CXX object
 vncviewer/CMakeFiles/vncviewer.dir/buildTime.cxx.o
 cd /home/mike/tmp/tigervnc.b/obj-x86_64-linux-gnu/vncviewer 
 /usr/bin/g++   -DPACKAGE_NAME=\tigervnc\ -DPACKAGE_VERSION=\1.2.0\
 -DLOCALEDIR=\/usr/share/locale\ -D__BUILD__=\20120406\ -DHAVE_GNUTLS
 -DHAVE_CONFIG_H -g -O2 -fstack-protector --param=ssp-buffer-size=4
 -Wformat -Wformat-security -Werror=format-security -Wall -O3 -DNDEBUG
 -I/home/mike/tmp/tigervnc.b/obj-x86_64-linux-gnu
 -I/home/mike/tmp/tigervnc.b/tigervnc/common/fltk
 -I/home/mike/tmp/tigervnc.b/tigervnc/common-o
 CMakeFiles/vncviewer.dir/buildTime.cxx.o -c
 /home/mike/tmp/tigervnc.b/tigervnc/vncviewer/buildTime.cxx
 /usr/bin/cmake -E cmake_progress_report
 /home/mike/tmp/tigervnc.b/obj-x86_64-linux-gnu/CMakeFiles 93
 [ 97%] Building CXX object vncviewer/CMakeFiles/vncviewer.dir/menukey.cxx.o
 cd /home/mike/tmp/tigervnc.b/obj-x86_64-linux-gnu/vncviewer 
 /usr/bin/g++   -DPACKAGE_NAME=\tigervnc\ -DPACKAGE_VERSION=\1.2.0\
 -DLOCALEDIR=\/usr/share/locale\ -D__BUILD__=\20120406\ -DHAVE_GNUTLS
 -DHAVE_CONFIG_H -g -O2 -fstack-protector --param=ssp-buffer-size=4
 -Wformat -Wformat-security -Werror=format-security -Wall -O3 -DNDEBUG
 -I/home/mike/tmp/tigervnc.b/obj-x86_64-linux-gnu
 -I/home/mike/tmp/tigervnc.b/tigervnc/common/fltk
 -I/home/mike/tmp/tigervnc.b/tigervnc/common-o
 CMakeFiles/vncviewer.dir/menukey.cxx.o -c
 /home/mike/tmp/tigervnc.b/tigervnc/vncviewer/menukey.cxx
 /usr/bin/cmake -E cmake_progress_report
 /home/mike/tmp/tigervnc.b/obj-x86_64-linux-gnu/CMakeFiles
 [ 97%] Building CXX object vncviewer/CMakeFiles/vncviewer.dir/CConn.cxx.o
 cd /home/mike/tmp/tigervnc.b/obj-x86_64-linux-gnu/vncviewer 
 /usr/bin/g++   -DPACKAGE_NAME=\tigervnc\ -DPACKAGE_VERSION=\1.2.0\
 -DLOCALEDIR=\/usr/share/locale\ -D__BUILD__=\20120406\ -DHAVE_GNUTLS
 -DHAVE_CONFIG_H -g -O2 -fstack-protector --param=ssp-buffer-size=4
 -Wformat -Wformat-security -Werror=format-security -Wall -O3 -DNDEBUG
 -I/home/mike/tmp/tigervnc.b/obj-x86_64-linux-gnu
 -I/home/mike/tmp/tigervnc.b/tigervnc/common/fltk
 -I/home/mike/tmp/tigervnc.b/tigervnc/common-o
 CMakeFiles/vncviewer.dir/CConn.cxx.o -c
 /home/mike/tmp/tigervnc.b/tigervnc/vncviewer/CConn.cxx
 /home/mike/tmp/tigervnc.b/tigervnc/vncviewer/CConn.cxx: In constructor
 ?CConn::CConn(const char*)?:
 /home/mike/tmp/tigervnc.b/tigervnc/vncviewer/CConn.cxx:103:21: error:
 format not a string literal and no format arguments
 [-Werror=format-security]
 /home/mike/tmp/tigervnc.b/tigervnc/vncviewer/CConn.cxx: In member
 function ?virtual void CConn::setExtendedDesktopSize(int, int, int, int,
 const rfb::ScreenSet)?:
 /home/mike/tmp/tigervnc.b/tigervnc/vncviewer/CConn.cxx:270:18: warning:
 comparison between signed and unsigned integer expressions [-Wsign

Bug#654924: Alioth Projekt genehmigt

2012-04-06 Thread Joachim Falk

Hi Yaroslav, Mike, TigerVNC developers,

Am 06.04.2012 19:08, schrieb Mike Gabriel:
 Hi Joachim,

 (reincluding the ITP isssue...)

 On Fr 06 Apr 2012 18:59:47 CEST Joachim Falk wrote:

 Am 06.04.2012 18:38, schrieb Mike Gabriel:
 Hi Joachim, Yaroslav,

 [SNIP]

 I have tested latest stuff in Git, please do a pull on master
 branch on Alioth, I have committed some build-deps.

 However, build fails (on squeeze _and_ sid)... See below...

 Any ideas?

 Yes. You have a more paranoid build environment than me, i.e.,
 -Wformat -Wformat-security -Werror=format-security.
 And the compiler caught a security violation. Format string is not
 constant but some (maybe user) input.

   } catch (rdr::Exception e) {
 vlog.error(e.str());
 fl_alert(e.str());
 exit_vncviewer();
 return;
   }

 http://www.fltk.org/doc-1.3/group__group__comdlg.html

 fl_alert(e.str()); = fl_alert(%s, e.str()); = that should work

 So we need some CXX flags in debian/rules? Any recommendations? The
 package should build on paranoid and non-paranoid systems, I guess.

 Can you provide a patch?

 Thanks,
 Mike

Am 06.04.2012 19:17, schrieb Yaroslav Halchenko:
 my 1c: CXX flags should not be overridden to filter out paranoidal flags
I concur
 (it is ok to extend with -O0 for noopt, etc) -- that would complicate
 various hardening etc ports attempts.  But providing a patch for
 upstream allowing to build on such systems would be beneficial!
tigervnc-devel should suffice

Mike, Yaroslav, please do a pull on the master branch on Alioth.
(I hope) I have fixed the issue. However, the fix still needs to be
tested.

Furthermore, I have attached the fix for the benefit of tigervnc-devel.

Regards,
Joachim
-- 
Joachim Falk joachim.f...@gmx.de

You can always tell a really good idea by the enemies it makes.
  --programmers' axiom
Index: vncviewer/Viewport.cxx
===
--- a/vncviewer/Viewport.cxx	(Revision 4882)
+++ b/vncviewer/Viewport.cxx	(Arbeitskopie)
@@ -950,7 +950,7 @@
   case ID_INFO:
 if (fltk_escape(cc-connectionInfo(), buffer, sizeof(buffer))  sizeof(buffer)) {
   fl_message_title(_(VNC connection info));
-  fl_message(buffer);
+  fl_message(%s, buffer);
 }
 break;
   case ID_ABOUT:
Index: vncviewer/vncviewer.cxx
===
--- a/vncviewer/vncviewer.cxx	(Revision 4882)
+++ b/vncviewer/vncviewer.cxx	(Arbeitskopie)
@@ -86,7 +86,7 @@
 void about_vncviewer()
 {
   fl_message_title(_(About TigerVNC Viewer));
-  fl_message(aboutText);
+  fl_message(%s, aboutText);
 }
 
 static void about_callback(Fl_Widget *widget, void *data)
@@ -311,7 +311,7 @@
   delete cc;
 
   if (exitError != NULL)
-fl_alert(exitError);
+fl_alert(%s, exitError);
 
   return 0;
 }
Index: vncviewer/UserDialog.cxx
===
--- a/vncviewer/UserDialog.cxx	(Revision 4882)
+++ b/vncviewer/UserDialog.cxx	(Arbeitskopie)
@@ -156,16 +156,16 @@
 
   switch (flags  0xf) {
   case M_OKCANCEL:
-return fl_choice(buffer, NULL, fl_ok, fl_cancel) == 1;
+return fl_choice(%s, NULL, fl_ok, fl_cancel, buffer) == 1;
   case M_YESNO:
-return fl_choice(buffer, NULL, fl_yes, fl_no) == 1;
+return fl_choice(%s, NULL, fl_yes, fl_no, buffer) == 1;
   case M_OK:
   default:
 if (((flags  0xf0) == M_ICONERROR) ||
 ((flags  0xf0) == M_ICONWARNING))
-  fl_alert(buffer);
+  fl_alert(%s, buffer);
 else
-  fl_message(buffer);
+  fl_message(%s, buffer);
 return true;
   }
 
Index: vncviewer/CConn.cxx
===
--- a/vncviewer/CConn.cxx	(Revision 4882)
+++ b/vncviewer/CConn.cxx	(Arbeitskopie)
@@ -100,7 +100,7 @@
 vlog.info(_(connected to host %s port %d), serverHost, serverPort);
   } catch (rdr::Exception e) {
 vlog.error(e.str());
-fl_alert(e.str());
+fl_alert(%s, e.str());
 exit_vncviewer();
 return;
   }


signature.asc
Description: OpenPGP digital signature

Bug#654924: Alioth Projekt genehmigt

2012-04-06 Thread Joachim Falk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 04.04.2012 02:34, schrieb Yaroslav Halchenko:
 awesome!
 
 would you mind opening up read-only access to the world?
Should be open. You can also use
  git clone http://xiao.jfalk.de/~joachim/tigervnc/tigervnc.git
It should have the same version as the alioth git repo.

Between, I have updated to tigervnc 1.2.0. I have also tested
the 1.1.90 tigervnc-standalone-server and the tigervnc-viewer.
Both packages work as expected. In fact, I am using them right
now.

Yaroslav, can you test the 1.2.0 stuff and the tigervnc-xorg-extension?
Simply git clone the repo and then execute ./fetch-subprojects.sh.
After that dpkg-buildpackage -rfakeroot. After that you should get

tigervnc_1.2.0-1_amd64.changes
tigervnc_1.2.0-1.dsc
tigervnc_1.2.0-1.tar.gz
tigervnc-common_1.2.0-1_amd64.deb
tigervnc-scraping-server_1.2.0-1_amd64.deb
tigervnc-standalone-server_1.2.0-1_amd64.deb
tigervnc-viewer_1.2.0-1_amd64.deb
tigervnc-xorg-extension_1.2.0-1_amd64.deb

 
 *$ ls -ld /git/pkg-tigervnc
 4 drwxrws--- 3 root scm_pkg-tigervnc 4096 Apr  2 20:00 /git/pkg-tigervnc/
 
 I also sent a request to join (can't promise doing much but who knows...)
I have added you.
 
 On Wed, 04 Apr 2012, Joachim Falk wrote:
 
 Dear Mike,
 
 we are in business. Alioth has now a project for tigervnc.
 I also added you as an admin. I myself have a version of
 tigervnc 1.1.90 which builds and generates debs for
Mike, are you still with us?
 
 tigervnc-common_1.1.90-1jf_amd64.deb
 tigervnc-scraping-server_1.1.90-1jf_amd64.deb
 tigervnc-standalone-server_1.1.90-1jf_amd64.deb
 tigervnc-viewer_1.1.90-1jf_amd64.deb
 tigervnc-xorg-extension_1.1.90-1jf_amd64.deb
 
 Testing remains to be done. Also some small features
 from my old tigervnc 1.1.0 package are still not
 merged.
 
 Regards,
 Joachim

Regards,
Joachim
- -- 
Joachim Falk joachim.f...@gmx.de

You can always tell a really good idea by the enemies it makes.
  --programmers' axiom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPfvqmAAoJEIjUIAk+3OYMiGIP/2XeyD5I/GtdbRhODMgM3AjI
0iB9kDz3NyNv6PLV703yLwXwcxGJSK9UVMegROON62uKKNmp5RESoz1hJOKxE8T0
VTV+j7fPMjUkJSMjPcON+aPXrb/tJORe1PmFz8rLKTp/TYCOR87Eo8m/uqOvxGVc
jtKJZbP1FZ83eJFFYAZ0MFKnCek+EIoF+DaLVSSFlPfuaTV39cooUtne6HoQBRaZ
hDsBmQnhY72FhMu/QdP28K2wOIFTH0FhMiX5meTEEzYmclka8cqZ4wfbfNlYZIUZ
B3z082xLTbxYP8Z9j2STQ00kWXujIAYMVaKWQX/GjXPL3Y41F2RQfANrGQdJ5tBK
SbsLW32pfTczP6r0faZ/veLD+GLwl+4+m4NycwflsZwq9fSpt/kW+YpkPKe2TTcx
QyUeHL2ZRhEo7MVUmf6yixrIU3QtbK2oMrRIPwb6BEl5O+0gQSw8XLCHD4h7BGLF
u8V03POZ7VoaDwmL26MRIxRtssGJqRrXBIerjseOERVZYE/APnZ5oD3o9+wYjkUO
J4uqqsBSKRjDa/37dSB6o+HpcAeT5hYD7ayJwk7X0W24XehLLg2G9wk5wTgrIu2Y
1OVrvH2I7h5HB2Jv2/0HctLQ2IghvJxLvb7kbXS8IhUIxpc8zQC2I3/vXUur2Uhg
D+YdeEAkTcR9GXPx8Tvu
=+DmM
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654924: Alioth Projekt genehmigt

2012-04-03 Thread Joachim Falk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Mike,

we are in business. Alioth has now a project for tigervnc.
I also added you as an admin. I myself have a version of
tigervnc 1.1.90 which builds and generates debs for

tigervnc-common_1.1.90-1jf_amd64.deb
tigervnc-scraping-server_1.1.90-1jf_amd64.deb
tigervnc-standalone-server_1.1.90-1jf_amd64.deb
tigervnc-viewer_1.1.90-1jf_amd64.deb
tigervnc-xorg-extension_1.1.90-1jf_amd64.deb

Testing remains to be done. Also some small features
from my old tigervnc 1.1.0 package are still not
merged.

Regards,
Joachim
- -- 
Joachim Falk joachim.f...@gmx.de

You can always tell a really good idea by the enemies it makes.
  --programmers' axiom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPe4HyAAoJEIjUIAk+3OYMymAQAJXK28uzsBNUn1cACp3tjaPK
heS8wRdubd3W1OmuNWBOg6J9W86hfz7QN6shLDyvhUeqhSF3vLlcPiF17WLDDDjw
L6pNqyvmEWai1E3JqbQvEGF/1M0HQeOHa72ZDJfzp1QJ6O8GLQEXyDWMs4cUwjWo
TSOaKfqsBLiBrV2XGbsiuK6IUGEw0oSGOKqB2HDUfDUFT+RqlckjC3jNp4GXSDWo
9A7MDl9VyoAbVgIRSVOAaRF2ASLOWE75jcIdiCY+5uehLMfuZ0aTtaAYnc6chapF
T+qJH0zZzKCHFauW5hsndGSrFOYsulbY6lhH9yBIXL2AWPXmhHP/2aNJ5hIR9MXg
Jq3sClv4o+35zq/qwsUSnCGtmeP/d5VdBMQaog1riMjriG4yN3BANx1uhUeArVJh
+1udlxTyjg0V5V7bQdVzgCcLKSIOxGgqRtyvLcHllqrx83enNeP3rtvapsnf5HTb
EzF6XIzwiPkF3PBQAT3Y28KM7Rc3V5WvLX+HTFIl+dczPYoWq6UF1Ey4JiegbqvS
BPqUzfXaf3Idx+4682Ye96ZUHItPmgmqMzMZPOUDChDkXJBWhRjr9Sxw7Z/hNN8v
GL607AKT3LJxSMI5cBpZ/MoxMalHsy2MOIgqHTi9+S7eNLVkYt16uYEKWy19WOlT
9qUkjSUQ48tj/5CPqvoX
=uwi/
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654924: Fwd: Re: TigerVNC 1.0.90 src debs

2012-03-04 Thread Joachim Falk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 29.02.2012 15:01, schrieb Mike Gabriel:
 Hi Joachim,
 
 On Mo 27 Feb 2012 23:30:51 CET Joachim Falk wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Am 23.02.2012 20:00, schrieb Joachim Falk:
 Am 23.02.2012 13:04, schrieb Mike Gabriel:
 Hi Joachim,

 On Do 23 Feb 2012 11:47:45 CET Joachim Falk wrote:

 Hmm. Wait a bit. At the moment I am at work. Maybe this evening I have
 time to update my package to tigervnc 1.1.90. I already began
 yeasterday
 with this. And you are right there is now only cmake. I have begun
 to integrate the xorg server and the tigervnc sources into their own
 subdirs as git projects and svn checkouts. The quilt problem runs much
 deeper. Quilt for the toplevel project is no problem I think. However,
 the xorg tree has its own quilt files which have to be applied too.

 Hang on. I would love to prepare the package via Git on git.debian.org.
 I am about to commit (at the weekend, probably) a version that is based
 on 1.1.90 and uses quilt and cmake via cdbs.

 Do you have an account on Alioth? I really want to recommend package
 development under Git.
 Did you create your version on Alioth?

 Well git is a distributed version control system ;)

 git clone http://xiao.jfalk.de/~joachim/tigervnc/tigervnc.git
 Mine is as denoted above. It is still not fully functional. But
 the patch system is finalized. Some patches from my tigervnc 1.1.0 deb
 are already applied. The tigervnc and xorg tree integration is mostly
 finished. I still seem to have a problem with the generation of the
 automake/autoconf build files for the xorg tree.

 
 I'd suggest to sync your Git to Alioth and continue/collaborate there.
 Do you have an account on Alioth? If not, I'd suggest registering and
 then apply for membership in the group ,,collab-maint''.
Ok, I have registered as jfalk-guest and applied for the project
pkg-tigervnc. Between, I fixed all the built errors for Xvnc.
Now the install stage has a problem. Furthermore, we will need
to modify the tigervnc configuration to use an external fltk if
possible. I think, we also need to check what else tigervnc uses from
internal sources.

 
 Thanks+Greets,
 Mike

Regards,
Joachim
- -- 
Joachim Falk joachim.f...@gmx.de

You can always tell a really good idea by the enemies it makes.
  --programmers' axiom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPU3FRAAoJEIjUIAk+3OYMH00QAI9F7bgRdt5vz0qdHTpw362j
Qg3qoL25dHQZiJQb7vqWRiRrq4dYFp5xpBSl+Ty+/LbW5xthqPqhXE9zkbvVL1SZ
Vw1Jr/nRmODUDmxzpfXvWt3mh4pX+kKGvIJU3h1vQRO7hET2PC7oq/geyRgolnj9
dhAhB1xjWtvV9fzE/PnySHhhY3hvtdOnYKSL4BNNQL49r/bc7shcXQ51zs1cRxLC
V0QsN6PvImImokv/oE7BA+e0YFfmWFFHAJhno3PEm9xgx5GZRizxlgP44xhOAMuB
pLui5xUWWIme66ogK0xxG1qzDRp2nK4+zGnSaufacJABGI55p73YgyjfGzM72NZE
uUTLI1vrdiPRX++/BHnnIS/pNpx8bTSfjWYWyHS/+L64kUP1BMFm/zfwbhy0VTTq
6E42GTex21DttQQS5Ncr/ZCXSOam/VOwe6V21uN2CfF2alDMlPjps8H3zwCMtnZ/
/1NPH+BkMYUWAaaTuE8Hs4/txCpGHAuAc78enLrKPopwPAGB4R1ls6FyBk3MwDCa
UuG4aj1ad9R8EKLnbPiCo4Zcz5584iPwsQqub2VBOBoHwAuXImt2clCg5sbrOte8
G6IjTRmkPVgbtW/45s2qxB2V7hG5OEcr4f5715Te6ESJYFmDvNJnUcRBdOMFiUbo
gX3MI4DFt+26ISFg2hXJ
=+FQK
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654924: Fwd: Re: TigerVNC 1.0.90 src debs

2012-03-04 Thread Joachim Falk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 04.03.2012 19:44, schrieb Mike Gabriel:
 Hi Joachim,
 
 On So 04 Mär 2012 14:42:50 CET Joachim Falk wrote:
 
 I'd suggest to sync your Git to Alioth and continue/collaborate there.
 Do you have an account on Alioth? If not, I'd suggest registering and
 then apply for membership in the group ,,collab-maint''.
 Ok, I have registered as jfalk-guest and applied for the project
 pkg-tigervnc. Between, I fixed all the built errors for Xvnc.

 Downloading the xorg packaging tree for building the package does not
 look like the right approach for building Xvnc to me. I'd rather think
 that Xvnc can be built against the available Xorg headers on the build
 system.
I don't think so. I don't really download the xorg tree but the debian
package for building various X11 servers (X, xnest, xdmx, xvfb, etc.).
This package is already striped down to use the available system libs
and headers to built the servers. The only development stuff this
package provided is xserver-xorg-dev, which containts only headers.
These are used to develop driver, which are loaded by the X11 server.
So it should be sufficient to built the vnc.so component of tigervnc.
However, I don't think that it is sufficient to built the standalone
Xvnc X11 server.

 I am not sure if your Git repository works the way it currently is
 constructed. At least it looks like a not-so-usual packaging repos.
 I am not an overall expert but what I prefer is using tools like
 git-import-orig and pristine-tar.
Well the tigervnc and xorg stuff are integrated as subprojects into the
top project. I admit the tigervnc stuff is a svn checkout.
The real question is: How do we handle patches on top of the orig
sources. Either we use quilt for this then the subprojectness of xorg
and tigervnc is no problem. Otherwise we drop quilt and use native git
management for both tigervnc and xorg. However, in this case we have
to import a fully patched version of the xorg tree. Otherwise,
the xorg quilt patches would be applied over our modifications.
That is a pretty unsatisfactory situation.


 To give some insight in what I mean I uploaded a point where I would
 start from to my Git site:
 http://code.das-netzwerkteam.de/gitweb?p=debian/tigervnc.git;a=summary
 
 For a better overview, please check out some other packaging projects I
 am involved in:
 http://code.das-netzwerkteam.de/gitweb?p=debian/x2goclient.git;a=summary
 
 Now the install stage has a problem. Furthermore, we will need
 to modify the tigervnc configuration to use an external fltk if
 possible. I think, we also need to check what else tigervnc uses from
 internal sources.
 
 The internally shipped sources appear to be in upstream's common folder.
 These source should be replacable by Debian package header files shipped
 with Debian sid.
 
 Unfortunately, I do not have the time I would like to give to this
 project, I hope for better times during the next couple of weeks. :-(
 
 Greetings,
 Mike
 
 

Regards,
Joachim
- -- 
Joachim Falk joachim.f...@gmx.de

You can always tell a really good idea by the enemies it makes.
  --programmers' axiom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPU9kBAAoJEIjUIAk+3OYM12wP/jR4uVG87p+0X3lIoiZhZmO/
6ZCGjaP0Dr0kypulQNVyhhTkrHFYp7zlx9Pge9TXQzNHHm7MTiTuM/fSNAAc0YT2
cHVov37vttIc6sUcD1SRFIT1xeBkNmw4zoDPIaJDWrE311C3dn0GZDXpGbBMDBcD
la2M7vuZxFQgLokxI4prul2vjKLjRXfCfUrpp8zudZT4Zfc5lGg2t++sUeACn8pw
TvloNP3lgXc6SeSK84lD7qGDLt6GGzFysgmgh5TFs3nJ9F8t8sRMKJtIKkW8AYX0
H4KfQkWcYCWAeKzicaX2lq9B3JFEprxLBxNGX1F2pFustpA7Hx4Nh8GAv5OkE5f8
oMbWacXTmU3uWgq4R8jwhtEuE73NaiiCyA6YeTCRqNBWx5kYe7Rzgo6IUDM192Rc
K6FKpYGmfpl2I1PmDLMTtLR1A3UXVkIuk29tfYm2UDSEEBFW3wPv+LNUWjr2gpVz
5DFZCXD4m8UmkR7IzNyS3El/Suz2UZV4Geaj32eCLxJrKfN2FDozVUQjSz1IiVxG
BuTWSRAatS+yU+SRwm1Scoc6WNuu4WnIirCzrWcTvgFeU7nnCPnR5s/FSyFeJQ9U
6P/Q3BE6p4V1JSdMrwB+v8LKJjlUsmHMTOfr2egOWtoJSmV82AaNKSLLS40ZUgvj
g5Qu6UO+sy15MBGNmmuD
=9H3N
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654924: Fwd: Re: TigerVNC 1.0.90 src debs

2012-02-27 Thread Joachim Falk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 23.02.2012 20:00, schrieb Joachim Falk:
 Am 23.02.2012 13:04, schrieb Mike Gabriel:
 Hi Joachim,
 
 On Do 23 Feb 2012 11:47:45 CET Joachim Falk wrote:
 
 Hmm. Wait a bit. At the moment I am at work. Maybe this evening I have
 time to update my package to tigervnc 1.1.90. I already began yeasterday
 with this. And you are right there is now only cmake. I have begun
 to integrate the xorg server and the tigervnc sources into their own
 subdirs as git projects and svn checkouts. The quilt problem runs much
 deeper. Quilt for the toplevel project is no problem I think. However,
 the xorg tree has its own quilt files which have to be applied too.
 
 Hang on. I would love to prepare the package via Git on git.debian.org.
 I am about to commit (at the weekend, probably) a version that is based
 on 1.1.90 and uses quilt and cmake via cdbs.
 
 Do you have an account on Alioth? I really want to recommend package
 development under Git.
Did you create your version on Alioth?

 Well git is a distributed version control system ;)
 
 git clone http://xiao.jfalk.de/~joachim/tigervnc/tigervnc.git
Mine is as denoted above. It is still not fully functional. But
the patch system is finalized. Some patches from my tigervnc 1.1.0 deb
are already applied. The tigervnc and xorg tree integration is mostly
finished. I still seem to have a problem with the generation of the
automake/autoconf build files for the xorg tree.

 
 Thanks!
 Mike
 
 Regards,
 Joachim

Regards,
Joachim
- -- 
Joachim Falk joachim.f...@gmx.de

You can always tell a really good idea by the enemies it makes.
  --programmers' axiom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPTAQOAAoJEIjUIAk+3OYMNz0P/05zfOvC7wdxVBGqLtNKEw/z
RjqxiBB87O18R3/BwhmcZSNX6+XJwn8CfmUMLFvPG4d5q5bOK0Bi8QnxQI4pHZLs
/nruHrY1VhUsyx3XSbUo9+QXyyAlGPX/WW3V/pU9jpySNXbZMpCcPtddVh0YvHwW
JF9kKHoa+bmCUq31P38Dm54Lx56Fnr1ALlwkZloCMilqrHYvyw7+GifM5SxfgHwK
sqlQB0mPbC5jboGTsVMm9hUeBDA+X27wUddxWZB8eYwsXmB/2v45AWY9GKNT1InF
iDtpVmM1fo9+fSXwqwTaJ7wyRKwOmORcLbMZ2EM/o1k7Ha6IrsXd1NZLb8HKhnKB
hC8b3Mv5diru/lt7MBJgLUdGf1mh1wq2feaNzznJh9ld86Kt87kBD0Roc4K2mKYE
Np4+rpLTHbF6bOPmSpfjXAEZCIQObJT/MlInz+mhdyxsDash2GfIXwy20yofjWBL
go++vxiUCB5UH8p4pBfj4KPrPamLUCxCSOZ3oC5hFfyCvLfDcB1Xyt7FZCcdGLya
/UFET48HqLrUEueNfIYmoJxqEk5TVf5O5aY55RazKaySg79S1SEc3DonuGx+07TU
Esp32pS8Nez7ViwQtnPg4BDmmmUUhcbQu+RuJ3t6rpUpvMcm7VD2tDSHRJaWo5pV
5wO3ZAvQD/SbCuDlJrDa
=7fOs
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654924: Fwd: Re: TigerVNC 1.0.90 src debs

2012-02-23 Thread Joachim Falk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 23.02.2012 08:40, schrieb Mike Gabriel:
 Hi Joachim,
 
 On Di 21 Feb 2012 23:08:03 CET Joachim Falk wrote:
 
 
 P.S.: I update the version on xiao with the latest packages I built
 myself.
 
 I have looked at your package this morning.
 
 Two major issues occur:
 
  o I wonder, why you have not used the cmake build environment provided
by upstream
Tigervnc 1.1.0 still had a configure built system at that time. And I
was not familiar with the cdbs cmake class.

  o the patches have been applied directly on top of the code, I would
 rather
prefer using a patch system (quilt), can you post the source for the
patch files?
Hmm. Wait a bit. At the moment I am at work. Maybe this evening I have
time to update my package to tigervnc 1.1.90. I already began yeasterday
with this. And you are right there is now only cmake. I have begun
to integrate the xorg server and the tigervnc sources into their own
subdirs as git projects and svn checkouts. The quilt problem runs much
deeper. Quilt for the toplevel project is no problem I think. However,
the xorg tree has its own quilt files which have to be applied too.

 Thanks,
 Mike

Regards,
Joachim
- -- 
Joachim Falk joachim.f...@gmx.de

You can always tell a really good idea by the enemies it makes.
  --programmers' axiom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPRhlOAAoJEIjUIAk+3OYMR4cP/1u7UVpMvBFC90XfOaxDLqGU
aKQL9wIt4Re4zCKDH//i/oBAtMTiagXL+OHXSde7MMQ0yOU0JJJyrejBu7o9EYEm
kxDexZO+Q1JLEdhIFVN9KqB4umrGmSbRMAcGO8WfU06Ye9hYopYuQISPnZ6/kCZM
7y39T/kBCdQwRvf135rXThcXT9pkOhiwywxIv71RfKQIUVf9pyEoGAPPBCYUPSd3
5erKHGSULKW1oKCRfJmhyTGgqh6gMju3kZBWQbdiihBmSc4IofJF6LwQpaX9Fd62
HlutiAhFtQ1I6Ww7IkYIkl2yjWPp1Me1DYQK9OCUgEnFmWtw7w9GaGScYbRgJCMF
bSYKIFyNsycGVYMjbJGWB5Y/1Jn6GcfEES9pmzYsSAiwIlpSwkAwHLYTtMCbM8vV
fdhDYgBBipveYvCu0N0UAGkbltey49YeUweC3B/2S4b3EFBgPtBUbCom/X3S0Skn
wNWgajSyfYNwH9ZnPc5BG3b/D7094A7vFgmyYFll3l1EV9cOxHyJ5p0HrvbmH++v
ty9BavGfh5/NNjk2y6cRuR3WE4NXaeOgZmTaBFtuF+Xwbiqt0OAdKjbabOamxWSt
YtNjLIMtBS2H5zVII9oH165j3jAOJBVkC/JY4XPmU19rB2IG1VD2yfRkef3ZI6Tz
/SwUW/Jt84XcItuTylUL
=M8J/
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654924: Fwd: Re: TigerVNC 1.0.90 src debs

2012-02-21 Thread Joachim Falk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey Mike,

fyi, regarding your ITP for tigervnc. I don't think that Antoine has
done anything in this regard. But you might ask or use my package as
basis for yours. I have already applied some fixes from redhat ontop
of the original tigervnc sources. The stuff is all versioned via git
so you can tell what changes I have applied.

Regards,
Joachim

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654924

-  Original-Nachricht 
Betreff: Re: TigerVNC 1.0.90 src debs
Datum: Sat, 17 Sep 2011 20:10:30 +0700
Von: Antoine Martin anto...@nagafix.co.uk
An: Joachim Falk joachim.f...@gmx.de

Hi,

Thanks for this, I was meant to do this ages ago and really dropped
the ball on this one.
I'll take a look asap.

Cheers
Antoine

On 09/17/2011 07:40 PM, Joachim Falk wrote:
 Am 23.05.2011 10:19, schrieb Antoine Martin:
 Hi Joachim,

 Joachim Falk wrote:
 Dear Antoine, you provide some binary debs

 http://winswitch.org/dists/squeeze/main/;

 for debian-squeeze for TigerVNC 1.0.90. However, I seem to be
 incapable of finding the corresponding src debs for the
 binaries. Could you point me in the correct direction? I want
 to tinker a bit with the built options for Xvnc4.

 I am afraid that those builds are hacked using bash scripts and
 are probably wrong. See the recent discussion about how Xvnc
 should be build against the host headers rather than using the
 build-xorg script which is in the source. I keep meaning to do
 things right, but I just don't have the time at present...
 Hi Antoine,

 it took me some time, but I finally got around to make some debs of
 my own. They should build tigervnc properly. Maybe you can use them
 as basis for some semi official version.

 http://xiao.jfalk.de/~joachim/tigervnc = Look here

 Cheers, Joachim
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPRBGYAAoJEIjUIAk+3OYMIuIP/0fLBlK2lQUC4TXtBnBnSFQq
0zE1ICYUiKxzx/BUhXGArYcypEaxk1ris0S98gFwjHOAccVODOij2ASW0FbUMP42
wTBKvjETlGwMmy6OxR4pf1DXUmI7HG9bAlIunzDhCbXnzwzH4Npi3rZVPtZuGMDj
g0DVBioLtPJxuiJ+6nas6N7STkIN9Yn9dwU2f0IAuMNb9HAf1tCYSpBKz8PmSlga
u5Qj/0gLVc+pTF+tYOI1JkWRB4hn5ss0+7REi1kLjr91SXcsckXyKRQlckR+xXbE
cI5bdoLZjpJjnlyE6dbMC/gXAir+FBPikllRS88zILwaG5aE0A+JVCCXt/3nVwQZ
u0lI4pXviUNf1bZ5MkNoQsEBfbEhOHoW2qDf/h6bR2gdvFif5nTEpAMZ9I6zhdu/
QVSwJyhh8VgYC6FZOinGrYmb0S7lwqFHuyuZOxJrBioga2IBzFi44fjDZ89z1BQ3
thKnf8U2oaCekZ/yobg7D3I6V5lkyd31DyDMCcyXRRYTwr4spscrf9pVBCOwZb51
r4YVib972ut1RkkPCOmLYKhqTjtGfiyW6n3p85T2hS2UNbO7Lycc4dVGyTADwf3n
9g/KBLMKB9ZQHHBkZL+zNgHTUAaTFc9K+vL11a1a/Vjf1ZZOGuJTlT74qrbP1yBc
e9NSAxPnQadgPyhF4Opi
=9qVt
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#654924: Fwd: Re: TigerVNC 1.0.90 src debs

2012-02-21 Thread Joachim Falk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 21.02.2012 23:00, schrieb Mike Gabriel:
 Hi Joachim,
 
 On Di 21 Feb 2012 22:50:21 CET Joachim Falk wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hey Mike,

 fyi, regarding your ITP for tigervnc. I don't think that Antoine has
 done anything in this regard. But you might ask or use my package as
 basis for yours. I have already applied some fixes from redhat ontop
 of the original tigervnc sources. The stuff is all versioned via git
 so you can tell what changes I have applied.

 Regards,
 Joachim
 
 I see you do not rely on libjpeg-turbo. I actually am waiting for
 libjpeg-turbo (f...@debian.org is packaging them) to enter Debian sid.
 
 Maybe I should build the package without. Hmmm...
Well. I packaged the stuff for squeeze. My version is not able
to do real time transmission on a 1900x1200 display. I don't know
if libjpeg-turbo will be able to. However, at least with the version
I have built it is again possible to execute a kde session under Xvnc.

P.S.: I update the version on xiao with the latest packages I built myself.

tigervnc (1.1.0-2jf) stable; urgency=low

  * Added RH patch tigervnc11-ldnow.patch disabling lazy symbol
resolution for libvnc.so

  * Added RH patch tigervnc11-rh690245.patch which add TLS encryption to
VeNCrypt

  TigerVNC (Xvnc, x0vncserver, the libvnc.so module, and vncviewer) now
  supports TLS encryption (using VeNCrypt) which allows TLS encrypted
  communication between a server and a viewer. (BZ#653491)

  * Added RH patch tigervnc11-rh588342.patch which fixes EQ overflowing bug.

  Xvnc could become unresponsive and the following error message was
shown
  in the log: [mi] EQ overflowing. The server is probably stuck in an
  infinite loop.. This was caused by a large number of user input
events
  in the Xvnc event queue, which were being processed too slowly. With
  this update, this issue no longer occurs and the system works as
  expected. (BZ#588342)

  * Add RH patch tigervnc11-rh628054-xorg.patch which fixes vmware
keyboard interaction bug.

  Prior to this update, Xvnc (the X VNC server; part of the tigervnc
  package) did not pass keyboard input to a remote VMware workstation
  because it did not take into account types of keyboards which do not
  have modifier keys. With this update, Xvnc recognizes all types of
  keyboards; thus, keyboard input is correctly passed to remote VMware
  workstations. (BZ#628054)

  * Add RH patch tigervnc11-rh645755.patch fix signal interrupted read

  The Xvnc server randomly refused connections when the reading of the
  password file (provided when starting Xvnc with the -PasswordFile
  option) was interrupted by a signal. With this update, the loading
of a
  password file continues after an interrupt signal is issued and
  connections are no longer refused. (BZ#645755)

  * Apply RH patch tigervnc-viewer-reparent.patch which adds vncviewer
embedding support via -Parent option.

  * Apply RH patch tigervnc-102434.patch which adds -passwdInput option
to vncviewer.

 -- Joachim Falk joachim.f...@gmx.de  Thu, 13 Oct 2011 20:12:48 +0200

 
 Thanks+Greets,
 Mike

Regards,
Joachim
- -- 
Joachim Falk joachim.f...@gmx.de

You can always tell a really good idea by the enemies it makes.
  --programmers' axiom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPRBW9AAoJEIjUIAk+3OYM5TwP/Am46x4gWrVGyoV8jx2KOvEX
Oz8P8d1np3+WEoPM8/HDA+wgSLdeIjBj9hgGNLbdWIW1u4XtlX9rqe6vVsdH2sF3
Ku7sjSIIvzU8Y9vzRTGboQnscagpjBZt1h1Mm++2j/eSWBnal/Y6bjvieekrTYQb
laIm4pVi93rwbE5oYI/aMF5rdAdvoK/ShnAIz2sLUea/2E12TtKLSa2IvVVkU6gM
Qi7gLhdhy1uOzTKDnQAGlk0usQ8BDLIiDI3/MZa3zldqLaiiwawrTo4E3AOc5jg5
73/c65LvGa+g6Cis6qSQwWUB+ErXapx6ZN/4cCaA3a8J788vTNYBBKtHx2c5cRBO
vLEslcwz+LlrVGgZyJAB4SyQyQHQneFSJRXa0xxUAxJYxb0VQ+iSsZ8Uc7kEkOA1
PvXtGrH5UxOPvCMjXO+5wsr60i3eHJ9d709P9s2LUjd4QRzVT8hBlCcl6JS9z9LY
u82/GzeQPXwMmwD2GT9ShfT7lpd8BAo/8YdcOrq6dxp7oV7v9FKxKfR+1WVzmnK4
QNLJVTSccYPA9W2fmMfOWZtayDz0Uw9msCy84dOpxwWPJp6KJKW4qdRbY5n6bHd2
fUF+UctL7SfF/V65lkobvj7zWQSe1qR4XTxWzThX8x5ZoV6Ui/yCteR24VttUiX6
UXtFmAskx1O9l71x2xcM
=hMAj
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#483183: cups: Cups web frontend live lock with HostNameLookups Double and unix domain socket client connection

2009-03-01 Thread Joachim Falk

Package: cups
Version: 1.3.8-1lenny4.1
Followup-For: Bug #483183


The cupds server always rejects AF_LOCAL (unix domain sockets)
when HostNameLookups Double is configured in cupsd.conf.
This leads to a livelock with the webfrontend if no
/etc/cups/client.conf is present (debian default).
The patch to fix the problem is attached. It disables
DNS reverse lookups for localhost connections be it
from 127.0.0.1 (IPv4), ::1 (IPv6), or unix domain sockets.

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.18-openvz-028stab060.2 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages cups depends on:
ii  adduser3.110 add and remove users and groups
ii  cups-common1.3.8-1lenny4.1   Common UNIX Printing System(tm) - 
ii  debconf [debconf-2 1.5.24Debian configuration management sy
ii  ghostscript8.62.dfsg.1-3.2lenny0 The GPL Ghostscript PostScript/PDF
ii  libavahi-compat-li 0.6.23-3lenny1Avahi Apple Bonjour compatibility 
ii  libc6  2.7-18GNU C Library: Shared libraries
ii  libcups2   1.3.8-1lenny4.1   Common UNIX Printing System(tm) - 
ii  libcupsimage2  1.3.8-1lenny4.1   Common UNIX Printing System(tm) - 
ii  libdbus-1-31.2.1-5   simple interprocess messaging syst
ii  libgnutls262.4.2-6+lenny1the GNU TLS library - runtime libr
ii  libkrb53   1.6.dfsg.4~beta1-5MIT Kerberos runtime libraries
ii  libldap-2.4-2  2.4.11-1  OpenLDAP libraries
ii  libpam0g   1.0.1-5   Pluggable Authentication Modules l
ii  libpaper1  1.1.23+nmu1   library for handling paper charact
ii  libslp11.2.1-7.5 OpenSLP libraries
ii  lsb-base   3.2-20Linux Standard Base 3.2 init scrip
ii  perl-modules   5.10.0-19 Core Perl modules
ii  procps 1:3.2.7-11/proc file system utilities
ii  ssl-cert   1.0.23simple debconf wrapper for OpenSSL
ii  xpdf-utils [popple 3.02-1.4  Portable Document Format (PDF) sui

Versions of packages cups recommends:
pn  avahi-utils   none (no description available)
ii  cups-client   1.3.8-1lenny4.1Common UNIX Printing System(tm) - 
ii  foomatic-filters  3.0.2-20080211-3.2 OpenPrinting printer support - fil
pn  smbclient none (no description available)

Versions of packages cups suggests:
ii  cups-bsd1.3.8-1lenny4.1  Common UNIX Printing System(tm) - 
pn  cups-driver-gutenprint  none   (no description available)
pn  cups-pdfnone   (no description available)
ii  foomatic-db 20080211-2+nmu1  OpenPrinting printer support - dat
ii  foomatic-db-engine  3.0.2-20080211-1 OpenPrinting printer support - pro
pn  hplip   none   (no description available)
pn  xpdf-korean | xpdf-japa none   (no description available)

-- debconf information:
  cupsys/raw-print: true
  cupsys/backend: ipp, lpd, parallel, scsi, serial, socket, usb, snmp, dnssd
#! /bin/sh /usr/share/dpatch/dpatch-run
## HostNameLookups_Double_AF_LOCAL.dpatch by Joachim Falk joachim.f...@gmx.de
##
## DP: Fix HostNameLookups Double in conjuction with AF_LOCAL connections.
@DPATCH@
--- orig/scheduler/client.c.orig	2009-02-26 22:34:25.0 +0100
+++ new/scheduler/client.c	2009-02-26 22:45:49.0 +0100
@@ -279,32 +279,39 @@
 }
   }
 
-  if (hostname == NULL  HostNameLookups == 2)
+  /*
+   * Check for presence of a localhost client. These clients do not
+   * need DNS reverse lookup matching. More importantly this also
+   * includes AF_LOCAL connections for which DNS reverse lookup
+   * makes no sense. This fixes a BUG where AF_LOCAL connections
+   * where always rejected when DNS reverse lookup is enabled.
+   */
+  if (!httpAddrLocalhost(con-http.hostaddr)  HostNameLookups == 2)
   {
-   /*
-* Can't have an unresolved IP address with double-lookups enabled...
-*/
+if (hostname == NULL)
+{
+ /*
+  * Can't have an unresolved IP address with double-lookups enabled...
+  */
 
-cupsdLogMessage(CUPSD_LOG_DEBUG2,
-cupsdAcceptClient: Closing connection %d...,
-con-http.fd);
+  cupsdLogMessage(CUPSD_LOG_DEBUG2,
+  cupsdAcceptClient: Closing connection %d...,
+  con-http.fd);
 
 #ifdef WIN32
-closesocket(con-http.fd);
+  closesocket(con-http.fd);
 #else
-close(con-http.fd);
+  close(con-http.fd);
 #endif /* WIN32 */
 
-cupsdLogMessage(CUPSD_LOG_WARN,
-Name lookup failed - connection from %s closed!,
-con-http.hostname

Bug#483183: I screwed up.

2009-03-01 Thread Joachim Falk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The previous message should have opened a new bug report.

Regards,
Joachim Falk
- --
Joachim Falk joachim.f...@gmx.de

You can always tell a really good idea by the enemies it makes.
  --programmers' axiom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmqwnIACgkQ/BnjNq3zHnLCVwCeMKECqmUtWaMK9a7v8J5xJOC6
y6cAmwf4qjufXD1Tl4MPazRnLMFWpq21
=aD6U
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#517718: cups: Cups web frontend live lock with HostNameLookups Double and unix domain socket client connection

2009-03-01 Thread Joachim Falk

Package: cups
Version: 1.3.8-1lenny4.1
Severity: normal
Tags: patch


The cupds server always rejects AF_LOCAL (unix domain sockets)
when HostNameLookups Double is configured in cupsd.conf.
This leads to a livelock with the webfrontend if no
/etc/cups/client.conf is present (debian default).
The patch to fix the problem is attached. It disables
DNS reverse lookups for localhost connections be it
from 127.0.0.1 (IPv4), ::1 (IPv6), or unix domain sockets.

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.18-openvz-028stab060.2 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages cups depends on:
ii  adduser3.110 add and remove users and groups
ii  cups-common1.3.8-1lenny4.1   Common UNIX Printing System(tm) - 
ii  debconf [debconf-2 1.5.24Debian configuration management sy
ii  ghostscript8.62.dfsg.1-3.2lenny0 The GPL Ghostscript PostScript/PDF
ii  libavahi-compat-li 0.6.23-3lenny1Avahi Apple Bonjour compatibility 
ii  libc6  2.7-18GNU C Library: Shared libraries
ii  libcups2   1.3.8-1lenny4.1   Common UNIX Printing System(tm) - 
ii  libcupsimage2  1.3.8-1lenny4.1   Common UNIX Printing System(tm) - 
ii  libdbus-1-31.2.1-5   simple interprocess messaging syst
ii  libgnutls262.4.2-6+lenny1the GNU TLS library - runtime libr
ii  libkrb53   1.6.dfsg.4~beta1-5MIT Kerberos runtime libraries
ii  libldap-2.4-2  2.4.11-1  OpenLDAP libraries
ii  libpam0g   1.0.1-5   Pluggable Authentication Modules l
ii  libpaper1  1.1.23+nmu1   library for handling paper charact
ii  libslp11.2.1-7.5 OpenSLP libraries
ii  lsb-base   3.2-20Linux Standard Base 3.2 init scrip
ii  perl-modules   5.10.0-19 Core Perl modules
ii  procps 1:3.2.7-11/proc file system utilities
ii  ssl-cert   1.0.23simple debconf wrapper for OpenSSL
ii  xpdf-utils [popple 3.02-1.4  Portable Document Format (PDF) sui

Versions of packages cups recommends:
pn  avahi-utils   none (no description available)
ii  cups-client   1.3.8-1lenny4.1Common UNIX Printing System(tm) - 
ii  foomatic-filters  3.0.2-20080211-3.2 OpenPrinting printer support - fil
pn  smbclient none (no description available)

Versions of packages cups suggests:
ii  cups-bsd1.3.8-1lenny4.1  Common UNIX Printing System(tm) - 
pn  cups-driver-gutenprint  none   (no description available)
pn  cups-pdfnone   (no description available)
ii  foomatic-db 20080211-2+nmu1  OpenPrinting printer support - dat
ii  foomatic-db-engine  3.0.2-20080211-1 OpenPrinting printer support - pro
pn  hplip   none   (no description available)
pn  xpdf-korean | xpdf-japa none   (no description available)

-- debconf information:
  cupsys/raw-print: true
  cupsys/backend: ipp, lpd, parallel, scsi, serial, socket, usb, snmp, dnssd
#! /bin/sh /usr/share/dpatch/dpatch-run
## HostNameLookups_Double_AF_LOCAL.dpatch by Joachim Falk joachim.f...@gmx.de
##
## DP: Fix HostNameLookups Double in conjuction with AF_LOCAL connections.
@DPATCH@
--- orig/scheduler/client.c.orig	2009-02-26 22:34:25.0 +0100
+++ new/scheduler/client.c	2009-02-26 22:45:49.0 +0100
@@ -279,32 +279,39 @@
 }
   }
 
-  if (hostname == NULL  HostNameLookups == 2)
+  /*
+   * Check for presence of a localhost client. These clients do not
+   * need DNS reverse lookup matching. More importantly this also
+   * includes AF_LOCAL connections for which DNS reverse lookup
+   * makes no sense. This fixes a BUG where AF_LOCAL connections
+   * where always rejected when DNS reverse lookup is enabled.
+   */
+  if (!httpAddrLocalhost(con-http.hostaddr)  HostNameLookups == 2)
   {
-   /*
-* Can't have an unresolved IP address with double-lookups enabled...
-*/
+if (hostname == NULL)
+{
+ /*
+  * Can't have an unresolved IP address with double-lookups enabled...
+  */
 
-cupsdLogMessage(CUPSD_LOG_DEBUG2,
-cupsdAcceptClient: Closing connection %d...,
-con-http.fd);
+  cupsdLogMessage(CUPSD_LOG_DEBUG2,
+  cupsdAcceptClient: Closing connection %d...,
+  con-http.fd);
 
 #ifdef WIN32
-closesocket(con-http.fd);
+  closesocket(con-http.fd);
 #else
-close(con-http.fd);
+  close(con-http.fd);
 #endif /* WIN32 */
 
-cupsdLogMessage(CUPSD_LOG_WARN,
-Name lookup failed - connection from %s closed!,
-con-http.hostname

Bug#508484: Bug in strace off by one in string_quote, patch lifted from CVS of developer Dmitry V. Levin

2008-12-11 Thread Joachim Falk

Package: strace
Version: 4.5.17+cvs080723-2
Severity: important
Tags: patch


I have decided to notify you of the off by one BUG in string_quote.
This stuff seems to be fixed in CVS HEAD between revision 1.80 and 1.81
for util.c. For your convenience I have attached the patch as lifted
from CVS. Applying attached patch fixed the BUG for me for a debian
lenny system running on x86_64 arch (AMD64).

Regard,
Joachim Falk

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (520, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.18-openvz-028stab059.6 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages strace depends on:
ii  libc6 2.7-16 GNU C Library: Shared libraries

strace recommends no packages.

strace suggests no packages.

-- no debconf information
2008-11-09  Dmitry V. Levin  l...@altlinux.org

* util.c (string_quote): Fix support for NUL-terminated string.
Add comments.
(printpathn): Fix the case when ... was appended to the output
but no truncation was actually made.  Add comments.
(printstr): Fix memory allocation.  Fix two cases when ... was
appended to the output but no truncation was actually made.
Add comments.

--- util.c.orig 2008-07-19 15:08:55.0 +0200
+++ util.c  2008-12-08 18:46:21.0 +0100
@@ -407,6 +407,12 @@
 
 static char path[MAXPATHLEN + 1];
 
+/*
+ * Quote string `instr' of length `size'
+ * Write up to (3 + `size' * 4) bytes to `outstr' buffer.
+ * If `len'  0, treat `instr' as a NUL-terminated string
+ * and quote at most (`size' - 1) bytes.
+ */
 static int
 string_quote(const char *instr, char *outstr, int len, int size)
 {
@@ -417,12 +423,18 @@
if (xflag  1)
usehex = 1;
else if (xflag) {
+   /* Check for presence of symbol which require
+  to hex-quote the whole string. */
for (i = 0; i  size; ++i) {
c = ustr[i];
-   if (len  0  i == size - 2  c != '\0')
-   ++i;
-   if (len  0  c == '\0')
-   break;
+   /* Check for NUL-terminated string. */
+   if (len  0) {
+   if (c == '\0')
+   break;
+   /* Quote at most size - 1 bytes. */
+   if (i == size - 1)
+   continue;
+   }
if (!isprint(c)  !isspace(c)) {
usehex = 1;
break;
@@ -433,20 +445,31 @@
*s++ = '\';
 
if (usehex) {
+   /* Hex-quote the whole string. */
for (i = 0; i  size; ++i) {
c = ustr[i];
-   if (len  0  c == '\0')
-   break;
+   /* Check for NUL-terminated string. */
+   if (len  0) {
+   if (c == '\0')
+   break;
+   /* Quote at most size - 1 bytes. */
+   if (i == size - 1)
+   continue;
+   }
sprintf(s, \\x%02x, c);
s += 4;
}
} else {
for (i = 0; i  size; ++i) {
c = ustr[i];
-   if (len  0  i == size - 2  c != '\0')
-   ++i;
-   if (len  0  c == '\0')
-   break;
+   /* Check for NUL-terminated string. */
+   if (len  0) {
+   if (c == '\0')
+   break;
+   /* Quote at most size - 1 bytes. */
+   if (i == size - 1)
+   continue;
+   }
switch (c) {
case '\': case '\\':
*s++ = '\\';
@@ -495,18 +518,25 @@
return i == size;
 }
 
+/*
+ * Print path string specified by address `addr' and length `n'.
+ * If path length exceeds `n', append `...' to the output.
+ */
 void
 printpathn(struct tcb *tcp, long addr, int n)
 {
-   if (n  sizeof path - 1)
-   n = sizeof path - 1;
-
-   if (addr == 0) {
+   if (!addr) {
tprintf(NULL);
return;
}
 
+   /* Cap path length to the path buffer size,
+  and NUL-terminate the buffer. */
+   if (n  sizeof path - 1)
+   n = sizeof path - 1

73 matches

Mail list logo