Dell shipping revamped Ubuntu 8.04 with the Mini 10

Update: it looks like I’m sucking in a lot of search engine traffic relating to Poulsbo / GMA500 on Linux – that was unintentional because there’s no information here. Please look at Adam Williamson’s work on a native driver for Poulsbo instead.

Update 2: I came across some Ubuntu-specific notes which should be useful too.

—

I was a bit surprised by Dell’s announcement just now: it seems they’ve gone through some real efforts to make Ubuntu 8.04 look all 2009ish on their latest netbook entry-level notebook. Let me try and be all 2009ish too, and include some of their Flash-terrorism YouTube footage:

Don’t worry,  I haven’t suddenly become a sucker for fancy “iconography” (apparently that has a whole different meaning “in the office of the CTO” – don’t take this badly, Dell, I am a fan!), nor have I finally grown fond of NetworkManager, but seriously: WWAN support is pretty cool, and having it neatly integrated is even better.

Actually, I’m just really pleased to see what importance Dell seem to be assigning their Ubuntu programme these days. This little cheapling has Intel’s Poulsbo chipset (just like the Mini 12), which is great for power consumption, but apparently a real chore when it comes to Linux support. As far as I’m aware, no other vendor is even trying to support it. In addition, also to keep the price low, there’s the ever troublesome Broadcom wifi chip, “official” Linux-support for which was supposedly also negotiated by Dell. I’m guessing there was no way they’d get all that working on 9.04, but to make up for that they backported the NM improvements and updated the “iconography” (sorry).

I’m just saying, that’s a lot of effort when you have a business partner called Microsoft that’s giving you Windows XP basically for free…

Ok, enough Ubuntu/Dell fanboyism for one day. Good night!

P.S.: Rik – if you happen to read this – I didn’t know they had a 6-cell battery coming (I told the guy to get a Samsung instead…)!

Playing with Windows 7 beta in Ubuntu Hardy

…using kvm, that is. But wait, you say, why come from freedom and subject ourselves to this:

Wait, what??

The thing is, after reading that the SABDFL himself seems to like the recently released Windows 7 beta 1, I somehow felt compelled to try it out, too. Like Shuttleworth points out, it’s nice to have some competition, and of course it doesn’t make sense not to be aware of what that competition looks like.

While I won’t have time in the next few weeks to play with this beta a lot, now was the time to download it, because MS are taking it offline on 10 February. You’re provided with an activation key for the installer, and the installed system remains accessible until sometime in August. In case you’re getting curious too, the download page is here – note that the iso to download is rather substantial at 2.5GB. To avoid too complicated issues, I opted for the 32-bit version.

On the Guest Support Status page on the kvm wiki I found an entry stating that Windows 7 has been tested on the amd64 architecture, with kvm-62. Guess what? That happens to be exactly the version of kvm that’s in the Hardy repositories. It’s actually been a while since I installed kvm (note that kvm needs hardware support in your CPU and your BIOS by the way, otherwise look up qemu, but I’m not sure if you want to run something big like this in that case), but off the top of my head you can install it in Hardy (please correct me if I’m forgetting anything crucial) by a simple

sudo aptitude install kvm
sudo adduser username kvm #replace username

and then a reboot (well, you could go without rebooting and then modprobing etc, but this is the brief version…). The adduser line allows you to use kvm as a normal user. As always, I’d like to add that you should know what you’re doing when running with root privileges (sudo), and at the very least read the man pages to any commands pasted from some random guy’s blog… there, I said it again.

The kvm wiki entry also lists the settings with which Windows 7 was tested; there’s one issue here and that is that the usb-options to kvm don’t work on Hardy. So, omitting those, we can install with the following two lines:

qemu-img create -f qcow2 win7.img 15G
kvm -localtime -std-vga -m 2048 -cdrom win7.iso -boot d win7.img

I think I’ll skip explaining the switches – seriously, read the man pages. Well, actually, the kvm man page doesn’t contain much, so look at the one for qemu instead. Obviously, you can drop the -cdrom and -boot options on subsequent runs.

The installation ran buttery-smooth here, but then I’m a bit spoiled with an Intel T8100 CPU and 4GB of RAM. Anyway, I think it was mostly a disk-performance limited affair (it’s all on an encrypted LVM volume on a slow laptop harddisk…), but still I was looking at a completely installed and also fully patched system (yes, kvm/qemu takes care of passing-through your network connection) within 45 minutes. At this point, the disk image takes up 5.1GB of space.

