You could try this command line option:
--start-maximized
Another option:
--start-fullscreen
Many of these Chromium options are supposed to work with Opera.
https://peter.sh/experiments/chromium-c ... -switches/
64-bit 'portable' Opera browser.....
-
Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
@ Terry:-
Yes, that's a HUGE list of available '--switches' for these Chromium 'clones' from Peter Beverloo, ain't it? I'd forgotten about it, myself.
Most folks simply aren't aware of just how many 'presettable' options these browsers do come with. I'm glad you raised the point and got an answer for it, 'cos the small window at start up was driving me nuts, too..... 
@ Mike:-
I'm still going to investigate Iron, however; that's the one that's giving me 'issues'. As for Brave, as soon as I visited NetFlix & signed-in, it auto-downloaded and installed WideVine for me.....didn't have to click on anything. I'm wondering, however, if Brave contains the clue to getting it working in Iron? Both are using the new location for WideVine.....the new WideVineCdm sub-directory; Iron, however, has a full list of 'platforms' within the manifest.json file inside WideVineCdm, whereas Brave's manifest.json file is empty.
(It's not only locations, though; there appears to be a number of subtle coding differences in the main browser 'shared library', between different Chromium clones. Enough of 'em, anyway, to make each individual clone require its own custom solution. No 'one-size-fits-all' solution here, I'm sorry to say; despite that most of 'em are using identical components, they all seem to have implemented those components in different ways. Buggers!!)
I'll look further into it tomorrow, when I get time.
Mike. :wink
Yes, that's a HUGE list of available '--switches' for these Chromium 'clones' from Peter Beverloo, ain't it? I'd forgotten about it, myself.
Most folks simply aren't aware of just how many 'presettable' options these browsers do come with. I'm glad you raised the point and got an answer for it, 'cos the small window at start up was driving me nuts, too..... @ Mike:-
Short answer? No, I'm afraid not. Those particular .json config files appear to be unique to Opera, unfortunately.mikeslr wrote:Should similar changes be made to the LAUNCH scripts in Brave-portable and Iron-portable?
I'm still going to investigate Iron, however; that's the one that's giving me 'issues'. As for Brave, as soon as I visited NetFlix & signed-in, it auto-downloaded and installed WideVine for me.....didn't have to click on anything. I'm wondering, however, if Brave contains the clue to getting it working in Iron? Both are using the new location for WideVine.....the new WideVineCdm sub-directory; Iron, however, has a full list of 'platforms' within the manifest.json file inside WideVineCdm, whereas Brave's manifest.json file is empty.
(It's not only locations, though; there appears to be a number of subtle coding differences in the main browser 'shared library', between different Chromium clones. Enough of 'em, anyway, to make each individual clone require its own custom solution. No 'one-size-fits-all' solution here, I'm sorry to say; despite that most of 'em are using identical components, they all seem to have implemented those components in different ways. Buggers!!)
I'll look further into it tomorrow, when I get time.
Mike. :wink
Last edited by Mike Walsh on Sun 12 Jan 2020, 13:38, edited 2 times in total.
-
thinkpadfreak
- Posts: 98
- Joined: Mon 17 Oct 2016, 05:11
Hello.
I got to know you decided to close Chrome packages thread. I am sorry that it is difficult to use the current version of Chrome.
I have tried Opera, and it works fine. We Japanese use some input method (system to convert the input through the keyboard into Japanese characters or kanji).
We run Chrome or Chromium as spot, adding env command as follows:
env GTK_IM_MODULE="xim" google-chrome-stable
I noticed that, with your portable version of Opera, we don't need to add env command to deal with Japanese.
I hope Opera will continue to work fine when it has become Chromium 79 based.
I got to know you decided to close Chrome packages thread. I am sorry that it is difficult to use the current version of Chrome.
I have tried Opera, and it works fine. We Japanese use some input method (system to convert the input through the keyboard into Japanese characters or kanji).
We run Chrome or Chromium as spot, adding env command as follows:
env GTK_IM_MODULE="xim" google-chrome-stable
I noticed that, with your portable version of Opera, we don't need to add env command to deal with Japanese.
I hope Opera will continue to work fine when it has become Chromium 79 based.
-
Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
@ thinkpadfreak:-
No need to run as spot, and you don't need to make further modifications. Is it any wonder I prefer this to Chrome? It's just so much easier to use...
Mike.
Well, there you are. Go, Opera....yay!!thinkpadfreak wrote:I noticed that, with your portable version of Opera, we don't need to add env command to deal with Japanese.
I hope Opera will continue to work fine when it has become Chromium 79 based.
No need to run as spot, and you don't need to make further modifications. Is it any wonder I prefer this to Chrome? It's just so much easier to use...
Mike.
Mike, nicely done.
You are singlehandly creating the biggest Opera fan club since "Madam Butterfly" or "Tosca".
I took your point about "sudo" in the LAUNCH script, and rewrote it to test for the command in case a distro doesn't use it. I tested it in the latest FATDOG (which does not have sudo and it worked.) I think this will work for all cases now. Here it is:
Cheers,
s
(Your browser work is really needed and appreciated - thanks)
You are singlehandly creating the biggest Opera fan club since "Madam Butterfly" or "Tosca".
I took your point about "sudo" in the LAUNCH script, and rewrote it to test for the command in case a distro doesn't use it. I tested it in the latest FATDOG (which does not have sudo and it worked.) I think this will work for all cases now. Here it is:
Code: Select all
#!/bin/sh
#
# Launcher for 'portable' Opera browser
# test for existence of sudo command
prefix=" "
which sudo 2>/dev/null && export prefix=sudo
export HERE="$(dirname "$(readlink -f "$0")")"
${prefix} tee "$HERE"/opera/resources/pepper_flash_config.json >/dev/null <<EOF
{
"PepperFlashPaths" : [
"${HERE}/opera/PepperFlash/libpepflashplayer.so"
]
}
EOF
${prefix} tee "$HERE"/opera/resources/ffmpeg_preload_config.json >/dev/null <<EOF
[
"${HERE}/opera/libffmpeg.so"
]
EOF
${prefix} tee "$HERE"/opera/resources/widevine_config.json >/dev/null <<EOF
[
{
"preload" : "${HERE}/opera/libwidevinecdm.so"
}
]
EOF
"$HERE/opera/opera-browser" "$@"
s
(Your browser work is really needed and appreciated - thanks)
-
Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
@ rockedge:-
I've definitely had it with Chrome. This thing is just so easy to use.
What's happening with the new forum, BTW?
Mike.
Mm! It is damn fast, isn't it? I'm in Bionic64 ATM, and it runs better than Chrome has done for quite a while. And so much of the stuff I have to 'add-in' to Chrome via extensions is built-in to Opera by default; overall, I have to confess I'm very impressed with it.....more so, now we've got WideVine, etc, sorted once & for all.rockedge wrote:been using Opera again now for a day...it blazes and runs very nicely on Bionic64
While I lived in Germany Opera was my go to browser before I dabbled with firefox many moons ago
I've definitely had it with Chrome. This thing is just so easy to use.
What's happening with the new forum, BTW?
Mike.
-
Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
@ seaside:-
I refuse to take credit for the work of others. The principle came from Fred, many months ago (though as he says, it's actually been floating around the web for years in one form or another, so....) Various tweaks have come from other folks over the last year or two.....and for this particular browser, your valuable contribution has "put the icing on the cake", so to speak.
Nah, it's not really single-handed at all. All I will take credit for is putting all these odds'n'ends together into a working package that the whole community will benefit from.
-------------------------------------
I had the idea to try and assemble a working 'portable' from the available Linux Chromium-based 'clones' years ago, during my final months of fighting XP (before I consigned it to the dustbin of history). I always liked the idea of an app you could run from a flash drive, as with the Windows PortableApps, and 'share' between systems. It's even more relevant when you're running multiple Puppies, since browsers are not small items.....and it just seems pointless duplicating the same install, over and over again. For a time I duplicated the browser itself, but shared profiles, via symlinks, from an external, remotely-mounted data partition, but this way is better still! Of course, my scripting skills in those days were even more abysmal than they are now; I'm gradually getting the hang of things, I guess.....but it doesn't come naturally to me, y'know?
I was always terrible with learning languages, even as a nipper.....and it comes harder & harder, the older you get!
Much of what I package these days draws on either previous experience, or the same as many others do.....borrowing snippets of code from other folks existing scripts. Which I think is endemic in the open-source world, if the truth be known.
-----------------------------------------
At the end of the day, if what I produce works & does what I want, I'm more than happy to share. And if it meets with other's approval, well.....I'm good with that.
Anything to make the whole 'Puppy' user-experience more attractive to everybody has to be to everybody's advantage. I don't care if we do end up with 50 ways of doing the same thing; not everybody wants to approach a given subject from the same angle, so choice is also a 'good thing'.
Mike.
Oh no you don't!seaside wrote:Mike, nicely done.
You are singlehandly creating the biggest Opera fan club since "Madam Butterfly" or "Tosca".
I refuse to take credit for the work of others. The principle came from Fred, many months ago (though as he says, it's actually been floating around the web for years in one form or another, so....) Various tweaks have come from other folks over the last year or two.....and for this particular browser, your valuable contribution has "put the icing on the cake", so to speak.Nah, it's not really single-handed at all. All I will take credit for is putting all these odds'n'ends together into a working package that the whole community will benefit from.
-------------------------------------
I had the idea to try and assemble a working 'portable' from the available Linux Chromium-based 'clones' years ago, during my final months of fighting XP (before I consigned it to the dustbin of history). I always liked the idea of an app you could run from a flash drive, as with the Windows PortableApps, and 'share' between systems. It's even more relevant when you're running multiple Puppies, since browsers are not small items.....and it just seems pointless duplicating the same install, over and over again. For a time I duplicated the browser itself, but shared profiles, via symlinks, from an external, remotely-mounted data partition, but this way is better still! Of course, my scripting skills in those days were even more abysmal than they are now; I'm gradually getting the hang of things, I guess.....but it doesn't come naturally to me, y'know?
I was always terrible with learning languages, even as a nipper.....and it comes harder & harder, the older you get!
Much of what I package these days draws on either previous experience, or the same as many others do.....borrowing snippets of code from other folks existing scripts. Which I think is endemic in the open-source world, if the truth be known.
-----------------------------------------
At the end of the day, if what I produce works & does what I want, I'm more than happy to share. And if it meets with other's approval, well.....I'm good with that.
Anything to make the whole 'Puppy' user-experience more attractive to everybody has to be to everybody's advantage. I don't care if we do end up with 50 ways of doing the same thing; not everybody wants to approach a given subject from the same angle, so choice is also a 'good thing'.
Mike.
64ScPup problem
G'day Mike,
Now I understand your "Alice in Wonderland"-inspired avatar. With browsers, you need to run as fast as you can just to stay where you are.
I had success with your Opera Portable in 64Bionic8.0 but in peebee's latest 64ScPup, no go.
As usual, I run these via a symlink from the actual packages on my data partition - I put the Opera directory link into /opt and this was fine in 64Bionic8, as far as I went setting up the profile in /root/.config/ to eventually link this back to the data partition. I suspect I'll need separate profiles for Bionic and ScPups given the differences in lib file set-up between them.
Anyway, back to 'running on the spot',......
After initial nothingness in 64ScPup, I ran 'LAUNCH' from a terminal and got the below strings of messages:
I had noticed a poster in the SCPup thread asking if anyone had got Opera running. But thought I should post something here when I found I couldn't get it running..
I'm using a Vivaldi in 64ScPup to post this and there seems a lot of similarity with Vivaldi and Opera. Becoming the 'devil I know'.
Thanks for your efforts.
David S.
Now I understand your "Alice in Wonderland"-inspired avatar. With browsers, you need to run as fast as you can just to stay where you are.
I had success with your Opera Portable in 64Bionic8.0 but in peebee's latest 64ScPup, no go.
As usual, I run these via a symlink from the actual packages on my data partition - I put the Opera directory link into /opt and this was fine in 64Bionic8, as far as I went setting up the profile in /root/.config/ to eventually link this back to the data partition. I suspect I'll need separate profiles for Bionic and ScPups given the differences in lib file set-up between them.
Anyway, back to 'running on the spot',......
After initial nothingness in 64ScPup, I ran 'LAUNCH' from a terminal and got the below strings of messages:
Maybe you and Lewis Carroll can understand this?# cd /opt/Opera-portable
# ./LAUNCH
[278960113/090432.892800:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[27896
[27896
[279270113/090433.145439:ERROR:gl_surface_glx.cc(78)] XGetWindowAttributes failed for window 33554436.
[27927
[27927
[27927
[27927
[27927
(opera:27896): GLib-GIO-ERROR **: 09:04:33.186: Settings schema 'org.gnome.desktop.background' is not installed
/mnt/sdb3/Puppy_Archive/OperaPortable64/Opera-portable/opera/opera-browser: line 9: 27896 Trace/breakpoint trap "$HERE/opera" --user-data-dir=$HERE/PROFILE --ppapi-flash-path=$HERE/PepperFlash/libpepflashplayer.so --disable-infobars --no-sandbox "$@"
# [279410113/090434.083302:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[27941
[27941
[280120113/090434.385120:ERROR:gl_surface_glx.cc(78)] XGetWindowAttributes failed for window 33554436.
[28012
[28012
[28012
[28012
(opera:27941): GLib-GIO-ERROR **: 09:04:34.404: Settings schema 'org.gnome.desktop.background' is not installed
[28012
[279410113/090434.737933:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[280420113/090435.320136:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[28042
[28042
[281010113/090435.593882:ERROR:gl_surface_glx.cc(78)] XGetWindowAttributes failed for window 33554436.
[28101
[28101
[28101
[28101
[28101
(opera:28042): GLib-GIO-ERROR **: 09:04:35.649: Settings schema 'org.gnome.desktop.background' is not installed
[280420113/090436.132279:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[281270113/090436.540974:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[28127
[28127
[281860113/090436.861888:ERROR:gl_surface_glx.cc(78)] XGetWindowAttributes failed for window 33554436.
[28186
[28186
[28186
[28186
[28186
(opera:28127): GLib-GIO-ERROR **: 09:04:36.915: Settings schema 'org.gnome.desktop.background' is not installed
Discarded=1
[279300113/090442.786103:ERROR:broker_posix.cc(40)] Recvmsg error: Connection reset by peer (104)
Discarded=1
[280150113/090443.169937:ERROR:broker_posix.cc(40)] Recvmsg error: Connection reset by peer (104)
Discarded=1
[281050113/090444.198005:ERROR:broker_posix.cc(40)] Recvmsg error: Connection reset by peer (104)
Discarded=1
[281900113/090445.470639:ERROR:broker_posix.cc(40)] Recvmsg error: Connection reset by peer (104)
0113/090432.892800:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
0113/090433.145439:ERROR:gl_surface_glx.cc(78)] XGetWindowAttributes failed for window 33554436.
0113/090434.083302:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
0113/090434.385120:ERROR:gl_surface_glx.cc(78)] XGetWindowAttributes failed for window 33554436.
0113/090434.737933:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
0113/090435.320136:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
0113/090435.593882:ERROR:gl_surface_glx.cc(78)] XGetWindowAttributes failed for window 33554436.
0113/090436.132279:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
0113/090436.540974:ERROR:object_proxy.cc(632)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
0113/090436.861888:ERROR:gl_surface_glx.cc(78)] XGetWindowAttributes failed for window 33554436.
0113/090442.786103:ERROR:broker_posix.cc(40)] Recvmsg error: Connection reset by peer (104)
0113/090443.169937:ERROR:broker_posix.cc(40)] Recvmsg error: Connection reset by peer (104)
0113/090444.198005:ERROR:broker_posix.cc(40)] Recvmsg error: Connection reset by peer (104)
0113/090445.470639:ERROR:broker_posix.cc(40)] Recvmsg error: Connection reset by peer (104) I had noticed a poster in the SCPup thread asking if anyone had got Opera running. But thought I should post something here when I found I couldn't get it running..
I'm using a Vivaldi in 64ScPup to post this and there seems a lot of similarity with Vivaldi and Opera. Becoming the 'devil I know'.
Thanks for your efforts.
David S.
Re: 64ScPup problem
delete
Last edited by s243a on Mon 13 Jan 2020, 01:19, edited 1 time in total.
Find me on [url=https://www.minds.com/ns_tidder]minds[/url] and on [url=https://www.pearltrees.com/s243a/puppy-linux/id12399810]pearltrees[/url].
Re: 64ScPup problem
Have you tried installing some of the missing dependencies such as: UPower, OpenGL.davids45 wrote:G'day Mike,
Now I understand your "Alice in Wonderland"-inspired avatar. With browsers, you need to run as fast as you can just to stay where you are.
I had success with your Opera Portable in 64Bionic8.0 but in peebee's latest 64ScPup, no go.
As usual, I run these via a symlink from the actual packages on my data partition - I put the Opera directory link into /opt and this was fine in 64Bionic8, as far as I went setting up the profile in /root/.config/ to eventually link this back to the data partition. I suspect I'll need separate profiles for Bionic and ScPups given the differences in lib file set-up between them.
Anyway, back to 'running on the spot',......
After initial nothingness in 64ScPup, I ran 'LAUNCH' from a terminal and got the below strings of messages:
Maybe you and Lewis Carroll can understand this?# cd /opt/Opera-portable
# ./LAUNCH
[27896
[27896
[27896
[27927
[27927
[27927
[27927
[27927
[27927
(opera:27896): GLib-GIO-ERROR **: 09:04:33.186: Settings schema 'org.gnome.desktop.background' is not installed
/mnt/sdb3/Puppy_Archive/OperaPortable64/Opera-portable/opera/opera-browser: line 9: 27896 Trace/breakpoint trap "$HERE/opera" --user-data-dir=$HERE/PROFILE --ppapi-flash-path=$HERE/PepperFlash/libpepflashplayer.so --disable-infobars --no-sandbox "$@"
# [27941
[27941
[27941
[28012
[28012
[28012
[28012
[28012
(opera:27941): GLib-GIO-ERROR **: 09:04:34.404: Settings schema 'org.gnome.desktop.background' is not installed
[28012
[27941
[28042
[28042
[28042
[28101
[28101
[28101
[28101
[28101
[28101
(opera:28042): GLib-GIO-ERROR **: 09:04:35.649: Settings schema 'org.gnome.desktop.background' is not installed
[28042
[28127
[28127
[28127
[28186
[28186
[28186
[28186
[28186
[28186
(opera:28127): GLib-GIO-ERROR **: 09:04:36.915: Settings schema 'org.gnome.desktop.background' is not installed
Discarded=1
[27930
Discarded=1
[28015
Discarded=1
[28105
Discarded=1
[28190
I had noticed a poster in the SCPup thread asking if anyone had got Opera running. But thought I should post something here when I found I couldn't get it running..
I'm using a Vivaldi in 64ScPup to post this and there seems a lot of similarity with Vivaldi and Opera. Becoming the 'devil I know'.
Thanks for your efforts.
David S.
**Note, I provided debian links. I'll try to find some slackware links for you. Also, mike can look into seeing if these libraries can be included as part of the portable.
Find me on [url=https://www.minds.com/ns_tidder]minds[/url] and on [url=https://www.pearltrees.com/s243a/puppy-linux/id12399810]pearltrees[/url].
Re: 64ScPup problem
Regarding the OpenGL issue, the following link looks relevant:
https://www.slackwiki.com/ATI_Graphics
also you should be able to install UPower via the package manger. I see that it is in the standard slackware repo:
https://mirrors.slackware.com/slackware ... /a/upower/
Find me on [url=https://www.minds.com/ns_tidder]minds[/url] and on [url=https://www.pearltrees.com/s243a/puppy-linux/id12399810]pearltrees[/url].
-
Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
Morning, all.
Hm. Well, after putting on my 'considering cap', I'm thinking there may have to be 'workarounds' for some Pups. I'd forgotten that the Slackware-based Puppies employ lib64, whereas in the 'buntu-based Pups lib64 is simply a sym-link to lib itself.
I had the same problem years ago when I first started putting the Chrome builds together; had to build separate packages for the two 'breeds'.
Whether or not we can find a way to combine these differences into a single, 'one-size-fits-all' Opera-portable package that everybody can use, I really don't know. Maybe using the internal 'libs' library that battleshooter helped enormously with a couple of years ago for the Chrome packages would help?
In fact, the more I think about it, I believe this was why I later found that a single Chrome build seemed to work on all Pups, and I was able to quit building separate packages altogether. All those missing items reported by David do exist in the Chrome 'libs' directory, so.....
I'll have a look into it later this afternoon; see what happens, like.
Watch this space, kiddiwinks. I'll report back.
-------------------------------
@ davids45:-
David, is this peebee's most recent 20.01 version? I need to make sure I'm getting the same variant as you're running, for 'testing' purposes...!
Mike.
Hm. Well, after putting on my 'considering cap', I'm thinking there may have to be 'workarounds' for some Pups. I'd forgotten that the Slackware-based Puppies employ lib64, whereas in the 'buntu-based Pups lib64 is simply a sym-link to lib itself.
I had the same problem years ago when I first started putting the Chrome builds together; had to build separate packages for the two 'breeds'.
Whether or not we can find a way to combine these differences into a single, 'one-size-fits-all' Opera-portable package that everybody can use, I really don't know. Maybe using the internal 'libs' library that battleshooter helped enormously with a couple of years ago for the Chrome packages would help?
In fact, the more I think about it, I believe this was why I later found that a single Chrome build seemed to work on all Pups, and I was able to quit building separate packages altogether. All those missing items reported by David do exist in the Chrome 'libs' directory, so.....
I'll have a look into it later this afternoon; see what happens, like.
Watch this space, kiddiwinks. I'll report back.
-------------------------------
@ davids45:-
David, is this peebee's most recent 20.01 version? I need to make sure I'm getting the same variant as you're running, for 'testing' purposes...!
Mike.
Multi-Architecture differences
Sometime --about that of the publication of Ubuntu Trusty Tahr-- debian/Ubuntu and Slackware diverged in how they handled 64-bit libraries. debian/Ubuntu assigned 64-bit libraries to various folders with the designation x86_64-linux-gnu while Slackware located them in folders with the designation /lib64. Puppies --for whatever reason-- are unable to find folders with the designation x86_64-linux-gnu. To work-around that, in debian/ubuntu 64-bit Puppies, they are relocated to the various folders just named /lib --which is where 32-bit libraries have always been located.
Slackos had no problem with finding libraries located in folders named /lib64. See this post, http://www.murga-linux.com/puppy/viewto ... 945#960945. In fact, debian/ubuntu puppies also have no problem finding libraries located in "lib64" folders. IIRC, when I discovered that I suggested that debian/ubuntu Puppies be modified to use /lib64 folders.
To do that, petget [and now pkg-cli] would have to be modified so that if a file in an input package was located in an x86_64-linux-gnu folder it would be output to a lib64 folder. Instead, apparently with Bionicpup64 --perhaps others-- such files are now automatically output to /lib.
In the meantime, following up on the work of battleshooter, watchdog and fredx181, we are now creating applications which locate libraries within the applications themselves. The result is that each application requiring the same libraries has it own copies, increasing the overall size of disk-space --and if I'm not mistaken RAM needed when a Puppy is running two applications using the same libraries but obtained from different locations.
So I wonder if it were possible to employ a variation of the battleshooter/watchdog/fredx181 approach in many instances to locate necessary libraries --which conflict with those of the operating system-- in one location, say /opt. And, as previously suggested, adapt all 64-bit Puppies to use /lib64 folders.
Slackos had no problem with finding libraries located in folders named /lib64. See this post, http://www.murga-linux.com/puppy/viewto ... 945#960945. In fact, debian/ubuntu puppies also have no problem finding libraries located in "lib64" folders. IIRC, when I discovered that I suggested that debian/ubuntu Puppies be modified to use /lib64 folders.
To do that, petget [and now pkg-cli] would have to be modified so that if a file in an input package was located in an x86_64-linux-gnu folder it would be output to a lib64 folder. Instead, apparently with Bionicpup64 --perhaps others-- such files are now automatically output to /lib.
In the meantime, following up on the work of battleshooter, watchdog and fredx181, we are now creating applications which locate libraries within the applications themselves. The result is that each application requiring the same libraries has it own copies, increasing the overall size of disk-space --and if I'm not mistaken RAM needed when a Puppy is running two applications using the same libraries but obtained from different locations.
So I wonder if it were possible to employ a variation of the battleshooter/watchdog/fredx181 approach in many instances to locate necessary libraries --which conflict with those of the operating system-- in one location, say /opt. And, as previously suggested, adapt all 64-bit Puppies to use /lib64 folders.
-
Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
@ Mike:-
You might be 'pushing it' to suggest that everybody re-build their Puppies to take account of a new, common resource location!
Having said that, it might be one way to take care of the 64-bit Chromium-based browsers, though.....although it would mean all of us pooling resources & 'pulling together' on this one..
I hear what you're saying, I really do. I know it's daft all of us duplicating the same libs in multiple locations; it adds 'weight', it consumes space unnecessarily.....but at least it does work.
------------------------
I'm about to fire-up Scpup64, and have a go at seeing if I can get Opera to run by adding-in the Chrome 'extra libs' directory, then pointing the browser to look there.
I may have knocked the Chrome packages on the head, but I still have all the resources!
T'other Mike.
You might be 'pushing it' to suggest that everybody re-build their Puppies to take account of a new, common resource location!
Having said that, it might be one way to take care of the 64-bit Chromium-based browsers, though.....although it would mean all of us pooling resources & 'pulling together' on this one..
I hear what you're saying, I really do. I know it's daft all of us duplicating the same libs in multiple locations; it adds 'weight', it consumes space unnecessarily.....but at least it does work.
------------------------
I'm about to fire-up Scpup64, and have a go at seeing if I can get Opera to run by adding-in the Chrome 'extra libs' directory, then pointing the browser to look there.
I may have knocked the Chrome packages on the head, but I still have all the resources!
T'other Mike.
64SCPup
G'day T'other Mike,
I'm fairly sure I'm using the latest version of peebee's 64ScPup - 20.01+1-T.
I'm using your portable Opera in 64Bionic to see how to keep its memory size down with links, to later share with 64ScPup when fixed, one way or t'other.
I'll then try to include these Opera links into my one-size-fits-all-apps sfs for my 64-bitPups (or more likely have two sfs, one for the Ubuntu derivatives, one for the Slacko/Sc Pups, which is how I run my 32-bit Pups).
Thanks (all) for your ideas,
David S.
I'm fairly sure I'm using the latest version of peebee's 64ScPup - 20.01+1-T.
I'm using your portable Opera in 64Bionic to see how to keep its memory size down with links, to later share with 64ScPup when fixed, one way or t'other.
I'll then try to include these Opera links into my one-size-fits-all-apps sfs for my 64-bitPups (or more likely have two sfs, one for the Ubuntu derivatives, one for the Slacko/Sc Pups, which is how I run my 32-bit Pups).
Thanks (all) for your ideas,
David S.
Hello Mike,
I want to let you know that the Opera-portable works perfectly running on WeeDog64 (Void Linux)
I want to let you know that the Opera-portable works perfectly running on WeeDog64 (Void Linux)
- Attachments
-
- 2020-01-13-185118_1280x1024_scrot.png
- (194.13 KiB) Downloaded 370 times
-
Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
Evening, boys & girls.
@ rockedge:-
Nice to hear, my son. That's another we can add to 'the list'....
--------------------
@ David:-
Now, then. This is quite a 'tangled-up *mish-mash*', from the look of it. I've just been experimenting in SCPup64 20.01.
I re-built a 'test' version of Opera to include the same internal 'libs' directory that my Chrome packages have been using for the last 2 or 3 years.....courtesy of battleshooter. It still runs without issue in both Xenial64 & Bionic64.
However; in SCPup64 20.01, after installing libpng12.so.0, I got all the exact same output as you did. I also, just for the hell of it (even though I've called a halt to it), tried the Chrome-portable package I put together a week or two back.
Chrome also gave the same output, and stuff about .org/freedesktop/UPower, etc.....but it went ahead & started. Opera, on the other hand - and I don't understand this, because I've never seen a Chromium-based 'clone do this before - gave all the same output, plus a few other lines about the system message bus, and just 'hung'; 'froze up'.
Usually, if the 'clones' don't like summat, they'll normally either quit or abort.....
Since this 'fat' version of Opera doesn't 'fix' the issue (and it seems to work everywhere else 'as-is'), I won't be uploading it. It's not necessary.....and it doesn't look to be a browser issue anyway, more a system one. As such, I would suggest consulting peebee on this one, since SCPup64's his 'baby'.
-------------------------------
I did a bit of digging. It appears that this 'uPower' thing has been around for several years (mentions of it are to be found as far back as Ubuntu 12.04 LTS), in successively newer versions. Its intention is to eventually replace the old HAL - the Hardware Abstraction Layer - the part of the kernel-space that allows the software & hardware to 'talk' to each other.
Here's its website:-
https://upower.freedesktop.org/
It appears that it's a kind of 'middleman' layer, and as such is being pulled into systemd. All the mainstream distros appear to be going down this route; Red Hat's Lennart Poettering has been exerting an utterly unholy influence over the community with his evil creation......and Slackware are no different. Further reading would seem to indicate that the overall intention is to make the lives of sysadmins as easy as possible.....and sod the poor 'user'.
I get the impression that the prevailing attitude seems to be 'Well, if you can't beat them, then you might as well 'git while the going's good', and join 'em...' Red Hat & co seem to be utterly convinced that the only way to beat Microsoft at their own game is take all the community's 'creations' and meld them together into a single, 'common' distro, where there is only ever going to be one 'approved' way of doing things, whether you like it or not......and 'free expression' will be thoroughly frowned-upon! And naturally enough, RedHat will be the ones dictating what will, and will not, be allowed.....
I sense IBM's hand assisting the 'stirring of the pot' in this.....there's no love lost between them and Microsoft. They have long memories, and hold a grudge near enough forever.
The days of the MyCrudSoft DOS 'debacle' are still fresh, as far as they're concerned.....
Top & bottom, systemd's involved with this 'upower' thing, one way or another. I hate systemd; loathe it with a passion.....and point-blank refuse to piss around trying to make software work with it. Normally I would bend over backwards to try and make things work with as many Pups as I can, but I draw the line at this. Sorry an' all that.
Mike.
@ rockedge:-
Nice to hear, my son. That's another we can add to 'the list'....
--------------------
@ David:-
Now, then. This is quite a 'tangled-up *mish-mash*', from the look of it. I've just been experimenting in SCPup64 20.01.
I re-built a 'test' version of Opera to include the same internal 'libs' directory that my Chrome packages have been using for the last 2 or 3 years.....courtesy of battleshooter. It still runs without issue in both Xenial64 & Bionic64.
However; in SCPup64 20.01, after installing libpng12.so.0, I got all the exact same output as you did. I also, just for the hell of it (even though I've called a halt to it), tried the Chrome-portable package I put together a week or two back.
Chrome also gave the same output, and stuff about .org/freedesktop/UPower, etc.....but it went ahead & started. Opera, on the other hand - and I don't understand this, because I've never seen a Chromium-based 'clone do this before - gave all the same output, plus a few other lines about the system message bus, and just 'hung'; 'froze up'.
Usually, if the 'clones' don't like summat, they'll normally either quit or abort.....
Since this 'fat' version of Opera doesn't 'fix' the issue (and it seems to work everywhere else 'as-is'), I won't be uploading it. It's not necessary.....and it doesn't look to be a browser issue anyway, more a system one. As such, I would suggest consulting peebee on this one, since SCPup64's his 'baby'.
-------------------------------
I did a bit of digging. It appears that this 'uPower' thing has been around for several years (mentions of it are to be found as far back as Ubuntu 12.04 LTS), in successively newer versions. Its intention is to eventually replace the old HAL - the Hardware Abstraction Layer - the part of the kernel-space that allows the software & hardware to 'talk' to each other.
Here's its website:-
https://upower.freedesktop.org/
It appears that it's a kind of 'middleman' layer, and as such is being pulled into systemd. All the mainstream distros appear to be going down this route; Red Hat's Lennart Poettering has been exerting an utterly unholy influence over the community with his evil creation......and Slackware are no different. Further reading would seem to indicate that the overall intention is to make the lives of sysadmins as easy as possible.....and sod the poor 'user'.
I get the impression that the prevailing attitude seems to be 'Well, if you can't beat them, then you might as well 'git while the going's good', and join 'em...' Red Hat & co seem to be utterly convinced that the only way to beat Microsoft at their own game is take all the community's 'creations' and meld them together into a single, 'common' distro, where there is only ever going to be one 'approved' way of doing things, whether you like it or not......and 'free expression' will be thoroughly frowned-upon! And naturally enough, RedHat will be the ones dictating what will, and will not, be allowed.....
I sense IBM's hand assisting the 'stirring of the pot' in this.....there's no love lost between them and Microsoft. They have long memories, and hold a grudge near enough forever.
The days of the MyCrudSoft DOS 'debacle' are still fresh, as far as they're concerned.....Top & bottom, systemd's involved with this 'upower' thing, one way or another. I hate systemd; loathe it with a passion.....and point-blank refuse to piss around trying to make software work with it. Normally I would bend over backwards to try and make things work with as many Pups as I can, but I draw the line at this. Sorry an' all that.
Mike.