| 11 Oct 2024 |
 K900 | Maybe we should just stick a passthru.rulesPath or passthru.supportsRules on the udev package then | 15:56:56 |
 Alyssa Ross | hmm | 15:57:07 |
| Alyssa Ross | I guess we can cross that bridge if we come to it | 15:57:19 |
| Alyssa Ross | I added a comment. It's difficult to fully explain this succintly but hopefully it's good enough. | 15:57:54 |
| K900 | Also something is telling me most things will just hardcode $prefix/lib/udev anyway | 15:58:01 |
| Alyssa Ross | unfortunately not | 15:58:10 |
| K900 | Or $prefix/etc/udev | 15:58:14 |
| Alyssa Ross | IME | 15:58:16 |
| Alyssa Ross | but they do often provide an option, and only check for udev.pc if the option is not provided | 15:58:31 |
| Alyssa Ross | and in lots of cases we're already setting that option, so there's nothing to do | 15:59:01 |
| Alyssa Ross | systemd.pc / libsystemd.pc is the same distinction btw | 15:59:27 |
| Alyssa Ross | renaming the udev attribute to libudev for consistentcy might also make things mildly less confusing | 16:01:17 |
| 12 Oct 2024 |
| Alyssa Ross | Jan Tojnarcould I get your review on https://github.com/NixOS/nixpkgs/pull/347803? I'm waiting to merge them all at once since they all rebuild basically the same stuff
| 13:41:57 |
| 14 Oct 2024 |
 vcunat | bobby285271: the gnome branch is good enough for the upcoming staging-next iteration, right? | 09:52:55 |
| vcunat | (along with other staging stuff) | 09:53:07 |
| vcunat | * (along with other staging stuff, so there will be time to fix stuff before it hits master) | 09:53:23 |
| vcunat | * (along with other staging stuff, so there will be more than a week to fix stuff before it hits master) | 09:53:35 |
 bobby285271 | The PR is "in good state" for me, personally. 🤷 I am aware Jan reviewing the branch so I guess I will wait for their feedbacks. | 13:30:02 |
| vcunat | OK, but I wouldn't wait beyond the point when we start the staging-next. Or at least not long beyond. I guess I'd simply merge it myself when starting. | 13:52:07 |
 Jan Tojnar | I managed to go through the downstream diffs and everything looked great, Bobby did a perfect job. | 22:21:22 |
| Jan Tojnar | Sorry I have not been of much help, only gotten around to testing and reviewing again yesterday. I skimmed through about 20% of the upstream diffs and briefly tested it in a VM but probably won't be able to continue until the weekend. | 22:21:47 |
| Jan Tojnar | Will try to test it on my PC during the week but I am okay with merging it as is. | 22:22:54 |
 Jeff | FYI I've tried the gnome branch on a couple of systems now and it seems to be working well. I had to disable a couple of packages but those build failures don't seem to be directly related to Gnome. | 22:59:17 |
| 15 Oct 2024 |
 fabianhjr | I have also been running the gnome branch and haven't noticed any issues | 02:06:45 |
| fabianhjr | * I have also been running the gnome branch and haven't noticed any issues (other than plugins that don't yet support gnome 47 unu) | 02:07:08 |
 Leonardo Santiago | hello guys | 13:20:13 |
| Leonardo Santiago | I have a double monitor setup, one that is 21x9 and the other a 4K tv | 13:21:25 |
| Leonardo Santiago | I wanted to use the 4K tv with 200% scale (otherwise everything looks so tiny I can't even read) but if I do that, the monitor also get 200% scale | 13:22:16 |
| Leonardo Santiago | I read online that per-monitor scaling is gated behind the "scale-monitor-framebuffer" experimental feature | 13:22:57 |
| Leonardo Santiago | I tried setting it using home-manager dconf module but it seems to not have any effect, does anyone know what is going on? | 13:23:20 |
