Hi Laszlo, Great to see efforts going forward ;-) What about making packaging available in some public VCS (I would prefer/recommend GIT) so we could collaborate more efficiently. Few brief comments (can't look in detail atm):
* have you considered dh-autoreconf to help with the pain of regenerated files? * as you could see from other vnc packages, /usr/bin/vnc* is managed through alternatives: $> ls -l /usr/bin/*vnc* | grep altern lrwxrwxrwx 1 root root 22 Jan 21 2010 /usr/bin/Xvnc -> /etc/alternatives/Xvnc* lrwxrwxrwx 1 root root 27 Jan 21 2010 /usr/bin/vncconfig -> /etc/alternatives/vncconfig* lrwxrwxrwx 1 root root 27 Jan 21 2010 /usr/bin/vncpasswd -> /etc/alternatives/vncpasswd* lrwxrwxrwx 1 root root 27 Jan 21 2010 /usr/bin/vncserver -> /etc/alternatives/vncserver* lrwxrwxrwx 1 root root 27 May 22 2009 /usr/bin/vncviewer -> /etc/alternatives/vncviewer* lrwxrwxrwx 1 root root 29 Jan 21 2010 /usr/bin/x0vncserver -> /etc/alternatives/x0vncserver* lrwxrwxrwx 1 root root 28 May 22 2009 /usr/bin/xvncviewer -> /etc/alternatives/xvncviewer* so it would be great to adopt this strategy for this package as well * would be great similarly to split out server and client into separate packages * what kind of error were you getting while hitting that problem with building twice in a row? I have tried on a stable Debian system, and succeeded to do fakeroot debian/rules build, clean, build * jpeg library is probably not just libjpeg (didn't look what is from it there) but extended one with turbojpeg, which ideally indeed should be packaged separately... FWIW it is already present in few other packages: $> zgrep turbojpe ~/deb/docs/Contents-sources.gz chromium-browser: src/third_party/libjpeg_turbo/turbojpeg.h chromium-browser: src/third_party/libjpeg_turbo/turbojpegl.c ssvnc: vnc_unixsrc/vncviewer/turbovnc/turbojpeg.h x11vnc: x11vnc/misc/turbovnc/turbojpeg.h * zlib -- I don't see any commits in tigervnc repository hinting on them patching it (besides build system)... they carry 1.2.5 version which is already in Debian unstable (stable carries 1.2.3.4) so it would be ok to use system-wide available one so little patching I guess is due to make that happen NB I don't know if 1.2.3.4 is API compatible, so it might make sense to carry copy of zlib along in the sources so it could be easily used while building backports (which I would hope to be able to do) Hope this of some help ;) keep on good work On Wed, 30 Nov 2011, Laszlo Boszormenyi wrote: > Hi Yaroslav, > I've made a preliminary tigervnc package[1]. It builds and seems to be > working. However it has some problems, like debian/copyright is not DEP5 > compatible and due to upstream issues it can't be build two times in a > row. Even worse, upstream tarball contains embedded code of libjpeg and > zlib1g. Only libjpeg seems to be used from the system. > Cheers, > Laszlo/GCS > [1] dget -x http://www.routers.hu/gcs/tigervnc_1.1.0-1.dsc -- =------------------------------------------------------------------= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111130230111.gh8...@onerussian.com
