Summary: | app-emulation/wine-1.7.38[vaapi] requires libva, whose dependencies conflict with app-emulation/emul-linux-x86-xlibs[-abi_x86_32] | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | C. Wijtmans <cj.wijtmans> |
Component: | Current packages | Assignee: | Adam Feldman <np-hardass> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | proxy-maint, wine |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
USE=abi_x86_32 emerge -pv x11-libs/gtk+:2
emerge -av --update --deep --newuse wine |
Description
C. Wijtmans
2015-03-08 18:17:15 UTC
Chances are it's a case of "you're doing it wrong". Start with building x11-libs/gtk+:2 with abi_x86_32. chances are dependencies are blocking eachother. Created attachment 398408 [details]
USE=abi_x86_32 emerge -pv x11-libs/gtk+:2
(In reply to C.J. Wijtmans from comment #2) > chances are dependencies are blocking eachother. Not really, though you really should have asked this as a question on the forum. At least wrt. wine I'm certain no emul-linux-x86 packages are needed. All emul-linux-x86 have abi_x86_32 useflags - make sure they're set and not usemasked (as they might be by package.use.stable.mask). Then start setting that useflag (while ensuring it's not usemasked) on the dependencies. It will take awhile, but eventually you should get a clear list and (most likely) be able to unmerge emul-linux-x86 packages. Actually, the faster route that might work would be to unmerge emul-linux-x86 packages, mask them and just struggle through the series of 'emerge -upvD @world' attempts till you set/unmask abi_x86_32 on all packages that will need it - for me, wine needed it on about 200 packages, so completing the list took awhile, but in itself was quite simple. (In reply to Rafał Mużyło from comment #4) > (In reply to C.J. Wijtmans from comment #2) > > chances are dependencies are blocking eachother. > > Not really, though you really should have asked this as a question on the > forum. > > At least wrt. wine I'm certain no emul-linux-x86 packages are needed. > > All emul-linux-x86 have abi_x86_32 useflags - make sure they're set and not > usemasked (as they might be by package.use.stable.mask). > Then start setting that useflag (while ensuring it's not usemasked) on the > dependencies. > > It will take awhile, but eventually you should get a clear list and (most > likely) be able to unmerge emul-linux-x86 packages. > > Actually, the faster route that might work would be to unmerge > emul-linux-x86 packages, mask them and just struggle through the series of > 'emerge -upvD @world' attempts till you set/unmask abi_x86_32 on all > packages that will need it - for me, wine needed it on about 200 packages, > so completing the list took awhile, but in itself was quite simple. i am not on stable. and if you looked at my packages you would see emul-linux-x86 packages cant be unmerged. (In reply to Rafał Mużyło from comment #4) > Actually, the faster route that might work would be to unmerge > emul-linux-x86 packages, mask them and just struggle through the series of > 'emerge -upvD @world' attempts till you set/unmask abi_x86_32 on all > packages that will need it - for me, wine needed it on about 200 packages, > so completing the list took awhile, but in itself was quite simple. Althought it might be a solution. It doesnt solve the bug. If i have to go through hoops and mask things to get a package to install its a bug. The old emul packages arent properly fased out yet. (In reply to C.J. Wijtmans from comment #6) > (In reply to Rafał Mużyło from comment #4) > i am not on stable. and if you looked at my packages you would see emul-linux-x86 packages cant be unmerged. Really ? Let's see - wine is covered; going by the ebuild, so is skype, nvidia-drivers and android-sdk-update-manager; epsxe is no longer in the tree nor are its plugins; not sure if games-util/steam-launcher ever was; gcc is a bit more complicated case - due to toolchain.eclass, it will pull emul-linux-x86-xlibs and emul-linux-x86-xlibs, however I'm at least 85% sure you could get around that with bogus virtual ebuilds, that will simply have the gcj reqs listed in RDEPEND (basically gtk+:2, media-libs/libart_lgpl and a couple x11-libs) with '[abi_x86_32]' appended. > The old emul packages arent properly fased out yet. Given the above, for any ebuild still in the tree they effectively are. You may be right about the packages in the portage tree but some are in overlays. I will check more in depth later. But the issue is if i still have to do things manually("go through hoops") such as scenario should be considered a bug. Created attachment 398624 [details]
emerge -av --update --deep --newuse wine
i unmerged the packages, was able to emerge the updated nvidia-drivers but wine failed...
Also skype is still there. (In reply to C.J. Wijtmans from comment #9) > Created attachment 398624 [details] > emerge -av --update --deep --newuse wine > > i unmerged the packages, was able to emerge the updated nvidia-drivers but > wine failed... First of all: FFS, support questions belong in the forum. I strongly suspect, that due to package.use.stable.mask entries for abi_x86_32 portage isn't picking up the correct packages and/or doesn't prompt for needed use changes. As a shortcut, just put a use.stable.mask unmask entry for abi_x86_32 and add '-N' to emerge command. Again, I can certainly say wine doesn't need emul-linux-x86 packages - I've got that installed without anything more than a list of package.use.stable.mask/package.use entries. I dont know why you are so persistent. `-- dev-util/android-sdk-update-manager-23 ~amd64 `-- app-arch/tar-1.28 (app-arch/tar) ~amd64 `-- app-arch/gzip-1.6 (app-arch/gzip) ~amd64 `-- virtual/pkgconfig-0-r1 (virtual/pkgconfig) ~amd64 `-- virtual/jdk-1.7.0 (>=virtual/jdk-1.5) ~amd64 `-- dev-java/ant-core-1.9.2 (>=dev-java/ant-core-1.6.5) amd64 `-- dev-java/swt-3.7.2-r1 (dev-java/swt) amd64 [cairo] `-- dev-java/swt-3.6.1 (dev-java/swt) amd64 [cairo] `-- x11-libs/gtk+-2.24.27 (>=x11-libs/gtk+-2.24.23-r2) ~amd64 [abi_x86_32(-)] `-- app-emulation/emul-linux-x86-gtklibs-20140508-r6 (app-emulation/emul-linux-x86-gtklibs) ~amd64 [-abi_x86_32(-)] `-- net-im/skype-4.3.0.37-r5 ~amd64 `-- sys-apps/sed-4.2.2 (>=sys-apps/sed-4) ~amd64 `-- virtual/ttf-fonts-1 (virtual/ttf-fonts) amd64 `-- dev-qt/qtcore-4.8.6-r1 (dev-qt/qtcore) ~amd64 [abi_x86_32(-)] `-- dev-qt/qtdbus-4.8.6-r1 (dev-qt/qtdbus) ~amd64 [abi_x86_32(-)] `-- dev-qt/qtgui-4.8.6-r1 (dev-qt/qtgui) ~amd64 [accessibility abi_x86_32(-)] `-- dev-qt/qtwebkit-4.8.6-r1 (dev-qt/qtwebkit) ~amd64 [abi_x86_32(-)] `-- app-emulation/emul-linux-x86-qtlibs-20140508-r1 (>=app-emulation/emul-linux-x86-qtlibs-20120520) amd64 [-abi_x86_32(-)] `-- media-libs/alsa-lib-1.0.28 (media-libs/alsa-lib) amd64 [abi_x86_32(-)] `-- app-emulation/emul-linux-x86-soundlibs-20140508 (>=app-emulation/emul-linux-x86-soundlibs-20120520) amd64 [-abi_x86_32(-)] `-- x11-libs/libX11-1.6.3 (x11-libs/libX11) ~amd64 [abi_x86_32(-)] `-- x11-libs/libXext-1.3.3 (x11-libs/libXext) amd64 [abi_x86_32(-)] `-- x11-libs/libXScrnSaver-1.2.2-r1 (x11-libs/libXScrnSaver) amd64 [abi_x86_32(-)] `-- x11-libs/libXv-1.0.10 (x11-libs/libXv) amd64 [abi_x86_32(-)] `-- app-emulation/emul-linux-x86-xlibs-20140508 (>=app-emulation/emul-linux-x86-xlibs-20120520) amd64 [-abi_x86_32(-)] `-- media-sound/pulseaudio-5.0-r7 (media-sound/pulseaudio) ~amd64 [abi_x86_32(-)] `-- media-sound/apulse-0.1.4 (media-sound/apulse) ~amd64 [abi_x86_32(-)] `-- sec-policy/selinux-skype-2.20141203-r3 (sec-policy/selinux-skype) ~amd64 Well there is a profile called default/linux/amd64/13.0/no-emul-linux-x86. Could have been mentioned somewhere or maybe i missed it. :roll: in some of the cases (like, you know, OR deps) 'equery d' output is pure BS As I already mentioned, the only legit case here is gcc[gcj] and I'm about 95% sure it can be solved the way noted earlier, as both the xlibs and gtk+:2 are covered by multilib ebuilds. well i dont have gcc[gcj]. and portage seemed to wint to pull them in for nothing. Switching to the profile helped. Mixing abi_x86_32 and emul-linux-x86 can cause the sorts of issues that you encountered in the initial report. From what I've read, you are aware of the no-emul-linux profiles. As you are running ~amd64, you likely shouldn't encounter any packages that are incompatible with that profile. I personally would highly recommend switching to that. That should also majorly simplify matters for you. I am going to agree with Rafal that this probably isn't the best venue for troubleshooting this issue. I'd generally recommend IRC (#gentoo or #gentoo-wine) or forums first. Now, onto the subject at hand... There core issue is probably that the new use flags s3tc and vaapi require building dependencies with abi_x86_32 use flags, and that likely causes depgraph issues. I'll look into what the best way to handle that is. The emul-linux-x86 packages have been removed. |