[proposal] The Opera browser

ruario · 2009-11-17 11:38:04

quarkup wrote:

im updating the opera-g4 PKGBUILD to have variables(switches) for the snapshot version
it has already switches for the beta version and bundled version
check it out (here) to see how to get the latest version from opera's ftps (betas/ final versions with or without the qt bundled)

Very nice, though I don't (yet) see the option for snapshots (however perhaps this is work in progress).

If you or anyone else want some quick tips about grabbing the latest snapshot, considering skimming through my earlier blog post if you have not done so already, to get a couple of ideas about how it might be done.

quarkup · 2009-11-17 20:14:32

I'll post it as soon as I have it done, possibly today.

deej · 2009-11-17 21:06:30

ruario wrote:

If you or anyone else want some quick tips about grabbing the latest snapshot, considering skimming through my earlier blog post if you have not done so already, to get a couple of ideas about how it might be done.

I've used this little gem I picked up somewhere...

wget -nv http://my.opera.com/desktopteam/blog/ -O - | grep snapshot.opera.com\/unix | head -1 | sed -e "s/.*\(http.*\)\" target.*/\1/" | wget -i - -erobots=off -r -nd -np -A gcc4-qt4.x86_64.tar.gz

( Nice code, ruario ) ... works a treat.

Deej

[EDIT]

Don't use this unless you are aware of the implications:

It's a snapshot - it may not work.
You may never return to Firerocks after using Opera

Deej

Last edited by deej (2009-11-18 06:27:26)

sr · 2009-11-18 03:10:38

Nice code deej - It certainly beats editing the PKGBUILD manually when there's a new release. I'm confused, though: why would it cause a problem with uninstalling? As I understand it, all it does is find the link to the current snapshot build, and download it, which fits well into the PKGBUILD, except for the file hash.

deej · 2009-11-18 06:25:53

sr wrote:

Nice code deej - It certainly beats editing the PKGBUILD manually when there's a new release. I'm confused, though: why would it cause a problem with uninstalling? As I understand it, all it does is find the link to the current snapshot build, and download it, which fits well into the PKGBUILD, except for the file hash.

I'd love to take credit for the code, but it is ruarios.

As to the dire warning about uninstalling by hand - head was firmly-up-arse there; I had a previous
discussion running thru' my head at the time Post amended

Deej

ruario · 2009-11-18 08:38:39

Hmm ... I have been internally debating replying to deej as I can suggest a couple of good tricks that make auto-downloading and testing snapshots easier. However, that is going firmly into off-topic territory. This thread is supposed to be about re-organising the packages for Opera in AUR. The discussion about Opera in [extra] is still related as it may replace some of those potential AUR packages.

The rest of this posting if Off-Topic. Please skip this post if you have no interest in reading about auto-downloading and testing Opera snapshots

Ok, I do want to give some advice about testing Opera snapshots but I also don't want to get a bad reputation for posting stuff in the wrong place, so soon after joining these forums. I figure I'll respond once with regards to auto-downloading and testing snapshots (clearly marked above so that those who are uninterested can skip over it) but if anyone else is interested in these topics or has further questions I suggest we move them elsewhere to avoid taking over this thread. Let's either create a new topic in Arch's own Off-Topic area or perhaps better yet use my own blog (I have opened up the comments sections so that you do not need to create a My Opera account to post there). Posting on my blog rather than the Arch Off-topic area has the benefit of assisting Opera's other UNIX/Linux users and not just Arch users. These are probably the two most relevant blog posts, so add questions or thoughts to them if you have any:

UNIX snapshot update 'one liners' and scripts
Testing Opera under UNIX/Linux, without changing your main profile settings

With that disclaimer out of the way.

@deej: If you are using a one liner to download a tar package, then why not:

1) Grab the bzip compressed package (since it is a smaller, faster download).
2) Decompress and extract the package on the fly.

Here is another example using the latest Linux G4 x86-64 (a.k.a. gcc4-qt4.x86_64) snapshot package once again:

