14 thoughts on - Running The Wine Emulator On CentOS 7

• Only a guess as I don’t run wine and don’t have any Windows applications, but…

  CentOS 7 is 64-bit. Therefore I’m guessing you’ve installed a 64-bit version of wine on CentOS? Further guessing your Windows apps are
  32-bit? Can you see where I’m going here?

  I’m guessing you are either going to need to build/install a 32-bit version of wine or will need to find 64-bit versions of your Windows applications.

  Like I said, just a guess :-)

• Le 07/03/2015 18:24, Ned Slider a

• Only if 32-bit versions of all the BRs are available. You can’t build in mock as there is no 32-bit tree to build against.

• Niki,

  There are some 32bit RPMs (slightly older) here:
  http://arrfab.net/attic/RPMS/7/x86_64/

  HTH
  Lucian

  —
  Sent from the Delta quadrant using Borg technology!

  Nux!
  http://www.nux.ro

  —– Original Message —–

• Damn, I built those packages initially to help someone from the family
  (and those aren’t signed !) while hoping that EPEL would build the
  32bits version, which they never did .. Tech details : those were built through mock , but against 32bits version of CentOS 7, as all required packages to init a CentOS 7 i686
  buildroot are available since day #1 on http://buildlogs.CentOS.org

  I wanted then to remove those packages, but just by looking at my webserver logs, it seems more and more people are now using those wine packages :-(

  –

• I was just getting ready to build those, I need them :) .. how about we put them (or newer ones, if available) in i686 extras.

• Le 09/03/2015 13:02, Johnny Hughes a

• Le 08/03/2015 01:53, Nux! a écrit :

  I tried to install these, but I ran into some trouble. Here’s what I
  tried to do.

  I’m using the yum-priorities plugin. The official CentOS repos are configured with a priority of 1. Besides that, I’m using the EPEL and Nux-dextop third party repos, each with a priority of 10.

  I created an /etc/yum.repos.d/wine.repo file:

  [wine]
  enabled=1
  priority=5
  name=Wine repository baseurl=http://arrfab.net/attic/RPMS/7/$basearch/
  gpgcheck=0

  I gave it a priority of 5, since I want the wine-* packages to have precedence over those present in EPEL.

  But when I try this:

  # yum install wine

  … here’s what I get:

  =======================================

  Error: Multilib version problems found. This often means that the root cause is something else and multilib version checking is just pointing out that there is a problem. Eg.:

  1. You have an upgrade for openal-soft which is missing some dependency that another package requires. Yum is trying to solve this by installing an older version of openal-soft of the different architecture. If you exclude the bad architecture yum will tell you what the root cause is (which package requires what). You can try redoing the upgrade with
  –exclude openal-soft.otherarch … this should give you an error message showing the root cause of the problem.

  2. You have multiple architectures of openal-soft installed, but yum can only see an upgrade for one of those architectures. If you don’t want/need both architectures anymore then you can remove the one with the missing update and everything will work.

  3. You have duplicate versions of openal-soft installed already. You can use “yum check” to get yum show these errors.

  …you can also use –setopt=protected_multilib=false to remove this checking, however this is almost never the correct thing to do as something else is very likely to go wrong (often causing much more problems).

  Protected multilib versions: openal-soft-1.15.1-3.el7.arrfab.i686 !=
  openal-soft-1.16.0-2.el7.x86_64

  ========================================

  Now before I’m wrecking my system, I thought I’d rather ask your advice. What can I do to install this Wine version cleanly?

  Cheers,

  Niki

  —
  Microlinux – Solutions informatiques 100% Linux et logiciels libres
  7, place de l’église – 30730 Montpezat Web : http://www.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32

• We really should have this very soon after the 7.1 x86_64 release. I am building all the packages for both as we do 7.1.

  But, so far the new kernel is not building 32 bit :(

• Yes, WRT Springdale, I have built the i686 kernel for 7.0 too and that works .. it is the 7.1 kernel that is not building i686. If they get that working (or if anyone else does) then I will grab their configs and build it.

  Since Red Hat does not build the i686 kernel for RHEL 7 (just kernel headers for build requirements), they have not tested that a full kernel builds, nor do they provide i686 config files. But Red Hat does backport changes into their kernels and therefore standard 3.10.x kernel config files do not work with the Red Hat backported kernels.

  If someone out there is smart enough to build the 7.1 kernel for i686 .. really, just smart enough to create good config files that will build .. that will help.

  I plan to do that after 7.1 64 bit is released and all the updates after
  7.1 happen, but if someone can do it earlier, it will speed getting a
  7.1 32 bit after the 64 bit is done.

• Yeah, as said, I built those initially, but haven’t tracked those, so if Epel updated some of the required packages, you’ll have that issue. Feel free to just exclude those conflicting packages from epel.repo and that would normally work :
  exclude=wine* openal*

  Remove also those packages (if still installed on disk) and then you should be able to install wine (both x86_64 and i386)

  As it seems quite some people are interested in wine packages, and that EPEL will probably not build those packages, I’m wondering if the best solution is to :
  – – rebuild all those (and track version updates) and host it on people.CentOS.org
  – – put those on C7 extras

  Opinions ?

  –

• Hi Niki,

  I’ve built a CentOS 7 i686 liveCD, just as a PoC , some time ago and I
  tested it on a Pentium 4 / 2.8Ghz and 1Gb of ram :
  https://twitter.com/Arrfab/status/553547691272445953

  While it “works” it’s quite slow so probably better then to stick with CentOS 6 and wait for something lighter than Gnome3/Gnome-shell as Desktop Environment (xfce/mate/$other)

  Cheers,

  –

• Le 10/03/2015 12:08, Fabian Arrotin a

• Le 10/03/2015 12:12, Fabian Arrotin a