dkg

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?

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.