64-bit 'portable' Opera browser.....

Message

Mike Walsh · #1 Post by **Mike Walsh** » Wed 01 Jan 2020, 19:01

Evening, all.

Looks like I'll have to eat my words..! Having clearly stated, only a couple of months back, that truly 'portable' versions of any of the Chromium-based 'clones' were impossible to build, I've gone and shot myself in the foot.....because here, after a certain amount of head-scratching, is

Opera 'portable'

....for your perusal & enjoyment.

I started thinking about this yesterday afternoon. By bedtime last night I'd got it pretty well 'fleshed-out' in my mind, though nothing concrete to show for it.

After a couple of false starts this morning, it turned out the wrapper-script was going to be a lot simpler than I thought, given that Opera themselves call the large, 'shared' library that contains the bulk of the browser directly from the .desktop entry . They don't actually use a wrapper script at all. We, however, have to use one in Puppy.....'cos otherwise our poor canine goes 'barking mad' trying (and failing) to get it going!

So it's simply a modification of the one in the SFS packages I published day before yesterday, along the lines of Fred's launch-script for portable-Quantum. (Cheers as always, Fred!)

-------------------------------------------------

It's the usual procedure. Download the tarball from my GoogleDrive, here:-

Opera-portable tarball

Unzip it, and move the 'Opera-portable' directory anywhere you like. Click to open it, and hit the 'LAUNCH' script. That's all there is to it.

------------------------------------------------

It'll take several seconds to fire up, because it first checks & updates PepperFlash if necessary.....the 'auto-updater' is built-in, and runs with the launch script. On the first run, it then creates the 'PROFILE' directory within, and populates it. (EDIT:- [02/01/20] Now changed; the Pepper update is triggered manually from a script beside LAUNCH, instead. Gxmessage advises you when the process is complete.)

WideVine is included, along with the 'libffmpeg' fix I garnered from the guys'n'gals over at the Opera forums.....so NetFlix, Hulu, Amazon Prime, Spotify, etc., etc., will run OOTB.

Apart from the (necessarily) slow start, this thing runs fiendishly fast, and is a joy to use. I haven't yet tried out the built-in VPN, but you've got all sorts of other stuff built-in.....like the Telegram, WhatsApp & Facebook 'Messenger' services right there in the sidebar at the single click of a button. And more besides......including quite a lot of stuff I normally have to add to Chrome via extensions. It's all here.

----------------------------------------

This'll need more testing yet, before I definitely make my mind up.....but there's a strong possibility I may finally abandon Google Chrome; this thing really is that good. I'm beginning to understand what all the fuss was about with the older Operas.....

Watch this space.

Mike.

s243a · #2 Post by **s243a** » Wed 01 Jan 2020, 19:07

Thank you, Mike

I'll probably give this a try sometime.

01101001b · #3 Post by **01101001b** » Wed 01 Jan 2020, 20:29

Mike Walsh wrote:It'll take several seconds to fire up, because it first checks & updates PepperFlash if necessary...

In my system (DPupBuster8 64bit), Opera-portable didn't start at all until I commented out that line ("UpdatePep64"). Then, bang! it started amazingly fast.

Thank you Mike! Great work!

Mike Walsh · #4 Post by **Mike Walsh** » Wed 01 Jan 2020, 21:01

s243a wrote:Thank you, Mike

I'll probably give this a try sometime.

Ah, you're very welcome. Let me know what you think, please. This is a first release, so things may well get changed yet for the next one.....whenever it arrives.

Cheers.

Mike.

Mike Walsh · #5 Post by **Mike Walsh** » Wed 01 Jan 2020, 21:09

01101001b wrote:
Mike Walsh wrote:It'll take several seconds to fire up, because it first checks & updates PepperFlash if necessary...
In my system (DPupBuster8 64bit), Opera-portable didn't start at all until I commented out that line ("UpdatePep64"). Then, bang! it started amazingly fast.

Thank you Mike! Great work!

