As one of the Co-Maintainers of KVIrc, I'd like to give you a short outlook on what is planned for KVIrc in Debian in the near future or at least in the Wheezy release cycle.

• Upload of a 4.0.3 bug fix release to stable-proposed-updates as soon as upstream releases it.
• Packaging a new 4.1.1 snapshot every ten days (that is always after the previous one migrated to Testing) and make ready for 4.1.1 (maybe even 4.2?) in Wheezy.
• Rework the CMake build script of KVIrc to ensure minimal linking. At the moment KVIrc has CMake gather all B-Ds in the global CMakeLists.txt and adds those to all compiler/linker invocations. By pushing the include_directories() calls down to the respective modules and adding just the required variables to the target_link_libraries() invocations, we can improve the situation significantly.
• KVIrc uses a lot of reinvented-the-wheel code, some of this is due to its age (I think KVIrc is around since Qt2 and a lot of stuff wasn't available as an easy-to-use library then). But to be maintainable, KVIrc must move to leaner code base, which can be achieved by replacing such fragments of code with library calls. This is a big task and might not be completed in time for Wheezy, but the effort should be taken nonetheless.

Apart from what is listed above, we, the Debian Maintainers of KVIrc, strive to improve its packaging constantly.

I've been building unofficial wine-unstable packages for some time now and the amount of people apparently using them has become noticable (not only traffic-wise). Thus the amount of questions send to me has also risen quite a bit. In this post I try to address most of the questions in the hope it'll help people understand my motives for building these packages and potential pit falls for users.

First of all: I'll stop building those packages as soon as Debian has a – for my purposes – recent enough version in the archives. This is expected to happen soon as most/all of the blocking issues should be sorted out now/soon. See e.g. #557783 for some insight into the problems. It might happen after updated packages are in Debian, that I'll build one version or the other occasionally to test a certain patch or version. The bottom line of this is: don't rely on me to provide always the latest packages. (This, by the way, is also explanation enough to the question, whether I'm going to build the "official" (I consider only those entering Debian's archives official) Debian packages for upstream (WineHQ).)

Another question, which is seen every now and then in my inbox, is, whether I could add patch xyz to the packages. The answer is no. I maintain those packages for myself and if you want to use them, you're welcome. If you need another patch applied, just download the source package and add the patch with quilt to the series.

When a certain version/build doesn't work for you, you can ask me for help, but please don't expect me to handle "doesn't work" reports like I would handle bug reports for my packages. The wine-unstable packages are for myself and if they work for me, that's all I aim for.

Before spreading the word about my packages, make sure, you and those who read your post/message/whatever about my packages understand, that it is generally a very bad idea to install third-party packages, even though I'm a Debian Developer. Make also sure everybody understands that only the source package is signed with my key.

Please don't download all packages (binary and source), unless you really need all of them. Please pick the ones, you need and just download them.

Even though this might sound like begging, which I'm not, it'd be nice, if you could consider donating (via PayPal) something, to help cover the traffic costs. The traffic for just the wine-unstable packages has risen dramatically in the last few months. Thanks!

Now, I hope I've answered most questions, if not, feel free to contact me.

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).

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.

Included from screenshots.debian.org (License: GPL2 or later)

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.

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.

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.

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.

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.

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. ;-)

Just a short note, as I've already got e-mails about this: the binary packages are built ASAP, but currently one Build-Depends (openssl) isn't satisfiable for all platforms. The reason is simple: a new OpenSSL package (1.0.0d-1) was uploaded into unstable just recently and not all builds made it into the archive yet, some are still in incoming (please note, that they might not be there anymore, when you click the previous link).

So please be patient, the builds are done, when possible. Thanks. ;-)

All my notebooks till today have been ThinkPads from the T series, sadly Lenovo decided (or, maybe, were persuaded) to go with nVidia GPUs for their current designs (T5xx). That's sad, because nVidia doesn't cooperate with the FLOSS world. I still wanted a ThinkPad with up-to-date parts. That left me with the Edge series, which is designed to be the bridge between consumer and business models. After some searching I settled on the NVLJ6GE model (the last two letters just indicate, that this is the "German" variant). The key specs are Intel Core i5-480M, 4096 MB RAM, AMD Mobility Radeon HD 5145, Intel WLAN module and a non-glare display.

