Oh, the Windows/Fedora time schizophrenia…

Every other beta test release, my time zone goes askew, thanks to Windows defaulting to keeping the hardware clock at localtime and Linux kernel+userland’s ever shifting way of dealing with this (to be fair, at least they tried – OS X just insisted on the clock being set to UTC).

Right now it seems that systemd¬†expects the kernel to assume the clock was UTC and so it had to do the heavy lifting of adding the 7 hours offset — but somehow the kernel (or some other utility?) has already added those 7 hours, with the result that my clock ended up 14 hours ahead. And somehow this didn’t manifest itself until I booted to Windows to pull some pictures from my Lytro…

Going to try a clean installation first, to reduce the possible things that could go wrong – and help test the new Anaconda installer in advance of the Fedora 18 beta – but if this fails, I’m seriously going to just tell Windows to use UTC (though *that* codepath there is not well tested either, and used to be buggy in Windows XP and Vista).

Update: after a complete reinstall (still using the F17 installer since the pre-beta live image is broken), having verified that on F17 prior to upgrading it works, the same issue still occurs. Bug filed; moving on to more productive endeavors for the rest of the weekend.

Important milestone in support for Clojure in Fedora reached

Screenshot of Leiningen 1.7.1, installed from RPM on Fedora 17

It works! A major part of our (Kushal Das and myself) proposed Clojure feature for Fedora 18, the Leiningen build tool used by Clojure project, is now up and running.

After packaging many dependencies, rigging up build scripts, and reporting bugs against other components we depend on (some are not fixed yet but hopefully all the fixes will get applied soon) — now we can turn our attention to packaging real apps. Yeah!

To follow our progress (and chip in — volunteers welcome!), see our progress documentation, with complete links to issues in Fedora’s bug tracker.

Firefox and Thunderbird 13.0, zero installation required*

Now that Mozilla has released version 13 of both Firefox and Thunderbird, it’s high time that I port their relevant 0install interfaces — they were last updated when I was with the OSR group, as the versions packaged in Fedora have been up to date for the past few months.

A simple invocation of

0desktop http://hircus.multics.org/interfaces/2011/firefox-launcher.xml


0desktop http://hircus.multics.org/interfaces/2011/thunderbird.xml

would give you desktop launchers for those two; they will check for updates periodically and you can manually override which version you want to run, out of the ones listed in the feed.

*you’d need to install zeroinstall-injector first, either through your distribution package or by hand.

e.g. on Fedora:

yum install zeroinstall-injector

and on Debian/Ubuntu:

apt-get install zeroinstall-injector 

More cnucnu release monitoring goodness

I just spent a few minutes clearing up Fedora’s Upstream Release Monitoring todo list — more packages will now get bugs filed against them on Bugzilla when a new version comes out, including gnucash, links (3 minor versions behind) and, surprisingly, Xaw3d, which has been resurrected on freedesktop.org after years of inactivity — we’re still packaging the old unmaintained version.

Note to self — figure out how to integrate the Python tool used by URM, cnunu, to keep track of non-Fedora software. My 0install feeds could use some release monitoring love…

The compat-wireless dance

At Fedora, our kernels tend to track upstream as much as possible, which sometimes makes for an amusing wireless experience. Here’s a tale, amusing in hindsight, of my three Sony computers, all using the ath9k module.

Firstly acquired is the 15″ Vaio EB I use as a desktop replacement. It works fine with stock drivers — at least, no known problem until today. We’ll get back to it later. Next, the 10.2″ Vaio W netbook. With this the wireless driver would need to be cycled — unload and reload — unless it’s kept active by, say, a continuous ping session.

Now, the EB did not use to work with the experimental compat-wireless drivers — basically the wireless code not yet merged into the Linux kernel; while the W absolutely requires these to avoid the ping keep-alive workaround.

Then comes the 13″ Vaio Y I got on a closing sale — at a nice discount price. Both the EB and the Y need to be on Fedora 15 because of graphics quirks (the former Radeon 5650, the latter Intel Arrandale), but that’s for another article. Everything seems to work fine, until I realized today, attempting to transfer a large-ish (> 100 MB) tarball from the Y to the EB, that the wireless on the Y keeps freezing up if I continuously transmit! It’s not a regression, or not a recent one, since older kernels do that too.

In goes compat-wireless to the rescue, and lo and behold, the transmission now works fine. Only then I find out that now the EB also acts up when it’s downloading at maximum speed. Sigh… funnily, now compat-wireless works fine on it, and fixes the problem.

I don’t even think I want to file bugs on this — different issues on different laptops — I’m just glad the latest wireless code works uniformly well now, and am just waiting for it to land in the mainline kernel.