Mmm..... Uh-huh. Fair comment. The script 'as-is' works OK for me, but I've been wondering for the last hour or two if that was the wisest course of action, or whether I should leave it out of the script, and just allow folks to 'trigger' it manually, as & when.

I hate Flash & Pepper as much as anybody, but we're still stuck with 'em for the next 12 months before EOL rolls around. So we may as well keep them up-to-date until we are finally shot of them.

An all-HTML5 'net can't come fast enough for me, I tell you....

Mike.

Terry H · #6 Post by **Terry H** » Wed 01 Jan 2020, 21:10

Well done Mike, really nice job. I'm running Barry's EasyOS Pyro 1.3 at the moment, so I thought I'd give it a try. I'm posting from it now, it's all good. Couldn't get it to run using LAUNCH script bit it ran from terminal launched in directory using ./opera-browser script. I'll have a play with Launcher.

Opera has been my default browser on my Android tablet for several years now. I'll have a look at getting it to run in a container.

Edit: Just read 01101001b's post above about commenting out Update Pepper flash, maybe that was my issue. I'll check.

After commenting out that line, it ran fine launching Opera.

Mike Walsh · #7 Post by **Mike Walsh** » Wed 01 Jan 2020, 21:17

Terry H wrote:Well done Mike, really nice job. I'm running Barry's EasyOS Pyro 1.3 at the moment, so I thought I'd give it a try. I'm posting from it now, it's all good. Couldn't get it to run using LAUNCH script bit it ran from terminal launched in directory using ./opera-browser script. I'll have a play with Launcher.

Opera has been my default browser on my Android tablet for several years now. I'll have a look at getting it to run in a container.

@ Terry:-

It might be the same issue as noted above by 01101001b.....the addition of running the Update Pepper script via 'LAUNCH'. Try commenting that line out, and let me know what happens, please; the more feedback I get on this the better. Just because that particular bit runs for me, doesn't mean it's going to work for everyone, of course.....

I know little enough about the 'Dogs', and even less about EasyOS. About all I know of the latter is that it uses an awful lot of "containers".....

I only added the 'LAUNCH' sym-link to /opera-browser to save folks needing to dig around inside the main browser directory, that's all it was.

Mike.

fredx181 · #8 Post by **fredx181** » Wed 01 Jan 2020, 23:13

Thanks Mike ! Posting from it now, really fast !

Same for me that it's got stuck on the "UpdatePep64" script, made some small changes to it and works for me now (attached).

Code: Select all

root@live:/mnt/sda5/Opera-portable/opera# ./UpdatePep64
LATEST_VERSION=32.0.0.303
INSTALLED_VERSION=32.0.0.303
LATEST_VERSION=INSTALLED_VERSION=32.0.0.303

Good chance that it works for others too, but even then I think it should be launched from a separated script or symlink because of the startup delay (when launching from "LAUNCH").

Cheers and I wish you a great 2020 !

Fred

Mike Walsh · #9 Post by **Mike Walsh** » Thu 02 Jan 2020, 00:15

@ Fred:-

And a Happy New Year to you, too!

Hm. Odd, that; I don't quite know what to make of it, 'cos your modified version, and my original which I downloaded from sfs's post in my old PepperFlash thread, both work for me. I can see where you've made a few changes, but it's like so much 'Greek' as far as I'm concerned..!

No use asking me what the damn script does. Sfs developed his version from Geoffrey's original, wonderful auto-updater he put together for Flashplayer. It was a crying shame that Adobe played musical URLs with the download locations as often as they did; I honestly feel Geoff just got fed-up with maintaining it in the end....

Curiously, the download locations for PepperFlash, on the other hand, never seem to have varied since the day sfs wrote his script..! I've been using it since the day it was uploaded to the Forum, and it's never yet failed to deliver.....

No word of a lie, it's saved me a whole heap of work this last couple of years.

--------------------------------------------------------------------------

I'm in two minds as to what to do about the Pepper update script. I know this is a first release of this portable Opera; a little bit of 'fine-tuning' is certainly indicated, I don't mind admitting.