Now to the part about running and installing Debian testing on this. Judging from the hardware I was pretty sure, that getting all hardware (i.e. all hardware I'd be using; e.g. I'm not using WiMax or the integrated web cam so far, which means I've dectivated them in the BIOS) up and running. and I'm happy to report, that this is true.

The installation was really straight forward (netinstall CD in expert mode (64 bit), running through all steps and booting, that's it). I did the install over a wired network, mainly because this is faster for me, but with an USB stick and the firmware for the Intel Centrino module a installation over the wireless interface should work too.

I'm now running a slightly customized setup (e.g. my own 2.6.38.2 kernel and Mesa 7.10.2, the X from experimental), but not because some serious problems with Wheezy.

So far I can recommend this ThinkPad for usage with Debian (or Linux in general), though, if you don't want a "big" GPU, you might be happier with a T or L series model. They should run somewhat longer with the default battery (Lenovo 25+ with six cells). As for the service for this line I can't say anything yet, but as it's still a ThinkPad, I hope it'll be as for the other ThinkPad series.

As I got some e-mails about this: if you're on amd64 and Wine complains that it couldn't find a 3D acceleration card, then this is no bug in my wine-unstable packages but #614805.

The short-term workaround for you is to use LIBGL_DRIVERS_PATH=/usr/lib32/dri. You can either put it in front of every Wine invocation or you can export the variable in a specific shell session (don't export it globally), in which you'll run Wine or other programs needing the 32 bit libraries.

#614805 should be fixed automatically by the next ia32-libs upload, if it contains a version of Mesa containing Git commit cdd1912f.

Yesterday I received another report for a game, which wasn't working with the wine-unstable packages built by me. The reason why the reporter wrote to me and suspected a bug in my builds was, that the same game worked on the system of a friend (using a different distribution). After some exchanged e-mails it became apparent that this was yet another installment of S3TC-compressed textures. And as this wasn't the first time I got such reports, I thought I blog about the solution today.

As S3TC is one of those patent-encumbered texture compression formats (don't ask me why one can get a patent for such things, it's, IMHO, a very bad thing and we'd be better off, with a lot less patents), Mesa doesn't support it out of the box. You need to install an additional library or the proprietary driver for your graphics card. Before installing the library, make sure, that it is legal in your jurisdiction (i.e. check whether the patent is valid in your jurisdiction). If that is the case, you can install libtxc-dxtn0 from the Debian Multimedia repository or compile it yourself from source. If the patent is valid in your jurisdiction, you're most likely required to get a license from the rights holder for using the library, but I'm no lawyer so you might want to consult one prior to making your decision.

For amd64 users, there is an additional caveat: Wine needs the 32 bit variant installed. At the moment, this means downloading the i386 package from debian-multimedia.org and extracting the library to /usr/lib32.

For users with the r600c/g driver it gets (currently) really tricky, as there is no fully working support for loading libtxc_dxtn.so (current status is WIP). Here the only solution I know, would be to use the proprietary driver or writing patches for r600g (last option preferred *g*).

Just two days ago I wrote about S3TC-compressed textures and that it is a little bit tricky for amd64 users to get the correct libraries installed. Since then I've been in contact with Christian Marillat, the guy behind debian-multimedia.org and he immediately responded with uploading ia32-libs-libtxc-dxtn0 to make it easier to install the 32 bit variant of libtxc_dxtn0 on 64 bit platforms.

A big Thank You! to Christian! And if you find his service helpful, consider donating to him (I can only guess at the amount of traffic he gets, especially since a lot of people certainly don't use one of the mirrors). (Just a short disclaimer: Christian didn't ask me to put the donation request in this post, in fact he'll only know about it, as soon as this goes online.)

I'll add an Suggests: in the next upload of wine-unstable to the server on libtxc-dxtn0/ia32-libs-libtxc-dxtn0 so people'll have an easier time to get S3TC working. But again: before installation: make sure it is legal for you to install the library.

Due to popular demand ("I would give you something, if you'd offer Flattr."), which really just came up after WineHQ started linking to the download page, I've added a Flattr link to the wine-unstable download page. I still wanted to keep it as unobtrusive as possible and just use a text link.

In other news I've uploaded 1.3.19 today, sorry that I didn't manage to do so before the weekend was over, but the upstream release happend after I went on a short trip to Bremen.

And since some people didn't seem to read the notes on the download page, I'll try it through this channel: the package download page is NOT an APT repository. I want people to carefully consider the pros and cons before installing software from a third party. So please don't point your sources.list to the download page. Thanks!

I'm using gitosis to manage my Git repositories on the public server. That server was recently upgraded to Squeeze and I didn't create a new repository on that server so far but today I wanted to and got:

ERROR:gitosis.serve.main:Repository read access denied
fatal: The remote end hung up unexpectedly

A search yielded some results with people messing up their keys or forgetting to create the configuration file entry or something similar. None of this was my problem. As it turned out, the post-update hook for the admin repository has been moved from /usr/share/python-support/gitosis/gitosis-0.2-py2.5.egg/gitosis/templates/admin/hooks/post-update to /usr/share/pyshared/gitosis/templates/admin/hooks/post-update, but the symlink hasn't been updated on upgrade. After running a simple

ln -sf /usr/share/pyshared/gitosis/templates/admin/hooks/post-update post-update

in the hook directory of the admin repository everything worked again.

Steve Kemp recently announced his resignation from Debian. That left a few of his packages without a maintainer, one of them was Chronicle. As a Debian Developer using Chronicle, I've adopted this package. The upstream development will still be mostly done by Steve. The packaging is done in a Git repository. The 4.6-1 upload consists of a new upstream version and some housekeeping stuff on the packaging side (like switching to a minimal debian/rules, fixing some Lintian warnings and complying with the latest version of the Debian Policy).

I'd like to take this opportunity and thank Steve for all his work for Debian. Hopefully he'll be back to Debian in the future.

I've just uploaded a new KVIrc SVN snapshot (r5829) to Unstable. This one took a little longer than the "normal" ten days because the transition of the previous version waited for some other packages to migrate first. This transition might also take longer than we hope for, due to #625607 in EGLIBC, which leads to a segfault in CMake on SPARC.

The stable update to (more or less) upstream's 4.0.4 is also almost ready. We hope for an upload soon.

Just a short announcement for the impatient: Wine 1.3.20 packages are available. As of this writing it's only the source package, the binaries follow as soon as they're built.

As a small side note: this is, as far as I can remember, my quickest upload of a Wine version (only about 15 minutes after the release was tagged upstream).

I've uploaded liblwp-authen-oauth-perl to Debian today, [UPDATE: currently the package is waiting in NEW (please note, that the previous link might not work, in case the package has entered the archive already or the page hasn't been generated yet). and is now in the archive. Thanks a lot to the FTP Masters for the quick processing!]

LWP::Authen::OAuth allows to easily integrate OAuth authentication into Perl programs and libraries. Some of you might already guess, why I have an interest in OAuth for Perl: as a user (and maintainer) of Chronicle I'd find it neat, if there could be some Flattr integration (especially a automatic submission of new posts to Flattr). This sent me searching for an Perl implementation of the Flattr API. Unfortunately this turned up nothing, therefore I'm now planning to write some sort of Net::Flattr Perl module, which I can then use in Chronicle for one task or another.

Net::Flattr (preliminary name, but probably the final one, as the implementation of the Twitter API is called Net::Twitter) is going to be a library, which should offer the same functionality as Flattr's PHP library. For now there are some scetches to this extent on my hard drive, but nothing showable. I hope I find the time soon to write this but it shouldn't be too difficult. ;-)

Apart from my particular use case, you can use LWP::Authen::OAuth for any other OAuth-requiring API. I hope the package helps you to build more cool tools for and on your Debian system!

Today I was playing with some RDF information, initially triggered by my entry about Josephine. While at it I decided to add some information explicitly to the head tag, including

Obviously I wanted to add those two tags to my templates, so Chronicle adds that to all files. Unfortunately this resulted in an encoding error of the "ä". Some digging in the source of chronicle showed, that HTML::Template-new() was called without ensuring, that the tempalte files were parsed as UTF-8 encoded. The solution was to add a filter.

The just uploaded version 4.6-2 contains the required patch and if you don't use the Debian packages you won't be left out for long, as Steve already applied the fix upstream.

As I'm asking for donations to help cover the traffic costs for the wine-unstable packages I provide and to support my Debian work in general if appreciated, I thought a "Thank you!" to all those who've donated something so far would be in order (don't worry, I won't disclose any names of donators or other personal information).

Thus here we go: Thank you! It's much appreciated.

For all those who just read this and think they'd like to donate something too, if just they could locate the links to do so, here they come:

• PayPal (general donation link, the wine-unstable specific link can be found on the package page
• Flattr:
  • general Debian work
  • wine-unstable packaging (traffic)
  • donate through Flattr (you need to be logged in, otherwise the previous link will redirect you to the main page)

I already blogged about S3TC support with Wine, but back then I wrote about problems to get that working on amd64 without a proprietary driver. Now I've figured out a way to get it working on amd64 with the free radeon drivers (Gallium versions).

It's actually pretty simple, as most things are, once you figured it out. For 64 bit applications, you just need a recent Mesa version and the package libtxc-dxtn0. If you're using a card supported by the r600g driver, you first need a version of the Mesa package, which is build with the Gallium version of the r600 driver (the classic driver should work too, but I haven't tested that), like my unofficial Mesa packages (those packages were built for testing r600g, see this e-mail to debian-x). r600g users also need to set R600_S3TC_ENABLE=1, otherwise the driver won't attempt to load libtxc-dxtn0.

For 32 bit applications (like Windows games run with Wine) the initial setup is a little bit more involved: in addition to the above you also need to update a few libraries under /usr/lib32: namely Mesa and libdrm (if you use my Mesa packages you need a i386 copy of libffi too). The quick and dirty approach is to download the i386 packages for libgl1-mesa-dri, libgl1-mesa-glx, libglu1-mesa, libdrm2, libdrm-intel1, libdrm-radeon1 and (if you use my Mesa build) libffi5. Unpack the packages (dpkg-deb -x) and move the files under /path/to/unpack/dir/usr/lib to /usr/lib32. Alternatively you can also build a new ia32-libs package (make sure you change the source.list file of ia32-libs to use at least testing as a base, otherwise you'll end up with basically the same versions as are in the current package).

No matter how you updated your drivers you now need the 32 bit version of libtxc-dxtn0. debian-multimedia.org offers a packaged version.

After installing all the previous packages, Wine should be able to display (most) S3TC-using programs (in case you use the r600g driver, make sure you have R600_S3TC_ENABLE=1 set). If you're using my Mesa builds you can drop the LIBGL_DRIVERS_PATH=/usr/lib32/dri part again from your Wine invocation.

Please note, that there might be some S3TC-using applications with graphical glitches, when using the above method, as the support for S3TC in r600g is still marked as WIP.

As the local geek I get all sorts of (Linux) questions asked, like "How can you delete the nth line with Sed?" or "Is there a way to search for the following in a file?" (the latter being a request to construct a regular expression for grep). And while I'm pretty sure, you can find answers for such questions quickly with $SEARCH_ENGINE I find myself generally typing the answer into the IM session. This, and just seeing Bernd's post about Vim on Planet Debian, prompted me to start a little, irregular series of posts, to which I can point people, whenever I get asked such questions.

I start this off with a tip for Vim, a very powerful text editor. The problem is simple: you get (source code) files with trailing whitespaces (sometimes accumulated in "empty" lines). This makes diffing (and merging) difficult. Thus the question is: how do I prevent that from happening? How do I notice, that I have whitespaces at the end of a line? The solution consists of two lines in your .vimrc:

:highlight TrailWhitespace ctermbg=red guibg=red
:match TrailWhitespace /\s\+$\| \+\ze\t/

If you just want this functionality if syntax highlighting is also active, then you should use

:autocmd Syntax * syn match TrailWhitespace /\s\+$\| \+\ze\t/

instead of the :match line. The regular expression used in both cases matches trailing whitespaces and whitespaces in front of tabs.

Of course there are several other options on how to do this or what you might want to highlight, but that would be beyond the scope of this little post.

Yesterday's blog entry garnered a lot of attention and some responses (in the form of e-mails, which is totally fine). Two of them deserve, as far as I'm concerend, their own little entry in the mini-series I kicked off. So, here we go:

First up was reader Sylvain "ythier" Hitier, who suggested adding

set list lcs=eol:¶,tab:»-,trail:·

to your .vimrc and making use of the :list option. The above line will highlight tabulators, trailing whitespaces and the end of a line. And it'll allow you to differentiate the three.
A warning though: you would want to deactivate this, in case you want to do copy and pasting with your mouse.

[UPDATE] Sylvain just sent me a little key binding for C&P he's using to toggle the highlighting:

function CutPaste()
  setlocal paste! nu! list!
endfunction
map <F10> :call CutPaste()

[/UPDATE]

The second really nice idea came by courtesy of Thilo Six to my attention:

" automatically delete trailing whitespace & Dos-returns    {{{2
fun! <SID>MyDeleteTrailingWhitespace()
  if ! &bin
    let l:l = line(".")
    let l:c = col(".")
    silent! :%s/[\r \t]\+$//
    call histdel("search", -1)
    call cursor(l:l, l:c)
  endif
endfun
autocmd BufWritePre,FileWritePre * call <SID>MyDeleteTrailingWhitespace()

The above snippet will automatically delete trailing whitespace and carriage returns as added by a lot of Windows programs.
Again a little warning: the function is executed automatically, so be sure you have only replacements included in the regular expression you really want to get deleted!

Thanks a lot for all the input I've received!

From time to time I get e-mails about my wine-unstable packages being uninstallable. Most often it turns out, that the problem stems from using e.g. oldstable (Lenny) instead of at least stable (Squeeze). The same problem arises, if you wish to install the wine-unstable packages on a platform for which I don't offer binaries. In either case you need to build the package from source, which isn't as difficult, as many think.

This entry in my ongoing tips mini-series of posts is thus going to detail how you setup pbuilder and afterwards use it to build a package. Please note, that I'm just focusing on pbuilder here and ignore things like cowbuilder.

Preparations

The following steps are needed just once, in general. Some would be needed again, if you want to create a second base.tgz, e.g. for a different distribution.

1. Install pbuilder with your favourite package manager, e.g. aptitude: aptitude install pbuilder
2. Become root
3. Configure pbuilder. Have a look at /etc/pbuilderrc, /usr/share/doc/pbuilder/examples/pbuilderrc and the manual page for pbuilderrc for reference. If you want to change some settings made in /etc/pbuilderrc, create a /root/.pbuilderrc and override any settings you don't like.
4. Create the base.tgz (the chroot environment for your builds). In the easiest case all your settings are made in the configuration files and you just need to run pbuilder --create, which creates the base.tgz in /var/cache/pbuilder, unless you changed the configuration.
   You should also note, that you can override certain settings, like the distribution or the path to (and name of) the base.tgz file created. See the manual page for pbuilder for all options and when they can be used.

Build a package

The following steps are needed for every build:

1. Download the source package, you want to build. No matter how you fetch them (dget, apt-get source, …), you should end up with three files, one of them ending in .dsc.
2. Become root.
3. Update your base.tgz file: pbuilder --update. Again, see the manual page for further options. (You can skip this step, if you just created the base.tgz or you just updated it for another build.)
4. Build the source package: run pbuilder --build /path/to/source-package.dsc (obviously you need to replace the last argument with a real path)
5. If you haven't changed the configuration of pbuilder in that regard, then your binaries end up in /var/cache/pbuilder/result. Install the binaries, you want, from there (with dpkg -i).

Now you should be able to build your own packages from source!

And to answer one question, that some of you might have now ("Why use pbuilder at all and not just build the package with dpkg-buildpackage directly?"): because pbuilder allows you to reliably build in a clean environment. That can safe you a lot of trouble, especially if you modified the source package. And it helps to keep the number of installed packages on your system down.

Today's addition to the tips series has a funny history. A friend of mine was stuck in an envrionment, where she couldn't install Perl or CLive but PHP with some PECL modules was installed. She needed to download a few videos for a presentation, but didn't know how to fetch the videos from YouTube. So I was asked to help. ;-)

After some pondering of the problem, I came up with the following script:

 *
 * Small little script to help out in the absence of Perl/Clive but with
 * PHP present.
 *
 * License: GPLv3 
 *
 */

if(php_sapi_name() !== 'cli')
  die("This script needs to be run on the CLI!\n");

if($argc !== 2 )
  die("No URL given on CLI or too much parameters!\n");

// Script expects a URL like http://www.youtube.com/watch?v=[ID]
if(filter_var($argv[1], FILTER_VALIDATE_URL, FILTER_FLAG_QUERY_REQUIRED) === false)
  die("Parameter given as URL does not seem to be an URL or contain a query!\n");

if(!$ch = curl_init($argv[1]))
  die("Couldn't init cURL handle for »".$argv[1]."«\n");
curl_setopt($ch, CURLOPT_HEADER,          false );
curl_setopt($ch, CURLOPT_RETURNTRANSFER,  true  );
$htmlsource = curl_exec($ch);
$error = curl_error($ch);
curl_close($ch);
if($htmlsource === false)
  die('cURL returned an error: '.$error."\n");
unset($error);

if(!preg_match('/url_encoded_fmt_stream_map=([a-zA-Z0-9%\.,\-_]+)&/',
               $htmlsource, $matches))
  die("No matches found for url_encoded_fmt_stream_map!\n");

$final = NULL;
foreach(explode(',', urldecode($matches[1])) as $decoded_url_map) {
  parse_str($decoded_url_map, $tmp);
  if($tmp['quality'] === 'hd1080') {
    $final = $tmp;
    $final['url']   = urldecode($tmp['url']);
    // $final['type']  = urldecode($tmp['type']); // Not used
    break;  // Not really needed, but should save us some
            // iterations, since 1080p seems to come always first.
  }
}

if(!is_array($final) || is_null($final))
  die("No 1080p version of the video was found!\n");

if(!preg_match('/

You can download it from my website or you can just copy the code given above into a file. No matter how you obtain the code, the invocation will look like: php -f /path/to/script.php http://www.youtube.com/watch?v=[ID].

Now, before I get a lot of e-mails telling me, what could be improved on the script or its other limitations (like only being able to download 1080p videos), please remember that it was hacked together for a simple use case with no real intent on my part to use it for anything else. It only later occurred to me, that others might be in a similar pinch sometime. Thus I'm releasing the above code "as is" under the GNU GPLv3. Therefore you're free to adapt it to your needs. Please also note, that I'm not recommending using the above script instead of CLive. If you can install CLive, do so and don't bother with the above.

Just a short entry, as I've already got a few e-mails about this: the JPEG is broken at the moment for my unofficial wine-unstable packages on amd64. This is due to #638543 in ia32-libs-dev. Please see the bug report for a detailed explanation.

A rebuild with libjpeg62-dev isn't an option, as other build dependencies pull libjpeg8-dev in anyway. Thus forcing the older version on amd64 just generates a FTBFS.

Full multi-arch support in the toolchain (including dpkg) or an update for ia32-libs are the two viable solutions for this as far as I can tell.

[UPDATE 2011-09-05]I received some questions (or saw them), which I tried to answer with a follow-up entry.[/UPDATE]

As I tried to explain this a few times in the past to others and had trouble myself, when I started using Linux, I thought I take some time today and write down what parts comprise the Linux graphics stack and how they interact. I'll ignore some parts which aren't too interesting to an average user at the moment, to keep this post as consise as possible. Apart from that, I hope I'm able to put all the relevant data into one spot.

Let us start our little journey in the kernel. There, in a directory named gpu you'll find the drm directory, which contains all DRM drivers. In this post, we'll focus on those. The drivers in that directory are the kernel side of the Direct Rendering Infrastructure (DRI) and are responsible for managing concurrent access to the graphics hardware. They also provide interfaces to pass commands and data to the GPU. The DRI wiki explains the three main purposes of the DRM modules.

The DRM module is also the part that decides whether KMS or UMS is used. Other acronyms you might hear with regard to graphics acceleration on Linux and are referring to the Kernel part are:

• GEM: an Intel-developed memory management system for GPUs.
• TTM: refers to the memory management system used by almost all non-Intel drivers (e.g. AMD's Radeon drivers). The TTM interface is "GEM-ified", meaning it offers the same API as GEM.

Apart from that, every driver has its hardware-specific parts like utilizing power-saving functions of the respective GPUs, loading firmware, if required, etc.

Now we move from Kernel space to user land. We'll ignore any non-X and non-Mesa parts (like acceleration for TTYs). That means, that our next GPU specific part is most likely the DDX. (Please note, that the classic DDX might be replaced by a Gallium3D state tracker, currently that would be the xorg state tracker, but xorg will be replaced by XA. This is only an option if the Gallium driver for your GPU supports one of those state trackers, see the Gallium status page for further details.) The DDX for your GPU offers plain (2D) X acceleration on your hardware. The respective DDX' are generally named xf86-video-[NAME], where [NAME] is replaced by e.g. ati or intel. The DDX decides which X acceleration paths are available. Acronyms you might hear, referring to the DDX part of the graphics stack, are:

• EXA: even though it looks like an acronym, the X.Org wiki Glossary defines it as:

  acceleration architecture with no well-defined acronym

  EXA superseded the older XAA and offers 2D acceleration, often in conjunction with XRender.
• UXA: more or less EXA for Intel GPUs.
• GLX: actually not a part of the DDX, but an extension for X. It provides a way to draw with OpenGL into an window managed by X.
• XRandR: An extension for X which needs to be supported by the DDX to work. It offers a standardized way to set up (multiple) heads (e.g. resolution, position, rotation, etc.).

We're almost through: the last important part is the 3D acceleration offered by a Mesa driver. Mesa drivers come in two flavours: classic (e.g. all Intel drivers which are supported by Intel) and Gallium3D-based (like the drivers for Radeon chips from the R300 onwards). The difference here is, that the Gallium3D drivers try to share as much code as possible (and thus simplify writing a new driver supporting many platforms, systems and technologies), while the classic drivers are specific to certain platforms, chips, and technologies. They share much less code among each other. All parts of Mesa need direct access to the graphics hardware (DRI)

The Mesa drivers use the 3D pipeline of the GPUs for accelerated drawing, even for non-3D applications like video acceleration (recently VDPAU, XvMC and VA support were added to Gallium3D, driver support followed quickly). Otherwise the Mesa drivers are mainly used for OpenGL acceleration. Users of OpenGL include scientific programs, CAD and – of course – games.

This concludes our little journey through the various parts of the Linux graphics stack. I hope it helps in understanding the building blocks.

Thanks to the awesome patent situation (if you're unaware of what I'm talking, you can catch up by listening to PRI's This American Life episode about patents, reading Florian Mueller's write-ups about the patent wars (current focus: mobile devices) or by having a look into my posts with the "patent-mess" tag), Debian will most likely be unable to distribute Mesa packages with ARB_texture_float enabled (if you want to build mesa yourself with this extension enabled, just add --enable-texture-float to confflags-dri in the Mesa source package's debian/rules). But some programs really like to have this extension, thus I started building Mesa myself. The resulting packages can be found on dev.carbon-project.org.

Big fat warning: please check, whether you're affected by the US patent #6,650,327 (i.e. if it's a valid patent in your jurisdiction) before you use the packages. If in doubt, consult with your lawyer.

By the way, if you're not working in an area where knowledge of the specifc claims/content of the patent might be harmful, you have some time on your hands and you want to learn, what's "patentworthy" these days, have a look at the claims of the patent. Otherwise the three links from the beginning must do.

Before I end this post, just one more remark about my Mesa packages: they'll follow upstream's Git and thus might have problems from time to time. If Debian's Mesa packages suffice your needs, stay with them. If not, feel free to use my packages or use them as a base for your own packages.

This post is a small follow-up on yesterday's post about the Linux graphics stack. I'm still keeping to high level stuff and won't dig too deep, but a few questions arose (others reached me by e-mail), so, here we go.

Gallium3D is a framework, initially developed by Tungsten Graphics, which were bought by VMware. The idea behind Gallium3D is, that many functions can be shared between drivers for different GPUs and that the effort to support a new platform/system is – for classic drivers – pretty high. With Gallium3D you just need a state tracker and a target. The state tracker is code, that gives the pipeline of Gallium3D drivers access to a platform/system, like OpenGL or X on various operating systems. A target is the required as glue between a state tracker and the actual driver. For example: there is a state tracker for video playback acceleration (the recently added g3dvl). The state tracker itself offers the interface and common functions (with some help from the auxilliary stuff) between the Gallium3D pipeline and the userland libraries like libvdpau1. Targets like vdpau-[DRIVER] glue the driver and the state tracker together.

The winsys part of Gallium3D is a similar concept but it abstracts the windowing system on the target platform away (e.g. Wayland, X or GDI).

I didn't write about the proprietary drivers yesterday, as I don't consider them a real part of the Linux graphics stack, more like parasites, and didn't want to encourage anyone to use them (yes, I know, there are some cases in which you might be better off with them, but generally I'd avoid them). Anyway, I got some questions about those (some by e-mail, the other I'm aware off, can be found behind the link at the beginning of this entry). So, where do the proprietary drivers come in? They are basically the entire stack in a closed form, plugging into the public interfaces of the Kernel (whether that's legal is disputed), some other parts like X (by building a DDX) and building their own libGL. Especially the last part can be a cause for a lot of pain, when you don't use the proprietary driver packages offered by the distribution (e.g. Debian's fglrx packages divert the libGL and restore the default one on unistallation, with the vendor build scripts and tools this is not really guaranteed, which might leave you with a broken OpenGL setup).

Another question was, why Mesa was lacking support for a recent OpenGL version (i.e. 4.x). In my opinion there are a few reasons, though I don't really feal like the best person to answer this. The first are design issues by some internal representations (e.g. missing integer support in the intermediate representations). The second is the available number of developers being able to implement new OpenGL functions. Apart from a not all too clear specification the Mesa code base is huge (even if you ignore most of the drivers), which makes it difficult for new developers to start coding away. Then you need an understanding of how modern GPUs operate to find good solutions for the problems faced. If you want to get an idea for this, take a look at Zack Rusin's or Alex Deucher's blog. Then, there is a sad split of developers, on the one hand we've got the Gallium3D-using developers on the other we've got the ones staying with the classic driver model. This means, that you have to implement e.g. GLSL extensions for TGSI and Mesa's IR respectivly. There might be other reasons, I'm totally missing, but this should give you some insight into why it takes so long, to get current OpenGL versions supported.

I hope this clears some of the remaining questions, if not, feel free to write me an e-mail, but please remember, that this is not an in-depth analysis.

Just a short entry: sorry for the 1.3.28 upload delay, but due to #640864 ([UPDATE]: a big "thank you" goes to the GCC maintainers for their fast response[/UPDATE]) I've been unable to do a build. The latest version is now available (binary packages might take a few minutes to appear after this post went up).

[UPDATE 2011-09-11]: All binary packages (i386 and amd64) built as of now. i386 took a little longer, because the i386 packages of gcc-4.6 (4.6.1-10) hadn't reached my mirror in time for yesterday's (CEST) last build run.[/UPDATE]

If you're a German citizen and haven't signed the petition against a new data retention law, then sign it immediately, please. There are approximately [UPDATE]five twenty-five*[/UPDATE] hours left (after that you can still sign the petition until 2011-10-06, but it won't help in the endeavour to cause a public meeting of the petition committee). If you know somebody, who hasn't signed, get the word to them.

[UPDATE]* According to netzpolitik.org the deadline for triggering a public meeting of the petition committee was moved to 2011-09-14 23:59 (CEST), which gives you another 24 hours to sign the petition in time (or get others to sign it). Please use that time![/UPDATE]

[UPDATE2 (2011-09-14)]netzpolitik.org moved the entry about the deadline change to a new blog post, thus I've updated the link above. If you need instructions for the signing process, you can watch „Endspurt: Petition gegen die Vorratsdatenspeicherung“.[/UPDATE2 (2011-09-14)]

[UPDATE3 (2011-09-14)]We did it! Keep it up![/UPDATE3 (2011-09-14)]

As the administrator for several MTAs I've received my fair share of support requests for "unreadable" e-mails. They generally have an attachment called winmail.dat. This is what all (for exceptions see the rest of this blog post) non-Outlook MUAs can display, when they receive an e-mail with the application/ms-tnef (or application/vnd.ms-tnef) MIME type. TNEF is a propietary format cooked up in Redmond. When chosen, the e-mail in question isn't sent as text/plain or at least text/html, but the entire e-mail is put into an TNEF-encoded attachment, most often called winmail.dat, in which you (most commonly) find the content of the e-mail in RTF, possible attachments are also put into the winmail.dat.

The easieast solution for all involved parties is to convince the sender, that her Outlook and/or Exchange setup needs fixing (disabling TNEF in Outlook and Exchange 2003). Sadly this won't work all the time. The other solutions are to either filter the e-mails on your e-mail server and run them through something like ytnef_smtpd.py (please note, that this might be legally problematic for you as a service provider, opening an e-mail, even automatically, is a violation of communication privacy rights in many jurisdictions). Or, if the legal problem is too big or can't be solved through an local server installation (e.g. because there is no server running 24/7), you're left with either using Outlook (probably what Microsoft intended) or you can use a plug-in/add-on for your client. I've tested the LookOut add-on for icedove and it seems to work well. There are of course plug-ins for many other clients, but I can't honestly tell whether they work or not.

[UPDATE 2011-09-20]: Fellow Debian Developer Josselin Mouette wrote me, that Evolution is capable of reading TNEF-encoded e-mails out of the box, but he also said that [TNEF e-mails should] be banned by all means.[/UPDATE 2011-09-20]

Now, before I close, please always try to convince the sender/postmaster to fix their setup. It has only advantages: text/plain e-mails are smaller, they're less likely to contain malicious code (i.e. no parts hidden away from the virus scanner on the mail server (amavis can read TNEF e-mails, if libconvert-tnef-perl is installed)) and all recipients can open the e-mails with the client of their choice.

After a little pause, I thought I add another entry to my ongoing tips series. Today we'll get rid of the black bars you can most likely observe on a widescreen display, when playing a video DVD with MPlayer.

This little post assumes that you've already inserted the DVD you'd like to watch, your MPlayer setup works with dvd:// style addresses, you know which title from the DVD you want to watch (the examples will use the first title) and you know your monitor's aspect ratio (the examples uses 16:9).

Now all that is needed are the following two steps:

1. Detect the cropping parameters:

   mplayer -vf cropdetect -monitoraspect 16:9 dvd://1

   The previous line is followed by the usual MPlayer header and output. The film should start playing and after a few seconds you can press q (just wait until the detected values stop changing). Now there should be a few lines looking like:

   [CROP] Crop area: X: 0..719  Y: 76..499  (-vf crop=720:416:0:80).
   A:   1.5 V:   1.5 A-V: -0.000 ct: -0.018  38/ 38  5%  7%  1.0% 0 0
   [CROP] Crop area: X: 0..719  Y: 75..500  (-vf crop=720:416:0:80).
   A:   1.6 V:   1.6 A-V: -0.000 ct: -0.018  39/ 39  5%  7%  1.1% 0 0
   [CROP] Crop area: X: 0..719  Y: 75..500  (-vf crop=720:416:0:80).
   A:   1.6 V:   1.6 A-V: -0.000 ct: -0.018  40/ 40  5%  7%  1.1% 0 0

2. Play the film with the detected crop values and the correct aspect for the video material (4:3 for PAL and 3:2 for NTSC):

   mplayer -vf crop=720:416:0:80 -monitoraspect 16:9 -aspect 4:3 dvd://1

Of course you can add any other options to the invocation as usual, though you only need to add those to the second invocation (e.g. select the correct audio stream or start in fullscreen mode). Also, you might want to set the monitor aspect permantly in your MPlayer configuration (just add monitoraspect = "16:9"), as the monitor rarely changes for the average machine /etc/mplayer/mplayer.conf.local is probably the best place (make sure your /etc/mplayer/mplayer.conf includes that file at the end).

Now you should be able to enjoy all video DVDs on your widescreen display without black bars at the top and bottom!

[UPDATE 2011-10-26] The story has developed.[/UPDATE]

Recently I was talking with somebody about the WEB.DE toolbar, and today I finally got around to look something up I was told then. And while I searched for the information on the download page for the WEB.DE toolbar, I stumbled over the download URL for the installer:

http://wa.ui-portal.de/webde/webde/s?produkte.browserdownload.link.download.ff7&bd_mc=undef_undef&ns_type=pdf&ns_url=http://dl.web.de/browser/firefox/WEB.DE_MFF7_Setup.exe

There I was magically attracted by the ns_url parameter, because it smelled like something where you could just pass any URL along. And indeed you can: http://wa.ui-portal.de/webde/webde/s?produkte.browserdownload.link.download.ff7&bd_mc=undef_undef&ns_type=pdf&ns_url=http://bundestrojaner.net/inhalt-bundestrojaner-gratis-download-3.html. That should redirect you to http://bundestrojaner.net/inhalt-bundestrojaner-gratis-download-3.html instead of http://dl.web.de/browser/firefox/WEB.DE_MFF7_Setup.exe.

This is a serious flaw, as it might allow an attacker to request a username and password combination from an unsuspecting user. With a harvest page designed to look like another WEB.DE page you should have a high return rate. This is, by the way, a flaw on the OWASP Top 10 (2010 edition).

I've informed somebody working for United Internet and expect the bug to be resolved pretty soon, hopefully it won't work anylonger when you read this.

Reading Sylvestre Ledru's announcement, that sun-java6 was removed from the archives, I'd like to point out, that the recommended immediate purge of any binary packages built by sun-java6 should be postponed until you did have time to check, that important applications are working for you with the OpenJDK implementation.

I need to retain sun-java6-plugin until upstream bug #588 for icedtea-plugin is fixed. If you have equal requirements (using ELSTER is required by tax law for me), make sure everything works with OpenJDK/IcedTea, otherwise you need to fetch the latest shipped version from snapshot.debian.org or install something directly from Oracle.

Now, as security issues were mentioned in Sylvestre's post, I'm NOT recommending to have sun-java6-plugin running in your browser on default. Just switch the Java plugins before you really need it. For Iceweasel you can (de-)activate plugins in the add-on manager's plugin tab. Apart from that I'd recommend to not surf with any scripting or plugins active at all, NoScript! is a great way to do this conveniently.

You might have read my recent post about an open redirect on WEB.DE's homepage. Now, as it turns out, the spread of this particular bug is far wider, than I first thought.

After posting the previous story, I was surprised, how long it's taking to fix the bug. Then I remembered, that the domain for the redirect wasn't web.de but ui-portal.de. Now, knowing that WEB.DE is owned by United Internet doesn't make it that suspicious, but I was intrigued enough to check what the DNS said about the domain. And, as it turns out, the domain points to an IP owned by comScore/Nedstat:

$ dig @85.214.73.63 wa.ui-portal.de

; <<>> DiG 9.7.3 <<>> @85.214.73.63 wa.ui-portal.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51273
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;wa.ui-portal.de.               IN      A

;; ANSWER SECTION:
wa.ui-portal.de.        10      IN      CNAME   wa-ui-portal-de.sitestat.com.
wa-ui-portal-de.sitestat.com. 30 IN     A       77.72.113.50

;; AUTHORITY SECTION:
wa-ui-portal-de.sitestat.com. 83 IN     NS      glns03.sitestat.com.
wa-ui-portal-de.sitestat.com. 83 IN     NS      glns02.sitestat.com.
wa-ui-portal-de.sitestat.com. 83 IN     NS      glns01.sitestat.com.

;; ADDITIONAL SECTION:
glns01.sitestat.com.    24      IN      A       77.72.113.10
glns02.sitestat.com.    24      IN      A       77.72.115.10
glns03.sitestat.com.    24      IN      A       87.249.105.10

;; Query time: 63 msec
;; SERVER: 85.214.73.63#53(85.214.73.63)
;; WHEN: Wed Oct 26 14:27:54 2011
;; MSG SIZE  rcvd: 202

All that is missing now, to confirm everything, is a whois for 77.72.113.50, which shows Nedstat B.V. as the owner (Nedstat is a part of comScore since 2010).

That was, when I realized, that there are probably a lot more sites offering such links, and as a search for inurl:ns_url=http shows (I'm not yet linking to a result page, but you can look it up yourself, of course), that assumption was correct. There are some big names like Siemens or the Bertelsmann Stiftung, using the click-tracking service by Nedstat, returned by the search. That is a problem, as links looking like they're pointing to a trustworthy site/domain have a high potential for being clicked. Most people won't notice the open redirect, especially not, if the attacker took some time to design a target page, that looks like the original (most likely for phishing) or let the redirect point directly at some installer for malicious software or both.

I've informed Siemens and the Bertelsmann Stiftung too, but I can't inform every affected website operator, so I've informed comScore/Nedstat directly and hope, they'll fix the issue in a timely manner. And not less important: inform their customers immediately.

Maybe you've already heard, that Google is starting to charge a fee for using the Maps API (Google may decide you're an non-profit organization and waive the fees). That is, in my opinion, Google telling you to look for better alternatives. And thanks to the awesome effort of the OpenStreetMaps community, there is such an alternative.

Thus today's addition to the mini-tips series will tell you, how you get an OpenStreetMaps-powered map on your website.

1. First you need to determine the coordinates, where you want to center, the map. You can do this with OpenRouteService.org. Just search for the address, right-click on the marker highlighting the result, and set it as e.g. your start point, that'll give you the coordinates in the start field on the left. Alternatively you can just move your pointer over a place on the map and have a look at the lower right corner, where the current coordinates for the pointer position are displayed.
2. Then you need to add a few things to the website, where the card is to be shown:

   • Include the OpenLayers script in the <head> of your webpage: