Bloggy

So before I went underway our car had developed a trouble causing the Check Engine light to come in continuously. No abnormal sounds but being nuclear-trained has taught me not to live with “locked-in” alarms or warnings. I wasn’t able to troubleshoot it in the limited time I had before deploying so I asked my wife to make sure it got investigated when she had free time.

She took the car to the dealership. She actually had to make two trips; apparently there were two separate faults that would have caused the light to come in by this time. Nothing mechanical luckily, but apparently at some point while the dealership was troubleshooting the issue they had to unhook the battery. Doing this activated the anti-theft feature of my radio; it would not play music unless I typed in the anti-theft code. This code was included on a card which I was supposed to remove from the car and keep in a safe place. Needless to say, I had removed it from the car, and it is still in some safe place, nowhere to be found.

So my car radio has been silent for about a month and a half now. I finally got the time to really dig into this issue since the dealership apparently is completely unable to figure out what the unlock code should be. A little browsing on the Internet and apparently many people have had the same issue, and the unlock codes are few enough to list in one paragraph.

So I went and wrote them down and typed them in one by one. After about a dozen tries the radio started working again. Yay! I will record the code in my KWallet this time; it is the only thing which I reliably can count on being there. In case anyone else develops this issue with a Chevy Aveo, I found these posts helpful: automotive forums and Yahoo! Answers.

Posted by mpyne under Personal & Useful Tricks | 2 Comments »

kio_perldoc: I’ll keep it short:

• Ported to KDE 4.
• The GENERATOR metainfo in the output has kio_perldoc now, so that proper blame may be placed.
• The S<> tag in Pod now produces HTML which isn’t super broken. (Look for Mac OS in perlport)
• Don’t try to load IMG tags. I wasn’t going to add this in except that it causes Konq 4 to crash for some reason.
• Fix formatting of bulleted lists. Patch graciously provided by Bruce Ravel.
• All C library functions are called like ::foo() now to avoid ambiguity. (e.g. with close())
• Corrected a call to execlp(). If you ran kdeinit in a terminal you could actually see the man page come up…
• Fix linkage for hyperlinks that refer to the same page.
• The HTML output looks more like www.kde.org now.

Still needs CMake, Perl 5.8, etc. The KDE 3 version is 0.8.1, and KDE 4 version is 0.9, but it’s the same feature set.

Posted by mpyne under KDE & Programming & Useful Tricks | 1 Comment »

All that work I was doing to add parallel updating and building to kdesvn-build gave me a great appreciation for one thing that Perl does right: copious documentation, even if you need to use a special program to view it (perldoc, which man-page-ifies it).

What I really wanted was a KIOSlave interface to perldoc that way I could view the documentation nicely hyperlinked in Konqueror. The KDevelop guys already had a kio_perldoc, but it wasn’t really too great. It simply dumped the output of perldoc more or less straight to konqueror, which misrendered it since it wasn’t HTML. It could also output plain text but that was HTML-ified using blockquote instead of pre which caused it to still look weird.

It was that way mainly because there’s no good way to export HTML from a perldoc file. Perl includes a pod2html but let’s just say it hasn’t kept up with the times too well. Plus it’s very hard to convert the hyperlinks produced by pod2html into something that perldoc would be able to redirect to itself, which defeated the purpose of having hyperlinks in the first place.

I eventually decided to do a little Perl magic to handle the conversion from .pod (which perldoc would output) to html that wasn’t crap. It took a bit of searching on CPAN to weed out the POD->HTML converters which either had way too many dependencies or didn’t produce suitable output. I eventually settled on Pod::HtmlEasy, a useful and customizable Pod->HTML converter that didn’t have too many dependencies and was suitable for standalone use.

Some merging of files and removal of unnecessary dependencies later, and I had a script which would run perldoc for me and automatically convert its output to HTML. All my KIOSlave had to do was call the script and dump its output straight to the receiving end.

The actual handling of that is probably more complicated than necessary. I think I will use popen() in the future just like every other similar KIOSlave instead of handling the children myself. But, it works pretty well:

It handles URIs of the form perldoc:/Net::HTTP to get module information, perldoc:/functions/select to look up documentation on Perl functions (like perldoc -f) and perldoc:/faq/search_terms to looks for your search terms in the perlfaqs (like perldoc -q). These URIs were all pioneered by the KDevelop KIOSlave.

The next step would probably be to port this to KDE 4 and coordinate with the KDevelop developers to either integrate this back into KDevelop or (my preference) get this into kdesdk since this is useful for many more developers than just KDevelop users. Also the generated HTML looks very similar to perl.org’s perldoc resources, I need to get it looking more like the kde.org website family (CSS help appreciated :)

You can grab it from my dumping ground. Although it is for KDE 3, you still need CMake to build it, as there’s no way I’m wasting bandwidth on autotools. :)

Posted by mpyne under KDE & Programming & Useful Tricks | 5 Comments »

