[02:28] Can anyone help review this one: https://github.com/ubuntu/snapcraft-desktop-helpers/pull/184 [02:28] ubuntu issue (Pull request) 184 in snapcraft-desktop-helpers "bindtextdomain: Support locale files under share/locale" [Open] [05:54] good morning [05:59] Morning didrocks [06:00] hey duflu [06:03] duflu: hum, I'm running mutter 3.32.0+git20190410-1ubuntu1 which has supposively your timestamp fix, but when I click on the dock, I still have my apps not focused when they start [06:03] good morning desktopers, happy friday! [06:04] hey duflu didrocks [06:04] hey seb128 [06:04] Hmm [06:04] Hi seb128 [06:04] Happy Friday [06:04] some people on the french forum says that it fixes it for them, so there is maybe many causes ? [06:05] * didrocks just tried if intellihide mode could have an impact, but not the case [06:05] GNOME has been having issue giving the focus in some cases since we switched to it (or at least ti's also an issue in bionic) [06:05] unsure if your issue is different [06:05] well, it's quite a 100% hit here [06:05] which was never the case before 2.31 [06:05] 3.31* [06:05] on any app? [06:05] yep [06:05] terminal [06:05] nautilus [06:05] didrocks, the bug seems to be fixed here. Remember it was Xorg sessions only [06:05] firefox [06:05] duflu: I'm on Xorg [06:06] ah wait [06:06] maybe it was slightely updated this morning by unattended-upgrade [06:06] Update not fully installed? [06:07] (I wonder why unatteded-upgrade is installed, it's not a security fix…) [06:07] and so apt policy showed me I was on the latest [06:07] we apply dev updates with unattended-upgrade now? [06:07] looks like it from my history.log :/ [06:07] weird [06:07] http://paste.ubuntu.com/p/BXpj2M2gRP/ [06:08] as I wasn't expecting that, I thought apt policy -> latest meant "updated yesterday evening and running latest" [06:08] so, let me alt+F2 [06:08] Yeah [06:08] Or log out... [06:08] duflu: all working now! [06:08] Though not if you want to keep your windows [06:08] \o/ [06:08] at least, confirming the fix :) [06:08] but really, unattended-upgrade, why? [06:09] Foundations? [06:09] yep, unsure if this change was desired [06:09] I definitively didn't tweak any config [06:09] and especially on the dev cycle, I want to have control of my ugprade [06:09] I knew I had the fix because my test wallpaper became sharper today [06:10] seb128: duflu: do you have the same unattended-upgrade experience? [06:10] didrocks, not sure. My dev system gets turned off every night [06:10] duflu: well, same for me, it's on reboot that it updates [06:10] Weird [06:10] duflu: you can look at your apt logs and see if you have unattended-upgrade lines [06:11] * didrocks disables the service for now [06:11] didrocks, yes. It seems I am now getting unattended-upgrade [06:12] let me file a bug [06:13] didrocks, yeah, I killed it a few time recently because it was blocking me to using apt in the morning and taking too long and I couldn't be bothered waiting to do $work [06:13] seb128: do you think that should be -tracking? I have no opinion, but we may have other side-effects I guess… [06:13] ok, let me open the bug first [06:13] "Software & Updates" tells me it is set to only auto-install security updates [06:14] yeah, it's supposed to only mess with those [06:14] How do we know mutter wasn't a "security update"? [06:14] we don't have security updates in the dev version [06:15] so, it's not in the "security" pocket [06:15] Yeah, the pocket [06:15] just the regular release one [06:15] yep [06:15] and as you can see in my pastebin those are all regular packages in the release pocket ^ [06:15] I asked rbalint on #ubuntu-devel [06:17] thx! [06:48] didrocks, k, so sidestepping over, the situation is that we got confused by u-u but the focus fix works for you after all? [06:48] seb128: indeed. I still think that changing the behavior of u-u in a drastic way without warning users is weird [06:49] but at least, the main point, "focus mutter issue" is fixed [06:59] he failed at communicating properly yeah [06:59] but I think on principle it's fine to have that behaviour, it gives us testing before landing changes to stable which would be difficult to get otherwise [07:00] and unstable series are probably mostly used by distro dev or users who like to test edge things and can deal with the behaviour (if it's documented) [07:01] yeah, we need a reminder that upgrades start applying automatically [07:49] RAOF are you around? [07:49] Hmm, no. Not even in the channel [08:00] morning [08:00] hey willcooke, how are you? [08:00] hi seb128, ok, how about you? [08:00] hey willcooke [08:01] morning didrocks [08:02] willcooke, good, it's friday! [08:02] hello [08:02] hey Laney [08:02] how are you? [08:02] hey Laney [08:04] yeah not bad [08:05] Morning willcooke and Laney [08:42] Laney, are you all Ubiquiti'd up at home? [08:43] oh sorry [08:43] hey didrocks duflu ;-) [08:43] and willcooke [08:43] willcooke: yes [08:43] ahoy! [08:43] I want to get another access point actually, it doesn't quite cover the whole house properly atm [08:44] Laney, cool. I think I asked you about it before, and you were a big +1. I think the time has come for me to admit that my cobbled together collection of cheap no-name Wifi APs has had its time [08:44] Let's see what May brings [08:44] the month, not the witch [08:44] never rely on M... yes indeed [08:44] :D [08:45] They have two different product lines which don't particularly integrate with each other, which is a bit sad [08:45] so I have https://www.ui.com/edgemax/edgerouter-poe/ and https://www.ui.com/unifi/unifi-ap-ac-pro/ [08:45] but they have separate software stacks [08:46] edgemax is what I was looking at for the router [08:47] Laney, did you choose the pro over the lite for a specific reason? [08:49] I think it could achieve faster speeds or something? More channels maybe? [08:50] oki, I'll do some more reading [08:50] was a few years ago already [09:21] Laney, with the freeze nothing is autoaccepted now right? like I don't need to worry about packages being in a set or not for gstreamer right? [09:21] (I don't want to e.G have some universe plugin autoaccepted while the base is not) [09:23] seb128: the script is off [09:23] thx [09:28] Laney, k, gstreamer stack uploaded to disco and desktop ppa (https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/ppa) [09:28] needs to build now (seems like ppa doesn't do depwait?) [09:28] let's give it some testing from the team in the ppa once it will be built [09:29] sure they do, you just get the × icon [09:29] ah, indeed [09:29] good [09:35] seb128, Laney: do you know how to detect that a udev rules is running on the live installer. I would like to make it quit in this specific case, so that LP: #1824177 can be fixed [09:35] Launchpad bug 1824177 in nvidia-graphics-drivers-410 (Ubuntu) "dmesg spammed with nvidia-nvlink messages during install" [Undecided,Confirmed] https://launchpad.net/bugs/1824177 [09:35] willcooke: ^ [09:38] sorry, I dont know [09:39] tseliot, sorry but I don't know either [09:44] tseliot: isn't vorlon saying that you shouldn't be doing anything until reboot at all? [09:44] but no, sorry, I'm not aware of an official way to detect a live environment [09:44] you might want to ship something in casper [09:45] AFAIK udev rules in /run shadow ones in /lib [09:46] Laney: I don't think udev rules have that kind of logic in place. What I was thinking is to make the udev rule quit when on the live installer. So far, I've found out that update-initramfs is diverted on the live installer. Maybe I can use that [09:47] right, that's a casper script [09:48] so, I want to test a condition in the udev rule, and avoid doing any big changes before the release [09:50] I think you probably want to make casper ship a udev rule in /run/udev/rules.d/ that overrides the packaged one [09:50] "files in /run take precedence over files with the same name in /lib. This can be used to override a system-supplied rules file with a local file if needed" [09:50] Laney: do you mean a rule with the same name? [09:50] yep [09:51] that's even easier. I can try it here now [09:51] slightly hard bit will be testing the casper change [09:57] Laney: just an empty udev rules with the same seems to do the trick, and I don't get spammed any more [09:57] thanks [09:57] woot thanks tseliot Laney [09:58] np [09:58] tseliot: so that's a casper-bottom script fwiw [09:58] like the one to disable snap refresh [09:58] Laney: ok, then I'll have a look at the sources, and come up with a patch [09:59] ok [09:59] to test it you can do break=top from an iso boot and then hack it into place in /scripts [09:59] but it's very bare bones, be warned [10:03] Laney: ok, I'll try that. Thanks [10:04] (well, you could probably re-pack the ISO or something too...) [10:15] Can anyone review this PR?: https://github.com/ubuntu/snapcraft-desktop-helpers/pull/185 [10:15] ubuntu issue (Pull request) 185 in snapcraft-desktop-helpers "gnome-platform: Drop unnecessary build-packages" [Open] [11:04] Laney: I wrote the script manually (using tee), and made the file executable (chmod a+x), after booting with break=top, and then I run the "exit" command. /run/udev/rules.d/ wasn't created. Is there any way to check what happened? Maybe a log from casper? [11:05] I don't see anything useful in casper.log [11:05] the script was in scripts/casper-bottom/ [11:07] brlin, try asking kenvandine when he gets online [11:18] new ups battery arrived, going off line for a few mins while I change it over. I can't remember exactly what's connected and what's not, but I assume my modem is. [11:22] tseliot: weird, I just tried the same and it worked for me -- did you add it to ORDER and copy all of the boilerplate stuff that the other scripts have at the top? [11:23] casper.log isn't very helpful tho, agreet [11:28] seb128: Sure, thanks! [11:29] (not sure what ORDER does tbh) [11:35] well, that went better than I expected. [11:35] Hardly anything caught on fire [11:54] so it seems upowerd is holding on to one of my upses, and I want nut to manage it. Any ideas how I can stop upower doing that, or just stop upowerd altogether? [11:55] heh, I just killed it and started nut before it could restart. Problem solved [11:56] also, nut is *the* hardest thing to work with in the world. [11:57] :/ [11:57] gstreamer stack update in https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/ppa if others want to test it [11:57] (seems to work fine here) [11:57] disco update [11:57] * willcooke updates [11:58] thx [11:59] (tested totem/rb/cheese here) [11:59] brb, changing location [12:13] (back) [12:15] seb128: is there a but about the g-i-s/snap thing? [12:16] andyrock, hey, good timing I was about to ping you :) [12:16] bug #1824188 [12:16] bug 1824188 in gnome-initial-setup (Ubuntu) "Software tab is empty on clean 19.04 install" [High,Confirmed] https://launchpad.net/bugs/1824188 [12:16] andyrock, ^ [12:16] I took a look at the code, it's going to take a while to fix it [12:17] also because reproducing the bug it's not easy [12:18] could you kill snapd, and run g-i-s without it running, then start once g-i-s is running? [12:20] andyrock, attach gdb to the snapd service to block it from responding? ;) [12:21] (side note: a problem I was having with a specific bluetooth mouse not reconnecting automatically is seemingly fixed :) ) [12:21] clobrano, hey, is that gnome-initial-setup bug about using the incorrect icon still valid? the description pointed out to the welcome-app yaru icon but that has been removed [12:22] willcooke, good! was that the gnome-bluetooth update? [12:22] willcooke, also did you test the gstreamer updates? I dropped from IRC for a bit so might have missed that [12:23] hey seb128! Was the bug opened on launchpad? I can't find it on github [12:24] seb128, just testing now. Cheese works, downloading b.b.bunny now... [12:24] rb radio works [12:24] clobrano, yes, bug 1803521 [12:24] bug 1803521 in gnome-initial-setup (Ubuntu) "gnome-initial-setup uses wrong icon" [Undecided,New] https://launchpad.net/bugs/1803521 [12:24] let me check [12:25] clobrano, thx [12:26] seb128, @ bluetooth - I think so. I found an upstream bug which said it was fixed, so sounds right [12:26] willcooke, good :) [12:27] Saviq, do you still have your Logitech M557 mouse? If so, I think that disco has the fix now for reconnecting problems [12:27] willcooke: yeah I've been working with duflu to verify the fix [12:29] Laney: unless I missed something obvious: http://paste.ubuntu.com/p/vMRpJdRccV/ [12:29] Saviq, woot [12:29] Saviq, what fix is it? [12:29] Laney: and no, I didn't add it to ORDER. I'll check that [12:29] Saviq, I mean are you refering to a specific commit we can SRU? [12:29] (bug number?) [12:29] I think its adding the device ids to a file so that it auto tries with pin 0000 [12:30] I'll find it [12:30] I'll get you guys the big number when I'm back in Ubuntu [12:30] seb128, looks like this one: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1246981 [12:30] willcooke, Saviq, https://salsa.debian.org/gnome-team/gnome-bluetooth/commit/ba99a3ce then? [12:30] Ubuntu bug 1246981 in bluez (Ubuntu) "Bluetooth mouse fails to re-connect after sleep." [Medium,Confirmed] [12:31] The latest gnome-bluetooth update I believe [12:31] seb128, yeah that looks like it [12:31] well the diff doesn't make sense to me though [12:32] hm, nothing about this mouse in there [12:32] one sec [12:32] ah [12:34] willcooke, no, it's fine, I misread it [12:34] it's the [12:34] [12:34] [12:34] [12:34] [12:34] bit from the diff [12:35] ah, I see [12:35] I'm going to SRU that now [12:35] woo, thanks seb128 [12:35] np [12:37] seb128: using gdb it's not going to work because gnome-initial-setup will just block [12:37] because it's using sync operation [12:37] andyrock, ah, it's a sync call without timeout? [12:38] I'll try to make it async [12:38] andyrock, or maybe ask #snappy if they can help you putting snapd in the state which makes it not respond [12:38] seb128, willcooke: my bug is https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1777062 [12:38] Ubuntu bug 1777062 in gnome-bluetooth (Ubuntu Cosmic) "Logitech M535 mouse only pairs successfully after 4-5 tries" [Undecided,New] [12:39] seb128: yes, since the Yaru icon is not there anymore, that specific behavior is invalid. However the "problem" should still be there [12:39] clobrano, what's the icon you expect to be used between the two? [12:40] Saviq, thx [12:40] Saviq, willcooke, that bug description doesn't make sense to me. gnome-bluetooth only handle the pairing from the settings, not happens later [12:40] I mean if it pairs it in a way that is not persistent/trusted in bluez that explain it has to be paired again [12:40] seb128, Totem working with an h264 working. Promoted me to install the codec, did that from the ppa, restart totem, loaded the video, moar rabbits [12:40] but if you pair using bluetoothctl then gnome-bluetooth is out o fthe picture [12:41] willcooke, great, thx for testing! [12:41] seb128, is the pin-code-database shared between bluetoothctl and gnome-bluetooth perhaps? [12:42] willcooke, gnome-bluetooth used to have overrides, the change is basically to drop that to use the bluez one [12:42] bluez doesn't use anything from gnome-bluetooth no [12:43] it's a lower level component, doesn't require GNOME nor event a graphical session [12:43] willcooke, the gnome-bluetooth change should fix the case of "pairing done through GNOME doesn't persist" [12:43] which is probably most reports [12:44] the "pairing with bluetoothctl has problem" from Saviq sounds like it's different though [12:44] maybe that was a kernel issue or such also fixed in disco [12:45] I bet duflu will know [12:46] I will SRU the gnome-bluetooth fixes since they make sense [12:46] that's a good first step [12:46] seb128: yes, the bug was opened because the unexpected icon was used, and this issue is gone [12:46] seb128: but I thought that the problem is due to a difference in how the .desktop files where written [12:47] clobrano, right, if we standardize we need to pick one icon or the other, I just don't know which one makes more sense ... do you have an opinion on that? [12:48] seb128: I have no strong opinion, I can only say that "preferences-system" doesn't seem specific enough if the real target is the ubuntu-logo [12:48] k [12:48] clobrano, thx [12:48] seb128: np :) [12:49] omg, just noticed... s/where/were ^ [13:11] brlin: i'm on it [13:14] kenvandine: <3 [13:20] morning kenvandine [13:23] hey willcooke [13:26] seb128: if we want to get rid of most of the gedit crashes it would be nice to have this in disco: https://gitlab.gnome.org/GNOME/gedit/merge_requests/32 [13:26] GNOME issue (Merge request) 32 in gedit "build: Reintroduce enable-gvfs-metadata option" [Merged] [13:26] Laney, ^ do you have slots to help reviewing the few pending fixes from andyrock for gedit today? [13:27] seb128, Laney: the other fixes are not strictly necessary if we get this in debian/disco [13:27] andyrock, why not? they don't fix other problems? [13:28] well you mean they are less important? [13:28] they do, but if we enable gvfs metadata the crash is not going to happen [13:29] they're necessary if and only if gvfs metadata is disabled [13:31] to summarize: [13:32] 1. https://gitlab.gnome.org/GNOME/gedit/merge_requests/34 is necessary both if gvfs is enabled and if it is disabled (but we already distro patched it) [13:32] GNOME issue (Merge request) 34 in gedit "open-document-selector: Properly remove idle" [Opened] [13:33] 2. https://gitlab.gnome.org/GNOME/gedit/merge_requests/35 it is necessary only if gvfs is disabled [13:33] GNOME issue (Merge request) 35 in gedit "metadata-manager: Remove singleton" [Opened] [13:33] andyrock, oh ok [13:33] 3. tab: Cancel loading operation when tab is disposed this does not fix a crash but I saw it while debugging so I fixed it [13:33] now the commit that just got merged re-enabled gvfs by default [13:34] jbicha, ^ or maye you can review since you have been sort of gedit maintainer in recent cycles :-) [13:34] seb128: jbicha said that I can merge them if I want but I can't because I'm not a GNOME developer [13:35] andyrock, I try to get it later today if Laney can't but I'm currently on a packed todolist for the day :/ [13:35] and now it's too late for me to ask 💔 [13:35] my suggestion for Laney is to review/merge https://gitlab.gnome.org/GNOME/gedit/merge_requests/34 [13:35] GNOME issue (Merge request) 34 in gedit "open-document-selector: Properly remove idle" [Opened] [13:35] it should be safe enough [13:36] willcooke, Saviq, https://launchpadlibrarian.net/418989286/gnome-bluetooth_3.28.0-2ubuntu0.2_source.changes (used another bug for the SRU which looked like the issue and was less old/busy, those reports which collect problems over years often lead to difficult SRU validation because some of the people subscribed have another problem and will claim your SRU doesn't work) [13:36] andyrock, that's the wrong one right? [13:36] that one we already backported/SRUed [13:36] you mean !32 [13:36] nope [13:37] ah, you mean upstream [13:37] I know that it has been backported but it still nice to have it upstream [13:37] right [13:37] gotcha [13:37] you are correct :) [13:37] seb128, @ bluetooth: will confirm on this machine [13:37] seb128: also I can distro-patch the commit to enable gvfs by default after I take care of g-i-s [13:38] andyrock, k, let's see what L_aney says when he's back from lunch [13:38] andyrock, thx [13:38] kk [13:40] yay: [13:40] W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://dl.google.com/linux/chrome/deb stable Release: The following signatures were invalid: EXPKEYSIG 1397BC53640DB551 Google Inc. (Linux Packages Signing Authority) [13:40] W: Failed to fetch http://dl.google.com/linux/chrome/deb/dists/stable/Release.gpg The following signatures were invalid: EXPKEYSIG 1397BC53640DB551 Google Inc. (Linux Packages Signing Authority) [13:40] W: Some index files failed to download. They have been ignored, or old ones used instead. [13:41] EXPKEYSIG [13:41] well done google :p [13:42] \m/ [14:00] brlin: thanks, that's a nice improvement. Merged! [14:01] kenvandine: Thanks! Here's another one: https://github.com/ubuntu/snapcraft-desktop-helpers/pull/184 [14:01] ubuntu issue (Pull request) 184 in snapcraft-desktop-helpers "bindtextdomain: Support locale files under share/locale" [Open] [14:06] brlin: saw it, that only helps snaps with --prefix=/ [14:06] can't imagine there are a ton of those [14:06] kenvandine: Snapcraft autotools plugin by default built with empty prefix [14:07] s/built/build/ [14:07] although it time cost should be negligible [14:07] empty usually defaults to usr or usr/local [14:08] kenvandine: That's not what I encountered though :-/ [14:08] ok [14:09] It does specify `--prefix` while configuring , just set it as null: https://github.com/snapcore/snapcraft/blob/77c17b26573e474783e9535bf66ce3fe358b71f1/snapcraft/plugins/autotools.py#L121 [14:10] brlin: indeed [14:11] brlin: merged [14:11] kenvandine: Thanks a bunch! [14:11] brlin: thank you! [14:18] seb128: yeah I saw the ping about gedit somewhere else [14:19] Laney, it was trello :) [14:19] so I had the tab open already, but thx for the re-ping [14:19] seems SRUable to me [14:19] Laney, but that other bug andyrock was pinging about seems worth trying to get into disco proper so maybe one for today if we can squeeze [14:44] Laney, thx for catching that tracker buggy upload, trying too much this week and not taking time to do some of them properly :/ [14:45] Laney, I was going to upload to Debian but didn't want to wait to wait for launchpad to pick the uploads/sync and miss friday to get it reviewed [14:45] np, good when reviews work [14:45] Laney, but feel free to take over that :) [14:45] well you can do a ~fakesync upload [14:45] like for gstreamer [14:45] but also things can be SRUed at this point, maybe that makes for fewer mistakes with less rushing [14:45] right, it's just that jbicha commited 2.2.1 things to the vcs [14:46] and I didn't want spend time sorting out what to do there at the time [14:46] yep, I'm making a branch from the 2.1.8-1 tag [14:46] k [14:46] git checkout -b debian/buster debian/2.1.8-1 and update debian/gbp.conf [14:46] thx for the tip :) [14:46] yeah, I know for SRU, I've difficulties to be in peace with that though :( [14:47] we always end up getting reports in the error tracker and launchpad until end of times from users who don't apply updates for some reasons [14:47] yeah like we get people who insist on running devel-proposed [14:47] but that's probably my issue, I should accept that such are software users [14:47] * Laney has made peace with these things [14:47] one day you need to teach me how :) [14:48] anyway, I do try to land some of the crashers fix in the release for those reasons [14:48] but I'm not pushing so fine if they sit in the queue or in proposed until SRU time [14:48] okey, maybe make sure they have a bug report attached then [14:48] not saying they don't, haven't checked for that [14:49] yeah, that one had [14:49] g-c-c doesn't for the translation fix I added [14:49] worth thing it get rejected and it's a bit more work [14:49] I try to that for the next ones [14:49] nod [14:49] should I reupload the gstreamer stack for a SRU reference? [14:49] probably for -release [14:49] probably going to accept those ones in a minute [14:50] morning! [14:51] Laney, thx [14:52] hey Trevinho, how are you? [14:53] seb128: hey, all good! [14:53] you? [14:53] good! [14:53] happy friday btw :) [14:54] the work day only starts for you, but any fancy plan for the w.e ;) [14:55] seb128: do you want me to add an error message in g-i-s in case it fails to get the featured snaps ? [14:55] I've added a retry behaviour [14:55] it's going to try to every 250 ms for a maximum of 5s [14:56] but what if it fails? showing an error will required a UIFe [14:59] andyrock, I think new string is fine in that case [15:00] willcooke, Laney, ^ opinion? (about bug #1824188) [15:00] bug 1824188 in gnome-initial-setup (Ubuntu) "Software tab is empty on clean 19.04 install" [High,Confirmed] https://launchpad.net/bugs/1824188 [15:01] For the string, how about... "Unable to retrieve applications at this time. Please open Ubuntu Software to see what's available." [15:01] willcooke, we do want a string/UI change right? even if it's untranslated at this point? [15:02] thinking.... [15:02] andyrock, also chipaca was saying yesterday that it takes 90s for snapd to be ready in his kvm [15:02] willcooke, did you do any timing testing at the end? [15:02] seb128: happy Friday you too :-), well... some more sightseeing I expect [15:02] I did, and it was no where near 90 seconds. Let me fire up the vm [15:02] andyrock, so maybe 1s for 30s or something would be better [15:02] oh, except I will need to reinstall [15:03] willcooke, no hurry, but I think we still want to push a bit further than 5s retry total [15:03] i noticed the same problem in hyperv yesterday [15:03] Yeah [15:03] empty page [15:03] It certainly feels like something has got worse there on the snapd side [15:04] who's going to wait 90s for that page? XD [15:04] is that a spinner while waiting for the list of snaps? [15:05] Laney, correct [15:05] andyrock, well, I think that's total from boot that it takes 90s [15:06] Laney: I'm going to add a spinner too [15:06] andyrock, seb128 - if we don't have apps to show, we should remove the "You can use software to install apps like these" too [15:06] andyrock, so time your session start, the wizard load, you go through previous steps [15:06]