dkg
-
Posts
74 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Blogs
Posts posted by dkg
-
-
FYI, the Funtoo Container FAQ still states that meta-repo is shared.
-
I can't figure out why I don't get emails from Jira when someone updates a ticket that I've created or watched. Poked all around the Jira settings and account. Is it just me?
-
First, if you haven't, I suggest reading up a little on passive vs. active PFC, waveform, etc. Second, my (older) CyberPower CP1500PFCLCD works a treat with apcupsd. From what I've seen, at least some newer CyberPower models work, as well, though I don't think there is an exhaustive list anywhere. It looks as though the LE850G uses USB for communication, so I think chances are good it will work.
-
I've been having a problem lately where Dropbox has been repeatedly creating filling up ~/Dropbox/.dropbox.cache/tmp_dirs with what looks like identical folders until the disk is (near) full. I've since revoked all user permissions to that folder do prevent this behavior. Is anyone else experiencing this?
-
2 hours ago, drobbins said:
From an install instructions perspective, they are correct. You should remove python-3.6 as Funtoo Linux 1.4 does not have python-3.6 and instead has python-3.7. So if you are upgrading your system to 1.4 and want your system to be set up that way, it is necessary to remove python-3.6.
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.
-
1 hour ago, drobbins said:
I hope that makes sense.
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.
-
3 hours ago, drobbins said:
@dkg you should really not file Funtoo bugs on the Gentoo bug tracker. It is an issue in Funtoo, not Gentoo. Please close the bug as invalid on Gentoo's bug tracker and file it on Funtoo's bug tracker.
I am both a Gentoo user and a Funtoo user. Would you like me to open a bug on both trackers?
-
1 hour ago, drobbins said:
@dkg you may find that some of the 'left over' things depending on 3.6 are actually 'old'/deprecated and can be removed. For example, pycrypto is old, and should be deleted, and pycryptodome is now being used in its place.
See the bug I filed at gentoo yesterday ?
-
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.
-
On 9/23/2019 at 8:38 AM, mauricev said:
/opt/my-overlay/net-fs/s3ql is recognized and let's me emerge net-fs/s3ql-3.3::my-overlayDid 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 directoryWhich 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.
-
On 4/7/2019 at 10:53 PM, drobbins said:
@dkg Sorry that Funtoo is not working for you but unfortunately the multilib implementation in Gentoo that 'works' for people has serious technical issues that make it hard to maintain. It is getting in the way of certain important efforts in Funtoo. We are likely going to circle back to multilib at some point but with a better implementation.
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.
-
On 4/5/2019 at 3:06 PM, librin.so.1 said:
If You're referring to the 32-bit chroot wiki page, then indeed, it fails to mention that the host's epro profiles, flavors and mix-ins (which otherwise likely provide the "X" use flag for You) do not carry over to the chroot and thus need to be set there independently.
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.
On 4/5/2019 at 3:06 PM, librin.so.1 said:Appears You did not make a WoW64 build of wine (I mentioned it in my "guide") and thus only got x86 wine available, so this is expected.
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.
On 4/5/2019 at 3:06 PM, librin.so.1 said:BTW, I'd personally switch back to gentoo, too. But alas, my hatred towards systemd dwarfs the inconvenience of removed multilib support, so I'm staying with funtoo.
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.
-
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.
-
On 2/18/2019 at 10:16 PM, librin.so.1 said:
Tarballs of what? If You mean funtoo stage3 tarballs, just use a 1.3 tarball for the chroot. It's not like the chroot has to match the base OS in version or anything.
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.
Dirty Pipe fix?
in Funtoo Hosting
Posted · Edited by dkg
typo
My container is running kernel 5.10.46. If I'm not mistaken, that version if vulnerable to Dirty Pipe (CVE-2022-0847). The first in the 5.10 series to be fixed was 5.10.102. I've already rebooted the container, with no change. Is there something else I should be doing?