I’ve started on work to implement a feature requested in bug 109619. Namely, to allow kdesvn-build to start the build process as soon as the first module has been updated from subversion and then to run the two updates in parallel as much as possible.

It’s harder to do than it sounds at first but I think I have something working. If you try it out (latest kdesvn-build from trunk/KDE/kdesdk/scripts) and it’s broken for you please let me know.

Also some KMail/Kontact tips for you: I don’t know why but I was under the impression that the “Mark Thread As->” feature required you to click on the root email of the thread in question. That’s not the case, any message in the thread will cause the whole thread to have the desired attribute applied. Also, if you ever get messages in your inbox that simply refuse to go away then you may have a bad message folder cache. At least for Maildir type accounts. In that case, shut down Kontact and KMail (including from the system tray), go to your Maildir folder (mine was ~/Mail) and look for hidden files of the type .folderName.index* (I had .inbox.index, .inbox.index.ids, and .inbox.index.sorted in mine).

RENAME these files to something else (I moved them to a backup directory), and then restart Kontact. It may take a couple of seconds to rescan your folder (although it was near instantaneous on my system) and then you should have your folder corrected with all the undeletable messages gone.

Posted by mpyne under KDE & Useful Tricks & kdesvn-build | 3 Comments »

So after having a Gentoo upgrade break a lot of programs, even after running the revdep-rebuild which rebuilds packages affected by a changed library, I decided that I had to have a way to find out what libraries in particular were causing programs to need to load the affected library. In my case an expat upgrade replaced libexpat.so.0 with libexpat.so.1. Even though revdep-rebuild was supposed to rebuild the affected packages it missed quite a few.

(I would eventually figure out that the reason it messed up is because the lib64 directory is symlinked to lib since I have a 64-bit system. The program would end up linked against a library in /usr/lib64, revdep-rebuild would look for programs linked against the exact same library, but in /usr/lib instead, and then not find it.)

Anyways, after playing around with ldd and discovering that it would not give a nice tree diagram showing what the dependencies of a program was I decided to make a tool that would do so. I call it ELF Library Viewer (elflibviewer on the command line):

If it interests you at all it is available from my dumping ground. It requires Qt 4 and the readelf utility to be installed. It doesn’t really do much error handling (i.e. run it on ELF executables and libraries and you’ll be fine) but it shouldn’t ruin your binaries either.

It is rather Linux-specific at this point as well, but it should mirror the GNU binutils way of finding libraries closely. Instead of searching the ld.so cache it checks ld.so.conf to figure out what ld.so should be caching however. Let me know if this program proves useful for you (or if I’m just reinventing the wheel). Bonus tip: Type the name of the offending library into the search line and hit enter. It will highlight in red all of the libraries which depend on the offending library. It also recursively resolves dependencies, but only the first time it sees a library. It probably wouldn’t be too hard to copy over the dependency tree each time it reencounters a library but I can’t be bothered to implement it.

Posted by mpyne under Computing Troubles & KDE & Screenshots & Useful Tricks | 16 Comments »

In the past couple of hours I’ve managed to fix 3 different screwups I made with qmail. Because having to deal with qmail (or rather, MTAs in general) always gets me upset, I figured I’d document what I’ve done for posterity. Sorry to the Planet KDE readers, this is longer than I thought it would be.

For starters, when you setup qmail, don’t forget to add all the aliases for your machine to the /var/qmail/control/locals file. No, qmail doesn’t know that localhost is actually a local machine, nor does it automatically know about your computer name. So in my case, I’d forgot to add midna (the computer name) and localhost to the locals file before email was being sent, and although qmail retained it, it was trapped in the queue, unable to be delivered.

qmail splits up its queue into two sections, remote (which it tries to deliver over SMTP) and local (which it normally can just deliver to on disk). In my case qmail is pretty much receive-only, so SMTP-outbound delivery wasn’t working (and wasn’t likely to¹). And anyways, all the crap stuck in the remote queue really belongs in the local queue, and it would have been there if I hadn’t screwed up the locals file.

Now the QMail queue is a very touchy part of the filesystem. Try moving files around and you’ll likely hose all the email retained in there, not to mention any email delivered to qmail in the future. So it’s not like you can just move messages from the remote to the local queue. Instead, what you should to when you’ve got messages in the remote queue that need delivered locally, is to play with the /var/qmail/control/smtproutes file. This file controls the SMTP servers which are used to relay messages.

Something like this will tell QMail that messages intended for your local domain should be SMTP’ed out to localhost. QMail will receive them and, since your locals file is now correct will put them in the local queue where they’ll be delivered.

localhost.localdomain:[127.0.0.1]

That takes care of the first problem. But, don’t forget to remove the entry again after the mail has been placed in the local queue! Another problem I was having was that emails to an old user of mine weren’t being delivered to the correct email account. qmail has nifty support for address of the type user-foo@domain, where the -foo part can be whatever user wants, which is nice for getting unique email address to give to merchants or other websites you suspect may give away your address. It’s even useful simply for filtering (which is what I was using this particular address for).

