Ruari's thoughts

Recently there has been a lot of talk on the My Opera forums and in the comments of Desktop Team blog about Qt styles. Some of this discussion has been about setting the "-style" option to avoid crashes and separately other users questioning why the brand new "-systemstyle" option is not the default. So far I have not seen anyone put two and two together but these issues are related.

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

Since I have been playing around with cURL of late, I started thinking about how to use it to upload files to My Opera's file space. It can actually be done fairly easily, here some examples.

Note: The following examples will work on Linux, UNIX and Mac OS X. Whilst it is possible to achieve similar results on Windows, I have not covered this.

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.

Read more...

^{Disclaimer: I should start by stating that the text below represents my personal thoughts, and not official Opera policy. Working in the Opera testing department I often have to try out a range of different Opera builds on a number of different distributions, requiring various installs, uninstalls and upgrades. Depending on what issue I am testing at the time, I make use of a number of different methods for install. Some of the reasoning I touch on below. Wearing my employee hat for a moment the official recommended install and packages for non .deb/.rpm based Linux distributions, are the tar packages.}

Recently I saw the following comment from a Gentoo user on our snapshot blog:

Originally posted by DmitryIsaenko:

I don't actually know, where I can ask it.. but where I can get Gentoo overlay for Opera 10 or just ebuild for my OS?

