[Pkg-x2go-devel] Bug#655618: ITP: nx-libs -- NX protocol libraries and binaries

[Mike Gabriel]

Hi Stefan, hi all,

On Fr 13 Jan 2012 17:14:08 CET Stefan Lippers-Hollmann wrote:

> Hi
>
> 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?
>>
>> Renamed!
>> http://anonscm.debian.org/gitweb/?p=collab-maint/x2go/nx-libs-lite.git;a=tree
> [...]
>
> 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

-- 

DAS-NETZWERKTEAM
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

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.alioth.debian.org/pipermail/pkg-x2go-devel/attachments/20120113/2f280d0c/attachment.pgp>