Posts Tagged 'ubuntu 8.04'

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…)!

Advertisements

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??

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??

Eight tips for a robust Ubuntu Hardy installation

It’s been a while since I wrote stuff here – ironically I thought it was cool to get my own domain name, and then I ended up having too much fun on the GNU/Linux blog I also started. This should actually also go on the other blog, but I really wanted to write something here :)

Besides, the more Ubuntu buzz on blogs, the better, right? With the release of Ubuntu 8.04 this week, it couldn’t be a better time.

About these tips

If you’re new to the GNU/Linux operating system, this may not be for you. Nothing I’m mentioning here is complicated in any way, but it sort of assumes you’re reasonably comfortable finding your way around in Ubuntu. Instead, you may want to check out the Ubuntu website and, if you’re looking for help, the Ubuntu Forums.

The tips I’m listing here are a personal collection of things that I think might make your Ubuntu system that little bit more robust. That’s not only in a security or stability sense: I’m also thinking about protecting my system from my own tweaking and fiddling around (which you’ll inevitably do if you want to learn new things).

The tips here are most simple to act on at installation time, so I’ve sort of turned this into an installation advice list. Quite a few pointers here point back to my own writing of this week, for which I apologise. My middle name is not Narcissus, but those pieces needed a good overview to connect them, and this is it.

Preparations

1. Check hardware compatibility before you start – this is still a big problem for all free-software operating systems. By now, it’s no longer a problem the developers can really help: all hardware could be made compatible if some manufacturers weren’t so secretive about the devices they make. As a sad result, the Ubuntu Forums are full of reports on (mostly) hardware compatibility problems.

No general recommendations here, but you’ll want to be prepared. If your wifi chip vendor is an ***, it’s helpful to know which packages and other files you need to have at hand. A few pointers: HardwareSupport on the Ubuntu wiki pages, TuxMobil, UbuntuHCL.org.

2. Download a disc image using BitTorrent – it takes some persistence to find the page with the torrent links for Hardy if you start from the Ubuntu frontpage. I presume they don’t want to confuse new users. Of course, using the torrents takes some load off the main servers, helps some people, and (best of all) it’s likely faster too (especially now, just after the release date).

If you’re interested in the tips in the next section, you’ll want the alternate installer disc image.

Installation

Almost all choices you make during installation are revertible later on. I mean, you can always change your username, clock settings (local or UTC time?), which packages you want. One thing is a bit more tricky to change later, and that’s partitioning your disk(s). The alternate installer gives you some neat extra partitioning options which I want to highlight here.

3. Logical Volume Management – creating your file systems as LVM logical volumes gives you a lot more flexibility. The LVM HOWTO has a section “Benefits of Logical Volume Management on a Small System” which however doesn’t mention one of its cooler features: snapshots. LVM snapshots allow you to keep an image of your file system frozen at some point in time.

That will be useful for at least one thing: six months from now, you can take a snapshot of your root file system, upgrade to Ubuntu 8.10, and if it didn’t work well (proprietary video and wifi drivers seem to have regressions to no end), you still have a working 8.04 snapshot you can boot to use until you fixed the upgrade.

The other useful application for the home user: it’s easier to create consistent backups from a snapshot. Now, while you’re at it, I’d combine LVM with…

4. Disk encryption – reusing the rationale from this post: “if someone steals your laptop, you’ll worry a lot less about them getting access to your email and other important accounts (think browser cookies…). In case you’re wondering why the user login won’t protect you: anyone with physical access to the machine – like a thief – can just reboot and start in single-user mode, thereby getting root user privileges. Not so with an encrypted disk”.

Be sure to make frequent backups though – recovering data from an encrypted disk can be hard.

Post-installation

5. Set up version control on your configuration files – before you stroll off to your favourite geek forum and take advice from everyone and their dog to alter all kinds of stuff in configuration files under /etc, you might want to ensure that you can always get back what it said originally. Don’t get me wrong, I also try risky stuff people I’ve never met recommend to me, but I really like to keep track of those actions, too. So here you go: version control on /etc using Bazaar. As explained there, version control gives you some cool flexibility that a simple backup wouldn’t.

6. Installing additional packages: use aptitude – actually that’s not really what I want to recommend. There are quite a few APT front-ends and it’s worth checking out several, especially if you’ve never looked beyond Synaptic. So check out a few, and then decide that you like aptitude :)

