Hi Reinhard, We have to distinguish current code bases properly:
code.x2go.org -> X2go upstream (currently containing sort of upstream NX'ish
code forks, which is a non-optimal redundancy now that
NoMachine has brought up some recent work of NX again)
collab-maint on Alioth -> package preparation for Debian
(pkg-x2go-devel team)
Launchpad.net/~x2go -> build engine for Ubuntu (provided by X2go upstream) packages.x2go.org -> build engine for Debian (provided by X2go upstream)
On Sa 21 Mai 2011 17:13:33 CEST Reinhard Tartler wrote:
o drop nxcomp (and later nxcompext, nxcompshad) from code.x2go.org (X2go upstream), same with nxproxy (the code is not a real fork...)What problem would that solve? AFAIUI this step would break the PPA and leave users of released versions of ubuntu in the cold
As discussed on pkg-x2go-devel, for Debian the Debian maintainers of X2go will have to use NoMachine as upstream for nxlibs + nxproxy. So, there is no point of hosting NX code on code.x2go.org.
For the X2go Launchpad PPA (build engine) I would then draw in the code from collab-maint Git (instead of drawing in the code base from code.x2go.org / X2go Git).
o provide X2go-specific patches for NX 3.5 upstream on X2go upstream that are recommended to be incorporated by package maintainersdid you already look at those 'patches'?
This might be a misunderstanding. Stéphane's patches, those that he sent to the x2go-dev list, are all packaging patches. I took a quick look and they look fine. However, I would love to avoid using those to re-patch our NX libs on code.x2go.org.
What I meant with X2go patches for NX is: if the X2go project encounters a problem with the NX libs or nxproxy, then we should have a location where we provide patches to fix those issues, of course, without breaking the NX API for qtnx and other clients.
Normally, we would send these patches to NoMachine (and we will try that), but we should also plead the Debian maintainers of NX libs to incorporate those patches into the Debianized NX packages.
o draw Stéphanes work to collab-maint on AliothWhy not on code.x2go.org?
Because code.x2go.or is intended for X2go upstream development. Not for building Debian packages.
On Alioth's collab-maint workspace all Debian developers have write access by default. That's my main reason for hosting the packaging code there.
Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419 GnuPG Key ID 0xB588399B mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
pgpzpZL3HFt9H.pgp
Description: Digitale PGP-Unterschrift
_______________________________________________ X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