wget -nv http://my.opera.com/desktopteam/blog/ -O - | grep snapshot.opera.com\/unix | head -1 | sed -e "s/.*\(http.*\)\" target.*/\1/" | wget -i - --spider -r -erobots=off -nd -np 2>&1 | grep \/opera.*.gcc4-qt4.x86_64.tar.bz2 | sed -e "s/.*http/http/" | wget -i - -O - | tar xjf -

Also, with snapshots prior to commiting to install (via install.sh directly, a package build, etc.), you should probably always have a quick test run first.

Before I explain what I mean by this I should explain one further thing. In case you are not aware Opera starts up via a wrapper script that sets up an appropriate environment before loading the main Opera library. In addition to other things, the wrapper knows the location of the Opera library it should use and also sets the directory where your profile/setting will be written and/or stored (typically ~/.opera). This wrapper is what typically lives in '/usr/bin/' after install.

With the tar packages, in addtion to install.sh we also provide a 'testing' wrapper. This testing wrapper 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 back to the setup you had before you began testing or if you are happy with the testing, commit to install.

It might help if I gave you an example. I will test in the /tmp directory. Here is how I could quickly test the latest Linux G4 x86-64 snapshot (currently 10.10-4728) without messing up my setup:

$ cd /tmp
$ wget http://snapshot.opera.com/unix/rc-4728/x86_64-linux/opera-10.10-4728.gcc4-qt4.x86_64.tar.bz2 -O - | tar xjf - 
$ cd opera-10.10-4728.gcc4-qt4.x86_64/
$ ./opera &

This will start the Opera snapshot and the wrapper script will create a new (clean) profile as a sub-directory of '/tmp/opera-10.10-4728.gcc4-qt4.x86_64' called 'profile', i.e. '/tmp/opera-10.10-4728.gcc4-qt4.x86_64/profile'. It will feel like you are running Opera for the first time because the new profile directory will be blank initially. Hence you will be presented with the license text again and all your bookmarks and other customisations will be missing. (Incidentally this is a great way to confirm if a possible bug is really a bug or a problem with your setup.)

Bear in mind that although the testing 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 with the snapshot 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 &

Note: Be very careful with doing that however, particularly if you are not planning to fully install this snapshot later because sometimes snapshots can reorganise the layout of your settings and hence downgrading later might not be possible (or at least not easy). Always make sure you have a backup of '~/.opera' first!

deej · 2009-11-18 08:49:00

Marvellous stuff. I agree about using your blog or off-topic; I can see this subject becoming
very interesting and potentially very well attended.

We'll all soon be members of The Elektrans :lol::lol:

Deej

quarkup · 2009-11-18 10:52:17

updated the PKGBUILD ( http://aur.archlinux.org/packages.php?ID=31783 )

it now has the snapshot build option
it has been tested for both archs but if you find any error or something which you want to tell just comment the package in aur.

its working for both bundled or not bundled version of qt, beta or final releases or even snapshots.

I guess it's easier now to get the various PKGBUILD's from this one which uses flags (variables)

IMO it's good to go!

@ruario, please when you can just check it out to be sure its ok.

Last edited by quarkup (2009-11-18 11:12:55)

ruario · 2009-11-18 11:38:44

I don't have time to install and verify right now but I'll comment quickly after a very quick preliminary scan of the PKGBUILD.

Most importantly:
1) Wow, this is really nice! Thanks so much for the effort! If this all works (and it looks like it should) then this is now my favourite Opera PKGBUILD.

Lesser importance:
2) I presume the 'lib32-libxext', 'lib32-libxt' and 'lib32-gcc-libs' dependencies are added is so that the user can also run 32bit plugins as well? If so then great, I am just checking/curious.
3) Any reason for the bundled unofficial "opera.svg"? Within the tarballs you will find "usr/share/icons/hicolor/scalable/apps/opera.svg". Do you not like the official logo we provide?

Even lower importance (given that you have already done so much):
4) So when are you making the equivalent "opera-g3" PKGBUILD (or you could provide a "generation number" option as well and just call rename your package "opera-latest", or something similar). Yes it is a big ask but you can't blame me for asking?