Aptitude runs in a console, and has both a direct command line mode and an interactive mode. Its killer feature for me: it tracks which packages were only installed as dependencies of a package you really chose. So if you ever tell it to remove that package, it will remove its dependencies, too.

Here’s a more elaborate discussion of the tool’s merits.

7. Keep non-repo software under /usr/local – just one more quote of my own writing (promised!): “To ensure that the package manager doesn’t interfere with software you installed “manually” (i.e. not through dpkg, apt-get, aptitude, synaptic, …), there’s an article in the Filesystem Hierarchy Standard that says everything you install manually should go into /usr/local (or /opt, actually) and not directly into /usr.”

If you want to make it easier for yourself to enforce that policy, without reading every line of every install script you use, you might like to check out that post. It’s about installing software on /usr/local without full root privileges.

8. Secure your web browser – with properly set user permissions, should you now bother with such things as a firewall and a virus scanner on your desktop (laptop) machine? Probably not. (Although I wonder if everybody is sudoing all the time, won’t somebody exploit that at some point? How high are the chances that a malicious script that’s trying to use sudo hits you while a sudo session that you started is still open? Not sure how that would work, but then I’m not a seasoned malware designer).

A lot of executable code that you rake in as a normal user is stuff coming through your web browser: scripts on web pages, but also (Firefox) browser plug-ins. Malicious code in those can only destroy stuff that you have write permission for, and can only collect information that you have read permission for (which is typically most of other users’ data!), so decide if you think that’s still worrying. A good start for securing Firefox is this overview at Ubuntu Forums.

Wrap up

That’s all I could produce in my spare time this week… hope it’s useful. I’d love to hear if it is. Commenting here does not require you to leave any contact details (hint!). Thanks for reading.

First thing to do on a fresh Ubuntu Hardy installation

Edit – although of course I love to have some readership for this post, I should say that you might want to check out this cooler solution instead: etckeeper is a package that was designed to do all the stuff I’m describing here… thanks to Daniel for his comment!


Well, to be absolutely honest, it was the second thing I did. The first thing after installing was fixing the wifi drivers. But straight away after that, I set up version control on the configuration files in /etc. Basically, that stops you from making a mess out of your configuration files. Sounds good?

Thanks to the guys at Canonical (who are also the ones backing Ubuntu), version control has become easier than ever: with Bazaar it is so easy to set up that I basically have version control for anything I’m working on nowadays. If you know about revision control already, probably you see the use of it and could skip the rest of this post… or you could stick around and see how effortless things become with Bazaar (bzr).

Edit – probably superfluous, but just another word of warning: don’t do anything just because I did. There’s a lot of sudoing going on below here, so you could do damage to your system. Don’t trust a random blogger. Read the man pages, read the online documentation.

Rationale

Before I show how to set it up, let’s see how you’d use it. Every time you’ve made significant changes to /etc (let’s say you installed new packages, or created new users, or reconfigured your acpi-support settings, or anything), you create a “checkpoint”, or in version control lingo: you commit a revision. That could be as simple as two lines in a terminal (and I’m sure you can get a GUI for this too):

cd /etc
sudo bzr commit -m "short comment on what you've done"

Well, actually, if you had installed new software you might not know what had changed. So you’d have a few more lines:

cd /etc
sudo bzr status #tells you which files are new or have been changed
sudo bzr diff filename #tells which lines in "filename" were just added/removed
sudo bzr add . #puts any new files under version control
sudo bzr commit -m "short comment on what you've done" #sets a checkpoint

Still, not too scary, I’d say? Later, you can review what you changed before:

cd /etc
sudo bzr log #shows comments, date, and version numbers of committed revisions

You can go back to any revision now, say e.g. to number 3:

cd /etc
sudo bzr revert -r 3 #sends state of /etc back to revision 3

Here’s the real kicker though: you can also revert changes within specific files, between any two revisions. That is, you don’t have to send the whole file back to it’s old state, bzr can just remove/reinsert the lines that you’re interested in and leave all other (later!) changes to the file intact. This is what really makes revision control more powerful than plain and simple file backup.

An example: you’ve changed /etc/X11/xorg.conf to use the proprietary fglrx video driver. You removed all the tweaks you had put in before for the open-source driver. This change was part of revision 4. Some days later, you put in all kinds of tweaks for your synaptics touchpad. That was revision 9. Yet some time later, you added wacom tablet settings. Revision 15. But now, you decide you want your open-source driver back… If you’d restore the backup, you’d lose your synaptics and wacom settings. With bzr, this is how you do it:

cd /etc
sudo bzr merge -r 4..3 ./X11/xorg.conf
sudo bzr diff #shows the changes, just to check if it was ok
sudo bzr commit -m "went back to the open-source driver by undoing rev4"

That’s it. Really. Effortless. All your fancy tweaks for the video driver have now been put back in place, but the changes you made for the input devices have not been removed. (In case you’re interested: the bzr user guide calls this reverse cherry-picking).

Stating the obvious

This is of course useful for a lot more things than just /etc. Revision control works well on anything that looks like text. Have a look at the files in your ~/.gconf directory: they’re in xml format. Now if you tweak the looks of your Gnome desktop and applications, bzr can track what changes you made. And restore older settings later.

Setting it up

Installing bzr is of course as easy as

sudo aptitude install bzr

…or apt-get if you want to be old-skool ;) Now, I had a look around the net to see if anyone else used bzr for this, and found this – frankly, that’s pretty much what I’m about to type up here. I’ll give it a spin of my own but I’ll also skip a few bits here, like how to back up your bzr repository and how to send yourself messages in case you forgot to commit your changes to the repository – so see russel.rucus.net for those parts.

Bringing everything in /etc under version control is as simple as

cd /etc
sudo bzr init #creates a version control repository under /etc/.bzr
sudo chmod go-rwx .bzr #only root may see it
sudo bzr add . #adds everything in /etc to it
sudo bzr commit -m "freshly installed state of Hardy"

You need to use superuser permissions here because you’re not allowed to read everything as a normal user (think /etc/shadow and such). As you’re storing those sensitive files in the bzr repository, you don’t want anyone to read it, hence the chmod. As a result of this chmod, you will now always need to use sudo – otherwise bzr cant access .bzr/.
Now, bzr by default is set to skip some files, for example something like apt/sources.list~ is a previous version of apt/sources.list and will get skipped because of the tilde. Of course you want to check that bzr doesn’t accidentally skip anything important, so

sudo bzr ignored #prints all skipped files

If you see any file there that you did want to add, you can add it by explicitly typing

sudo bzr add sources.list~ #you don't want that, but it's an example

Basically, your /etc directory is now under version control. You can very easily check for changes with

cd /etc
sudo bzr status

as I said before, and if you’ve installed new software and new files appear in /etc, you can now do

sudo bzr add . #adds all the new files
sudo bzr commit -m "installed awesome new package"

A few more things you should note

There may be some files that you actually don’t want or need to put version control on. You can create an ignore-list for those files, so that bzr will skip them when you say “add .”. Guess what the command is?

sudo bzr ignore ./mtab #bzr will ignore mtab from now on

This actually creates a file /etc/.bzrignore with “./mtab” in it. The leading ./ means you only want to ignore /etc/mtab, not any mtab found somewhere under /etc.

Now, you actually already added mtab in the section above, so there’s no point ignoring it now – it’s already under version control. To take something out of revision control:

sudo bzr remove --keep mtab

Here, –keep means that you don’t want to delete mtab. Otherwise, bzr might think you want to get rid of the file, while you just want to take it out of revision control. So far, I have done this on four files: ./mtab, ./adjtime, ./resolv.conf, ./ld.so.cache – these are all files that get generated automatically and are changed by the system (on a standard Hardy install, resolv.conf gets changed by network-manager). After running “remove –keep” on them, you’ve got something to commit again: removing is a change, too.

Second thing. If you installed bzr and immediately used it as superuser, something will be funny in your home directory now: the ~/.bazaar directory will be owned by root. If you use bzr on other things later on, without sudoing, that will generate errors. So

sudo chown -R yourname:yourname ~/.bazaar

In this .bazaar directory you will find a file .bazaar/ignore which specifies the patterns that are ignored by default (like the tilde). Change it as you like.

Finally, if you want to be more verbose in your commit messages, you can leave out the -m and the comment, and bzr will open an editor for you. Type your essay, then save and exit to complete the commit. But by now I’m really just telling you stuff you could read in the Bazaar User Guide – an excellent piece of documentation. Have lots of fun!

PS: if you’re a control freak like me (hey, you’ve read this dreadful piece all the way down), you may also like the previous post on strictly separating repo and non-repo software.