sphalerite changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 19.09 now in beta! https://discourse.nixos.org/t/nixos-19-09-feature-freeze/3707 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 19.09 RMs: disasm, sphalerite | https://logs.nix.samueldr.com/nixos-dev
Cale has joined #nixos-dev
ris has quit [Ping timeout: 276 seconds]
clever_ has joined #nixos-dev
clever_ has quit [Changing host]
clever_ is now known as clever
drakonis has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
thonkpod has quit [Quit: WeeChat 2.4]
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
jonringer has joined #nixos-dev
jonringer has quit [Quit: Leaving.]
jonringer has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis has quit [Ping timeout: 276 seconds]
evanjs- has joined #nixos-dev
qyliss has quit [Quit: rebooting]
qyliss has joined #nixos-dev
das_j has quit [Remote host closed the connection]
das_j has joined #nixos-dev
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 268 seconds]
drakonis_ has quit [Ping timeout: 268 seconds]
drakonis_ has joined #nixos-dev
drakonis has joined #nixos-dev
evanjs- has quit [Quit: ZNC 1.7.4 - https://znc.in]
drakonis has quit [Ping timeout: 246 seconds]
drakonis has joined #nixos-dev
drakonis has quit [Read error: Connection reset by peer]
drakonis has joined #nixos-dev
drakonis1 has joined #nixos-dev
drakonis_ has quit [Read error: Connection reset by peer]
drakonis has quit [Ping timeout: 245 seconds]
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
ivan has quit [Remote host closed the connection]
ivan has joined #nixos-dev
Jackneill has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
teehemkay has quit [Excess Flood]
teehemkay has joined #nixos-dev
orivej has joined #nixos-dev
Jackneill has joined #nixos-dev
__monty__ has joined #nixos-dev
ris has joined #nixos-dev
jonringer has quit [Ping timeout: 276 seconds]
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined #nixos-dev
orivej has quit [Ping timeout: 265 seconds]
avn has quit [Remote host closed the connection]
orivej has joined #nixos-dev
drakonis1 has quit [Ping timeout: 265 seconds]
drakonis1 has joined #nixos-dev
drakonis1 has quit [Ping timeout: 276 seconds]
drakonis has joined #nixos-dev
jonringer has joined #nixos-dev
jtojnar has quit [Read error: Connection reset by peer]
<niksnut> ouch, my system closure size went from 5.3 GB in 19.03 to 6.4 GB in 19.09
<arianvp_> Ouch
<niksnut> anybody experience the mouse pointer being unusably slow in 19.09?
<ivan> niksnut: yeah, we switched to libinput by default
<ivan> services.xserver.libinput.enable = false; to restore sanity
<ivan> I saw that on my Logitech G9 which should have been moving much faster
<niksnut> yeah, I have a G502
<niksnut> I'll try that
<niksnut> or should there be some udev rules to configure the mouse?
<niksnut> I notice 'xinput set-prop 8 300 4' (to change acceleration) fails with 'integer parameter out of range for operation'
<niksnut> so I can't set the acceleration higher than 1
<ivan> libinput is one of those software with incredibly detailed rationale about why it is better than {libev, synaptics} but is hampered by author testing it on his laptop and 'works on my machine'
<emily> you can just tweak the acceleration factor or whatever
<emily> libinput works fine for me and many other people, it's the default in multiple distros...
<niksnut> ivan: thanks, disabling it worked
<niksnut> emily: how do you tweak the acceleration factor?
<niksnut> even at the highest acceleration settable in plasma it was still unusable
<emily> take a look at services.xserver.libinput.accel{Profile,Speed}
<emily> maybe you want a different profile rather than/in addition to speed
<niksnut> well, ideally a mouse would just work...
<niksnut> yeah it looks like libinput's udev rules are not used
<emily> nixos having udev bugs is usually a fair bet...
<niksnut> I'll try adding them and see if that fixes it properly
evanjs has quit [Quit: ZNC 1.7.4 - https://znc.in]
drakonis has quit [Ping timeout: 245 seconds]
evanjs has joined #nixos-dev
<niksnut> that didn't help
drakonis has joined #nixos-dev
<niksnut> I'm guessing somehow the systemd hwdb (which has the dpi info) doesn't get used: https://github.com/systemd/systemd/blob/master/hwdb/70-mouse.hwdb#L370-L372
<niksnut> or maybe not, "udevadm info /dev/input/event0" shows MOUSE_DPI though "udevadm info /dev/input/mouse0" doesn't
<niksnut> so it looks like the logitech g502 has a dpi/frequency setting stored inside the mouse, and mine was set to 400 dpi or so
<disasm> globin: +1 to failing builds with removed options
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 276 seconds]
__monty__ has quit [Quit: leaving]
<worldofpeace> Lol, I changed plasma5's default to use libinput to make touchpads not be terrible. interesting this happens for mice.
<worldofpeace> what udev rules are we missing in the module?
<niksnut> none
<niksnut> it's only an issue with crazy configurable gaming mice
<samueldr> has there been a writeup of the talk yet? (or are the slides complete enough?)
<samueldr> thank, though I was hoping for something like one of lennart's usually good blog posts :)
<samueldr> (I'm not good with listening to talks generally)
<samueldr> niksnut: about #69272, do you know if #44047 (if you already are somewhat familiar with it) would have caused similar bloating?
<{^_^}> https://github.com/NixOS/nixpkgs/issues/69272 (by edolstra, 32 minutes ago, open): Qt wrapper causes closure bloat
<{^_^}> https://github.com/NixOS/nixpkgs/pull/44047 (by samueldr, 1 year ago, closed): Loads qt plugin paths as registered...
<niksnut> how does it decide which paths to add?
<samueldr> let me review what I proposed, it's been a while
<samueldr> I think it was that, at build time, any [propagated]BuildInput having the qt plugin path prefix would be added to the registered qt plugin paths
drakonis has joined #nixos-dev
<samueldr> (I still had some unanswered questions)
<niksnut> QT_PLUGIN_PATH is less of an issue because lib/qt-*/plugins is unlikely to exist in a build-time-only dependency
<niksnut> but /share is not very discriminating for XDG_DATA_DIRS
<samueldr> oh, I hadn't realised that hook also managed XDG_DATA_DIRS
<samueldr> then I figure the answer is "it wouldn't have bloated as much, but also wouldn't have the same results as it lacked XDG_*_DIRS support" or something like that
<niksnut> it's also a bit of an issue that it leaks into user shells (e.g. in konsole)
<samueldr> I am really not fond of all wrappers due to environmental contamination
<niksnut> yeah
drakonis_ has quit [Ping timeout: 246 seconds]
<niksnut> we need something like RPATH
<samueldr> what would be nice is environment variable isolation per store path, so that launching a konsole could add what is needed, but anything launching that is not in that path wouldn't have them... but that's a pipe dream; and I wouldn't dare imagine how to implement that sanely
<samueldr> (and also breaks so many rules)
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 246 seconds]
<niksnut> RPATH-like would mean: add an XDG_DATA_DIRS field to the ELF dynamic section (just like RPATH) and patch qt/gtk to read it
<niksnut> then a program like konsole can have its own XDG_DATA_DIRS without it being inherited by child processes
<samueldr> that sounds like an interesting idea
<samueldr> though how would it fare in situations where it's ran under something like a scripting language
<samueldr> e.g. packaging an app written in python, that uses Qt, and relies on QT_PLUGIN_PATH being set right
<niksnut> there you'd need to automatically (but in a language-specific way) patch the script to call some function to set the search path
<samueldr> if the library (e.g. Qt) relies on a well-known store path holding the data, the runtime (e.g. python, lua, ruby) doesn't have to know about it
<samueldr> though it's maybe less generic, as you can't override any environment variable, only pre-determined ones
<niksnut> it could look for a path relative to the store path containing the executable, like /nix-support/qt-plugin-path
ris has quit [Ping timeout: 265 seconds]
<samueldr> sorry if this sounds a bit presumptuous(?), but "like this?" https://github.com/NixOS/nixpkgs/pull/44047/files#diff-0d4fd569da3fdaee275ea9d30230b6ffR114
<niksnut> heh, yes exactly :-D
<samueldr> I wasn't sure if you were referencing the PR
<niksnut> no
<niksnut> might be worth generalizing
<niksnut> to XDG_DATA_DIRS etc
<samueldr> then this at least answers an open question: the approach was right
<niksnut> yeah