P.S. Before anyone asks, just so you don't think I am super lazy!! Yes I could make an opera-g3 PKGBUILD based off of quarkup's opera-g4 but ...

1) I wouldn't want people thinking it was down to me when quarkup did all the hard work. I have no interest in stealing his credit.
2) If I maintained a PKGBUILD people might consider it "official" and since we have no internal Opera process for maintaining this, I might not even be allowed to do anything that gives that impression (I'm not certain about this, I'm just speculating).
3) quarkup might want to add the the "g3" option within his own PKGBUILD.

Last edited by ruario (2009-11-18 11:54:23)

quarkup · 2009-11-18 11:48:17

1) thanks

2) actually it was a opera-g4 user (system) which had the x86_64 then he posted the changes (actually the user has removed the comment)

3) i based on another different PKGBUILD (i think it was one of the 'dev' or 'devel' for qt4). I will later change that

4) i though put another variable there, so it's possible to check if we want the qt3 or qt4, although it is not possible since there are the static versions for qt3 and for qt4 there are the bundled, so this would not work.

I'm not a qt3 user, but I think that someone could use this PKGBUILD to change it.
It's easier now to get a opera PKGBUILD, just by setting and/or removal of the variables you may find on the opera-g4 package

next weekend I may check it out.
the proposal is still up, and the opera-g4 PKGBUILD may help everyone (afaik) to get the desired version of opera.

edit: and thanks for your support

Last edited by quarkup (2009-11-18 11:49:32)

ruario · 2009-11-18 11:57:55

Fair enough!

quarkup wrote:

static versions for qt3

Actually there are no static versions at all now for Linux, only Solaris.

ruario · 2009-11-18 12:17:27

quarkup wrote:

2) actually it was a opera-g4 user (system) which had the x86_64 then he posted the changes (actually the user has removed the comment)

I thought about this more and I think you should probably remove the 32bit library dependences for the 64bit package. Whilst having them is handy if you want to run 32bit plugins, they are not real 'dependencies' in that Opera does not depend on them to run. It is generally best to use 64bit plugins on a 64bit OS where possible and most major plugins are available for both architectures anyway.

Also if you try and install a 32bit plugin via pacman on a 64bit machine I presume it will install the required 32bit dependencies anyway.

quarkup wrote:

3) I based on another different PKGBUILD (i think it was one of the 'dev' or 'devel' for qt4). I will later change that

\o/ because I 'personally' prefer our official logo.

quarkup wrote:

... thanks for your support

No need to thank me. I get paid for it! Of course I would do it for free anyway. Just don't let my boss know!

ruario · 2009-11-18 12:21:53

deej wrote:

We'll all soon be members of The Elektrans :lol::lol:

The UNIX/Linux Elektrans are actually called the "Panic Team". Yes this is a joke on 'kernel panics', something we hope that they will help us to avoid!

quarkup · 2009-11-18 19:03:13

opera-g3 -->> http://aur.archlinux.org/packages.php?ID=32094

note: who want to be it's maintainer ? I'm going to disown because I use the qt4.

edit: including ruario of course.

I'm the contributor already

about the possible (if there will be a cleanup) "future" packages, we can now have the PKGBUILD's done.

opera -> okay
opera-g4 -> okay
opera-snapshot -> (*)
opera-snapshot-g4 -> (*)
opera-beta -> (*)
opera-beta-g4 -> (*)
opera-labs-[labs feature name]
opera-labs-[labs feature name]-g4

(*) -> by editing the opera-g4 PKGBUILD it's easy to get these packages PKGBUILD.

Last edited by quarkup (2009-11-18 20:27:13)

ruario · 2009-11-19 09:35:26

@quarkup: If really can't find anybody else that wants 'opera-g3' I guess I can probably maintain it in some non-official way. I'll be wearing my Archlinux user hat, rather than my Opera employee hat. It won't get the same kind of testing we have for Opera official packages but I'll run a few quick smoke tests to ensure it basically works.

