[03:41] robert_ancell: https://forum.snapcraft.io/t/reviews-are-shared-across-snaps-flatpaks-and-apt-packages/13505 <- is this something you can answer? [03:42] (even if the answer is just "this is just how gnome-software works, with reviews attached to upstreams rather than packagings") [03:44] jamesh, it's being done server side. [03:47] robert_ancell: I guess I'm conflating gnome-software and the review server then. It sounds like something that could only be fixed by us either (a) not using the upstream review server, or (b) convincing upstream to not merge reviews for different packagings of an app [03:47] yeah, that's basically it. === ecloud_wfh is now known as ecloud [06:10] good morning [06:39] Morning didrocks [06:43] hey duflu === pstolowski|afk is now known as pstolowski [07:35] morning all 0/ [07:36] Morning clobrano [07:36] hey duflu :) [07:45] hey clobrano :) [07:45] hey didrocks, how are you? [07:46] I'm fine, thanks, and you? [07:50] I'm good as well :), waiting for the summer to end here XD [07:55] here it's grey and rainy, summer is very far… :p [08:02] o/ [08:02] Laney: <3 [08:02] lis!!!! [08:03] hi laney :) [08:05] hey Laney, lis [08:05] good morning didrocks :) [08:06] ahoy didrocks [08:06] how are you both doing?!?!?! [08:06] * lis just back from canada after 2 weeks vacation for thanksgiving [08:06] so, pretty good :) [08:07] how are you? [08:07] I'm good, thanks, yourself? [08:07] YEAHHHHH [08:08] doing pretty alreet [08:08] we won the pub quiz last night 👍 [08:09] how are the crops? must be some interesting stuff around now [08:09] rad! [08:10] Morning Laney and really morning lis [08:11] urgh [08:11] hey duflu [08:11] we tried an experimental variety of corn [08:11] which is blue coloured [08:11] and i'm sorry to report that it tastes NASTY [08:12] just go with a good ol' super sweet variety is my advice [08:13] duflu: it's more morning for laney, i think [08:14] Laney: interesting. next you'll have to try all the different carrots. those actually taste good regardless the colour [08:14] didrocks, it's a bit cloudy now, but with 23 degrees and till yesterday you can go swimming at the beach :D [08:14] not had much success with carrots so far [08:14] hey Laney [08:14] should persevere [08:14] o/ clobrano [08:15] I heard a documentary on the radio recently about all the different kinds of banana there are in the world [08:15] seems like there's an exciting variety that we don't really get to see [08:17] if only we could viably grow them over here [08:18] clobrano: waow :) [08:21] didrock, yeah I know, first world problem XD [08:28] goooood morning desktopers [08:29] hi hi seb seb [08:30] hihihi [08:30] hey willcooke :) [08:30] hey willcooke [08:31] hey lis, how are you? [08:31] jetlagged but happy :) [08:31] lut didrocks, en forme aujourd'hui? [08:31] how have you been? [08:31] ça va, et toi ? [08:31] I'm good [08:31] Morning seb128 and willcooke [08:31] in London today [08:31] hey duflu [08:31] didrocks, ça va :) [08:32] moin seb128 [08:32] lis, where are you? [08:32] hey Laney [08:32] Wimpress, https://bugs.launchpad.net/bugs/1848969 is new, I tagged this one instead of the old one [08:32] Ubuntu bug 1848969 in indicator-datetime (Ubuntu) "src/date-time.cpp:171:GDateTime* unity::indicator::datetime::DateTime::get() const: assertion failed: (m_dt)" [Critical,Confirmed] [08:33] it lacks info but it's likely a bug introduce in the port to the new e-d-s by the look of things [08:33] Laney, ^ fyi, I think you did the code changes, unsure if you would be interested to poke at the segfault (once the bug has more info/a bt probably) [08:35] I mean not really, ideally someone from one of the flavours that uses this component would maintain it [08:35] but... [08:35] if the desktop team wants to decide to own it in this way... [08:36] Morning desktoppers o/ [08:36] hey Wimpress [08:37] Laney, ok, no worry, I was mentioning in case you were interested, I don't think we need to own the issue as you said flavors can poke at it since they are the ones using the comoponent [08:38] I'd be OK reviewing or advising someone but I think it'll be a bad message if we continue maintaining that stuff (IMO anyway) [08:38] would rather have not touched it at in the first place ;-) [08:38] hey Wimpress [08:47] yeah, agreed on not maintaining it, I was a bit unsure about if it was a situation of "we break it, we fix it" [08:48] but that would mean paying for being nice in the first place and fixing it rather than just demoting it and its rdependd to proposed for example [08:49] problem is that ended up being the whole unity desktop [08:49] or work to take that indicator out of it [08:52] probably a bit of a fine line on this one [08:54] bit like how Trevinh_o ends up fixing budgie for new mutter every cycle, we wouldn't want to have to own maintaining that as a result of needing to do this to push the ubuntu desktop on [08:54] except in that case there is an upstream so it sort of works [08:58] right [08:58] good morning desktoppers [08:59] hey oSoMoN , how are you today? [08:59] hey oSoMoN [08:59] hey oSoMoN [09:01] Wimpress, https://trello.com/b/uEut6bfN/ubuntu-desktop-1910-cycle [09:01] that's in the topic ;-) [09:02] * Laney eyes landscape [09:02] hey seb128, Laney, didrocks, willcooke [09:03] seb128, I'm good, but we had heavy rains last night and roads and trains are collapsed, it's a mess out there [09:03] :( [09:03] not your week [09:03] nope… I can't wait for next week, it can only get better [09:05] :( [09:05] * Laney hugs oSoMoN [09:05] * oSoMoN likes hugs [09:07] * didrocks hugs oSoMoN as well [09:08] PILE ON [09:14] * seb128 piles on oSoMoN :) [09:17] duflu, bug #1849135 some of the users state they also get the issue on wayland sessions [09:17] bug 1849135 in xorg-server (Ubuntu) "Clicking Activities in the corner doesn't work in Xorg sessions" [Undecided,Confirmed] https://launchpad.net/bugs/1849135 [09:19] duflu, also I think we can drop the nvidia/disco shell backport task, we are probably not going to do another round of SRU for disco at this point since 19.10 is out [09:20] seb128, I have not yet debugged the first issue so; sure. As for the second issue you read my mind again. I was going to ask to drop it [09:21] I have seen upstream two possible causes for the non-clicking and only one was Xorg-specific [09:21] k [09:21] feel free to wontfix the disco issue if you have the bug number handy [09:27] seb128, I've had a couple of disco fixes awaiting review for some weeks/months mentioned in my reports. I'll change them now [09:27] thx [09:28] Oh, singular now [09:30] seb128, could you please reject it? I don't want to delete it and don't get the option myself https://code.launchpad.net/~vanvugt/ubuntu/+source/mutter/+git/mutter/+merge/372984 [09:32] duflu, done [09:32] Ta [09:32] Weird you can't just close your own proposal [09:34] No idea what the other disco issue was on my mind [09:34] seb128, what shall we do with this? Is it waiting on the science team? https://salsa.debian.org/science-team/fftw3/merge_requests/1 [09:35] Also, good morning oSoMoN [09:36] good afternoon duflu [09:52] duflu, I will give them a few more days to comment and upload to Ubuntu next week if they don't [09:53] Thanks [11:12] clobrano, re the sound theme/system-ready thing, the path used for lookup is $XDG_DATA_DIRS/sounds [11:14] Trevinho: can you please SRUify the mutter bugs you are closing with that upload? [11:17] seb128, thanks. I'm on yaru session now, and $XDG_DATA_DIRS resolves (also) in /usr/share/Yaru, but this folder does not exist [11:17] while /usr/share/ubuntu exists but it's not in XDG [11:19] ^ but `/usr/share/ubuntu` doesn't have a sounds subdir :O [11:19] that's not a sound dir [11:20] right [11:21] oh, nvm, there's also /usr/share which has our sounds [11:21] Laney: yeah, ok... I was waiting for the debian merge/upload in order to proceed with the ubuntu merges though [11:22] but I see they're coming now [11:22] :) [11:22] it's all done babes [11:22] ❤ [11:32] hi, is this the right place to ask about the chromium snap? [11:32] clobrano, ok, poking around you it seems to work in the Yaru location after removing ~/.cache/event-sound-cache* [11:32] ackk, hey, yes you can ask here though it's a dev channel and not an user support forum so depends of the question [11:33] seb128, okay, but it's working now in my system too. I don't know what kind of error I did previously [11:33] btw, the use case was to use a symlink in Yaru source and let meson install everything in the same place [11:33] well it was not working for me when adding the file to Yaru until I removed the cache [11:33] it seems to work now [11:34] I see, but we are not using the Yaru location, everything is installed under `/usr/share/sounds/Yaru/stereo` [11:34] does this make sense? [11:35] that's what I meant for Yaru location [11:35] I created /usr/share/sounds/Yaru/stereo/system-ready.oga [11:35] yeah, I think canberra remembers negative lookups [11:36] ackk, what's the question about the chromium snap? [11:37] Laney, that's a bit unfortunate, it means existing users will not get their system-ready sound work unless we delete that cache for them? [11:37] oSoMoN, hi, I was reading that chromium has experimental support for pipewire since 73, but I don't see the flag under chrome://flags. I was wondering if it's not detecting something because it's in the snap [11:37] oSoMoN, tl;dr I wanted to try screensharing with wayland [11:37] dunno, you'd have to look into the precise details of the cache [11:37] but when is system-ready used apart from in the installer? [11:39] Laney, isn't gdm supposed to be playing that as well once you get to the greeter? [11:39] or is it a different sound? [11:39] Laney, /usr/share/gdm/autostart/LoginWindow/libcanberra-ready-sound.desktop [11:40] dunno [11:40] but I hope that we don't bring back a sound on startup with this change [11:40] ackk, it's currently not built in the snap, but that's certainly something we could play with. Would you mind filing a bug at https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+filebug to track the feature request? [11:40] ^ [11:40] Laney, not on login, but a beep when the greeter is ready, which is needed for blind users to know when they can type their password? [11:41] oSoMoN, sure [11:41] screen reader doesn't say anything in that case? [11:41] I don't know offhand [11:42] well, if it restore that beep and we don't want it then we need to change canberra I guess [11:43] seb128: > that's what I meant for Yaru location > Ok! [11:44] or other option would be to change ubiquity to play installer-ready indeed and add this sound [11:44] if we don't want gdm to play one and not distro patch canberra [11:44] oSoMoN, https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1849478 [11:44] Ubuntu bug 1849478 in chromium-browser (Ubuntu) "(experimental) pipewire support not available" [Undecided,New] [11:44] feel free if you want to check the other flavours [12:09] ackk, thanks [12:09] oSoMoN, ty [13:51] mvo: did you make any progress on the snap validation issue? [14:01] good morning everyone! [14:01] hey hellsworth [14:03] hi didrocks, how are things? [14:03] good morning hellsworth [14:03] hi oSoMoN, hope you are well today :) [14:04] I'm fine, thanks, you? [14:05] yeah ok. kind of tired but excited because this afternoon we're supposed to get lots of snow :D [14:05] like 25cm [14:05] i want to make a snowman if that happens [14:07] nice! :) [14:07] here is only about grey weather :/ [14:07] grey is nice too [14:07] that's tea drinkin weather :) [14:08] heh, indeed :) [14:08] kenvandine: sort of, I noticed that the default provide looks a bit odd now: https://paste.ubuntu.com/p/BJBBRkdcRQ/ - of course our error is terrible [14:08] kenvandine: I suspect changing the default provider to a snap will fix the build issue [14:09] weird... i wonder when that changed [14:11] oh, maybe the move to the snapcraft extension [14:11] mvo: it doesn't affect installation of the snap though [14:14] https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/project_loader/_extensions/gnome_3_28.py#L69 [14:23] kenvandine: yeah, I think we split the ":" for historic reasons [14:23] kenvandine: I think we (snapd) needs a better message at least [14:25] sergiusens: ^^^ [14:26] https://github.com/snapcore/snapcraft/pull/2763 [14:26] sergiusens: snaps built with the extension is breaking iso builds [14:27] oh my that's not good [14:27] hellsworth: good morning! [14:27] kenvandine: darn, that logic was reviewed by 20 or so people, why is it breaking only now? [14:27] Our first seeded snap that transitioned to the extension [14:28] we transitioned to the extension in gnome-calculator master [14:28] when they branched for gnome-3-34 and that landed in stable [14:28] it broke the build [14:28] sergiusens: the snap works fine, but validation fails [14:29] kenvandine: validation from where, if these snaps are in the store too and certainly passed review? [14:29] sergiusens: can we fast track that? [14:29] yeah, snap lets you install them [14:29] for historic reasons [14:30] kenvandine: anyways, mind fixing the kde extension in the same PR [14:30] but the validate-seed command doesn't pass them [14:30] sure [14:30] kenvandine: fastracking is going to make me miss some objectives you know :-) [14:31] kenvandine: can you please create a similar PR for kde please? [14:32] sergiusens: the kde one is confusing me [14:32] is the slot name different? [14:32] kenvandine: how so? Oh, yeah, they have multiple slots providing the same content [14:32] kde-frameworks-5-plug seems to have a slot named kde-frameworks-5-core18-slot for the default provider [14:34] mvo: if i'm reading this, the kde snaps need to be able to specify the slot for the default-provider [14:34] as the slot name doesn't match the plug name [14:36] mvo: plug=kde-frameworks-5-plug has default-provider = kde-frameworks-5-core18:kde-frameworks-5-core18-slot [14:36] kenvandine: thanks, I will have a look at our code then [14:36] so maybe validate-seed just needs to honor it [14:36] kenvandine: that sounds like the validation code doesn't covers this [14:36] or... the kde snaps are doing something bad :) [14:36] kenvandine: indeed, let me have a quick look [14:36] thanks [14:37] kenvandine: well, bad is that it was never documented or enforced, snapd might need to have to live with this now [14:38] yeah, well i'm guessing snapd does the right thing when it's specified [14:38] if it didn't something would have broken [14:38] i'm guessing the validation code just doesn't handle that case [14:38] but we'll let mvo sort that out [14:39] sergiusens: in the gnome case the names match, so it isn't needed [14:40] kenvandine: right, I don't mind removing it, but I would prefer to avoid fast tracking if possible [14:40] yeah, understood [15:01] kenvandine: I will fast track your change. Battery of tests does take 12 hours though [15:01] I can start after the meetings end [15:35] sergiusens: i just submitted a PR for the kde-neon extension [15:36] completely untested :) [15:36] Laney, seb128: we found the problem with the image build [15:37] kenvandine, oh, what is it? [15:37] we need either a fix to snapd or snapcraft to land [15:37] (sorry on a stupid and flaky airport wifi) [15:37] gnome-calculator from the gnome-3-34 branch now uses the gnome-3-28 snapcraft extension [15:37] is there a snapcraft change leading to a bug in the update of those snaps? [15:38] the extension adds a default provider with the slot specified [15:38] default-provider: gtk-common-themes:gtk-3-theme [15:38] for example [15:38] which is documented and snapd actually ignores everything after the : [15:38] so it works [15:39] but validate-seed fails it [15:39] didrocks, I would welcome your input on bug #1849512 , I guess that's rather a bug in the 'backend' (adduser?) than in g-c-c if a bug at all [15:39] bug 1849512 in gnome-control-center (Ubuntu) "Creating a new user on top of ZFS filesystem does not create a new dataset for his home directory" [Undecided,New] https://launchpad.net/bugs/1849512 [15:39] kenvandine, oh ok [15:39] seb128: i've submitted a PR to snapcraft to fix that [15:39] but will take time [15:39] i think mvo is working on fixing the validation code [15:40] nice one [15:40] so it doesn't fail the case [15:40] how is snapcraft spposed to fix it? [15:40] just not append the slot [15:40] looks like a bug in the validation code in any case no? [15:40] yeah, once I'm no longer in meetings I can start fixing this :) [15:40] snapd actually only uses the snap name [15:40] it discards the slot if it's specified [15:41] but it is better if the extension doesn't specify it, since it isn't used [15:41] but yeah, the real fix should be in the validation code [15:41] it should behave the same everywhere [15:42] seb128: this issue is due to the user not having zsys installed [15:42] as we can't do anything magic without the magic having it :p [15:42] and as it's not seeded by default… [15:43] kenvandine, thx for the status update! [15:43] didrocks, I see, going to fix next cycle once zsys is promoted :) [15:43] thx [15:44] seb128: yeah, the issue is people who did create users before this will never have the dataset created [15:44] let's see how many bug reports we'll close (it's already the 3rd report on this…) [15:45] :( [15:45] but yeah, not much we can do at this point [15:45] indeed [15:46] well, this was known and mentioned before the decision was taken, so, I can only comment on the bug for now [15:46] (done btw) [15:46] thx [16:14] Wimpress, popey, do we have a policy about deleting post like that https://discourse.ubuntu.com/t/call-for-testing-chromium-browser-deb-to-snap-transition/11179/165 ? It's just annoying to see those in middle of productive discussions... (sorry, on a flacky wifi pre-boarding my flight so I'm probably not going to stick around long) [16:16] hellsworth: got a few minutes to see a common issue we run into and how to fix it? [16:16] * kenvandine just hit a relatively common scenario [16:20] yes [16:20] meet.google? [16:20] nah [16:20] oh ok [16:21] gnome-nibbles just changed handling of some help files [16:21] we'll talk in query === pstolowski is now known as pstolowski|afk [16:48] kenvandine: Is anyone looking into (maybe with the help of snappy people, if it's as confusing to you as it is to me) why the desktop livefs suddenly fails to build? [16:48] I can't fathom how it worked on the 21st and has failed since. [16:48] Unless a snap was updated and is actually broken. [16:49] Oh, gnome-calculator.snap was updated. That might be the problem. [16:49] infinity: Read about 1 hour ago in here (yes) [16:49] Laney: Ah-ha. Thanks. I'll go back to not caring, then. [16:59] infinity: yeah :) [17:29] kenvandine: your validate PR needs a look [17:34] sergiusens: thanks [18:12] sergiusens: fixed