Disclaimer: splashscreens should be avoided and programs should start faster. Some programs are just too slow so a splash screen is needed. Wouldn’t it be cool if all programs that showed splashscreens actually showed a splash matching the same theme as your desktop environment and your display manager? This might going to happen. Besides OOo, amarok and the gimp, which other programs uses splash screens? And where do they store their splash screens? Artists: This is also your clue to consider it. I don’t have much artist skills, but I have some ideas for the implementation. To show off something, I can start here: The plan is of course to make it as easy as apt-get install debianized-splashscreens to get debianized splash screens - and apt-get remove to get the original splash screens back. Oh - and of course easily to change for derivatives who wants some other styling.

I found some program today. It had a file, buttons.h which was autogenerated by:
uic -o buttons.h -embed buttons pics/attach.png pics/detach.png
Unfortunately, those pictures wasn’t included in the tarball - and as it is seen earlier, uic doesn’t generate endian-agnostic code. So what do smart man do now? Write upstream and wait? Could be done. Or figure out how to de-uic the header file. Qt and #kde4-devel to the rescue. #include "buttons.h"
#include "qimage.h" int main()

uic_findImage("attach.png").save("attach.png","PNG");
uic_findImage("detach.png").save("detach.png","PNG");

compiled with g++ -I /usr/include/qt3/ test.cpp -lqt-mt and now there is images that can be uic’ed.

Around 2 months have passed since 439832 was filed. It seems nothing has happened yet. We sooo want Debian armel in the next release.

Yay! We have now sewed fancy kde4-cds with the current state of kde4. Get them before your neighbor. Look at kde team homepage to find it. Reports welcome to debian-kde@lists.do Thanks to the rest of the team and to the debian live project who made this quite easy.

Christian, I am pretty sure that at least dato have access to pink themes. Jut try look at his screen shots in his blog post and in this piece of minirok software: minirok screenshots

According to a KDE packager in some Germany based distro:

Delivering Eventually, By Interminable Annihilation of Novelty


About the recent blogs on planet debian about debian maintainers, I guess I have a couple of comments also. About me: I am currently in "waiting for DAM" stage. I have been 10 months getting there and has now waiting for 6 weeks there. Looking at the DAM queue, people have been waiting in more than 6 months. What would make the process faster for me ? Getting processed by the DAM - and then the keyring maintainer is the obvious answer. A thing that would have made my 10 months at AM stage shorter would be if the "reward" for getting the AM stage done wouldn’t have been queueing in maybe to 6 months. It wasn’t like the most motivating factor for answering my AM. The fact that it took 10 months is mostly my own fault. So what am I trying to say here? Fix it it at the DAM stage (and maybe at the keyring stage also) and see people becoming DDs faster. Without lowering the barriers - except the barriers for the ability to stand in a queue. Debian Maintainers seems mostly like a ugly hackaround this. And I kind of find my self being in the target group for some of the use of Debian Maintainers. - and I am eagerly waiting getting processed in the DAM queue. And back to development Who wants to test & fix kdm on sparc ? (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433801)

Hi! Earlier I blogged about being too (little) paranoid. One of the comments was my unencrypted /boot on my harddrive. So I did something to it. Daniel Baumann told me some stuff at debconf about how to make bootable cd’s with grub - so I had to try to move my /boot to a cdrom instead. It works. A quick and dirty howto:
mkdir -p builddir/foo
cp -r /boot builddir/foo
cd builddir
genisoimage -no-emul-boot -boot-load-size 4 -boot-info-table -r -b boot/grub/stage2_eltorito -o boot.iso foo
and now you are not yet up and running. It looks like it, but you have to adapt boot/grub/menu.lst to make it boot from cd. First issue: boot fails with a “Error 29: Disk Write Error” - I wondered a bit and asked for help around and wondered a bit more why grub wanted to write to my harddrives in order to boot … finally solved it with help from the Super Grub Disk Page - it was the savedefault point of all my kernels. Removing that made it boot. So time to remove /boot and trust my cd. Which was a wrong decision. All my kernels had root=(hd0,0) so it kind of didn’t work. Changing this to root=(cd) did it - and removing (hd0,0) from my splashimage was also a bit nessesary. So after this, rebuild the cd again with the genisoimage command mentioned above and now I am up and running completely. And I of course have secretly marked the cd so evil people can’t replace it without me noticing it. So what’s next step in my tinfoil covered world ? SELinux? something else? I guess you know how to make comments. Feel free. /Sune

From my nightly irc log:

anonymous debconf attendee> i saw ari and i thought he was astronut.. then i read this badget and it was ari… :)


Some people have been missing me today. Sorry about that. Flying sucks. Plane from Copenhagen to Heathrow delayed one hour - so the hour I had to get from the first plane to the next plane was kind of … gone. Getting from Heathrow terminal 4 to terminal 1 required to take a bus, then be half hour in the queue to be allowed to join the queue to a extra security check. I got rebooked to a plane to EDI 3 hours later than my original flight, so I had a couple of hours to kill in the domestic part of Heathrow. The place where the gate is the most exciting place to be. British Airways was nice and offered me a cup of coffee and a piece of cake while waiting. Finally I was allowed on the plane with 16:15 planned departure. Somehow I was upgraded to first class which was nice - so I sat on first row next to the aisle. And then the pilot said we was delayed. Maybe we wouldn’t take off to until 20:20 or something … F*ck - was the general word amongst the people - even on business class. Somehow Heathrow got stuff sorted out and we departed 18:05 - only almost 2 hours late. Finally Edinburgh airport needed to find my luggage. It only took as long time in Edinburgh to get the luggage as the time it took from when we took off in heathrow … Finally - at 21:00 I walked into Teviot and got registered. \o/ A quick trip to the hostel to check in there was needed before 22:00 - so I was back at teviot 10 to 10. Open laptop. Get on internet. Try to get beer. The bar was just closed. *sigh* what a day. Hope it gets better tomorrow ;-) At least I have met a couple of nice Debian people - and it seems I have a bed.