That said, I have looked at the PKGBUILDS a little more and installed them a couple of times with different options set on 32 and 64 bit Arch installs. Here are my thoughts:

1) The "patching files" section is not needed as the default plugin path looks at the '/usr/lib/mozilla/plugins' directory. Try 'grep mozilla usr/share/opera/defaults/pluginpath.ini' in an extracted official Opera tar package and you will see what I mean. I presume this patch relates to some older version of Opera that did not have this.

2) The conflicts list needs to be bigger. You can use the list of different Opera AUR packages from your first posting in this thread, along with the new variant names that we have proposed to build it up. Sure it will be long, but at least it will catch everything.

3) The supplied opera.desktop has a couple of flaws.
- i) "Name=Opera (snapshot)" should probably just read "Name=Opera" given that you can also install a stable or a beta via these PKGBUILDS.
- ii) "X-Ximian-Topleve" should be "X-Ximian-Toplevel" (The final 'l' seems to have been cut off)
(After correcting these you'll obviously have to regenerate the md5 for opera.desktop and then update the PKGBUILD).

4) You might want to add some warning in the comments at the top that the default setup options of this PKGBUILD will install a development snapshot, e.g. something like:

"WARNING: The default setup options of this PKGBUILD will install a development snapshot. Opera snapshots contain the latest changes, but may also have severe known issues, including crashes and data loss situations. In fact, they may not work at all. Please read the Opera Desktop Team Blog first so that you are aware of possible known issues, or consider using the options below to select a more stable build."

You could also supply the direct links to the Opera Desktop Team Blog and Opera snapshot FAQ immediately after this for convenience, i.e.:

http://my.opera.com/desktopteam/blog/
http://snapshot.opera.com/faq.html

5) The 'lib32-libxext' 'lib32-libxt' 'lib32-gcc-libs' depends are definitely not required for 64bit systems so you can remove them completely rather than just commenting them out.

