Vivaldi 32-bit not installing
-
Hello all.
I'm trying to re-install Vivaldi on my 32-bit laptop, running Fedora Linux 27, once I run the RPM installer, I get the following:
# rpm -ivh vivaldi-stable-1.14.1077.60-1.i386.rpm
error: Failed dependencies:
libffmpeg.so is needed by vivaldi-stable-1.14.1077.60-1.i386
libnss3.so(NSS_3.22)(64bit) is needed by vivaldi-stable-1.14.1077.60-1.i386
libssl3.so(NSS_3.28)(64bit) is needed by vivaldi-stable-1.14.1077.60-1.i386I've since found the libffmpeg.so library in the qmplay2 package, but the RPM is still looking for it and why would the 32-bit version be looking for 64-bit libraries?
Update: the vivaldi.repo file was in the /etc/yum.repos.d directory and received this when I tried to install via that:
**# dnf install vivaldi-stable
Last metadata expiration check: 2:05:44 ago on Tue 24 Apr 2018 06:31:25 PM EDT.
Error:
Problem: conflicting requests- nothing provides libffmpeg.so needed by vivaldi-stable-1.14.1077.60-1.i386**
So, it's still looking for libffmpeg.so. I removed the qmplay2 package as it is QT related.
Update #2: If libffmpeg.so is part of the ffmpeg package, it's already installed.
Last metadata expiration check: 2:37:43 ago on Tue 24 Apr 2018 06:31:25 PM EDT.
Package ffmpeg-3.3.7-1.fc27.i686 is already installed, skipping.
Dependencies resolved.
Nothing to do.
Complete! -
@gwen-dragon If the steps outlined on those pages must be performed each and every time Vivaldi is updated, then it's not worth the trouble.
Thank you for the reply.
-
@edwardp these steps describe how to get proprietary media support for Vivaldi and are caused by licensing issues.
Depending on distro and browser the amount of needed manual steps or compromises (ship 3rd party blobs) varies.@gwen-dragon does vivaldi not include a (limited)
libffmpeg.so
for RPM like it does for DEB packages?
If so making this a hard dependency seems to be a packaging error.
And the64bit
dependencies indeed look like one… -
@gwen-dragon Fedora does not. However, I have Chromium installed, but must download Pepper Flash from Adobe's web site, then manually extract the files into a certain sub-directory used by Chromium.
If these same files must be extracted to a directory used by Vivaldi, if it doesn't load the files from the Chromium directory automatically, please advise.
-
@gwen-dragon seems to be a packaging errors (also in
vivaldi-stable-1.15.1147.36-1.i386.rpm
).There is a
libffmpeg.so
in the package, but also listed in requirements.
This also applies to the 64bit RPM package.
Might be overcome if Chromium is installed and avertises its version.The explicit
64bit
requirements in thei386
package will never be satisfied on a pure 32bit install.
libnss3.so(NSS_3.22)(64bit)
is a bad duplicate oflibnss3.so(NSS_3.22)
,
libssl3.so(NSS_3.28)(64bit)
needs to be replaced completely (or removed? Could not find anything in the package using it (64bit also)?). -
@gwen-dragon VB-39553 only tackles (at least given its name) a (maybe even resolvable) part of the problem and applies to 64bit and 32bit packages equally.
The plattform mismatch requirement only applies to the
i386
version and may be a not yet tracked (independent) issue.
If the test platform is a 32bit environment on a native 64bit system this one falls through the cracks.
No problem if they are resolved together in one go, but just to make shure. -
@gwen-dragon done
VB-39727: Bad 64bit dependencies for i386 RPM packageMaybe should have faked System to
Linux i686
for better discoverability… -
@gwen-dragon /usr/lib/adobe-flashplugin/ doesn't exist.
https://docs.fedoraproject.org/quick-docs/en-US/installing-chromium-or-google-chrome-browsers.html shows where the Pepper Flash tar file is extracted, with Chromium installed on 64-bit.
On 32-bit, it's extracted in /usr/lib/chromium-browser/PepperFlash/
-
Will an announcement be made once this problem is resolved (apparent packaging error)?
-
@edwardp It's come to the attention of the developers, and will be remedied. If I see that it's corrected before there's an announcement, I'll let you know here.
-
@becm I have Chromium installed on the same system (from the Fedora package) and it runs fine. The only thing I have to do occasionally, is manually update Pepper Flash.
-
@edwardp said in Vivaldi 32-bit not installing:
libffmpeg.so is needed by vivaldi-stable-1.14.1077.60-1.i386
libnss3.so(NSS_3.22)(64bit) is needed by vivaldi-stable-1.14.1077.60-1.i386
libssl3.so(NSS_3.28)(64bit) is needed by vivaldi-stable-1.14.1077.60-1.i386When I attempted to install the latest Vivaldi, the references to libssl3.so/libnss3.so (64bit) did not appear, however the reference to libffmpeg.so, did.
Unfortunately, I neglected to mention that I also have Vivaldi installed on 64-bit Fedora 27, it installed and works perfectly, including YouTube and all audio. I also have Google Chrome installed, as well as Chromium. Vivaldi is using PepperFlash that installed with Google Chrome per the vivaldi://about screen.
I just checked /usr/lib64 and there is no libffmpeg.so file in there. I also ran the command
find -name "libffmpeg.so"
and it found no such file.
What could then be missing on the 32-bit system?? If Vivaldi is looking for PepperFlash to resolve this, how can I get Vivaldi to use the PepperFlash in the chromium-browser/PepperFlash directory?
UPDATE:
This is what I have been able to determine so far:
-
Both 64-bit and 32-bit Fedora 27 installations, do not have libffmpeg.so installed.
-
64-bit Vivaldi installs, updates and runs fine without any audio issues.
-
32-bit Vivaldi installed fine using the --nodeps addition to the rpm command and it also launches without issue. Tested audio at YouTube, https://www.audiocheck.net/ which has an HTML5 audio file and also at https://www.onlinemictest.com/sound-test/. The audio at all three sites, played perfectly.
-
I installed the PepperFlash RPM from Adobe, it installed in its own directory, which Vivaldi is retrieving it from.
I am now of the opinion that libffmpeg.so isn't required by Vivaldi and that perhaps a packaging error remains with the 32-bit version.
-
-
@gwen-dragon maybe give them a heads-up, the next inconvenience is on the way (Stabel and Snapshot):
Ubuntu 18.04 bumped default version tolibappindicator3-1
and movedlibappindicator1
touniverse
repo,which is disabeld in a default install.
Update: Repo limitation applies to live system only, not installed variants.The
gtk3
version is included sinceDebian wheezy
andUbuntu trusty (14.04)
, a linking/dependency update should be possible.
This would also further a completegtk2
→gtk3
transition.Vivaldi runs fine on
Debian 9.4
withoutgtk2
orlibappindicator1|3
(manual archive extraction).
I guess it already is a (optional)dlopen
kind of library insertion or not even needed at all. -
@gwen-dragon bug reported.
VB-40045: Required dependency missing on Ubuntu 18.04Link to
libindicator1
availability and my previous post included.And of course, now I realize that Required dependency not available on Ubuntu 18.04 would have been a much better title…
-
@gwen-dragon Yay \o/, thank you!
Everybody should have a post-hit-send-spell-correct-dragon!I vow to attempt not to require such interventions in the future.
-
@gwen-dragon during live run only
main
andrestriced
repositories are active (updated post 209776).
But if more get activated by default on install the severity of this issue may not be as pressing as I feared.
So it may indeed only beVB-40045: Required dependency moved to 'universe' repo on Ubuntu 18.04
which is still a move from Canonical-supported (
main
) to Community-maintained (universe
) starting with this release.
But there goes my resolution to not require subsequent title changes…I need to make another (fresh) install, so I'll take this chance to see where I (quite possibly) made changes during installation.
Can confirm all repos activated, even for newMinimal Install
option and without network connectivity.
All required packages exceptlibappindicator1
(and its alsouniverse
-dependencylibindicator7
) are already installed.
Whereaslibappindicator3-1
is already in the default minimal desktop install set as well.Going forward, a switch to the Gtk3 variant would make the (now) required
apt -f install
package fixup step obsolete, since it already seems to be the more common requirement for contemporary software even in
Ubuntu 16.04
. -
Are there any updates on this?
Updating the package via dnf in Fedora, the new version still looks for libffmpeg.so and when I attempted to install the rpm package once downloaded, that would not install, even using the --nodeps flag, as it was also looking for libffmpeg.so, as well as the same reference to the other two items mentioning 64-bit.
-
@ayespy Yes. TWO months ago.
Meanwhile...
rpm -ivh vivaldi-stable-1.15.1147.52-1.i386.rpm --force
error: Failed dependencies:
libffmpeg.so is needed by vivaldi-stable-1.15.1147.52-1.i386
libnss3.so(NSS_3.22)(64bit) is needed by vivaldi-stable-1.15.1147.52-1.i386
libssl3.so(NSS_3.28)(64bit) is needed by vivaldi-stable-1.15.1147.52-1.i386I fail to see why this should take two months (and counitng...) to fix this, especially where this is a proprietary product, not open-source.
The --force command should have installed this without the dependencies. So perhaps there is another issue with the package.
-
As for libffmpeg.so it's easy to get a tarball.
-
@gwen-dragon the issue
VB-39727: Bad 64bit dependencies for i386 RPM package
references this as well and has a hint why this may not be detected in default tests.@lamarca a (hard)
libffmpeg.so
dependency is still wrong and has to be removed.
The existence of the Chromium variant seems to not sattisfyrpm
.
More general locations are ignored forcheckffmpeg()
in Vivaldi startup script.
The reduced free codec variant included in the package meets all requirements on installation.If anything this is a weak dependency.
But so would belibappindicator3
(updatedVB-40045
with hopefully better explanation).