[Pkg-x2go-devel] [X2go-dev] Starting to get x2go into Ubuntu Oneiric

Thu May 19 18:25:22 UTC 2011

On Thu, 2011-05-19 at 19:46 +0200, Mike Gabriel wrote:
> Hi Stephane,

Hi Mike,

> On Do 19 Mai 2011 17:36:32 CEST Stéphane Graber wrote:
> 
> >> Everything around packaging for Debian (and subsequently Ubuntu) we
> >> should discuss on the related mailing list
> >> (pkg-x2go-devel at lists.alioth.org):
> >> https://alioth.debian.org/mail/?group_id=100595
> >
> > Oh, that's great news, for some reason I forgot to look for an ITP :)
> >
> > As we need the package in Ubuntu really soon to start testing and
> > getting it through the MIR process, I'm probably going to upload
> > python-x2go directly in Ubuntu.
> >
> > The package should be mostly identical to what should enter in Debian,
> > so it should be really easy for it to be uploaded in Debian and once
> > it's in unstable, sync it in Ubuntu so we make sure we have the same
> > packages in both distros.
> >
> > For all the other x2go packages, as it's less urgent for me, I can
> > definitely wait to have it in Debian and then just request a sync.
> > Depending on the time I have, I might help getting the packages in shape
> > for an upload in Debian (will just need someone to do the actual
> > upload).
> 
> Please register at Alioth and let me know your login name. I will add  
> you to the pkg-x2go team.

"stgraber-guest" should work.

> >> I have not known about NX 3.5 yet (DAMN!!!) Is there an active
> >> community around NXv3 alive somewhere else apart from the X2go
> >> community??? For Debian we will provide upstream NX. That should be
> >> the same for Ubuntu (if you start uploading packages to Ubuntu before
> >> we do so for Debian).
> >
> > The packages in Debian and Ubuntu (same one) are quite outdated.
> 
> I know. Our Git hosts a 3.4.0.x (we have added a nano version number).  
> X2go has a release scheme that throws out a altogether-working-well  
> code bundle. Next release will be called Baikal.
> 
> Before this Baikal release (a recommended set of package versions  
> bundled together as _the X2go Software), I would like to stay away  
> from NX 3.5 if it does not work out of the box. (We have to look at  
> the related patchset 3.4 -> 3.5, too).

Yeah, that's something that I noticed earlier today and that seems weird
to me.
From my point of view (maybe I'm wrong) it seems like x2go is kind-of
forking the "upstream" NX code but at the same time tries to follow
their versioning and keep the same names.

This could become a real problem if x2go's version of nxproxy, libxcomp*
end up being somehow incompatible with NoMachine's as people won't
really know what they're installing.

At least for Ubuntu, I'm going to consider NoMachine as the upstream of
everything that's listed on this page:
http://www.nomachine.com/sources.php

And if x2go needs some specific changes (I'm going to have to go through
git to figure that out), then it should be applied through documented
patches in debian/patches and tested for compatibility with everything
using the same libraries (qtnx being one of them).

So far, my tests show that I can easily get a FreeNX + X2go server
working and can easily get python-x2go/x2goclient and qtnx working using
the same libraries.

I perfectly understand that NoMachine isn't a great upstream and that
there's bug fixes that need to be applied, but I still prefer carrying
these as well separated patches in the package rather than using a
different upstream.

In an ideal world (to me), x2go would be maintaining a list of
recommended patches on top of NoMachine's source code, that I could
easily pull and integrate in the Debian package (as debian/patches/
files).

> > Updating them is quite trivial, so I'm currently doing it in Ubuntu and
> > will send the new packaging back to Debian once I'm done, so hopefully
> > we can have both up to date and in sync.
> 
> As the X2go project will be upstream for Debian in the near future  
> send the changes, patchsets, insight to the x2go-dev list (development  
> of X2go upstream). This will then lead to an inclusion into Debian.

Will do.

> >> DO you think you can work on our NX code base and do the changes
> >> there? Work on each Git project (nxcomp, nxcompext, nxcompshad) could
> >> start in a Git branch first.
> >
> > I'm currently using the upstream tarballs from
> > http://www.nomachine.com/sources.php and updated the packaging based on
> > what's in the x2go PPA and in Debian. Resulting packaging should
> > probably end up in Debian and then be synced in Ubuntu.
> 
> Ok, so you also actually picked up dead source from NoMachine. Thank  
> god... Thus, it again makes sense to incude all actual code changes  
> (version packaging changes) into the X2go Git repos... (to have all  
> code together end up in Debian, finally).

It really is an issue to have two "upstreams" for the same "project" ...
I'm really reluctant to use x2go as the "upstream" for anything that's
at http://www.nomachine.com/sources.php

Though I'm perfectly fine using NoMachine's source code and applying
recommended changes from x2go's git on top of that.

Of course if Debian actually chooses to "switch" upstream for the NX
code over to x2go, then I'll be fine syncing from Debian. I just think
it'll confuse a lot of people having two "active" upstreams for the
"same" code...

> > I'll have a look at the git branches on code.x2go.org to see if I missed
> > anything and will propose patches or merge proposal (if I end up reading
> > about using git ;)) for any change I needed to do.
> 
> I'll be on a seminar at the weekend, but if you have any questions,  
> please do not hesitate to contact me (myself being in the role of the  
> Git-Admin  on code.x2go.org).