Currently we only provide and support four package types for our Linux/UNIX users: .deb files for users of Debian-based systems (including Ubuntu), .rpm files for users of distributions like Redhat/Fedora, Suse, Mandriva, etc., .pkg files for our Solaris users and tar files for testing and users of all other systems. Even with the tar packages, these are fairly generic packages and not overly tailored to specific distros (e.g. they don't contain an install/ directory, with slack-desc and doinst.sh files for Slackware users).

We don't do this because we like users of other distros less but simply as an attempt to keep things manageable and keep the quality high, given naturally limited resources. The binaries contained within the provided packages are engineered to work with as many different distributions as possible. Indeed Opera fans often use them as a base to create new packages that work more naturally with their distribution of choice. Something we are very thankful for by the way! However, understandably this tends to be done only for big releases as it is entirely dependant on the time and dedication of the independant maintainer.

So ... What are users of non .deb/.rpm distributions supposed to do if they want to try out our snapshots?

Well, there are a couple of options. If you just want to do some quick testing, use the tar packages. If you want to install Opera then use the .... umm ... I'll get to that later, as I don't want to put you off so early in this blog post!

Testing a Snapshot: Part 1

If you just want to try the snapshots and don't intend to replace your main Opera installation, then you could make use of the third method I outlined in an earlier blog posting. You just need to ensure you already have the required dependencies pre-installed. On a modern (and up to date) distro the only one you are likely to have to worry about too much is the Qt toolkit. Install this via whatever method is appropriate for your distribution. Then download one of the tar files to an appropriate directory, extract and run Opera 'in place'. Here is a quick recap of how it is done, using the opera-10.00-4502.gcc4-shared-qt3.i386.tar.bz2 package as an example:

$ wget http://snapshot.opera.com/unix/snapshot-4502/intel-linux/opera-10.00-4502.gcc4-shared-qt3.i386.tar.bz2
$ tar -xjf opera-10.00-4502.gcc4-shared-qt3.i386.tar.bz2
$ rm opera-10.00-4502.gcc4-shared-qt3.i386.tar.bz2
$ cd opera-10.00-4502.gcc4-shared-qt3.i386
$ ./opera &

Note: This assumes you have installed Qt3 on Intel architecture (i386 or above). Alter the command as appropriate if you have a different version of Qt installed or use a different processor architecture.

In all likelihood this will 'just work', in which case skip to 'Testing a Snapshot: Part 2' of this posting (below). If it doesn't run try another package (e.g. gcc3 if gcc4 fails). If you continue having trouble and want to see a list of dependencies, run the following command within the extracted directory:

$ find . -print | grep opera.opera | xargs ldd

Once you are sure you have all the dependencies in place, try again.

Testing a Snapshot: Part 2

As I highlighted in my earlier blog post, running Opera in this way will cause a new 'clean' settings directory (profile) to be created as a subdirectory of opera-10.00-4502.gcc4-shared-qt3.i386 (i.e. opera-10.00-4502.gcc4-shared-qt3.i386/profile). If you would prefer use your main opera profile you can specify it with the '-pd' switch, changing that last line to:

$ ./opera -pd ~/.opera &

Note: This will however upgrade the main Opera settings/profile directory to a 10 style profile. If you intend to go back to Opera 9.64 then back up the directory first (see Method 1 in the that previous blog post if you are unsure how to do this).

Installing a Snapshot: The Background

If you really want to install an Opera snapshot, without first creating a distro specific package, then use one of our .rpm packages. Yeah, I said it, even though I know this will sound painful to the ear of many a Gentoo or Slackware user! Don't run yet, read the rest of this section first to at least understand my reasoning!!

Why the .rpm files? Well you could use one of the tar packages as they included an install script (called install.sh). However installing via RPM has one major advantage; it includes an easy way to uninstall. We have not yet written an uninstaller for the install.sh script. Therefore, doing it that way would mean having to manually remove all the files if you no longer wanted that copy of Opera. That isn't really very convenient for a release version (indeed we have a bug in our database about this: DSK-162946), but is even less ideal for snapshots given their nature (they receive very little internal testing). And why not the .deb files? Well sure, you could use these. I suggest the .rpm files because they are supported by almost all modern Linux distributions, even if the .rpm format is not used as the main package file format for that distro. This includes both Slackware and Gentoo, along with a multitude of others. In fact it even includes Debian based distros like Ubuntu! Now, I am not suggesting or advising you use the .rpm files for an Ubuntu install (though you could, I have tried it), I'm just saying it is possible!

If you are wondering why .rpm support is available on so many distributions I suspect there are two reasons. Firstly, the .rpm-based distros' historic dominance of the Linux landscape for a number of years (prior to the rapid emergence of Ubuntu as 'most popular distribution') meant that it was a very popular format, and therefore many other distros included it for the sake of compatibility. Secondly, the .rpm format is actually the Linux Standard Base (LSB) standard format. Distributions don't need to supply the RPM Package Manager to comply with LSB but they do need some way to deal with .rpm package installs (any package manager or package conversion tool that supports .rpm will suffice). That said, my own quick checks seem to show that the 'RPM Package Manager' is readily available for all major distributions, so I will use it in my installation examples below.

Note: If your distro of choice does claim LSB compliance but does not offer the RPM Package Manager, you will need to find out which package manager or conversion tool is supplied to deal with the .rpm format and do your own investigation of how it works.

Installing a Snapshot: Examples

Using the RPM Package Manager on a distribution that doesn't use it as the default package manager, means one of its key features doesn't really work that well. That feature is dependancy resolution. But if you are a Slackware user you will know that dependancy resolution is for wimps anyway! Also, you can still make use of the RPM Package Manager's dependancy checking, to help ensure everything is already in place prior to install, and to make sure you selected the right .rpm package in the first place. Here is the command to list a package's dependencies, using opera-10.00-4502.gcc4.shared.qt3.i386.rpm as an example:

$ rpm -qRp http://snapshot.opera.com/unix/snapshot-4502/intel-linux/opera-10.00-4502.gcc4.qt4.i386.rpm

You probably won't have to worry about this too much however. If you already found a tar package that worked for testing in the 'Testing a Snapshot' section above, just pick the equivalent .rpm package. Look at the numbers of the 'gcc' and 'qt' parts of the file name for the tar package that worked for you, to find the equivalent .rpm package.

After you have installed the RPM Package Manager on your distribution of choice, and made sure you have the right .rpm package and the required dependencies all in place, switch to root and install it as follows:

# rpm -Uvh --nodeps http://snapshot.opera.com/unix/snapshot-4502/intel-linux/opera-10.00-4502.gcc4.qt4.i386.rpm

Or if you prefer 'sudo':

$ sudo rpm -Uvh --nodeps http://snapshot.opera.com/unix/snapshot-4502/intel-linux/opera-10.00-4502.gcc4.qt4.i386.rpm

Note: Before issuing one of the above commands make sure you have removed any copy of Opera that is already installed by either install.sh or a native package manager.

To uninstall, execute the following as root:

# rpm -e opera

or via sudo:

$ sudo rpm -e opera

There you go, I hope that helps some of our users on non .deb/.rpm based Linux distributions get involved in testing snapshots!

Finally, after 10 is out, if a trusted Opera fan creates a package for your favoured distribution, feel free to remove the RPM installed Opera (and the RPM Package Manager itself) and switch to that. Or if you want, you can keep using the .rpm files! Isn't choice great on Linux? Have fun!

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.