[01:23] Good morning [01:32] Hi callmepk [01:34] hi callmepk, duflu [01:34] Morning jamesh [01:39] Monring duflu, jamesh [01:39] *Morning [01:39] RAOF, this will be handy: https://gitlab.freedesktop.org/mesa/mesa/-/commit/fa5e800e05 [01:41] It's been so long coming. I really shouldn't be excited about it [01:42] Hi duflu o/ [01:42] Hi Wimpress [01:42] Bit late? [01:42] jamesh: o/ [01:43] Heh. [01:43] hi Wimpress [01:43] Yeah, I have war stories about Z390 motherboards, memory timings and nvidia drivers in Ubuntu [01:44] Also, duflu, thanks for digging into Plymouth. [01:44] Wimpress, no worries. I am still affected by a couple more bugs in there I hope to fix [01:44] on various machines [01:45] The spinner theme is working brilliantly across a range of devices I have with different IGPs and GPUs. [01:45] Well, hopefully many machines but not enough of my machines yet [01:45] If there are bugs still, I can't obviously see them them. [01:46] Also, jamesh, apologies in advance. I won't be making the snapd code review call later. [01:46] It's nearly 3am here. [01:46] Wimpress: no problem. [01:47] Sleep required before resuming the beta sprint and then the Snapcraft Summit which is PDT timezone. [01:47] virtual summits are hard when you're in the wrong time zone :( [01:47] Indeed. [01:48] Also, really appreciate your diligence on Firefox and snap integration. [01:49] Wimpress: btw, the xdg-open improvements should be making their way into snapd 2.44.2. This will make existing snaps that call /usr/bin/xdg-open talk to xdg-desktop-portal if it is available [01:50] so no more ugly zenity dialog when opening local files [02:06] jamesh: wooo! that is awesome! [02:06] jamesh: That's wonderful news. [02:07] amurray: Hello there 🙂 [02:07] hey Wimpress :) [02:07] Wimpress: burning the midnight oil? [02:07] * Wimpress considers sleepless nights to chat with all the interesting people down under 🙂 [02:08] Yeah, burning the 3am oil. [02:08] It's that kind of week. [02:10] * amurray will have to try and be boring enough to convince Wimpress to go to bed :) [02:13] But nvidia drivers are broken and that an interesting problem to solve 🙂 [03:36] Wimpress! [03:36] why are you up this late [03:37] jamesh: FYI there's a snapd snap published which contains the browser-support PR and your portalinfo PR [03:38] it's published on latest/candidate/mar-2020-snapcraft-summit [03:38] works quite nicely [03:38] great [06:02] good morning desktoppers [06:02] morning oSoMoN [06:02] hey jamesh, how are you? [06:03] good. [06:03] bringing my ancient snapd dbus-activation branch back up to date now that the user-daemons branch is pretty much done [06:09] good that things are moving forward on this front [06:14] hi all [06:17] goood morning desktopers! [06:22] Morning seb128, oSoMoN, jibel [06:23] hey duflu, lut oSoMoN, jibel, how are you? [06:23] OK. How are you seb128? [06:24] duflu, I'm good thanks! [06:29] seb128, doing alright. Thanks. [06:31] duflu, do you have any idea why #Restart=on-failure is commented in the bluez bluetooth.service? would it be a good idea to enable it? [06:36] seb128, no. I was wondering why it didn't restart actually [06:37] Probably a good idea to enable it [06:37] duflu, k, I will do that [06:37] duflu, also did you see that I commented on the apport not triggering issue? [06:38] Bluetooth? Yes [06:38] seb128, I wonder if LimitCORE=infinity would override protection without having to remove it [06:39] "it" meaning ProtectSystem=full [06:39] duflu, I will test, but probably more a problem on the apport side to fix? [06:39] I have no idea about apport [06:40] good morning [06:40] Morning didrocks [06:40] ProtectSystem makes /usr /boot /etc read only from the manpage [06:41] lut didrocks, comment ça va ? [06:42] seb128, so it shouldn't break core dumps(?) [06:42] duflu, unless the apport job is triggered from the same env and tries to write into one of the locations? I will check that [06:44] salut jibel, seb128, didrocks [06:44] hey duflu [06:45] good morning duflu, seb128, oSoMoN [06:45] ça va :) et vous ? [06:46] ça va bien! [06:49] la forme! [07:50] morning oSoMoN jamesh jibel seb128 duflu didrocks [07:50] Hi marcustomlinson [07:51] good morning marcustomlinson [07:52] morning marcustomlinson [08:03] moin! [08:03] Hi Laney [08:08] hey Laney [08:08] hey Laney, jamesh, marcustomlinson, how are you today? [08:09] yo Laney [08:09] doing ok thanks seb128 [08:09] you? [08:09] I'm good thx [08:09] good morning marcustomlinson, Laney [08:12] good morning marcustomlinson [08:24] hey duflu didrocks seb128 marcustomlinson oSoMoN [08:27] Urgh. If the first step of any “GNOME Shell is being silly” bug is to disable extensions, why do we allow extensions to be enabled *at all*? [08:31] RAOF, yeah I kind of want to block bug reports automatically on that. But I was being easier on you than on most [08:33] duflu: no, I mean if it's *that* buggy isn't it a disservice to our users to allow them to load extensions *at all*? [08:33] RAOF: I have thought about that but imagine the complaints... probably worse than the bug reports [08:34] (The bug is also not NVIDIA related, because it happens on both my desktop and my ATI/Intel laptop) [08:35] duflu: is there a way we could make loading extensions an obviously-dangerous act? [08:35] Alternatively, is there a way we could go back to a sensible architecture, like Unity 8? 😜 [08:36] Well people won't miss what they never had [08:36] That is in a system without extensions [08:37] * RAOF would also accept “sensible” architectures like compiz-unity 😀 [08:37] RAOF: Actually most of my requests were not extension-related in your bug so sorry if the numbering implies a required ordering [08:38] I also have a gperfmon trace for you on the memory-usage bug, once I've uploaded it. [08:38] Both of those will wait for tomorrow. [09:08] mutter ubuntu/master Daniel van Vugt * [open] merge request !59: changelog: Remove a spurious line that should have been deleted * https://deb.li/AOWU [09:09] mutter ubuntu/master Iain Lane * [merge] merge request !59: changelog: Remove a spurious line that should have been deleted * https://deb.li/AOWU [09:15] gnome-shell-extensions pristine-tar 7ea702c Simon McVittie gnome-shell-extensions_3.36.1.orig.tar.xz.delta gnome-shell-extensions_3.36.1.orig.tar.xz.id * pristine-tar data for gnome-shell-extensions_3.36.1.orig.tar.xz * https://deb.li/ilJYM [09:15] gnome-shell-extensions tags a215b75 Simon McVittie upstream/3.36.1 * Upstream version 3.36.1 * https://deb.li/22n [09:17] Why, hello there `gnome-software --gapplication-service`. Good of you to be using 1.3GB RSS while not actually being used! [09:19] gnome-shell ubuntu/master Daniel van Vugt * [open] merge request !38: Keep the Ubuntu logo bright (LP: #1867133) * https://deb.li/KBHi [09:19] Launchpad bug 1867133 in gnome-shell (Ubuntu) "Ubuntu logo vanishes and fades back in (with a slightly different size) on gdm start" [Low,In progress] https://launchpad.net/bugs/1867133 [09:26] Huh, the bots are communicating [09:35] didrocks: duflu: so, ubuntu-logo theme never showed Ctrl+C fsckd message correctly (buggy logic that eats it), the new spinner theme does show it correctly, and I am now suspecting that we flicker that message on every boot now, even though there are no fscks to run; as if systemd-fsckd pushes that message out first, then starts fscks, realiases no fscks are needed, and that it. Now the question is [09:35] if systemd-fsckd should like push the ctrl+c message after a delay (i.e. 1s after starting fscks), and abort pushing it out, if all fscks have completed by then. [09:36] or if the theme should be "smart" enough to hold up the ctrl+c message, until after there are fsckd progress. [09:36] xnox: I was guessing myself. It's not in the spec [09:36] xnox: are you sure about the never showed Ctrl+C? I tested everything at the implementation time. Maybe a later merge from someone broke it rather :p [09:37] on the order, that’s interesting, let me check [09:37] (finishing some iso testing first) [09:37] xnox: If it makes it easier for you I can change the behaviour of 104.patch to better match the existing stuff. Just specify how [09:38] didrocks: right, i'm looking at current focal state, so can't tell when the regression happened. I think the logic is correct under "fake messages" debug labels =) [09:38] didrocks: let me try a few different themes again. [09:40] duflu: i think in the old "fsck" (mountall/upstart) messages the theme did stuff like "store these messages, and flash them only when progress received, like an actual percentage" with lots of comments like "TODO move all of this logic to mountall, we just show what it tells us, without doing all of this scripting logic" [09:41] duflu: i guess in the future, where it is a mode, we would switch to the new mode, only when fscks are determined to be needed to run, and they are like producing output. [09:42] xnox: so, you are incorrect [09:43] fsckd only send Ctrl+C when it has the first % from fsck ready to be send [09:43] so, if you don’t have fsck in progress, the Ctrl+C message won’t be displayed [09:43] aha, so that's nice. [09:43] however, on the first progress report: [09:43] - if ctrl+C not send -> send it (only once thus) [09:43] - then send the progress [09:43] sent* [09:44] which is a bit backwards, especially if progress is >98.9% [09:45] I don’t think it’s illogical to send the ctrl+C message first, whatever pourcentage you are going to send (which is != 100%) [09:45] Although that implies different behaviour between fsckd-cancel-msg: and keys: because the latter is not fsck-specific [09:46] Unless someone can point to a spec for the "keys:" thing [09:46] i think we can forget about "keys:" no? [09:46] OK, doesn't matter then [09:46] xnox: Want fsckd-cancel-msg to auto-vanish? [09:46] that's the other thing, does fsckd ever remove the cancel-msg, after it is done? [09:46] or if it is transalted [09:47] i guess i want logs from it. [09:47] I assumed it would, but I could be wrong [09:47] Mostly because I was generalising for keys: [09:48] plymouth-theme-ubuntu-gnome-logo => still exists! fun [09:50] The upstream proposal is unlikely to ever land but it's useful as SCM and for auto-generating patches. I can change it to do whatever is easiest for Ubuntu [09:55] duflu, why do you think it's unlikely to land? [09:57] seb128, because upstream said so :) [09:58] duflu, ah, I though you were speaking about !106 but the comment is about !104? [09:58] I mentioned that in the status update this week I think? [09:58] Yes, those two [09:59] but yes, the current patch we can change as fits us [10:00] Ah, no I didn't state it in the status update [10:01] oh [10:01] xnox: r = plymouth_send_message(m->plymouth_fd, "", false) when the checks are finished (which should clear both content) [10:01] duflu, well, I've been following the upstream MR, I just though you were saying the mode approach from 106 where not likely to ever land upstream [10:01] duflu: "fsckd:1:%d:Checking in progress on 1 disk (%d%% complete)" [10:01] duflu, but you were speaking about the current patch, so ignore my comment [10:01] I'm not sure how to respond without creating confusion [10:01] * duflu nods [10:02] duflu: my understanding was "fsckd:NUMBER_OF_DISKS:PERCENT_COMPLETE:FALLBACK MESSAGE" where fallback message, is not shown on graphical plymouth, and only like shown/recorded as messages if one clicks ESC [10:02] duflu: or am I understanding this wrong..... [10:02] duflu: i wonder what i should be sending there. [10:02] (in casper md5sum) as we now have duplicate messages [10:03] * duflu is checking [10:03] xnox: It's not a "fallback". The implication is that it's the main message shown with disk checking [10:04] duflu: ack! i shall fix it then [10:04] xnox: man systemd-fsckd.service [10:04] Though that's confusing because there's a separate main message in plymouth which I remember before/after disk checks [10:05] The spec is too vague to say if that's right or wrong [10:06] So I assume the display-message should just be hidden and superseded by fsckd: while that's active [10:06] iirc [10:07] duflu: https://people.canonical.com/~xnox/casper-fsck.png [10:08] duflu: so the first message is "generated by the theme", the second message is ":" from fsckd, and last is the keycode. [10:09] duflu: imho we have 3 progress bars here =) one visual, and two % ones [10:10] duflu: i'd rather keep the first line for the regular display-message stuff; and make the theme override whatever was passed as with the Checking disks: 6% complete (or blank?) and keep the Ctrl+C message [10:11] duflu: for now, i will change casper, to emit empty : in that message to at least kill one of the messages [10:11] xnox: Are you saying you want the first line to come from display-message ? [10:12] duflu: for casper yes, because we flash individual file names there "Checking capser/filesystem.squashfs" etc. [10:12] duflu: for regular fsckd not sure, we could flash errors/warnings there. [10:12] duflu: or a heading [10:12] or maybe it shouldn't be there [10:13] duflu: somehow i was expecting just the progress bar, no text about % progress, and the Ctrl+C line to cancel. [10:13] duflu: and the checking disks 68% done be in ESC output only [10:13] * xnox ponders what is happening on the ESC output, one sec. [10:14] I'm trying to EOD but I am now too confused to offer a fix today. Maybe you can email me :) [10:14] if anything needs fixing [10:14] duflu: i am confused too =) i need UX/UI design people to tell me how it should look like [10:15] xnox, if ubuntu-logo is right I will check that again and see if it's not being emulated well enough [10:19] 🤷 [10:19] Night... [10:20] night duflu! [10:26] mvo, hey, could you change the maintainer from https://launchpad.net/update-notifier to ubuntu-core-dev? [10:33] seb128: sure, one sec [10:33] seb128: done [10:34] mvo, thanks [10:34] mvo, I converted it to git and push as lp:update-notifier now [10:37] seb128: nice [11:48] yeah, i have weird things to show to duflu [12:23] xnox, email or launchpad if you don't want to wait for tomorrow morning [12:23] Hey seb128, [12:24] hey GunnarHj, how are you? [12:24] seb128: Since you now is a proud member of ~ubuntu-translations-coordinators, do you have an idea how to handle this kind of request properly: [12:24] https://answers.launchpad.net/ubuntu-translations/+question/688978 [12:24] The https://launchpad.net/~ubuntu-l10n-ta team is apparently abandoned by the owner and the other admin, and several applications to join the team have been left unanswered. A complication is that the guy who offers to take over is someone without an Ubuntu record as far as LP is concerned. [12:24] Is this an rt.ubuntu.com thing? Other ideas? [12:24] seb128: I'm ok, thank you. [12:26] GunnarHj, easiest is to try to contact the current admin asking them to add someone, that's what I did for ~ubuntu-translations-coordinators ... but yeah, if that doesn't work then you need a RT [12:26] Hi all - why is the vendor splash remaining up on the screen during boot in focal? [12:27] Beret, hey, because that's what modern OS-es do, win10 does the same [12:27] Beret, that's the only way to have a smooth boot without transition or flicker [12:28] Beret, that somewhat fails/look less nice if for some reason you have a grub menu though (like multibooting or being old school) [12:29] seb128: While David responds to emails, this owner has so far ignored the guy's application to join. So yeah, rt next. [12:30] GunnarHj, I'm unsure request to join do trigger emails? also there is a difference between responding to an administrative request and to a personal email [12:30] GunnarHj, I do tend to be lazy on e.g list moderations or applications reviews and could ignore those for a while but I do respond to emails [12:31] GunnarHj, same, David was not dealing with ~ubuntu-translations-coordinators requests but responded to a private email [12:32] seb128: I get the point. Maybe try a personal email first. [12:32] right [12:32] GunnarHj, also I'm unsure about promoting that guy admin, as you said his launchpad account is new. We don't know who he is and he has no activity there [12:41] seb128: Right. I think we would need to establish a proper procedure for cases like this. I fear that the situation is the same for more teams. [12:42] indeed :/ === Newfangled___ is now known as Newfangled [13:26] is gedit untranslated for others as well? [13:28] seb128, wfm [13:29] oSoMoN, spanish or french? did you do the update and have your local built deb? [13:29] translated in french here [13:29] k, thanks [13:29] seb128, French, and I have a clean update [13:29] I guess it makes it a local issue [13:30] shrug, my own stupidity [13:30] thanks fro replying oSoMoN and didrocks! [13:30] yw :) [13:30] I have to change LC_ALL to fix session-migration tests, they don't work under fr_FR [13:30] had [13:30] and I still has that set [13:36] probably the test script should set it, sorry! [14:15] seb128, ok thanks [14:17] Beret, np, if you dislike it for some reason feel free to open a bug with your rational and we can get design's input [14:28] seb128, I don't dislike it. It's clean and consistent - I just wanted to make sure the change was intentional and on purpose [14:31] thanks [14:31] Beret, good, and yw! [14:56] bah ... the snap store in forcal doesnt expose the audio-record plug in the "permissions" window .... that makes a few of my snap just hard lock up (i.e. zoom-client) [14:58] (this works on 18.04 and 16.04 btw) [14:59] kenvandine: ^ [15:02] oh [15:02] [Build #19100162] riscv64 build of atk1.0 2.35.1-1ubuntu1 in ubuntu focal RELEASE [15:02] ogra: i just fixed that a couple days ago [15:02] new arch seen :) [15:03] it should be in the latest revision on latest/stable/ubuntu-20.04 [15:04] well, i downloaded dialy-live from cdimage [15:04] *daily [15:05] seems to be from yesterday [15:08] ogra, latest build is 20200401, and there is a new one coming soon [15:08] ok [15:33] ricotz, FYI, I figured out the build failure on ppc64el/s390x on xenial and bionic: https://bugzilla.mozilla.org/show_bug.cgi?id=1626972 [15:33] Mozilla bug 1626972 in Untriaged "firefox fails to build on ppc64el and s390x with an old clang/libstdc++" [Normal,Unconfirmed] [15:58] oSoMoN, \o/ [15:58] kenvandine, tried with upgrading snap-store, still no audio-record, do i need to use edge ? [16:03] kenvandine, gedit master snap start failed to build because the tpl part is using autotools to build and they removed it now to only have meson [16:03] (just a FYI, I still don't know how reliably those failure email reach you) [16:48] ogra: it's in the stable/ubuntu-20.04 channel [16:48] which is what's seeded [16:49] once i work out the last of the issues there it'll get promoted to stable [16:53] seb128: i'm ignoring failures on the master snaps for now [16:54] once i get some other things off my plate i'll review all the snaps and fix any failures [18:29] kenvandine, awesome, thanks ! [19:34] ricotz, hey, could you have a look to indicator-sound failing to build with the current vala? [19:34] https://launchpadlibrarian.net/471371580/buildlog_ubuntu-focal-amd64.indicator-sound_12.10.2+18.10.20180612-0ubuntu1_BUILDING.txt.gz [19:34] /<>/indicator-sound-12.10.2+18.10.20180612/src/notification.vala:22.2-22.20: error: Creation method of abstract class cannot be public. [20:54] github is broken :/ [21:00] oh come on gh, sort your s*** out... [21:08] Looks like some of GitLab is back, but not mentioning users - kenvandine see https://github.com/snapcore/snapd-glib/pull/83 [21:08] snapcore issue (Pull request) 83 in snapd-glib "Add support for new snap types: "core", "base" and "snapd"" [Open] [21:09] robert_ancell: there doesn't seem to be a type "core" [21:09] the core snap is type os [21:09] core18 is type base [21:10] I think we can mark all base snaps as "essential" [21:10] robert_ancell: i did a quick query of the store and found 4 uniq types in the store [21:10] app, base, os, snapd [21:10] robert_ancell: yeah [21:10] kenvandine, what is an OS snap? [21:10] core [21:10] i suspect that is more legacy [21:11] yeah. [21:11] but regardless, we need to handle it [21:11] I figure we treat os and base as the same in g-s [21:11] yeah [21:11] so you can drop core from your PR [21:11] kenvandine, it's in snapd [21:11] oh [21:12] just no sanps using it [21:12] snaps [21:13] robert_ancell: ok, so we'll mark base, os, core, and snapd types as essential? [21:13] Yeah, I think so. Basically anything not app [21:13] and add a hack to mark the content snaps from a static list for now? [21:13] Perhaps just that logic - != app, then it's "system" [21:13] and snap-store as well [21:13] yeah. [21:13] oh, you mean not having an app defined? [21:13] or just the static list? [21:14] i'd vote for the static list until we can talk to the snapd folks about a new type for content [21:15] it would also be interesting if snapd could tell us if a snap was installed because it was needed or if a user specifically chose to install it [21:15] I mean if type != "app" then we mark it as not uninstallable. [21:15] ok [21:15] kenvandine, yeah, that would be useful. And if it can be removed without affecting any existing snaps. [21:16] yeah