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.

Advertisements

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

and

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.

HOWTO: Installing Oracle’s Java plugin on an SELinux-enabled system

As tested on Fedora 14 x86_64, with Sun JRE 6u23, Firefox 4 and Google Chrome.

That this works was a pleasant surprise to a friend and I — he thought the Java plugin does not work with Chrome, and I did not realize the 64-bit version is out (OpenJDK has had a plugin since it was called IcedTea, but the Java applets I need to use tend to make use of the Sun/Oracle binary blobs not yet reimplemented).

Getting it to work with Chrome is straightforward — like with Flash, you symlink $JRE_HOME/lib/amd64/libnpjp2.so to /opt/google/chrome/plugins. With Firefox 4, though, SELinux comes into play. Presumably because while Chrome’s executable is already marked as requiring an executable stack, Firefox 4’s (or rather, XULRunner 2’s) is not.

No big deal, you might think. The SELInux troubleshooter pops up, just follow its suggestions and all shall be well — pipe the relevant audit log lines to audit2allow, load the generated policy modules, close Firefox and try again. Except for… no cheese.

If this happens to you, save yourself trying to delete the symlink, reload Firefox, closing, recreating the symlink, and trying again. It appears that Firefox tries to cleverly remember which plugins fail to load, and it’s this cache that you need to purge. Delete ~/.mozilla/firefox/*.default/pluginreg.dat, and you’d be set on the next restart.

Good bye del.icio.us, hello Xmarks and Firefox 4!

How fast the wheel turns. Not too long ago, Xmarks‘ public bookmark-syncing service is shutting down, while Yahoo’s Delicious seems reasonably healthy (despite worrying indicators such as lack of support for the more recent Firefox 4 betas, and lackadaisical support for Chrome that, I think, no longer works either). And now the latter is closing — though it’s ironic that you see no official announcement when logging into Delicious, save the news articles and switching guides bookmarked by users!

Now Xmarks is owned by LastPass, and hopefully will be integrated soon with their own offerings — Xmarks’ password-sync is inferior, for instance, and if they offer a unified SSO with LastPass’ multi-factor authentication then that would be wonderful. I carry a Yubikey around these days, with the primary key set for Fedora’s Account System, and the second key set for Yubico’s public server for use with LastPass. If someone were to use a keylogger on a public computer that I use, then by all means; the password they tapped won’t be enough.

These all mean that I’m no longer trapped on Firefox 3, since the other extension without official Firefox 4 support, Greasemonkey, supports it in their nightly builds. Gmail is really annoying to use without Greasemonkey’s Gmail Fixed Font script! Makes one wish that Google integrates its Mail and Groups teams a bit better — Groups’ interface allows switching between fixed-width and propotional fonts for reading, while Gmail only offers it for composing. Sadly Groups’ new beta interface does not even have this feature implemented — ah well, there are three feature requests for it already, hopefully they’ll get it implemented before the new interface goes live.

EDIT – looks like Delicious will survive but will be spun off. Hope it gets taken over by a company that can give it the attention it needs — less laggy FFox support, and proper Chrome, iOS, Android support would be nice. Xmarks works well enough for me that I’ll probably stick with it though.