Will do.

> > My current goal is really to get something in Ubuntu as soon as possible
> > so other teams can start using it but I really don't want to end up
> > having to maintain my own packaging.
> > So as soon as the same version (or newer version) enters Debian, I'll
> > get a sync done so Ubuntu drops its own packaging and uses Debian's
> > (which hopefully will be close to identical).
> 
> Ok, ... identical -> that shall be the goal!!!
> 
> >> The question is, if it is advisable to update to NX 3.5 first and then
> >>   packaging for Ubuntu. My recommendation is to get packages into
> >> Debian/Ubuntu first and then start working on NX 3.5. But I do not
> >> have a clue how dramatic the changes are.
> >
> > For nxproxy, which is the only one I looked at so far, the changes are
> > close to non-existent.
> > Current packaging (for 3.4) worked as-is and the patch that Debian
> > carries (allowing stdin as input) applied without any change.
> 
> Whenever you have the first reliant diffs at hand, send them for  
> introspection to x2go-dev. We are first interested in actual upstream  
> source code changes. The packaging is subsidiary for an update from  
> 3.4.a.b -> 3.5.c.d.

I should have the 3.4 => 3.5 diff for nxproxy shortly, will send it to
x2go-dev then.

> >> Do you have a clue how intense the effect on x2goagent (formerly
> >> x2goagent) will be???
> >
> > I haven't started working on the libraries yet, I'm guessing that's
> > where the changes might be a bit more substantial and so might break
> > x2go. If that's the case, I'll use 3.4 instead and we can deal with 3.5
> > later :)
> 
> For the NX libs: also take a look at our Git. I have just today  
> reworked the autoconf/configure/make process.

ok

> >> > Next on my list will be to get python-x2go into the Ubuntu archive as
> >> > that's what we'll be using for our client integration (Ubuntu Software
> >> > Center is in python) and finally I'll be working on getting the
> >> > x2goserver itself in the repository (lower priority than the rest) so we
> >> > don't need a PPA to build our servers.
> >>
> >> Again, how about working on Debian inclusion. I am not involved with
> >> Ubuntu policies too much. Will there be syncs between Oneiric and
> >> Debian sid in the future? Or is that pathway already closed?
> >
> > Ubuntu is currently in auto-sync from Debian unstable until the
> > Debian-Import-Freeze on 16th of June. After that I can easily file
> > manual sync requests that get processed daily, until our Feature Freeze
> > on the 11th of August.
> 
> Ah... Ok. Fine. Thanks for the info.
> 
> > So my current plan is:
> > - Get python-x2go, nxproxy and libxcomp3 in their latest version in
> > Ubuntu and get people to test it (enable integration in Software Center)
> 
> Please considering using the latest-known-to-work-with-X2go versions  
> as opposed to the not-supported-any-more versions from NoMachine.  
> This, of course, all depends on the contents of the patchsets, but  
> basically, I think, we should approach the  
> latest-known-to-work-with-X2go approach.

I usually prefer re-testing and fixing stuff to work with the lastest
"stable" release from the current upstream as unfortunately I can't
guarantee that someone else will push 3.5 to the Ubuntu archive.
We don't have per-package maintainers in Ubuntu so someone else can
perfectly decide to push a new upstream release at any time before
Feature Freeze. People usually ask the last uploader if there's any
reason to stick with an old version, but not always, therefore if it
works with 3.5, I prefer to go with it.

