[09:05] ok I need to asks snapd gurus ; is there a way to force snapd to recalculate / reapply policies after a "snap connect" ? [09:06] seb128, ah just in time [09:06] seb128, hello [09:07] seb128, made a little of progress: "snap connect firefox_XXX:audio-record" also breaks, until I reboot, then it's still listed in connections and "snap run --shell firefox_XXX" works [09:07] I can't find a way to force policy application or something like that [09:10] lissyx, hey, you should try asking about that on #snappy , I'm not understand snapd enough to be of real use there [09:10] but I see you added the details to the bug, I can at least try to nag people to review it [09:14] you wrote firefox_XXX , are you using parallel installs? [09:16] yes I am [09:16] that's the only way to perform mozregression without breaking user's firefox [09:17] and https://snapcraft.io/docs/parallel-installs does not show anything bad? [09:18] ok so a snap refresh --amend and my connections are OK ? [09:21] no it's not :( [09:22] :-( [09:24] weird [09:24] "snap refresh --amend" works when I do it from my shell [09:24] but not from within the python code :( [09:25] weird indeed [09:25] but those commands/steps you listed in the bug, you do them from a shell or from a python script? [09:26] from the python script [09:26] except https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/2043993/comments/2 [09:26] -ubottu:#ubuntu-desktop- Launchpad bug 2043993 in snapd (Ubuntu) "snapd reports connections established but running does not work due to missing connection" [Undecided, New] [09:30] it's not specific to the python env then :/ [09:35] no it's not [09:41] seb128, but subprocess.run(check=True) on the snap refresh and it looks to make it [09:41] I still need to triple check once more [09:47] looks to be OKayish now [09:47] it's still super weird [09:47] indeed :/ [09:49] worth investigating but at least I can get mozregression to work [09:49] just have to polish a bit the bisection result and we are good [12:51] hello desktopers! :) [12:52] Hi seb128! Is there a plan for the localization matters in the installer? [12:52] https://github.com/canonical/ubuntu-desktop-installer/issues/2324#issuecomment-1819061133 [12:52] -ubottu:#ubuntu-desktop- Issue 2324 in canonical/ubuntu-desktop-installer "Languages list doesn't include English variants" [Open] [12:53] ricotz, GunnarHj, hey [12:53] GunnarHj, no plan no [12:59] seb128: Isn't it a bid odd to handle that stuff via bugs only? I'm thinking of selecting the desired English option, handling of regional formats, and — of course — localization of "Try Ubuntu". [12:59] Or is the thought to leave the locale setting to post installation? If so, shouldn't gnome-initial-setup be reconsidered? [13:03] good morning [13:03] GunnarHj, I don't understand what you mean 'by bug only'? [13:04] GunnarHj, the installer let you select a locale/keyboard/timezone, why would we need gnome-initial-setup to ask those questions again? [13:05] seb128: I mean that if there is no plan, users will experience functional regressions compared to Ubiquity and submit bugs. [13:06] GunnarHj, plan for what? [13:06] we have a working installer, it's not perfect as any software, when we have bugs reported we work on them with the resouces we have [13:07] not having english variants listed in only a bug that needs to be fixed [13:08] it's quite minor for users it seems, we only got one report since lunar [13:10] seb128: keyboard/timezone is ok, but locale is very compared to Ubiquity. Not saying it can't work, but in that case we tell users that the "guesswork" done by Ubiquity is gone, and that they need to fine tune their locale post installation in Settings. [13:11] s/very compared/very simplistic compared/ [13:29] GunnarHj, well, we are using subiquity as a backend so basically it's the same behaviour than a server install would have. If that's wrong we should improve/fix subiquity [13:29] as I said, only one user complained in 2 cycles so it seems most people don't see a problem though [13:35] GunnarHj, if we add the english variants to the languages list, is that enough to fix the issue in your opinion? [13:43] seb128: What I primarily would miss in that case is the (not-so-uncommon) case where people want English as the display language but something else as regional formats. [13:43] If I pick English as language, but Swedish/Sweden as keyboard/tz, I end up with only English locales. To fix Swedish regional formats, I need to: [13:43] - Go to Settings [13:43] - Proceed to "Mangage Installed Languages" [13:43] - Install Swedish. [13:43] Only after that I'm able to change the regional formats to Swedish. [13:45] GunnarHj, it's somehow guess work though right? [13:45] like before the installer was assuming that because I'm in a timezone I want the format corresponding to it [13:45] but that's often not try [13:46] not true [13:47] but agreed that we should at least include the english variants in the language list to start [13:48] seb128: Yes, it's guesswork. But given the low frequency of related bugs in the past few years, that approach seems to have worked most of the time. [13:48] well, as said we got no report about the new installer behaviour in lunar/mantic [13:49] so according to that metric the new installer isn't more confusing that the old one... [13:49] than [13:50] seb128: Installing locales-all would make my example less cumbersome. But that would probably come with disadvantages. [14:07] seb128: Anyway, dropping the guesswork with respect to regional formats may be worth a try. But in that case it's important IMO that it's presented as a delibarate design choice and not as an omission. [14:51] seb128, hi :), there is a thunderbird 115.5.0 build1 package for sponsoring at https://people.ubuntu.com/~ricotz/thunderbird/ === Guest1721 is now known as ogra === cpaelzer_ is now known as cpaelzer [15:38] ricotz, thanks, uploaded now! [17:49] mozjs signed tags 94e8aa6 Jeremy Bicha upstream/115.5.0 * Upstream version 115.5.0 * https://deb.li/3MiJi [17:49] mozjs upstream/115 7633361 Jeremy Bícha config/milestone.txt js/src/vm/JSContext.cpp * New upstream version 115.5.0 * https://deb.li/IiNv [17:49] mozjs pristine-tar 4a9e5ab Jeremy Bícha mozjs115_115.5.0.orig.tar.xz.delta mozjs115_115.5.0.orig.tar.xz.id * pristine-tar data for mozjs115_115.5.0.orig.tar.xz * https://deb.li/3eSEn [18:40] seb128, thx [18:40] ricotz, thank to you for working on the update! [18:41] seb128, just a changelog change for the other series [18:52] ricotz, there are no security fixes though so unsure we want to push to the other series? [18:53] seb128, there are a bunch of fixes https://www.mozilla.org/en-US/security/advisories/mfsa2023-50/ [18:53] https://www.mozilla.org/en-US/security/advisories/mfsa2023-52/ [19:28] seb128, ? [19:58] ricotz, I don't understand how Mozilla is working :-/ [19:59] seb128, why did you assume that there are no security fixes? [19:59] ricotz, because the email they sent yesterdau to a private list which includes distributors stated 'At present, no Thunderbird specific advisories for this release.' [20:00] maybe that was meant for the 115.4.3 release? [20:00] no, the subject includes 115.5.0 as version [20:00] ok [20:01] I guess things changed between yesterday and today [20:01] the process is just confusing to me :) [20:01] thanks for pointing it out! [20:01] I am just taking https://www.mozilla.org/en-US/security/advisories/ for granted ;) [20:05] right :) [20:41] libgnome-games-support Jeremy Bicha 442684 * commented merge request !2 * https://deb.li/3XG57