[Pkg-x2go-devel] Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries
mike.gabriel at das-netzwerkteam.de
Fri Jan 13 20:41:56 UTC 2012
Hi Stefan, hi all,
On Fr 13 Jan 2012 17:14:08 CET Stefan Lippers-Hollmann wrote:
> On Friday 13 January 2012, Mike Gabriel wrote:
>> Hi Reinhard, dear all,
>> On Fr 13 Jan 2012 11:31:00 CET Reinhard Tartler wrote:
>> > http://anonscm.debian.org/gitweb/?p=collab-maint/x2go/nx-libs.git;a=tree
>> > and, from what I see, is appropriate for being uploaded to unstable. For
>> > clarity, I think we should rename the git repository from nx-libs.git to
>> > nx-libs-light.git. Mike, can you please handle that?
> Thanks, this makes it a lot more reviewable (I stumbled into the full
> nx-libs in the master branch last night). nxcomp and nxproxy indeed
> don't pose the problems I mentioned last night.
:-) two different pair of shoes... Good that Reinhard cloned the
original ITP into two (client-only and server/client).
> But I wonder, why do you need a merged source for this? The current
> versions of nxcomp and nxproxy, each built from their own upstream
> tarballs, is already at the 3.2 version state and should work (given
> that it's in the archive already) for client uses. If it's stability,
> as mentioned in some other string of this thread, that would be a
> mere - fixable - bug, but the only reason I can see is making the
> server parts buildable - and that's where my concerns of massive code
> duplication of the full X.org 6.9 source tree return.
nx-libs (LITE) is a subset of folders of nx-libs (FULL). If there was
acceptance or a strategy or a new realm of possiblities that would
allow us uploading nx-libs (FULL) to Debian some time in the future,
the transition would be smooth. Apart from that: nxproxy is just one
compilation step. nxproxy is a similar binary wrapper for libxcomp3.
So by content the two belong together, maintaining two source projects
is a possibility but it was not our choice here (we as in X2Go
upstream who is redistributing the NX tarballs).
Note: the X2Go packaging team uses X2Go upstream as NX redistributor.
And (being in a double role) X2Go upstream provides one tarball
nx-libs lite/light (with applied patches). This is done, because the
Debian packaging team shall have a patch-friendly upstream.
> Yes, I'm aware of how well the NX protocol works over high latency and
> low bandwidth links, but I also know how much of a nightmare it is to
> work on that imake hell of the forked X.org 6.9, aka nx-x11, source.
Yes, it is a hell. I have been in it for the last four weeks (over
X-mas, yeahhh...). But as I use X2Go for loads of projects from simple
GUI based system administration to large schools with PXE X2Go boot
environments (LDAP-based, PostgreSQL based), I really have a deep
interest of providing that to others (i.e. to Debian).
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B
mail: mike.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 490 bytes
Desc: Digitale PGP-Unterschrift
More information about the Pkg-x2go-devel