Finally, although I took umpteen screenshots during installation, I now decided I won’t put them up here; partly because I might get shot by the users of ubuntuweblogs.org (“Hello all, I’m the new guy who just joined, and I’m plastering your RSS readers with Windows screenshots… ;)”), partly because the web is flooded with Windows 7 screenshots already, and partly because I’m hoping you’ll try it out for yourself. Have fun!

—

Edit: it seems I haven’t been keeping track of my friends’ feeds properly. Shawn wrote about this already over a week ago. Also, he did post his screenshots…

Using the built-in microphone on a Latitude D630 in Ubuntu Hardy

Just briefly (I’ll hopefully add some more about my new machine later):

The Intel HDA sound drivers that ship with Hardy work just fine on this machine, but if you don’t know what all the sliders do (I had absolutely no clue) you’ll have a hard time getting any signal from the built-in microphone.

After some fiddling I figured out that the Capture screen of alsamixer gives you access to the appropriate controls. You need to set one of the Input sources to “Front mic”, you need to up the Mux on that one a little, and you need to make sure that the channel says “Capture” below it (in red, leftmost column in the image below) – otherwise it’s actually muted.

Now if you want to know a little bit more on what all this is about: I found a few clues here. Apparently Mux controls something like an analog pre-gain for the AD-converter, and the different channels on display in the Capture menu reflect the fact that the Sigmatel chip offers multiple AD-converters.

You can verify the proper operation of the mic using arecord and aplay like so (where hw:0,0 refers to the channel I activated as shown in the screenshot):

arecord -f cd -D hw:0,0 -d 5 test.wav # now say something...
aplay test.wav

Another thing I have to point out is that I have no idea if this is a best practice to getting it working right. Ubuntu Hardy uses something called PulseAudio and I haven’t had time to educate myself as to where that fits into the whole audio stack. Should I not fiddle with things through ALSA anymore? There’s more reading on all the different audio components at Linux.com but I haven’t had time to really get a clear picture of matters so far. Would love to hear from anyone who knows more about this.

In case the follow-up doesn’t come soon enough, do prod me if you need more info on the Latitude. One hint: if you’re ordering, phone them up and insist that you want Intel wifi (that’s not configurable in the webshop sometimes) and not the Broadcom stuff.

Compiling and repackaging vpnc with libssl support

Let’s start with some background (skip if you don’t care about that). I moved offices last week, and the new place requires me to interface with a Cisco VPN solution to get internet access. Now, I have to be fair and commend Cisco for providing a source tar-ball of their “vpnclient”, which should in principle allow users of any GNU/Linux distribution to connect to their system. I’m saying in principle, because I didn’t actually try their client. I can attest that the code compiles cleanly after applying a few patches, but after compiling I actually decided not to run the installation.

The thing is, the Cisco vpnclient is built as a kernel module, and I really dislike these manually maintained modules that are requiring attention at every kernel upgrade. Looking at the install script, you can of course expect all these things getting plugged into the init system to load the module. That’s just more intrusive than necessary – as vpnc demonstrates.

In addition to being very unobtrusive – a single, lightweight, userspace process – vpnc of course comes served to you through that wonderful package manager (yes, this is my favourite topic, sorry). Automagically. Or, almost.

One tiny problem: at least on Ubuntu Hardy, vpnc is by default provided without support for “hybrid authentication“. For that to work, vpnc needs to use functionality in libssl, which would make it incompatible with the GPL, apparently (so yeah, it’s not a bug, it’s a feature!). As I understand it, it is ok for end users to connect the two, but you can’t distribute it that way.

So we need to compile vpnc with libssl support ourselves. That’s not a problem: you can check out the Ubuntu-prepared source code using “apt-get source vpnc” (don’t you just love that!) to your current working directory. As the readme-file tells you you will need to have libgcrypt-dev, and now in addition you need libssl-dev (that took me a while to figure out: why isn’t it called libopenssl-dev?). As is clearly documented, there are just two lines in the Makefile that need uncommenting to make your GPL-incompliant version of the tool. That’s about it (run make – I’m assuming you have the build-essential virtual package installed).

Now the part that I just had to be fussy about: how do you distinguish your custom version from the current and future repository-provided binaries? You probably want to put it under package management control (nice for dependencies and such), but if you just install it under the same version number, the package manager seems to want to replace your package by the repository version. At least, so did aptitude on my system. A bit of searching turns up lots of ways in which people solve this problem. It all depends what you want to happen when the repository gets an updated version.