I want to keep the updater in, for sure. Now; community co-operation always tends to improve the experience for all concerned, and you've helped me out with some darn good suggestions and 'improvements' this last couple of years, so.....

Let me 'pick your brains', and ask you a question (if I may?) You're a much better coder than I'll ever be, and I'm wondering, now... Rather than triggering the script to run at launch, what might be involved in triggering it to run at shutdown, instead.....so it's updated ready for the next time you want to use it?

Could it be done easily, or would it be too awkward to implement? What d'you think? Do-able.....or should I just leave it as a manual jobbie?

Mike.

Geek3579 · #10 Post by **Geek3579** » Thu 02 Jan 2020, 07:29

I downloaded the file and extracted in a folder with Uextract.

all files extracted OK except as seen in this terminal message:

tar: Opera-portable/LAUNCH: Cannot create symlink to ‘opera/opera-browser’: Operation not permitted
tar: Exiting with failure status due to previous errors

Any help appreciated, thanks

fredx181 · #11 Post by **fredx181** » Thu 02 Jan 2020, 10:12

Mike wrote:Hm. Odd, that; I don't quite know what to make of it, 'cos your modified version, and my original which I downloaded from sfs's post in my old PepperFlash thread, both work for me.

Probably it depends on the wget version that is installed.

Rather than triggering the script to run at launch, what might be involved in triggering it to run at shutdown

Putting it at the end of the LAUNCH script works, but better make a separate UpdatePep symlink in same dir as LAUNCH, just my opinion though.

@Geek3579

all files extracted OK except as seen in this terminal message:

tar: Opera-portable/LAUNCH: Cannot create symlink to ‘opera/opera-browser’: Operation not permitted
tar: Exiting with failure status due to previous errors

I guess that's because you extract on a filesystem that doesn't support symlinks (FAT32 ?)

EDIT: @Mike, to avoid the symlink problem, you can also make LAUNCH a simple script instead, e.g. :

Code: Select all

#!/bin/sh

# Launcher for Opera browser
#
HERE="$(dirname "$(readlink -f "$0")")"

"$HERE/opera/opera-browser" "$@"

Fred

Mike Walsh · #12 Post by **Mike Walsh** » Thu 02 Jan 2020, 11:16

Morning, Fred.

I was thinking along the same lines myself. Putting a manual update script alongside opera & LAUNCH, and removing it from the 'LAUNCH' script.

The point about sym-links is well taken, and not something I was aware of; I never run Puppy from FAT32, always ext3, so haven't come across that one before. Something new I've learnt.

Both 'opera-browser' and 'UpdatePep64' can be triggered the same way. It's a trick I often use myself, but I never thought of it in this particular context.

I'll get on with a re-pack. Cheers, Fred.

Mike.

Mike Walsh · #13 Post by **Mike Walsh** » Thu 02 Jan 2020, 12:50

Opera-portable_v2

Okay. Version 2 now uploaded. Modifications include:-

Changing the LAUNCH sym-link to a separate launcher, pointing to ./opera/opera-browser. This should get round the FAT32 'no symlink' issue. (Thanks for the advice, Fred.)

The Pepper updater has now been removed from the main wrapper-script, so Opera will start.....much quicker! Instead, UpdatePep64 is launched manually, from a script alongside launch; when the process is completed, a gxmessage will pop-up to advise you of the fact. I think this is probably better; it leaves the choice of whether to update or not to the user ( as opposed to 'forcing' it on you).....and is easy enough to run, since it's there, right beside the main launcher, looking at you.

-----------------------------------------

Download from the main link in post #1.

MD5 - 0509a1f3336b10ff5d7efc09336c6bef
SHA256 - faf8c0b1ebf8747b960f40a1717b0e920ed3de6570e90637822493eb684397fc