> > - File the required MIR (Main Inclusion Request) to get these into the
> > "main" component which is a requirement for Ubuntu to ship it by default
> > (needs to go through a security review which can take a while)
> 
> Ok.
> 
> > - Have any packaging change forwarded to x2go PPA and Debian
> 
> Forward it to git.x2go.org (x2go-dev at lists.berlios.de) or rather  
> commit the changes yourself, once I have a go from Heinz Graesing to  
> grant you commit permissions.
> 
> > - Depending on the time I have, help getting the packages ready for
> > upload in Debian.
> 
> GREAT!!! Again: register on Alioth for team membership and also apply  
> for write access to the collab-maint project on Alioth. That's where  
> we will put the Debian packages together. The ITP holder (Jonas) is  
> the developer of CDBS. So, the X2go packages will be packaged with  
> CDBS (not debhelper). Just to let you know as early as possible.

Done. I have mix of old dh, dh7 and cdbs packages that I upload quite
regularly, so I don't particularly mind, though I tend to use dh7 for
most new packages.

> > - Check the state in Debian and as soon as the same versions are there,
> > sync from Debian and drop the Ubuntu packaging entirely. After that,
> > whenever possible packaging changes will happen in Debian only and get
> > synced in Ubuntu.
> 
> Ok!
> 
> >> If closed then I suggest you do your work for Oneiric but for the
> >> Ubuntu p-series we count on Debian sid? What do you think?
> >
> > I hope we'll already get Debian and Ubuntu in sync for Oneiric, we still
> > have time so it's perfectly doable.
> 
> It partially depends on X2go upstream development. The core developer  
> (Alex) is quite short of time currently (AFAIK).
> 
> >> > I hope to have most packages built for Oneiric in my test PPA
> >> > (https://launchpad.net/~stgraber/+archive/experimental) so I can do some
> >> > tests to make sure these don't break anything (including FreeNX/qtnx)
> >> > and if everything looks good, I'll be pushing these into the archive
> >> > later this week.
> >>
> >> Stéphane! Couldn't we arrange that you commit the work you perform to
> >> our Git which then will be synced to our PPAs (lauchpad.net/~x2go) and
> >>   from there you upload to Ubuntu main????
> >
> > I can certainly upload my changes directly to git instead of sending
> > patches.
> 
> Yes... that should be solution A. Waiting for feedback from Heinz  
> Graesing (project head).
> 
> > So far, working on nxproxy, the only changes I "think" I had to do was
> > switch to a non-native package and re-apply the current patches in
> > Debian.
> 
> The native packaging we have chosen so that we do not have to haggle  
> around with orig.tar.gz files. So, for official packaging that has to  
> be changed to 3.0 (quilt).

Yep, that's what I did.

> > I was planning on sending an e-mail today or tomorrow with the changes I
> > had to make to nxproxy and libxcomp3 when updating to 3.5 and preparing
> > for Ubuntu, including description of the changes and patches when
> > relevant. If you prefer I commit that to git directly, I can certainly
> > do it.
> 
> Looking forward to that. Please cross-check with my latest git commits  
> (this morning, till 2pm CEST). As mentioned earier I might have not  
> too much time to take a very close look at the weekend, but we will see.
> 
> >> This would make much more sense to me. Please apply for team
> >> membership, so that Heinz can give you edit-access to
> >> launchpad.net/~x2go.
> >
> > It's a restricted team so I can't apply, someone needs to add me.
> 
> I have sent a short notice off-list to Heinz.
> 
> >> I would really appreciated to go this way!!!!
> >>
> >> > Once I'm done and everything works for me, I'll be forwarding the list
> >> > of packaging changes I had to do (if any) so we can ensure your
> >> > dailybuilds and the "official" Ubuntu packages are in sync.
> >>
> >> Again, why not join the X2go team???
> >
> > Just waiting for someone to add me ;)
> 
> I am speaking of the human beings team, not only the launchpad/~x2go  
> team... :-)

I will certainly contribute patches whenever I need to patch something
and will help with Debian packaging if I find some time.
I unfortunately have to multi-task on quite a few upstream projects +
actual distribution work :(

> Greets,
> Mike

Thanks

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-x2go-devel/attachments/20110519/df384a27/attachment-0001.pgp>