-
-
Save ruario/99522c94838d0680633c to your computer and use it in GitHub Desktop.
This won't work on 32 bit installs, will it?
This method fails for me on Fedora 20.
The first step finishes without any errors.
But running:
tar -C/ -xvf data.tar --xform='s,(/usr/),\1local/,' --show-stored-names
Returns:
tar: This dosent look like a tar-archive
tar: Jumps to next session
tar: Exiting with failure status due to previous errors
(May be unprecise translations, had to translate it from my language.)
@DoctorJellyface: No
@SSamiK: file data.tar
reports what?
Nevermind! Just tried it again, and now it worked. Must have had a typo somewhere in there.
New errors now. Some shared libraries that are missing or not found.
They hardcode the versions of OpenSSL library, so in Fedora(after creation of symlinks to current library versions) i've receive the following:
opera-developer: /usr/local/lib/x86_64-linux-gnu/opera-developer/lib/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by opera-developer)
opera-developer: /usr/local/lib/x86_64-linux-gnu/opera-developer/lib/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by opera-developer)
Same for me, Arilas.
Something similar for me too on Sabayon, but Opera still runs without problems.
I had the same problem, tried linking to libssl and libcrypto that is provided in the steam runtime. It solves the version error but now I just have a segfault.
Edit:
Opera works on Fedora 20, using steam libssl and libcrypto but, it segfaults unless you run as root.
@YeOK Those getting crash on start up could you try running Opera from a terminal like so:
opera-developer --with-feature:first-run-import=false &
If that helps it is a crash that happens on importing settings from Chrome, and it occurs when Chrome is your default browser.
The switch can be used as a workaround, and the next build that we will release will include the real fix.
I have updated the top section linking to a couple of scripts I wrote that automate the entire process.
opera-developer for archlinux can be found in [herecura-testing] http://repo.herecura.eu/
it includes a wrapper script and the chrome-pepper-flash provided in [herecura-stable] works perfectly fine with it
the pkgbuild and scripts can be found https://github.com/herecura/herecura/tree/master/testing/opera-developer
@BlackIkeEagle: Thanks!
Yeah, it works when I disable the first run import . Thanks.
Thanks a lot. I've created a spec file for Fedora. Check my repo:
https://github.com/nobuyuki-ito/opera-developer-fedora-rpm
On Fedora 18( a little old version...), oepra developer works fine but for youtube video.
@nobuyuki-ito: Great work. The only thing I would say is that you needn't suggest the user manually setup a libudev symlink. Instead your package can include one, i.e. a symlink called /usr/lib64/opera-developer/lib/libudev.so.0
that points to /usr/lib64/libudev.so.1
.
If you have any other libs that you want Opera to have available you can also copy or symlink them into the /usr/lib64/opera-developer/lib
directory, thus avoiding clutter in the main system directories, where you could cause unintended problems.
If you intend that package to also work on systems that actually have libudev.so.0
, you could get really clever and set it up in the post install script, only if it is needed. Of course, if all distros and distro version you intend to support use /usr/lib64/libudev.so.1
then it would be an overkill and bundling the symlink directly in the package would suffice.
Nonetheless here is an example of what I mean from the post install of our Debian package. It has this function, which it later calls:
add_udev_symlinks() {
LIBUDEV_0=libudev.so.0
LIBUDEV_1=libudev.so.1
if [ -f "/lib/x86_64-linux-gnu/$LIBUDEV_0" -o -f "/usr/lib/x86_64-linux-gnu/$LIBUDEV_0" -o -f "/lib/$LIBUDEV_0" ]; then
return 0
fi
if [ -f "/lib/x86_64-linux-gnu/$LIBUDEV_1" ]; then
mkdir -p "/usr/lib/x86_64-linux-gnu/opera-developer/lib"
ln -snf "/lib/x86_64-linux-gnu/$LIBUDEV_1" "/usr/lib/x86_64-linux-gnu/opera-developer/lib/$LIBUDEV_0"
elif [ -f "/usr/lib/x86_64-linux-gnu/$LIBUDEV_1" ]; then
mkdir -p "/usr/lib/x86_64-linux-gnu/opera-developer/lib"
ln -snf "/usr/lib/x86_64-linux-gnu/$LIBUDEV_1" "/usr/lib/x86_64-linux-gnu/opera-developer/lib/$LIBUDEV_0"
else
echo "$LIBUDEV_1" not found in "lib/x86_64-linux-gnu" or "/usr/lib/x86_64-linux-gnu".
exit 1
fi
}
The pre-removal script uses this function:
remove_udev_symlinks() {
LIBUDEV_0=libudev.so.0
if [ -f "/usr/lib/x86_64-linux-gnu/opera-developer/lib/$LIBUDEV_0" ]; then
rm -rf "/usr/lib/x86_64-linux-gnu/opera-developer/lib/$LIBUDEV_0"
rmdir --ignore-fail-on-non-empty "/usr/lib/x86_64-linux-gnu/opera-developer/lib"
fi
}
P.S. if you look at my own scripts (install-opera and standalone-opera), you will see that I do similar tricks.
opera developer works fine but for youtube video.
I suspect you don't have Pepper Flash installed. Opera for Linux only supports PPAPI plugins, not NPAPI. Currently the only source for Pepper Flash is Chrome itself (it bundles Pepper Flash) or on some distros, like Debian/Ubuntu, a package is provided extracts Pepper from Chrome and puts it in its own directory.
Opera will look for the directories used by Chrome or the Debian/Ubuntu Pepper Flash package and if found use it. On Fedora you could get Flash working either by installing Chrome (you don't actually have to use it as your browser, being installed is enough) or by extracting the plugin and placing it in the Debian location.
Alternatively if there already is a package that provides Pepper Flash on Fedora, let us know which path it uses and we can get Opera to scan that as well.
@ ruario
I have Google Chrome Unstable installed. It looks like Opera only checks for the stable chrome directory when searching for pepper flash. A symlink added to '/opt/google/chrome' confirms PepperFlash is working.
Google use '/opt/google/chrome-beta' and '/opt/google/chrome-unstable'.
@ruario
I updated the spec file. Now rpm post scriptlet automatically creates symlink to libudev.so.1. Thanks for your good advice. I think your sh function is useful for installation for CentOS or Redhat variant in case of they don't know where libudev.so.0 is located at.
After I installed 'google-chrome-stable' package from Google, opera-developer detected pepper flash player plugin. It works on some websites including flash plugin contents.
Adobe Flash Player
Version: 14.0.0.125
disabled
Shockwave Flash 14.0 r0
Location: /opt/google/chrome/PepperFlash/libpepflashplayer.so
Type: PPAPI (out-of-process)
opera://plugins/
Now that the OpenSSL problems are gone, repackaging should be easier
I cant get either the fedora.spec file or the standalone installer in this threat to work with latest Opera developer.
With the standalone installer I get this:
./run: line 2: /home/SSamiK/opera-developer_25.0.1606.0_amd64/: Er en filkatalog
./run: line 2: exec: /home/SSamiK/opera-developer_25.0.1606.0_amd64/: cannot execute: Er en filkatalog
@SSamiK Most likely due to the change of name of the binary from opera to opera-developer. I have now fixed the standalone installer.
@nobuyuki-ito @Arilas @SSamiK @YeOK You do not need libssl libs from Ubuntu to get Opera working on fedora. A simple symlink will do. I have updated my instructions above and my own sample install scripts.
That SlackBuild from me is outdated. Please update the link to http://blog.t-rg.ws/uploads/opera.tar.gz or to my repo: https://github.com/fsLeg/SlackBuilds/tree/master/opera. The new SlackBuild can build both Developer and Beta flavors and can optionally build local version of FFmpeg.
On Fedora 20 and with Opera Beta 26.0.1656.27 I had to install libXss and make a symlink:
ln -sf /usr/lib64/libXss.so.1 /usr/local/lib64/opera-beta/lib/libXss.1
@fsLeg done. Thanks!
@RLndggr I checked and I did not need to do this with Opera 26.0.1656.32. Yes we depend on /usr/lib64/libXss.so.1 (provided by the libXScrnSaver
package) but no compatibility symlink is required.
libXScrnSaver
should already be present on a typical Fedora desktop install. However, if it is missing, you can simply issue the command:
yum install libXScrnSaver
FYI: I modified Fedora rpmbuild script to package opera for OpenSUSE.
@kikonen Thanks! I have added you above.
P.S. There is no need to do anything special for libssl on OpenSUSE ;)
Most of the rpm .spec files I have found use overly complicated workarounds for libcrypto (by bundling libs) and create rpms that will on work on specific distro releases by including libudev compatibility symlinks, rather than making them on the fly (as needed) in post install. I have therefore created some examples to demonstrate how I would deal with these issues.
I wouldn't trust alien as far as I could throw it personally but if you do, by all means use it.