(Bit of an experiment for me, since I realised SFR's 'Packit' will produce these...)

Enjoy!

Mike.

backi · #14 Post by **backi** » Thu 02 Jan 2020, 13:02

Hi Mike !
Tested on Bionic Dog64 works OOB ......
Fucking fast !

Xenial Dog64 failed starting.......despite Hacks mentioned above .
Nevertheless good Job... will have a look further into it .
Thumbs up man!

Best Regards ......and a Happy New Year !

Mike Walsh · #15 Post by **Mike Walsh** » Thu 02 Jan 2020, 14:31

backi wrote:Hi Mike !
Tested on Bionic Dog64 works OOB ......
Fucking fast !

Xenial Dog64 failed starting.......despite Hacks mentioned above .
Nevertheless good Job... will have a look further into it .
Thumbs up man!

Best Regards ......and a Happy New Year !

Hi, backi.

Ahh; so you like it then, do ya?

Good, good....

Yes, it's surprised me with just how responsive it is. Like I said, I've a sneaking suspicion it's going to replace Chrome as far as I'm concerned, it's that good.

Anyways; glad you like it, and.....a Happy New Year to you, too.

Mike.

Terry H · #16 Post by **Terry H** » Thu 02 Jan 2020, 16:00

I have played around with trying to get this to run in a container in EasyOS, so far I can't get it to run. Running it from a terminal doesn't give any indication of what's wrong, no messages or errors in logs.

I won't interfere with this thread any further regarding running in a container. I'll mention it in the EasyOS thread, to see if there are any suggestions. Regardless of whether it can be run in a container, it's definitely a keeper and I will use it. So, thanks Mike, nice job.

s243a · #17 Post by **s243a** » Thu 02 Jan 2020, 16:17

Terry H wrote:I have played around with trying to get this to run in a container in EasyOS, so far I can't get it to run. Running it from a terminal doesn't give any indication of what's wrong, no messages or errors in logs.

I won't interfere with this thread any further regarding running in a container. I'll mention it in the EasyOS thread, to see if there are any suggestions. Regardless of whether it can be run in a container, it's definitely a keeper and I will use it. So, thanks Mike, nice job.

I know that some (all?) chrome-based browsers require access to shared memory. I believe in chrome-based browsers this is a folder named something like "shm" (maybe /dev/shm). Perhaps the "Easy-Containers" don't have access to shared memory for security reasons. Maybe one, could created a fake shared memory folder in an easy-os container.

Chrome browsers will run in a virtual machine so perhaps there is a workaround.

Edit: docker can do it:

To run Docker with a custom shared memory size, use the --shm-size option. For example:

$ docker run -it --shm-size=256m <CONTAINER_NAME> /bin/sh

https://sondnm.github.io/blog/2018/09/0 ... -/dev/shm/

so maybe there is a way to do it with Easy-Containers.

https://medium.com/dot-debug/running-ch ... 5e7f4da4a8

Although the the above two links seem to be for a headless chrome? I wonder how that works?

A redit thread suggests using firejail instead of a docker container. However, said thread provides the following link to a chrome docker file:
https://github.com/jessfraz/dockerfiles ... Dockerfile

perhaps said file will help with figuring out how to run chrome in an Easy-Container. I think the key info in said file is the startup option:

Code: Select all

# docker run -it \
#	--net host \ # may as well YOLO
#	--cpuset-cpus 0 \ # control the cpu
#	--memory 512mb \ # max memory it can use
#	-v /tmp/.X11-unix:/tmp/.X11-unix \ # mount the X11 socket
#	-e DISPLAY=unix$DISPLAY \
#	-v $HOME/Downloads:/home/chrome/Downloads \
#	-v $HOME/.config/google-chrome/:/data \ # if you want to save state
#	--security-opt seccomp=$HOME/chrome.json \
#	--device /dev/snd \ # so we have sound
#   --device /dev/dri \
#	-v /dev/shm:/dev/shm \
#	--name chrome \
#	jess/chrome

Note the "-v /dev/shm:/dev/shm". EasyOS probably needs some way of specifying this if it doesn't already have such a feature.

Mike Walsh · #18 Post by **Mike Walsh** » Sat 11 Jan 2020, 16:17

Afternoon, all.

Opera-portable_v3

Now then; I thought I'd got this portable-Opera completely sorted, but as it turns out, I hadn't. Mainly my own fault, due to residual 'left-overs' from the unloaded Opera SFS package, and my not trying it out in a 'pristine' Puppy, minus save-file.....and Opera consequently reading resource 'paths' for libffmpeg.so, libwidevinecdm.so and libpepflashplayer.so from those residual left-overs.

Thanks to a post from seaside in the 'portable-Chrome' thread, Opera is now truly portable. Seaside did some research, and came up with a modified launch-script, which employs the 'tee' command. I don't fully understand its operation, but the upshot is that wherever you decide to place Opera (and you really can put it literally anywhere now), when the script is run to start the browser, the 'resource' paths in /opera/resources for the 3 above-mentioned items are re-written to point to their absolute location.

I've tested this out thoroughly in both Bionicpup64 and Xenialpup64 by moving the portable from one location to another a few times. After starting the browser each time, upon checking the pre-load 'paths' in

/opera/resources/ffmpeg_preload_config.json,
/opera/resources/pepperflash_config.json, and
/opera/resources/widevine_config.json

.....you can indeed see that the preload 'path' for each item has been re-written to take its 'current' location into account. Which is a very neat way round the problem, altogether.

For anybody who's interested in the script itself, you can see it here:-

Code: Select all

#!/bin/sh
#
# Launcher for 'portable' Opera browser
#
export HERE="$(dirname "$(readlink -f "$0")")"

sudo tee "$HERE"/opera/resources/pepper_flash_config.json >/dev/null <<EOF
{
  "PepperFlashPaths" : [
    "${HERE}/opera/PepperFlash/libpepflashplayer.so"   
  ]
}
EOF

sudo tee "$HERE"/opera/resources/ffmpeg_preload_config.json >/dev/null <<EOF
[
  "${HERE}/opera/libffmpeg.so"
]
EOF

sudo tee "$HERE"/opera/resources/widevine_config.json >/dev/null <<EOF
[
   {
      "preload" : "${HERE}/opera/libwidevinecdm.so"
   }
]
EOF


"$HERE/opera/opera-browser" "$@"

For Puppy, I've simply removed the unnecessary 'sudo' references. (Seaside was using this in DebianDog 'Stretch', hence the need for 'sudo'.) And it works.....very, very well.
-------------------------------------

I've re-packed & re-uploaded the browser tarball with the new launch script. You can find it at the above link in post #1.

New checksums:-

MD5 - 2487cb995d44115187619edd273c5b3f
Sha256 - 7af539ec58cb2c3b2ea81d6f0d0bc3dad85c3a1edeb3e4bcb8272fb0234b9d4b

-------------------------------------

For those of you who've already downloaded and are using the browser, the only thing that's changed is the launcher, so.....I've attached the modified script from seaside to this post. Just remove the 'fake' .gz, and replace the existing 'LAUNCH' script with this one.

Credits (and thanks!) go to seaside for this one.

Have fun..! Feedback is welcome, as always.

Mike.

mikeslr · #19 Post by **mikeslr** » Sat 11 Jan 2020, 21:53

Thanks Mike & seaside,

Should similar changes be made to the LAUNCH scripts in Brave-portable and Iron-portable?

Terry H · #20 Post by **Terry H** » Sat 11 Jan 2020, 22:26

Mike, not a question regarding portability but about Opera itself. One little niggling thing is I want the browser to start up maximized if possible, rather than a small window. I'm not able to find anywhere to do this in easy setup or browser settings. Any idea how to achieve this would be much appreciated. Thanks.

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

64-bit 'portable' Opera browser.....

64-bit 'portable' Opera browser.....

Re: 64-bit 'portable' Opera browser.....

Re: 64-bit 'portable' Opera browser.....