dkg

Since adding the 'X' use flag to wine-vanilla/wine-staging (not currently mentioned in guide), I can actually launch a program now. However, I could not use a copy of the existing wine prefix, as it complained that it "is not a 64-bit installation, it cannot be used with a 32-bit wineserver." I'd have to rebuild the prefix from scratch, not knowing all the tweaks I made to get it where it is. With work, I could probably copy the things needed to bring it into shape. But, it doesn't have access to any of the files from either my home folder nor NFS mounts. I'd have to bind remount a number of things - I actually gave up remounting /home due to some issues I ran into, and concerns about sharing files between them, especially given 64-bit vs. 32-bit. For one of my applications, I will currently load an optical disk using KDE's mounting mechanisms to '/run/media/$user/...' then have the Windows app read the disk. I'm not seeing how to do that without a lot of hand-holding. Also haven't figured out to launch an application without the whole tedious su/xhost/chroot/su sequence. I also just realized that in one app, foobar2000, I use a number of features that allow me to do things like launch Konsole or Dolphin to the folder containing the music file; as-is, I could only get this to launch one of those apps within the chroot - but I would want to be using the "native" apps, not install KDE into the chroot. In other words, so far, this looks to be a very poor substitute for multi-lib, at least where running wine is concerned, and where the goal is not to puts the apps in a chroot jail.

No success so far. Following the wiki instructions, when I run winecfg at the end, I get the following. I did run the 'xhost' command. 0009:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded. 0009:err:winediag:nodrv_CreateWindow The graphics driver is missing. Check your build!

In the meantime, can anybody share experience with running apps, particularly apps in wine, using a chroot as described in the wiki? It's not clear to me how to transparently launch applications in the chroot from a desktop (Plasma launcher/widgets). Or whether file type associations can work.

Yes, I don't know why I left "stage3" out of the post. I was not aware that they could run different versions of funtoo. If I find time, I will give it a try this weekend. Thanks.

I have a few important apps that I run in wine (not Steam or games). Before I go all in with the 1.3 upgrade, I wanted to try creating a 32-bit chroot in 1.2 to make sure I could get wine and apps working. The problem is, I don't see any 32-bit tarballs available for 1.2 - only 64-bit. How else might one go about this?

The system upgrade is now complete. Thanks for the help, @palica.

I think the Upgrade Instructions may be missing steps regarding the python upgrade. It says to run these commands: # emerge -u1 =dev-lang/python-3.6* # emerge -C =dev-lang/python-3.4* Both systems that I've upgraded to 1.2, I got this message when trying to remove python-3.4: [root@wolfie 73% etc]# emerge -C =dev-lang/python-3.4* * This action can remove important packages! In order to be safer, use * `emerge -pv --depclean <atom>` to check for reverse dependencies before * removing packages. >>> These are the packages that would be unmerged: * Not unmerging package dev-lang/python-3.4.6-r1 since there is no valid * reason for Portage to unmerge currently used Python interpreter. >>> No packages selected for removal by unmerge I don't recall exactly what I did the last time (it was some time ago), but today I tried first to use 'eselect python set'. This removed the '(fallback)' status for python3.6, but did not get rid of the above message. I ended up using 'eselect python edit' and entering a '-' before python3.4. This has happened to me twice now, which suggests it's not something weird that I did.

The 'emerge --emptytree' would do this anyway, dummy! :) Never mind, folks.

I'm curious. The Upgrade Instructions have one upgrade gcc, then set the subarch. It seems you'd want subarch turned on beforehand so the gcc binary gets the benifits of the optimizations. Or, if that doesn't work because the older gcc doesn't work with the subarch profiles, then it seems best to 'emerge -u1 gcc', then 'epro subarch', then 'emerge -1 gcc'. Is this a waste of effort?

Are you saying that there are steps I should follow to avoid 1.3? I did not put 1.3 in ego.conf, if that's what you mean.

I was following those steps. I didn't touch ego.conf. I tried to upgrade ego, and got the errors about PYTHON_TARGETS above.

