| paculino | I'm not sure what I did. Either the check mark for staying logged in is required to stay logged in after searches, or I really messed up building this browser | 00:01 |
|---|---|---|
| gnarface | plasma41: didn't try actually, not really sure i remember how actually... haven't had to actually use postscript on a printer since the 90's | 00:37 |
| gnarface | (like, before there was a HP open source driver) | 00:37 |
| gnarface | is there an option for that in chromium or something? | 00:39 |
| rrq | fsmithred: the search form is a plan html form so shouldn't require javascript | 01:00 |
| rrq | perhaps some browser need js for form submission ? | 01:01 |
| gnarface | shouldn't, if the html is correct.... | 01:02 |
| gnarface | (looking) | 01:02 |
| gnarface | not seeing anything obviously wrong with it though | 01:03 |
| gnarface | i seem to remember some old IE browser bug involving name and id attribute conflicts, but i think that was with javascript, not without... hmmm | 01:03 |
| rrq | the only javascript on the forum is for the quick reply (add/remove bbcode tags) | 01:04 |
| gnarface | oh, unless it's not the form submit itself... is there javascript involved in the redirect to the results page after submission maybe? | 01:04 |
| gnarface | some people don't know you can do that with bare HTTP headers | 01:05 |
| rrq | no other javascript | 01:05 |
| rrq | there is a css value including "url(Purpy/img/bull.png)" which probably requires javascript engine | 01:10 |
| rrq | would that stop the form submission? | 01:12 |
| rrq | a couple of "url(..)" values | 01:12 |
| rrq | that's not very new css "syntax" but possibly it requires javascript enabling | 01:15 |
| gnarface | i don't think so, i think that's again only in old IE versions and only if you call activex to force directx to render the pngs transparently in versions where it couldn't do without | 01:18 |
| gnarface | my memory is foggy on the whole mess, but iirc it would change the part between the () in an obvious fashion | 01:19 |
| gnarface | (and i'm not sure javascript was even required for that, but it might have been since it was using an activex hook) | 01:19 |
| rrq | hmm how do I turn off javascript in chromium? | 01:20 |
| gnarface | also dunoo | 01:20 |
| gnarface | *dunno | 01:20 |
| gnarface | there's not any guarantee it's even possible, but one would think it is... | 01:20 |
| onefang | killall -TERM chromium # Should turn off javascript. B-) | 01:21 |
| rrq | i found a settings toggle but that didn't stop my logged-out search on the forum | 01:22 |
| rrq | it does stop the bbcode shortcut buttons from having effect at least | 01:25 |
| golinux | That is NOT a function we should lose. . . . | 01:51 |
| gnarface | is anyone else here using the "position_fix" module option to the snd_hda_intel driver? i'm trying to figure out why recordings stopped working, and it seems like they moved what used to be position_fix=3 to something else, and i'm suspecting 6 from testing, but not sure because the descriptions i can google up don't seem to have changed what 3 is supposed to do | 01:52 |
| gnarface | actually, what it seems like, by description is they moved it to 4, but only 6 is actually working for me | 01:53 |
| gnarface | 3 doesn't work at all and 4 actually causes the problem i was trying to avoid | 01:53 |
| gnarface | (which is static in the recordings) | 01:59 |
| rrq | "``position_fix=6`` is to correct the position with the fixed FIFO | 02:11 |
| rrq | size, mainly targeted for the recent AMD controllers. | 02:11 |
| gnarface | yea, what throws me about that though is that i wouldn't consider this a "recent" AMD controller | 02:12 |
| gnarface | and from memory, the description of 4 matches what i thought was 3 before | 02:12 |
| gnarface | and 3 used to work | 02:12 |
| gnarface | i guess i'll just go with it since it's the one that says AMD but i wish i had a qualifier of what counts as "recent" in this context | 02:13 |
| gnarface | (i fully expect to have to change it again some time in the future) | 02:13 |
| gnarface | the default setting of 0 used to work, originally, though i'm not sure how many kernels ago that was... | 02:14 |
| rrq | right .. the Documentaiton changed Wed Aug 28 16:34:36 2019 +0200 | 02:15 |
| rrq | I need to check the module itself I guess | 02:15 |
| gnarface | ...wow, had it really been that long since i did an analog recording? i guess it might have been... | 02:16 |
| gnarface | well, at the time i originally found 3 to work, it wasn't even in the documentation yet though | 02:16 |
| gnarface | a post somewhere hinted that position_fix=1 would correct the regression i had then, and only 1 and 2 were documented, and neither of them actually helped, so on a whim i tried 3, in my head having already accepted defeat, and then was surprised it worked | 02:17 |
| gnarface | but that might have been something like 2016 | 02:18 |
| gnarface | and then after that i guess mainly had switched to a USB mic, so didn't notice the subsequent regression apparently | 02:19 |
| rrq | Sat Oct 1 16:21:24 2022 +0200 .. says something about position_fix=1 being fixed | 02:20 |
| gnarface | hmm | 02:20 |
| rrq | commit aab77d312dc39aeffe24223f00ea7c2acf6543cd seems to introduce position_fix=6 | 02:25 |
| rrq | refers to "commit c02f77d32d2c45cfb1b2bb99eabd8a78f5ecc7db upstream." | 02:27 |
| rrq | no that was the latest commitlog with that reference | 02:29 |
| rrq | (I'm just browsing the git log) | 02:30 |
| rrq | yes, now I've down to 2014 with fair few notes about dealing with "position" issues | 02:33 |
| gnarface | the thing is, before this all started, it was working fine, so i'm really curious why it became such a support issue after working fine for years, but it's not like i haven't had other issues with the same driver on previous motherboards, and i doubt i'd be able to really understand the details if shown in code anyway | 02:34 |
| gnarface | but what it seems like, from my perspective, is sabotage | 02:35 |
| rrq | seems that note about "recent AMD" turned up at Tue Aug 6 17:31:48 2019 +0200 | 02:36 |
| rrq | .. the changelog also talks about "mysterious stalls in pulseaudio" | 02:37 |
| gnarface | hmm... | 02:38 |
| rrq | BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195303 | 02:39 |
| gnarface | wikipedia says this motherboard is from 2011 | 02:39 |
| gnarface | that's definitely the right bug though | 02:40 |
| rrq | in 2019: "A long-time problem on the recent AMD chip (X370, X470, B450, etc with PCI ID 1022:1457) with Realtek codecs ... | 02:40 |
| gnarface | sound capture crackling is definitely the description i'd have used anyway | 02:41 |
| gnarface | it's a 990FX | 02:41 |
| gnarface | i think the manual called the soundcard "Azalia" but alsamixer calls it Realtek ALC892 | 02:42 |
| hacksenwerk | Is wayland somehow bound to Poetterware? | 11:47 |
| hacksenwerk | Because we should highly avoid using xorg any longer... | 11:48 |
| hacksenwerk | Every program running in a xsession can read __all__ keyinputs every othe rprogram running in the same xsession gets! | 11:52 |
| hacksenwerk | And Xorg has no support for GUI-level isolation and wont get that as it seems. | 11:52 |
| hacksenwerk | That's a security nightmare! | 11:53 |
| Wizzup | this is not really news though? I think the xorg ml had some isolation work done recently, at least some proposed. | 11:53 |
| hacksenwerk | Xorg is a keylogger. | 11:53 |
| Wizzup | is this a troll account or what? | 11:53 |
| hacksenwerk | Wizzup: yes its not new that's the problem here. | 11:53 |
| Wizzup | sounds like you're the right person to fix it | 11:54 |
| hacksenwerk | Wizzup: theres no isolation and stop trolling me with your fuck*ng troll accusations! | 11:54 |
| hacksenwerk | Wizzup: just stfu! Ignored! | 11:54 |
| hacksenwerk | This issue is in xorg since day one and noone is going to fix it. | 11:55 |
| hacksenwerk | I do not undersatnd why nobody does care aboyt that. | 11:56 |
| hacksenwerk | If I knew that before I would have dropped xorg already... | 11:57 |
| hacksenwerk | rrq: please report here too. | 12:00 |
| hacksenwerk | User rrq found out that disabling RECORD and/or XTEST extension does __not__ stop the key sniffing / key logging | 12:07 |
| rrq | the X11 protocol doc suggests a window may declare "do-not-propagate" for KeyPress/KeyRelease event to stop its propagation down to the root window which presumably is where the sniffing occurs | 12:13 |
| rrq | i.e. a windowing client program could declare that for its root window so as to confine its key press/release events... needs some testing I suppose | 12:15 |
| hacksenwerk | For everyone whos not in #devuan-offtopic I will link here the guide to reproduce the procedere I described: https://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html | 12:17 |
| hacksenwerk | Note: install the package xinput and use xinput --test id_here | 12:17 |
| hacksenwerk | The rest still is correct in the article. | 12:18 |
| Wizzup | https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1865 | 12:51 |
| hacksenwerk | Applications that support wayland are isolated from each other and do not suffer from that keylogging issue. But when you run applications that do __not__ support wayland, wayland will use a legacy fallback and the application is still affected by the keylogging issue. | 13:12 |
| hacksenwerk | rrq: Please report again if you find out. | 13:37 |
| drink | Hi. I'm having a little trouble with docker and the latest backports kernel on daedalus amd64, is this an appropriate place to ask about that? | 14:27 |
| Xenguy_ | drink, This is the Devuan Support Channel, so no harm in asking, but be patient for a reply. | 14:45 |
| drink | Sounds reasonable. Since updating to kernel 6.12.12 I am having problems with Docker and memory cgroup. It affects my ability to use CUDA with Docker. It works for a little while and then stops, which ollama says is about memory cgroup. Docker output shows e.g. time="2025-03-15T05:33:02.867831941-07:00" level=error msg="add cg to OOM monitor" error="cgroups: memory cgroup not supported on this system" | 14:47 |
| drink | I have tried adding all of "cgroup_enable=cpuset cgroup_enable=memory cgroup_memory=1 systemd.unified_cgroup_hierarchy=0" to my cmdline in various pieces and no combo has helped. | 14:48 |
| drink | /proc/cgroups does not show memory, but lscgroup does, though it shows "cpuset,memory:/" | 14:49 |
| rrq | hacksenwerk: it's possible to set the do-not-propagate attribute for a window to avoid the root window sniffing of key events | 15:09 |
| rrq | though it's equally possible and easy to reset that attribute | 15:10 |
| hacksenwerk | rrq: :( | 15:17 |
| hacksenwerk | My next devuan installation I will use wayland. But I need to figure out first how to get a minimal setup like I have now with X. | 15:18 |
| hacksenwerk | You need the protocol wich is wayland. Then you need a server that is called wayland compositor. | 15:20 |
| hacksenwerk | I use only a minimal xserver and a window manager. | 15:21 |
| hacksenwerk | Still reading about wayland... | 15:21 |
| hacksenwerk | All wayland compositors I've found are also window managers.... | 15:25 |
| hacksenwerk | And what they call minimal is a joke... | 15:25 |
| drink | Hmm, looks like the v1 memory cgroup option wasn't set. How unfortunate. Anyone know how to set the abiname? debian/config/defines doesn't seem to exist | 15:29 |
| drink | welp building a new kernel with CONFIG_MEMCG_V1=y fixed it, weird they changed that setting. | 16:02 |
| hacksenwerk | rrq: can you do a pastebin of what youve done, or write a forums post? | 16:19 |
| rrq | https://git.rrq.au/?p=rrq/newlisp/pinwin.git;a=blob_plain;f=keystop.lsp;h=cd08cb3fcc4040ed1782d21713fe003c7c2bb798;hb=HEAD | 16:20 |
| rrq | .. a short newlisp script | 16:20 |
| rrq | it sets/resets the KeyPressMask/KeyReleaseMask bits of the do_not_propagate_mask attribute, merging with whatever setting there might be otherwise | 16:22 |
| rrq | needs to be done on the "Window id" returned by xwininfo | 16:23 |
| hacksenwerk | rrq: Ok thanks, but how to use this? | 16:23 |
| rrq | for the targeted window | 16:23 |
| rrq | to stop propagation: keystop.lsp 0x240b0f4 1 | 16:24 |
| rrq | to start propagation: keystop.lsp 0x240b0f4 0 | 16:24 |
| rrq | install newlisp first of course | 16:24 |
| rrq | that number, 0x240b0f4, is the Window id returned by xwininfo for the target window | 16:25 |
| rrq | you may also use the ids from "wmctrl -l" | 16:28 |
| hacksenwerk | rrq: I have no clue xD | 16:29 |
| hacksenwerk | A HowTo in the forum would be nice. | 16:29 |
| hacksenwerk | gtg | 16:43 |
| rustyaxe | O_o excalibur installer seems borken. "Unmerged /usr is not compatible with excalibur" -- ok then why are you trying to install unmerged /usr? | 18:24 |
| greenjeans | How are you trying to install? What iso are you using? | 18:26 |
| rustyaxe | latest from leaseweb mirror: looks to be devuan_excalibur_6.0-20241017_amd64_netinstall.iso | 18:28 |
| rustyaxe | USB stick install | 18:29 |
| rustyaxe | i can always grab daedalus and upgrade from there, but im in the installer menu if anything useful can be gathered or worked around before i reboot | 18:29 |
| greenjeans | Gotcha...no experience myself with the excalibur netinstall isos | 18:30 |
| rustyaxe | No worries, just wanted to note the issue and see if anything useful i could offer before i go the daedalus and upgrade route | 18:30 |
| greenjeans | Upgrade route seems to be working pretty well, and today is first small freeze. | 18:31 |
| rustyaxe | ya thats how i usually go | 18:31 |
| rustyaxe | Just figured i'd grab/try the new iso | 18:32 |
| greenjeans | Problem is no new netinstall iso's since last fall, need somebody with some serious skills to take on that job | 18:33 |
| greenjeans | Above my skill level or I would try | 18:33 |
| greenjeans | I have a working Mate-mini of excalibur I made a couple days ago, hybrid-iso, if you're looking for a quickie working install and don't mind Mate it may be something that would work for you | 18:34 |
| rustyaxe | these dont even have vga hardware (: | 18:36 |
| rustyaxe | ty tho | 18:36 |
| rustyaxe | ive got devuan_daedalus_5.0.1_amd64_netinstall.iso installing now | 18:37 |
| greenjeans | Cool, good luck! (don't forget to usrmerge, lol) | 18:41 |
| fsmithred | rustyaxe, choose expert install and you'll get the usrmerge question. Say yes. | 19:08 |
| fsmithred | ok, if you upgrade to excalibur, install usrmerge first. (I think you now get prompted to do that during the upgrade if you haven't already done it.) | 19:10 |
| rustyaxe | fsmithred: Got ya, ill keep that in mind if go with the excalibur iso again. so far all good with daedulus and about to upgrade | 19:18 |
| Xenguy_ | rustyaxe, https://www.devuan.org/os/announce/excalibur-usrmerge-announce-2024-02-20.html | 20:10 |
| rustyaxe | Xenguy_: yea usually i install daedalus then upgrade, figured i'd try the excalibur iso since needed to download a copy | 20:11 |
| rustyaxe | really i should just set my pxe install server back up | 20:12 |
| hacksenwerk | since when did /etc/inputrc set bell-style none stopped working? | 23:32 |
| hacksenwerk | I hear a beep on tty when reaching the top of a file in vim for example. | 23:32 |
| hacksenwerk | Oh I changed from usb soundcard to onboard sound | 23:41 |
| hacksenwerk | But the beep is disabled in alsamixer... | 23:41 |
| hacksenwerk | and also in inputrc | 23:41 |
| Hurgotron | I just remember that I once wanted to enable the beep (via pc speaker), and that was surprisingly hard to find out | 23:47 |
| rwp | I blacklist the modules pcspkr and snd_pcsp to prevent any beeping to come out of pc speakers. | 23:53 |
| hacksenwerk | Hurgotron: :) | 23:56 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!