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…

If you have a laptop with Intel graphics and broken backlight control…

e.g. a Sony Vaio Y-series, where upon seeing the debugging data kernel developer Matthew Garrett (mjg) pronounced it “what an awful implementation — utterly broken”, there is hope yet.

Matthew has been working on native backlight control for a while, and for Intel hardware, there’s currently only one patch left to merge onto Linus’ kernel tree; it applies cleanly onto the most recent kernel release candidate (3.0-rc7).

Unfortunately, by default the ACPI subsystem will still be used if available, which is the sensible default. You do want to use the predefined backlight values whenever possible, not the raw values the graphics card let you set.

Ubuntu users have been resorting to Kamal Mostafa’s linux-kamal-mjgbacklight repository, which enables native backlight control, disable the ACPI video driver, and provide a patched GNOME Power Manager that can interface with the native backlight control.

The workaround I came up with is more lightweight — it just uses inotify-tools to monitor the brightness file, and apply an appropriate equivalent value to the native backlight control. Feel free to use this if you’re affected by a similar problem.

Try Thunderbird 5.0 now — without hassle

There are cases when getting a specific software from one’s Linux distribution is not the optimal solution — and I’m saying this as a package maintainer myself. The main ones are:

  • the distribution package might be out of date
  • legal reasons prohibiting the software from being packaged (e.g. Skype, Flash, Adobe Reader)

Note that the first point is not exactly a criticism — after all, distributors tend to be wary of introducing breaking changes in a stable release. For software in the second category, upstream often provides binary packages, but again, using a tarball requires users to deal with dependency resolution themselves, and even when Debian or RPM packages are provided, the packaging is often sub-par (upstream developers can’t be expected to be well-versed in the subtleties of each distribution’s packaging).

Enter 0install. Now installing, e.g. Thunderbird 5.0, is a simple process:


yum install zeroinstall-injector
0alias thunderbird5 http://mojo.informatik.uni-erlangen.de/interfaces/2011/thunderbird.xml

or use “Add New Program” from the application menu and provide it with the URL for the Thunderbird feed. This currently lets you easily select between Thunderbird 5.0 beta 2 and 5.0 final (for both 32-bit and 64-bit builds) as well as the distribution’s packaging (on RPM-based and Debian-based distributions as well as Gentoo), and will pull in needed dependencies (please report any problem here).

You can browse http://mojo.informatik.uni-erlangen.de/interfaces/2010/ and http://mojo.informatik.uni-erlangen.de/interfaces/2011/ to see other available feeds that I maintain (and 0install’s site for even more). Of note: Eclipse JEE, Maven 2.2.1/3.0.3, Skype and Tomcat.

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.