6) For the opera-g3 variant the path to the latest stable download will fail (this won't happen with opera-g4). This is due to the fact that Qt3 packages are stored in the 'shared' sub directory. This is for historic reasons relating back to when we offered 'shared' and 'static'. However in the latest Beta we got rid of this unnecessary directory. I presume that when we release 10.10 we'll probably do the same. In the mean time at least the link fails.

I think that is everything. Just minor stuff really, on the whole these are very nice PKGBUILDS!

As I said before, if you really can't get anyone to look after opera-g3, I'll do it because I think it is important to have a version reliant on Qt3, given it has less known issues. At the same time I would ideally remain only in an advisory/contributor role since these are still strictly speaking 'unofficial'. If I start maintaining packages for one distro then other distros may ask why they don't get the same treatment and I really don't want to get into a situation of overcommitting myself given I have quite a few official responsibilities that take a lot of my time.

Last edited by ruario (2009-11-19 09:44:35)

ruario · 2009-11-19 09:48:41

Also, just a thought. If you used some stuff from other Opera PKGBUILDS to help create your own and some of the old code is still in there (i.e. you didn't just replace everything) perhaps you should list some of those people as contributors at the top as well? I don't really know standard AUR procedure for this. I'm just guessing.

ruario · 2009-11-19 10:32:14

Another thought. You might want to install the Opera global preferences files as well:

/etc/operaprefs_fixed.ini
/etc/operaprefs_default.ini

You'll find them in the Opera tar packages. Their permissions should be 644 and owned by root.

Last edited by ruario (2009-11-19 10:34:38)

wuischke · 2009-11-19 10:57:34

2) The conflicts list needs to be bigger. You can use the list of different Opera AUR packages from your first posting in this thread, along with the new variant names that we have proposed to build it up. Sure it will be long, but at least it will catch everything.

Actually I think it's not necessary since these packages provide "opera", i.e. they will create a conflict for "opera".

ruario · 2009-11-19 10:59:39

wuischke wrote:

Actually I think it's not necessary since these packages provide "opera", i.e. they will create a conflict for "opera".

Ah hah ... makes sense. Ok skip '2)' then. I am pretty sure that the other points still hold true.

quarkup · 2009-11-19 11:10:57

okay, its updated now (for both packages, g3 and g4).

About the opera-g3, I just disowned it.

edit: (the step 2 is already done, hope there are no conflicts )

Last edited by quarkup (2009-11-19 11:14:46)

ruario · 2009-11-19 13:32:47

quarkup wrote:

About the opera-g3, I just disowned it.

Poor little opera-g3 PKGBUILD. I hope it finds a nice new owner soon.

What happens if nobody picks it up, will it be removed? I am debating becoming the maintainer. Indeed I was for a short while and then reconsidered if this was wise but then i also do not want it to disappear.

P.S. I made a couple of adjustments, e.g. installing the Opera global preferences files and making a minor tweak as "shared/" still wasn't working correctly. Now it works on all three variants (final, beta, snapshot) on both i686 and x86_64. Whomever takes over should watch out on the next final release as I suspect this will break again at that point given we are likely to stop using the shared sub directory.

Last edited by ruario (2009-11-19 14:00:46)

quarkup · 2009-11-19 14:28:57

if we are planning to make a cleanup on the opera's packages over the AUR, shouldn't we use the -qt4 name instead of -g4 ?

IMO its more simple for new users to recognize that it has support for the latest qt

would be something as simple as this

opera (opera-g3)
opera-qt4 (opera-g4)
opera-snapshot
opera-snapshot-qt4
opera-beta
opera-beta-qt4

ruario · 2009-11-19 15:55:38

Yeah ... maybe you are right. I like the G numbers because they mean more than just qt version but I agree this won't be so obvious to most users.

ruario · 2009-11-19 21:22:07

@quarkup: See my comment on the opera-g4 package. You don't seem to be picking up the latest RC.

quarkup · 2009-11-19 22:31:53

ok ok, thanks.
i think we from now on just need to 'split' the g4 and g3 packages to get all different versions of snapshot/beta and of course the 2 main final releases..

Last edited by quarkup (2009-11-21 12:06:57)

Arch Linux

#26 2009-11-17 11:38:04

Re: [proposal] The Opera browser

#27 2009-11-17 20:14:32

Re: [proposal] The Opera browser

#28 2009-11-17 21:06:30

Re: [proposal] The Opera browser

#29 2009-11-18 03:10:38

Re: [proposal] The Opera browser

#30 2009-11-18 06:25:53

Re: [proposal] The Opera browser

#31 2009-11-18 08:38:39

Re: [proposal] The Opera browser

#32 2009-11-18 08:49:00

Re: [proposal] The Opera browser

#33 2009-11-18 10:52:17

Re: [proposal] The Opera browser

#34 2009-11-18 11:38:44

Re: [proposal] The Opera browser

#35 2009-11-18 11:48:17

Re: [proposal] The Opera browser

#36 2009-11-18 11:57:55

Re: [proposal] The Opera browser

#37 2009-11-18 12:17:27

Re: [proposal] The Opera browser

#38 2009-11-18 12:21:53

Re: [proposal] The Opera browser

#39 2009-11-18 19:03:13

Re: [proposal] The Opera browser

#40 2009-11-19 09:35:26

Re: [proposal] The Opera browser

#41 2009-11-19 09:48:41

Re: [proposal] The Opera browser

#42 2009-11-19 10:32:14

Re: [proposal] The Opera browser

#43 2009-11-19 10:57:34

Re: [proposal] The Opera browser

#44 2009-11-19 10:59:39

Re: [proposal] The Opera browser

#45 2009-11-19 11:10:57

Re: [proposal] The Opera browser

#46 2009-11-19 13:32:47

Re: [proposal] The Opera browser

#47 2009-11-19 14:28:57

Re: [proposal] The Opera browser

#48 2009-11-19 15:55:38

Re: [proposal] The Opera browser

#49 2009-11-19 21:22:07

Re: [proposal] The Opera browser

#50 2009-11-19 22:31:53

Re: [proposal] The Opera browser

Board footer