Now qmail also has a nifty aliasing feature that allows messages sent to a virtual user to be redirected to a mailbox. All you do is create a .qmail-user file in /var/qmail/alias, the contents of which is the name of the mailbox to send to (i.e. mpyne).

But, this has two problems. First, email sent to user-foo won’t be redirected. If you want that to happen you need to name the alias file .qmail-user-foo. This would get unwieldy (imagine all the possible suffixes you could have added). But, if you have a .qmail-user-default alias, then any email which doesn’t match a different alias for the user will be redirected to that alias. So that solved my second problem.

The final problem is that the alias feature doesn’t work if you’re trying to alias email for a user that has an account on the system. In my case, I was having email sent to portage@midna forwarded to my account. But, portage is an actual user account on Gentoo systems. So even though the alias existed, qmail was searching for portage in /etc/passwd first, and found the entry. qmail in this situation then checks to see if the user owns their home directory, that the permissions are set right, etc. That wasn’t true in this case, so email sent to portage was in limbo.

The solution here is to take advantage of a QMail users database. By default in /var/qmail/users. You need to read the man page for qmail-users, but basically you setup the file /var/qmail/users/assign to redirect email for the user to someone else, run the qmail-newu program, and then the user database which is created is checked first, before checking for the home directory. And if the user isn’t present in the database then the rest of the sequence goes on unchanged so this won’t break your aliases and existing mailboxes².

My disclaimer is that this is all probably completely different if you’re using software like vpopmail or other user administration software bolted on top of qmail. My particular scenario was a qmail-only install. You may want to have the qmHandle program or similar available to help manage messages in your queue. And, be vary wary with any queue changes while qmail is still running. pkill -HUP qmail-send is your friend when changing files in /var/qmail/control. Sometimes restarting qmail is in order as well.

[1]: Strictly speaking it’s probably poor form to be able to receive SMTP messages without the capability to send a bounce back to the originator. So I’ll rig it to have outbound send capability before too long.
[2]: At least, I don’t think it will.

Posted by mpyne under Computing Troubles & Useful Tricks | 3 Comments »

I updated my tacky blogging tool today. The only real feature change is the ability to open your old blog posts to edit them. I just realized that the mtime of your blog entry will change, so the feature isn’t ultra-useful since that’ll make your entry pop back up as the newest entry.

I used zrusin’s delayed initialization technique to achieve a pretty respectable startup speedup. Almost a year after he mentioned that it would be a good idea to add that article to the KDE common mistakes page, I finally went and did so.

I also converted tacky to use bksys to build instead of my custom Makefile. Hopefully we’ll see greater uptake in the use of non-autotools-based KDE projects. It would be nice if the KDE build infrastructure were a part of KDE instead of having to be distributed with every program, but until then I’m using mini-build-systems =D.

Posted by mpyne under KDE & Useful Tricks | No Comments »

I spent 5 hours today fighting with KDialogBase over a new delete dialog for JuK. At first I thought I was having problems because of the use of Qt Designer, but it turned out that hand-coding the widgets into the code resulted in the exact same problem.

Turns out that for whatever reason, you have to add your own layouts in some modes of KDialogBase (namely, the one that actually worked, Plain).

I’m doing this work in the hopes of being able to re-enable the file-deletion feature of JuK. (I’m the kind of guy who is always holding Shift when clicking on Delete in Windows to keep the file out of the Recycle Bin). Scott and I have been discussing how we might do this, but I forgot to write it down, so I’ve pretty much forgotten everything. :-(

I think the conclusion (if we reached one) was that there would be a checkbox in the dialog to delete the files instead of trashing them. There is no checkbox in CVS yet, but that won’t be hard to add. I wanted to commit my current changes before going to bed since they at least have the benefit of changing the default action from Delete to Cancel, which is suprisingly hard to achieve with KMessageBox.

Posted by mpyne under KDE & Useful Tricks | No Comments »

So, I’ve been exercising a lot recently. I have to get ready to go to Officer Candidate School in January, and I wouldn’t like to have my heart explode after 2 days or so. I was able to get my 1.5 mile run time down to 14:30 today (quit laughing, I’ve never exercised in my life until this month). I would like to get it around 12:30 (or better). I already feel that I can breathe deeper, but now I need to psych myself up into running for longer, faster.

Read an interesting technique today on concealing e-mail addresses. Normally I just go all out with the gymnastics, replacing . with (DOT) and @ with (AT), but that’s cumbersome, and doesn’t work well for making the link clickable. The technique I read today involves replacing each character with the corresponding HTML entity equivalent. For example, an uppercase A in the address would turn into &65;. I just hacked together a Perl script to convert e-mail addresses into equivalent HTML entities. Let’s see how much more spam the webmaster@microsoft.com gets. :-)

Posted by mpyne under Navy & Useful Tricks | No Comments »