In the end i decided that I want the package manager to suggest an upgrade when a new version arrives. I’ll most likely remember that I need to recompile at that time (and if not, well, I’ll find out soon enough :)). The easiest way to get that working properly is to enter your locally produced package under a different version number. In my case, I changed the version number from “0.5.1r275-1” to “0.5.1r275-1+ssl1”. This style of version naming should, according to the Debian policy manual, produce the desired upgrading behaviour: the current 0.5.1r275-1 version is considered older than our self-cooked package, but 0.5.1r276-1 or 0.5.1r275-2 would both be considered to be newer.

A nice way to have things set up correctly with little effort is to get a few more packaging tools: devscripts (which provides debchange), debhelper and dpatch (which are build-dependencies of vpnc), and dpkg-buildpackage (comes with build-essential, actually). You can read about the details of those in the Debian New Maintainers’ Guide, or in the Ubuntu Packaging Guide (a bit more hands-on perhaps). And they come with extensive man pages.

In the source code directory (one down from where you ran apt-get source), I ran

debchange -v 0.5.1r275-1+ssl1 # then entered sth. in the changelog
dpkg-buildpackage
sudo dpkg -i ../vpnc_0.5.1r275-1+ssl1_amd64.deb

… yes, we’re really done already! If you don’t like the “+ssl1”, you can also type “debchange -n” which produces version number “0.5.1r275-1ubuntu1” on my system – that should also do.

Many thanks to Kyle who mentioned vpnc to me (I wouldn’t have known, and would be stuck with an ugly Cisco vpnclient on my system now), and who as a result had to endure my bugging him a million times to get me more deb packages while I was still stuck connection-less….

Skype on Ubuntu 8.04 amd64

I know, I need to play a bit more with Ekiga and other VOIP tools. But for now I really just wanted to quickly fire up Skype, and with Ubuntu Hardy it has become quite a bit simpler than before to install it (the 32bit executable that is) on an amd64 system.

Mistrusting as I am, I didn’t at first believe that it could be as simple as this Ubuntu Forums How-To promises. Basically it says you need just three commands (and to give away the conclusion – it’s true!):

sudo apt-get install ia32-libs lib32asound2
wget -O skype-install.deb http://www.skype.com/go/getskype-linux-ubuntu
sudo dpkg -i --force-all skype-install.deb

Now I’m fine with the first two; obviously, you need the skype package, and you’ll need some basic 32bit libraries to run it with. But “–force-all” is a bit drastic, and I really wanted to know what warnings and errors I’d be missing out on. So let’s see:

$ sudo dpkg -i skype-debian_2.0.0.68-1_i386.deb
dpkg: error processing skype-debian_2.0.0.68-1_i386.deb (--install):
 package architecture (i386) does not match system (amd64)
Errors were encountered while processing:
 skype-debian_2.0.0.68-1_i386.deb

Unsurprising. But instead of now forcing everything, let’s just force it to accept the architecture:

$ sudo dpkg -i --force-architecture skype-debian_2.0.0.68-1_i386.deb
dpkg - warning, overriding problem because --force enabled:
 package architecture (i386) does not match system (amd64)
Selecting previously deselected package skype.
(Reading database ... 103178 files and directories currently installed.)
Unpacking skype (from skype-debian_2.0.0.68-1_i386.deb) ...
dpkg: dependency problems prevent configuration of skype:
 skype depends on libqt4-core (>= 4.2.1); however:
  Package libqt4-core is not installed.
 skype depends on libqt4-gui (>= 4.2.1); however:
  Package libqt4-gui is not installed.
dpkg: error processing skype (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 skype

Right. I thought this was a static build? Why does it depend on that QT stuff?

Anyway, this is where I realised that when you set –force-architecture dpkg still tells you what objections it would have had otherwise. So we may as well –force-all and get on with it:

$ sudo dpkg -i --force-all skype-debian_2.0.0.68-1_i386.deb
dpkg - warning, overriding problem because --force enabled:
 package architecture (i386) does not match system (amd64)
(Reading database ... 103313 files and directories currently installed.)
Preparing to replace skype 2.0.0.68-1 (using skype-debian_2.0.0.68-1_i386.deb) ...
Unpacking replacement skype ...
dpkg: skype: dependency problems, but configuring anyway as you request:
 skype depends on libqt4-core (>= 4.2.1); however:
  Package libqt4-core is not installed.
 skype depends on libqt4-gui (>= 4.2.1); however:
  Package libqt4-gui is not installed.
Setting up skype (2.0.0.68-1) ...

Configuration file `/etc/dbus-1/system.d/skype.conf', does not exist on system.
Installing new config file as you request.

If I had been more trusting, that would have worked straight away… Interestingly, Skype looks and works just fine despite the missing QT libs (well yeah, that’s what a static build is for). Who configured those package dependencies??