| 22 Aug 2024 |
 Jan Tojnar | mica: I am not sure it is possible but you should be able to mark some other calendar as default and then disable the local one | 07:03:27 |
| Jan Tojnar | * mica: I am not sure removing is possible but you should be able to mark some other calendar as default and then disable the local one | 07:03:55 |
|  Artur Manuel joined the room. | 13:04:50 |
| Artur Manuel changed their profile picture. | 14:53:03 |
 @paperdigits:matrix.org | @Jan Tojnar thanks
| 15:39:35 |
| @paperdigits:matrix.org | I already do that, but wanted to remove the local calendar completely. I've asked in the gnome forum :D | 17:05:41 |
| 27 Aug 2024 |
|  @aloisw:kde.org left the room. | 17:20:47 |
| 29 Aug 2024 |
|  moved to @amadaluzia:tchncs.de joined the room. | 05:48:08 |
|  Florens joined the room. | 12:24:47 |
 edgar.vincent | mica: Funny, I was just wondering about the exact same thing. Do keep us posted if you find the answer.
| 14:52:41 |
| @paperdigits:matrix.org | No answer so far... Don't think I'll get one. | 14:56:19 |
| 30 Aug 2024 |
| moved to @amadaluzia:tchncs.de changed their display name from Artur Manuel (old email was lost, migrating) to (lambda (u) (format nil "~A lost their email!" u)) "Artur Manuel". | 03:53:16 |
| 3 Sep 2024 |
 K900 | Question: what do y'all think about defaulting GNOME (and possibly the other GNOME-likes) to Pipewire for audio in 24.11? | 11:17:31 |
| K900 | I assumed GNOME didn't enable any sound server by default because that's what we do for Plasma | 11:19:29 |
| K900 | But turns out it enables Pulse by default | 11:19:37 |
| K900 | And we should probably figure out some way to be consistent on that | 11:19:53 |
 Honnip | it also enables Pipewire as gnome-remote-desktop requires it 😅 | 11:53:01 |
| K900 | Yes, but only for video | 12:01:35 |
 @blitz:chat.x86.lol | Are there still issues with pipewire? I'm using this for quite some time without issues | 14:18:28 |
| K900 | I haven't seen any particularly bad reports | 14:20:36 |
| Jan Tojnar | In reply to @k900:0upti.me
Question: what do y'all think about defaulting GNOME (and possibly the other GNOME-likes) to Pipewire for audio in 24.11? sounds good, I think we had plans for that as far back as when worldofpeace was still contributing but there were always other priorities | 15:40:20 |
 ElvishJerricco | In reply to @blitz:chat.x86.lol
Are there still issues with pipewire? I'm using this for quite some time without issues For some reason my microphone ends up sounding extremely bad if I enable pipewire. I have spent exactly zero time investigating this | 19:47:51 |
| @blitz:chat.x86.lol | In reply to @elvishjerricco:matrix.org
For some reason my microphone ends up sounding extremely bad if I enable pipewire. I have spent exactly zero time investigating this Bluetooth? | 20:06:33 |
| ElvishJerricco | blitz: I was not using bluetooth, no | 20:21:20 |
| ElvishJerricco | USB mic and motherboard analog audio out | 20:21:53 |
| @blitz:chat.x86.lol | Ah that sucks | 20:54:19 |
| 4 Sep 2024 |
|  Philip Taron (UTC-8) joined the room. | 21:38:14 |
|  emily joined the room. | 21:41:50 |
| ElvishJerricco | Jan Tojnar: Ok, we've made a lot of progress understanding this bug. Here's the short version. It's not specific to systemd-initrd, and it's not specific to plymouth. Those things just seem to make a race condition more likely to trigger the problem.
The problem is simply that there is no reason that GDM wouldn't put GNOME on tty1. The only thing that would prevent it would be getty@tty1.service starting earlier than GNOME, but in the auto-login case that's a race condition. So the result is that when getty@tty1.service does start, GNOME crashes. And it gets worse. Because we still have multi-user.target: Wants=network-online.target, and because getty@.service has Type=idle, that means that you get this issue, where logging in within 5 seconds while networking is still connecting results in the same crash.
| 21:43:00 |
| ElvishJerricco | So, I think the solution is to build GDM with -Dinitial-vt=1. We don't do this now because switch-to-configuration is rather clumsy in how it starts new units. So it sees that getty@tty1.service isn't started and includes it in the list of things to start. Then GDM's display-manger.service: Conflicts=getty@tty${initialVT}.service results in display-manager.service getting killed.
But we think we can fix this by being smarter about starting new units. If switch-to-configuration's start logic is changed to simply doing systemctl start default.target, it will correctly consider the Conflicts= directive, and the unit with the directive will win, meaning getty@tty1.service won't be started and display-manager.service won't be stopped.
| 21:45:24 |
