clort | anybody have a fix for python (pip2, pip3) erroring when installing something, i always get | 12:17 |
---|---|---|
clort | subprocess.CalledProcessError: Command '('lsb_release', '-a')' returned non-zero exit status 1 | 12:17 |
clort | solutions i found are not working for me with devuan ceres | 12:18 |
clort | lsb_release is provided by package lsb-release | 12:24 |
clort | how is python so broken. i can get around it by faking /usr/bin/lsb_release to return something sensible | 12:30 |
clort | can i install python-fontconfig without using pip? | 12:32 |
cgb_orig | <- channel n00b seeking assistance | 12:36 |
onefang | Seek and ye shall find. Perhaps. | 12:38 |
clort | who changed all the mountpoints? i used to have root mounted on / | 12:38 |
clort | now i have /media/user/UUID or something | 12:39 |
cgb_orig | attempting to resolve xhost unable to display error | 12:39 |
cgb_orig | was a lot easier on Solaris in my day | 12:39 |
clort | oh nvm sorry | 12:39 |
cgb_orig | has anyone experienced/resolved "unable to open display" before and willing to share their expertise? | 12:48 |
onefang | Some more detail on what it is you are doing might help us help you. | 12:49 |
clort | well i got a nice little python script working now that will tell me every installed font that has a particular character or codepoint \p/ | 13:02 |
clort | just pip is all broken | 13:02 |
clort | cgb_orig: you'll want to have the DISPLAY environment variable set to point to your active display, if launching an X app from a shell | 13:03 |
luser977 | cgb_orig: echo $DISPLAY comes up empty? | 13:03 |
fsmithred | echo 'ALWAYS_SET_PATH yes' >> /etc/default/su | 14:23 |
clort | anyone here using zram with a 4GB RAM machine? | 14:34 |
cgb_orig | $DISPLAY=":0.0", "127.0.0.1:0", "localhost:0" - all respond "unable to open". Have already xhost +'d | 15:13 |
clort | cgb_orig: are you invoking the program from a local x-terminal? | 15:17 |
cgb_orig | @clort: correct, sudo'd | 15:20 |
aitor_ | cgb_orig: are you trying to run X as root? | 15:21 |
cgb_orig | @altor: correct | 15:22 |
aitor_ | do you have a ~root/.Xauthority? | 15:24 |
ShorTie | that don't work real well | 15:24 |
aitor_ | ShorTie: what do you mean? | 15:25 |
cgb_orig | @altor - yes. @ShorTie - I'm aware of security implications - I use it for testing | 15:25 |
cgb_orig | @aitor, apologies, small font | 15:26 |
ShorTie | not saying it can't be done, but most stuff install for user i do believe | 15:28 |
clort | what program are you invoking before you get 'unable to open' cgb_orig | 15:29 |
clort | when you report an error, it helps to share what you did to generate the error | 15:29 |
clort | because we cannot see inside your brain | 15:29 |
cgb_orig | Resolved! xhost :local:root. Will disable with xhost - once finished | 15:30 |
clort | ok | 15:30 |
ShorTie | unable to open means to me your going to the wrong screen, like :1 instead of :0 | 15:31 |
cgb_orig | @clort - indeed, thanks. I was invoking a number of programs all generating "unable to display" - I will be more specific in further queries. Thanks for your time and see you again. | 15:33 |
clort | cheers | 15:43 |
aitor_ | did anybody give a try to Ubus? | 15:44 |
aitor_ | https://openwrt.org/docs/techref/ubus | 15:44 |
aitor_ | I'll change my question: did anybody give a try to OpenWrt in general? | 15:51 |
clort | i'm pretty sure there is an openwrt chat | 15:55 |
aitor_ | i'm looking a t the forum, thanks | 15:57 |
aitor_ | clort: yes... https://webchat.freenode.net/ | 16:00 |
clort | maybe #openwrt or ##openwrt | 16:00 |
aitor_ | forget the link above | 16:03 |
aitor_ | there are three channels: #openwrt, #openwrt-devel and #openwrt-adm | 16:03 |
aitor_ | i have .deb packages for libubox and libubus including some working examples | 16:08 |
aitor_ | bbl | 16:18 |
unixbsd | Concerning a harddisk, with ntfs, is it possible to format ntfs with mkfs.ntfs with badsector (excl. during format)? | 20:12 |
unixbsd | is the main package site offline, and down currently? | 21:00 |
unixbsd | deb.devuan.org seems unstable currently, for 10 min ago. | 21:01 |
systemdlete | devuan ascii (host not vm) system occasionally causes screen "flashes" (quick off-on? I think). This has been happening occasionally, but today, it actually caused a freeze-up of sorts. The system would update the clock, but the overall system seemed to be frozen. I couldn't input or use the mouse. (I forgot to try to get a console, sorry.) | 21:15 |
systemdlete | The kernel log shows a ton of messages like: "radeon 0000:01:05.0: GPU lockup (current fence id 0x00000000037f8025 last fence id 0x00000000037f80bc on ring 0)" | 21:16 |
mason | systemdlete: Overheating? | 21:16 |
systemdlete | I ddg'd this a bit and discovered that other people have run into this. | 21:16 |
mason | Could be a bug, but I'd tend not to expect a bug to show up over time. | 21:16 |
systemdlete | https://gitlab.freedesktop.org/drm/amd/-/issues/856 | 21:17 |
mason | systemdlete: https://bugzilla.kernel.org/show_bug.cgi?id=62721 has an interesting idea at the bottom | 21:18 |
systemdlete | I know I need to upgrade to beowulf, but I've been busy doing other things first. It is on my list. | 21:18 |
systemdlete | thanks mason. | 21:19 |
mason | Don't know if it'll help, but it's a relevant knob. | 21:19 |
systemdlete | I might try it if I experience it again. Did you look at the link I posted? I think that is a more complete analysis. | 21:21 |
systemdlete | btw, this is not a laptop. I think the user in your link was running a laptop, so your overheating theory makes sense (laptops do all sorts of upsetting things) | 21:23 |
systemdlete | I admit that this ASUS board has, from time to time, been problematic. Just yesterday, the onboard ethernet port went out, and I had to reseat/jiggle the connector until it started working again. | 21:24 |
systemdlete | Most of the time, this system runs just fine. I suppose the onboard radeon chip might be an issue though. Have you heard of this? | 21:24 |
systemdlete | Guess I should offer up my kernel version also: 4.9.0-14-amd64 | 21:27 |
systemdlete | I was running a number of VMs also (about 6 or 7 I think) | 21:27 |
systemdlete | There was plenty of RAM left, though. Only about 16gb of the 32gb were in use, per htop. | 21:27 |
mason | systemdlete: I looked at your link. I didn't see discussion but I'll look again. | 21:39 |
mason | Oh, following it to the original bug, there's more data. | 21:39 |
systemdlete | (they migrated to a new site) | 21:46 |
systemdlete | here is another message from the kernel log just before I recycled the box: " [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on GFX ring (-110)." | 21:46 |
systemdlete | more info: Kernel log looks like this is rs780 chip, fwiw | 21:53 |
Wafficus | Hi there, I installed Jami on Devuan via apt, but running "jami" doesn't seem to launch it | 22:08 |
Wafficus | I found the package in Debian, but it doesn't appear to be named anyhting differently | 22:10 |
Wafficus | https://packages.debian.org/sid/jami | 22:10 |
Deknos | Wafficus, try running "gnome-ring"? | 22:18 |
Deknos | could be that the binary is still called that name. | 22:19 |
Wafficus | yes you're right | 22:20 |
Wafficus | it is gnome-ring for some reason | 22:20 |
Wafficus | I think its cause they changed the name to Jami recently | 22:20 |
Wafficus | thanks a ton! | 22:20 |
systemdlete | uh... I wonder, maybe this is important? I have no /lib/firmware which means there is no amd microcode updates. Is this correct (devuan ascii) for my amd system? | 22:37 |
systemdlete | mason: If a microcode update fixes the gpu issue, then maybe this is why I am having this problem? | 22:37 |
gnarface | depends on how old your system is | 22:37 |
systemdlete | how old... well, this is a fx8300 processor I think | 22:38 |
systemdlete | fx8350 maybe? | 22:38 |
gnarface | not old enough. you need the microcode updates for security, at least | 22:38 |
systemdlete | but I guess you want to know the chipset | 22:38 |
gnarface | can't tell if it'll be relevant to your other issue | 22:38 |
gnarface | no, FX tells me all i need to know - the FX series are the oldest AMD processors vulnerable to the spectrum/meltdown vulnerabilities. | 22:39 |
gnarface | so you will at least want the microcode upates for that, regardless of it helps with any other GPU issues (i doubt it actually) | 22:39 |
systemdlete | so I need to install it then? | 22:39 |
systemdlete | help me here | 22:40 |
gnarface | yea. phenom and earlier don't do speculative execution, but from what i read, the FX series has preliminarily implemented some of it | 22:40 |
gnarface | so yes, install it | 22:40 |
systemdlete | ah, I see. | 22:40 |
systemdlete | what did you mean by "not old enough" then? | 22:40 |
gnarface | "not old enough to predate speculative execution vulnerabilities" | 22:41 |
systemdlete | at any rate, it won't HARM anything to install it and use it, right? | 22:41 |
gnarface | if you had a pentium II it wouldn't be vulnerable either :-P follow? | 22:41 |
gnarface | i've never seen it harm anything. on a mobile processor i suspected it made the idle a bit hotter, but i can't be sure that wasn't just impending fan failure (the fan failed completely soon after that) | 22:42 |
systemdlete | "either?" (sorry, trouble parsing by this old man here) | 22:42 |
gnarface | a pentium II wouldn't be vulnerable | 22:42 |
gnarface | just ignore the either. it's a superfluous word in that sentence. i'm sorry i use too many words. | 22:42 |
systemdlete | ok | 22:42 |
systemdlete | I get confused by these things, sorry. | 22:43 |
gnarface | (actaully any single-core chip would not be vulnerable because the vulnerability fundamentally relies on multiple cores) | 22:43 |
systemdlete | spectre? | 22:43 |
gnarface | yea. but not ALL multiple-core systems are vulnerable, just the ones that do "speculative execution" or "branch prediction" | 22:43 |
gnarface | which was really popular after the core2duos but then quickly became very unpopular recently so new ARM chips are avoiding it | 22:44 |
systemdlete | istm that boot log mentions spectre | 22:44 |
systemdlete | but I don't have microcode installed | 22:44 |
gnarface | well the chips ship with some microcode | 22:44 |
systemdlete | is the spectre bit in the kernel itself then? | 22:44 |
gnarface | the updated microcode just replaces it on the fly | 22:45 |
systemdlete | I mean, compiled in? | 22:45 |
systemdlete | istr it was, but maybe my memory fails me (as it often does these days) | 22:45 |
gnarface | there is kernel components too i think, yes, that also had to be patched. update your kernel. | 22:45 |
systemdlete | I'm running the latest I think, for ascii anyway | 22:45 |
systemdlete | 4.9.0-14-amd64 | 22:46 |
gnarface | i'd assume the beowulf kernel has the patch, but i can't tell you for sure that 4.9 one does | 22:46 |
gnarface | actually i would assume it does but i'm just not 100% sure | 22:46 |
gnarface | i'd expect it to be mentioned in the changelog though | 22:46 |
systemdlete | I know I need to update to beowulf. That is becoming increasingly obvious. | 22:46 |
gnarface | well the ascii-backports kernel may also have it | 22:46 |
conifer | hi, I used to run firetools in the past but when I switched to beowulf I could run them for a day or two, and now they complain about a possible permissions problem | 22:47 |
gnarface | i still have some ascii systems around here but all headless | 22:47 |
gnarface | conifer: any specifics about the permissions of what? | 22:47 |
conifer | and I don't really have an idea how I broke it | 22:47 |
systemdlete | you mentioned additional heat when running with the microcode package installed. This is a desktop, and it has a fan, heatsync, etc etc. | 22:48 |
gnarface | systemdlete: it was a couple degrees warmer when idling. it was not a big deal. | 22:48 |
systemdlete | In fact, I think I have about 6 fans total (including the PS) | 22:48 |
conifer | I get a gui message "cannot run firejail sandbox, you might not have the correct permissions to run this program" | 22:49 |
systemdlete | my PS is deluxe, apparently, it has 2 fans (one inside and one outside) | 22:49 |
conifer | firejail itself runs fine | 22:49 |
conifer | i.e. I run apps in firejail without problems | 22:49 |
gnarface | conifer: it was working fine before, or did you migrate from Debian? i don't know anything about firejail really, but permissions issues are common when migrating from Debian | 22:50 |
systemdlete | next time the flashing and freezing starts again, I'll reboot. I'll install the microcode package now though so it will be ready at next boot. | 22:50 |
gnarface | systemdlete: the primary complaint people are having is that it hampers performance for some workloads | 22:51 |
conifer | it's a fresh beowulf installation. I don't have good experience in upgrading neither debian nor devuan | 22:51 |
fsmithred | conifer, is firejail-profiles installed? | 22:52 |
fsmithred | in buster/beowulf it's a separate package | 22:52 |
conifer | yes, it is, the backports version | 22:52 |
gnarface | systemdlete: (10-20% for Intel chips... enough that even Kernel developers are risking the security problems by avoiding the patch, but for AMD FX chips, probably not as much as that) | 22:53 |
systemdlete | interesting, thank you for that info gnarface. I note that firmware-amd-graphics is installed already. So I think you were right that the GPU issues are probably not addressed by the cpu microcode. | 22:53 |
conifer | I tinkered with net.core.bpf_jit_harden kernel.kptr_restrict and kernel.yama.ptrace_scope but it doesn't seem to matter in this case | 22:53 |
systemdlete | all good info gnarface. thanks again and again. | 22:54 |
gnarface | systemdlete: no problem | 22:54 |
gnarface | conifer: you have the backports versions of both packages, right? | 22:54 |
gnarface | conifer: (usually backports stuff is intended to be used as a set) | 22:55 |
conifer | firetools don't have a backports version | 22:55 |
fsmithred | firejail and firejail-profiles | 22:55 |
conifer | but firejail & profiles are both from the backports | 22:56 |
fsmithred | ok, good | 22:56 |
conifer | I can run firetools as root, but it doesn't run the apps as intended (at all) | 22:56 |
fsmithred | I made an alternative to firetools because I didn't like it. Couldn't edit which apps showed up in it. Is it still like that? | 22:57 |
conifer | when I run it as root I get "QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000 instead of 0" | 22:59 |
conifer | not sure if this helps, but this is what I see in terminal | 22:59 |
fsmithred | oh, are you using 'su' or 'su -' to get root? | 22:59 |
conifer | su without dash | 22:59 |
fsmithred | the behavior of su changed | 23:00 |
fsmithred | if you want the old way | 23:00 |
fsmithred | echo 'ALWAYS_SET_PATH yes' >> /etc/default/su | 23:00 |
gnarface | conifer: uid 1000 belongs to the first regular user you created. uid 0 is root. that error seems fairly straightforward. it's saying it wants the directory owned by root | 23:00 |
conifer | and firetools doesn't start any apps, term shows "The new log directory is /proc/27928/root/var/log" | 23:00 |
fsmithred | you can't start apps with firejail as user? | 23:00 |
gnarface | conifer: oh. yea, probably you used su instead of "su -" to make that directory, so you didn't inherit root's environment and it made it as your regular user | 23:01 |
conifer | when I run it with "su -" I get "qt.qpa.screen: QXcbConnection: Could not connect to display" | 23:01 |
gnarface | conifer: root's environment doesn't have DISPLAY defined, so you'll have to set it manually there | 23:02 |
conifer | "Could not connect to any X display" and it doesn't run at all | 23:02 |
gnarface | conifer: DISPLAY=":0.0" [command] | 23:02 |
conifer | OK, but I shouldn't need to be root to run firetools at all, right? | 23:02 |
fsmithred | right | 23:02 |
fsmithred | you should not want to run any desktop apps as root | 23:03 |
conifer | exactly | 23:03 |
gnarface | conifer: i honestly don't know enough about firetools. if you think not, i think you're right because that sounds sane. but you might need to still set up the directories as root initially | 23:03 |
gnarface | conifer: if you correct the permissions on that directory to be whatever it actually wants, i assume it will start working again. | 23:04 |
gnarface | conifer: (in the future when you use "su" always use "su -" now instead) | 23:04 |
fsmithred | that way you get root's path | 23:05 |
conifer | which dir do you mean? /run/user/1000 ? | 23:05 |
gnarface | conifer: yea, because that's the one from the error you reported, but there may be others | 23:05 |
gnarface | conifer: (remember, i dont' know anything about firejail) | 23:05 |
gnarface | conifer: (or firetools, other than what i've gleaned by context here) | 23:06 |
gnarface | conifer: i'm somewhat suspicious that /var/user/1000 is even the right name, honestly. if it wasn't supposed to be using 1000 for the UID, i can't imagine it was supposed to be using 1000 for the name either. what does that directory actually show for current ownership and permissions? | 23:07 |
conifer | also, my display seems not to be 0.0 ;_; | 23:07 |
gnarface | it should be unless you have 21 | 23:07 |
gnarface | 2* | 23:07 |
gnarface | are you running multiple Xorg instances? | 23:07 |
gnarface | you might also get permissions errors from Xorg if you don't run "xhost +" or "xhost +localhost" or something like that first | 23:08 |
gnarface | su -c should bypass that though | 23:09 |
fsmithred | there is /var/run/user/1000 | 23:09 |
* gnarface does not have either | 23:09 | |
fsmithred | maybe it's an elogind thing? | 23:09 |
gnarface | maybe | 23:10 |
conifer | _run/user is owned by root, 755, /run/user/1000 is owned by user, 700 | 23:10 |
gnarface | but this should have worked: DISPLAY=":0.0" su -c [command] | 23:10 |
gnarface | conifer: 700 would mean only that user can access it | 23:11 |
gnarface | conifer: is it the right user though? | 23:11 |
conifer | it's a laptop, there is only this one user and root | 23:12 |
conifer | I don't think I have multiple xorgs... | 23:12 |
fsmithred | I'm not sure I understand what you're trying to do | 23:12 |
conifer | run firetools as a regular user, it used to work in the past | 23:13 |
fsmithred | ok. Do you use that just to start apps in firejail, or do you use some of the other functions it has? | 23:13 |
conifer | ...or am I seriously not remembering things?... | 23:14 |
fsmithred | been a few years since I tried firetools, but I always ran it as user. | 23:14 |
fsmithred | it put a dock on the desktop with a few app buttons | 23:14 |
conifer | I used it see if the apps and jails closed correctly | 23:15 |
fsmithred | ok, my script doesn't do that part. It just starts the apps. | 23:15 |
conifer | and shut the jails with misbehaving apps | 23:15 |
fsmithred | how would one do that manually? | 23:16 |
fsmithred | I'm running 2 apps in firejail and I have 4 firejail processes running. | 23:16 |
conifer | without firetools I kill the app or its jail (whichever works) either from console or gui task manager | 23:17 |
fsmithred | I just closed ff and the two firejail processes for it went away on their own | 23:18 |
fsmithred | but nothing was misbehaving | 23:18 |
conifer | yeah, they usually do. but sometimes the app seem to close, but its firejail remains open with some memory still occupied | 23:19 |
fsmithred | You could try this and see if it does enough of what you want: https://sourceforge.net/projects/refracta/files/Extras/firemenu-1.2.deb/download | 23:19 |
fsmithred | I actually have a newer script that's better, but it's not packaged. | 23:20 |
fsmithred | and it needs yad to run (like zenity but more) | 23:20 |
fsmithred | https://sourceforge.net/projects/refracta/files/Extras/firemenu-1.2.deb | 23:21 |
fsmithred | wget the second one | 23:21 |
fsmithred | Here's the updated script: http://distro.ibiblio.org/refracta/files/extra_packages/firemenu | 23:23 |
fsmithred | I need to go make dinner. bbl. | 23:23 |
conifer | sure, np, enjoy your meal :) | 23:24 |
conifer | thanks for your help so far | 23:24 |
systemdlete | Does anyone know approximately when Chimaera is due to arrive? I know it is dependent on how many hands are working on it, etc, etc, and various unknowns. But is it a month away, 6 months, a year... just broadly speaking is what I am asking. | 23:30 |
systemdlete | (And I know you hate this question: Are we there yet? Are we there yet?) | 23:30 |
gnarface | systemdlete: not until after Debian's goes stable. so... you have a while probably. | 23:30 |
systemdlete | It sounds like devuan is now "all caught up" with the official release levels of Debian then? | 23:31 |
systemdlete | I just don't want to do an upgrade only to find out it is out of date a few weeks later. | 23:32 |
gnarface | systemdlete: well for the moment it's caught up, but that doesn't mean Chimera will be released hot on the heels of Bullseye. it'll probably at least take a few months like the others did. | 23:32 |
systemdlete | sure, sure. I figure as much. | 23:32 |
gnarface | systemdlete: no, it's not even something you need to worry about until after you hear Debian's next release gets marked stable | 23:33 |
systemdlete | There's all that careful surgery that needs to be done, to cut away the rot and infestation... | 23:33 |
Jjp137 | if you want something remotely concrete, the hard freeze for Debian Bullseye would be on 2021-03-12 (source: https://release.debian.org/bullseye/freeze_policy.html) | 23:33 |
gnarface | systemdlete: there's no conceivable situation where Chimera will go stable before Debian's corresponding release does. | 23:33 |
Jjp137 | but yeah even then you'll be waiting for quite a few more months | 23:33 |
systemdlete | OK. thanks all. | 23:33 |
gnarface | you're actually pretty much in the sweet spot for the right time to upgrade to beowulf right now. make a backup first to be sure obviously, but really right now, beowulf is fresh but not raw. | 23:34 |
gnarface | ascii is starting to get stale | 23:35 |
systemdlete | yeah | 23:35 |
systemdlete | boy is it ever... | 23:35 |
gnarface | gtx 1060 still needs beowulf-backports kernel to work | 23:37 |
gnarface | so depending on your hardware you might still need backports | 23:37 |
systemdlete | gnarface: No need for backup, as I'll be using separate partition(s). I have never directly clobbered an existing system for the last 15 years. For one thing, it is nice to keep the older version around for reference (cross-mounting). If anything goes terribly wrong, the old partition is still there so I can do things like get online and run down the source of the problem(s), etc. | 23:37 |
gnarface | systemdlete: hehe, sounds like famous last words to me, but i trust you know what you're doing. | 23:38 |
systemdlete | Goodness gnarface. I don't think I have any hardware here from the current era. | 23:38 |
gnarface | you'll probably be fine then | 23:39 |
systemdlete | I do backups of the host and most VMs (I don't bother backing up most test VMs) | 23:39 |
gnarface | beowulf has been very stable looking here | 23:39 |
systemdlete | So even if I need it, backups are available to me. | 23:39 |
systemdlete | I am running beowulf on a couple of VMs already, and yes, it is fine. Any issues are probably stemming from the host still being ascii (stale, as you say) | 23:39 |
systemdlete | I mean, I could just update the host kernel to the backports kernel... it is the same (4.19.0) as beowulf kernel I think. | 23:40 |
gnarface | might help, but i honestly couldn't be sure | 23:41 |
systemdlete | But it seems like it would be a good idea to get off ascii already. I don't want to be 2 releases downrev when Chimaera finally arrives. | 23:41 |
gnarface | yea i think it's the same version or nearly though | 23:41 |
systemdlete | package level is different. But the same kernel release number. | 23:41 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!