[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

Attachment: pgpUPrXpAh0g4.pgp
Description: Digitale PGP-Unterschrift


Reply to: