CrossOver Support - Community Forums

I just upgraded from Fedora 11 to 12 (KDE), and found that I could no longer install Crossover from RPM.

Kpackagekit straight-up failed without a warning message of any kind.

Using yum, it fails with "Package crossover-games-demo-8.1.0-1.i386.rpm is not signed"

When installing on Fedora 11, Kpackagekit and yum both used to warn that the package was unsigned, and then ask for root authentication (again) to proceed. On 12 either this is no longer an option (which seems odd), this is a bug, or I upgraded incorrectly. In any case, my system wouldn't allow me to install an unsigned package, at all.

To work around, I edited /etc/yum.conf

and changed "gpgcheck" from "1" to "0". This leaving this "0" setting in place is probably inadvisable, but switching it temporarily will allow yum to install the Crossover rpm in the absence of signature.

If anyone knows who to enable yum/kpackagekit to ask about missing signatures once more, I'm all ears...

cheers!

cant you use the sh with fedora core 12?
thats what i used to do anyway

very true.

I like installing the rpm to make sure that i've got all of the requisite packages - our rpm will install most missing libraries that it finds, whereas the .sh has no ability to search for and install dependencies. This is particularly useful on 64-bit systems.

I am having problems with this on fedora 13 as well and tried to do the same chaning from 1 to 0. I had the demo installed a while ago and went to buy it today. It would not let me register so I tried downloading the full thing and wouldn't install. So I tried uninstalling the demo to install the full version and it still wouldn't install. So now I just paid 40 bucks and am getting a "not signed" after using the demo.

Hi,

Just wondering if you've tried the shell installer (.sh) as well?

Cheers!

That I have not. I'm pretty new to linux so I don't know anything about .sh

Hi again,

You can download that installer from ;

http://www.codeweavers.com/account/downloads/

Then you can view the install help page at;

http://www.codeweavers.com/support/docs/crossover-pro/install

The same procedure works for pro/std/games. As Jack mentions,
the benefit of using the .rpm is that it will pull in all the
required dependencies -- the shell installer will not, however
if you use your package manager to install wine, that usually
pulls in the same required dependencies...

Let us know how you get on....

Cheers!

ps: this isn't the first time I've seen this issue btw ; typically
it's caused by a change in distro's makeup between releases.

Thanks

Since I've already installed this before shouldn't I still have all the required dependencies?

Quite likely, it's easy enough to determine the position as well
manually by using the 'cxdiag' command after crossover is installed.

Open a shell/xterm and issue one of the following commands;

[if you installed into /opt]

/opt/cxoffice/bin/cxdiag --debug

[if you installed into your user directory]

~/cxoffice/bin/cxdiag --debug

The terminal output is fairly self explanatory, but if you get
stuck with anything post back here.

Cheers!

ok I ran /opt/cxoffice/bin/cxdiag --debug in terminal

libcapi20.so.3: cannot open shared object file: No such file or directory
[MissingLibCapi20]
"Level"="Suggest"
"Title"="Missing 32bit libcapi20.so.3 library"
"Description"="Provides support for some ISDN cards. Very few applications need this."

libxslt.so: cannot open shared object file: No such file or directory
[MissingLibXslt]
"Level"="Recommend"
"Title"="Missing 32bit libxslt.so library"
"Description"="This library lets Windows applications perform queries and transformations on XML files."

libcrypto.so.0.9.8: cannot open shared object file: No such file or directory
libcrypto.so.0.9.7: cannot open shared object file: No such file or directory
libcrypto.so.0.9.7a: cannot open shared object file: No such file or directory
libcrypto.so.0.9.7f: cannot open shared object file: No such file or directory
libcrypto.so.0.9.8: cannot open shared object file: No such file or directory
libcrypto.so.0.9.8a: cannot open shared object file: No such file or directory
libcrypto.so.0.9.8g: cannot open shared object file: No such file or directory
libcrypto.so.0.9.8k: cannot open shared object file: No such file or directory
libcrypto.so.1.0.0: cannot open shared object file: No such file or directory
found libcrypto.so.10
libssl.so.0.9.8: cannot open shared object file: No such file or directory
libssl.so.0.9.7: cannot open shared object file: No such file or directory
libssl.so.0.9.7a: cannot open shared object file: No such file or directory
libssl.so.0.9.7f: cannot open shared object file: No such file or directory
libssl.so.0.9.8: cannot open shared object file: No such file or directory
libssl.so.0.9.8a: cannot open shared object file: No such file or directory
libssl.so.0.9.8g: cannot open shared object file: No such file or directory
libssl.so.0.9.8k: cannot open shared object file: No such file or directory
libssl.so.1.0.0: cannot open shared object file: No such file or directory
found libssl.so.10
default screen=0, planes=24
OpenGL vendor = 'DRI R300 Project'

I tried look for libcapi20.so.3 and found an rpm but it would not install

Hi,

The libcapi20.so.3 library warning you can safely ignore (unless
you application needs it), the missing 32bit libxslt.so library
should be fixed I imagine (although dependent on the app you may not
need it) -- the package is likely name ia32-libxslt or similar,
and the rest looks okay...

Cheers!

Jack Phinney wrote:

I just upgraded from Fedora 11 to 12 (KDE), and found that I could
no longer install Crossover from RPM.

unsigned, and then ask for root authentication (again) to proceed.
On 12 either this is no longer an option (which seems odd), this is
a bug, or I upgraded incorrectly. In any case, my system wouldn't
allow me to install an unsigned package, at all.

To work around, I edited /etc/yum.conf

and changed "gpgcheck" from "1" to "0". This leaving this "0"
setting in place is probably inadvisable, but switching it
temporarily will allow yum to install the Crossover rpm in the
absence of signature.

If anyone knows who to enable yum/kpackagekit to ask about missing
signatures once more, I'm all ears...

cheers!

Jack,

Download the rpm and run the following in the same dir (as root):

yum localinstall --nogpg cxg.rpm

This will preclude anyone from having to descend into /etc/ and make changes there, it's not necessary.

Also, when upgrading cx, you can do the following:

rpm -Uvh --nogpg cxg.rpm

If you are testing a build that does not recognize the package as an upgrade package then you must uninstall existing and install test package:

rpm -ev cxg_existing_packagename

yum localinstall --nogpg cxg_test.rpm

You might say, well, I'm passing rpm the name but it's not taking it. To get the exact name of the package that rpm is looking for (aka what it's true name is according to the rpm database), run the following:

rpm -qa | grep crossover

This will dump the true name you need to tell rpm command to uninstall. In other words when you are installing with rpm command you use the filename of the rpm but when you uninstall you use the name as it exists in the rpm database of your distro installation.

Also; in general, it's touch and go to upgrade rather than reinstall Fedora. The press statement is that it's ok to do and sometimes it works ok. However in my experience a more draconian approach, aka backing up your home dir and reinstalling on top of the existing partition structure is the best way. It gives you a more solid baseline. The more virgin the rpm database is, the less trouble you will run into.

For installing Fedora, since it is considered to be a bleeding edge distro, the press releases or the IRC fedora guys will tell you that, it's not just for home hobby/experimenting users, it is stable enough for production use. I say, that's bs.

If you install the latest thing that they have on the front page, you can expect to get something other than production quality. It IS possible to get a stable install, but you have to take advantage of the Fedora-Unity community and not the official DVD. Fedora Unity is a project that takes the latest bug fixes from ALL the distro packages as they exist at the most stable point in the distro upgrade cycle (the update repos) and use the upgraded/bugfixed packages to create a newer-better-faster-bugfixed installation DVD.

Fedora Unity project tracks the status of existing bugs and showstoppers during the genesis of the current Fedora release cycle and picks a fortuitous time to 'respin' the install dvd so that it's created AFTER showstopper/critical/major bugfixes have taken place in the package repositories.

Note: The original Fedora release never changes. They never respin it. Therefore as it is released, it (the dvd) will ALWAYS have the original problems it was released with, which historically have been some truly annoying stuff. Therefore I recommend using the Fedora Unity respin instead. YES, you can get the frontpage dvd and install, then do updates. But
it is not the same as using a dvd that was built from scratch using updated and bugfixed packages.

Because the more activity that takes place in package update and replacement vis a vis the rpm database, the more likely you will get a foobar or get hosed or get weirdisms when you least expect it. This goes for any dependency-based distro AFAIAC.

If you don't see a Fedora Unity release for the current Fedora, that means that either

a) The entire current release cycle was too problematic to respin for whatever reason or
b) The bugfixes of the current release have not reached a satisfactory apogee.

The Fedora Unity project overview:

http://fedoraunity.org/

Fedora Unity Current respin:

http://fedoraunity.org/Members/Southern_Gentleman/fedora-12-re-spins-20100303-released