Crusty Blaa

Its been a fun week completely focused on Fedora packaging and
bugzilla work. Had a nice wake up call on how huge a time sink
fixing non x86 builds can be. A day and a half debugging an ABI
mismatch on pcc breaking the gtk2 build! Sheesh.

Its nice to finish up a week with the feeling that you've got
a good handle on things, though.

I've been really taken by surprise at how my motivation has jumped
hugely with the move to Red Hat. I'm even enjoying things like bugzilla
work, packaging and release-team stuff these days. Clearly, this can't
last. And I've got to get back hacking on things like Vino soon ...

GNOME 2.6 looks like its pretty much on track. Things like the gtk+
schedule and the constant string freeze breakage has given the release
team the heebie jeebies somewhat, but after our irc meeting last night
I'm feeling pretty confident the release will come out without any huge
hitches.

Alex and I have been updating the GNOME packages in Fedora Core to the
latest GNOME Beta ones. Hopefully, by the time FC2 test2 goes into devel
freeze on Friday we'll have most of the packages updated. A big priority
is to get the new file selector out to the Fedora testing masses, so
I'm going to update gtk+/atk/pango/glib to the latest today. Also going
to shove the little gnome-netstatus applet in too :-)

So, I had a discussion with the RFB protocol maintainers at
RealVNC about getting the
new RFB security types - which I added in Vino for doing the
encryption thing - registered in the protocol. As far as I can
make out at this point:

• There are more security types registered than appear in
  the protocol specification.
• Security types 1-16 are reserved for "standard" security
  types.
• A security type becomes "standard" when it is added to the
  "reference implementation" ... which just happens to be
  the same product RealVNC is trying to make money from.

I can't make up my mind whether I care about this or whether
I should just leave sleeping dogs lie. My main worry is what
happens if we decide there are other additions we want to make
to the protocol. Oh well, cross that bridge when we come to it.
The RealVNC guys are friendly, so I don't expect there would
actually be problems.

In the end, we agreed that I had to use different numbers to
identify the new security types and I had to modify the way
the new security type actually worked. End result - I've just
pushed a new version of Vino with incompatible changes in the
protocol.

I've just imported Vino into CVS. Its "Remote Desktop" functionality
for GNOME using VNC's RFB
protocol which I wrote while at Sun.

Currently, the most notable bits over other VNC servers are:

• Support for encrypting the RFB protocol stream using SSL
• A dialog which prompts the user before allowing a remote user
  to connect
• Exports the local display, so you don't have to start up a
  seperate VNC display
• Properly integrated into GNOME

More details

here.

The

TODO list includes:

• Use the new
  DAMAGE extension instead of polling the screen
• Write a GTK+ based client - the current client is a Java applet
  but you can use any other vncviewer without encryption
• Service discovery using DNS-SD and mDNS
• Better authentication schemes

A rather "interesting" day doing bugzilla work, disting and
pushing 2.5.4 tarballs and jhbuilding GNOME HEAD in parallel
over a 56k dialup line. I think I'll be counting down the
minutes until the Eircom
fools manage to flick the magic DSL switch ...

How on earth did I put up with this for an entire year in
New Zealand?