=== _salem is now known as salem_ === chriadam|away is now known as chriadam === salem_ is now known as _salem === chihchun_afk is now known as chihchun [06:04] Where I can find a list of what current hardware support is like for Ubuntu touch on the NExus 4? [06:24] Jef91: Perhaps https://wiki.ubuntu.com/Touch/Devices [06:26] duflu, for refernce it is here https://docs.google.com/spreadsheet/ccc?key=0ArLs7UPtu-hJdDZDNWliMmV1YUJ3Zk1pQlpDdGp4VFE&usp=sharing#gid=0 [08:09] good morning [08:34] stgraber: hey! Do you know if your recent lxc upgrade could have caused the boot-up problems on touch devices by any chance? [09:46] Is Ubuntu not available for nexus 6 yet? [09:51] not until someone does a port [09:56] Is a really big task o [09:56] Porting? === chriadam is now known as chriadam|away [10:02] Good morning all; happy Friday, and happy Handwriting Day! :-D [11:09] anyone here? [11:09] i have a doubt [11:10] GAM002: yes there are people here [11:10] i am currently using ubundu 12.04 my internet is very slow so is which can help me save bandwidth? upgrading to 14.04 or downloading 14.04 and using it to ugrade and how much MB will the upgrade be? [11:11] anyone? [11:12] GAM002: Not sure I understand the question but the best place for things like that would be the #ubuntu irc channel this is a channel for touch development [11:12] ook [11:13] i ment how much MB will be needed to upgrade from ubuntu 12.04 to 14.04? [11:13] and please share the ubuntu irc link please [11:14] davmor2 [11:14] : [11:15] GAM002: just type /join #ubuntu [11:15] ok it worked thanks === _salem is now known as salem_ [11:17] um hi [11:17] sidharth: hello [11:17] I have reached here after browsing a bit about contributing to ubuntu [11:18] So I need some help on how to get started [11:19] sidharth: started on what? [11:19] Oh and this is my first time ever on an IRC. [11:19] starting to work on ubuntu [11:28] hmm... does the current devel-proposed boot for you guys? [11:28] seems stuck here on my Nexus 4 [11:28] mzanetti: nope, image 74 is broken [11:28] ah. thanks [11:40] mandel: heya; haven't fully finished testing the UDM stuff yet, but the data URIs with http:// URLs added to them raised a few red flags with me, so I dug into that deeper and it turns out to be a bug in the way oxide is passing data URIs to the webbrowser: https://bugs.launchpad.net/oxide/+bug/1413964 [11:40] Launchpad bug 1413964 in Oxide "data URIs have parent URL added to them when passed to webview's contextualData" [Undecided,New] [11:41] mandel: I'm think it might be best to label the http:// stuff in that branch as a workaround for this bug for now, and then remove it once the oxide folks have time to fix things on their end (since I'm guessing that won't be able to happen for RTM) [11:41] thinking* [11:41] mandel: what're your thoughts? [11:44] Elleo, I did notice that was not correct and was not part of the uri format, the way I fixed it is by checking the contains ('data:') instead startswith and do a split on it.. is certainly a hack [11:44] Elleo, I can add a #HACK comment to make sure that we deal with it [11:44] mandel: okay, cool [11:45] mandel: yeah, just so long as we remember to remove it once oxide is doing the right thing I think it's okay [11:45] Elleo, I'll add udm to that bug, sounds good? [11:45] mandel: yep [11:46] mandel: as far as the code goes otherwise it all looks good to me, I'm just going to run through all the browser download tests to be safe, then I think we'll be good to go :) [11:47] Elleo, sweet, I have downloaded several images (thumbnails) and works as expected, what is nice is that it was fixed only in the udm service side so no need to rebuild anything [11:48] mandel: yeah :) [11:48] Elleo, let me know your feedback and I'll request a silo etc.. [11:49] mandel: sure, should be done with browser/content-hub tests in a few minutes [11:49] superb [11:57] mandel: all looks good, if you just update the branch with a comment about the underlying bug I'll go ahead and approve it :) [11:57] Elleo, ack [11:59] Elleo, pushed [11:59] rev 340 [12:01] mandel: great, approved :) [12:08] davmor2: hi! I'm trying to reproduce bug 1413655, and now the phone seems to be stuck on the Google logo [12:08] bug 1413655 in system-image (Ubuntu) " --switch removes accounts" [Undecided,New] https://launchpad.net/bugs/1413655 [12:09] davmor2: did you also have to wait a long time? [12:09] mardy: yeap [12:09] davmor2: OK, I'll just keep waiting then [12:09] mardy: the apparmour profile it all to cock [12:12] dholbach sorrt for the bad revieuw on your app, after closing it and reopening it it worked, but i cant update my rating [12:12] *sorry [12:13] Justcarakas, and I thought we were friends! [12:13] * dholbach storms out [12:13] Justcarakas, interestingly enough... the same thing happened for popey [12:13] dbarth, alexabreu: so it looks like for two folks, starting a webapp works only on the second time [12:14] hehe, wel so it wasnt just me :D ps, you are likable [12:14] dbarth, alexabreu: can you try to install "roll a dice" from the store and see if it works on the first launch? [12:14] Justcarakas, thanks for the flowers :) === MacSlow is now known as MacSlow|lunch === ecloud_wfh is now known as ecloud [12:51] dholbach, trying [12:52] dholbach: webapp, or html5 one? [12:52] dbarth, html5 [12:52] ah [12:52] dholbach, ah this is not a webapp then [12:52] sorry, yes, it's html5 [12:52] is this a known issue? [12:53] not really; i've seen that in a silo, but that one had not landed since [12:53] can you reproduce it thought? [12:53] though [12:53] * dbarth installs roll a dice [12:54] dholbach, dholbach yes [12:54] dholbach, the first time I open it it spins, and does not ... but all subsequent tries work [12:55] alexabreu, shall I file a bug about it? [12:56] dholbach: yes, please [12:56] alexabreu: reproducing on rtm or vivid ? [12:56] dbarth, rtm [12:57] alexabreu: starts find on first try here on vivid [12:57] fyi [12:58] dbarth, alexabreu: https://bugs.launchpad.net/ubuntu-html5-theme/+bug/1413986 [12:58] Launchpad bug 1413986 in Ubuntu HTML5 UI SDK "First launch of a HTML5 app doesn't work, second one does" [Undecided,New] [12:58] davmor2: it's still there at the Google prompt, it's about 1 hour now... [12:58] davmor2: was it *taht* long? [12:59] mardy: ah crap sorry latest vivid image is broken see the phablet mailing list [12:59] dholbach, dbarth silo 13 might make it work [12:59] what's the hang about? [13:00] dbarth, lxc broke [13:01] mardy: ^ sorry dude I forgot all about the broken image [13:03] davmor2: oops, you are right [13:03] would it possible to have some very basic preliminary automated testing for -proposed images? like "does it boot"? [13:04] I'm just wondering if that's possible because I've seen a couple of "warning: does not boot" messages on the phone list in the last weeks === VargaD_ is now known as VargaD === dandrader is now known as dandrader|afk === alan_g is now known as alan_g|lunch === MacSlow|lunch is now known as MacSlow [13:18] did I read that one of the proposed images last night/this morning was busted? [13:21] yes [13:21] vivd though [13:51] ogra_: do we have a root cause already? [13:52] dholbach: in general, people aren't supposed to be using -proposed, and ci does have tests running [13:52] sergiusens, lxc it seems [13:53] dholbach: http://ci.ubuntu.com/smokeng/vivid/touch/ [13:53] dholbach: people running proposed should always check the ci results before upgrading [13:54] if not we will have a quality gate for proposed called proposed-proposed :-P and then people will use that and so on and so forth :-) [13:54] "people" should never run proposed [13:54] developers should ... on development devices [13:54] ogra_: exactly [13:55] let me rephrase [13:55] consumers shouldn't run it; developers should (but also know how to get out of it easily) [13:55] there is work going on to switch to a three channel model [13:55] one daily, one with a weekly promotion ... one with monthly promotions [13:55] ogra_: I know where that is coming from :-) [13:56] dogfooders should use the dsecond [13:56] devs the first [13:56] everyone else the last [13:56] and even then it isnt guaranteed to be bugfree if you use the development release [13:56] ogra_: I like it that you are driving most of this [13:56] since it is a development release :) [13:56] :) [13:57] or if the integration tests were reliable, you can have a step before the -proposed is published (and so, no-one is supposed to use that image until it's published to -proposed) [13:57] well, slangasek is driving it more than me [13:57] but i'm involved, yeah [13:57] didrocks, well, i would like to have a channel where you can just quickly push a package with debug enabled [13:58] so i wouldnt want proposed to be actually guarded [13:58] ogra_: maybe the set of tests could be small, like "does it boot, can I do a phone call" [13:58] that guarding should happen between proposed and the weekly channel instead [13:58] ogra_: so, 10 minutes of tests, and then, "publishing to -proposed" is just a 1 min switch, changing symlinks [13:59] sergiusens, I wasn't trying to blame anyone [13:59] to ensure devs always have a working phone at least [13:59] but I think it saves a lot of energy if we had something which tested a -proposed image for bootability [13:59] as far as I'm concerned.. what a consumer should run is a different question :) [13:59] dholbach: oh, I know; I didn't take any blame :-P [14:00] dholbach: I was just trying to explain what's currently there [14:00] sure [14:00] right, we're all aware that what we have is suboptimal atm [14:00] and all actual ressources go into rtm [14:01] ok... do you think it would be hard to have a bootability check for -proposed images? :) [14:01] ogra_: that will change next month I hope [14:01] dholbach, thats a question for CI ... [14:01] dholbach: it's not the bootability check, it's the ci infra that is the problem [14:01] dholbach: because they consume from that same channel to check tha [14:01] t [14:01] you need free devices to run the test and a setup that actually runs it ... and that needs to be hooked into the build process [14:01] dholbach: so the solution is what ogra_ says, a third channel [14:02] ok [14:02] while there are build process/promotion process changes needed, these are the last bits, we first need working infra to hook into [14:02] dholbach: but given how hard it is to change the backend, this isn't a one day operation (why that is I don't have the answer for ;-) ) [14:03] ogra_, would it be possible to take the same image and boot it in kvm or something beforehand? === alan_g|lunch is now known as alan_g [14:04] that would tell you the x86 kvm image works, yeah [14:04] but wont tell you much about the armhf $device one [14:04] hum, right [14:04] our emulation in touch is to far off from the actual devices === tedg is now known as ted [14:10] anyone know how to recover after upgrading to #82 from devel-proposed on krillin? [14:11] i flashed to #81, which seems to fail [14:11] doesn't even try booting [14:13] kenvandine: can you use ubuntu-device-flash to go back to 81? [14:13] nope [14:13] that's what i did [14:13] ubuntu-device-flash --channel=ubuntu-touch/ubuntu-rtm/14.09-proposed --revision=81 [14:13] just get the warning screen that i have to use a PC to restore the phone [14:13] like that? [14:13] erk [14:13] dunno, sorry. [14:13] :( [14:14] might have to --wipe and lose stuff [14:14] yeah... can't do that right now [14:14] or don't want to [14:14] popey, was bug 1413986 for you on vivid or rtm? [14:14] bug 1413986 in Ubuntu HTML5 UI SDK "First launch of a HTML5 app doesn't work, second one does" [High,Confirmed] https://launchpad.net/bugs/1413986 [14:14] dholbach: rtm [14:14] it's currently my daily driver... don't want to set it all up again right before the weekend [14:14] kenvandine: fwiw, I rsync my entire home off the phone daily to another machine as a backup [14:14] must be a way to get it booting again [14:15] you may be able to adb pull your home directory when in recovery mode [14:15] popey, do that restore all your accounts nicely? [14:15] and wipe and put it back [14:15] yeah. [14:15] everything worth keeping is in /home [14:15] and all my music is on an sd card. [14:16] thanks popey [14:17] so utopic [14:21] Hi .. I have a question about this slide: https://docs.google.com/presentation/d/1-OcIOjMSdiLI6JdBbuhobKkxdZRaaggeA-eSOoA5cnE/edit#slide=id.g3910e7ce9_2_31 [14:22] can we assume that when we talk about "Android layer" in the image is the "Ubuntu middleware block" ? === dandrader|afk is now known as dandrader [14:22] kenvandine: krillin is your daily driver? On edge? :-P [14:22] sergiusens, yes... sad panda [14:22] sergiusens, but... i wanted to use it as much as possible [14:23] and... [14:23] kenvandine: so go into recovery and ... [14:23] voice calls suck on mako [14:23] or andoird part is in the HAL ? [14:23] kenvandine: really? [14:23] my wife feels like she's talking to a machine when i use it [14:23] yeah... pulseaudio bug i think [14:24] kenvandine: ok, in recovery tar up /data/system-data/ and /data/user-data/; that's all your data [14:24] l3on: yes [14:25] kenvandine: --preserve-permissons and all that [14:25] l3on: the android layer is the bit broken out on the right [14:26] popey, but .. there I read "Network Manager" .. I thought that part was only Ubuntu related, no the Android one ... [14:27] anyway .. I assume that the adroid layer is in "Ubuntu Middleware" block [15:18] mardy: hi. do you know how to force the permission denied error when accessing account credentials, on rtm, without signon-apparmor-extension? [15:21] dobey: some operations will fail if the ACL is empty, but now I'm not sure of which [15:23] dobey: if you don't care about messing up your accounts, you could run a "DELETE FROM ACL;" in ~/.config/signond/signon.db [15:25] alexabreu: ^^ [15:33] oh doh [15:33] not alexabreu [15:33] alecu: ^^ [15:34] :) [15:34] great === alexabreu is now known as alex-abreu [15:38] dobey: after deleting all the ACLs, pay-ui still works perfectly in rtm [15:42] mardy: ^^ any other ideas? alecu isn't confident about landing my branch in rtm, without being able to recrete the error there :-/ [15:48] dbarth: the seed change for the apparmor extension, is it in a silo? [15:50] mardy: we're adding it back into rtm? [15:50] dobey: sure [15:51] dobey: if it's something siloable, it would be nice to land it together with your fix [15:51] dobey: if not, then I think that alecu should just verify that there are no regression with your changes, and maybe verify that they fix the issue when the extension is installed [15:52] i think it might not be available to install in rtm at the moment [15:52] but the exact same changes are already verified/landed in vivid [15:52] and it does fix it there [15:52] dobey: it should be also in rtm, afaik [15:54] oh, so it is [15:56] mardy: what's the name of that package? [15:56] signon-apparmor-extension [15:56] popey, I've been delighted with your restraint. When I wrote the kickstarter scope I was afraid Ms. Popey was going to hunt me down. :-) [15:56] https://launchpad.net/ubuntu-rtm/+source/signon-apparmor-extension [15:56] alecu: ^^ [15:57] ted: there's a kickstarter scope? :) [15:58] popey, feeding the addiction? [15:58] yeah :S [15:58] have you seen the oatmeal kickstarter? [15:58] haha [15:58] no... no i haven't [15:58] * ted goes back into the bunker to hide from Ms. popey [15:58] https://www.kickstarter.com/projects/elanlee/exploding-kittens [15:58] its gone MAD [15:58] OMG [15:58] you should totally back it [15:59] in 20 minutes... === chihchun is now known as chihchun_afk [16:00] dobey: ok, that one *is* available to be installed. But it's not installed on rtm/devel-proposed [16:01] alecu: right, it is not installed by default on rtm currently [16:01] ok, I'll try installing it, to see if explodes like a kitten [16:05] mandel, how do we run the test update server in your check-hash branch? [16:06] kenvandine, in the middle on a long meeting, I'll get back to you asap [16:06] sorry :-/ [16:06] mandel, no worries === chihchun_afk is now known as chihchun [16:10] has anyone else noticed the gallery showing videos as being on a different day from picture, when they are taken at the same time? [16:23] mardy: nope; it's on ogra's radar [16:23] mardy: i have a merge prop here https://code.launchpad.net/~dbarth/ubuntu-seeds/ubuntu-touch.utopic-signon-apparmor-extension/+merge/247315 [16:24] dbarth, after my last meeing (in ~1.5h) i'll prepare a PPA with the piled up seed changes [16:32] rsalveti, https://bugs.launchpad.net/ubuntu/+source/ubuntu-download-manager/+bug/1413584 [16:32] Launchpad bug 1413584 in ubuntu-download-manager (Ubuntu) "Should refuse download if it would leave an unsafely low amount of free space" [Undecided,New] === dandrader is now known as dandrader|lunch [16:33] jodh, during a review of the user-session logs we just noticed that we seems to get gigantic logs from some apps ... is there any switch we could set to globally turn off logging for the upstart session ? [16:35] ogra_, We could set console none for the application jobs… but it seems we want *some* logs, no? [16:36] ogra_, we were just discussing https://bugs.launchpad.net/ubuntu/+source/logrotate/+bug/1385464 [16:36] Launchpad bug 1385464 in logrotate (Ubuntu) "logrotate fails to run, if status file is corrupt (logrotate running during reboot?)" [Undecided,New] [16:36] ogra_: coincidentally, I just mentioned this to pmcgowan... if someone could sync ./debian/user-conf/logrotate.conf from lp:ubuntu/upstart to the upstart package used on touch, you'll suddently find that ~/.cache/upstart/ shrinks a lot! (see bug https://bugs.launchpad.net/ubuntu/+source/logrotate/+bug/1385464) [16:37] ted, why would we ... i think we would like some automation "app has crashed once, then switch on logging" ... for apps that behave we dont want to write more to disk than actually needed to have the app running [16:37] ogra_: pmcgowan: I had ~38M of log files and with the updated logrotate upstart job that dropped to 3.5M. [16:37] joi have 563M [16:38] jodh, ^^^ [16:38] the gzipped ones are all below 200k ... [16:38] ogra_, I'm not sure that we can be fine grained to say "this app vs. that app" so it's kinda a global on/off for all apps. [16:38] ogra_: pmcgowan: it's still not clear _what_ is actually corrupting thte logrotate status file, but the latest ./debian/user-conf/logrotate.conf detects it and forces a logrotate. [16:38] the unzipped ones that are actually in use go up to 80M [16:38] ted, yeah, thats more "future thinking" [16:39] jodh, when [16:39] ogra_, I'm sure systemd has six options for it :-) [16:39] jodh, my unity8 log for the current session is 80M [16:39] ogra_: wowzers! :) [16:39] it prints a few lines for every gesture [16:39] or touch ... [16:40] Someone needs to port g_debug()'s disable/enable logic to qDebug() [16:40] mandel, ok, i installed your branch and updates work :) [16:40] ogra_: can't we get that toned down a bit? constant i/o like that??? [16:40] other session jobs look similar ... not *as* big ... rather in the 10-20M but still [16:40] mandel, but i'm not sure how to verify it did a check [16:41] kenvandine, exactly, I have t give you the instructions to make it fail and see the error, sorry, in the meeting [16:41] I'll write a comment in the mr [16:41] jodh, thats another issue, indeed we shoudl tone that down, but i thing we shoudl generally turn off all logging on production devices [16:41] *think [16:41] mandel, np, just letting you know where i'm at [16:41] Cimi, any progress on the wizard? [16:41] ogra_, You should just switch to mint. [16:41] lol [16:41] mint touch :) [16:41] i would never do homebanking on mint ! [16:41] just syin ... [16:42] *sayin [16:42] :) [16:42] ogra_, Stop saying that, you're going to get another set of articles written ;-) [16:42] hahaha [16:42] ogra_: so can you confirm your logrotate status file is corrupt? (vi ~/.cache/logrotate/status, jump to the end and look for the control chars/nulls) [16:43] yep, i see a lot of ^@ [16:43] ogra_: yup - you're affected then :) [16:44] jodh, but even with it working it will only kick in if i restart the session or an app, no ? [16:44] ogra_: a manual 'start logrotate' should force a recompress. [16:44] ideally i would *never* do that [16:44] unless i get an image uipgrade that forces a reboot [16:45] pmcgowan, So my concern with turning all logging off would be that we *will* have access to those logs on automatically uploaded bug reports. [16:45] ted, with a crash you mean [16:45] pmcgowan, Correct [16:46] jodh, no changes ot the file [16:46] ogra_, I believe it also happens by cron, but wasn't happening because of the bad config. [16:46] ted, then we need better smarts somehow [16:47] ogra_: yes, unless we arrange for the :sys:rotate-logs event to be emmitted regularly. I had proposed to rotate hourly way back when, but was shot down as we could then rotate useful logfile out of existence. [16:47] ted, feel free to comment ont he bug [16:47] ogra_: there is also this awful hack (but it works :-): https://code.launchpad.net/~jamesodhunt/ubuntu/trusty/upstart/periodic-logrotate/+merge/202434 [16:47] phablet@ubuntu-phablet:~$ du -hcs .cache/upstart/ [16:47] 563M .cache/upstart/ [16:47] phablet@ubuntu-phablet:~$ start logrotate [16:47] logrotate stop/waiting [16:47] phablet@ubuntu-phablet:~$ du -hcs .cache/upstart/ [16:47] 563M .cache/upstart/ [16:47] no change [16:48] ogra_: try deleting the status file and re-running then. [16:48] ok [16:48] aha [16:48] seems to do something, prompt didnt return [16:55] ogra_, whats the verdict, I added rtm tasks to that logrotate bug [16:55] phablet@ubuntu-phablet:~$ du -hcs .cache/upstart/ [16:55] 45M .cache/upstart/ [16:55] a lot better now [16:55] pmcgowan, we need to run logrotate daily ... [16:55] there should be a cron job for this [16:55] iirc [16:56] ogra_, I thought we do but the corrupt file blocked it, or did I misunderstand [16:56] while i personally would prefer to switch off logging completely to get rid of the IO it seems everyone is shocked when i suggest this [16:56] pmcgowan, right [16:57] ogra_, can you take that bug then? [16:58] pmcgowan, if you can wait til snappy leaves me any time to work on phone bugs :) [16:58] sounds like no :( [16:58] rsalveti, ? [16:58] well, i can take it, but i cant promise it will be fixed before final [17:00] I think we should grab the fix, unless we dont think the files will get corrupted now [17:00] yeah, better safe than sorry [17:01] i think we should only log when in developer mode [17:01] the logging for end user devices is useless [17:02] kenvandine, It isn't useless when they're attached to crash reports. [17:03] kenvandine, ++ [17:03] i guess... but are we going to be able to do anything useful with the data in those crash reports? [17:03] kenvandine, Fix bugs? :-) [17:03] ted, ideally :) [17:03] ted, but they arent [17:04] until we have such a feature they should be off [17:04] the other issue is that generating the crash reports locks the phone up, users wont understand [17:04] yeah [17:04] as much as i would like automatic and useful crash reports [17:04] we'll just plaster your screen with popups like on the desktop [17:04] ogra_, For applications, not yet, but for everything else it works great. [17:04] :) [17:04] i think unless we are prepared to really manage that it isn't useful [17:04] yeah [17:04] we need tooling and automation to mine the data [17:05] totally with you on that [17:05] and identify items we should drill into [17:05] otherwise... it's going to just be noise [17:05] planning that sounds liek a great topic for the next sprint [17:05] I use it all the time... [17:05] indeed [17:05] but til we have this we should turn it off [17:05] ted, i think you are the only one :) [17:05] i look at it from time to time too [17:06] but it's a bit overwhelming [17:06] people that are debugging will actually knwo how to turn it on ... if not we should make sure to properly document it [17:06] and when you see a crash that looks common, it isn't trivial to look for patterns like which device, build, etc [17:06] so i think if developer mode is enabled, we log and file crash reports [17:07] kenvandine, Haven't done that personally (hasn't been useful) but bdmurray can get you access to the DB. [17:07] kenvandine, Folks have done reports like that. [17:07] For instance you can now list by device image. [17:07] what i want is some robot to tell me what to look at :) [17:07] kenvandine, Until we have that, we'll have to settle with managers ;-) [17:08] some intelligence that sees a pattern and raises awareness of common crashes [17:08] Yeah, we don't get that with managers ;-) [17:09] kenvandine, Last I talked to ev about this he was working on setting up an analytics system on the errors db. I think that got sidetracked though. [17:10] yeah [17:10] ev has some great ideas [17:10] You should talk to your CI stakeholder :-) [17:10] and i really look forward to seeing this become useful [17:10] all I'm going to say is that if you use the phone, crash reports suck as they just block your device [17:11] sergiusens, Crash reports on U8, or all? [17:11] ted: any crash report that is non recoverable [17:11] Hopefully that is sufficiently rare? [17:16] ted: I don't know anymore, I disabled crash reports since they just kill my battery life [17:17] * sergiusens already requested for crash reports to be processed only when plugged [17:17] well, i really like that we have statistics for crashes apps on errors.ubuntu.com [17:18] if every developer would regulary check this page we would actually get benefit from the reports [17:18] but since only very few people do that i think crash reports are moot atm [17:21] ogra_, I guess the question would be how could we get more people checking them? [17:21] ted, dunno, when did you check it last ? [17:22] for me that was last year [17:22] ogra_, For me it was the beginning of this week. [17:22] its a personal habit ... not sure we can force people into usin it [17:23] Force no, more visible, perhaps. === chihchun is now known as chihchun_afk [17:23] yeah [17:24] Or I guess make it part of the project management culture. [17:24] ogra_, ted I asked for filtering by channel and device on that page [17:24] right now its hard to sort it out [17:24] i wanted to make it a daily task of the landing team a while ago ... but the landing team already has to check so many stats and error pages [17:24]