Stuart Herbert | Gentoo

Contrary to what this week’s Gentoo Weekly News says, please don’t contact me about the removal of the nxserver packages from Portage. That section of GWN appears to be auto-generated by a script, and not checked by a human prior to publication.

Please send all queries to nx@gentoo.org instead. I believe Stefan (genstef) has taken over the NX packages.

My upstream contact at 2X - Raphael - would like to hear from anyone interested in continuing the work I started on bringing the 2X Linux Terminal Server to Gentoo.

If that sounds like you, please contact him directly via raphael at 2x dot com.

I’ve only done very basic testing, but so far I’m not seeing any problems at all with trying to run the Perl components (nxnode, and nxserver) from the 2X Linux Terminal Server as normal, interpreted Perl scripts.

I’m currently working on a patch for the server/nxnode component so that it will create and install nxnode and nxserver as interpreted scripts. Mostly, it’s just a case of stripping out all the steps used for compiling the scripts, and trying to install the dedicated Perl interpreter.

Once that’s done, it’ll be time to fill out the src_install() function of the ebuild … and then we’ll have something we can start testing for real.

When you port a package to Gentoo, the “normal” course of action - and the one that I teach when I’m mentoring - is to do what upstream does as closely as possible. But for the 2X Linux Terminal Server, I’m thinking of breaking that advice, just this once.

I have the bundled copy of Perl building, but I’m not sure it’s practical to use it. We’ll basically end up duplicating dev-lang/perl, and that’s more maintenance than I can take on.

The only reason I can think of for using the bundled Perl is that the perlcc installed as part of our “system” Perl 5.8.8 is currently broken. It can’t compile nxnode (I haven’t managed to try nxserver yet); when you try, it reports that it can’t resolve POSIX::SIGHUP et al. I knocked up a tiny test script to print POSIX:SIGHUP, and that works fine when run via the Perl interpreter. Try to compile it, however, and perlcc segfaults.

My knowledge of Perl is not what it used to be, but for the moment, my take on it is that we can’t rely on perlcc. But, do we need to?

Now that the code is GPL’d, I’m wondering if there is any practical reason to compile these scripts any more? (Raphael or any Perl wizards - can you think of a reason why we still need to compile these scripts?)

Unless there’s a compelling reason otherwise, I think the way forward is to patch server/nxnode to create and install normal Perl scripts to be interpreted by the “system” copy of Perl. That’s what I’m going to work on this week, unless someone can point out why it’s a bad idea.

The client compiles. The server mostly compiles. “All” that’s left to sort out is the sizable wad of Perl that makes up nxnode.

It might just be easier (at least for now) to build a dedicated Perl library & modules for 2X … which is exactly what the commercial NXServer does. I might have to do it anyway - according to the build script, the commercial NXServer builds its own copy of Perl w/ threads enabled.

I’ll have a play with it this evening.

The ebuild for compiling 2X’s GPL’d code is coming along. Even w/ ccache, it takes about ten minutes between compilation failures (and every fix increases that time), but it’s all going in the right direction.

• I’ve ported all of our existing patches over from the NoMachine ebuild to work against 2X’s code.
• I’m part-way through producing the patches necessary to build the code in-situ. So far, it’s just been adjusting paths between the different NX components for libraries and include files.

I’ve gotten as far as building nxclient and nxdesktop, plus required libraries. The next step (tomorrow) will be to do the same patching for the server components.

All this work is on x86. Once everything’s working on there, we’ll then have something to patch up for amd64 and other architectures.

This morning’s work on the ebuild for the 2X Linux Terminal Server has been a mixture of creating a basic ebuild to build the package, and then swearing profusely at trying to get the deps built out of Portage.

And, to cap it off, I can’t even file bugs to let the teams know about their broken packages because of our ongoing Bugzilla problems.

Mornings like this make me wonder why I’m still spending time on Gentoo; and that’s before you throw in other frustrations like the mess that the previous Trustees left the Foundation in. I know I’m not exactly in a calm mood right now, but I’m so annoyed with the (in)actions of the previous Trustees that part of me wishes that we could bar the lot of them from ever being Trustees again on the grounds of maladministration.

The rest of me just wish that folks wouldn’t take up for the post of Trustee unless they really understood that the role first and foremost is about good administration. The folks who want to go on a power trip should stick to being on the Council.

The good news is that the only bundled component for 2X Linux Terminal Server that we don’t have in Portage is Passwd-Linux … and that’s a perl module, so adding it is a no-brainer.

Of course, atm I’m just assuming that the Terminal Server will happily use the system-installed modules w/out any problems. Given that these modules are normally shipped w/ binary releases of the Terminal Server, I’m probably going to be proved wrong on that count.

Hopefully I’ll find out tomorrow.

Mmm … the 2X tarball includes the source code for a large number of components that we can provide through Portage, and their build script is very easy to read (if only that could be said about all upstream packages! )

If I get the ebuild to do the work instead of using their build script (which doesn’t work out of the box anyway, as it’s designed to work with a subversion checkout), it might not take that long to get something available for testing.

Mmm.

Booted the box on Friday evening, only to be greeted by the dreaded “Invalid partition table” error all the time. Ho hum. Time for a new disk. Damn thing was only two years old too, and it’s not a machine that’s ever been regularly used.

I’ve managed to get the box self-hosting again, but I’ve had other things to do this weekend, so it’ll be a few days before I’ve re-installed Gnome and KDE onto the box. Apologies to folks who are waiting for an amd64-compatible ebuild for FreeNX; it’ll be a few more days yet.

Although, tbh, you’re not missing much … I honestly can’t see me asking for FreeNX being marked stable on x86 until the orphaned processes bug is tracked down and resolved. And I’m seriously having second thoughts about whether I want to spend the time on that or not.

In the meantime, the folks at 2X have very kindly created the source tarball we need to get their GPL’d NX server and client into Portage. At 108M in size, it’s quite the download, and it’ll take me a few mornings to get it all compiled here on the laptop (I normally spend an hour every morning in my local Starbucks working on Gentoo stuff, before heading off to the office), but it’ll be worth the effort. Thank God for ccache, that’s all I can say!

Mmm … shame I can’t afford a new Mac Book Pro Core 2 Duo this side of the holiday season