I sent the e-mail below to fix the misunderstanding on both mailing-lists but forgot to set the right sender and so got stuck in the moderation queue :) Since then, Mike clarified the confusion but here it's anyway.
On Fri, 2011-05-20 at 17:25 +0200, Mike Gabriel wrote: > Hi all, Hi! > for those being able to contribute (and not subscribed to > pkg-x2go-devel on Alioth), I would like to make you aware on a > discussion thread around newly released NXv3.5 sources in relation to > X2go. > > Thread: > http://lists.alioth.debian.org/pipermail/pkg-x2go-devel/2011-May/thread.html > > Latest NX 3.5 release > http://www.nomachine.com/download.php > > Ubuntu is probably about to use these new NX libs for X2go in Ubuntu. > The current approach is also to make nxagent itself work with X2go > (which might not be what we want, as x2goagent has been patched by > Alex quite a bit already). The Ubuntu developer, Stéphane Graber, who > is really keen to get X2go into Oneiric, is very co-operative and > interested in X2go / Python-X2go. His objective is to keep everything > (X2go Git, Debian, Ubuntu etc.) compatible, assure that patches are > shared and that the code base is in sync, etc. Bad timing, I just sent an e-mail to pkg-x2go-devel about this :) It was actually a typo I made this morning. I don't plan on having nxagent and x2goagent compatible. They already have a different name so they can perfectly co-exist in the archive. X2goagent is from my point of view a clear fork of nxagent, so it's fine to have both. What I'm currently working on is getting python-x2go in the archive, which means updating its dependencies: - nxproxy - nxcomp I have test packages for these two including all the changes from x2go, the new upstream release and remaining patches from Debian. > But still, we (x2go-dev upstream) have to find a disposition on the > dual-upstream issue around NX libs. As mentioned in my last e-mail (just a few minutes ago), my problem is with: - nxcomp - nxcompext - nxcompshad - nxproxy Where we have two "upstreams" for the same code. x2go would have to choose to either fork the code and rename them to x2go* or maintain a patchset on top of NoMachine's code that maintainer can use in their packages. > In x2go-upstream we have to discuss if our nx* packages in Git are > actually a hijack (as NoMachine still seems to be active around NX > 3.5). Due to the latest NXv3.5 release by NoMachine there now exists a > dual-upstream situation... This should have been avoided and now has > to be dealt with. > > Currently, I see two possibilities (for X2go into Debian without > bringing up namespace issues), but I might be lacking sight here: > > 1. We make X2go work with NoMachine's NX 3.5 (complemented through a > patchset provided by X2go, this patchset may not break NX > functionality -> qtnx, freenx, etc., but improve functionality with > X2go). > > 2. We really fork NX libs, nxproxy (as already happened with > x2goagent). That would mean a renaming of libraries and also Git > projects etc, e.g.: x2goproxy, x2gocomp, x2gocompext, x2gocompshad. > > Please stay tuned around this topic and contribute to the discussion, > if possible. > > Thanks > Mike > > > _______________________________________________ > X2go-dev mailing list > X2go-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/x2go-dev -- Stéphane -- Stéphane Graber Ubuntu developer http://www.ubuntu.com
signature.asc
Description: This is a digitally signed message part
_______________________________________________ X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev