Ruarí's thoughts

Ok, let me start by saying I don't have a clear focus for this particular blog post. Really these are just some thoughts swimming around my head, but since it is late on Sunday and there is nothing good to watch on TV I thought I'd type them up anyway.

Read more...

The following are instructions for installing a second copy of Opera under KDE. Use these instructions for Gnome or Unity and these instructions for Xfce.

Read more...

When I joined Opera in January of this year I was given the option to pick the distro of my choice. I've distro hopped for a while but initially thought I would go with Ubuntu due to its popularity and the likelihood that a large percentage of our users would also be using it. As it happened, on my first day I needed a working machine almost straight away and since I had a Mandriva CD to hand (I got it free with a magazine I had picked up the day before), I figured why not?

Indeed it turned out that I quite enjoyed Mandriva but I soon realised it was not as simple as picking a single distribution. When I initially started going through the Linux/UNIX bugs I noticed (unsurprisingly) that certain bugs will only show on certain distros, certain OSes, certain architectures or only with one version of Qt.

Read more...

From time to time users ask me about getting more Opera Linux repositories. Recently I was asked about this in relation to us providing .rpm based auto updates of snapshots on the desktopteam blog, and I answered as follows:

Originally posted by ruario:

The debian packages are by far our most popular Linux download so they got a repository first. Additionally there is more that one rpm update system (apt-rpm, Urpmi, Zypper, Smart Package Manager, etc.), and if you start considering non .rpm distros as well the multitude of update systems on Linux/UNIX gets ever larger (slackpkg, slapt-get, Swaret, pacman/Yaourt, Portage, etc.). As you can imagine the decision about what to support is therefore quite hard. Additionally, a number of distros (Gentoo, Arch, SUSE, Linux Mint, etc.) include us in their own official or community repositories anyway meaning that further repositories are often unnecessary. All that said, we are of course constantly reviewing this situation and we may add an rpm based repository in the future.

Also, it is worth mentioning that snapshots are not currently available on the debian repository anyway, so the users of debian based systems are also downloading these snapshots 'manually'. For more information on this read the "Why no snapshot auto-updates?" section of my recent blog post.

