gnarface | [NoClan]GoAway: i think the primary benefit of kvm is performance, if you have hardware that supports it | 02:47 |
---|---|---|
gnarface | if caronte comes back, someone clarify for them that the list of supported hardware i386 and amd64 hardware is the same as debian's | 02:48 |
gnarface | [NoClan]GoAway: and if you do an upgrade, it shouldn't clobber any config files you've customized | 02:49 |
gnarface | (but you should always make a backup first, just in case) | 02:49 |
xisop | greetings. when i use the tty console (not sure if that's the correct term for it..) sometimes the blinking cursor disappears. by tty i mean hitting ctrl+alt+f1-6 | 05:25 |
xisop | is there a way to reset it to get the cursor back? i noticed it seems to happen if i spin up vim | 05:25 |
rrq | you mean the text input cursor or the one that gpm brings? | 05:28 |
xisop | the text cursor that usually shows up at login and continues to show up throughout the session | 05:29 |
debdog | could be silent mode which happens when one accidently hits ctrl-s | 05:29 |
xisop | hmm. maybe i should check that my bash/vim are using the correct term type | 05:29 |
debdog | quit it with ctrl-q | 05:29 |
xisop | does that usually block input though? | 05:30 |
debdog | the input is silent | 05:34 |
debdog | not blocked | 05:34 |
rrq | try 'tput cnorm' to get back the cursor | 05:44 |
rrq | (man 5 terminfo) | 05:47 |
rwp | xisop, What TERM are you using? AFAIK it should be TERM=linux on the Linux vt consoles. | 06:00 |
lts | xisop: there is literally the command "reset" to reset a tty | 06:02 |
xisop | sorry, i was away. the good news is that i haven't experienced it this boot | 06:04 |
xisop | i will likely write an alias in my .bashrc that has tput cnorm and possibly 'reset' as well | 06:04 |
gnarface | uh, i'm pretty sure ctrl+s will actually lock the terminal | 06:35 |
onefang | Pause, not lock. | 06:35 |
gnarface | well, inputs and outputs will queue up until you hit ctrl+q but i'm pretty sure nothing input-wise takes effect until then | 06:36 |
onefang | Except the ctrl-q obviously. B-) | 06:36 |
gnarface | background tasks will still run in some cases, but some stuff will actually stall waiting for terminal output to be acknowledged, i'm not super clear on the details | 06:36 |
debdog | hmm, good point | 06:37 |
gnarface | now that i'm thinking about it though, i can't recall if that'll stop the cursor blink too or not | 06:37 |
gnarface | anyway, it's a good theory, the only other thing that comes to mind is maybe a framebuffer driver issue just making the cursor invisible | 06:39 |
gnarface | but if it's just some state corruption based on bad binary character outputs leaking out somewhere, typing "reset" (then hitting enter) should indeed still work to clear it, even if you can't see the "reset" text output, or (usually) even if it comes out as garbled characters | 06:40 |
gnarface | i would try both in order (ctrl+q then the "reset" command) and if neither worked look into trying a different driver for the console | 06:43 |
gnarface | the current trend is to default to kms/modesetting for everything, but in some cases that's still not the best choice for all hardware | 06:43 |
debdog | hit ctrl-s then "date" enter. then went boiling water for tea when I came back ctrl-q. it definitely shows the time of input and not ctrl-q. | 06:45 |
gnarface | hmm, interesting | 06:46 |
debdog | interstingly the clock on my screen-statusbar also stopped updating | 06:46 |
gnarface | so then if that's the case, reset might work invisibly first, then the fix would show up after ctrl+q | 06:47 |
debdog | probably yes | 06:48 |
onefang | Ah screen-statusbar. I have often had to reset when running tmux, usually when an ssh to somewhere fell over coz the connectien died, and the ssh was displaying some TUI thing that had left the terminal in afunny state when it fell over. | 07:15 |
gnarface | debdog: now this is interesting though, when i ctrl+s then type date then ctrl+q, the output date is definitely the time of ctrl+q not the initial typing of the date command | 07:23 |
gnarface | that's IN x though | 07:23 |
gnarface | er, in X i mean | 07:23 |
gnarface | so maybe it's different if you tested that at the system virtual terminal? | 07:23 |
gnarface | or maybe it's a terminal, shell, or even window manager difference? | 07:24 |
gnarface | this rings a bell, like we've been over this before | 07:27 |
debdog | gnarface: xterm plus screen | 07:28 |
debdog | echo $SHELL | 07:29 |
debdog | /bin/bash | 07:29 |
debdog | windowmanager: fluxbox | 07:29 |
gnarface | interesting | 07:29 |
gnarface | i'm using urxvt, bash, and enlightenment | 07:30 |
gnarface | no screen | 07:30 |
gnarface | could it be something to do with screen? | 07:30 |
debdog | testing without... | 07:30 |
gnarface | it's gotta be something, because it had always been my understanding that pending inputs would fire after unlocking the terminal | 07:31 |
gnarface | but pending outputs, whether they actually ran their jobs or not instead of waiting for the terminal would depend on how they were coded | 07:31 |
debdog | I remember it differently. s stands for silent hence to shell works but there is no output visible | 07:32 |
debdog | ohh, without screen it displays the ctrl-q time | 07:33 |
debdog | well... | 07:33 |
onefang | xisop mentioned tty console, so no window manager. | 07:35 |
debdog | yes, and the solution was a different one | 07:37 |
gnarface | wait, but was there a solution actually mentioned? i thought we were still waiting for the issue to happen again | 07:42 |
debdog | I thought so <xisop> i will likely write an alias in my .bashrc that has tput cnorm and possibly 'reset' as well | 07:42 |
gnarface | oh, so maybe | 07:43 |
gnarface | hmmm... | 07:44 |
onefang | More a workaround than a solution. | 07:46 |
gnarface | well the real curiosity is what's doing it? | 07:47 |
gnarface | i'm interested in the low-level cause | 07:48 |
Ava | did u tried this prize draw https://t.co/bWI707eqmZ is it work or not ? | 11:58 |
Ava | ??? | 11:59 |
RhineDevil | I'm trying to use pipewire on devuan testing, the setup works by running this script on boot: https://paste.debian.net/hidden/ed0ab46f/ | 13:06 |
RhineDevil | Worked before but on last update plasma doesn't recognize pipewire | 13:06 |
u-amarsh04 | confused by this (my report): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030934 | 15:20 |
RhineDevil | XDG_RUN_DIR in my environment is empty, how do I fix? | 15:57 |
gnarface | you mean XDG_RUNTIME_DIR? | 15:58 |
mcr | I guess I gotta stop relying/using apt-cacher(-ng). It used to work so well :-( | 15:58 |
RhineDevil | gnarface: yes exactly | 15:58 |
gnarface | i think if it's not set and something is complaining it's a bug in your window manager | 15:59 |
gnarface | but i have had the same problem before, hang on i'll get you a script | 15:59 |
RhineDevil | gnarface: would be nice if the problem was addressed officially since the value in debian is set in libpam-systemd | 16:00 |
gnarface | hmm | 16:00 |
gnarface | i'm not sure there's not an official way | 16:01 |
RhineDevil | gnarface: if you can make it present to higher-ups, in the meantime pass me a script or something | 16:03 |
gnarface | yea | 16:04 |
RhineDevil | gnarface: what do you think about export XDG_RUNTIME_DIR="${XDG_RUNTIME_DIR:-/run/user/$(id -ru)}" as a temporary fix? | 16:07 |
RhineDevil | in /etc/bash.bashrc | 16:07 |
RhineDevil | in this way it provides an harmless default easily overrided | 16:09 |
gnarface | https://paste.debian.net/1270148/ | 16:09 |
gnarface | try this | 16:09 |
gnarface | i'd put it in your user's profile but up to you | 16:10 |
gnarface | i had put it in my ~/.bash_profile, but if you have a ~/.profile instead already, i'd put it there | 16:10 |
gnarface | not sure why but it seems to be the convention to define this type of stuff in the bash profile rather than the bashrc | 16:10 |
gnarface | there's a global one too but if this is your only user and nobody else uses the system i'm not sure there's any sense in making it global | 16:11 |
gnarface | https://paste.debian.net/1270149/ | 16:11 |
gnarface | if for some reason the first one doesn't work, try this one instead! | 16:11 |
gnarface | i mean ^ | 16:11 |
gnarface | RhineDevil: | 16:12 |
RhineDevil | gnarface: I think I'll stick to my solution, after all /var/run/user/$(id -ru) still gets created on session login | 16:12 |
RhineDevil | and it's chmoded for the current user | 16:12 |
gnarface | well whatever works | 16:13 |
RhineDevil | so no reason for creating a tmp runtime dir in /tmp/ in my opinion... | 16:13 |
RhineDevil | yeah | 16:13 |
gnarface | well just that everything else does it and that's what /tmp is for | 16:13 |
gnarface | but neither place is actually where this directory is s' | 16:14 |
gnarface | ... is "supposed" to go, i don't think | 16:14 |
gnarface | i think when it is working it goes somewhere in your home directory but i'm not sure | 16:14 |
RhineDevil | gnarface: didn't work, I guess the cause is plasma starting before profile or bashrc are run | 16:28 |
gnarface | RhineDevil: if you have a graphical login, it has to be set in its environment | 16:29 |
gnarface | RhineDevil: oh, plasma might just not be actually running your bash profile at all, too | 16:29 |
RhineDevil | As I thought, after forcing a restart of plasma it worked | 16:29 |
RhineDevil | gnarface: it runs it, just way later | 16:30 |
gnarface | does it run the global one earlier? | 16:30 |
RhineDevil | but I can't restart plasma just cause I want to have sound | 16:30 |
RhineDevil | gnarface: yeah the global one | 16:30 |
RhineDevil | ok uhm where the f should I put user variables even before plasma starts? | 16:32 |
RhineDevil | this things wacky af | 16:33 |
gnarface | hmm, try ~/.xsession | 16:34 |
gnarface | or maybe ~/.xsessionrc | 16:35 |
gnarface | actually, try putting this in ~/.xsessionrc: | 16:36 |
gnarface | . $HOME/.profile | 16:36 |
gnarface | then you can just add the XDG variable to your .profile as normal | 16:37 |
RhineDevil | gnarface: since I want global stuff, added the line in /etc/X11/Xsession.d/40x11-common_xsessionrc | 16:39 |
RhineDevil | see you in less than 1 min probably | 16:39 |
RhineDevil | gnarface: worked as expected | 16:42 |
gnarface | the reason to prefer the user one over the global one is then if it gets changed during an upgrade you don't have to worry about it getting clobbered or having to be manually merged | 16:43 |
RhineDevil | gnarface: I know, but packages offer you to keep global files, and most times it makes sense to do that | 16:46 |
dan9er[m] | The APT source onion service is down | 17:15 |
dan9er[m] | Keep getting Host Unreachable in aptitude, and when try to visit via Tor Browser it says the onion url is not on the hash chain | 17:17 |
[NoClan]GoAway | gnarface: thanks for the info. | 18:13 |
caronte | hey all | 22:28 |
debdog | oy | 22:33 |
caronte | Since I am a Devuan wannabe, I have anyway a question if somebody has still Ubuntu machines | 22:44 |
caronte | Hope it doesn´t sound trollish, but lately I found Ubuntu WAY less stable than I was used to. | 22:44 |
dan9er[m] | caronte: Please don't ask to ask, just ask, you'll get an answer faster | 22:45 |
caronte | well, I did :D | 22:46 |
dan9er[m] | Ubuntu is getting more unstable? So how does this relate to Devuan | 22:46 |
caronte | dan9er[m]: I am wondering if it is related to the use of systemd and snap packages. | 22:48 |
dan9er[m] | uuuh idk, I think one will need to do a deep dive to get a definitive answer | 22:49 |
dan9er[m] | someone more knowledgeable here can tell you some of systemd's flaws that make it unstable / harder to write stable software for | 22:51 |
fsmithred | better to have that conversation on #devuan-offtopic | 22:51 |
fsmithred | and save this space for support | 22:52 |
dan9er[m] | yeah | 22:52 |
caronte | dan9er[m], dan9er[m] thank you | 22:53 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!