SCALE, git, docs, Xfce

February 18, 2010
Josh Saddler

SCALE

SCALE 8x is just around the corner! I and something like 8 or 9 other devs will be there — it’ll be our biggest showing since SCALE 5x a few years ago. Several folks coming from the Bay Area or flying in from across the state. I’ll drive up Friday sometime to help setup the booth, and maybe try to get my Beagleboard working a bit better in time for the show on Saturday.

Git

Since my last post, I’ve opened up a couple of public repos at GitHub: one for my fork of LogJam, and one for my overlay, overnight. (Clever, yeah?)

The LogJam fork is to create a sane base for Gentoo and other distributions to get an up-to-date version of LogJam without having to maintain a huge patchbase. I was delving into the Fedora patchset; they had a few dozen they maintain for their RPMs. Once I’d finished updating my fork, submitting an upstream pull request was as easy as clicking a button and adding a short note. Awesome!

GitHub does nifty graphs about which sources have ties to other projects, as well as commit history charts. The downside is that since there’s lots of javascript and Flash powering the site, responsiveness can suck.

So, why choose GitHub? For all the reasons so far, plus the fact that there are a lot of Gentoo projects on there already, including other overlays. And LogJam upstream’s already on there, which really makes it easy to interact via the web interface.

Now, I should mention that I’m not married to GitHub or anything. In fact, I’ve registered an account at Gitorious, too, just in case I switch. Or if I want to have separate/mirrored projects at both websites.

I’m even thinking of git hosting some of my other personal projects, like night-sources. You know, stuff that needs organization. However . . . the problem I have with GitHub is that binary file hosting SUCKS. Lemme say that again: it’s terrible. Really bad. There’s no such thing as a static, canonical file name for a given archive, like you’d expect from SourceForge or Gna! or similar. Instead a small commit hash is appended to every file name, which is just ugly.

Let’s say that I have a kernel patchset (labeled only by a version number) that I distribute in an ebuild’s SRC_URI. I can’t just call it ${PV}.tar.bz2; it has to be something like ${PV}-36x746avF.tar.bz2. The maintenance for each subsequent ebuild version goes up, because you have to change SRC_URI every single time, which takes away the flexibility of using variables in the first place!

Now, I understand that with GitHub, supposedly the hashname increases security, as you’ll always know which commit it’s from. Same for which branch, etc. However, it’s also unnecessary, because the version number is right there in the file name. It’d be nice if you could always get individual tarballs the way you’re used to:

2.6.22.tar.bz2
2.6.23.tar.bz2
2.6.24.tar.bz2

. . . instead, you’ll get a bunch of random crap, appended to a really/long/tree/master/ URI.

So GitHub, if not git itself, is not ideally suited for binary packages, be it tarballs, image files, PDFs, etc. Lots of stuff cluttering up the path, and I have no clue if it can actually be removed. None of the support conversations I read on GitHub had a fix, either.

So I’m still looking for a good alternative. I may just have to keep everything in my devspace. As much as I’d like better organization of, say, night-sources (like the genpatches team has), I don’t want to deal with those kinds of weird versioning issues.

Docs

In spite of CIA being down for some time and losing lots of commits, I’ve done a fair amount of docs work in recent days.

Yesterday I spent awhile bringing the Printing Howto up-to-date for HPLIP, as well as fixing all the kernel config and usergroup info. There are also a buncha updates I made to the Openbox Guide; all patches were supplied by Nate. (Thanks!)

The Localization Guide also some some luv; I pruned the old section on using localedef with the real way to generate locales, localegen. This stuff was already in our other documents, including the handbooks, but somehow I just missed this one.

The Portage handbook received some updates for automatic block resolution, as well as using examples for packages that are still in the tree. Not all the commits I make are huge rewrites; some of them are small but really helpful. The Gnome Guide, for example, lacked explicit instructions to follow the Xorg setup doc before installing Gnome.

Now, it is possible to install Gentoo and then immediately go right to installing Gnome. However, you may end up with a few misconfigured or missing bits along the way. New users would probably not know what to do next, so by adding this short note about required configuration, hopefully some of those pitfalls can be avoided.

Xfce

Almost forgot this month’s Xfce desktop! I found a really neat wallpaper, and started looking for some gtk+ themes with similar colors, to save me the trouble of creating one myself.

I decided to redo my desktop in a general Elegant Brit theme. I also decided to try out the Cairo Dock ebuilds. (These were originally from the desktop-effects overlay, but I brought ’em up-to-date and submitted a pull request to the maintainers. Git makes collaboration easy!)

I later unmerged Cairo-Dock, as I found it to be very unstable and buggy. Even now, DBUS and DBUS-apps still aren’t working correctly, as not all of them can use the notification area anymore. Lame!