• encrypted everything the way d-i does it (boot unencrypted - rest dm-crypt+LUKS). Check
• strong passphrase for encryption. Check
• seperate laptop ssh key. Check
• sshd only public daemon running. keylogin only. Check
• other stuff that ‘listens’ either killed or firewalled away. Check
• weak password on user account. hmmm
• screensaver/autolock after 3 minutes. Check
• sudo-to-root passwordless. hmmm

Am I on the right track? should I turn up my paranoia on the ‘hmmm’s or is it in general acceptable? Oh - and of course - a layer of security by obscurity is always nice. So let us throw dvorak keymap in also.

Bastian suggests on planet that we need to spend even more time on bikeshedding. Please. Let us move on. ps.: kblogger seems to be able to do the job.

Kblogger is a nice little applet for Kicker. As the smart reader probably already have guessed, this is very much related to KDE. Kblogger basically sits in the bottom bar with a small "Blog!" button. Click it, and you should be able to write a blog post easily. I wonder if it works - and if I end up with packaging it for debian. And a general note. You need to use the link for the remote api to your blog. Not the ‘main’ link. In the wordpress case, it is to the xmlrpc.php file. Is there other apps that does similar things ? or is kblogger the state of the art currently ?

kde 3.5.7 is now available in debian unstable on several architectures. Hopefully the rest will catch up when some bugs in other packages are fixed. Feel free to upgrade - but please please please - log out of kde and back in after you have upgraded and before you start filing any bugs.

Some people dislike cdbs because of its lack of documentation. Well - try this

It seems that the main source of the configuration variables is in the CMake-files.
Especially kdelibs/cmake/modules/FindKDE4Internal.cmake. Instead of the automake –sysconfdir, it seems you can use -DSYSCONF_INSTALL_DIR=/etc at least in kde. This does not seem to be CMake specific, but something kde4 has implemented in their build system.

A week ago, I started the long overdue task of triaging bugs reported on iceape/mozilla. When I started, the count was 364, duplicated excluded. I’m still not halfway through the bug list, but already the bug count is down to 263, as of today. That is about a hundred bugs closed or merged. I can’t believe there were still bugs so old but yet not merged to even older occurrences of the same bugs. Since it is easier to appreciate the effort with nice colors, I started graphing the bug counts for iceape. Sune Vuorela started some similar things for kde a while ago, so, thinking this could be useful for a whole lot more people than KDE and Mozilla maintainers, I also started graphing the bug counts for all packages. There is not enough backlog to have more than the last week, though. I’m a bit concerned about the fact that the RRD updates take a lot of time and may induce some load on gluck… Please DSA hit me if you want it to be moved elsewhere. Anyways, back to iceape bugs, the oldest bug I closed was #80787, which was actually fixed as soon as I first uploaded xulrunner a year ago. On the other hand, the oldest I didn’t close is #78654. There are some other winners that I’m amazed they’ve not been treated upstream in the last 6 years. Now, while I tried to correctly and conveniently tag these oldest bugs, I didn’t take the required amount of time to track them in upstream bugzilla. So if you, dear reader, have a little bit of time, I would really appreciate if you could go through the list of bugs* that are tagged upstream, but not yet forwarded and either find them in upstream bugzilla, or file them if they don’t exist there. * strangely enough, the raw=yes argument to the BTS doesn’t seem to work properly. You can get a raw list (with no ordering by status or severity) through the LDAP gateway with the following command line:

ldapsearch -p 10101 -h bts2ldap.debian.net -x -b dc=current,dc=bugs,dc=debian,dc=org '(&(debbugsSourcePackage=iceape) (debbugsTag=upstream) (!(debbugsState=forwarded)) (!(debbugsState=done)))'

Note the LDAP query is probably not optimal. You can add debbugsID at the end of the command line if you’re only interested in the bug numbers.

Sune Vuorela asks about how to secure important data such as GPG keys on laptops.

I believe that the ideal solution involves booting from a USB device with an encrypted root filesystem to make subversion of the machine more difficult (note that physically subverting the machine is still possible - EG through monitoring the keyboard hardware).

The idea is that you boot from the USB device which contains the kernel, initrd, and the decryption key for the root filesystem. The advantage of having the key on a USB device is that it can be longer and more random than anything you might memorise.

In my previous posts about a good security design for an office, more about securing an office, and biometrics and passwords I covered some of the details of this.

My latest idea however is to have the root filesystem encrypted with both a password that is entered and by a password stored on the USB device. This means that someone who steals both my laptop and my USB key will still have some difficulty in getting at my data, but also someone who steals just the laptop will find that it is encrypted with a key that can not be brute-forced with any hardware that doesn't involve quantum-computing.

Also coincidentally also on Planet Debian in the same day Michael Prokop documents how to solve some of the problems relating to booting from a USB flash device.

Dear Lazyweb Now it is my turn to ask you for help. How to manage your private keys (ssh, gpg, ..) securely when on the move with a laptop ? Storing the stuff in your homedir makes it kind of vulnerable if you lose your laptop (get stolen).
Storing your keys on a usb stick has the same problems if it gets stolen. A idea could be to store half the key on a usb stick and the other half of the key on your laptop.
Another idea colud be to encrypt your private keys on the laptop with another key stored on a usb stick. (Or the other way around) Other ideas? And is there already some well thought software written to do this ?
Or is the best advice to just to keep your usb stick really really close and hope for the best. /Sune

..with your next release - the Goatse Gibbon !