[01:06] cyphermox_, buh, spreadsheet is borked again [01:54] robru: ah you guys already on the spreadsheet issue.... [01:55] sadly my build succeeded but no ppa ...guess the spreadsheet does the copy [02:05] robru: looking... [05:21] davmor2: ask the multimedia team to land qt 5.2 support :) === bfiller is now known as bfiller_afk [07:49] anyone else see bug 1280124 ? [07:49] bug 1280124 in linux-mako (Ubuntu) "kernel log getting spammed every 10s with battery notifications" [Undecided,New] https://launchpad.net/bugs/1280124 [08:07] Mirv: thank you for the handbook ;) [08:11] Mirv: you are back next Monday, right? [08:11] sil2100: you're welcome :) [08:11] sil2100: yes, 24th [08:16] didrocks: morning! [08:16] morning [08:16] Oh god... google's doing it again it seems [08:17] didrocks: I see a lot of ERROR fields in our spreadsheet, tried manually re-running syncstatus and it failed with an error ;/ [08:17] ah [08:17] not sure, no time to debug it [08:17] * sil2100 is afraid again [08:18] seems that already some packages could be published [08:18] Yes, I'll try publishing something and see if it unblocks and/or works [08:19] anybody to reconfig silo5? [08:20] thostr_: I can, in a moment [08:28] didrocks: sil2100 FYI, dogfooded 182 and it's good - only one bug filed bug 1280124 [08:28] bug 1280124 in linux-mako (Ubuntu) "kernel log getting spammed every 10s with battery notifications" [Undecided,New] https://launchpad.net/bugs/1280124 [08:29] popey: can you try 181, seems we won't ever have results on maguro for 182 [08:29] maybe a quick debug then :p [08:29] and nobody in the CI team is able to rerun them as psivaa isn't around and vila doesn't know the procedure [08:29] asac: FYI, we do have a gap ^ [08:30] Bah [08:30] I specifically did these early because I have lots of other things to do [08:30] popey: sorry, or we can say "discare maguro". Anyway, nobody is fixing the flaky tests [08:37] didrocks: we have nobody in eu timezone who can manage CI? [08:37] didrocks: packaging ACK - http://162.213.34.102/job/landing-008-2-publish/lastSuccessfulBuild/artifact/packaging_changes_address-book-service_0.1.0+14.04.20140213-0ubuntu1.diff (new deps) [08:37] popey: apparently not with psivaa away [08:37] That seems sub-optimal. [08:37] it is [08:38] like in image 181, we will never know if the unity8 new failures are legit or not [08:38] I'll just disregard them [08:38] * didrocks is tired to be the only one pushing [08:38] sil2100: +1 [08:39] * sil2100 tries debugging google scripts [08:39] But so far it seems to be the same absurd thing like a few days ago [08:39] sil2100: you sohld rather publish what can be published I guess [08:39] http://paste.ubuntu.com/6930076/ ffs [08:39] I would call this a server-side issue, my RT is still not answered [08:40] popey: mtp restarted in between? [08:40] possibly [08:40] * popey retries [08:40] didrocks: yes, but the spreadsheet doesn't update when things are published [08:40] sil2100: ah… [08:41] didrocks: I'm afraid that it would lead to confusion once I do that ;/ [08:41] at least i have office wired internet on my side [08:44] sil2100: last edit -> 8 hours ago [08:44] so same issue [08:44] my RT is still unanswered anyway [08:45] didrocks: I noticed something strange though [08:46] didrocks: refreshSiloStatus() seems to work for the first rows - it goes through those correctly, updating the status as needed - then suddenly around row 27 it failed [08:46] didrocks: oh [08:46] didrocks: ok, it came back to life ;p [08:47] * didrocks still sees #ERROR [08:48] sil2100: reconfigured? [08:49] didrocks: right, ERROR is back... and now I can't even scroll the bottom sheets since instead of the < > I have 'try out new google spreadsheets' [08:49] thostr_: I'll try it now, we have sheet issues [08:49] didrocks: 181 taking an aaaaaaaage to first boot as it does apparmor stuff [08:50] popey: I didn't see an apparmort change between 181 and 182 though [08:50] well, I'm going backwards from 182 to 181 [08:50] finally done [08:51] thostr_: reconfigured [08:51] sil2100: thanks. silo 11 is ready for publishing [08:53] thostr_: saw that, let me publish, seems like the first few rows can be published safely even when those google problems appear [08:53] sil2100: great [08:57] odd issue with 181 [08:58] if i tap the power button, I never get back to the welcome screen [08:58] and if i hover my hand over the light sensor, it's like the phone is on a call, the screen dims [08:59] popey: weird, I would have said it's due to Mir [08:59] but I don't see anything to fix it in 182 [09:00] * popey reboots [09:01] fine after a reboot [09:01] ⍨ [09:02] http://popey.com/~alan/phablet/device-2014-02-14-090226.png [09:02] check out that battery drain [09:03] although with no scale on either axis the data is somewhat meaningless [09:07] didrocks: two additional packaging diffs in a moment, these are a bit big so I'm trying to figure them out completely [09:07] thostr_: you know what's up with all that 'lets remove libubuntudownloadmanager1' ? [09:09] sil2100: no, i'm confused there as well [09:10] good morning [09:11] Morning [09:11] sil2100, hey there, can I get a silo for l. 34 in the ci train spreadsheet? [09:12] tvoss: let me check [09:12] didrocks: done dogfooding 181 [09:12] popey: all good after this reboot? [09:13] tvoss: hm, might be a problem with that, since the spreadsheet seems to be encountering some google-infra problems and the lower rows of it seem a bit brokish [09:13] yes [09:13] (like your graph btw) [09:13] thanks popey [09:13] sorry you had to redo the testing [09:13] np [09:13] sil2100, working fine here [09:14] tvoss: you don't see any ERROR fields? [09:14] sil2100, nope [09:19] thostr_: ok, so, the packaging doesn't seem right [09:20] thostr_: I don't think we can release silo 11 for now [09:20] thostr_: the thing is, the u-d-m version there adds all the 'breaks' and 'replaces', but it adds them according to a version that was not released into ubuntu [09:21] thostr_: so, if you consider this package and the one in Ubuntu, it's breaking and replacing non-existent packages, and not dealing with the ones that are actually in Ubuntu ;) [09:22] thostr_: let my try talking to mandel about this [09:22] sil2100: mhhh, I think I don't understand ;) [09:23] sil2100: I just added this package to ci, and this shouldn't have changed anything to my understanding [09:23] so the problems have been there before? [09:24] or did mandel and co not release any recent version of u-d-m for a long time? [09:24] thostr_: so, it for instance states that it breaks package ubuntu-download-manager-common1, while ubuntu-download-manager-common1 does not exist in the archive anywhere ;) As this binary package was never built in the archive [09:24] thostr_: I think it's the latter indeed [09:27] sil2100: is mandel online yet? [09:28] can somebody check why J doesn't pick this up? https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/fake_app_fixture/+merge/205916 [09:28] Morning all [09:28] mandel: ping, could you poke me once you're up? [09:28] kalikiana: you mean, for automerging? [09:29] kalikiana: there's no automerger anymore for projects using CITrain ;) [09:30] sil2100: I didn't think we were switched yet since the training is expected for monday [09:30] we don't have the test plan set in stone either [09:30] kalikiana: I think you're switched already since we already made one release using CITrain [09:31] kalikiana: at least a silo was prepared [09:31] k, I'll poke around in the team [09:31] Ok ;) [09:40] didrocks: packaging ACK, seems ok: http://162.213.34.102/job/landing-012-2-publish/lastSuccessfulBuild/artifact/packaging_changes_mediaplayer-app_0.20.5+14.04.20140213-0ubuntu1.diff [09:41] asac, didrocks: I noticed Maguro is running slower with nested mir and the newer mirs. So it might be that the device is locked up/crashed or just timing out. It might be sensible to concentrate on landing the 4.4.2 stuff and dropping the maguro sooner rather than latter. Just a thought. [09:42] tsdgeos: ^ [09:43] sil2100, I cna give you a hand with those [09:43] can* [09:43] sil2100, let me grab a cup of tea and we can do a hang out, sounds right? [09:44] \o/ Tea [09:44] sil2100: +1 [09:45] mandel: sure ;) [09:51] didrocks: found that silo 009 is *probably* ready for release, will try publishing it then [09:51] sil2100: ok [09:51] sil2100: please update with comments on the main spreadsheet [09:51] sil2100: mandel: could you forward the hangout link? [09:51] didrocks: too bad the backend doesn't have the 'Testing: Yes' info, as it's frontend only ;) [09:51] yep [09:51] sil2100, thostr_ https://plus.google.com/hangouts/_/76cpjc6h5o6i7sn5mtls4anf1k?hl=en-GB [09:51] mandel: be there in 5 minutes [09:52] sil2100, didrocks I'm trying to maintain the symbol files in dbus-cpp but I don't think that the amount of effort I/we have to put into it is reasonable [09:53] tvoss: how are you maintaining them? [09:53] sil2100, manually? [09:53] it's working for quite a lot of upstreams have stable ABIs though [09:54] didrocks, sil2100 you might remember that I had to switch to a different compiler version last week, and this is just not doable [09:54] didrocks, sil2100 again, I don't think we should assume api or abi to be stable for certain components or alternatively not force things into main [09:54] you should try to get help maybe from doko to reswitch to the latest get all symbols in place again [09:55] tvoss: so, in that case, you should bundle everything using that non stable apis in the same source [09:55] no need to separate things if you can't maintain clear boundaries [09:55] but we already had this discussion too many times I guess [09:56] didrocks, so you are effectively saying we shouldn#t share code? interesting pov [09:56] didrocks, well, we don't find a resolution [09:56] tvoss: if you want to share code, define an API and try to stabilize it [09:56] didrocks, you are off reality here [09:56] didrocks, my 2 c [10:00] didrocks, I just checked boost 1.55, unity-mir and a few other c++ packages. None of them has symbol files. Mind elaborating? [10:00] sil2100, ^ [10:00] tvoss: unity-mir is an issue, we should add it, not sure for boost, check with the maintainer [10:02] didrocks, I guess I'm asking for the policy here that is not clear to me [10:02] tvoss: it's really hard to do with C++ code, could you show me the current state of the symbols files that you tried preparing? [10:03] sil2100, it's your branch that I took and mp'd [10:03] tvoss: packages in main should have a symbol file to track (but that doesn't cover everything) ABI breakage, or we should ensure upstream really knows what they do and bump the soname at every breakage [10:03] didrocks, which I'm happy to do [10:03] didrocks, symbol files are just not an option from my pov at this point [10:04] sil2100, https://code.launchpad.net/~thomas-voss/dbus-cpp/force_gcc_4.7_and_symbols/+merge/206359 [10:04] tvoss: if you are doing the testing manually and rebuild everything yourself in your slot each time you break ABI, I guess that's fine. I think to avoid having you testing everytime manually, you should at least have some integration tests to detect breakages between your different components [10:05] didrocks, that is what the ap tests are for, aren't they? system-level integration tests that catch abi issues and such [10:05] tvoss: geh, crap, let me look into what's up there [10:05] tvoss: yeah, we need those though for location and so on. There is none AFAIK [10:06] didrocks, sure, let me just point out that we never suffered any functional regression or abi breakage with either dbus-cpp or location service. It was a compiler version mismatch that caused trouble in the end [10:07] tvoss: yeah, but dbus-cpp was rebuild against that compiler version mismatch which created issues on location-service [10:07] and that was uncatched [10:07] tvoss: ok, now this is something absurd, I wonder what dpkg-gensymbols does there on that jenkins machine since it doesn't make sense what I see [10:09] didrocks, you couldn't have detected the issue even with the symbol files in place as we learned last weeek [10:09] sil2100, yup, I actually lost track what is causing the issue [10:09] sil2100, stuff works fine locally, I send it off, it breaks [10:09] tvoss: yeah, but with AP tests, we would [10:10] sil2100, please take a look => https://code.launchpad.net/~mandel/ubuntu-download-manager/fix-packaging/+merge/206377 [10:11] didrocks, that's a different statement than saying you have to maintain your symbol files, both semantically and in terms of time and effort [10:11] tvoss: come on, I told that if no symbol file, I'm happy if he had a way to detect ABI breakage [10:11] and AP tests would be one of them [10:11] but it seems we would have none if we remove symbols [10:11] tvoss: normally I would check if it builds in a PPA and then land it if all is OK, but this would basically mean we won't have CI working for dbus-cpp ;/ I'll try to investigate with Francis later I guess [10:12] Since this seems to be somehow related to the CI setup [10:13] didrocks, sil2100 I'm quite confused now: we did the archive upload without a symbols file and both of you were adamant about having a symbols file for the next regular upload, which is why sil tried to help, too [10:13] tvoss: right, as long as we don't have AP tests covering/using your code [10:13] didrocks, at least I wasn't aware of that. sil2100 ? [10:14] tvoss: it's one of the other, the function I want is "be able to detect ABI mismatch" [10:14] sil2100, I need to go for a few mins to try and fix my laptop or find another machines, will me back in 20 mins or so.. :-( [10:14] we know symbols won't cover it 100% and that AP won't cover it 100% either, but at least we need one of the 2 [10:15] sil2100: I saved the backend script and the issue is gone [10:15] on the spreadsheet [10:15] :O [10:15] sil2100: removed your comment [10:15] mandel: thanks! [10:15] uh oh, indeed it looks fixed [10:16] sil2100, awesome, let me know in a few mins to make sure :) [10:16] didrocks: I still ahve the 'last edit 10 hours ago' though [10:16] sil2100: same [10:18] mandel: it's building now ;) [10:21] Ouch [10:21] didrocks: Exception: ['sudo', '-E', 'cowbuilder', '--execute', '--bindmounts', '/srv/juju/vol-0000011d/var/lib/jenkins/silos/landing-011', '--bindmounts', '/var/lib/jenkins', '--', '/srv/juju/vol-0000011d/var/lib/jenkins/citrain/chroot-tools/buildsource-chroot', '/srv/juju/vol-0000011d/var/lib/jenkins/silos/landing-011/ubuntu-download-manager', '--gnupg-parentdir', '/var/lib/jenkins', '--uid', '106', '--gid', '65534', '--gnupg-key [10:21] link? [10:22] http://162.213.34.102/job/landing-011-1-build/19/console [10:22] Link wink wink [10:22] apt-get: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory [10:22] above [10:22] so yeah, setting up the rootfs failed [10:24] "apt-get: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory" O_o (https://launchpadlibrarian.net/166268254/buildlog.txt.gz) [10:24] Mirv: woha! Same error I had? [10:24] didrocks: haha, without reading backlog! [10:24] didrocks, cf #ubuntu-devel [10:24] sil2100: yeah, I didn't read backlog and just pasted what seemed really weird for me elsewhere [10:24] Mirv: ahah, thanks for not stopping at the last line :p [10:24] sil2100: it's a distro issue [10:24] right, what seb said [10:25] ;) [10:31] didrocks, what if we made dbus-cpp a src package? much like gmock? [10:31] tvoss: I thought you wanted to share it. So I would prefer if you don't want to maintain ABI, that we use AP tests to detect a failure [10:31] cihelp: ev: can anyone help resurrecing mako tests? [10:32] err mako devices [10:32] didrocks, it's not that I don't _want_ to maintain ABI, it's a question of time and resourcing [10:32] tvoss: so AP tests I would say [10:35] didrocks: I am done with the silo tests [10:36] bzoltan: so, everything pass? no tests failing? [10:37] didrocks: I give you the list of tests I run ... the notes tests are unreliable (2 fails out of 5) [10:39] * didrocks waits for the link :) [10:42] didrocks: http://pastebin.ubuntu.com/6930475/ [10:42] didrocks: but the notes were fine after all [10:43] ev: so, asac is telling me that there is someone that can rerun the unity8 from your team? [10:43] test* [10:43] bzoltan: hum, I see no unity8 and a lot of tests are missing compared to the dashboard [10:43] bzoltan: not sure about your skip, it doesn't fail on the daily smoke testing for ubuntu-keyboard and such [10:44] bzoltan: I guess you tried on mako, you can refer to http://ci.ubuntu.com/smokeng/trusty/touch/mako/181:20140213.3:20140115.1/6579/ [10:44] didrocks: I skipped everything what failed on a stock image [10:44] bzoltan: they don't fail in what we run everyday though [10:44] see the link above [10:45] didrocks: did you rune from CLI on your machine or you just look at the levitating spacecraft with jedi engineers around it? [10:45] you ran 13 test suites instead of 27 [10:45] bzoltan: we did run them ourself for your release for the past 8 months [10:46] didrocks: I would loooooove to get my dirty fingers on the script you use. Why I can not run the same? [10:46] bzoltan: the landing team is running the APs all the time [10:46] unity etc. are now runn by kgunn and friends more often [10:46] bzoltan: the script that the CI team is using is part of the wiki page that you got linked to [10:46] asac, didrocks: is there any reason why I can not see the exact same script what you use? [10:47] didrocks: this one -> https://wiki.ubuntu.com/Touch/Testing ? [10:48] bzoltan: they run the phablet-test-run command; there is no single script [10:48] asac: guys ... we went thru this already [10:48] bzoltan: however, as i told you, ask folks and update wiki with missing details [10:49] Mirv: can you tell bzoltan how we run APs? [10:49] sil2100: ^^ [10:50] Mirv: sil2100: he says he cannot reproduce a green dashboard [10:50] asac: you still think that "I hold it wrong" right? :) [10:50] bzoltan: i am not thinking anything [10:50] bzoltan: all i see is that i connected you to ogra [10:50] and didnt hear any further complains yesterday [10:50] and you made good progress [10:51] Ok [10:51] asac: I do not complain ... I run the tests... the very same tests I got from Mirv and some of them failed on the stock 181 image ... so I skipped them from the testing of the UITK silo [10:51] bzoltan: i am thinknig you are not working well with the team ... you seem to try to solve things on your own and then ignore them rather than reaching out for help [10:51] bzoltan: yeah, dont skip them [10:51] bzoltan: uitk is central enough that we cant leave any gap open [10:52] its actyally the most central compnoent we have with potential for regressions [10:52] asac: I need 5 minutes f2f with yoou [10:52] sure [10:52] bzoltan: the smoketesting we do actually runs on normal hardware and uses phablet-test-run as well, so it shouldn't fail when ran on the local device ;) This might mean something's wrong [10:52] asac: yes I told bzoltan my method yesterday. I think he's actually running some extra tests that are not on the dashboard. [10:52] asac: https://plus.google.com/hangouts/_/calendar/em9sdGFuLmJhbG9naEBjYW5vbmljYWwuY29t.g04rj4pc565qsh6humb980bt1k [10:52] Mirv: bzoltan: cant you guys just solve it here? [10:53] i really would prefer to be not involved at all [10:53] We're reverting libgcc1, will be sorted soon [10:53] thanks cjwatson [10:53] yay [10:53] cjwatson: thanks! :) [10:53] asac: you are involved [10:53] bzoltan: i have no permissionm for that HO [10:53] asac: as far as I understood everything but notes was already passing now, so it seems it starts to be in order aside from finding out what's wrong with running those tests. I suggested removing /home/phablet/autopilot and rerunning. [10:54] asac: invitation posted [10:55] bzoltan: i am not allowed still [10:55] killed plugin etc. [10:55] bzoltan: https://plus.google.com/hangouts/_/canonical.com/alexander [10:55] try that one [10:55] asac, are you logged in anywhere with your private G+ account ? [10:55] in a HO? [10:55] hangouts dont work anymore if you are [10:56] no, in G+ anywhere ion the same browser [10:56] * ogra_ always has to log out in all tabs where he has his private account in use to use HOs [10:56] (as long as they were started with a company account) [11:00] didrocks: to highlight my point I just closed the click app I installed and the phone is locked [11:00] huh [11:01] davmor2: so maguro is in a bad state on 181? [11:01] smells like it doesnt like the new Mir [11:02] didrocks: no just slow it will unlock again in minute....talking of which [11:02] ogra_: that nexus 7 i flashed yesterday.. can I OTA update it? [11:02] davmor2, can you take a look at top and see if there is any swapping [11:02] davmor2: ok, apart from that, all good? [11:03] popey, once we have official images you will be able to (you need to do it once from the cmdline with system-image-cli to initialize) [11:03] didrocks: yeap good, but that could easily explain why it is dying during autom ation [11:03] ah okay [11:03] davmor2: indeed [11:03] thanks ogra_ [11:03] popey, OTA needs the images on the server indeed :) [11:04] asac: kgunn: I guess we need to take a decision today on maguro (new Mir slowing it down a lot) [11:04] ogra_: give me a minute I'll run top and open and close some apps and see if I can get it back into that state [11:06] ogra_: makes sense when you say it out loud ☻ [11:07] Mirv: have time? [11:08] asac: I haven't had lunch and it's over 1pm, otherwise yes [11:08] so the answer is I guess "depends" :) [11:10] Mirv: can you come now in a HO? [11:10] asac: ok [11:10] https://plus.google.com/hangouts/_/canonical.com/alexander [11:11] Mirv: https://plus.google.com/hangouts/_/canonical.com/alexander [11:11] tvoss: ^^ [11:11] i am in there [11:11] ogra_: ^^ [11:12] didrocks: it seems the spreadsheet works, but I still get the "Ooops" message every time I update some cell... [11:12] didrocks, ogra_: that would explain it. ubunut-loc I'm assuming ubuntu location is using 92% cpu [11:13] davmor2, ouch [11:13] asac, gimme a sec, need to go back to the office [11:13] didrocks: really worrying, but at least it doesn't seem broken completely [11:14] davmor2 again? :/ [11:14] davmor2: ok, can you try to revert what enter in that image one after another? [11:14] What the hell [11:14] davmor2: reboot and look at top again [11:15] didrocks, ogra_: 845 root 20 0 115136 6856 5292 S 101.8 1.0 23:00.74 ubuntu-loc+ [11:15] davmor2: you didn't have that on the last image? [11:17] sil2100: the whole device is slower with nested mir but running the location stuff just doesn't help. [11:18] sil2100: can you help davmor2 to bisect the image, removing one by one what was new on the last images? [11:18] didrocks: ACK [11:18] thanks [11:19] didrocks, sil2100: so no top is looking much healthier. [11:25] didrocks: so even with location off now I would say that maguro is 10-20% slower than it was, without opening an app just moving around the unity scopes and scrolling. [11:25] but now it is flashing las t promoted : [11:25] ) [11:25] Yeah ;) [11:25] didrocks: we want to try last promoted image as a starting point [11:26] why doe sit take 3 years to flash maguro [11:27] biab [11:29] sil2100: sounds good [11:39] davmor2: I wonder if the same was happening in the image before we upgraded Mir, i.e. 2 images ago [11:39] FYI a more completely commented version of how I do testing: http://pastebin.ubuntu.com/6930701/ [11:40] davmor2: since this seems like the problem we had before, and platform-api is a dependency of location-service - maybe another gcc mismatch? [11:41] Looking at the build logs [11:47] davmor2: doesn't seem so [11:47] At least not gcc [11:49] didrocks: http://162.213.34.102/job/landing-010-2-publish/lastSuccessfulBuild/artifact/packaging_changes_camera-app_2.9.1+14.04.20140213-0ubuntu1.diff <- unity8-ap dep addition and icons for desktop, safe [11:50] sil2100: +1 [12:00] davmor2: did it downgrade already? [12:02] didrocks, sil2100: hum, I added a line to CI train this morning that vanished since, do you know what happened? [12:03] seb128: maybe the google issue [12:03] should I just add it back? [12:03] yes please [12:03] interestingly, I still had it before I refreshed the page [12:04] shrug [12:04] I noticed it's still failing a bit in syncing properly [12:04] got an oops again [12:04] grrr, another oops [12:05] seb128: yeah, that's what we are getting since this morning [12:05] well, added the lines, but 2 of the columns gave me oops errors [12:05] line [12:05] thanks seb128 [12:05] seb128: I see it, thanks [12:06] thanks [12:14] morning [12:15] Morning [12:16] hey rsalveti [12:21] ogra_: what do I do wrong -> http://pastebin.ubuntu.com/6930884/ [12:21] davmor2: give me a sign how it goes [12:21] ogra_: nothing happens after that... not a character on the consol [12:22] phablet-config autopilot --dbus-probe enable usually takes a while to finish for the first time [12:24] ogra_: it moved :) and did something not nice http://pastebin.ubuntu.com/6930891/ [12:24] sil2100: ^ [12:25] hm, it seems to want to download the latest UITK from the archive, which he should fetch from the PPA instead [12:25] yeah [12:25] bzoltan: you have the silo PPA added on your device, right? Just in case [12:25] yes [12:25] I'm aftaid phablet-test-run might not be smart enough ;/ [12:26] Mirv,sil2100,didrocks: modulo whatever mirroring may be involved, the libgcc1 thing should be reverted now [12:26] and we're building the real fix [12:26] sil2100, ogra_: I have 0.1.46+14.04.20140212-0ubuntu1 UITK from the silo PPA [12:26] asac, ev, didrocks: mako and maguro are continuing now. Maguro had another device failure and mako was complete except for the unity8 tests didn't run to completion it seems. [12:27] plars: do we konw what stopped the unity8 tests? [12:27] great, cjwatson [12:27] didrocks: not yet, it's a bit chaotic at my house right now (getting 4 kids ready for school) but I'll be able to check on it in a few minutes [12:28] sorry it took longer than it should have done, unfortunately it collided with a battery swap on the lp master db [12:28] cjwatson: thanks :) [12:28] * sil2100 already noticed it might be reverted properly as his build job worked [12:28] plars: thanks! [12:28] cjwatson: thanks as well :) [12:29] sil2100: right I'm back now, sorry m-i-l meds time [12:29] davmor2: ok [12:31] sil2100: ogra_: Mirv: I was using the lines from Mirv and the phablet-click-test-setup --click com.ubuntu.calculator type of commands fail [12:31] bzoltan, check again that you did all of the preparation stuff [12:31] bzoltan: right ;/ I think it wasn't ready for the case of testing a new UITK [12:33] sil2100: before http://paste.ubuntu.com/6930927/ [12:33] Looking at pull-lp-source now [12:33] davmor2: ok, so try this: [12:33] ogra_: is the latest image broken because of the libgcc1? or still good? [12:33] davmor2: could you update all the mir bits on your maguro? i.e. mir packages, platform-api and unity-mir? [12:34] rsalveti, 182 looks ok on my maguro [12:34] great then [12:34] sil2100: after http://paste.ubuntu.com/6930935/ [12:34] well, at least it started, didnt play with it [12:34] davmor2: since I have a hunch that it might be the cause - especially platform-api [12:34] i think davmor2 has some speed issues [12:34] After? [12:34] davmor2: after what? ;) [12:34] ogra_: I had performance issues with mako as well [12:34] sil2100: before enabling location and after [12:35] after playing videos I could easily get the system-compositor and unity8 to fight each other :-) [12:35] rsalveti, yeah my mako stays on trusty ... no proposed for me there :) [12:35] both were consuming ~60% of my cpu [12:35] davmor2: oh, ok, thanks [12:35] davmor2: could you do the test I pointed out ^ [12:35] davmor2: with upgrading mir on the image you are on now ;) [12:35] (and all related bits) [12:35] sil2100: so you want me to just update the mir stuff right [12:35] ogra_: phablet-config autopilot --dbus-probe enable [12:36] rsalveti, bug 1279391 .... might extend into other directions too ... [12:36] bug 1279391 in Mir "[nested] inclusion of u-s-c as system comp not getting system load zero as quick as before" [Undecided,New] https://launchpad.net/bugs/1279391 [12:36] davmor2: http://people.canonical.com/~ogra/touch-image-stats/20140213.3.changes <- here you have some mir packages you can use as reference [12:36] sil2100: right will do [12:37] ogra_: yeah. ot [12:37] ogra_: it's happening here as well [12:37] ogra_: I wonder why at bzoltan's pull-lp-source doesn't use the PPA's and only looks into the archive [12:37] ogra_: or maybe it only uses launchpad tarballs and the archive? Not supporting PPA's at all? [12:38] sil2100, no, idea, to me it looks like one or more steps of the setup process are missing [12:38] bzoltan, did you run phablet-click-test-setup ? [12:38] ogra_: not really, there's just one step before this one - it's enabling dbus-probe, then everything should be done by phablet-click-test-setup --click which fails [12:38] yes [12:39] ogra_: this is output from phablet-click-test-setup --click ;p [12:39] ogra_: it is phablet-click-test-setup that is failing [12:39] sil2100, what is --click ? wiki doesnt talk about that [12:39] * ogra_ is talking about the general preparation stuff [12:39] ogra_: 04:38 < ogra_> bzoltan, did you run phablet-click-test-setup ? [12:39] I mean [12:40] ogra_: https://wiki.ubuntu.com/Touch/Testing#Running_Click_tests [12:40] right [12:40] ogra_: it says it all and it works [12:40] ogra_: http://pastebin.ubuntu.com/6930973/ [12:41] Ok guys, I need to at least take my girl for some lunch, I'll be on IRC all the time on my phone to answer questions and help bisecting further with davmor2 [12:41] i dont get why it tries to fetch the uitk at all [12:41] And be in front of a real PC in like 1.5h [12:41] ogra_: not sure as well, but it does that always [12:41] it doesnt do that here [12:41] sil2100: no rush I'll be on Lunch soon too :) [12:41] I mean, it was doing it always for me, as if it was assuming tests might need UITK autopilot elements [12:42] ogra_: since it fetches UITK source for the autopilot bits from UITK [12:42] well, let me re-flash my maguro and run the procedure [12:44] sil2100: have fun! [12:46] Mirv: thanks! Although Im here all the time, good thing for smartphones ;) [12:49] ogra_: can we work to get the x86 tarball published? [12:49] ogra_: are we always building it as well? [12:49] want to know if we need to first build it automatically or just need to publish it [12:50] rsalveti, nope, not building it at all yet [12:50] we need to add i386 to default-arches on cdimage ... then do a test build to see the fallout [12:51] ogra_: how busy are you today still? :-) [12:51] live-build is capable ... but not sure whats exactly needed in cdimage (probably even nothing) [12:51] sil2100: Mirv: ogra_: would you please ping me when you figured out how click app testing goes with Silo PPA? [12:51] * rsalveti wants ogra_'s brain [12:51] brrraaains [12:51] rsalveti, i'll try to get to it [12:51] zombies .... aaaahh ... aaah ... aaaaahhh [12:52] ogra_: awesome, let me know if you need help testing or reviewing the changes [12:52] * tvoss opens ogra_'s head and puts a candle in :) [12:52] * ogra_ sits inteh corner with a stupid grin and light coming out his eyes [12:52] rofl [12:52] sil2100: with all those from that list installed that had mir in no change location is using a max of 1% [12:55] * davmor2 hands ogra_ a shotgun and some shell to fend off the Zombie Pirate Le_Chuck (D'oh wrong story) Zombie developer rsalveti [12:55] lol [12:55] *g* [12:56] bzoltan: ogra_ sil2100: when I've tested a package treated specially by click-test-setup like unity8 and ui-toolkit, I've needed to edit /usr/bin/phablet-click-test-setup (lines 63-64) so that it won't try to wrongly download the package being tested, since it's already installed from the PPA and the script tries to download it from archives [12:57] Mirv, can we add that to the wiki somehow (or open a bug for click-test-setup to get a switch) [12:57] sure, filing a bug. [12:59] Mirv, i guess that is because the packages are also in ppa:ubuntu-unity/daily-build together with the test packages ? [13:01] asac, didrocks: ok, except for a single fail in webbrowser (I can rerun that to in a sec) mako is complete now [13:02] didrocks: unity8 was a screen unlocker failure again (seen that twice now in the last two days with various tests) [13:03] and we've killed two maguros since yesterday, rfowler will have a busy morning I'm afraid [13:03] bug #1280279 [13:03] bug 1280279 in phablet-tools (Ubuntu) "phablet-click-test-setup tries to download unity8 and ui-toolkit from main archives, failing when those are being tested" [Undecided,New] https://launchpad.net/bugs/1280279 [13:03] plars: ok, thanks for rerunning those :) [13:03] Mirv, thanks ... [13:04] bzoltan, ^^ see the bug === alan_g is now known as alan_g|lunch [13:04] Mirv, you should document your workaroudn too i guess [13:05] ogra_: yes, just did [13:05] thx [13:06] davmor hmm.. [13:12] davmor: could you try upgrade some other packages? [13:18] plars: will look at them in a bit [13:21] rfowler: thanks a lot, it's maguro 1 and 2 [13:22] plars: busted image? [13:23] rfowler: not as far as I can tell, this was on two different images and did not happen at install time (nor during the same test) [13:23] rfowler: so I'll be curious what kind of state they are in [13:23] plars: could be dead batteries again... it's about that time [13:24] rfowler: yeah, that's what I was wondering [13:34] bzoltan, does it work for you with the workaround from Mirv ? [13:35] ogra_: yes, I am executing the click tests right now [13:35] http://paste.ubuntu.com/6931185/ is my setup on a freshly flashed device (indeed not with your UITK package added) [13:35] awesome :) === alan_g|lunch is now known as alan_g [14:03] xnox, around? [14:06] ogra_: E/IMGSRV ( 1262): :0: OpenServices: Cannot open device driver /dev/pvrsrvkm. [14:06] E/IMGSRV ( 1262): :0: PVRSRVConnect: Unable to open connection. [14:06] ogra_: that is pretty much what I see after I have applied the workaround from Mirv [14:06] getting this with maguro, latest image [14:06] and it seems unity8 is not coming up [14:07] tvoss: ^ [14:07] and got a crash file for unity8 [14:07] weird [14:08] let me get some food and will check after I'm back [14:08] brb [14:08] happy Feb 14th to you all, see you in a week /me @ bus [14:09] Any body around to help figure out why the Unity 7 automerger is not working? [14:09] ChrisTownsend, it got switched to CI train I guess? [14:09] rsalveti, strange, is that 182 ? [14:10] i just did a fresh flash of my maguro and it came up fine [14:10] ChrisTownsend, yes, it did according to the table [14:10] seb128: Ok. I don't really understand what all of this new stuff is, but that's not your problem:) [14:10] ChrisTownsend, in CI world the merge back to trunk happens after upload. You do a landing requests for a set of branches, the system give you a ppa with a build of those, you test the result, if you are happy you press the button to upload to distro, once it's the release pocket the change get merged back to trunk [14:11] ogra_: would you know why if I'm flashing the recovery image /res seems to not be changed with my content? [14:11] (the rest of the code, is) [14:11] ChrisTownsend, that ensures things are driven through the image properly and not merged to trunk before being tested in production, [14:12] seb128: Ok, I see the value in that, but that sounds like distro is the new upstream. [14:13] ChrisTownsend, no, you are upstream, you are the one asking for the landing and pressing the buttons (well, you = the project, bregma in your case) [14:14] ChrisTownsend, but Ubuntu is the product we focus on yes, so the emphasis is on landing your work there [14:14] didrocks, /res ? [14:14] ChrisTownsend, it has been changed to avoid the current unity situation, where we have a backlog worth months of work, which is in trunk and not in the product [14:14] ogra_: yeah, in recovery mode [14:15] seb128: Well, I mean we can't get stuff into trunk until it's released in distro. I guess that will make intermediate releases happen much more quickly. [14:15] seb128: Any ways, thanks for the explanation. [14:15] ChrisTownsend, yw [14:16] ChrisTownsend, and yeah, ideally you would land work at least once a week, more often is good as well [14:16] didrocks, i think /res is only used for the UI animations when upgrading, what do you want to change there ? [14:16] ChrisTownsend, that way we keep getting the improvement, we have small delta to test/debug in case of issue, etc [14:16] ogra_: trying to change the animation as per design spec (hoping to do something fun for once) [14:16] didrocks, how did you change it ? [14:17] ogra_: so, I'm changing the images and the code to accept 8 images instead of 7 [14:17] can somebody give me a slot for l21 [14:17] ogra_: took the android package (will backport to git after that), change bootable/recovery/res/images with the new assets [14:17] didrocks, hmm there might be some makefile that hardcodes the names [14:17] it's a 1 line depends change in indicator-session for unity-system-settings on desktop [14:17] ogra_: well, even the old one that are erased and not in the package anymore are still in /res [14:18] if I adb shell [14:18] weird [14:18] ogra_: I tried to grep as well -> no result [14:18] sil2100: sure what do you want me to update next? [14:18] well, /res is clearly not from a partitionn mount or anything [14:18] yeah, so should come with flashing recovery, right? [14:19] sil2100: nevermind I got it again [14:19] it is inside the img ... but i would suspect the build system forces them in somehow [14:19] sil2100: I think it is this one libubuntu-platform-hardware-api1 [14:19] ogra_: I didn't find anything splitting those image (there is a python script, but it's not called) [14:19] right, if you fastboot flash recovery recovery.img it should put yours in place [14:19] ogra_: yeah, so didn't work for that case :/ [14:19] sil2100: also it isn't instant you need to leave it by the look of it [14:20] ogra_: not sure what I'm doing wrong… [14:20] didrocks, ask sergiusens ... he knows the build system in and out [14:20] sergiusens: time for helping me on something weird with recovery? [14:20] i bet there are some .mk files that have the pics hardcoded [14:20] probably [14:21] as the other changes are there [14:23] what's the issue? [14:23] sergiusens, replacing the upgrade animation in recovery [14:24] sergiusens: ok, so, I'm using the android source package in distro (I'll learn how to build from the git source later on) [14:24] sergiusens: I've replaced the images in bootable/recovery/res/images/ [14:24] ogra_, I thought that was assigned to me :-) I was waiting for you to give me the assets ;-) [14:24] sergiusens: ah, I didn't know that, I'm happy to do something fun for once :) [14:25] sergiusens: I changed bootable/recovery/ui.c for the offset and take 8 images [14:25] sergiusens, me ? [14:25] davmor2: hmmm [14:25] davmor2: so it's platform-api indeed [14:25] ogra_, yeah, discussed at last vuds [14:25] didrocks: ^ [14:26] sergiusens: when I compile it and flash the recovery system, I get the new code (including some sleep hack for system-image-upgrader) [14:26] sergiusens, heh, darn, i had totally forgotten about that ... well, now it is didrocks doing it [14:26] no problem, just proves my point that assigning people to stuff is useless ;) [14:26] ++ [14:26] didrocks, so are you missing files? [14:26] we just need a big blackboard where people can grab WIs [14:26] sergiusens: but the images are still the old ones… (I can see there are only 7 of them and only the old ones in /res/images) [14:26] sergiusens: yeah, like if the rest was flashed, but /res was coming from somewhere else [14:26] sergiusens, to me it looks like the imgs are cpoied to there from elsewhere [14:27] lol [14:27] * ogra_ keeps quiet now to not sound like an echo [14:27] ogra_: isn't that big blackboard called LP [14:27] sil2100: can you work with the last lander? [14:27] didrocks: so, we probably found the package for the location-service 100% CPU bug, it seems to be platform-api ;/ [14:27] davmor2, that has all stuff assigned [14:27] didrocks: let me look [14:28] sil2100: want a bug throwing together? [14:29] davmor2: what do you mean? [14:30] sil2100: for the 100% cpu now we know the cause do you want me to write up a bug?> [14:30] sergiusens: I tried to grep, but the bootable/recovery/make-overlay.py doesn't seem to be called anywhere or whatsoever [14:30] davmor2: yes ;) I think it's good to have one anyway [14:30] sil2100, what's with 100% CPU? [14:31] tvoss: it seems location-service on maguro seems to hit the 100% CPU bug again - it only happens when we upgrade platform-api to the latest version [14:31] tvoss: there was a platform-api upload yesterday, no-change upload (just a mir dep bump) [14:31] tvoss: so maybe some gcc issue again? [14:32] didrocks, recovery_resources_common := $(call include-path-for, recovery)/res [14:32] build/core/Makefile [14:32] sil2100, that shouldn't affect the service, it only uses the hardware bits'n'pieces from platform api [14:32] ogra_: didrocks: asac: This is where the UITK tests are -> http://pastebin.ubuntu.com/6931443/ [14:32] sil2100, mind showing me the upload? [14:33] tvoss: sure, I also didn't see anything specific... [14:33] ogra_: didrocks: asac: I do not think those failures has anything to do with UITK [14:33] tvoss: https://launchpad.net/~ci-train-ppa-service/+archive/landing-013/+build/5582302 <- this is what landed [14:33] sergiusens: so, seems it's going to use the right paths [14:33] didrocks, those files aren't deps === bfiller_afk is now known as bfiller [14:34] didrocks, so if you did a prior build, clean up or iirc, do make snod [14:35] sil2100: https://bugs.launchpad.net/ubuntu/+source/platform-api/+bug/1280311 [14:35] Launchpad bug 1280311 in platform-api (Ubuntu) "libubuntu-platform-hardware-api1 causes 100+ cpu usage when engaging location" [Undecided,New] [14:35] * ogra_ is happy you dont have to make snot [14:36] make snod won't work; it just the opposite :-) [14:37] sergiusens: hum, res isn't in the ramdisk though, I wonder if I don't need to flash anything else than the recovery partition? [14:37] sergiusens: I did a clean full package build [14:38] and there is just one icon_installing_overlay01.png in the whole source, so no caching I guess [14:39] can somebody give me a slot for l21? [14:39] it's a 1 line depends change in indicator-session for unity-system-settings on desktop [14:40] (sorry to ask again but I would like to land before the WE, it's desktop only and ridiculous trivial) [14:40] tvoss: can you think of anything that could have re-triggered the bug? It seems to happen only on maguro [14:40] (slow system) [14:40] didrocks, well I do have res ls $OUT/recovery/root/res [14:40] gives m keys and images [14:42] sergiusens: just a hacked version, but the recovery image is at http://people.canonical.com/~didrocks/tmp/ubuntu-preinstalled-recovery-armel+mako.img. Do you want the source package? === WebbyIT is now known as rpadovani [14:42] didrocks, at it to gerrit :-) [14:43] sergiusens: sure, let me do that (but the images are not definitive and I'm adding the sleep command to be able to test easily) [14:43] sergiusens: btw, I'm interested to know how to build from gerrit for mako [14:44] maybe the issue is just in the way I'm building the package [14:44] didrocks, 4.4 or 4.2? [14:44] sil2100, can you hand me the upstart logs? [14:44] didrocks, I guess you should 4.4 this ;-) [14:44] sergiusens: I'm happy with 4.4, was 4.2 as I used the package [14:44] davmor2: ^ [14:45] tvoss: davmor2 has a maguro and can reproduce, so I think he can provide what's needed [14:45] tvoss: sure what do you want exactly? [14:45] davmor2, the upstart log of the location service [14:45] hm, I can't seem to find the landing of yesterday's Mir on the spreadsheet, not even in the Archive tab [14:45] sil2100, did you see my question earlier (asked twice already, I need a slot for a trivial desktop landing) [14:45] I think I'm getting blind [14:45] seb128: yes, doing it now ;) [14:46] seb128: the u-s-d, right? [14:46] sil2100, yes (indicator-session in fact, but to support u-s-d ;-) [14:46] sil2100, thanks [14:46] didrocks, phablet-dev-bootstrap --sources aosp --repo-branch phablet-4.4.2_r1 my_repo [14:46] Ah, hah, right, the name confused me ;) Assigning [14:47] seb128: spreadsheet is giving me problems, one moment [14:47] k [14:48] didrocks, I have one build here: 7,4G [14:49] rsalveti, FYI i'm firing off an i386 only ubuntu-touch image build now, to see if there is any fallout ... [14:49] didrocks, sil2100, you guys dont want to build an image within the next hour or so ? [14:50] ogra_: no [14:50] great, starting ... [14:50] * ogra_ is curious if it will be published [14:50] (i know it will be build) [14:51] didrocks, this should help you: make $OUT/recovery.img showcommands [14:51] didrocks: so... spreadsheet is still broken a bit for me, I can't assign a silo - would you mind if I assign a silo manually by tweaking the fields? [14:52] didrocks: since jenkins already assigned one for seb128 [14:52] didrocks, you will see something like: cp -rf bootable/recovery/res /media/sergiusens/minasithil/android/phablet-trusty/out/target/product/manta/recovery/root/ [14:54] sergiusens: this will build by default on mako, maguro, manta… ? [14:54] sil2100: yeah [14:56] didrocks, I don't understand the question [14:57] sergiusens: the build command will build like the package (I remember we do a loop), is there anyway just to build for one device, like mako? [14:57] (to not have to build on every device) [14:57] for* [14:57] didrocks, oh [14:57] why would you want that ? [14:57] didrocks, . build/envsetup.sh [14:58] ogra_: just to be quicker in the dev/test side [14:58] oh, for local builds :) [14:58] right [14:58] lunch (add number or it will disaply a list of targets [14:58] i thougth generally [14:58] then make [14:58] there's no breakfast or brunch in aosp [14:58] sergiusens: excellent, trying that as soon as it finishes to fetch the repo :) [14:59] sil2100, I have no idea, do you have the list of mir changes handy? [15:00] AOSP devs have to stay hungry [15:00] seb128: ok, silo assigned [15:00] sil2100: I need to rebuild in silo 002, but the build button is not appearing [15:00] seb128: just be warned, the spreadsheet has problems with syncing stuff sadly [15:01] bfiller: yes, google problems... you can try clicking on the link that is assigned to the button [15:01] sil2100: nm, button not there but still working [15:02] tvoss: is a changelog enough? ;) [15:02] sil2100, yup [15:04] tvoss: https://launchpad.net/ubuntu/+source/mir/0.1.5+14.04.20140212-0ubuntu1 [15:04] rsalveti, a present for you at http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20140214.1/ [15:04] :) [15:04] ogra_: \o/ [15:04] ogra_: yeah, 182, but from cdimage [15:05] but it shouldn't be any different [15:05] I'll take a look [15:05] well, depends what landed today [15:06] oh, hmm, we have two manifests now [15:06] that will likely confuse my scripts [15:07] rsalveti, in any case it is intresting that building the x86 image took only 10min :) [15:07] * ogra_ actually thought it had failed ... [15:09] x86 livefs builds are pretty quick, yes [15:10] cjwatson, especially if you are used to armhf only for over a year :) [15:11] rsalveti, ouch ... 501M ... x86 actually surpasses our limits [15:11] ogra_: ouch, quite big [15:11] yeah, +30M vs armhf [15:12] sil2100, any news about the udm landing? [15:12] rsalveti, ogra is there a new cdimage image? [15:13] tvoss, no changes on armhf [15:13] but yes [15:15] mandel: let me check, since the spreadsheet doesn't update for me too well, one moment [15:22] mandel: looking through the diffs again [15:22] didrocks: so you don't want to build 4.4 right now [15:22] as that's not our official target yet [15:22] we still need to switch officially :-) [15:22] rsalveti: hum… but I just want to hack on the recovery, so shuld be fine? [15:22] didrocks: yeah, that should be fine [15:23] rsalveti: I'm still wondering why using the package did change the rest of the ramdisk, but not /res, but we'll see with the branch [15:23] then apt-get build-dep android, repo init -u https://code-review.phablet.ubuntu.com/p/aosp/platform/manifest.git -b phablet-4.4.2_r1; lunch (select the target), make -j10 [15:23] (still fetching) [15:23] didrocks: yeah, that might take a while === alan_g is now known as alan_g|tea [15:24] rsalveti: I'm at 5G… so should be soon done as it's 7 I heard ;) thanks for the quick receipt! [15:25] recipe* [15:25] tvoss, sil2100: do you need anymore info from this phone I want to reboot it before the device burns through the desk [15:25] davmor2, nope, feel free [15:27] ogra_: for some reason lxc-android-boot didn't copy the udev file for maguro [15:27] tvoss: cp /usr/lib/lxc-android-config/70-maguro.rules /lib/udev/rules.d/ [15:27] tvoss: then reboot [15:27] rsalveti: is that the 4.4.2 image landing in an update near you soon? [15:27] ogra_: didrocks: the UITK tests are here -> http://pastebin.ubuntu.com/6931718/ Actually the results are better with the silo UITK than with the stock [15:27] rsalveti, awesome, I just flashed the latest ubuntu-system though to help tracking down the 100% CPU issue [15:28] bzoltan1: ok, so only address_book and notes_app have tests failing, right? [15:28] bzoltan1, thats awesome news \o/ [15:28] davmor2: beginning next week I hope [15:28] didrocks: No, the Notes App is failing too [15:28] rsalveti: \o/ [15:29] bzoltan1, thats what didrocks said ;) [15:29] ehh ... me is an ass [15:29] (address_book and notes_app) [15:29] bzoltan1: seems to be in the known flakyness acceptance. Ok, so we are going to kick an image soon [15:29] then, we'll get the toolkit in [15:29] bzoltan1, nah, just a bit blind :) its friday, all good [15:29] and kick another image [15:29] * bzoltan1 hugs didrocks [15:29] * didrocks hugs bzoltan1 back [15:30] * ogra_ doesnt want to be an image today ... [15:30] kicked all day [15:30] bzoltan1: thanks for the testing! I know it's tedious! [15:30] ogra_: to be an image? [15:30] didrocks: it did not hurt... learned a lot on the way [15:30] didrocks, yeah, you kick these poor things all the time [15:30] didrocks: just time consuming [15:30] ahah :) [15:30] bzoltan1: yeah… [15:31] ogra_: should I start one now, nothing blocking on your side? [15:31] didrocks, go ahead, kick it like beckham (or so) [15:31] ahah :) [15:31] don't start speaking about football please! [15:31] * davmor2 redirects all the image kicking in ogra_ 's direction he makes it sound like he wants it [15:31] (shot!) [15:33] didrocks: don't introduce guns into football they are dangerous enough withouth them ;) [15:33] didrocks: are you ready for 2 packaging ACKs by any chance? ;) [15:33] davmor2: +1 [15:33] sil2100: yep [15:33] tvoss: you have a maguro btw.? [15:34] sil2100, yup [15:35] didrocks: those are bigger packaging diffs: http://162.213.34.102/job/landing-011-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-download-manager_0.3+14.04.20140214-0ubuntu1.diff <- u-d-m here, looks more or less ok, just hope nothing slipped my eye - u-d-m was the only rdep of libubuntudownloadmanager1 if anything [15:35] didrocks: there is a breaks+replaces for it as well [15:36] didrocks: sil2100 can one of you help? [15:36] didrocks: and this: http://162.213.34.102/job/landing-011-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity-scope-click_0.1+14.04.20140213.2-0ubuntu1.diff <- this becomes the new rdep of the new u-d-m libraries, there's also some rules magic in it [15:36] kgunn: what's up? [15:36] sil2100: so row 31 small change to unity-mir & papi [15:36] says its build [15:36] but when i go to ppa [15:36] nothing is in there [15:36] and i flashed, did all the ppa add only to find it empty ... :-/ [15:37] kgunn: ah, ok, so... we still have probably problems with the spreadsheet ;/ First thing, try refreshing the page? [15:37] The spreadsheet that is [15:37] sil2100: yep did that...still says silo ready [15:37] but [15:37] https://launchpad.net/~ci-train-ppa-service/+archive/landing-006/ [15:37] nothing in there [15:38] Ok, let me see [15:38] kgunn: silo ready is meaning "you can start building" [15:38] kgunn: right, I see silo ready, so build has not been pressed [15:40] sil2100: didrocks [15:40] sorry it was a late night [15:41] didrocks: now are you playing a joke on me ? build button says "#N/A" [15:41] kgunn: no worries, that's a google problem as well [15:41] kgunn: buttons seem to have stopped working ;) Just press on the link there [15:41] * sil2100 has no idea what's up with the spreadsheet [15:42] kgunn: yeah, google is playing with us… [15:42] sil2100: thankfully i did...i just ignore warning signs :D [15:42] ahah [15:42] not sure it's a good sign :p [15:42] 50/50 [15:42] kgunn: the link is there just the button is not visible… [15:43] tvoss: the interesting thing is that we didn't observe it on the mako, so hm, it's not entirely the same as before [15:44] plars: doanac: we need to setup a different dashboard entry for a new customized channel (which will be used by mwc) [15:44] plars: doanac: can be mako only, if we have enough devices for it :-) [15:45] plars: doanac: the channel is called trusty-customized-demo [15:45] rsalveti: shouldn't be too hard. a couple of questions: [15:46] rsalveti: how should we label this. WRT: http://ci.ubuntu.com/smokeng/ [15:46] sil2100: +export G_MESSAGES_DEBUG=all [15:46] +export U1_DEBUG=1 [15:46] are we going to spam the logs? [15:46] would we call the "variant" touch-mwc ? [15:46] let me ask cwayne [15:48] doanac: touch_custom_demo [15:48] rsalveti: ack. i'll take a look today [15:48] doanac: awesome, thanks [15:49] sil2100: short description for libubuntu-download-manager-priv0 and libubuntu-download-manager-client0 are identical, should they? [15:50] +Description: QT library for Ubuntu Download Manager - development files [15:50] + . [15:50] didrocks: it seems they wanted to have build errors easily visible [15:50] + This package contains the header that can be used to allow an application use the Ubuntu Download Manager client library. [15:50] the . should be removed === alan_g|tea is now known as alan_g [15:51] sil2100: also, why breaks/replaces? it doesn't seem to have package files overlapping [15:52] +Package: libubuntu-download-manager-client-dev [15:52] -> should dep on some qt-dev packages [15:52] (see .pc) [15:52] didrocks: the descriptions are not identical, they have different last lines - is that not enough? [15:52] and some for +Package: libubuntu-download-manager-common-dev [15:53] sil2100: short description (the one line) should be different [15:53] didrocks: ah, ok, right [15:53] sil2100: I guess there are too many things to fix them in a future upload, better to get a new MP in and rebuild? [15:54] sil2100: also, cherry on the top, trailing comma please :) [15:55] didrocks: ;) Ok, will fix those up quick and rebuild - what about the click-scope? Should I get rid of the 'force debugging during build'? [15:56] sil2100: I think that's fine for now, but we should write somewhere to have that removed before end of cycle [15:56] sil2100: also, ensure that u-d-m has been tested to download files and flash to a newer version [15:57] didrocks: will poke thostr, but he spent some time already on the testing - double-checking won't hurt though [16:04] sil2100, I just flashed devel-proposed and my location service is behaving correctly === gatox is now known as gatox_lunch [16:06] tvoss: hmmm, davmor2 said it wasn't visible instantly [16:06] btw. what platform-api version you have installed? [16:06] sil2100, whatever is latest in the image [16:06] sil2100, I thought that had landed [16:07] tvoss: yes, but I want to make sure you ahve the same thing ;) [16:07] rsalveti: is there any trick (as I guess we don't need dalvik) to not use java? I'm getting (as we build-dep on 1.7): javac: target release 1.5 conflicts with default source release 1.7 [16:08] tvoss: did you trigger the location service? I did it by opening the webbrowser and typing maps.google.com and saying allow for location and then click on the target button for finding my location [16:08] sil2100, davmor2 http://pastebin.ubuntu.com/6931935/ [16:08] davmor2, sil2100 you did not mention that to me [16:09] tvoss: I did in the bug report [16:10] tvoss: https://bugs.launchpad.net/ubuntu/+source/platform-api/+bug/1280311 [16:10] Launchpad bug 1280311 in platform-api (Ubuntu) "libubuntu-platform-hardware-api1 causes 100+ cpu usage when engaging location" [Undecided,New] [16:12] sil2100: re: https://code.launchpad.net/~mandel/ubuntu-download-manager/fix-packaging/+merge/206377 i think the breaks/replaces need to be there to avoid breaking upgrades in the PPAs, as u-d-m is automatically pushed to some PPAs before going to the archive. so anyone/thing using those PPAs needs to be able to properly upgrade [16:12] didrocks: we don't use java atm (afaik), but we might still have some dependency check in it [16:12] openjdk 1.6 should work just fine [16:13] rsalveti: ok, will use that, thanks [16:13] davmor2, sil2100 I can look into that next week if that's fine with you [16:13] tvoss, sil2100: I see no issue with that I don't think it is something that should stop the promotions. [16:14] davmor2, ack [16:14] davmor2, can you assign the bug to me, please? [16:14] tvoss: done [16:14] didrocks: ^ [16:15] dobey: right [16:15] dobey: mandel already told me the rationale for that - since we are releasing to the archive now, we can't consider things related to PPA's [16:18] balloons, you around? [16:18] tvoss, indee [16:19] sil2100: well, not exactly. this is the bootstrap, otherwise those changes would already be in the archive. i think it makes more sense to leave them in (and then remove them in the next "release" perhaps). at least that is my understanding of how transitions are meant to work [16:20] dobey: you mean, leaving the Breaks: ubuntu-download-manager-priv1 etc.? [16:20] ogra_: I'm surprised by the empty diff in latest image [16:21] didrocks, that was my x86 test [16:21] ogra_: some stuff has hit and published since 3am [16:21] ignore it [16:21] yeah [16:21] I was about to say it :) [16:21] sil2100: yes [16:21] ogra_: can we get this list? :p [16:21] or it's lost forevererererer [16:21] i did build woth ARCHES='i386' [16:21] so it only pulled the existing armhf pieces [16:21] didrocks, ? [16:21] didrocks, there is no list for 14.1 [16:22] ogra_: ah, not yet built [16:22] since it is identical to 14 on armhf [16:22] sil2100: line 3 in the sheet is ready to get propagated when you have time [16:22] and it will be 14.2 [16:22] yeah :) [16:22] dobey: well, ubuntu-download-manager-priv1 never existed anywhere besides in the daily PPA, right? [16:22] okidoki! [16:22] didrocks, cross your fingers though ... not sure how my script will handle that [16:22] ogra_: it better has to behave! :) [16:22] (i might have to fiddle manually so we dont end up with a full manifest) [16:23] lets see :) [16:23] sil2100: well the daily PPA is how packages were being built and then pushed into the archive. moving to CI train is a transition away from that, so i think the package should handle that upgrade path [16:24] dobey: sadly, daily-build PPA was never meant to be used besides for testing purposes, it's not an official part of Ubuntu so things landing in Ubuntu should not take that into consideration [16:24] didrocks: am I right here, or in this state I simply misunderstand ^ ? [16:25] sil2100: you mean, for additional breaks/replaces? [16:25] that's not harmful in that case, we can keep it [16:25] just wanted to ensure we had a real use case [16:25] didrocks: I mean, breaks+replaces of packages that were never in the archive but only in daily-build [16:25] sil2100: well, it's an official part of the CI for releasing things to ubuntu [16:25] that would be dropped in a couple of weeks then [16:26] sil2100: there's no harm in keeping the upgrade path, and doing a proper transition to the new process. and they can be removed after [16:26] didrocks: since earlier I dropped the release and asked to fix this, since there were breaks+replaces for packages that never entered the archive, but were only visible in daily build [16:26] sil2100: yeah, that's fine if this has a justification [16:26] didrocks: ah, ok... [16:27] sil2100: the biggest concern is the missing deps on the -dev packages [16:27] didrocks: I thought that we don't consider things that have not been in the archive [16:27] bleh, nevermind then, just don't listen to me today then [16:27] dobey: I'll remove that merge then and rebuild, seems you're right [16:30] sil2100, around? [16:30] sil2100, so I got amd64 to pass on Jenkins here https://code.launchpad.net/~thomas-voss/dbus-cpp/force_gcc_4.7_and_symbols/+merge/206359 [16:30] sil2100: didrocks: robru: allocating 19.. [16:30] sil2100, should I remove the MP then? [16:30] sil2100, but looking at https://jenkins.qa.ubuntu.com/job/dbus-cpp-trusty-armhf-ci/95/console I don't think that the 32bit symbols are picked up [16:31] mandel: leave it for now, we'll make it invalid later [16:31] ack [16:31] tvoss: hmm [16:32] ogra_: great! http://people.canonical.com/~ogra/touch-image-stats/20140214.2.changes [16:32] I guess we can publish the toolkit now [16:32] perfect [16:32] mandel: I personally don't like considering PPA's, especially since we always said not to use daily-build at all [16:32] so i dont need to touch anything [16:32] * ogra_ pats himself on the sholder [16:32] Since the state of that PPA was never sure [16:33] But I'm not a core-dev, so I don't know [16:33] sil2100, Ido what you guys tell me, you know waaaya more about this than I do [16:35] ok, sdk published [16:35] sil2100: so. think of it less about considering PPAs, and considering transitions and upgrade paths for a native package. [16:35] bzoltan1: FYI ^ [16:35] bzoltan1: so, you will be in image 184 [16:35] (trying to get as few things in possible into that one) [16:36] dobey: but how is this an upgrade path if we always say that everyone uses daily-build at their own risk? [16:36] sil2100: because it's a native package, anyone can pull trunk and do bzr bd, get some packages, and install them. the packaging needs to deal with transitions through that as well. even if it's not advised to do that [16:37] sil2100: we also only ever tell people to use the official ubuntu release at their own risk. :) [16:38] dobey: well, I don't care enough, it can stay if didrocks says it's ok [16:38] sure [16:39] i'm just trying to help explain why i think it's a good idea to keep it (not only in this case, but in any similar cases) [16:39] dobey: no worries, I understand your rationale and it's sane, just being a bit grumpy today [16:40] Sorry for that [16:40] anyway, need to go get lunch now. :) [16:42] tvoss: let me try building this locally as well - strange though? [16:42] sil2100, yup, please make sure that you switch -DCMAKE_BUILD_TYPE=coverage in debian/rules when you build locally [16:43] tvoss: I've been wondering, does it build in both cases now? Both with coverage and without? [16:43] sil2100, what means build to you? [16:44] tvoss: I mean the package [16:44] tvoss: btw. crap, noticed a small mistake I made in the include, but it still shouldn't explain why 32bit symbols don't get picked up [16:45] sil2100, so amd64 should work now both for with and without coverage [16:45] Nice [16:45] what was the mistake for the include? [16:46] tvoss: instead of 'powerpc' it should be 'ppc64el' [16:46] hmmm ... [16:46] didrocks, is there any special requirement which boots i should wear on monday ? or will any kind of boots do ? [16:48] sil2100, I have no clue why it is not including the file apparently or not finding the symbols tbh [16:49] sil2100, I have to step out for a bit [16:50] ogra_: boots? Not sure if we have "hope boots" but that would do it if they exist :p [16:50] i'll take a look at my local boot supplier on the weekend then :) [16:56] tvoss: will also look more into that after the meeting... [16:58] Damn, google stopped responding... [16:59] yeah, same here [16:59] At least the spreadsheet [16:59] Great === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [17:03] balloons: coming? [17:07] didrocks, ;-) === gatox_lunch is now known as gatox [17:21] sil2100: tested silo 006, for unity-mir & platform-api...that's ready to go...and its needed for mwc... [17:21] so if someone can do me the honors soon...that'd be great [17:30] didrocks: I don't know what you mean. I'm only looking at the QT5.2.1, 4.4.2, MWC images and daily you make it sound like it's a lot ;) [17:30] davmor2: ahah :) [17:31] didrocks: I have 7 hours in the airport I'm going to test the hell out of the MWC image then I'm charing the n10 up for that :) [17:31] ogra_: rsalveti: ok, the png issues seem to be due to my hacking on the package itself, it's working better with the git branches. I'll get more beautiful images for next week [17:32] davmor2: take some more batteries even! [17:32] didrocks, wheee ! [17:32] didrocks: nah I'll just find a socket somewhere :) [17:32] Great day [17:33] kgunn: we want an image to be kicked first, since we also published UITK [17:36] sil2100: ah, ok...if it could land before monday that'd be great...dunno if that's possible [17:36] maybe with US landing team now it can ? :) [17:36] ogra_: oh, I forgot [17:36] ogra_: did you promote 181 btw? [17:37] balloons: in the landing call, didrocks said he was kicking off 184 also, so we should be on the lookout for differences between 183 and 184 that could be related to the ui-toolkit update [17:37] kgunn: I guess it will be possible ;) robru and cyphermox_ will be your guides, just be advised that we have some spreadsheet problems still [17:37] didrocks, nope [17:37] didrocks, want me to ? [17:38] oh, you already announced it :P [17:38] didrocks: what is the plan regarding landing 4.4.2 will we need people to actually reinstall Android 4.4.2 boot into that and then reflash to Ubuntu? [17:38] ogra_: yeah, sorry with the spreadsheet, I forgot about it :p [17:38] * ogra_ does so then ... [17:38] davmor2: I think flashing will be enough, not sure [17:38] davmor2: TBH, bigger fish to fry for now :p [17:38] rsalveti: ^ [17:38] ogra_: thanks ;) [17:39] didrocks: no worries I just want to make sure I have devices in the right state to test it either way :) [17:41] didrocks: sorry, which png issues? [17:42] davmor2: no, we need a better plan [17:42] problem is that we'd need to reflash the bootloader [17:42] .oO( now why did i read beer plan above) [17:42] and that's waaay complicated [17:42] Many many big fish [17:42] ogra_: is it because it is Friday night? [17:43] davmor2, most likely :) [17:43] or because rsalveti said it [17:43] kgunn: we'll land that today :-) [17:43] not sure, either of the two [17:43] rsalveti: rock n roll [17:43] see i am actually trying to land stuff :) [17:43] ogra_: did we already pushed for a new image with the toolkit changes? [17:43] rsalveti, it is building afaik [17:43] great [17:44] once that's done we can land the new copy&paste stuff [17:44] rsalveti: btw, demo-stuff & phone-right-edge ppa's will be worthy of playing with over the weekend [17:44] kgunn: yeah [17:44] i should send a mail out later [17:44] kgunn: did we get the landscape mode already? [17:44] rsalveti: its in demo-stuff [17:44] oh, cool then [17:44] didrocks: https://code.launchpad.net/~sil2100/ubuntu-download-manager/fix_deps/+merge/206536 <- does this look better? [17:44] rsalveti: ah, you didn't follow, I got bad png copied back when hacking with the package, but that was surely an overlook. I'm changing the recovery updater (just to do something fun for once) [17:44] kgunn: we can probably land that in the archive [17:44] but you do have to manual update one env varibale [17:45] rsalveti: right so we need a better plan but currently that is how it stands right? I only want to know so I can prep devices before the 4.4.2 lands so I can test it the way we expect a user to install it. :) So if you can let me know asap what the plan will be I can then prep things for it :) [17:45] kgunn: right, any reason for not landing that? [17:45] === Image 181 Promoted === [17:45] rsalveti: well, n7 landscape isn't somethign we'd want to land [17:45] its not really product [17:45] only demo [17:45] sil2100: approved [17:45] (e.g. its not really the right way) [17:45] ogra_: \o/ [17:45] kgunn: right, but if we have an option we can indeed land it [17:45] sure [17:45] kgunn: and have that option set as part of the custom properties [17:45] so people could still use it [17:45] didrocks: ok, so I'll publish u-d-m once mandel and alecu confirm the testing [17:46] which is quite useful [17:46] kgunn: like people flashing their own n7 during mwc [17:46] (they're on it) [17:46] * kgunn recalls what happens when you land demo-only code [17:46] kgunn: the user experience would be quite different [17:46] rsalveti: add...but we have ppa's and instructions [17:46] kgunn: they will get a huge phone, basically [17:46] kgunn: but that's not what we'll be flashing on people's tablet [17:47] rsalveti: yeah...and ?? [17:47] kgunn: then they will get a huge phone :-) [17:47] and we'll demo a tablet [17:47] until you add the ppa [17:47] for them [17:47] as you'll be connected to a computer [17:47] kgunn: right, but then you have to enable rw, and then you can't automatically update it anymore [17:47] yep... [17:48] if we merge it in the archive and have an option for that [17:48] it would just be better [17:48] not only is it demo....no one has run any of the n7 landscape code through the testing paces [17:48] greyback_: ^ [17:49] kgunn: I think the functionality is still useful (not only for demos) [17:49] but it depends on the implementation :-) [17:49] that's why I wanted to get this merged if possible [17:50] sil2100: maybe a known issue - after I've done merge and clean some rows are showing up as "packages ready for testing" status [17:50] even though they have been merged and released [17:51] rsalveti: i suppose you could put it up for landing, do all the testing etc.... [17:51] kgunn: sure, why not [17:51] we need to test it anyway [17:51] rsalveti: as kgunn said, it's mostly demo code done for n7's benefit, no tests are ready for it. (no tests exist for side stage at all really) [17:51] or do you want a broken demo? ;-) [17:51] rsalveti: only reason not too is for the aforementioned reason that's its not really our final intention [17:51] and i don't really want to land demo code [17:52] alright, fine then, more stuff in a ppa then [17:53] so right-edge + scopes for phone [17:53] landscape + scopes for tablet [17:53] in demo-stuff [17:53] precisely [17:54] rsalveti: we're relying on manual testing as greyback_ indicated...so any feedback there is still useful [17:54] sure, we don't want to demo broken code === alan_g is now known as alan_g|EOW [18:04] rsalveti, who cares about the code as long as the UI isnt breaking :) [18:04] ogra_: :-) [18:04] you just don't want to explode while people are demoing it [18:05] haha, yeah [18:09] Damn [18:09] This will be a long Friday [18:10] sil2100: what now? :-) [18:46] plars, wow, unity8 on mako looks really unhappy [18:54] cihelp: it seems Jenkins bot doesn't want to pickup this branch [18:55] cihelp: https://code.launchpad.net/~albaguirre/unity-mir/hide-surface-during-app-suspend/+merge/205695 [18:55] cihelp: any ideas? [18:58] AlbertA, checking [18:59] cihelp: also this one https://code.launchpad.net/~albaguirre/unity-mir/cross-compile-link-fix/+merge/205690 [18:59] cihelp: thanks for checking [19:00] AlbertA, np [19:03] retoaded: it doesn't seem to have run in 2 days [19:20] AlbertA: I'm not sure what is going on.. we will need to wait for fginther to come back [19:20] cjohnston: ok [19:35] ogra_: sorry, had to run an errand at lunch - you mean the errors in camera-app? We got a new camera-app too [19:41] fginther: Hi, I saw your email. Thanks for the info. I have a question about the tests that the overlapping monitors doesn't occur on. Do those tests pull anything from the daily-build PPA as well? [20:18] robru: dude, I'm assigning a silo to line 34 [20:18] ogra_: which image? [20:21] robru: scratch that, blocked by line 22. [20:40] plars: do we have someone looking at the camera / unity8 issue? [20:41] rsalveti: I can't rerun because the next image is queued up right behind it [20:41] right, let me flash mine and see [20:41] rsalveti: I can retry at home perhaps - but especially on the camera one I'm thinking it's worth getting someone to take a look since we got a new version [20:41] plars: hm, right, let me see [20:42] * port autopilot tests to python 3. [20:42] * add integration test to make sure gallery icon in the camera toolbar [20:42] really opens the gallery-app. (LP: #1228335) [20:42] Launchpad bug 1228335 in camera-app (Ubuntu) "[Autopilot test needed] Test tapping on the gallery icon takes you to the gallery app" [Medium,Fix released] https://launchpad.net/bugs/1228335 [20:42] bfiller: ^^ [20:43] that might be the cause of the issue [20:43] might just be a bug in the test case itself [20:45] cihelp cjohnston: I'm beginning to think it's me, here's another branch where Jenkins bot just doesn't seem to want to run: [20:45] https://code.launchpad.net/~albaguirre/mir/screencast-crash-fix/+merge/206337 [20:47] AlbertA: my *guess* is there is something wrong due to the ci train stuff [20:50] rsalveti, plars : are you talking about these failed camera tests?http://ci.ubuntu.com/smokeng/trusty/touch/mako/183:20140214.2:20140115.1/6594/camera_app/ [20:50] rsalveti, plars : if so, they look like unity crashes [20:50] bfiller: yeah [20:50] indeed, there's a crash as well [20:50] bfiller: but unity8 was updated at feb12 [20:51] might be a new issue with unity8 [20:51] but caused by latest camera-app [20:51] I'm flashing latest to test and see [20:51] hmm, nothing that stands out in http://people.canonical.com/~ogra/touch-image-stats/20140214.2.changes [20:52] plars: right, only camera-app itself [20:53] rsalveti: I'll try as well, nothing in camera landed that should be causeing that but never know [20:53] bfiller: yeah, because the previous image was fine [20:53] http://ci.ubuntu.com/smokeng/trusty/touch/mako/182:20140214:20140115.1/6584/ [20:53] did I mention I hate autopilot :) [20:53] we had 2 crashes but the tests were fine [20:54] and one crash for the dialer-app still [20:54] yup [20:54] known [20:54] bfiller: at least the camera-app failed the same way for both maguro and mako [20:55] so it might just be an issue with the test case itself [20:55] well, unity8 crashed in both cases :-( [20:56] plars: and no unity8 tests yet on mako [20:56] plars: failed when running phablet-test-run [20:56] [Errno 2] No such file or directory: '/var/lib/jenkins/slaves/mako-02/workspace/trusty-touch-mako-smoke-daily/clientlogs/unity8/test_results.xml' [20:57] bfiller: welcome to the club :) [20:57] rsalveti: I'll rerun them when they get through the other tests [20:58] plars: how can I quickly reproduce that test run with the same image here? [20:58] from the logs it copies the autopilot first [20:58] and then it runs the test cases [20:58] rsalveti: which one, the camera-app one or unity8? [20:58] plars: camera-app [20:59] rsalveti: I have that running at home right now, it's about to be finished installing, though I just realized it's probably installing 183, not 182 [20:59] plars: oh, ok [21:00] plars: wanted to try locally as well, but don't remember how to do that from a system-image [21:00] rsalveti: the current stuff just uses phablet-test-run, so I want to let it go ahead and finish this, but then I'll install 182 and try it there at home [21:00] great, let me try [21:01] crap, no wireless, let me reflash 4.2.2's radio :-) [21:06] plars: how to install the tests there so I can run them with phablet-test-run? [21:07] * rsalveti not used to test apps with autopilot [21:07] rsalveti: for camera-app, it's not click so you need to apt-get install camera-app-autopilot [21:07] rsalveti: or specify it with -p using phablet-test-run [21:07] oh, got it now [21:08] hm, still fails when just giving the -p option [21:08] plars: was it supposed to extract the package locally and so on or do I first need to make it rw? [21:09] rsalveti: you need to make it writable with phablet-config writable-image [21:09] awesome [21:11] rsalveti: after that comes back up, swipe the screen unlocked and you can just do: 'phablet-test-run -p camera-app-autopilot camera_app' [21:11] robru or cyphermox could I get some help to publish Unity7 please? [21:11] bregma, sure, what's up? [21:11] rsalveti: which image are you running on? [21:11] plars: 184 [21:11] bregma, according to the spreadsheet packages are built but testing is incomplete. is that the case? [21:12] robru, yes, but this is my first time through, and testing is now complete [21:12] I have no idea what to do next except ping you [21:12] because those are my instructions [21:12] bregma, ok no worries. we had some hiccups with the system but i'll see what i can do [21:12] _your_ had hiccups [21:12] bregma, so all the packages in silo 3 have passed your barrage of manual and automatic tests? [21:12] robru, yes indeedy [21:13] it is time, stand back [21:13] bregma, ok great. so normally you should mark 'testing done: yes' on the silo 3 page of the spreadsheet. [21:13] rsalveti: I'm seeing the same errors with 184 that the dashboard shows on 183 [21:13] bregma, then i hit publish [21:13] shall I do that now? [21:13] plars: great [21:13] bregma, yes [21:13] then it's probably bfiller's fault [21:14] bregma, let me know if you lack permission or whatever [21:14] robru, nope, no edit privs on [21:14] that page [21:15] bregma, [21:15] ok [21:17] bregma, ok i added you but then i just made the change myself. [21:17] easy peasy [21:17] bregma, ok so i did the publish job, but there's packaging changes, which need to be acked by a core dev. I usually lean on cyphermox_ for that ;-) [21:18] cyphermox_, please review these packaging diffs http://162.213.34.102/job/landing-003-2-publish/ ;-) [21:18] AlbertA, your userid wasn't in the jenkins white list to automatically run jobs, it is now. [21:19] bregma, good god... no compiz release since october... that is a huge changelog ;-) [21:20] your welcome [21:20] *you're [21:20] omg I'm a grammar nazi [21:20] bregma, hmmm, actually the changelog diff seems to show it's removing some entries? that's a bit strange, any comments there? [21:20] bregma, http://162.213.34.102/job/landing-003-2-publish/lastSuccessfulBuild/artifact/packaging_changes_compiz_1%3A0.9.11+14.04.20140213-0ubuntu1.diff [21:21] are those entries for trunk changes backported to Ubuntu? [21:21] bregma, dunno, they say they're from raring [21:21] and a couple from saucy... but quite old [21:22] ChrisTownsend, yes those other jobs pull in packages from the daily build ppa, just not unity (those jobs use 7.1.2+14.04.20131106.1-0ubuntu4) [21:22] like the changelog from last march to last april is just getting dropped. [21:23] bfiller: plars: yeah, same failures [21:23] and no unity8 crash, so the tests are indeed broken [21:23] bfiller: plars: cyphermox_: should we just revert it? [21:23] so we can unblock other silos [21:24] or can we land new silos without getting 100% green? [21:24] * rsalveti wanted to land copy&paste still [21:24] bfiller: or are you fixing it today still? :-) [21:25] rsalveti: I don't want to revert anything [21:25] bregma, it looks like the result of some kind of large revert actually. for example there's a changelog entry that says 'drop unity_support_test.patch' and then another part of the diff introduces that patch. [21:25] rsalveti: I want to understand what the issue is [21:26] bfiller: right, we don't need to revert if you can still propose a branch today [21:26] rsalveti: you're assuming it's my bug [21:26] bfiller: not necessarily, it could be something else [21:26] but reverting it might be enough to get 100% green again [21:26] doing so to check [21:27] robru, problem is development was done in parallel between trunk and a Ubuntu branch, and the packaging got updated only for the Ubuntu branch, and now we're moving to trunk [21:27] just that because of the failures I assume we'll stop the line [21:27] rsalveti: I spent a ton of time testing and retesting including running AP tests to get camera-app landed [21:27] the last thing I want to do is revert it :) [21:27] haha, right :-) [21:27] rsalveti: are you seeing the error when running on your device? [21:27] bfiller: anything I can do to help? [21:28] bfiller: yes, same errors [21:28] fginther: Ok, thanks [21:28] bregma, any way you can just restore the changelog entries in the trunk branch and rebuild? debian/changelog is supposed to be sacrosanct... it looks bad if you're revising the history [21:28] rsalveti: unity crashing? [21:28] bfiller: nops [21:28] rsalveti: can you paste the errors [21:28] rsalveti: and verify what version of camera-app you are using [21:28] bfiller: http://paste.ubuntu.com/6933595/ [21:29] bfiller: 2.9.1+14.04.20140213-0ubuntu1 [21:30] rsalveti: can you in fact launch gallery from camera when doing it manually? [21:30] bfiller: yes, the app seems fine [21:30] bfiller: might be an issue with autopilot [21:30] maybe you tested with a previous version of autopilot? [21:31] rsalveti: has that changed recently? [21:31] bfiller: yesterday [21:31] and the day before [21:31] ok, I reverted camera-app and camera-app-autopilot, let's see what happens [21:32] rsalveti: I'm testing with 1.4+14.04.20140212-0ubuntu1 and it works fine [21:32] using 1.4+14.04.20140213-0ubuntu1 here [21:32] bfiller: and image 184 [21:32] Ran 11 tests in 47.959s [21:32] OK [21:32] rsalveti: actually unity8-autpilot is what is being used I think in this test [21:33] rsalveti: try leaving camera-app and reverting autopilot or unity8-autopilot [21:33] plars: ok, so previous version wasn't failing [21:33] bfiller: right [21:33] plars: can you easily do the revert? [21:33] rsalveti: the test hasn't changed, nor has the app [21:33] rsalveti: right, 2.9.1+14.04.20131106-0ubuntu1 was the one I reverted to [21:33] don't have the packages around [21:33] we should be reverting autopilot not the app [21:34] rsalveti: if you have an easier way, I'm interested. I just downloaded them from http://ports.ubuntu.com/pool/universe/c/camera-app/ and dpkg installed them [21:34] oh, didn't know they would still be around [21:34] bfiller: aiui, the autopilot version and app version should always match [21:35] rsalveti: the error you are reporting is different than what's here http://ci.ubuntu.com/smokeng/trusty/touch/mako/183:20140214.2:20140115.1/6594/camera_app/ [21:35] bfiller: well, the same tests are failing, right? [21:35] maybe the last issue is a crash with unity8 [21:36] it's not [21:36] lol [21:36] let me run them again [21:36] rsalveti: camera_app.tests.test_gallery_integration.TestGalleryIntegration.test_gallery_button_opens_gallery(with touch) passes in the smoketest but your stack shows an error [21:38] got just one failure now [21:38] the opens_gallery [21:38] http://paste.ubuntu.com/6933659/ [21:38] let me run it again [21:39] bfiller: yeah, I believe the ones from the dashboard were both caused by the unity8 crash [21:39] because of the error [21:40] let me open that crash file [21:40] rsalveti: so I'm game for skipping the test if that's causing problems. rather do that then revert camera-app [21:41] camera_app.tests.test_gallery_integration.TestGalleryIntegration.test_gallery_button_opens_gallery fails every time for me [21:41] bfiller: can you try this test with 184? (latest) [21:41] rsalveti: yup, reflashing. takes like 20 minutes with this dual-boot setup [21:42] bfiller: oh, also testing dual-boot? [21:42] rsalveti: just have my N4 setup with it cause I like to be able to run Android [21:42] oh, got it [21:42] thought you were also testing it because of mwc :-) [21:43] no [21:46] we'd need someone from the unity8 team to investigate this crash [21:46] reverting will probably get us to a green state again, but that's not the cause [21:46] and we need to investigate the crash itself [21:47] plars: do we have any sort of retracer for the crash files? [21:48] argh, and crash file is invalid it seems [21:48] 861K [21:48] rsalveti: no idea [21:48] let me open it with gdb [21:48] argh, so annoying that ports is so slow for me [21:49] BFD: Warning: /home/phablet/bla/CoreDump is truncated: expected core file size >= 333623296, found: 3071080. [21:49] yeah, useless [21:50] rsalveti: you mean when running apt-get update? it's paintful [21:50] bfiller: was just trying to install libc6-dbg haha [21:50] 24k/s [21:50] rsalveti: it's awful [21:51] rsalveti: btw, the autopilot tests are launching stuff still from command line with --desktop_file_hint so some things are crashing in the shell that way during autopilot only [21:51] both cores, from mako and maguro, are useless [21:51] I hate this [21:51] rsalveti: like the unity crash from dialer-app [21:51] right [21:52] so yeah, can't reproduce it [21:52] hahah [21:52] rsalveti: try running camer-app like camera-app --desktop_file_hint=/usr/share/applications/camera-app.desktop and see if crash happens when launching gallery [21:52] bfiller: see if you are at least getting the same failure [21:52] sure [21:52] rsalveti: yup, downloading still [21:52] wicked slow downloading from android app [21:53] bfiller: worked fine [21:53] they should put some parallel download in there [21:53] rsalveti: this is why I hate autopilot [21:53] or android is just too slow [21:53] hahah [21:53] bfiller: yeah, can understand your pain [21:53] rsalveti: chasing shit that's not really an issue [21:53] yeah [21:55] alright, leaving for a bit to get some dinner, will be around later [21:55] good luck with autopilot :-) [21:57] robru: can you publish silo-017, testing complete there [21:57] bfiller, sure, thanks [21:59] robru: thanks, and silo-002 as well is ready to be published [22:00] bfiller, success on both counts! please merge and clean once they hit release pocket. [22:00] robru: awesome, will do [22:19] robru: mind approving silo-6 as well? [22:19] kgunn tested it, everything seems to be good there [22:19] we probably want to get this camera issue solved asap though =\ [22:19] but they are touching a different package [22:30] rsalveti: getting same failure as you [22:30] bfiller: right [22:32] rsalveti, ok [22:33] rsalveti, gonna need a core dev to ack these packaging changes [22:33] rsalveti, http://162.213.34.102/job/landing-006-2-publish/ [22:33] robru: fine, I can do it [22:34] I'll just publish myself then, asked because I'm still waiting folks to get to dinner [22:34] rsalveti, ah, didn't realize you were a core dev. in that case go ahead! [22:34] rsalveti, no wait, I can hit the publish button [22:35] rsalveti, just needed your go-ahead. somewhat circular ... ;-) [22:35] haha, got it [22:35] rsalveti, ok, it's published. please hit 'merge and clean' once you see it in release pocket [22:36] robru: awesome, thanks so much [22:36] rsalveti, you're welcome [22:46] robru, after some analysis I found it's only the changelog that is wacked-out in compiz because of the various embedded packaging branches diverging so I can get a simple fix up.... what do I do with the MP now??? [22:46] bregma, great, just add the new MP to the end of the list in the 'pending' tab of the spreadsheet. let me know once that's done and I can reconfigure the silo to include it. [22:48] robru, done [22:48] bregma, sorry what line was that again? [22:49] bregma, nm found it [22:50] bregma, ok, it's reconfigured. please hit the 'build' button on the silo 3 sheet [22:52] bregma is missing the Job/Build permission [22:52] gasjtag sadface [22:52] bregma, crap sorry. ok i can do it for now. [22:52] I was so excited, too [22:53] bregma, ok pay attention to here: http://162.213.34.102/job/landing-003-1-build/16/console this'll tell you if it has any merge conflicts or whatever. once it finishes building, please do some more testing to make sure that nothing else accidentally broke [23:20] robru: can I get a silo please for line 36? this is to unblock the camera-app AP test blocking the image [23:20] rsalveti: ^^^ [23:20] bfiller, sure [23:22] bfiller, camera-app is already in silo 8. you can't have more than once silo per project. do you want to add that MP to the existing silo 8? [23:22] bfiller, the other option is to jettison silo 8 and have just this one instead. [23:23] robru: didn't see that, sure we can add this MR to silo 8, should be fine [23:23] bfiller, ok. is there a certain merge order to avoid conflicts? please update line 32 and I'll reconfigure silo 8 for you [23:25] robru: on second thought after looking at that MR, I'd rather jettison silo 8 and just have the new MR [23:25] bfiller, ok sure [23:28] bfiller, ehh, clearing the silo is a bit slow. i'll ping you when the new silo is ready [23:29] robru: np, thanks === bfiller is now known as bfiller_bbiab [23:37] bfiller_bbiab, ok you got silo 2 now for camera-app. please click build. [23:39] bfiller_bbiab, meh, i'll click build since you're away [23:40] bfiller_bbiab, http://162.213.34.102/job/landing-002-1-build/32/console start testing once that's done [23:43] robru: awesome thanks === bfiller_bbiab is now known as bfiller [23:43] bfiller, you're welcome [23:44] bzoltan, please merge & clean silo 1 [23:46] robru, all my Unity7 landing stuff is still sane (on amd64), the arm build will take some more hours, what is the next step? [23:46] bregma, once the build finishes I have to hit the publish button. i've got an eye on it [23:47] bregma, then once the packages land in the release pocket, theoretically you should be the one to click 'merge & clean', but I guess you don't have access to the jenkins yet, so I'll take care of it for today [23:47] and for my next landing, I just create a new line in the spreadsheet and request a silo, correct? [23:48] bregma, yes exactly. ping me when the line has all the info and i can assign a silo for you [23:49] are people around over the weekend? [23:50] bregma, maybe... maybe not. I normally leave my IRC open but I might only check it a couple times per day. can't speak for anybody else. this weekend is trickier since I'm moving... [23:50] yer all slackers [23:51] bregma, tell that to the 12 hour day I pulled on monday ;-) [23:54] ah, you can get away with only 12 hours on a regular basis then? [23:55] bregma, well, i like to take some time for my personal projects... gotta have that work/life balance and all... [23:56] kgunn, please merge & clean silo 6 [23:57] ok, I gotta run to the grocery store so I can make myself some lunch. promise I'll be back in ~20 to deal with anything that might explode...