[root@wolfie 61% ego]# emerge -1 ego These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] app-admin/ego-2.4.2 [2.4.0] PYTHON_SINGLE_TARGET="-python3_4* -python3_7%" PYTHON_TARGETS="-python3_4* -python3_7%" Would you like to merge these packages? [Yes/No] y >>> Verifying ebuild manifests >>> Emerging (1 of 1) app-admin/ego-2.4.2::core-kit >>> Failed to emerge app-admin/ego-2.4.2, Log file: >>> '/var/tmp/portage/app-admin/ego-2.4.2/temp/build.log' >>> Jobs: 0 of 1 complete, 1 failed Load avg: 0.08, 0.07, 0.02 * Package: app-admin/ego-2.4.2 * Repository: core-kit * Maintainer: drobbins@funtoo.org funtoo * Upstream: https://bugs.funtoo.org/ * USE: amd64 elibc_glibc kernel_linux userland_GNU * FEATURES: preserve-libs sandbox userpriv usersandbox * No Python implementation selected for the build. Please set * the PYTHON_SINGLE_TARGET variable in your make.conf to one * of the following values: * * python3_7 python3_4 python3_5 python3_6 * ERROR: app-admin/ego-2.4.2::core-kit failed (setup phase): * No supported Python implementation in PYTHON_SINGLE_TARGET/PYTHON_TARGETS. * * Call stack: * ebuild.sh, line 92: Called pkg_setup * ebuild.sh, line 331: Called python-single-r1_pkg_setup * python-single-r1.eclass, line 562: Called python_setup * python-single-r1.eclass, line 552: Called die * The specific snippet of code: * die "No supported Python implementation in PYTHON_SINGLE_TARGET/PYTHON_TARGETS." * * If you need support, post the output of `emerge --info '=app-admin/ego-2.4.2::core-kit'`, * the complete build log and the output of `emerge -pqv '=app-admin/ego-2.4.2::core-kit'`. * The complete build log is located at '/var/tmp/portage/app-admin/ego-2.4.2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/app-admin/ego-2.4.2/temp/die.env'. * Working directory: '/var/tmp/portage/app-admin/ego-2.4.2/homedir' * S: '/var/tmp/portage/app-admin/ego-2.4.2/work/ego-2.4.2' [root@wolfie 61% ego]# PYTHON_SINGLE_TARGET="python3_4" emerge -1 ego These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] app-admin/ego-2.4.2 [2.4.0] PYTHON_SINGLE_TARGET="-python3_7%" PYTHON_TARGETS="-python3_4* -python3_7%" Would you like to merge these packages? [Yes/No] y >>> Verifying ebuild manifests >>> Emerging (1 of 1) app-admin/ego-2.4.2::core-kit >>> Failed to emerge app-admin/ego-2.4.2, Log file: >>> '/var/tmp/portage/app-admin/ego-2.4.2/temp/build.log' >>> Jobs: 0 of 1 complete, 1 failed Load avg: 0.08, 0.02, 0.01 * Package: app-admin/ego-2.4.2 * Repository: core-kit * Maintainer: drobbins@funtoo.org funtoo * Upstream: https://bugs.funtoo.org/ * USE: amd64 elibc_glibc kernel_linux python_single_target_python3_4 userland_GNU * FEATURES: preserve-libs sandbox userpriv usersandbox * The implementation chosen as PYTHON_SINGLE_TARGET must be added * to PYTHON_TARGETS as well. This is in order to ensure that * dependencies are satisfied correctly. We're sorry * for the inconvenience. * ERROR: app-admin/ego-2.4.2::core-kit failed (setup phase): * Build target (python3_4) not in PYTHON_TARGETS. * * Call stack: * ebuild.sh, line 92: Called pkg_setup * ebuild.sh, line 331: Called python-single-r1_pkg_setup * python-single-r1.eclass, line 562: Called python_setup * python-single-r1.eclass, line 532: Called die * The specific snippet of code: * die "Build target (${impl}) not in PYTHON_TARGETS." * * If you need support, post the output of `emerge --info '=app-admin/ego-2.4.2::core-kit'`, * the complete build log and the output of `emerge -pqv '=app-admin/ego-2.4.2::core-kit'`. * The complete build log is located at '/var/tmp/portage/app-admin/ego-2.4.2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/app-admin/ego-2.4.2/temp/die.env'. * Working directory: '/var/tmp/portage/app-admin/ego-2.4.2/homedir' * S: '/var/tmp/portage/app-admin/ego-2.4.2/work/ego-2.4.2'

Sync was successful. I did the above. Still had issues getting ego to merge. I had to add PYTHON_SINGLE_TARGET and PYTHON_TARGETS to make.conf for some reason. Had to use this to turn ignore a file collision with a man page for boot.conf: [root@wolfie 61% ego]# FEATURES="-collision-detect -protect-owned" ebuild ego-2.5.0.4.ebuild merge Got this QA warning: * QA Notice: Symbolic link /usr/sbin/boot-update points to /usr/sbin/ego which does not exist. [root@wolfie 61% portage]# whereis ego ego: /usr/bin/ego /etc/ego.conf /usr/share/ego /usr/share/man/man1/ego.1.bz2 But at this point, epro worked well enough to get my profiles back where they were, and ego worked well enough to sync. Any tips on why I needed to set the PYTHON variables in make.conf and why 'eselect python' isn't working? [root@wolfie 61% ego]# eselect python list Available Python interpreters, in order of preference: [1] python3.4 [2] python2.7 [root@wolfie 61% ego]# eselect python set 1 [root@wolfie 61% ego]# eselect python list Available Python interpreters, in order of preference: [1] python3.4 [2] python2.7

Good catch! It seems to be doing a lot more now.

Also, you might have missed it, but one of the logs in the initial post shows that I tried to clone ego from git and run 'ego sync' with that.