Sarah and Deborah are now home, and everyone is doing well; in fact, the hospital visit was only about half the normal length since things were going so well. Only have a few pictures so far, but the one that turned out best is the following one, where Rebecca (who is used to the role of little sister and is new to being a big sister as well) is holding Sarah, with a little help from grandma. Despite imperfect GIMP abilities and needing to google on red-eye removal tutorials, the picture turned out really well:
Quite a while ago, Behdad filed a bug about not counting reporting bugs that were later marked as duplicate, incomplete, invalid, notabug, or notgnome (actually, he didn’t include incomplete or invalid, I added those later). His description was a bit broken in that it sounded like he didn’t want closing bugs as such to count, but once we got things straightened out, it sounded like a good idea.
Now, even the most conscientious bug reporter is going to occasionally file a duplicate or invalid report. In fact, this change caused me to be one of the people who lost a point. But long term, it makes more sense to not reward mistakes (or worse, active bad behavior) so I think this will be a good change.
Hopefully this change won’t be accompanied with as many weird anomalies as the last one. (*fingers crossed*) If you do see any, though, let me know.
Wow, people notice their points, and weird bugs that make them lose 10 of them (just because it’s on a log scale and 10 points represents the vast majority of their work…). When you work on stuff like boogle and often times on metacity, you have to pry feedback out of other people. But they’ll find you in bugzilla, IRC, or email if you have a bug that killed their hard earned score (especially when it “doesn’t affect anyone else”). Sorry about that everyone. Should all be fixed now. If you still see any problems, feel free to reopen bug 360707 and add a comment there.
I briefly tried out Solaris, but ran into a number of issues that I didn’t know how to fix. I was a bit impatient and since the manual said I’d have to reinstall to get a multiboot system anyway, I just replaced it with Linux. I made sure to leave some extra freespace, and part of that will be used for putting OpenSolaris back on it at some point. You Sun people on planet Gnome should expect some questions when I get around to it.
The fc6test3 x86_64 cds I downloaded and tried to install from gave me a kernel panic relatively early on in the install process. Doh! Still need to retry that and record a few more details so I can report it. So, I decided to go with i386…
Turns out that getting Rawhide installed (already had FC5 cds to do a basic install and wanted to use yum to update) was a tad messier than expected on the initial stages, then super smooth after that. The initial stages should have been just editing /etc/yum.repos.d/fedora*.repo to change some “enabled=” lines and then running a “yum update”. But, hal conflicted with the installed fc5 kernel, so I had to update the kernel separately. When I tried out the new kernel, I got a frozen system at boot. So I retried at runlevel one and found that manually switching to runlevel 3 showed lots of
security_compute_av: unrecognized class 57
messages. So, I updated any package looking at all related to selinux, then tried out the new kernel again. At that point it worked, so I removed the old kernel. At that point “yum update” worked, and everything has worked without a hitch so far since then. I was actually somewhat shocked since yum upgrades aren’t exactly well documented and seem less supported, and the fact that fc6 is still a few weeks from release; but it has been very smooth.
So, some stuff is up and running and I still definitely have a lot more messing around to do. But it also has allowed me to get some of the metacity patches reviewed (though I’ve got a ton left; there’s been tons submitted recently, particularly by Carlo Wood), and do some bugzilla work as well. All in all, a nice new fun toy.
Damien, I have two pointers to bug-buddy/bugzilla enhancements that should eventually help when they become available, and one about a workaround you can use now:
Your bug-buddy suggestion (search for and present user with possible duplicates at bug submission time) is already filed as bug 345103. Sorry, haven’t had the time to implement it yet. Feel free to follow it. However, there are two other possibilities:
Olav filed bug bug 330323 about creating an interface for automatically rejecting bugs with known stack traces. That would allow maintainers to provide stack traces (and gnome-versions, to avoid rejecting regression reports) of frequently duplicated bugs and having bugzilla have bug-buddy notify the users that the given bug is already known/fixed. Unfortunately, it’s another one of those haven’t-had-time-yet-things.
You can opt to not receive email for bugs in the unconfirmed state, and instead rely on the bugsquad or other volunteers to triage bugs appropriately. Go to your email preferences to achieve this.
I’ve been updating/rewriting the documentation on the short search form used in GNOME Bugzilla (known internally as boogle). Of course, most people just need to know “type in a couple words to search on” (example) or “submit an invalid search and just read the builtin error messages to learn more” (example). However, the documentation exists for those that want to learn the gory details of expert searches; to make it more fun, I would like to sprinkle search terms on that page that lead to funny bugs in bugzilla. I already have a few, but want more.
So, know of a funny bug in GNOME Bugzilla? Let me know!
Being a bit bummed about academic stuff can be a great way of getting stuff done in GNOME, however. I caught up on a huge back-pile of email, nearly caught up on metacity patch review, and even fixed up some bugzilla bugs. One feature request that I’ve wanted for a long time was to enable searching reporters without using the complicated/advanced search page (which is also known as the “wait for your birth certificate to expire while it loads” page); now reporters can be searched with the expected boogle syntax: reporter<op><email1>,<email2>,…,<emailn> where <op> is ‘=’ or ‘!=’ (and ‘:’ is aliased to ‘=’). Simple example:
Also, I introduced two special “email addresses”. ‘me’ and ‘developer’, the latter of which adds an ability that the complicated/advanced form does not have. Thus, if I want to find all nautilus bugs filed by either one of its developers or me I can use the search
 No, my strategy wasn’t to merely wait until all emails were irrelevant (though it may have seemed that way to some people; my apologies to those individuals).
