Present Perfect

... went a little something like this.

• home desktop upgraded to F14, still a bunch of packages missing.
• Want to do a release of moap because it's been too long, but can't because make check fails because pychecker fails because F14 is the first one with Python 2.7
• Look into pychecker failures. Figure out that there are new opcodes. Worse - for the first time I can tell opcode numbers have been shifted around. Find this bug where renumbering started; commented to ask if this was expected. Apparently it is, although no good reason for doing so has been offered. Shrug, not my fight, although it's going to make for ugly if's in Pychecker code.
• Realize I don't actually have Python 2.7 on the Pychecker buildbot page. Remember I have a script to build Python versions from source which now builds 2.3-2.7 and 3.0 (just check out and run make, then py-x.y to start a shell with that version of python).
• Add it to buildbot master config, restart, see buildbot fail spectacularly. Apparently buildbot was upgraded since I last started it, and code has been shuffled around. Spend a few hours figuring out how to upgrade buildbot and my code with custom steps without losing the history. Now have a buildbot 0.7.12 building on 2.7 as well.
• Add some ugly if's for python versions to handle opcode reshuffling. Brings down the test failures. Add some handlers for new things like POP_JUMP_IF_TRUE/FALSE and JUMP_IF_TRUE/FALSE_OR_POP. End up with only one test failure difference with 2.6
• Look into the remaining failure, realize that it is checking for constness of return results, and JUMP_IF_TRUE/POP_TOP pairs are now POP_JUMP_IF_TRUE, so peeking ahead to see LOAD_CONST should move by one opcode.

So, yay! That means CVS (yes...) HEAD of pychecker now works just as good for 2.7 as 2.6 and it's time to start releasing somewhere this week. And maybe I should push on and fix some of the older failures, or shelve them for now, while I'm at it, and have nicely green builds!

... went a little something like this. home desktop upgraded to F14, still a bunch of packages missing. Want to do a release of moap because it's been too long,...

I plugged in a second monitor, smaller and to the right of my big primary monitor, and the desktop just nicely expanded. So far so good.

The panels however travelled to the new smaller monitor, which is not my primary monitor.

I can see how that might make sense to want in some cases, maybe. But I think the typical use case when you plug in a new monitor is that you just want more display area, not that all your stuff automatically moves. Principle of least surprise no ? It's also much more likely you plugged in a smaller screen than a bigger screen than the first monitor you had.

Just spent an hour trying to figure out how the hell to move those panels back, painful. No amount of Ctrl/Shift/Alt/left/middle click drag would make it work (never mind that I had to remove a bunch of stuff just to have clickable panel area - still don't get why for example the applications panel applet doesn't give up the space around the logo to be panel area, looks like such an obvious area to release to me...). It was not locked_down in GConf, there was nothing in the right click menu to move it (except for top/bottom/left/right, all confined to monitor 2).

Hunting around I saw Lennart had the reverse problem in Fedora, and I tried all of the remedies in there. The only one that worked however is to dive into gconf-editor, go apps>panel>toplevels, and change monitor from 0 to 1 in bottom_panel and top_panel. Not sure why my primary is 1 and secondary is 0, but there you go...

I might be bothered to do something about this if I could figure out how the magic works when you plug in a second screen, but Xinerama is such a minefield of different preferences between different users, and I promised myself to not go too deep yak shaving so I get somewhere...

I plugged in a second monitor, smaller and to the right of my big primary monitor, and the desktop just nicely expanded. So far so good. The panels however travelled...

Turns out that the behaviour changes and problems in redland-bindings I was experiencing were not necessarily bugs, although opinions may differ.

I filed some bugs, and fixed moap to adjust for the behavioural changes, sprinkling comments.

I packaged up redland-bindings and it's available from my package repository.
I'm going to retry to get it into Fedora properly, so here is the package review request.

Turns out that the behaviour changes and problems in redland-bindings I was experiencing were not necessarily bugs, although opinions may differ. I filed some bugs, and fixed moap to adjust...

I still can't get over how obtuse and error-prone git's command line UI is.

Today I was trying really hard to checkout a tag of some project to try and fix a bug.

Are there tags ? Why, yes.


$ git tag -l
redland-bindings_0_9_17_1
redland-bindings_0_9_18_1
redland-bindings_0_9_19_1
redland-bindings_1_0_0_1
redland-bindings_1_0_0_2
redland-bindings_1_0_10_1
redland-bindings_1_0_1_1
redland-bindings_1_0_2_1
redland-bindings_1_0_3_1
redland-bindings_1_0_4_1
redland-bindings_1_0_5_1
redland-bindings_1_0_6_1
redland-bindings_1_0_7_1
redland-bindings_1_0_8_1
redland-bindings_license_lgpl_apache2
redland-bindings_license_lgpl_mpl
redland_bindings
start


Here are my attempts and its responses:


$ git checkout redland_bindings_1_0_7_1
error: pathspec 'redland_bindings_1_0_7_1' did not match any file(s) known to git.
$ git checkout -b redland_bindings_1_0_7_1 redland_bindings_1_0_7_1
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'redland_bindings_1_0_7_1' which can not be resolved as commit?


Can you spot my error ? It took me a good thirty minutes to figure out what exactly I was doing wrong. Git could have just told me. Suggestions to improve these obtuse error messages?

The first error suggests that git thinks I'm trying to check out a file. Strangely enough git checkout -h says:


usage: git checkout [options]
or: git checkout [options] [] -- ...


so why does it even think I'm trying to check out a file ? The usage suggests the only way to check out a file is to list them after -- which I didn't specify. Isn't the more logical thing to assume I was trying to check out a branch ? And while on the subject, you have to somehow understand or assume that, even though a tag is not a branch, you can actually check out a tag this way.

Instead the error should probably say something like:


git doesn't know about a branch or tag named '...'
Check with git tag -l or git branch -a to see all tags and branches.
If you wanted to specify a file instead, use -- to separate branch or tag from file names.


Now the second one. I am sorry git that I crossed the flux capacitators to reverse the coagulation of the ninth-dimensional positrons. But could you please try and insult me in English ? All I can get from this message, *after* understanding what my problem was, is that you think I want to switch branches (is that the same as checking out a tag ? Maybe, how can I tell ?) at the same time as updating a path. I'm pretty sure I'm only trying to do one of those two things, although I'm not too sure. And I think the proper English for that second sentence would be something like

"Did you intend to checkout the tag or branch '...', which does not exist in the repository ?
Use git tag -l or git branch -a to see a list of tags and branches.


I can't *wait* for the comments to pour in telling me I'm stupid because I can't automatically read 'cannot be resolved as a commit' is gitese for 'the tag does not exist'.

I'm only writing this post because git in this particular instance caused me to waste less time than average with obtuse UI, so I had some time to spare to complain.

I still can't get over how obtuse and error-prone git's command line UI is. Today I was trying really hard to checkout a tag of some project to try and...

I finally got off my ass and upgraded my home machine to Fedora 14 (from 11).

Only ran into two bugs so far, one seems to be something annoying in redland causing moap not to break... check later.

In the meantime, I updated mach for Fedora 12/13/14, because yes I still end up using it whenever I build packages. So here is a new service release.

mach allows you to set up clean roots from scratch for any distribution or distribution variation supported.

Get it from the mach project page.

I built packages for F12/13/14 available from my repository, and will start rebuilding some other packages (I did redland-bindings, but be warned, the F14 one version doesn't seem to work for me!)

I finally got off my ass and upgraded my home machine to Fedora 14 (from 11). Only ran into two bugs so far, one seems to be something annoying in...