If you feel it is too 'manual', it would be fairly simple to knock up a shell script utilising wget (or curl) to auto grab your favoured package and install it (I'm not recommending you do so but it could be done), e.g. a script that does something like:

1. Pull the rss feed.
2. Extract the first blog post link and grab that page.
3. Extract the 'snapshot.opera.com/unix/....' link.
4. Parse the sub-directory and build number to work out the download link to your favoured package.
5. Grab the package and pass this to your package manager for install (or extract and install with the tar package).

This got me thinking about exactly how easy this would be to do and it occurred to me that I could probably do it with a one liner (albeit a fairly long and ugly one liner). Here is what I came up with after a just a couple of minutes thinking.

Edit: I recently wrote something a little longer that will detect your architecture and download the latest 10.6x+ snapshot build, unpack it and set and title pref so that you can keep track of which build is which:

http://people.opera.com/ruario/examples/testing/getsnap

Read more...

People often like to try new snapshot or beta builds of Opera but are cautious about messing up their main profile with a build that could be unstable. They need a way to get back to their previous state. I'll outline a few of ways this can be done. I won't list all possible ways, just three simple ones that I hope that most UNIX/Linux users could use without too much fuss. I should also mention that all of these methods have been outlined elsewhere both officially and unofficially, so I am not saying anything new here. If you are an advanced user don't be shocked if I teach you nothing new. However not everyone knows these methods and sometimes it helps to rewrite these things so that people get a more rounded idea of how it all works. Also by placing it on my own blog post, people can ask me directly about any part they are unsure of.

Method 1

The first method is as simple as they come (and should be done anyway, even when trying the other methods). The short version is: Backup your profile settings directory before you start testing!

If you are unsure about how to do this I'll explain (if you know how it is done skip to Method 2). By default the UNIX/Linux version of Opera stores its profile settings in the directory ~/.opera (where '~' refers to your home directory). To backup you simply make a copy of this hidden directory. This can be done via the GUI (graphical user interface) using a file manager such as Gnome's Nautilus. You just have to display hidden files first. In Nautilus this is done via 'View > Show Hidden Files' (or the keyboard shortcut ctrl+h). Similar options are also available under other file managers such as Konqueror or Dolphin. Simply copy the ~/.opera directory to something suitable like 'opera_profile_backup'. Alternatively on the command line you could issue a command such as the following:

$ cp -r ~/.opera ~/opera_profile_backup

Now you can update Opera to the latest test build and test away. When you have done testing either keep the new snapshot/beta, or if you want to downgrade then simply do so. If you suspect any issues with your profile following the testing you can restore it by removing the corrupted ~/.opera and renaming ~/opera_profile_backup to ~/.opera. Done ... simple!

Note: Before you can backup your profile settings you must shut down Opera first. If Opera is running you may not get a good backup as files made be in the middle of being altered.

Method 2

This is a slight improvement on Method 1 and as an added bonus it also a great way of testing if a suspected bug is really an Opera issue or some problem with your profile. Before you upgrade make a backup copy of your profile settings as outlined in Method 1. Just to be sure!

This method utilises the '-pd' switch. The '-pd' switch allows you to specify a different Profile (settings) Directory. As you now know, Opera stores its profile settings in the directory ~/.opera by default. To specify a different directory you simply follow the '-pd' switch with one of your choice and if the directory doesn't exist, Opera will create it!

To actually test a build using this method simply upgrade to the Opera package you want to test and run Opera from the command line using the '-pd' switch to specify a test directory, e.g.

$ opera -pd /tmp/opera_snapshot_test &

A directory called 'opera_snapshot_test' will be created as a sub-directory of '/tmp/' to house your profile settings.

If you wanted to test your current profile settings without messing them up, you could copy ~/.opera to /tmp/opera_snapshot_test first before running Opera with the '-pd' switch, i.e.:

$ cp -r ~/.opera /tmp/opera_snapshot_test
$ opera -pd /tmp/opera_snapshot_test &

When you are done testing you can delete this whole directory and either keep this build or downgrade as you see fit.

Note: Earlier I mentioned that the '-pd' switch can be used to test if a suspected bug is really an Opera issue or some problem with your profile. This is true because you can use it to specify a clean profile. Therefore, before submitting an Opera bug try testing first with the '-pd' switch set to some new unused directory.

Method 3

This is the cleanest and best method (in my opinion), as it does not require you to upgrade or even 'install' the version you want to test. Instead of using one of the RPM or DEB packages, download one of the tarballs instead. A 'tarball' is a tar archive, which is typically compressed with gzip or bzip2. Hence the relevant Opera packages will end with .tar.gz or .tar.bz2. The tar packages are primarily provided for users of distributions that don't use the RPM or Debian based package managers. These could be distributions like Slackware, one of the smaller cut down distributions like Puppy Linux or even a setup where an advance user has manually created their own install (such as Linux from Scratch). These packages require no package manager and include an install script to assist installation.

As no package manager is needed, these versions do not handle full dependency checking. That may sound like a problem but it really isn't. Typically everything will already be in place on a modern distro anyway. The only part that might be missing in some modern distributions is the correct version of the Qt toolkit. However even this is not such a problem. If you have installed Opera previously via one of the package managers then Qt will have been installed already. In which case you just need to know if it is Qt3 or Qt4 and then pick the appropriate tar package. Even if you don't know this, it still doesn't matter, just try the Qt3 version first and if that doesn't work try Qt4. If you are really stuck just pick one of the static or bundled packages as these include a copy of Qt, so that you don't need to install it! There is no real risk of picking the wrong version anyway as we aren't going to actually 'install' a new copy of Opera as you'll see in a moment.

The key to how this works is that in addition to the install script, another handy script is included with the tar packages. It is a 'wrapper' script that allows opera to run 'in place', without editing or updating files outside of its own directory. The wrapper script is called 'opera' and is in the top level directory of the untarred package. As no files outside of the test directory are touched, when you are done testing you can simply delete the whole directory to revert to your setup before you began testing. Cool eh?

It might help if I gave you an example. I will test in the /tmp directory. Here is how I could quickly test 10.00-4464.gcc4-qt4.i386 without messing up my setup:

$ cd /tmp
$ wget http://snapshot.opera.com/unix/snapshot-4464/intel-linux/opera-10.00-4464.gcc4-qt4.i386.tar.bz2
$ tar -xjf opera-10.00-4464.gcc4-qt4.i386.tar.bz2
$ cd opera-10.00-4464.gcc4-qt4.i386
$ ./opera &

This will start opera and the wrapper script will create a new (clean) profile as a sub-directory of /tmp/opera-10.00-4464.gcc4-qt4.i386 called 'profile', i.e. /tmp/opera-10.00-4464.gcc4-qt4.i386/profile

Bear in mind that although the wrapper script does not update any files outside of its home directory by default, you can force it to do so if you desire, e.g. if you wanted to test your regular profile you could do the following instead after the step of cd'ing into the opera-10.00-4464.gcc4-qt4.i386 directory:

$ ./opera -pd ~/.opera &

There isn't much point in doing it this way though as it would alter your main profile, which is the very thing we are trying to avoid! I just wanted to demonstrate that the '-pd' switch still works even when running the wrapper script. A safer way would be to make a copy of your profile first and test on that copy, i.e. after the step of cd'ing into the opera-10.00-4464.gcc4-qt4.i386 directory, you would do the following:

$ cp -r ~/.opera profile
$ ./opera &

Here are the full set of steps again:

$ cd /tmp
$ wget http://snapshot.opera.com/unix/snapshot-4464/intel-linux/opera-10.00-4464.gcc4-qt4.i386.tar.bz2
$ tar -xjf opera-10.00-4464.gcc4-qt4.i386.tar.bz2
$ cd opera-10.00-4464.gcc4-qt4.i386
$ cp -r ~/.opera profile
$ ./opera &

Then after I have finished testing I could do the following to clean up after myself:

$ cd /tmp
$ rm -fr opera-10.00-4464.gcc4-qt4.i386*

In this case not only was your main profile settings folder not altered, we didn't even have to upgrade the installed copy of Opera!

Ok, that is all for now. If you have any questions ask below and I'll do my best to help.