Maybe this will be therapeutic…
I’m still really bummed about finding out all the research I was doing on coming up with a more efficient implicit scheme for the Immersed Boundary method using some kind of projection method variant was all for naught. I believe I can argue pretty convincingly that it is very unlikely anyone could find a very efficient scheme using such methods, at least for the type of problem we are considering. So, instead of finding a really cool method and explaining that one method, I get to explain a ridiculously over-generalized set of possibilities and state why people shouldn’t waste months/years of their time looking for an efficient method within that mess (and point out the specific things that would need to be fixed in order to obtain an efficient scheme using such methods). Oh, and I get to try out a few more methods that don’t fit into that general classification and compare them as well. *sigh*
It also negatively affects our (my?) previous paper a bit too (I did about 95% of the work, so problems with it bother me more than the others involved). I thought that paper was a pretty big result, as it pointed out that some “common knowledge” held in the community was in fact just myths. It answered some questions that have been outstanding for a decade or more in the community, and was supposed to greatly assist in finding an efficient implicit scheme. But, unfortunately, all those results are merely academic unless an efficient implicit implementation can be found. Yeah, I know, I’m a mathematician so it’s supposed to be okay (and even desirable according to some mathematicians I’ve talked to) for practicality to be orthogonal to my work. But I just don’t work that way. If it has no practical use, who cares?
In an effort to cheer me up, Bob has told me a couple of times that “negative results are undervalued too much; they’re still results.” And, well, writing up this stuff should still allow me to finish this calendar year. So the glass isn’t completely empty. Maybe just halfway.
 I need a name for this that more accurately specifies what I mean. But I don’t have anything better right now.
 Yes, that might sound a bit odd to those who have read closely and know more about my area of study. The practicality of my research to society, even if I had been much more successful, would still be relatively low. It’s one of the things that has bothered me the most about my doctoral studies, and is one of the things I’m determined to change when I finish up this year, one way or another.
Vytautas Liuolia (or Vytas, for short) is one of the Google Summer of Code students, being jointly mentored by Matthias Clasen and me. He’s working on a library to make single instance applications easy to write. Basically, all existing “solutions” to this problem in the Gnome world (and there are many) are wrought with bugs. We need to make it easy to do the right thing in order to get apps to actually work right, and Vytas is working on that for us.
While I would like to claim that this is merely an application problem, and that our base system is a shining example of getting everything right (in particular because I have put a lot of my own time into trying to make it so), such is simply not the case. Vytas has had the “pleasure” of learning all kinds of nasty X details, scouring various freedesktop.org specifications, and becoming familiar with some of the guts of both gtk+ and metacity. Some of his fun has included dealing with race conditions and making things robust and backwards compatible even when faced with apps/libraries/window-managers/toolkits (yes, we make him worry about all that stuff) which use obsolete versions of the specifications.
He has been patching metacity and gtk+ to provide extra functionality needed by the library so that it can do its work without exposing too many ugly implementational details to the programmer or requiring any hacks of them. But even better than that, today he uncovered a focus handling bug with new windows that has been in metacity for years now. I had gotten complaints over the years so I knew there was an issue, and in trying to track it down I had read over the code many times trying to figure out what could possibly go wrong (I had never been able to duplicate the problem myself). I even created various patches to increase the debugging spew for others to use, but to no avail. However, the bug is finally dead now. So very, very dead. Just the way we like ‘em.
Rock on, Vytas.
 The library may become part of gtk+ or some other gnome library, but we don’t know where it’ll end up yet.
 For example, there’s bacon, which was actually meant to be a general library for this. There are lots of other building blocks used as a base for building such an app, such as sockets, X messages, bonobo, and D-Bus. And there are various tutorials out there on how to use those building blocks to construct such a program. It is not uncommon for various apps to switch which building blocks they use occasionally in their particular hand-rolled version of this functionality.
 I’m not exaggerating. They all suck. They all handle the basics okay, but do not handle startup notification correctly and thus feel buggy and non-integrated — unless someone has manually patched the relevant program. Manually patching the relevant program is an annoyingly difficult exercise, as it requires pretty detailed knowledge of how startup-notification and focus handling with timestamps work, learning an entirely new single instance mechanism in many cases (really, nearly each and every app does it differently) and producing some ugly, hacky, difficult to understand patches. Sometimes, quite understandably, even hackier workarounds or incomplete patches are used instead.
Update: Only three mistakes found so far in the original — typos in both Matthias’ and Vytautas’ names, and an incorrect statement about gedit. Can anyone spot any more?