Unfortunately I haven’t made any blog updates in awhile. I’ve been very busy between work and school (and I will likely spend this weekend working on a 20 page project that I’ve written 0 pages for ;). That doesn’t mean I have nothing to report though…
First off, I have renamed kdesvn-build to kdesrc-build to reflect the fact that it builds from Git-based software repositories. In conjunction I released kdesrc-build 1.12 which has various minor improvements, including a few Git improvements.
I’ve complained about my car breaking down. It’s fixed, although I will be selling it now (my wife and I were debating the merits of getting an improved car for awhile before, this incident sealed the decision).
Just today I’ve committed a new feature to JuK, the sadly neglected KDE Software Compilation music manager. Now you can use the scroll wheel in the track announcement popup to quickly switch tracks without having to use the Next/Prev buttons. It’s probably already in every other media player with a playlist, but it’s at least in JuK now. Note that this is a 4.6 new feature, not 4.5.
I’ve also been “reviewing” a patch to further remove Qt3 support code from JuK, which I will try to clean up and get comitted this release cycle. The big thing I still need to do is to finally convert from K3ListView to a real Model/View architecture to finally be rid of Qt3Support. Help is always appreciated btw =D
Burkhard LÃ¼ck, the documentation super-hero, has been improving JuK documentation for me, but I still need to make some changes that he’s requested to bring the docs closer to 2008-era (let alone 2010) :(
That’s another good “intro to KDE Platform” kind of job by the way, it’s how I got introducing into coding for JuK myself. ;)
So if you have been looking at Planet KDE or the kde-scm-interest mailing list recently you will have noticed that some of our intrepid sysadmins have started setup the systems that will be needed to migrate the KDE source code to . Konversation and Amarok have already switched.
kdesvn-build has already supported git (and the upcoming 1.12 release has some git improvements), so building and installing konversation and amarok is as simple as fixing your kdesvn-buildrc to refer to the correct git repository. For Amarok and Konversation this means changing gitorious.org to git.kde.org for most users using the read-only clone URL (like git://gitorious.org/amarok/amarok.git). Read-write access occurs with a separate URL, lookup the TechBase entry for more info.
If you have already built a gitorious version of Amarok or Konversation then you have two options to correct the downloaded source:
- Remove the source directory, and kdesvn-build will clone it again from the updated repository, or
- Use the a manual git remote URL updating command as described on the Konversation homepage.
It has been awhile since a release of kdesvn-build, and the kdesvn-build website was recently effectively offline due to an IP address change, so I’ll probably move to more stable KDE-hosted servers if possible. With all that in mind, it’s probably time to change the name again! (Who remembers kdecvs-build? ;)
My initial plan for the name is kdesrc-build. I figure there’s no way this one won’t be future-proof (and besides, svn will still be supported for some time probably). ;) If anyone has better ideas for a name that is descriptive, relatively future-proof, and catchy, please leave me a suggestion in the comments.
While I’m polling the audience, I’ve been thinking about the design of kdesvn-build. Right now it is a 217 KiB single-file Perl script, with no external dependencies required aside from Perl 5.8. This is mainly to make it as easy to install and upgrade as possible. Does this ease of upgrading actually make a big difference for you all? It hasn’t been very difficult keeping the script in one file (I even managed to get Perl’s weird object orientation to work in one file) so I can keep that going if it’s worth it.
So if you’ve used kdesvn-build to build some of the modules that are hosted on Gitorious then you are probably familiar with an error that always comes up when doing the initial checkout. This error is so famous that every “how to build using kdesvn-build” guide I’ve seen over the past couple of months have mentioned that the clone step for qt-copy would need to be done manually.
A Konversation developer, argonel, noticed the issue the other day and got in touch with me, so I had him strace the output of the (successful) manual run and the (unsuccessful) kdesvn-build run. It wasn’t initially super helpful although it clarified what was going on (the gitorious.org end of the connect was closed on their end for some reason).
That was the conclusion of that, but then I get an email the next day from argonel saying that he’d done more digging, and that it was a known issue which could be worked around by adding the -v flag to git, which forces progress output to be displayed even if the output is redirected. (The issue has something to do with kdesvn-build redirecting the git output, if you run the git command manually but redirect its stdout to a file then you’ll see the clone fail after about 30 seconds as well).
This progress output makes the logged output look really bad, however, so the workaround I ended up implementing in kdesvn-build is to show the progress output on the terminal and redirect the rest (you may actually prefer this as it’s possible to see the progress of the checkout now).
In short, the Great kdesvn-build Git Clone Bug should be fixed. Please test the trunk version of kdesvn-build for me to make sure I got it though!
Maintaining the documentation for a project is a necessary, but often thankless task.
I’ve been going over the kdesvn-build documentation recently since there were several major changes to kdesvn-build in version 1.10 which I didn’t bother to document.
I’d only scratched the surface of the changes when I got fed up with the output that you get by default with our documentation generators (which is not meant as offense, just the way it is).
So, I took a detour and tried to duplicate my output-finessing feats that I had earlier performed on kio_man, kio_info, and kio_perldoc.
To see what I’m talking about first, consider the following:
- Open up KHelpCenter and look at one of the installed documentation pages. (The specific one doesn’t matter, I’m just referring to styling).
- Now look at the output of running meinproc4 with the kde-web.xsl XSLT stylesheet. (meinproc4 is the tool that KDE uses to convert the DocBook XML source to the output HTML). The kde-chunk-online.xsl output is similar. Remember that logo? :)
- The docs.kde.org output is looking a bit better, but still out of date.
- Finally, the kdesvn-build website has my current results at this time.
Now I am neither an artist nor a web designer but I do think that the output is starting to look better. (The content itself is still mostly out of date but I’ve at least updated the command line options and configuration options tables).
So now my question is, is this something I should work on trying to integrate back (at least for KHelpCenter stylesheets, since that output looks broken to me in the header)? I think our “spit and polish” on our user-interfacing documentation could go a lot way toward making the documentation more pleasant to use. And better yet we are outputting specifically for one of the most advanced HTML engines in the world so there’s no reason for us not to use every useful feature if it makes the output nicer, no?
Oh, I changed the git checkout/update procedure a week or so ago in trunk, if you’re not testing it I would appreciate it if you could test so I can do the next release this upcoming week without me being the only one to use it. ;)
So I woke up this morning to notice that my kdesvn-build --refresh-build run from last night had a hiccup somewhere:
The problem was kdelibs failed to install, which meant every subsequent module error-ed out during the CMake process. The problem with kdelibs was related to me having an old library installed in my Qt directory since I hadn’t cleared out my Qt/KDE installation directories first (whoops).
It would be really annoying to have to type out each module to build just to skip the first four that had built right. Luckily I don’t have to do that, instead this sufficed:
$ kdesvn-build --no-src --resume-from kdepimlibs
Script started processing at Sat Dec 12 19:04:24 2009
< << Build Process >>>
Building kdepimlibs (1/21)
Preparing build system for kdepimlibs.
Removing files in build directory for kdepimlibs
The magic here is the --resume-from command line option which skips until the given module in the build process. --no-src is only available since kdesvn-build-1.10, use --no-svn if you haven’t upgraded yet.
Now Konversation has also switched to git.
Peter mentioned it being unfortunate that there was not a way to build Subversion and git modules with the same tool. Except that there is, and has been since October (and even before in the summer if you like unreleased code). kdesvn-build. Yes, I know I still need to rename it, I’ll get to that eventually ;)
Anyways, here’s what I added to my existing kdesvn-buildrc to build konversation:
Now one catch is that scripts (including Michael Jansen’s build tool, last I’d heard) seem to have less success running git than doing so at the command line :-(. If you do end up manually cloning the git repository then make sure you’re using the trunk version of kdesvn-build to avoid git errors later.
One possible workaround is to use the HTTP protocol for the repository instead of the git:// version, but that’s less efficient so I’d really prefer to find a way to make git always work from scripts instead.
Anyways, congrats to the Konversation developers on continuing to blaze the git trail for KDE.
So it’s been a busy month for me:
At work I’ve qualified as an instructor, qualified as Command Duty Officer (basically the senior-most officer on duty when everyone else goes home for the day), and just today I’ve become the Division Director for my division. Basically it just means way more work (I spent 10 hours at work today…) but on the other hand I’ll eventually get my picture on the posted Chain of Command pictureboard at the entrance. Not sure that’s the best tradeoff ever but that’s the major job I was assigned here for in the first place so onward I’ll go.
My class has a sense of humor. I mentioned yesterday that we always ran out of a particular flavor of coffee creamer first while underway. When I walked into the class today there were two little individual-sized creamers waiting for me. :)
On the KDE front, I sent the KDE.news story about Sheldon’s T-shirt to a friend of mine who watches Big Bang Theory. I’ve switched kdesvn-build in trunk to not use any specific remote alias names for git repositories (since people who already had a repo clone couldn’t just use it with kdesvn-build). Finally I’ve been testing a patch to fix a JuK crash-on-shutdown bug. (My reproducer hasn’t gotten back to me though, so it may end up in trunk with me being the only tester :-/). Oh, Jeff Mitchell and Kubuntu conspired to get support for ASF and MP4 added to JuK (requires taglib 1.6, with support for MP4 and ASF specifically enabled). Still to do is to actually make a new kdesvn-build release, change the kdesvn-build name (I’m accepting reasonable suggestions!), and somehow, someway, eventually port JuK off of qt3support and kde3support.
Last (but certainly not least), on the personal level I’ve been super-busy learning LaTeX so that I could turn in two research papers (due on the same day, THANKS PROFESSORS! :P). Now I have to prepare related presentations (which I’m going to use LaTeX Beamer for).
The most somber assignment deserves its own paragraph: We received the death certificate for Emma in the mail recently. We know as much now as we did when she died; the cause of death is listed as undetermined. I need to find time during the working day to run to various Navy offices to handle the administrative mumbo-jumbo of updating my record of dependents to match. It’s still weird. Every day that I really focus my thoughts on Emma, I still don’t really accept that she’s dead. Not sure when it will finally hit me but I’m not looking forward to that day.
Another season, another kdesvn-build release.
Big things in this release:
- The run-tests option, as suggested, tested, and improved by David Faure.
- Git support, so that you can build qt-copy and amarok (and more KDE modules if/when they switch). You need to add the repository option and possibly also the branch option to select what code to clone/update. See the sample configuration file for details.
- All KDE 3 support has been removed.
- Various bugfixes.
I expect you may find bugs with the git support, if so please let me know so I can fix. There are sadly still a couple of reported bugs, but the only reason I went and released this was because I had nice people prompting me via e-mail. I will fix them though, I promise. ;)
Now back to my research papers…
Since I haven’t blogged in awhile I thought I’d give an update as to what I’ve been doing in the past month or so:
- This is only tangentially related to KDE at best but I’ve been pushing to get an improved video game music emulation library supported by GStreamer. The library in question is simply called Game Music Emu (or libgme depending on where you’re looking ;). It is an all-in-one emulation framework allowing for decoding and playback of Super NES, NES, Sega MegaDrive/Genesis formats and more. This has ended up with me having commit access to libgme and fostering a mini-revival by the library author to turn it into a proper library. Based on this work, the GStreamer devs have applied my patch to use libgme and then improved my patch several times from there. The next releases of gst-plugins-bad (for SNES SPC, etc. playback) and gst-plugins-base (for the typeinfo fixes) will be able to make use of these changes. JuK requires TagLib support to add files to a collection so even if you use phonon-gst you’ll still need to use a separate player to test it out though (Qt’s example musicplayer is perfectly sufficient though).
- I haven’t forgotten about kdesvn-build’s git support (it’s actually there, but not plugged into anything other than qt-copy). My major hiccup has been handling the case where the user changes the “repository” option on me (especially with regards to qt-copy). I may just punt and make the user manually do it since I’m not sure what the best way is to switch over the remote tracking options in git (i.e. make git pull work from the new repository from now on)
- I’m trying to get started in a Master’s degree program for a M.S. in Computer Science. I’ve taken the required entrance exam (the GRE) and although I’ll not post the exact scores I will say I did well (and without studying to boot. I tried to study but couldn’t get the “PowerPrep” software to work in Wine). It’s been a bit of a special case for me as I was a couple of weeks past the deadline due to the timing of showing up at my present command, but I think everything will work out to start ASAP.
- If you’re just getting started with KDE 4.3 and you start seeing dialogs warning about being about to start executing a file, that’s by design. I’ve heard of a bug where dragging a working desktop link will make an “unsafe” desktop link since the destination doesn’t fall under the same exemptions as the old location which I may try to look into. Just remember that this is for your own good, and is a one-time only dialog per file! If you are writing your own .desktop links which you want to launch applications, just make sure to set it as executable.
- Finally I’m going to be putting an old unused computer of mine to good use and setting it up for my 2.5 year old son. He enjoys computers too much, now it’s time for him to click on his instead of mine and my wife’s! ;) So I’d prefer it to have a guest account arrangement on super-lockdown (no Web, edu games, paint applets, etc. available, locked or healing desktop, that kind of thing). Any suggestions for KDE-friendly distributions for this kind of thing? I’m trying to keep download size for the install media under 1 GB.
If you’ve been using kdesvn-build to build qt-copy, I recommend updating to the Subversion /trunk version, or using the 1.9.1 release. This is to adapt to a recent change to the qt-copy configure script, which causes an infinite loop (with subsequent disk fillup thanks to output logging). 1.9.1 will not work with older versions of qt-copy however.
For those who are interested, the change is to add a method for accepting a license without user prompting, which means that the previous method kdesvn-build employed (essentially running sed on the configure script) is now unnecessary (and harmful :-/).
In other KDE news, I ran across an issue with KWin closing on me after I closed out of all applications, starting from the other day. I’ve committed a fix to trunk, but I’m still not sure why it’s started exactly. But if you’re running into issues with KWin closing on you when you close all windows make sure to update kdebase.