Hello,
I just finished testing nxproxy and nxcomp with x2goclient, python-x2go and qtnx on Ubuntu Oneiric. Test was successful with no regression that I could see.
So I now have:
Uploading in Oneiric, packages will be available to all users in a few minutes.
As I mentioned earlier, I've been basing these two uploads on a clean NoMachine tarball and re-applied the changes from the existing Debian package and from x2go's git. They can all be found in the (relatively well documented) debian/patches/ directory of the source packages.
Links:
I'd think these two meet Debian criteria for upload, so if anyone with upload rights to Debian can help getting them in there it'd help minimizing the delta between Ubuntu and Debian (as I'd ask for a "sync" from Debian, thereby removing any remaining delta).
http://launchpadlibrarian.net/72109360/nxcomp_3.2.0-7-1.1_3.5.0-1-0ubuntu1.d...
As promised, attached to this e-mail are a few patches which I "think" should be merged into x2go's git repository for future daily builds of the packages.
nxproxy-update-debian-control.patch: proved to not be needed (at least on Ubuntu)
nxproxy-update-manpage-mention-nx.patch:
nxcomp-debian-patch-sa_restorer.patch
nxcomp-debian-update-control.patch proved to not be needed (at least on Ubuntu)
nxcomp-debian-update-copyright.patch
The result is that both sources packages are lintian-clean with lintian 2.5 including "I:" tags. The resulting binary packages are lintian-clean with lintian 2.5 though some have "I:" tags warnings that should be fixed in the future (library symbol and some fixes for the manpage), lintian output attached.
I'll now start working on python-x2go, making sure it's in shape to be added to the Ubuntu archive and will get it uploaded so hopefully it should be in Ubuntu by the end of next week (it needs to go through quite extensive review as it's a new package).
Have a good weekend!
-- Stéphane Graber Ubuntu developer http://www.ubuntu.com
Hi Jonas, hi Stéphane,
On Fr 20 Mai 2011 21:01:10 CEST Stéphane Graber wrote:
I'd think these two meet Debian criteria for upload, so if anyone with upload rights to Debian can help getting them in there it'd help minimizing the delta between Ubuntu and Debian (as I'd ask for a "sync" from Debian, thereby removing any remaining delta).
@Jonas: What steps are needed for this to happen? I just wanted to
upload Stéphane's work to pkg-x2go on collab-maint (Alioth), but
Alioth seems to be offline.
A set of very-near-future goals could be:
o drop nxcomp (and later nxcompext, nxcompshad) from code.x2go.org (X2go
upstream), same with nxproxy (the code is not a real fork...)
o provide X2go-specific patches for NX 3.5 upstream on X2go
upstream that are
recommended to be incorporated by package maintainers
o draw Stéphanes work to collab-maint on Alioth
o prepare the packages for Debian upload
o upload to Debian sid
o sync to Ubuntu oneiric
o from then on: use Alioth for the package maintenance (and sync to Ubuntu)
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@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Sat, May 21, 2011 at 12:45:22 (CEST), Mike Gabriel wrote:
Hi Jonas, hi Stéphane,
On Fr 20 Mai 2011 21:01:10 CEST Stéphane Graber wrote:
I'd think these two meet Debian criteria for upload, so if anyone with upload rights to Debian can help getting them in there it'd help minimizing the delta between Ubuntu and Debian (as I'd ask for a "sync" from Debian, thereby removing any remaining delta).
@Jonas: What steps are needed for this to happen? I just wanted to upload Stéphane's work to pkg-x2go on collab-maint (Alioth), but Alioth seems to be offline.
A set of very-near-future goals could be:
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
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'?
o draw Stéphanes work to collab-maint on Alioth
Why not on code.x2go.org?
o prepare the packages for Debian upload o upload to Debian sid o sync to Ubuntu oneiric o from then on: use Alioth for the package maintenance (and sync to Ubuntu)
-- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4
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@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Sat, May 21, 2011 at 20:43:18 (CEST), Mike Gabriel wrote:
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).
But that's exactly my point, there is really no need for breaking the current setup before we have a something that can replace it. And now you propose to move the current known-to-work branches to something that doesn't even exist yet.
IOW: Go ahead and do whatever you want to do on alioth. When it's ready, we can reconsider if it's worth moving there, but currently, I really don't see any benefit in breaking the current infrastructure. And for Stéphane's work, well, what's the problem with integrating it in the *current* infrastructure on code.x2go.org?
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.
No, it's not. Please have a look at them.
[...]
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.
I don't know what to say here, I'm speechless.
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.
Still, so far you have found exactly one DD (i.e., me) willing to work on x2go upstream. Just granting access to everybody is unlikely to improve the situation.
-- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4
Hi Stéphane,
On Fr 20 Mai 2011 21:01:10 CEST Stéphane Graber wrote:
Hello,
As I mentioned earlier, I've been basing these two uploads on a clean NoMachine tarball and re-applied the changes from the existing Debian package and from x2go's git. They can all be found in the (relatively well documented) debian/patches/ directory of the source packages.
The patches are now committed to our Git (so that we have them in our
current build env) under your identity.
Unfortunately, Alioth has been down for some days already and so has
git.debian.org (location of collab-maint).
I want to start working on the 3.5.0 branch on Alioth ASAP.
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@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...