| 2023-02-11 00:11:34 +0100 | mc47 | (~mc47@xmonad/TheMC47) (Ping timeout: 260 seconds) |
| 2023-02-11 00:34:03 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 248 seconds) |
| 2023-02-11 01:16:16 +0100 | Forkk_ | (~forkk@li926-228.members.linode.com) (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2023-02-11 01:18:13 +0100 | Forkk | (~forkk@li926-228.members.linode.com) |
| 2023-02-11 01:18:33 +0100 | Forkk | (~forkk@li926-228.members.linode.com) (Client Quit) |
| 2023-02-11 01:19:07 +0100 | Forkk | (~forkk@li926-228.members.linode.com) |
| 2023-02-11 01:19:27 +0100 | Forkk | (~forkk@li926-228.members.linode.com) (Client Quit) |
| 2023-02-11 01:20:01 +0100 | Forkk | (~forkk@li926-228.members.linode.com) |
| 2023-02-11 01:21:19 +0100 | Forkk | (~forkk@li926-228.members.linode.com) (Client Quit) |
| 2023-02-11 01:21:54 +0100 | Forkk | (~forkk@li926-228.members.linode.com) |
| 2023-02-11 01:22:14 +0100 | Forkk | (~forkk@li926-228.members.linode.com) (Client Quit) |
| 2023-02-11 01:22:46 +0100 | Forkk | (~forkk@li926-228.members.linode.com) |
| 2023-02-11 01:56:39 +0100 | chomwitt | (~chomwitt@2a02:587:7a12:aa00:1ac0:4dff:fedb:a3f1) (Ping timeout: 256 seconds) |
| 2023-02-11 01:59:44 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-02-11 02:36:05 +0100 | shinjipf | (~shinjipf@2a01:4f8:1c1c:c1be::1) (Quit: Shinji leaves) |
| 2023-02-11 02:43:00 +0100 | shinjipf | (~shinjipf@2a01:4f8:1c1c:c1be::1) |
| 2023-02-11 02:43:26 +0100 | shinjipf | (~shinjipf@2a01:4f8:1c1c:c1be::1) (Client Quit) |
| 2023-02-11 02:47:51 +0100 | shinjipf | (~shinjipf@2a01:4f8:1c1c:c1be::1) |
| 2023-02-11 03:38:17 +0100 | nexilva[m] | (~nexilvama@2001:470:69fc:105::2:cf52) (Quit: Reconnecting) |
| 2023-02-11 03:38:37 +0100 | nexilva[m] | (~nexilvama@2001:470:69fc:105::2:cf52) |
| 2023-02-11 04:04:56 +0100 | banc | (banc@gateway/vpn/protonvpn/banc) (Ping timeout: 268 seconds) |
| 2023-02-11 04:08:07 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2023-02-11 04:20:50 +0100 | banc | (banc@gateway/vpn/protonvpn/banc) |
| 2023-02-11 04:40:58 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2023-02-11 04:58:23 +0100 | td_ | (~td@i53870923.versanet.de) (Ping timeout: 264 seconds) |
| 2023-02-11 04:59:50 +0100 | td_ | (~td@i53870908.versanet.de) |
| 2023-02-11 05:00:02 +0100 | haasn` | (~nand@haasn.dev) (Quit: ZNC 1.7.5+deb4 - https://znc.in) |
| 2023-02-11 06:07:10 +0100 | berberman | (~berberman@user/berberman) (Ping timeout: 260 seconds) |
| 2023-02-11 06:07:31 +0100 | berberman | (~berberman@user/berberman) |
| 2023-02-11 09:39:28 +0100 | <xmonadtrack> | New xmonad-contrib branch created: pull/800 (1 commit) https://github.com/xmonad/xmonad-contrib/pull/800 |
| 2023-02-11 09:39:42 +0100 | unclechu | (~unclechu@2001:470:69fc:105::354) |
| 2023-02-11 10:00:04 +0100 | nasrudin_[m] | (~nasrudinm@2001:470:69fc:105::2:f299) (Quit: You have been kicked for being idle) |
| 2023-02-11 10:05:49 +0100 | malook | (~Thunderbi@2a02:9b0:4000:8906:98ed:21f1:bb5e:feed) |
| 2023-02-11 11:00:06 +0100 | mc47 | (~mc47@xmonad/TheMC47) |
| 2023-02-11 11:51:16 +0100 | Maeda | (~Maeda@91-161-10-149.subs.proxad.net) (Quit: leaving) |
| 2023-02-11 12:09:51 +0100 | chomwitt | (~chomwitt@2a02:587:7a12:aa00:1ac0:4dff:fedb:a3f1) |
| 2023-02-11 12:14:08 +0100 | chomwitt | (~chomwitt@2a02:587:7a12:aa00:1ac0:4dff:fedb:a3f1) (Ping timeout: 248 seconds) |
| 2023-02-11 12:41:29 +0100 | Hmmf | (~Hmmf@2a01:e0a:582:bb40:e5c6:f484:7015:1722) (Quit: Client closed) |
| 2023-02-11 13:10:19 +0100 | Maeda | (~Maeda@91-161-10-149.subs.proxad.net) |
| 2023-02-11 13:55:44 +0100 | <liskin> | Solid, geekosaur: are you guys getting emails from GitHub about scheduled workflows failing? |
| 2023-02-11 13:56:14 +0100 | <liskin> | I mean, usually it's stuff that I handle anyway, I'm just curious whether you do get them or not :-) |
| 2023-02-11 13:56:57 +0100 | <liskin> | we have a failing packdeps for all repos because ghcup is completely broken on GitHub actions and will be for some time |
| 2023-02-11 14:10:47 +0100 | patrl | (~patrl@user/patrl) |
| 2023-02-11 14:46:37 +0100 | <geekosaur> | I get them for my personal forks but not for the main repo |
| 2023-02-11 14:46:54 +0100 | <geekosaur> | unless I submitted a PR |
| 2023-02-11 14:47:40 +0100 | <geekosaur> | and yes, I read about that when it happened to cabal-install, it'll be a couple of weeks before github picks up the update that fixes it |
| 2023-02-11 14:48:46 +0100 | <liskin> | oh my |
| 2023-02-11 14:54:22 +0100 | <liskin> | Notifications for scheduled workflows are sent to the user who initially created the workflow. If a different user updates the cron syntax in the workflow file, subsequent notifications will be sent to that user instead. If a scheduled workflow is disabled and then re-enabled, notifications will be sent to the user who re-enabled the workflow rather than the user who last modified the cron syntax. |
| 2023-02-11 14:54:31 +0100 | <liskin> | whoever came up with this must've been a genius |
| 2023-02-11 15:02:52 +0100 | <xmonadtrack> | xmonad Tomas Janousek * v0.17.1-45-g391c0fc: TUTORIAL: Update xmobar URL (2 minutes ago, 1 file, 1+ 1-) https://github.com/xmonad/xmonad/commit/391c0fc0c939 |
| 2023-02-11 15:42:48 +0100 | <geekosaur> | liskin: is https://github.com/haskell/cabal/commit/4756705cce74a2af1dc1b1202a1cc96b95eb6e5e worth it just for your sanity for the next two weeks? |
| 2023-02-11 15:43:57 +0100 | <liskin> | geekosaur: probably not; it's just packdeps, everything else doesn't seem to rely on ghcup on github action runners |
| 2023-02-11 15:44:16 +0100 | <liskin> | I've subscribed to the relevant github issues so I'll get an email when it's fixed |
| 2023-02-11 15:44:35 +0100 | <liskin> | unless we're planning to do a release in the following two weeks :-) |
| 2023-02-11 15:53:52 +0100 | td_ | (~td@i53870908.versanet.de) (Ping timeout: 248 seconds) |
| 2023-02-11 16:00:54 +0100 | td_ | (~td@i53870908.versanet.de) |
| 2023-02-11 17:00:06 +0100 | unclechu | (~unclechu@2001:470:69fc:105::354) (Quit: You have been kicked for being idle) |
| 2023-02-11 17:59:34 +0100 | tremon | (~tremon@83-85-213-108.cable.dynamic.v4.ziggo.nl) |
| 2023-02-11 19:20:00 +0100 | malook | (~Thunderbi@2a02:9b0:4000:8906:98ed:21f1:bb5e:feed) (Quit: malook) |
| 2023-02-11 19:20:24 +0100 | malook | (~Thunderbi@5.110.225.18) |
| 2023-02-11 19:24:41 +0100 | malook | (~Thunderbi@5.110.225.18) (Ping timeout: 255 seconds) |
| 2023-02-11 20:32:46 +0100 | <ectospasm> | I'm trying to figure out how to enable gaps/spacing on one monitor. Right now, I'm working with only one screen/display, and my current avoidStruts isn't avoiding all docks/struts. |
| 2023-02-11 20:33:00 +0100 | unclechu | (~unclechu@2001:470:69fc:105::354) |
| 2023-02-11 20:33:33 +0100 | <ectospasm> | I have a number of conky CLI commands piped into dzen2, with multiple docks at the bottom of my screen. See https://git.eldon.me/trey/XMonad/src/branch/multiheaded-fixup/xmonad.hs |
| 2023-02-11 20:34:52 +0100 | <ectospasm> | I was having a problem with those gaps still showing on my 1 and 2 monitors in a three monitor setup. I've removed the gap stuff, but now avoidStruts doesn't bring the gap on the bottom above the highest conky dzen2. |
| 2023-02-11 20:35:09 +0100 | letztesendung | (~letzte@2a00:d880:3:1::9567:bfa0) |
| 2023-02-11 20:35:14 +0100 | letztesendung | (~letzte@2a00:d880:3:1::9567:bfa0) () |
| 2023-02-11 20:35:41 +0100 | <geekosaur> | so, Gaps says: |
| 2023-02-11 20:35:53 +0100 | <geekosaur> | To configure gaps differently per-screen, use XMonad.Layout.PerScreen. |
| 2023-02-11 20:35:53 +0100 | <geekosaur> | Warning: If you also use the avoidStruts layout modifier, it must come before any of these modifiers. See the documentation of avoidStruts for details. |
| 2023-02-11 20:36:34 +0100 | <geekosaur> | (it says "coming soon" for PerScreen, but it exists now. with the downside that it works by screen size, not screen ID) |
| 2023-02-11 20:44:35 +0100 | <ectospasm> | OK, so I include PerScreen, and is there anything else I need to do for that? |
| 2023-02-11 20:46:38 +0100 | <ectospasm> | So I have to know my total screen geometry, I believe I have three screens at 1920x1080 when I have all my external monitors connected. |
| 2023-02-11 20:47:07 +0100 | <ectospasm> | The primary is in the middle, so I'd need x=1920-3840 to have the gap. |
| 2023-02-11 20:47:41 +0100 | <ectospasm> | That would need to be adjusted for when I only have one screen (like I have right now, I need to be in the room with the baby in the playpen) |
| 2023-02-11 20:54:18 +0100 | <geekosaur> | sadly, that's not how it works. it uses `ifWidth` and it sounds like the width is 1080 for all of them |
| 2023-02-11 20:55:03 +0100 | <geekosaur> | that said, the module really should be done better; I think a layout actually has the information needed to determine the actual screen number |
| 2023-02-11 21:32:33 +0100 | <ectospasm> | I thought 1920 was the width. |
| 2023-02-11 21:33:22 +0100 | <ectospasm> | Anyhow, isn't the width 5760 when I have three monitors, if they're all 1920x1080? |
| 2023-02-11 21:33:48 +0100 | <geekosaur> | sorry, I even thought I checked that, whoops |
| 2023-02-11 21:34:13 +0100 | <geekosaur> | that's the size of the root window, not the size of the screen rectangle passed to the layout |
| 2023-02-11 21:34:20 +0100 | <ectospasm> | I guess 1080 could be the width if the screen is in portrait orientation. |
| 2023-02-11 21:34:34 +0100 | <geekosaur> | (note that the layout doesn't get a position. I think) |
| 2023-02-11 21:35:13 +0100 | <geekosaur> | hm, actually it might. but it still wouldn't show in the width, only in the x value |
| 2023-02-11 21:35:46 +0100 | <geekosaur> | which would then have to be compared against all the ScreenDetail rectangles |
| 2023-02-11 21:36:59 +0100 | <ectospasm> | Is the x value the leftmost pixel of the screen? |
| 2023-02-11 21:38:38 +0100 | <geekosaur> | should be, yes |
| 2023-02-11 21:41:46 +0100 | <geekosaur> | okay, yes, the layout is passed the full screen rectangle including its position, so in particular the first/outermost layout receives the screenRect from the ScreenDetail including x value |
| 2023-02-11 21:42:12 +0100 | <geekosaur> | we should really rewrite PerScreen to use that intead of (or in addition to) the ifWidth hack |
| 2023-02-11 21:45:15 +0100 | <vrs> | I have an odd problem - I have XF86AudioMute bound to "amixer set Master toggle", but whenever I do that xmonad goes into a loop of calling it and I have to restart it to regain proper function |
| 2023-02-11 21:45:26 +0100 | <vrs> | xev doesn't see anything out of the ordinary, it's not the keyboard repeating keys |
| 2023-02-11 21:46:04 +0100 | <vrs> | it doesn't happen with anything else, such as XF86AudioMicMute |
| 2023-02-11 21:46:25 +0100 | <vrs> | (which calls amixer set Capture toggle") |
| 2023-02-11 21:47:11 +0100 | <vrs> | when I disable the keybinding nothing happens, so nothing else is grabbing that |
| 2023-02-11 21:48:51 +0100 | <vrs> | why would specifically XF86AudioMute do that to my xmonad? |
| 2023-02-11 21:49:08 +0100 | <geekosaur> | no idea |
| 2023-02-11 21:49:11 +0100 | <geekosaur> | @where paste |
| 2023-02-11 21:49:11 +0100 | <lambdabot> | Help us help you: please paste full code, input and/or output at e.g. https://paste.tomsmeding.com |
| 2023-02-11 21:56:20 +0100 | <vrs> | not sure what I could paste, it's a pretty standard ezconfig as far as that is concerned |
| 2023-02-11 22:07:45 +0100 | <vrs> | it's not deterministic and inserting even a sleep 0.01 seems to make a difference |
| 2023-02-11 22:08:09 +0100 | <liskin> | vrs: can you reproduce that in an empty X session where literally nothing else runs? |
| 2023-02-11 22:08:20 +0100 | <liskin> | Like not even pulseaudio/pipewire |
| 2023-02-11 22:08:49 +0100 | <liskin> | These things synthesise keypresses |
| 2023-02-11 22:09:02 +0100 | <vrs> | do they? |
| 2023-02-11 22:09:32 +0100 | <vrs> | I mean that would explain it |
| 2023-02-11 22:09:32 +0100 | <liskin> | Well I haven't seen them do AudioMute before |
| 2023-02-11 22:09:55 +0100 | <liskin> | But AudioPause in response to headphones disconnect, yeah |
| 2023-02-11 22:17:04 +0100 | <ectospasm> | why are you using amixer if you're using pulseaudio/pipewire? Don't those have CLI utilities to mute sinks, etc.? |
| 2023-02-11 22:17:21 +0100 | <vrs> | do they have toggle? amixer is purely a habit thing |
| 2023-02-11 22:17:55 +0100 | <vrs> | (and because it worked on freebsd I think back when I had a freebsd desktop) |
| 2023-02-11 22:19:52 +0100 | <ectospasm> | Yeah, it might behave better if use say pamixer --toggle-mute, you might need to provide which sink you want to mute. |
| 2023-02-11 22:20:19 +0100 | <ectospasm> | I know nothing of pipewire, but I'd be surprised if it doesn't have a similar mixer command. |
| 2023-02-11 22:20:38 +0100 | <vrs> | anyway the bug goes like this for me: I hit XF86AudioMute a few times, then at some point xmonad starts repeatedly calling the commend at about 20 times per second and my windows stop responding to input. xmonad commands are still accepted and I can recover by hitting either hitting mute at the correct time, or restarting xmonad |
| 2023-02-11 22:21:12 +0100 | <vrs> | after that applications accept input again |
| 2023-02-11 22:21:29 +0100 | <geekosaur> | weird. that sounds like something wrong with event handling |
| 2023-02-11 22:21:40 +0100 | <geekosaur> | hm, what version of xmonad and what version of ghc |
| 2023-02-11 22:21:41 +0100 | <geekosaur> | ? |
| 2023-02-11 22:21:58 +0100 | <vrs> | 0.17.1 + 9.0.2 |
| 2023-02-11 22:22:07 +0100 | <vrs> | (debian testing) |
| 2023-02-11 22:22:48 +0100 | <geekosaur> | mm. I'm still unclear on whether 9.0.2 is affected, but this might be a new manifestation of the join point bug |
| 2023-02-11 22:23:09 +0100 | <geekosaur> | is there a way you can try ghc 9.2.5? or xmonad from git? |
| 2023-02-11 22:24:00 +0100 | <geekosaur> | the join point bug is a ghc code generation error that leads to the memory we allocate for X events becoming corrupted and/or corrupting the heap |
| 2023-02-11 22:24:49 +0100 | <vrs> | hm if so then it's pretty localized because all I'm seeing is odd behavior for audiomute specifically, and no crashes/segfaults |
| 2023-02-11 22:24:51 +0100 | <geekosaur> | supposedly it only affected 9.2.x, except we have some very similar bug reports involving 9.0.x |
| 2023-02-11 22:25:05 +0100 | <geekosaur> | yes, it behaves very oddly and inconsistently |
| 2023-02-11 22:25:49 +0100 | <geekosaur> | I think bgamari had to experiment to find a combination of settings and environment that made it show up and behave reliably |
| 2023-02-11 22:27:20 +0100 | <vrs> | hm. it's not amixer at least, I managed to repro with a version that was just sleep 0.1 |
| 2023-02-11 22:29:44 +0100 | tremon | (~tremon@83-85-213-108.cable.dynamic.v4.ziggo.nl) (Quit: getting boxed in) |
| 2023-02-11 22:30:11 +0100 | <geekosaur> | anyway, 9.2.4 and later have a fix for the bug and xmonad git has a workaround |
| 2023-02-11 22:30:25 +0100 | <vrs> | it could be a hardware bug (keyboard being wonky or so) but then I can't explain why xmonad still processes commands and applications don't |
| 2023-02-11 22:31:28 +0100 | <geekosaur> | xmonad commands follow a different code path in the X server (keyboard grabs) although it'd still be pretty weird |
| 2023-02-11 22:32:07 +0100 | <geekosaur> | although come to think of it, if xmonad is still processing commands then event pointer corruption seems unlikely |
| 2023-02-11 22:39:50 +0100 | <vrs> | hm. since this keyboard generates an XF86WakeUp when I press Fn, I suspected grab weirdness and bound XF86WakeUp to return() |
| 2023-02-11 22:40:08 +0100 | <vrs> | which, as expected, makes XF86WakeUp not show up in xev anymore |
| 2023-02-11 22:44:23 +0100 | <vrs> | now if I do fn-down mute-down fn-up mute-up (note the interleaving), I can reliably reproduce the problem |
| 2023-02-11 22:45:12 +0100 | <vrs> | I had a few cases where XF86WakeUp would end up in xev (outside the grab, even though it should be grabbed) but I can't reproduce that right now |
| 2023-02-11 22:46:46 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2023-02-11 22:48:37 +0100 | <vrs> | okay it is a bug somewhere below xmonad, without the xmonad keybinds I can still get mute to repeat with that sequence |
| 2023-02-11 22:48:50 +0100 | <vrs> | so either X or the keyboard get something wrong here |
| 2023-02-11 22:49:18 +0100 | <vrs> | xmonad afaict just sees a key that it has bound staying pressed, and that's why it keeps the grab |
| 2023-02-11 22:52:02 +0100 | <geekosaur> | with keys like that it's also possible for it to be an ACPI bug (BIOS or, much less likely, Linux) |
| 2023-02-11 22:53:05 +0100 | <vrs> | yeah I suspect that the fn key here is doing something nonstandard (it's already decidedly odd for it to generate XF86WakeUp but that's apparently just a thing with these models) |
| 2023-02-11 23:02:49 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2023-02-11 23:11:07 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2023-02-11 23:15:03 +0100 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |