[Pkg-x2go-devel] [X2go-dev] nxproxy and nxcomp uploaded to Ubuntu Oneiric

[Mike Gabriel]

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 maintainers
>
> did 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 Alioth
>
> Why 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.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/20110521/4ac7fef3/attachment.pgp>