[02:05] === IMAGE 119 building (started: 20150303-02:05) === === chihchun_afk is now known as chihchun [06:51] alexabreu: it seems the rtm-013 was rebuilt before the trunk was properly updated, thus it's not publishable and needs another rebuild + testing instead === marcusto_ is now known as marcustomlinson === marcusto_ is now known as marcustomlinson_ === marcustomlinson_ is now known as marcustomlinson [07:48] Mirv: will probably miss the landing meeting as I have an appointment at school. [07:52] popey: ok === marcusto_ is now known as marcustomlinson [08:44] rvr, how did it fail ? [08:50] ogra_, sergiusens, robru: Could you take a look at http://pad.lv/1427559 to review a phablet-tools fix needed for automated sanity testing? [08:50] Launchpad bug 1427559 in phablet-tools (Ubuntu) "phablet-network requires NetworkManager, sudo, and wifi" [Undecided,New] [08:51] (patch already linked) [08:52] ToyKeeper, any reason you can not use the existing -n option ? [08:53] (we use it in the lab) [08:53] For one, it requires patching every tool which uses phablet-network... [08:54] (which expect phablet-network to "just work" with no options or input) [08:55] well, couldn't you just add a default for that file instead then ? [08:56] I suppose it could use an environment variable or dotfile to point toward a NM config file, and eliminate a few lines to parse the other file... [08:57] (and use that instead of '-n', when available) [09:00] ToyKeeper, http://paste.ubuntu.com/10512922/ [09:00] err [09:00] http://paste.ubuntu.com/10512925/ [09:01] the second one is the right way around :) [09:04] ogra_: Are you suggesting it as a patch, or suggesting that each affected person modify /usr/bin/phablet-network? I'm trying to avoid the need to modify files installed by apt-get. [09:05] huh ? i suggeted to change your MP :) ... but there are bugs ... one sec [09:05] ogra_, what you propose makes no difference with current behaviour because you always have to provide a network file as argument to -n and the default will never be used [09:05] ToyKeeper, http://paste.ubuntu.com/10512940/ this one should work [09:05] jibel, yes, fixed [09:06] Okay, I'm fine with a different method/patch... so long as it will "just work" with no changes to files from the distro or tools which rely on phablet-network. (so, behavior specified by env var or checking for a special file) [09:07] ToyKeeper, yeah, no prob with changing the coe ... i just found your change a bit huge for the task :) test my change, if it works for your usecase we can land it [09:07] *code [09:14] * popey returns [09:16] ToyKeeper, maybe using the network file provided on the command line, then ~/.phablet-network, then the system configuration then fail would do what you want. It won't change phablet-network's behaviour for current users, no change to the argument, no env to specify, and minimal changes to phablet-network and fixes the problem for automated tests running on machines without NM or without a Wifi [09:16] connection. [09:17] jibel: Yup, that's what I was just doing. :) [09:18] * jibel re-reads your patch :) [09:19] I mean, what I was just redoing; no point having two slightly different formats for the wifi auth file. [09:21] jibel, that is what my patch does ... [09:22] well, in a different order ... if ~/.phablet-network exists it gets used, else it uses NMs default file unless there is -n [09:22] http://paste.ubuntu.com/10512940/ [09:25] ogra_: Thanks. Mostly, I wanted to make sure the idea was okay, and that someone on the project was aware of the patch. :) [09:26] thanks for bringing it up :) [09:26] ogra_: New patch is uploaded, much simpler than the first, and does as jibel described. [09:27] one small nitpick, can you put the actual filename in the usage line too ? [09:27] (or uses NM-format wifi config from $DEFAULT_NETWORK_FILE which defaults to ...) [09:27] ogra_: It *is* in the usage line. Did you try running it? [09:28] i dont see usage pointing to ~/.phablet-network in your code [09:29] only to the var ... it should tell you that there is a default value for the var [09:29] The variables get expanded when it prints the help string. [09:29] * ogra_ slaps forehead [09:29] sorry ... [09:29] i need more coffee :) [09:30] ToyKeeper, approved [09:33] I can't say I'm fully awake either... [09:36] :) [10:41] ogra_: ping [10:41] rvr, hey, so what failed exactly ? [10:41] ogra_: push/pull [10:41] ogra_: They work when the screen is locked [10:42] hmm, did you reboot after installing the package ? [10:42] Yes [10:42] But let me recheck again [10:44] After reboot [10:44] $ adb push diff.diff /home/phablet [10:44] 645 KB/s (26568 bytes in 0.040s) [10:44] hmm, did you ever install that phone with --developer-mode ? [10:45] check if there is a dev-mode override file in place, it is called /userdata/.adb_onlock [10:45] that would disable the lock screen check altogether [10:48] ogra_: Let me see [10:49] ogra_: Yes, the file exists [10:49] remove it and reboot [10:49] so we know at lest the behavior is correct with the file in place :) [10:49] :D [10:50] i should have added that to the test plan, sorry [10:51] $ adb push diff.diff /home/phablet [10:51] error: closed [10:51] perfect :) [10:51] Perfect [10:51] (sadly the error message is hardcoded on the PC side ... i would have liked something like "error: screen locked" ) [10:52] The other tests passed, I'm approving the silo [10:52] thanks :) [11:08] Mirv: we have started the final Vivid landing ... I hope it will make it [11:08] bzoltan_: hey! The final big release of UITK to vivid - does that have any features? [11:08] * sil2100 assigned a silos [11:08] *silo even [11:08] bzoltan_: but if it's feature-packed, then we'll probably have to file an FFe for it [11:09] FFe's are the cool thing this cycle [11:09] sil2100: at this phase all new UITK festures address long pending bugs [11:12] sil2100: it is a big one, packed with 13 bugfixes. Who's call is to make an FFe or not? [11:13] It's usually the release team deciding, as if we publish it'll require their approval - if they find that it requires an FFe, it needs to be filled in, but it's always best to try knowing that beforehand [11:14] Let's ask the release team, sometimes they give us FFe's quite easily for typical touch/next components [11:14] bzoltan_: is the UITK used anywhere in the desktop, besides Desktop Next? [11:15] sil2100: our own QtCrator does, but not the version this landing has. [11:15] sil2100: no other application depends on it [11:17] bzoltan_: good luck! [11:23] Mirv: sil2100: i have added the gles branch too. Would you please reconf teh silo? [11:24] bzoltan_: sure ,on it === MacSlow is now known as MacSlow|lunch [12:00] bzoltan_: you'll need to bzr rm debian/patches in your -gles branch, since the real fix is in staging now and conflicts [12:05] Mirv: OK, thanks [12:05] ogra_, sil2100: so it appears there is a custom-tarball option in ubuntu-device-flash it just doesn't work [12:05] * sil2100 off to lunch [12:05] davmor2, time for a bug then [12:06] ogra_: indeed === chihchun is now known as chihchun_afk [12:46] davmor2, I filed bug 1427667 [12:46] bug 1427667 in goget-ubuntu-touch (Ubuntu) "option --custom-tarball doesn't work" [Undecided,New] https://launchpad.net/bugs/1427667 [12:47] jibel: nice === MacSlow|lunch is now known as MacSlow [13:32] Mirv, ack (for silo 13) === chihchun_afk is now known as chihchun [14:02] imgbot, status 119 vivid [14:03] Status: succeeded, Started: 2015-03-03 02:02:09 UTC, Finished: 2015-03-03 02:56:07 UTC [14:03] Build URL: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch/+build/21663 [14:03] Changelog: http://people.canonical.com/~ogra/touch-image-stats/119.changes [14:27] sil2100, rsalveti, once the livecd-rootfs upload i just did lands in the archive, i want to do a re-build (need the log info) [14:28] for vivid that is [14:30] sure [14:35] dbarth, what's the status of rtm silo 10? [14:36] dbarth, i'd like to prepare another landing for settings soon [14:46] balloons: what's happening with https://code.launchpad.net/~nskaggs/ubuntu-calendar-app/fix-infloop-ap-trunk/+merge/251122 ? [14:47] balloons: It appears to be blocking https://code.launchpad.net/~pkunal-parmar/ubuntu-calendar-app/LiveEventModification/+merge/247711 [14:47] (which I am gettng increasingly worried about) [14:51] * balloons erases his original comment [14:52] popey, specific to that merge, I created it to help kunal's merge and fixup the tests. I filed several more bugs as well around calendar as you know. It seems trunk is not stable [14:53] ogra_: sure thing [14:54] popey, I was also going to mention calendar seems to have struggled in the past, but we've done work to make it well tested and working. It seems to break down over time [14:55] I can only assume the previous tests were not completely stable and they are changing code and not tests as time goes on [14:55] sil2100: 5.4.1 not all sun and flowers, so no early signoff testing this week at least. no other problems seen yet but there's a problem with the keyboard for unknown reason. [14:56] sil2100: if there are any big issues, it would mean I'd land it to vivid after the fork, not before... [14:56] if that publisher will ever move ... [14:56] Mirv: ouch, you mean the OSK doesn't work properly? [14:56] popey, the weird part is how trunk manages to get broken tests in it. This whole 'run it again' when jenkins doesn't pass it is how that happens. [14:57] balloons: I landed a few merges a couple of weeks back and had to retry a few times [14:57] sil2100: you could say so... a crash bug #1427710 - tsdgeos might have time to look at it at some point. but it better have a good explanation (plausible, there is always some room for something not noticed) or otherwise Qt 5.4.1 starts to sound too risky. [14:57] balloons: this one just refuses to pass [14:57] bug 1427710 in maliit-framework (Ubuntu) "A maliit-framework segfault with Qt 5.4.1" [Undecided,New] https://launchpad.net/bugs/1427710 [14:58] sil2100: during the meeting I hadn't yet tried to _type_ anything, just playing media and swiping along :) [14:58] popey, right.. I've re-run things as well, but doing that rather than fixing the issue does lead to messes like this [14:58] hah ;) [14:58] balloons: is there someone who can help us clean these up? [14:59] Mirv: sil2100: need to talk to Saviq later to see if i can sneak some time into this [15:00] popey, I mention that they have struggled because I've seen things removed / commented out in the tests when I went to correct the loop issue in my mp [15:00] sil2100: meanwhile, we do have FFe granted... [15:00] Mirv: oh! [15:00] balloons: we need a way forward, because right now we're stuck and nothing is landing [15:00] popey, yes, I noticed Carla actually has been submitting calendar mp's before I even asked her or Daniel to look [15:03] popey, this is marked critical, so in theory it should be first on the list for folks: https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1426183 [15:03] Launchpad bug 1426183 in Ubuntu Calendar App "rev593 (trunk) autopilot tests experience random failures" [Critical,Triaged] [15:04] :( [15:05] aww, now I feel sad [15:06] welcome to my world [15:26] kenvandine: you could take the branch if you want; i'd still like to get dobey's approval on that one though [15:26] brb [15:26] what's up? [15:27] dbarth, i'll leave it to you, i mostly wanted to know when you thought it would get an ack... so i can plan when i can do my landing or if i should try to get in front of you in line [15:27] dobey, rtm silo 10 [15:27] well the branch is already approved [15:28] there is some other issue in rtm that makes it sort of not work right though [15:28] i'm asking about the silo [15:28] or well, i'm not sure if it's another issue in rtm, or a feature [15:29] the code is correct though [15:47] dobey: so the hook that cleans up the account acl is fine to land ? [15:48] wait, what? [15:49] no, i don't think we should land that [15:50] why is that in there? [15:52] that code doesn't exist in vivid, so i don't think we should land it in rtm. and we don't fully understand what is happening on boot in rtm, so landing a "fix" without understanding the issue seems wrong to me. [15:55] === IMAGE 120 building (started: 20150303-15:55) === [15:58] mardy: won't this hook fail anyway, because it's unconfined and unconfined isn't in the acl, so it can't actually do queryInfo() on the identity? [16:20] well i need to get lunch [16:26] jibel, could you try image 120 (once it is done) wrt /var/log ownership ... according to the buld log it is definitely syslog owned now [16:27] ogra_, what is 120? 130 is in devel-proposed for krillin [16:27] jibel, ah, the both goes after mako versions :) [16:27] *bot [16:27] ok [16:28] jibel, the image that is just building ... should be done soon [16:28] I'll try whatever is in proposed [16:47] trainguards, can you please remove qtmir{,-gles} from vivid silo 19 [16:48] Saviq: sure, from the PPA you mean? [16:48] sil2100, yes, because the build job lied to me again :P [16:48] * Saviq tries to find the bug [16:48] Oh, so it seems it still doesn't remove packages when reconfiguring ;/ [16:49] yeah [16:51] Saviq: should be gone from the PPA now [16:51] om26er, ↑ [16:51] sil2100, thanks [16:52] Saviq, great, thanks [17:17] sil2100: my krillin dived into a reboot loop and even the recovery mode does not bring it out [17:18] ogra_: ^ [17:18] or anybody :( [17:20] === IMAGE 120 DONE (finished: 20150303-17:20) === [17:20] === changelog: http://people.canonical.com/~ogra/touch-image-stats/120.changes === [17:20] bzoltan_: huh? [17:20] bzoltan_: how? What did you do to get it in this state? [17:22] sil2100: the AP tests of the dialer app ... it does it all the time [17:22] sil2100: but this time I can not do anything with it [17:23] ogra_: ^ do you know what can be done in this case? [17:23] nope [17:23] well, first of all file a bug against that ap test [17:23] then try to get into fastboot mode and flash the open recovery.img [17:23] from there you should be able to do u-d-f [17:23] ogra_: sil2100: anything what could bring back this device to a working state? [17:24] ogra_: how to flash the open recovery.img? [17:25] bzoltan_, by following the instructions from the mailing list [17:25] ogra_: with what subject? [17:25] * bzoltan_ gets hundreds of mails on many ML [17:25] something about adb and recovery [17:27] ogra_: I am not much closer... [17:30] popey, ok, all links restored for rtm [17:31] yay [17:31] thanks [17:35] ogra_: sil2100: and where to get the recovery.img from? [17:35] bzoltan_, click the link in the mail [17:35] it has all instructions [17:49] ogra_, on 131 /var/log is owned by root:syslog [17:49] \o/ [17:50] what changed? [17:50] the code used "chgrp syslog /var/log" [17:50] not sure why that didnt work [17:50] i switched it to"chown root:systlog /var/log" [17:50] (without the typo :P ) [17:51] so we should be fine now ... [17:51] what scares me a bit is that there could potentially be other dirs we dont cover like this [17:51] syslog is just sticking out because we all look at it all the time [17:55] indeed that was my concern with this bug [17:55] right, but not much we can do except keepin our eyes open [17:57] ogra_: I did not find "the" mail .. I have 11k mails in that folder and I did not find the one with instructions on how to flash the recovery.img [17:58] bzoltan_, i get between 600-800 mails per day, dont try to get into a pissing contest with me :P [17:58] bzoltan_: "adb no longer available in recovery on krillin/vivid (and rtm too)" [17:58] that's the subject [17:59] ogra_: you win me by far great master :) but that does not help my device [17:59] bzoltan_, well, what popey said [17:59] * popey wins at making the google mail bots search his mail [17:59] lol, i wont give them access to my imap server :) [18:00] ogra_: how tricky .. it was on the phablet ML [18:00] ya [18:00] (i'm pretty sure i would have found it in minutes if i had the time for searching) [18:03] bzoltan_, ogra_: Can I join in the pissing contest I get around 800-1200 emails a day when I take a week off it takes 3 weeks to get fully caught up again. And even I know about the adb not working any more mail. Also I have several folders around the 20-30000 email mark and 3 over 50,000 and I haven't been here as long as ogra_ so I assume his folders are bigger still :D [18:04] my whole /var/mail/ogra on the server contains around 5mio mails [18:04] dating back to before i started at canonical [18:04] davmor2: ogra_: with 3years I am junior here ... but still I am surprised that ML archive here is considered as documentation storage :) [18:04] ogra_: yeah but your old dude ;) [18:05] * ogra_ shakes his cane [18:05] get off my lawn ! [18:05] can't you see the sign [18:05] :D [18:06] bzoltan_, well, it helped me a lot to have it over the last decade [18:06] and evolution is reasonable fast at searching piles of mail [18:06] even at that size [18:06] ogra_: claws is blistering quick [18:07] ogra_: searching in mails my client is fast too.. once I figure out the right folder :) [18:07] bzoltan_: just search them all ;) [18:07] * bzoltan_ checks the oldes mail ... yes it came in 96 [18:08] searching in /dev/null is the fastest evar [18:08] dobey, yeah, but the results are so unsatisfying [18:08] s/un// :) [18:08] haha [18:09] the oldest mail in my inbox is from "?" [18:09] yay spam [18:09] lol [18:12] oldest actual mail i have is i think ~1997ish [18:12] man I wasn't even born then [18:12] mine is from a mailing list [18:13] bzoltan_, ogra_: my first mail on my home server is 2006 and in gmail is 2004 -ish [18:14] Laney: bigRon at our lug can tell you about the days they invented the interwebz ;) [18:16] davmor2: I am confused with my records... I wrote a mail server and client in 92 for novel netware 3.1 without nowing about the existence of internet/email do those mails count? [18:16] * bzoltan_ gets sensitive about the golden past === alan_g is now known as alan_g|EOD [18:42] bzoltan_: hahaha [18:51] ogra_: fastboot - u-d-f - reboot cycle again ... [20:26] does anybody know what the hack I do wrog here https://ci-train.ubuntu.com/job/ubuntu-landing-003-1-build/147/console ? [21:06] bzoltan_: yeah, -gles isn't configured in the silo [21:28] robru: do we need tro reconf? [21:29] bzoltan_: yeah, seems so. one sec [21:30] bzoltan_: ok try now [23:30] tedg [23:31] nuddy [23:31] buddy [23:31] lol [23:31] robru, I'm getting ready to head out, is that a purposeful ping? :-) [23:31] tedg: yes. you apparently didn't manage your silo conflicts very well [23:31] ? [23:31] tedg: there it is ^ [23:32] tedg: you had url-dispatcher in silo 4 and 8 [23:32] Hmm... I don't have an RTM silo. [23:32] tedg: you published 8 and then didn't rebuild 4. [23:32] tedg: but you do? http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=tedg [23:32] robru, That branch landed, someone must have reallocated the silo after I deallocated it. [23:33] Perhaps a race condition [23:33] (human) [23:33] Let me kill it. [23:33] tedg: weird, it was built by bfiller: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-004-1-build/104/console [23:34] tedg: ok well if you're sure it's wrong, you can kill it. also the mp is merged, so that's curious. [23:34] I marked it as not ready anymore. [23:34] tedg: thanks [23:34] robru, The MP was in silo8, it landed with the webbrowser changes. [23:35] I originally had a silo for the MP so that the browser folks could test, but then they just worked on vivid since it was there already. [23:35] Anyway. Useless history :-) [23:35] robru, Thanks for mentioning it, cleaned it up :-) [23:35] 'night folks. [23:35] tedg: night