vivaldi browser
Posted: Mon 02 Mar 2015, 19:29
Hi, phil.
Is it the same as this one?
BFN.
musher0
Page 1 of 5
Posted: Tue 03 Mar 2015, 02:34
Posted: Tue 03 Mar 2015, 08:51
i think it is , i just added pepperflash to it
Posted: Tue 03 Mar 2015, 11:48
I see. Thanks.
Posted: Tue 03 Mar 2015, 12:43
LxPup15.02 (and presumably Slacko6Beta2) needs libgconf-2 for Vivaldi to work - pet attached.
65mb, but Vivaldi browses better
Posted: Sat 11 Apr 2015, 00:50
65mb, but Vivaldi browses better 
Posted: Sat 11 Apr 2015, 06:06
Downloaded and installed in Tahr. Looks promising.
Thanks for the pet.
Thanks for the pet.
Posted: Mon 27 Apr 2015, 04:54
Test on Puppy Precise 5.7.1
After installing lbnss3 and libnspr from Ubuntu Precise repository I was able to run Vivaldi getting this terminal output:
YouTube videos play as usual, though.
Code: Select all
sh-4.1# vivaldi-snapshot
/opt/vivaldi-snapshot/vivaldi-bin: error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directory
sh-4.1# /usr/bin/vivaldi-snapshot: error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directoryCode: Select all
sh-4.1# vivaldi-snapshot
[12844:12844:0427/012809:INFO:audio_manager_pulse.cc(258)] Failed to connect to the context. Error: Connection refused
[12844:12844:0427/012810:WARNING:sxs_linux.cc(125)] Failed to read channels file.
ATTENTION: default value of option force_s3tc_enable overridden by environment.
getrlimit(RLIMIT_NOFILE) failed
getrlimit(RLIMIT_NOFILE) failed
getrlimit(RLIMIT_NOFILE) failed
[12838:12946:0427/012833:ERROR:channel.cc(258)] RawChannel read error (connection broken)
getrlimit(RLIMIT_NOFILE) failed
getrlimit(RLIMIT_NOFILE) failed
getrlimit(RLIMIT_NOFILE) failed
getrlimit(RLIMIT_NOFILE) failed
getrlimit(RLIMIT_NOFILE) failed
getrlimit(RLIMIT_NOFILE) failed
getrlimit(RLIMIT_NOFILE) failed
getrlimit(RLIMIT_NOFILE) failed
[WARNING:flash/platform/pepper/pep_module.cpp(63)] SANDBOXED
getrlimit(RLIMIT_NOFILE) failed
getrlimit(RLIMIT_NOFILE) failed
getrlimit(RLIMIT_NOFILE) failedPosted: Tue 28 Apr 2015, 04:05
Tried the .pet in Quirky April 7.0.3. Nothing happened so I:
# vivaldi-snapshot -D
/opt/vivaldi-snapshot/vivaldi-bin: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory
vivaldi on older hardware
Posted: Tue 28 Apr 2015, 17:55
I downloaded the 140MB vivaldi tar (embedded in a deb) from
their site, used ar in another linux to extract data.tar
and unpackaged with tar. Says my hardware is too old.
Anyone know the hardware requirements?
My DELL Inspiron 8100 is 1GHz. Hard to find good laptops
without widescreen and glare.
their site, used ar in another linux to extract data.tar
and unpackaged with tar. Says my hardware is too old.
Anyone know the hardware requirements?
My DELL Inspiron 8100 is 1GHz. Hard to find good laptops
without widescreen and glare.
Posted: Tue 28 Apr 2015, 19:03
Flash, it looks like you need the gconf dotPET posted by peebee, above...Flash wrote:Tried the .pet in Quirky April 7.0.3. Nothing happened so I:# vivaldi-snapshot -D
/opt/vivaldi-snapshot/vivaldi-bin: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory
Posted: Tue 28 Apr 2015, 19:44
Thanks. I installed it, now I get a different error:
# vivaldi-snapshot -D
/opt/vivaldi-snapshot/vivaldi-bin: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory
# /usr/bin/vivaldi-snapshot: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory
Posted: Wed 29 Apr 2015, 00:28
Those are symlinks. You should have libudev.so.[...] (where [...] represents the version numbering, in Caro Vanguard it's libudev.so.0.11.1) somewhere in /lib -- just create a relative link from it, entitled libudev.so.0 and you'll be OK. (That's lib udev dot ess oh dot zero!)
Posted: Wed 29 Apr 2015, 23:22
Thanks. Quirky April has libudev.so.1.6.0 in /lib. I right-clicked on it in Rox and chose Link, then created a Symlink to it named libudev.so.0. Now, when I enter vivaldi-snapshot in a urxvt window, I get this:
There's nothing that begins with libdbus in /lib and Pfind finds nothing in all of April when I search for libdbus*# vivaldi-snapshot
/opt/vivaldi-snapshot/vivaldi-bin: error while loading shared libraries: libdbus-1.so.3: cannot open shared object file: No such file or directory
# /usr/bin/vivaldi-snapshot: error while loading shared libraries: libdbus-1.so.3: cannot open shared object file: No such file or directory
Posted: Thu 30 Apr 2015, 00:10
Sounds like you need a DBus package, doesn't it! 
I'm not familiar with Quirky April or any of the other pseudoPups that BK has been cooking up since his apparent retirement. However, if it's 32 bit and compatible with dotPET packages, I would snap up what's on the wikka, and I'd probably grab dbus-glib while I was at it, just in case.
http://puppylinux.org/wikka/dbus
http://puppylinux.org/wikka/dbusglib
There are download links on each linked page. In the case of the DBus page (the first link) you probably would want the newer link -- that would be, of the two possibilities, the one that's higher on the page.
By the way, this is the process I refer to as 'libhunting' -- somebody didn't expect you to need these libs, and now you're left to track 'em down. In defense of the dev who left 'em out, well, you really can't expect to have every single support package in existence in your distro... I don't think even eg Debian does that! ...that said, DBus is pretty basic, as I understand it...
I'm not familiar with Quirky April or any of the other pseudoPups that BK has been cooking up since his apparent retirement. However, if it's 32 bit and compatible with dotPET packages, I would snap up what's on the wikka, and I'd probably grab dbus-glib while I was at it, just in case.
http://puppylinux.org/wikka/dbus
http://puppylinux.org/wikka/dbusglib
There are download links on each linked page. In the case of the DBus page (the first link) you probably would want the newer link -- that would be, of the two possibilities, the one that's higher on the page.
By the way, this is the process I refer to as 'libhunting' -- somebody didn't expect you to need these libs, and now you're left to track 'em down. In defense of the dev who left 'em out, well, you really can't expect to have every single support package in existence in your distro... I don't think even eg Debian does that! ...that said, DBus is pretty basic, as I understand it...
Posted: Thu 30 Apr 2015, 02:40
Thanks, it might be a day or two before I can get to that.
The Vivaldi .pet is 61 MB. How much larger would it be if it included the more obscure libs Vivaldi needs to run? I think what I'm talking about is an application in a directory, or perhaps a Rox app. There are many libs that every Puppy can be expected to have. Those don't need to be included -- unless they're tiny, in which case might as well include them too.starhawk wrote:... you really can't expect to have every single support package in existence in your distro... I don't think even eg Debian does that! ...that said, DBus is pretty basic, as I understand it...
Posted: Thu 30 Apr 2015, 03:00
...and what, pray tell, happens if Puppy already has the libs you need? For example, Caro Vanguard has libdbus (...which, BTW, should be in /usr/lib -- check there before you download!).
To answer my own question -- what happens is file clobber that breaks stuff. It's far better to have the user go off libhunting for a little bit, than to have applications that break other parts of the OS when you install them!
Applications in a directory are the basis for how Linux works, really -- and dotPET packages generally do not (if ever at all) contain ROXApps. Remember that a dotPET is a tarball (*.tar.gz archive) that has an MD5sum plunked into it such that PetGet can tell when the package has corrupted... if you were to convert a dotPET to a regular tarball and open it in eg PupZip, you'd find directories like /usr and /etc and such in there. The files within that directory hierarchy are plunked down into the appropriate places in the filesystem. All PetGet really does is verify the package, unpack it, read the directory tree, and plunk files where they go. It's not *that* complicated. Certainly not rocket science!
To answer my own question -- what happens is file clobber that breaks stuff. It's far better to have the user go off libhunting for a little bit, than to have applications that break other parts of the OS when you install them!
Applications in a directory are the basis for how Linux works, really -- and dotPET packages generally do not (if ever at all) contain ROXApps. Remember that a dotPET is a tarball (*.tar.gz archive) that has an MD5sum plunked into it such that PetGet can tell when the package has corrupted... if you were to convert a dotPET to a regular tarball and open it in eg PupZip, you'd find directories like /usr and /etc and such in there. The files within that directory hierarchy are plunked down into the appropriate places in the filesystem. All PetGet really does is verify the package, unpack it, read the directory tree, and plunk files where they go. It's not *that* complicated. Certainly not rocket science!
Posted: Thu 30 Apr 2015, 03:45
I thought an application-in-a-directory included in the directory everything the app needs to run. Almost like a binary. That way, the app would know right where a needed library was. No other app in the computer would know that particular library was in that particular directory, so there would be no collision. Am I wrong about how that works?
Posted: Thu 30 Apr 2015, 16:00
The binary is the executable part of the code. Everything else included supports it. However -- the person or people creating the package (not just a binary!) make certain assumptions about the filesystem content outside of that package -- the environment into which the package will be installed.
Generally you don't package all required supporting libs in with a binary. You /can/ do that, but then you end up with a boatload of duplicates. /usr/lib exists for a reason, you know
Let's look at Chromium, my web browser of choice. There is a shell script at /usr/bin/chromium, but the actual binary is /usr/lib/chromium/chromium (oddly enough, with a lib icon, dunno why, it's not a *.so). There are supporting libs in /usr/lib/chromium, but those are not the only required libs by any means. Pepperflash is included with this particular Chromium (one of peebee's SFSs) and that's hanging around somewhere. Strictly speaking it's 'recommended' rather than 'required' in that Chromium will run without Pepperflash -- but then you don't get flash content, only HTML5 (etc) and that's kind of a downer.
However, if I install that SFS into Carolina Vanguard, open a terminal and type chromium [ENTER] -- I will get an error message, about a missing symlink having to do with libevent, which (as I understand it) is a thing that lets callbacks occur when something happens to a file. (Remember that everything is a file in Linux, and that libraries --'libs'-- add capabilities to the binaries within a filesystem. libjpeg, for example, allows binaries to, well, do stuff with JPEG files, for example.) You can find more info on libevent at its website.
So, Chromium's developers, and the people who packaged it up for us (peebee repackages Slackware TXZs from a guy calls himself 'alienbob', so there's a couple folks involved there), made an assumption that libevent would be present in some form in whatever distro it was plunked into. In most cases that's probably a safe assumption. However, in Carolina Vanguard, it isn't, and libevent becomes a dependency ('dep'). In this case it's the only one. You haven't been so lucky with Vivaldi, apparently, but that does happen. In particular, it happens a lot when you're pulling in stuff from other distros. So, for example, if I install an application from say Slackware 14.1 into TahrPup, because TahrPup does Ubuntu better than Slackware, I'll quite likely have a fat pile of deps (mostly libs) to hunt down. What is a safe assumption about Slackware 14.1's filesystem contents, is not necessarily so for Ubuntu Trusty Tahr.
Make sense?
Generally you don't package all required supporting libs in with a binary. You /can/ do that, but then you end up with a boatload of duplicates. /usr/lib exists for a reason, you know
Let's look at Chromium, my web browser of choice. There is a shell script at /usr/bin/chromium, but the actual binary is /usr/lib/chromium/chromium (oddly enough, with a lib icon, dunno why, it's not a *.so). There are supporting libs in /usr/lib/chromium, but those are not the only required libs by any means. Pepperflash is included with this particular Chromium (one of peebee's SFSs) and that's hanging around somewhere. Strictly speaking it's 'recommended' rather than 'required' in that Chromium will run without Pepperflash -- but then you don't get flash content, only HTML5 (etc) and that's kind of a downer.
However, if I install that SFS into Carolina Vanguard, open a terminal and type chromium [ENTER] -- I will get an error message, about a missing symlink having to do with libevent, which (as I understand it) is a thing that lets callbacks occur when something happens to a file. (Remember that everything is a file in Linux, and that libraries --'libs'-- add capabilities to the binaries within a filesystem. libjpeg, for example, allows binaries to, well, do stuff with JPEG files, for example.) You can find more info on libevent at its website.
So, Chromium's developers, and the people who packaged it up for us (peebee repackages Slackware TXZs from a guy calls himself 'alienbob', so there's a couple folks involved there), made an assumption that libevent would be present in some form in whatever distro it was plunked into. In most cases that's probably a safe assumption. However, in Carolina Vanguard, it isn't, and libevent becomes a dependency ('dep'). In this case it's the only one. You haven't been so lucky with Vivaldi, apparently, but that does happen. In particular, it happens a lot when you're pulling in stuff from other distros. So, for example, if I install an application from say Slackware 14.1 into TahrPup, because TahrPup does Ubuntu better than Slackware, I'll quite likely have a fat pile of deps (mostly libs) to hunt down. What is a safe assumption about Slackware 14.1's filesystem contents, is not necessarily so for Ubuntu Trusty Tahr.
Make sense?
Vivaldi abort
Posted: Sat 22 Aug 2015, 16:04
Excuse my bad English. I used Google Translate.
I installed the pet Vivaldi, libraries were missing and what I did was I copied the libraries that come in my firefox 40.0.2 because they are the same that appeared me in terminal. Now, in trying to run it, this appears in terminal. I'm using X-Precise.
http://postimg.org/image/gsvf4y4yz/
I installed the pet Vivaldi, libraries were missing and what I did was I copied the libraries that come in my firefox 40.0.2 because they are the same that appeared me in terminal. Now, in trying to run it, this appears in terminal. I'm using X-Precise.
http://postimg.org/image/gsvf4y4yz/