Cùran's life
A Debian Developer's observations

1st March 2011 00:00 (GMT)
KVIrc in Debian: a small addendum

Raúl (another maintainer of KVIrc) asked me to add a request to our users to my previous entry about KVIrc in Debian. So here it is: please report any bugs you find!

Please note, that most of the bugs you find are most likely upstream bugs. If you're sure of this, you can help us by tagging your bug accordingly. This is done by adding Tags: upstream to the pseudo-headers of your e-mail. If you really want to help us, you can also check, if upstream already knows about this bug and add a Forwarded: pseudo header to your e-mail (if you want to report a new bug upstream, you can do so at https://svn.kvirc.de/kvirc/newticket).

Permalink | debian, kvirc.
1st March 2011 00:00 (GMT)
Weather Forecasts In A KDE Environment

As Squeeze was just released, some might be on the lookout for a replacement for LiquidWeather++, a SuperKaramba script. Others might just search for the first time for a way to have a weather forecast displayed on their desktop.

With my yaWP maintainer hat on, I'd like to recommend yaWP for the job.

Why yaWP?

Short answer: because it's the best (SCNR). Longer answer: because yaWP is easy to use, yet highly customizable. yaWP can track the forecasts of several cities for you, you can put yaWP on your desktop or in your control bar. You can limit the amount of days displayed (in the control bar mode). It's localized for many languages (if your language isn't among the already existing ones, please consider translating yaWP). yaWP can work with multiple services, is themeable and can display a satellite image for your area.

Now, some of you might still (don't ask me why) prefer a different Plasmoid for displaying the weather forecasts. But even those can benefit from yaWP and use one of its three data engines (AccuWeather, Google Weather Service and Weather Underground (Wunderground)), thanks to KDE's Weather Ions.

Ok, and how does it look?

Please remember, that yaWP can be themed, so the picture below just shows one option of many.

A screenshot of yaWP displaying data
Included from screenshots.debian.org (License: GPL2 or later)

Permalink | debian, kde, yawp.
2nd March 2011 10:05 (GMT)
Downloading entire YouTube playlists

Downloading videos from YouTube isn't a problem thanks to tools like clive. But fetching all videos of a playlist was always a little bit tricky. There is clivescan, but it requires user intervention and needs Tk. Other tools have focused on feed parsing, so in case you have a playlist feed you can then download all (listed) videos. But none of the tools offered me a simple way to download all videos in a playlist from the command line. That's when I started writing ytplaylistfetcher, a simple shell script aiming to parse a YouTube playlist, extract all unique video ids and pass the list on to clive for downloading.

By now ytplaylistfetcher is pretty much complete and there aren't many changes ahead (unless YouTube changes its page layout again, e.g. back to multi-page playlists).

At the moment ytplaylistfetcher can handle the three common playlist link formats. If you've encountered another format or found a playlist link that doesn't work, let me know.

ytplaylistfetcher has just one limitation in my opionin (but one I can live well with): it is limited to YouTube playlists. But that isn't a severe drawback in my opinion, as I rarely receive playlist links to other video hosting platforms (at least none where a simple wget call doesn't solve the problem.

This little script show-cases one reason, why I like Linux so much: there is always an easy way to extend existing functionality.

Permalink | clive, debian.
2nd March 2011 16:20 (GMT)
Embedding license information in a XHTML-valid way

When you want to offer creative work, or at least your blog posts, under a license which gives the receivers a lot of freedoms, you'll sooner or later come across the Creative Commons licenses. And after you've selected a license of your liking, you'll be presented with a little XHTML snippet. Nice. What's not so nice is, that you'll break the validity of your website as soon as you put that snippet somewhere on your homepage. What to do?

Easy. Ask the W3C for help (ok, don't call them, just use a search engine). Since Tim Berners-Lee is promoting the semantic web for some time now, there must be some conformant way to add the information, which hopefully is also supported by standard-compliant browsers. The answer is a W3C recommendation. The recommendation talks only about XHTML 1.1, but there's also a XHTML 1.0 DOCTYPE (If you don't care about IE, you can use the XHTML 1.1 variant, at least the last time I checked, IE failed miserable with XHTML 1.1. Admittedly, it has been a while since I looked this up.). Just put:



at the top of your document. Depending on what RDF namespaces you want to use (and how often), you can add more namespaces than the default one to your html tag. So a template for a "XHTML 1.0 + RDFa" document might look like:




  
    An XHTML 1.0 + RDFa standard template
    
  

  
     

Your HTML content here

[Website Title] by [Author's Name] is licensed under Creative Commons Attribution-ShareAlike 3.0 Unported License unless noted otherwise.

When you're finished, you can start adding licensing information (and other relations) to your website as this little blog is doing.

Permalink | creativecommons, licensing, meta, xhtml.
3rd March 2011 12:48 (GMT)
Extending Chronicle (Updated)

This little blog is created/compiled with Chronicle, coded by Steve Kemp, and one of the cool features is that you can specify a command run before/after your blog gets compiled from the input files. This presents us with one problem and a lot of opportunities.

First to the problem: the singular "a command" (from the manual page) might not be enough. Maybe you want to run more than one command. This can be achieved by creating a directory for the commands you want to run before the compilation and one for the commands you want to run after the chronicle run. [UPDATE]Then just add run-parts /path/to/{before,post}.d to your .chroniclerc for the {pre,post}-build configuration entries.[/UPDATE] (Thanks to Steve for pointing the obvious out to me, don't know why I didn't think of run-parts myself.)

Now to one of the oppurtunities this offers: you can now, for example, create static pages, which share the general visual appearance with your blog entries but don't show up in the tags or archive system. I'm using this to generate an imprint for this blog. The script to generate the imprint looks like:

#!/bin/sh

set -e

OUTPUT_PATH=`grep output ${HOME}/.chroniclerc | cut -d= -f2 | tr -d [:blank:]`

sed -nre'/<\?xml version/,/blosxomFirstDayDiv/ {/blosxomFirstDayDiv/b;p}' \
        ${OUTPUT_PATH}/index.html > ${HOME}/tmp/imprint.html
cat `dirname ${0}`/imprint.data >> ${HOME}/tmp/imprint.html
echo -e "\n" >> ${HOME}/tmp/imprint.html
sed -ne'/imprint_match/,$p' ${OUTPUT_PATH}/index.html >> ${HOME}/tmp/imprint.html
mv ${HOME}/tmp/imprint.html ${OUTPUT_PATH}/imprint.html

There are again some assumptions made here, which you'd need to adopt to your setup:

  • I'm using a modified version of the "Copyrighteous" theme (one of the modifications was detailed yesterday).
  • The script expects the output setting in your .chroniclerc.
  • The content/body of the imprint is stored in a file imprint.data in the same directory as the script which generates the imprint.
  • There is a tmp directory below ${HOME} (this is there to cope with a chroot environment).

Now you have a very powerful system to modify/extend your chronicle-generated blog. I hope you enjoy it as much as I do!

A little P.S.: you might want to use version 4.5, as 4.4 had a nasty encoding bug.

Permalink | chronicle, debian.
7th March 2011 15:41 (GMT)
On building from Source

I've received a few requests to help with failing builds in the past, mainly for packages I maintain (either officially or unofficially). And most of those requests revolve around custom Wine builds. Because this is recurring, I'd like to take the opportunity to write down some general answers which solve most of the problems, so I can point people to this entry.

  • Use pbuilder (cowbuilder is a good companion to pbuilder).
  • If you've modified the packaging, make sure you didn't introduce bugs, which lead to your failure (this implies careful reading of your build logs).
  • If you didn't update the packaging and just used a newer upstream version to build your packages, you should check what was changed upstream (maybe you need some additional Build-Depends or something similar) and whether the unmodified Debian package (including the .orig.tar is buildable in current Sid.
  • If you added patches (maybe taken from some upstream bug tracker), make sure it's not those patches, which cause the breakage.
  • When you do a backports build make sure all build dependencies are satisfied.

Apart from that, you'll most likely find a lot of answers in the Developer's Reference and the New Maintainers' Guide.

Nothing of this is news to Debian Maintainers, but I hope it helps people doing a build for themselves, when they're less experienced.

Permalink | debian.
8th March 2011 13:00 (GMT)
KDE4 with multiple displays

This is kind of an "Dear Lazyweb" entry: I'm looking for a way to make a KDE4 control bar span more than one display. Just consider two displays next to each other, configured with RandR to form one big desktop. I haven't found a way to have the control bar span both screens. Sure I can add another control bar to the second but that's not what I want.

And while at it: is there a way to hid the toolbox thingy of the desktop activity in the upper right corner (at least once, because having it on two displays sitting next to each other doesn't make that much sense)?

Just to make sure: the displays are not in clone mode, but create a large desktop spanning two displays. The Squeeze version of KDE is used.

So, if you know how to do this or have a pointer to some article, please let me know.

Permalink | debian, kde.
14th March 2011 13:44 (GMT)
ytplaylistfetcher: new playlist URL format

It seems like YouTube has added a new format for playlist URLs. You'll find it on search result pages. The ID of the playlist comes after:

list=PL

So a complete URL containing this format might look like http://www.youtube.com/watch?v=hzMtVJTxrJw&playnext=1&list=PL00A3D4ABEAF28FA3

I've added support for this format in bcccc0f7 to YTPlaylistFetcher. You can download the latest version by right-clicking on the previous link and select "Save Link as ..." from the context menu.

Permalink | clive, debian.
18th March 2011 19:11 (GMT)
KVIrc updates (ahead)

For the users of Debian Squeeze we, the KVIrc maintainers, plan to upload the soon-to-be-released upstream bug fix release 4.0.4, packages of RC2 are available. RC2 is most likely going to be identical to the final 4.0.4 release.

The update will be, if the SRMs agree (still need to ask them, but I wanted to wait for the final version before I do that), uploaded to stable-proposed-updates, maybe squeeze-updates and fix a few nasty bugs, which some users might experience, including graphical glitches when used under Gnome (upstream bug #1010), some crashes (e.g. upstream bugs #878, #879, #1093, #1098 and some without bug numbers like r4796), a regression in the Perl scripting support and a lot of translation updates (btw: if you use KVIrc and the translation for your mothertounge is lacking, consider to help! Coordinate your efforts on IRC.)

Apart from that I just uploaded a new SVN snapshot of 4.1 into Sid, the next will follow in about ten days unless you report bugs, which make an earlier upload necessary. ;-)

Permalink | debian, kvirc.

Common Blog License: Creative Commons Attribution-ShareAlike 3.0 Unported License | Imprint (Impressum) | Privacy Policy (Datenschutzerklärung) | Compiled with Chronicle v4.6

Archives

Tags
Feed
Support my Debian work!
Validated