Hi I wasn't on this mailing list so far, so I just respond to this mail which seems to cover at least a few aspects I would like to answer.
On Tuesday 07 June 2005 19:08, you wrote: > On Tue, 7 Jun 2005, Roberto C. Sanchez wrote: > > > OK. Thanks. I already have a sponsor in Anibal Salazar. [...] > You are completely right. We are using it here and that's why I also have > a great interest. My impression of the packager of the Kanotix version > is, that they are happy if the software just hits the Kanotix CD and > they did not recognize the profit they could gain if it would be an > official Debian package. This would save them a great amount of time. > Stefan has obviousely understand the problem, but may be tha package is > to much for a single person. I'm working on debian compatible nx/ freenx packages for kanotix since late august/ early september 2004 and subsequently got in contact with Fabian Franz (freenx upstream) and kalyxo.org. Since october 2004 I'm working in cooperation with kalyxo.org on improving and updateing the packages and kalyxo.org (http://kalyxo.mornfall.net) has always been considered the offcial home for these packages (while they were simultaneously uploaded and included in kanotix) by freenx upstream. Fabian Franz (freenx upstream) got me in contact with you on April the 16th and I'm working on cleaning up the packages, whenever my free time allows it, since then. Getting some help from experienced debian developers, especially concerning good practices for packaging and better knowledge of debian policies would really be great. > > Last time I saw (about 2 weeks ago) the packages were 6 months old. It > > is good to see they are updated. Where did the .orig.tar.gz originate? Unfortuneately, major packaging changes in order to get the package acceptable for debian combined with personal lack of time. The last (security) update to the stable branch (1.4.x) of the NX libraries developed by NoMachine took place on february the 10th, the current development snapshots of the 1.5.x branch aren't yet compatible to freenx 0.4.0, which was released on the 11th of may. > Stefan reassembled it from different files. I guess he will answer this > question in detail. I really would urge for group maintainance in this > case. If nneded I (or Anibal?) could start an alioth project with SVN > archive. [...] NoMachine NX libraries: The .orig.tar.gz is generated by the get-orig-source target of debian/rules, in the current packages provided by http://kalyxo-archive.mornfall.net/pool/main/n/nx/ or my pre- experimental packages hosted at http://debian.tu-bs.de/project/kanotix/unstable/nx/ basically it fetches these source tarballs from upstream (http://www.nomachine.com/download/nxsources/): - nxagent - nxauth - nxcomp - nxcompext - nxdesktop: rdesktop based - nxproxy - nxviewer: TightVNC 1.2.4 based - nx-X11, XFree86 4.x based These sources are (no longer) fetched and compiled for the following reasons: - nxssh: offers additional functions to nxssh dependend software components, freenx no longer depends on this since 0.2-2 (09.10.2004) "due to security concerns from SuSE" (freenx changelog). The removal of this component from the current .orig.tar.gz (1.4.0.2) might affect a number of free nx implementations, but on the other hand maintaining an openssh fork (forked at 2002-06-26?) might not be the easiest task and is at least not necessary for freenx itself. - nxspool: was never packaged so far and is samba3 (=) based and used to implement smb printing/ tunneling into the nx protocol, to my knowledge this isn't currently needed bs freenx. - nxesd: is a pre- woody fork of a debian esound package, which neither compiles on current debian sid (unmet build-deps) nor is used by freenx. - nxuexec, nxwin, nxscripts are not needed for nx/ freenx or on linux at all. - nxtunnel* scripts written by Peter Rockai and Kurt Pfeifle: not necessary for freenx and definately don't belong to the NoMachine sources, maybe reused in a separate package. Necessary patches have been collected under the terms of the GNU GPL from SuSE, FreeBSD, Gentoo, Fedora (Rick Stout), Mandrake and NoMachine or initially written by Peter Rockai and/ or adapted by me. Starting with the nx 1.4.0.2 packages (same source base as the previous 1.4.0-m2* packages), I started a major packaging clean up in cooperation with Andreas Tille, which removed the mentioned sources from the .orig.tar.gz and moved internally used program components from /usr/bin/ to /usr/lib/nx/, these changes are nearly complete and still need some regression testing - at the same time the packaging mechanisms itself were significantly changed (cdbs/ simple-patchsys, new ./configure && make structure loosely adapted from the one used by SuSE (and Mandrake). The following things are currently on my personal todo list for the nx package: - creation of a proper -dev package - splitting of the the .orig.tar.gz into separate packages (at least for nxdesktop, nxviewer - if possible also for nxproxy and maybe nxcomp, nxcompext - nxagent and nxauth might be rather hard to compile outside of the nx-X11 source tree). - further clean up, streamline the orig.tar.gz for 1.5.0. FreeNX: freenx has similarily been restructured (moving everything not needed by the user to /usr/lib/nx/). Compared to the nx libraries, this package seems quite good shape and the debconf mechanisms might be almost finished (setting up sshd while configuring and being a bit more gentle running/ supended sessions while upgrading are next on my list, desperately needed are manpages for nxserver, nxsetup and node.conf). Compatibilty Overview: i386: compiles and works quite fine powerpc: I can't test this myself, but I've been assured that it compiles and runs. ia64: I've been told that it compiles, although I never got any response if it actually works. amd64: compiles after some patching, basic functionality can be tested by switching to plain X bitmaps (nxclient), but still suffers from serious redrawing problems - not in a usable state right now. There are still some lintian warnings/ errors to discuss, but those will be fixed by a -dev package or better discussed at another time. Thank you very much for your support and I hope not to have spammed this list too much. Kind regards Stefan Lippers-Hollmann, [EMAIL PROTECTED]
pgpqUPMSGEzTM.pgp
Description: PGP signature
