dkg

Umm. Okay. I suppose this all makes sense to people with deep insight into Funtoo, but it's awful confusing to this user. Python 3.6 is in the tree, but it's not part of Funtoo 1.4. Software which I find critical is in the tree, but does not have a Python 3.7 target (only 3.5 and 3.6). So I keep Python 3.6 and therefore I'm deviating from Funtoo 1.4, I guess. I did not know that what I did was not supported. Seems the correct thing to do was to remove 3.6, and break that critical software. It needed to be fixed for 3.7, but I had no idea about this when I started the upgrade. I'm not sure how I would know that there are packages without 3.7 targets before I get to the part of the upgrade where I sync the new tree. Even after, unless I'm actively looking for for these problems, I don't think any red flags would get raised before the step where Python 3.6 is removed. If there was warning about this potential problem area, I must have missed it. I guess I'm saying I don't know where I went wrong in this process. What should I have done differently?

And there you have it. 🙂 https://bugs.funtoo.org/browse/FL-6963 Honestly, I feel this discussion has gotten a little off track, though. It was supposed to be about my concern with the upgrade instructions. I guess the answer is, "Don't blindly follow the steps." Good advice, that. I only pointed out the s3ql problem because pycrypto vs. pycryptodome came up. A workaround is there if anybody needs it.

Sure, it makes sense, but it is a problem that I am experiencing in both. I am happy to open a Funtoo bug, too, if that is the proper etiquette in my situation.

I am both a Gentoo user and a Funtoo user. Would you like me to open a bug on both trackers?

See the bug I filed at gentoo yesterday 🙂 https://bugs.gentoo.org/707878

True. But until that work is done, advising people to execute 'emerge -C =dev-lang/python-3.6*' without checking if they are using it seems silly.

Did you get s3ql v3.3 working? Could you share your ebuild?

I'm confused by the way that the 1.4 upgrade instructions state, unconditionally, "Remove python-3.6 as it will no longer be used." There are at least a couple of ebuilds in the tree that do not have a Python 3.7 target, e.g., net-fs/s3ql and dev-python/pycrypto. What am I missing?

I appreciate the post, but I'd like to ask a question. It seems to me that with the chroot method, there is going to be no integration or interaction between the "host" and the chroot "guest". That is, I can't start an application in the chroot by clicking on a Plasma icon, or using 'Open With' in Dolphin. Or the other direction, having a command in a Windows app open a folder in Dolphin or Konsole, or a URL in Firefox. Have you found ways to make things like this work with your method? Thanks.

Perfect, thank you.

I'm getting spam in my logs in my container from agetty like this: Jul 21 00:19:58 dkg agetty[5782]: /dev/tty1: cannot open as standard input: No such file or directory Jul 21 00:19:58 dkg agetty[5784]: /dev/tty3: cannot open as standard input: No such file or directory Jul 21 00:19:58 dkg agetty[5786]: /dev/tty5: cannot open as standard input: No such file or directory Jul 21 00:19:58 dkg agetty[5787]: /dev/tty6: cannot open as standard input: No such file or directory Jul 21 00:19:58 dkg agetty[5783]: /dev/tty2: cannot open as standard input: No such file or directory Jul 21 00:19:58 dkg agetty[5785]: /dev/tty4: cannot open as standard input: No such file or directory Which is true, those devices do not exist. And it makes sense that a container isn't going to have all these ttys, either. I just don't know how to tell it not to look for them. Thanks.

Believe me, I appreciate that multilib is a hack, and I've had plenty of issues with it over the years. And I can accept that my use case is uncommon. It's also a use case that is not addressed well by chroot or containers, unfortunately. Hope my feedback was useful, anyway. By the way, I cannot figure out why the forums do not send me an email when someone replies to a post or thread I'm following. Don't know if it's just me or what.

I'm aware that and X server is going to magically appear in the chroot, but I was hoping xhost would make it unnecessary, though I was pretty sure going in that it would not. No, I did not, as I had no need to run 64-bit Windows apps. The point is, I could not copy the wine *prefixes* over. This, I did not anticipate. Not disaster, but definitely a pain. Gentoo still uses openrc by default. Meanwhile, I'm still limping along with Funtoo 1.2 on that system.

Well, since a few weeks have passed with no suggestions for my difficulties, nor news of a solution in the near term, I guess I'm faced with "downgrading" this system to Gentoo. As much as I love Funtoo's extra features (enough that I've been a financial supporter of Funtoo for years), it just isn't providing the things I need for this system. Hope to bring it back to Funtoo one day.

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.