| 8 Jan 2025 |
 ElvishJerricco | p14: I think that's not true | 21:25:47 |
| ElvishJerricco |
StandardError=
Controls where file descriptor 2 (stderr) of the executed processes is connected to. The available options are identical to those of StandardOutput=, with some exceptions: if set to inherit the file descriptor used for standard output is duplicated for standard error, while fd:name will use a default file descriptor name of "stderr".
| 21:26:02 |
| ElvishJerricco | *
StandardError=
Controls where file descriptor 2 (stderr) of the executed processes is connected to. The available options are identical to those of StandardOutput=, with some exceptions: if set to inherit the file descriptor used for standard output is duplicated for standard error, while fd:name will use a default file descriptor name of "stderr".
| 21:26:11 |
| ElvishJerricco | *
StandardError=
Controls where file descriptor 2 (stderr) of the executed processes is connected to. The available options are identical to those of StandardOutput=, with some exceptions: if set to inherit the file descriptor used for standard output is duplicated for standard error, while fd:name will use a default file descriptor name of "stderr".
| 21:26:24 |
 p14 | Oh, apologies for my mistake; I'm struggling to explain why I'm not getting debug output for bin/gdm in the display manager process. | 21:26:55 |
| p14 | I think I must have hallucinated this incorrect point from somewhere. | 21:27:19 |
| ElvishJerricco | p14: When I set services.xserver.displayManager.gdm.debug and services.xserver.desktopManager.gnome.debug I get debug output | 21:27:25 |
| ElvishJerricco | I am glad those exist because at one point either they didn't or I didn't know about them and getting debug output was proving impossible :P | 21:27:49 |
| p14 | I have those set. I have less debug output than I am expecting. I am experimenting with multi-seat and trying to determine why the second seat hangs immediately during login | 21:27:53 |
| p14 | Unfortunately it also produces no log messages. Maybe because it is hanging so early in the process? | 21:28:11 |
| p14 | I've found a helpful soul who is trying to help me to get it to working but they're claiming I'm missing logs. | 21:28:33 |
| p14 | (Which I'd believe because there are so few of them) | 21:28:38 |
| p14 | I'm sort of beginning to think this second seat's gdm is just not producing logs and I don't understand why | 21:29:41 |
| p14 | Right, there isn't a gdm-per-seat, it's just the one gdm... 🤔 | 21:30:58 |
 Salt | okay, new question about extensions... what is the timeline from merge of backport PR to actually being in nixpkgs? | 22:23:32 |
 Alyssa Ross | couple of days | 22:24:37 |
| Salt | kay, will try to be a bit more patient before checking whether a specific extension is breaking | 22:25:15 |
| Alyssa Ross | (assuming backport to a release branch, not to staging) | 22:25:18 |
| Salt | yeah, it appears to be a release backport | 22:25:51 |
| Salt | * yeah, it appears to be a release backport, merged 2 days ago | 22:27:16 |
| Salt | I just saw this comment while trying to track down a different package's backport state and was wondering it is the general consensus?
I don't think any of the GNOME packagers use stable so you are on your own testing the changes :-)
| 23:45:29 |
