=== Laney is now known as Guest69163 === wgrant_ is now known as wgrnat === wgrnat is now known as wgrant [03:05] === trainguards: RTM IMAGE 40 building (started: 20140915 03:05) === [04:25] === trainguards: RTM IMAGE 40 DONE (finished: 20140915 04:25) === [04:25] === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/40.changes === [04:52] May I ask for a silo to the line 58 ? [04:53] Mirv: Do you know who from QA team is in the CE timezone? The silo9 is ready to land. [04:55] It may be a little while... looks like 4 silos are in queue before rtm-009. [04:55] I'll be trying to get through some of those before I sleep though. [04:55] (and others should be around in ~3 hours) [05:09] ToyKeeper: Is it possible to re-prioritize the UITK silo? This bug is fixed and it was proven to be a dialer app bug - https://bugs.launchpad.net/dialer-app/+bug/1368295 [05:09] Launchpad bug 1368295 in dialer-app "latest UI toolkit causes visual glitch in Recent tab of dialer-app" [Critical,Confirmed] [05:09] ToyKeeper: The test logs are here - http://people.canonical.com/~bzoltan/ap-2014_09_12-21_44_44/ [05:10] ToyKeeper: By the way ... that^^ bug is a showcase that just because a problem drops out when one adds the UITK silo it is still not sure that the regression is caused by the UITK. [05:15] bzoltan1: It's also a showcase for why QA tests things regardless of what anyone says about a change being bug-free. BTW, is there an AP test now for the gap brendand discovered? [05:18] bzoltan1: I think the earliest one is brendand around 0800 UTC [06:08] ToyKeeper: I do not know. Renato should tel. [06:08] tell [06:16] ToyKeeper: May I ask you to clean up the UITK Test Plan doc page? I think it should be a clear document and not a discussion page. We can move the discussion to the mailing list for example. [07:50] asac, do you know if it was a wnated thing that there are no more mako and krillin builds at all for develo-proposed ? (only these two arches get ignored) [07:55] ogra_: err [07:55] ogra_: no [07:55] how comes? [07:55] system-image only imports the other areches [07:55] no idea why [07:55] feels like an oversight [07:55] since when? [07:55] i guess it is related to the custom tarball stuff that stephane changed [07:56] friday was the last build [07:56] yeah [07:56] so guess thats a bug [07:56] lets wait for him to get up [07:56] right [07:56] ogra_: was there anything else you guys pinged me on? lost my bip server/logs (dont even know if it was on earlier today, had to kill it) [07:57] yeah, bip behaved wried, i guess due to the hacks [07:57] i had the same here [07:57] hacks? [07:57] i didnt ping you ... [07:57] should i be bworried? [07:57] yeah, freenode was hacked [07:57] oh [07:57] nice [07:57] if you use one, change your password [07:57] ogra_: do you see backlog if i was on earlier today? [07:57] the nickserv one [07:57] or just joined at 9:47 [07:58] ok let me do that [07:58] i see you were on and off [07:58] but so was i, so my data isnt really meaningful :) === ogra_ is now known as ogra === ogra is now known as ogra_ [08:00] * ogra_ updated his as well === kgunn is now known as Guest60061 [08:00] i dont want to change my password :( [08:00] i will never remember [08:00] haha [08:01] * asac thinks about his backup strategy [08:01] write it down in Passwords.txt on your desktop and you will never forget it again :) [08:01] yes [08:01] but [08:01] :) [08:01] how is my backup strategy [08:01] :P [08:02] you ask one of the hackers if you forgot it :) [08:02] i'm sure for a small fee they will ... [08:02] * asac thinks he should backup his gpg key at least another time ... i am sure i have it somewhere on a cd that is probably bad now [08:04] just freenode hacked? or oftc too? === Guest69163 is now known as Laney [08:05] i think just frenode [08:05] maybe they dont know yet ;) [08:06] heh, could be [08:06] freenode was all over the press though [08:09] whats the best incremental backup tool for doing that to a usb disk? [08:09] nowadays [08:10] rdiff-backup i remember [08:11] dunno, i use plain tarballs pushed to a NAS [08:11] hmm. not very efficient :) [08:11] but rock solid to recover ;) [08:24] monday, so it's new device tarball day [08:24] http://people.canonical.com/~jhm/barajas/device_krillin-20140912-23825b8.tar.xz [08:24] + http://people.canonical.com/~jhm/barajas/device_krillin-20140912-23825b8.changes [08:24] ogra_, ^ [08:25] john-mcaleely, awesome ... [08:26] oh, wifi changes [08:26] hmm, i'm not sure the new initrd has even been landed in the other arches [08:26] john-mcaleely: let's get someone from QA giving it a test ride then ;) Thanks! [08:26] sil2100, thank you! [08:27] hmm, no, it hasnt yet [08:28] * ogra_ wonders why his krillin doesnt offer any RTM updates [08:28] sil2100: hello :) ... how are we doing this? do you have power to create a new card in trello to put this manual sign off into the pipeline? [08:31] GRRRRR [08:31] triple popey! [08:31] Chrome is unusable here [08:31] we're gonna get so many app uploads today [08:31] "Aw, snap" every time [08:31] use a proper browser [08:32] shut your noise [08:35] popey: disable extensions :) [08:52] asac: sadly not ☹ all extensions disabled [08:52] reallly [08:52] bzoltan, is the 'fix' that will land in dialer-app really a fix or is it just a workaround? [08:52] odd [08:52] :) [08:53] brendand: it was a bug in the app [08:53] brendand: i expect that the fix is a fix === Chipaca` is now known as Chipaca [09:01] bzoltan, i dunno - was dialer-app doing something clearly wrong according to the specification? [09:01] brendand: I do not know the details.. but something like that [09:02] bzoltan, you know there could be other apps doing the same thing [09:02] brendand: I do not know. If they do and they have tests then they will fail. I can not do code review for all apps :) [09:03] brendand: That is what I told last week. The apps do crazy stuff and as the UITK is getting better those hacks drop out... [09:06] bzoltan, it says it's caused by setting flickable property after the page is created or something like that [09:06] brendand: yes [09:08] sil2100: well, for example, this one I'm trying to publish right now (after checking that yes the change is isolated and no versions are being skipped) https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-008-2-publish/21/console [09:08] sil2100: that should be also a new silo [09:08] sil2100: and that's a new silo [09:09] bzoltan, i need to talk to renato a bit about it [09:09] brendand: This is a very typical scheme ... can not even blame anybody. It is expected. The UITK is under development and the apps started to work with the 0.1 version of the UITK long time ago and they used private APIs, applied smart hackarounds to deal with the shortcomings of the UITK, etc .. as the UITK improves these hacks become bugs.... [09:09] Mirv: let me check the config! [09:09] brendand: please talk to him. And ask zsombi too if you have questions. It is a complicated issue :) [09:10] sil2100: and just to queue more to you, I've seen examples of merge & clean not working without ignore_missing_projects even though publish went fine: https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-006-3-merge-clean/4/console === vrruiz_ is now known as rvr [09:10] uuuh [09:11] Mirv: I'm looking at this silo 008 and hm, it somehow has nothing in the backend (almost) [09:12] Mirv: ok, I have no idea what happened, but watch_only was enough to get the .project files back - maybe there is something buggy somewhere that causes it not to save those [09:13] Mirv: I'll investigate this in the meantime, but for now just watch-only in such cases and then publish should be fine === davmor2_ is now known as davmor2 [09:24] sil2100: ok! [09:38] davmor2, my krillin locked up again - is that still meant to be happening? [09:38] davmor2, swipe gestures only [09:38] brendand: no it's meant to be fixed [09:38] Saviq: ^ [09:39] davmor2, it's definitely not here [09:39] davmor2, didn't Saviq go on holiday? [09:39] Yeah, we're SCREWED [09:39] * sil2100 panics without Saviq around [09:40] sil2100: man now who do we pick on [09:43] * sil2100 checks Saviq's leave e-mail [09:45] brendand, there are MPs but it is not fixed [09:46] brendand, bug 1295623 targeted for the 2014-09-25 [09:46] bug 1295623 in unity8 (Ubuntu) "Sometimes input breaks and only edges are responsive" [Critical,In progress] https://launchpad.net/bugs/1295623 [09:47] davmor2: let me think, greyback might be the right person to pester! [09:47] sil2100: mzanetti and kgunn for unity8 [09:48] how can I help? [09:48] It should be fixed. brendand can you get a backtrace of were unity8 in it's locked state? [09:48] =were [09:48] greyback: well, its not fixed for the dash [09:49] jibel: did the shell (i.e. launcher, indicators) lock up or the dash? [09:53] mzanetti, only the dash [09:54] jibel: ack, known, dandrader is working on that [09:57] mzanetti: sadtrombone.com [09:58] davmor2: indeed... [09:59] mzanetti: so you now know you're getting all of Saviq 's "It's your fault" right ;) Well done that man :) [09:59] yes, I know :D [10:00] davmor2: in this particular case though I'd say "I told em like 10 times that the patch doesn't fix it for the dash" [10:00] mzanetti: ouch [10:00] sil2100: ^ [10:00] so blocker still [10:01] davmor2: hmm... current devel image has th issue already [10:01] I'm not sure what the rules are, but if the rules say "no new issues" then IMO we should release the partial fix already [10:02] mzanetti: the partial fix went in on Friday but didn't fix the scope which is what was locking up anyway :( [10:03] mzanetti: this is RTM that we base decision on now not utopic's branch [10:03] ah [10:03] mzanetti: that will also mean that we are likely to go into traincon0 which will make that fix more imperative if that helps with work allocation [10:04] I'll find out what ETA we have for fixing the dash too. I hope its not long any more. Given that we have a way to repro and know what the issue is [10:04] mzanetti: cool :) [10:05] sil2100: still want me to look at promotion or shall I get on with silo testing? [10:06] grrr [10:08] davmor2: how does this look like from the users perspective? Is the input bug rarely reproducible or is it still as much of a pain? [10:10] sil2100: well when it happens it's a pain in the arse, only recourse is to reboot the phone, I've not seen it over the weekend however 3 others have so fairly annoying for users I would imagine [10:10] I see it quite often tbh [10:11] davmor2: secret hint just for you: open terminal app (the launcher should still work) and type "restart unity8-dash" [10:11] * ogra_ sees it a lot less since dash became an app [10:12] mzanetti: yeah I don't have terminal in my launcher, I need to keep it stock for testing I add stuff afterwards, that's the difference between QA and Engineer :) [10:12] Damn === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss [10:14] sil2100: besides it gives mzanetti time to fix tagger so it actually launches....yes there's that nick again [10:14] davmor2: that's a bug in the camera backend [10:15] mzanetti: booo! transfers blame to bfiller's team [10:15] mzanetti: do you have a bug number for that by any chance? [10:16] hmm, no... [10:17] is the camera actually working? [10:17] * mzanetti boots that device [10:17] mzanetti: yes [10:18] strange... all my apps crash now when trying to access the camera, without me having them changed... wonder what changed [10:19] Damn #2, if we don't promote #40 then we need to go into TRAINCON-0 [10:21] Mirv: could you please upload http://s-jenkins.ubuntu-ci:8080/job/terminal-app-click/lastSuccessfulBuild/artifact/out/com.ubuntu.terminal_0.5.147_armhf.click when you get a moment, thanks. [10:21] sil2100: ♫ Traincon0 here we come, do-dah, do-dah. Traincon0 here we come, do-de-do-dah-day ♫ [10:21] Mirv: http://s-jenkins.ubuntu-ci:8080/view/click/job/dropping-letters-click/lastSuccessfulBuild/artifact/com.ubuntu.dropping-letters_0.1.2.2.63_all.click also. [10:22] Mirv: (if there's a preferable way for me to ask this, better for your workflow or whatever, just say) [10:25] davmor2: are you gonna be testin' my silo by any chance? [10:26] cwayne: no, not straight away. I need to finish image test first before we can consider silo testing :) [10:27] mzanetti: btw. do you know of any ETA for the dash input bug fix? [10:27] davmor2: oh i didnt mean right away, just in general :) i wanted to coordinate with whoever did it so i'd know when it lands so I can add stuff to the custom tarball :) [10:27] om26er: hey! [10:27] sil2100, Hi! [10:27] om26er: did you notice bug 1295623 on mako during exploratory testing? [10:27] bug 1295623 in unity8 (Ubuntu) "Sometimes input breaks and only edges are responsive" [Critical,In progress] https://launchpad.net/bugs/1295623 [10:28] sil2100, yes, that happens frequently [10:28] om26er: on latest rtm proposed image on mako? [10:28] cwayne: ah right so it is likely to either be me, brendand or vrriuz in Euro timezone or ToyKeeper or elopio_ in US [10:28] we didnt produce devel-proposed image for some reason over the weekend [10:28] asac, didn't test on the latest rtm image, I just flashed it on my phone. [10:29] sil2100: not yet. Daniel will be online soon and I'll find out [10:29] om26er: which one did you test before? [10:29] asac, latest utopic image that was till last night [10:30] asac: om26er tests rtm every 2 days [10:30] asac, sil2100 239, that was. [10:30] right, but utopic image wasnt produced [10:30] asac: and every other day he tests utopic [10:30] for a couple day [10:30] asac: system image had a hiccup see sil2100 he announced it in the landing meeting. [10:30] utopic-proposed is stuck on fridays image [10:30] are we sure that the image he had has the input fix? [10:30] right [10:31] * ogra_ is pretty sure the fix entered utopic eralier though [10:31] landings usually take several days to migrate over [10:31] and this one took specifically long thanks to a oxide dep [10:31] sil2100, on rtm 39 I just reproduced the bug with Michael's steps. [10:32] The input fix should be in devel-proposed earlier, as the QA sign-off to rtm took much longer due to the additional deps [10:32] hmm [10:32] right [10:33] last upload of unity8 was on wed ... [10:33] and it entered the images on thu [10:33] (and then rtm on fri.) [10:33] asac: the fix isn't complete we were just talking about this. :( mzanetti was going to ask around to figure out when the rest of the patch could land [10:34] do they have a patch? [10:34] mzanetti: ? [10:34] we want that cherry picked and fast landed at best [10:34] "fast landed" heh [10:34] asac: I'll find out when the person working on it comes online. should be any minute now [10:34] There is a merge that is prepared, but not yet ready - we would need Daniel to be online [10:35] ogra_: well, compared to land in staging branch first [10:35] and wait till that is ready [10:35] ogra_, have you seen that phablet-config writable-image now spews lots of 'error: device offline'? [10:35] well, instead we land in staging distro first :) [10:35] ogra_, i think it still works though [10:36] brendand, looks like a bug in phablet-network, i only saw it on manta on the weekend [10:36] brendand, please file something and assign to me [10:37] dev mode saw some improvements that i cant test with a mako image yet, tthanks to the image builder breakage [10:39] ogra_, do we need to do something special to run commands as root with adb shell? [10:39] adb shell "echo $password" | sudo -S " [10:40] (as i wrote in several mails :P ) [10:40] and if you are in the shell interactively just sudo indeed :) [10:41] ogra_, yes i remember you wrote that - just not in what context :) [10:41] :) [10:46] cihelp: Hi! Some kind of network(?) issues are blocking Mir CI jobs: e.g. https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/2772/console . Any ideas? [10:46] hi alf_ :) [10:46] alf_: do you think https://code.launchpad.net/~dandrader/qtmir/frozenApps-lp1295623/+merge/234393 will fix our input issue? [10:46] asac: hi :) [10:46] brendand, btw ... http://paste.ubuntu.com/8349605/ thats on 239 mako with the latest packages manually added [10:46] or is that unlikely and we can start digging our grave? [10:47] input issue is what has repro instructions in bug 1295623 [10:47] hehe [10:47] bug 1295623 in unity8 (Ubuntu) "Sometimes input breaks and only edges are responsive" [Critical,In progress] https://launchpad.net/bugs/1295623 [10:48] ogra_, so another question you probably already answered in an email that i vaguely remember - what do we need to do to phablet-test-run to get that working? [10:48] nothing i thought [10:48] oh? [10:48] we use it in smoke testing, there it works [10:49] brendand: you need to juggle muppets, while chanting please work, please work, please work ;) [10:49] psivaa_, did you do anything in ci to make phablet-test-run work? [10:49] brendand, and we obviously had people use it for the last weeks ... [10:49] at home ... or how does QA verify stuff ? [10:49] alf_: if you are unfamiliar with all this then dont bother ... was just hoping for a confident voice :) [10:49] ogra_, yeah - seems unlikely we wouldn't have noticed it [10:50] ogra_, well i'm following the instructions on the wiki: https://wiki.ubuntu.com/Touch/Testing [10:50] hmm [10:50] brendand, how does it fail ? [10:50] ogra_, but i get http://paste.ubuntu.com/8349627/ [10:51] ogra_, clearly permissions related [10:51] right [10:51] sil2100, ping [10:51] tvoss: pong [10:52] brendand, aha [10:52] adb shell 'echo ubuntuci |sudo -S bash -c '\''echo phablet ALL=\(ALL\) NOPASSWD: ALL > /etc/sudoers.d/phablet && chmod 600 /etc/sudoers.d/phablet'\''' [10:52] brendand, from smoke testing ... [10:53] ogra_, that should be added to that wiki then i suppose [10:53] i guess we should promot for the device pw in phablet-test-setup and integrate something like this [10:53] asac: I am not familiar with it, but in any case don't pick up the shovel just yet :) It seems the mp covers the second aspect of the input problem, but can't say for certain myself. [10:54] *prompt [10:54] asac: can't say for certain myself if it is a final/total fix [10:54] popey: dropping-letters + terminal. this is the preferred way, they go neatly to my 'hilight' window and I can pick them up at a suitable moment. [10:54] uploaded, that is. [10:54] Mirv: great, thanks. [10:55] alf_: yeah. maybe there is a third part too :) [10:55] thanks [10:55] alf_: hope cihelp helps soon [10:55] if not ping ev directly after a while [10:55] asac: ack, thanks [10:57] brendand, what device, channel and image version was bug 1369504 ? [10:57] bug 1369504 in phablet-tools (Ubuntu) "phablet-config writable-image spews lots of 'error: device offline' messages - but still seems to work" [Undecided,New] https://launchpad.net/bugs/1369504 [10:57] i'm actually pretty sure the new adbd fixes this [10:58] it just didnt make it into mako/krillin thanks to the system-image breakage [10:58] ogra_, updated with 'system-image-cli -i' [10:58] on what arch and channel ? [10:59] (mako, krillin ? rtm or utopic) [10:59] Mirv: http://s-jenkins.ubuntu-ci:8080/job/music-app-click/lastSuccessfulBuild/artifact/out/com.ubuntu.music_1.3.625_all.click please. [11:08] alf_: looking at it whilst rebuilding the job [11:08] popey: music done [11:08] psivaa_: thanks [11:09] thank you Mirv [11:11] * ogra_ wonders what that garbage at the end of sil2100's last mail is [11:12] ogra_: what garbage? [11:12] evoolution shows me ten lines of garbage at the bottom [11:12] ogra_: and which e-mail [11:12] the one to phablet»@ [11:12] The reminder mail [11:12] yeah [11:13] hmmm, here it looks fine on my outbox [11:13] ogra_: fine here [11:13] bah [11:13] why is evo on trusty so broekn then :( [11:14] ogra_: because it is evolution? I moved to claws ugly but it just works ;) [11:14] davmor2, calws doesnt get along with 5mio mails on my imap server ... [11:15] neither does thunderbird ... they are useless if you have a big archive on the server [11:15] and evo is usually super reliable for me [11:17] yeah, in the ML archive it looks fine too [11:17] weird === MacSlow is now known as MacSlow|lunch [11:29] dbarth_: MP approvals https://ci-train.ubuntu.com/job/ubuntu-landing-001-2-publish/26/console [11:38] fginther, around? [11:40] * sil2100 lunch [11:50] Mirv: done [12:04] sil2100, or Mirv ^^^ line 74, pllease assign me an rtm silo [12:04] -l [12:08] sil2100: asac: hey. we have a branch which is said to fix the dash too: https://code.launchpad.net/~dandrader/qtmir/frozenApps-lp1295623/+merge/234393 [12:08] code looks good to me on a first glance. will to a test run in a bit and let you know [12:09] looks like we're going to get this today still [12:15] ogra_: all the rtm silos are full :) [12:16] sigh [12:16] ogra_: oh 2 just freed up like magic :) [12:20] \o/ [12:21] mzanetti: ok, let's do it like this... once you approve the branch, we'll prepare both ubuntu and ubuntu-rtm silos for it [12:22] mzanetti: we'll build it for both and please first test it for ubuntu-rtm [12:22] mzanetti: cool. thats awesomee news. dont rush, test thoroughly [12:22] alf_: fyi, still looking at the network issue [12:22] sil2100: works for me... Note that I didn't do landings in a while so bear with me if it takes me a bit to figure details during the landing process === Ursinha is now known as Ursinha-afk [12:24] :) [12:24] mzanetti: if its ready lets get it into rtm and devel at same time [12:24] let me know if you need help [12:25] ack [12:36] greyback_, ok totally frozen now including swiping [12:36] including swiping sounds new [12:37] brendand: entire shell? Ok, that's new. Can you attach gdb to unity8 and grab a backtrace? [12:37] greyback_, command to do that would be appreciated [12:37] greyback_, i could of course look it up [12:37] greyback_, but you might know off the top of your head [12:37] brendand: "sudo gdb -p `pidof unity8`" to attach [12:38] greyback_, done [12:39] brendand: at a prompt? enter "bt" === MacSlow|lunch is now known as MacSlow [12:39] I expect we'll not get much useful until you install some debug symbols though [12:40] qtmir-android-dbgsym qtdeclarative5-qtmir-plugin-dbgsym qtbase5-dbg <- install these please to get better backtrace [12:40] greyback_, http://paste.ubuntu.com/8350204/ [12:41] brendand: oh interesting, seems attribute change in mir has locked up somehow. [12:41] sil2100, ^^ can i have an rtm silo for line 74 ? [12:41] seems there are two free ones [12:42] brendand: could you install libmirserver25-dbgsym and try that again please? [12:42] greyback_, unable to locate package? [12:42] ogra_: sure! [12:42] * ogra_ hugs sil2100 [12:42] brendand: you need to add extra repo to apt: https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages [12:43] brendand: you can skip step 2 [12:44] greyback_, libmirserver25-dbgsym : Depends: libmirserver25 (= 0.7.2+14.10.20140912-0ubuntu1) but 0.7.1+14.10.20140909.1~rtm-0ubuntu1 is to be installed [12:44] * sil2100 hugs ogra_ [12:45] brendand: what mirserver version have you installed? Maybe mirserver24? [12:45] greyback_, no it's 25 === Ursinha-afk is now known as Ursinha [12:46] greyback_, it's expecting a newer version - this is RTM i'm on remember [12:47] brendand: oh rtm [12:47] ogra_: is there a different ddebs repo for RTM images? [12:47] greyback_, no idea, ask pitti (in #ubuntu-touch i suppose) [12:48] ogra_: will do, ta [12:49] brendand: while I'm waiting, could you pastebin me the output of "t a a bt" from gdb? [12:52] sil2100: can we get rid of the ~rtm on http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=sergiusens [13:02] brendand: to confirm, you had a partially hung shell (the dash was unresponsive, yes?) and you kept working with apps? [13:02] and eventually everything siezed up? [13:03] greyback_, actually i was running an autopilot test suite (uitk) [13:03] greyback_, at one point the tests kept running but the ui was frozen, but i only checked after it finished that it was totally unresponsive [13:03] sergiusens: sure! I have a flag for that ;) [13:04] brendand: was the dash frozen when you started the AP suite? [13:04] sil2100: is it accessible to me? [13:04] greyback_, no [13:04] sergiusens: why do you not want the ~rtm part btw.? [13:05] sil2100: we are going to start doing the inverted landings [13:05] greyback_, btw pitti is off sick today, at least until later on [13:05] sil2100: so my MPs come together with what is my trunk [13:05] sil2100: I really don't see the use of it really; look at how debian syncs are done; they keep the version verbatim [13:05] brendand: hmm ok. Mir folks have a theory about what happened (some app was hanged - and Mir has bug that it will eventually seize up because of that app) and there's a MR with a fix ready: https://code.launchpad.net/~afrantzis/mir/fix-1350207-unresponsive-clients/+merge/233934 [13:06] brendand: but without more info about hte hang, or being able to reproduce it ourselves, we can't really say much more [13:06] sergiusens: ah, ok, I understand now - ok, then give me a moment, the 'do not append ~rtm' flag was currently only available for sync silos [13:06] sil2100: either that or you will need to add logic to remove the ~rtm when we source copy to utopic [13:06] sil2100: ok [13:07] no problem [13:07] sil2100: I knew we were going to need to iron it out as it's a new deploy path [13:07] sergiusens: that's what I'm working on right now, but this will be a good workaround for now [13:07] Anyway, makes sense for now [13:07] brendand: I'll try running the UITK tests on an RTM image, to see if I can repro it anyway [13:10] hi traingurds: could I get a silo reconfigured? thanks! (https://ci-train.ubuntu.com/job/ubuntu-landing-014-0-reconfigure/build?delay=0sec) [13:18] popey: hey dude can you try something please. drag down networking-indicator, toggle on flight mode, let everything settle, then toggle it off again, does the Network title move to the left and become work? [13:19] yeah, been like that for ages [13:19] other indicators do that too [13:20] popey: thanks [13:20] sergiusens: let me just run some tests on my branch and it should work for merges as well [13:23] So are we promoting images on the utopic branch anymore? [13:23] sil2100: Huston we have a problem. Flight mode is definitely causing issues with calls was working fine till is was activated, Other than that everything that was broken friday still is :) [13:24] tedg, we might perhaps promote one along with rtm [13:24] after a quick "does it boot" test [13:24] Okay, I want to land the UAL cgroups stuff, but I thought I'd do it after a promotion. But not sure if it makes sense to wait in utopic? Just wait on the sync to rtm? [13:25] tedg, i turned utppoic into my testbed for everything nowadays :) [13:25] *utopic too indeed [13:25] it is really helpful to have an image that contains your stuff and flash that afresh [13:25] Ha, "ogra_ made me do it!" ;-) [13:26] and you can roll back at any time if you see an issue [13:26] Yeah, will be nice when we get silo images in CI Airline. [13:26] ++ [13:26] i'm so eagerly waiting for that [13:27] ogra_, BTW, did you see this? https://code.launchpad.net/~ted/ubuntu-seeds/indicator-display.touch.utopic/+merge/234337 [13:28] tedg, ah, no, i havent done my weekly "seed merge check" day yet :) [13:28] ogra_, Ah, okay. Wanted to make sure it's on the list. [13:29] davmor2: good news then! [13:29] tedg, https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.utopic/+activereviews [13:29] it is ;) [13:29] davmor2: flight mode was in overall a bit brokenish === boiko_ is now known as boiko [13:30] sil2100: well quite a lot brokenish and I think it stays brokenish [13:30] sil2100: I'm about to shut it down and restart and see if calls get through right then === cprov__ is now known as cprov [13:32] davmor2: ok [13:35] sil2100: just ping me back when ready :-) [13:37] sergiusens: still waiting for CI to kick in ;p [13:44] core devs? a trio of quite simple packaging acks (accounts-plugins, signon, signon-plugin-oauth2) needed: https://ci-train.ubuntu.com/job/ubuntu-landing-001-2-publish/ [13:45] === trainguards: IMAGE 240 DONE (finished: 20140915 13:45) === [13:45] === changelog: http://people.canonical.com/~ogra/touch-image-stats/240.changes === [13:45] a bit unexplained dependency changes in signon-plugin-oauth2, otherwise clear [13:46] mardy: as a pre-emptive strike, you might want to explain the stricter signon-plugins-dev dep plus Breaks: account-plugins-google (0.12 is not available anywhere I think?) [13:48] Mirv: account-plugins-google 0.12 should be coming out of silo 001 [13:49] mardy: oh, of course, you're right. nothing unclear really then [13:49] we just need an ack [13:49] I allocated rtm silo for the same landing now [13:52] pete-woods, is silo 14 going to be ready for sign-off today? [13:54] brendand: it's possible, but not guaranteed. [13:54] pete-woods, ok - i'm not rushing it, just wondering [13:55] brendand: I'd definitely like to see it evaluated today :) [13:56] brendand: there's not much to test in terms of the actual scope at the moment. you can just log in, and the scope shows an extra department because its logged in [13:56] so it's not super exciting :) [13:57] pete-woods, oh wait, we're talking about different silo 14's :) [13:57] pete-woods, i should always specify rtm i guess [13:57] pete-woods, so i meant rtm silo 14 which has the stuff you were trying to land last week (embedded artwork i think) [13:58] brendand: ohhh! [14:01] brendand: the packages in that silo are too old. I don't know how you update them [14:01] mediascanner should be 0.105+14.10.20140909 [14:02] do I just build them like for non-rtm? [14:02] * pete-woods hits silo 14 build button [14:02] pete-woods, i would ask sil2100 any questions about silos [14:04] okay, it seems like it works just like non rtm :) [14:04] okay, maybe I have no idea what I'm doing [14:12] pete-woods: hey! Which silo was that? [14:12] pete-woods: 14? [14:12] * sil2100 looks [14:12] sil2100: yes. rtm silo 14 [14:12] It might be an old silo [14:13] sil2100: it is an old silo, yes. but I thought we needed to updated it with what we actually want to land into RTM [14:13] pete-woods: uh, ok, it's not even an sync silo, someone just pushed packages directly to it or something - let me reconfigure it for you [14:14] pete-woods: you want to sync from ubuntu, right? [14:15] sergiusens: sil2100: so what is the option in there, keep landing with ~rtm and remove when doing copy or are we going to have that flag in any generic silo? (to not have rtm even when landing in rtm) [14:15] sil2100: yes, from utopic [14:15] rsalveti: option is to do a non ~rtm version and then sync back to utopic [14:15] sil2100: hey sorry to pester, can i get silo 11 for line 61, i turned line 35 into a test line for things not quite ready [14:16] rsalveti: so, this flag will be available anyway, since you might not want ~rtm sometimes by yourself, but in the long run it will remove the ~rtm when doing a sync back to ubuntu [14:16] sergiusens: right, but can we already do that when building stuff for rtm? [14:16] sil2100: alright [14:16] rsalveti: no, I'm on the wait list :- [14:16] :-) [14:16] just waiting sil2100 then :-) [14:16] brendand, any news (good or bad) on the device tarball? [14:16] Yeah ;/ Had problems with testing, as preprod silos were b0rken [14:17] sil2100: I just don't want those ~rtm changelogs in my trunk :-) [14:20] thanks for the sync! :) [14:21] sil2100: approved: https://code.launchpad.net/~dandrader/qtmir/frozenApps-lp1295623/+merge/234393 [14:22] mzanetti: \o/ [14:22] mzanetti: ok, let's prepare landings for that, let me take care of that in 5 minutes [14:22] trainguards: hi guys! I could still do with (utopic) silo 14 being reconfigured (https://ci-train.ubuntu.com/job/ubuntu-landing-014-0-reconfigure/build?delay=0sec) cheers! [14:29] pete-woods: reconfig done [14:29] Mirv: thanks! :D [14:30] sergiusens: hey! Redeployed the stuff, you can find the DO_NOT_APPEND_RTM_TO_VERSION checkbox in the build-job now [14:30] It *should* work ;) [14:31] sergiusens: I mean, tested it on preprod and works, CI also says it works, so it works [14:33] mzanetti: ok, let me get to your landing now [14:35] mzanetti: sil2100: does the input landing going good? [14:35] or rather looking good :)? [14:35] mzanetti: sil2100: are we piping it into rtm at same time? [14:36] any other bad things QA found on #40? [14:36] asac: yes, what we'll do is that I'll fill in both landings (ubuntu, ubuntu-rtm), build both and I asked mzanetti to perform the testing first on rtm [14:36] So that we can land both at once [14:36] yeah [14:36] sounds good... is it isolated enough to not put QA on that silo too? [14:36] asac, not sure you noticed, utopic-proposed is fine again [14:37] thats great :) [14:37] mako and krillin build now [14:37] great [14:37] * asac looks forward to get a new n4 image from that channel [14:37] ogra_: i already have a new system updat enotification? [14:37] should i skip that? [14:37] its dated today [14:37] 240 ? [14:37] it doesnt tell me :) [14:38] system-settings tells you [14:38] got a notification at 16:06 on sep 15 [14:38] ogra_: i didnt upgrade yet :) [14:38] you dont need to install it :P [14:38] * asac just goes for it [14:38] but it shows you what it downloads/would download [14:38] yea its downloading 240 [14:38] * asac install & restart [14:39] http://people.canonical.com/~ogra/touch-image-stats/240.changes [14:39] all changes from the weekend :) [14:39] yeah the download allowed me to observe the progress bar working ... so i assumed something was in it [14:39] apparmor will re-rpofile [14:39] my boot took 3-4min here [14:39] really? [14:40] yeah [14:40] ok... its now booting after install [14:40] let me see :) [14:40] jdstrand: didnt we have the plan to pregenerate the app profiles at some point? [14:40] and with the new dev mode that only starts after lightdm you can only sit and wait and hope :P [14:40] :) [14:40] oh :/ [14:40] (before i could at least check via adb that apparmor is running) [14:40] ogra_: so thats bad i guess? [14:40] asac, well, no way around [14:40] how will we check fatal things in future if we cannot adb into early boot [14:41] devmode will have to check the screen state (or in the alternative case pop up a confirmation dialog) [14:41] so it cant start before lightdm anymore [14:41] but lightdm is up once the animation is there? [14:41] shortly after, yes [14:41] 10-15sec after usually [14:41] well it came back up at least [14:42] * asac doesnt look forward to first real bustage [14:42] yeah, will be awful [14:42] but guess someone still knows how to debug this :) [14:42] for the moment i included an emergency adb that fires up if container or lightdm fail [14:42] but we'll have to drop that before final [14:42] guess its a special ubuntu-device-flash flag to put it into fully open mode? [14:42] (and it will stop working once the screen lock check is in) [14:43] like --rooted-mode [14:43] no, there is no such thing as "fully open mode" [14:43] you can debug via recovery though [14:43] why? [14:43] just a lot more painful and more time consuming [14:43] asac, because we would need an open adbd then [14:44] ogra_: yes, just a setting i assuem [14:44] (which i plan to work on for porters later, but my current foocus is to have all modifications for the default mode in the current packag) [14:44] early-insecure-adb [14:44] nope [14:44] why not? [14:44] current adbd wouldnt work with that [14:44] well. why not make it work that way? [14:45] (depending on the device though, some devices need the container to set ip everythng first) [14:45] *up [14:45] wouldnt that give us more efficiency? [14:45] asac, sure ... add another 24h to my days and i'll do parallel developemnt for both adbds :P [14:46] i'm currently fully focused on getting the planned rtm bits done ... [14:46] and that eats all my day [14:46] * davmor2 moves ogra_ to venus to increase his daily hours [14:46] (since three weeks now, there are tons of custom scripts people use that need adjustment etc) [14:47] davmor2, bah, its smelly there i heard [14:47] venus smells like farts ! [14:48] * davmor2 senses a Uranus joke in here somewhere [14:48] lol [14:49] asac, for rtm we need to be locked down and secure ... we can happily poke holes into that afterwards again [14:49] i dont disagree with that part. however, if we cannot debug early boot stuff anymore effectively its a problem [14:49] and if you can break into the system through recovery mode anyway [14:49] then i dont see how this adds protection from the evil friends [14:50] we will lock that down too [14:50] mzanetti: ok, silo 006 for ubuntu is for you - could you take care of uploading/preparing the -gles counterpart ther? [14:50] this setting could be in the RO part of the image [14:50] mzanetti: for now I build only the qtmir package [14:50] ogra_: recovery? so developers cannot use the devices for hacking? [14:50] ? [14:50] ogra_: or will we implement "unlock will wipe your data" feature? [14:50] sil2100: ack. I'll try my best :D [14:50] asac, developers can use the device as before [14:50] asac: they can once they enable developer mode [14:51] davmor2: kernel developers? [14:51] that want to debug sometihng before lightdm is up? [14:51] asac, they cant in the model that security requested [14:51] can they also flash the image just like normal? [14:51] mzanetti: once you add the -gles bits give me a sign and I'll build the RTM versions then :) [14:51] and recover in case that image doesnt boot anymore? [14:52] ogra_: how will users recover from an image that doesntt boot anymore? [14:52] (beyond that fact that we have nothing to deal with kernels on krillin from userspace (like flash-kernel for example)) [14:52] asac, no idea [14:52] by re-flashing i guess [14:52] can they reflash? [14:52] if the recovery was unlocked [14:53] which you say will be locked [14:53] yes, like on nexus [14:53] ok. and you unlock and it wipes user data? [14:53] yes [14:53] that would be good i guess [14:53] like on nexus [14:53] and then recovery is unlocked? [14:53] stays? [14:53] right [14:53] i would hope so :) [14:54] sounds good... now we can just add a setting into RO part of iamge that will turn on adb before lightdm and are happy again :) [14:54] * ogra_ isnt involved with recovery lock/unlock ... but thats how i understood the reqs. [14:54] kk [14:54] asac, no, we cant [14:54] we can, but you dont have time [14:54] asac, that would need another adbd binary installed [14:54] right [14:54] you can also make adbd honour that setting somehow i am sure [14:54] its a time thing [14:54] thats fine [14:54] well, i'll have the time, just not now :) [14:55] sil2100: thanks [14:55] currently keeping the world working with the locking down eats my time [14:55] and it doesnt realyl feel right to ship a fully open adbd by default [14:55] ogra_: only concern: how will folks recover the infrastructure in case we spit out a bogus image? is that well undertstood? [14:56] asac, yes, i work hand in hand with plars [14:56] asac, sometimes it needs someone to manually recover the HW thogh ... depends how badly they are screwed [14:56] ogra_: as long as there are clear guidlines how to do that using recovery mode its fine [14:57] asac, well, CI simply flashes with --developer-mode and --password handed to ubuntu-device-flash [14:57] asac, and i expect that our infra devices will always have an unlocked recovery [14:59] ok [14:59] well as long as plars is happy i am happy :) [14:59] plars will be so much more happy with my weekend changes :) [15:01] ogra_: have all of those landed now? I know you said manta should be in better shape now, so I'll work with rick to try to get all those recovered today [15:01] plars, utopic-proposed has all changes [15:01] plars, rtm-silo-006 has the rtm landing [15:01] also it seems we are somewhat unblocked now and have 2 solutions for button instrumentation. I'm hoping we'll see IS progressing on that pretty quickly now [15:01] ogra_: what all did you change? [15:01] plars, i had to move adbd startup after lightdm in any case [15:02] ogra_: ah that [15:02] ogra_: ok, once that's all fully landed, I'll remove those workarounds and try it locally first [15:02] plars, so you shoudl be able to drop the hack checking for the UPSTART session var [15:02] ogra_: sounds good [15:02] for manta i had to add a fix to the container ... [15:02] permissions for the functionfs were set wrongly [15:03] manta -proposed should actually work flawless again [15:03] (well, as flawless as manta can work :P ) === plars changed the topic of #ubuntu-ci-eng to: Train support: trainguards | Vanguard: plars | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: Latest flash update hung all makos on s-jenkins. [15:11] sil2100: ok. I think I'm done with the gles-sync [15:11] sil2100: https://code.launchpad.net/~mir-team/qtmir/gles-sync/+merge/234703 [15:12] mzanetti: ok, let me reconfigure then and rebuild :) Looks good, thanks! [15:24] alex-abreu: hi, so I see you've approved https://code.launchpad.net/~vorlon/ubuntu-html5-theme/lp.1369052/+merge/234565; but it's still failing on the CI with an error I don't understand. Can you help me figure this out? https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-utopic/2917/console [15:30] slangasek, sorry otp, but from a quick glance seems like a glitch/transient error [15:32] ogra_: hmm phablet-config writable-image loop prints Error:device not found until it is rebooted now [15:33] davmor2, brendand reported that too, it seems to work though [15:33] didnt get to check whats the issue there yet [15:33] ogra_: yes indeed [15:33] it seems to not use "adb wait-for-device" [15:37] alex-abreu: ok. Do you think I should retry the jenkins job? [15:37] slangasek, I'd say yes === gatox is now known as gatox_lunch [15:49] mzanetti: the rtm silo will finish building soon [15:49] mzanetti: so please get your ubuntu-rtm device ready for testing! :) [15:51] davmor2: hey! Were you able also to get a list of blocking/critical bugs related to the custom tarball? [15:52] sil2100: yes but there is silo 006 I think which will help cwayne land some other stuff [15:52] 006 ? thats mine ! [15:54] davmor2: can i have that list of critical bugs? [15:54] tedg, did someone talk to you about the ubuntu-app-launch crashes we see in smoke testing ? looks like another app icon issue (like the one we had before) [15:55] ogra_, Those would be recoverable errors, not crashes :-) [15:55] ogra_, Where are they? [15:55] well, they produce a .crash file :) [15:56] tedg, heh, if i could find one now :P [15:56] i hate hate hate hangouts ... we had a valid url in the chat in this mornings meeting [15:56] cwayne: you can have bug or the silo landing ;) I need to have the time to sit and write it, the big one as you know is tagger which is due to the camera app so one for bfiller 's team I guess. Here maps login, picture scope no opening anything when you click open [15:57] davmor2: actually has nothing to do with the camera-app itself [15:57] tedg, see the other channel [15:57] davmor2: it's the camera service backend but it can be fixed in tagger itsleft [15:57] itslef [15:57] ugh [15:58] bfiller: oh interesting [15:58] mzanetti: ^ [16:00] ogra_: hm, I have problems with my HO [16:00] same here [16:01] ogra_: I can't connect to the link of our landing HO [16:01] robru: are you able to connect? [16:01] and i'm DROWNING IN HARPS !!!! [16:01] argh !!! [16:01] sil2100: yeah I'm the only one in the HO! [16:01] robru: are you able to get in? [16:01] Phew, works [16:02] robru: nm, it finally let me in (obviously) [16:02] wow [16:02] now FF crashed [16:02] ogra_: it's an Irish conspiracy [16:03] hahaha [16:03] hmm [16:03] "can not find server at accounts.google.com" [16:03] fun [16:03] ogra_: everybody's there but you [16:03] robru, well, i cant get in [16:04] and FF crashed again [16:04] ogra_: still? [16:04] Ouch [16:04] it tells me it cant find accounts.google.com [16:05] geezy, my firefox is totalyl crazy now [16:06] sigh, so much about using a stable release on production machines [16:06] mzanetti: rtm packages built! Please test rtm silo 002! [16:09] davmor2, can't play videos off the SD card? [16:09] same issue as with music tracks from eth scope ? [16:10] brendand: yeah it is the same as the track issue [16:10] ogra_, yeah indeed === ev__ is now known as ev [16:15] kgunn_: ping [16:19] sil2100: hey [16:20] kgunn_: we need help! There's an urgent ubuntu-rtm qtmir landing we need tested, where mzanetti doesn't seem to be around anymore [16:20] It's a blocker that we would like to have landed ASAP [16:20] Since it's like the only non-whitelisted blocker currently :) [16:20] kgunn_: ubuntu-rtm silo 002 [16:21] alex-abreu: well, the failure is not intermittent: http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-utopic/2928/console I do notice that it says it's trying to use python3, but ubuntu-html5-theme seems to only build python2 packages; so I'm not sure how this was working before? [16:22] sil2100: he's around...lemme talk to him [16:22] kgunn_: thanks :) [16:23] alex-abreu: ah. autopilot was uploaded on August 6 dropping the python2 compatibility code... I would have hoped this would have been regression-tested, but apparently not? [16:26] slangasek, this one did not indeed ... I'll file a new bug & work on it to port to python 3 [16:27] sil2100: I'm still around. testing silo 2 now [16:27] to serialize the landings [16:27] mzanetti: thanks! :) Remember it's ubuntu-rtm that we want to test here [16:27] alf_: psivaa_: I think I have a solution, but I need to patch some code that I don't have access to at the moment. We may be able to force it some other way though if it's urgent [16:27] sil2100: yeah, I'm installing on top of ubuntu-touch/ubuntu-rtm/14.09-proposed [16:27] sil2100: is that ok? [16:28] Yes, that's the way to go [16:29] mzanetti: don't forget you gotta manually add the package line to the apt sources....can't just use apt-add-repo [16:29] oh [16:30] Yeah, that's still b0rken [16:30] ah... understood why. thanks for the hint [16:34] My firefox constantly crashes after I exit a hangout [16:35] That's a rather specific way of cleaning up the memory [16:35] sil2100: FF hates you hate it back it works for me [16:42] plars, oh, seems there is a mako now failing too in the 240 test [16:42] ogra_: oh, strange [16:42] same erros [16:42] error: cannot connect to daemon [16:42] Command 'adb shell id -ru' returned non-zero exit status 255 [16:42] cannot bind 'tcp:5037' [16:42] * daemon not running. starting it now on port 5037 * [16:48] robru, Ursinha: hey! Is the automerger fixed for cu2d now? === gatox_lunch is now known as gatox [16:49] sil2100: fginther was working on that. last I heard, there was some new node that couldn't run the job properly. workaround was to disable the new node, not sure if it was ever fixed [16:49] robru: fginther doesn't seem to be around today, but let me test that later with a merge [16:50] sil2100: yeah please do a merge, even if the -autolanding job fails you can still get good results from the -ci job === Ursinha is now known as Ursinha-afk [16:52] sil2100: hey. not able to install the packages... [16:52] sil2100: you said silo2. I assume that was a typo and you meant silo6 [16:52] but still seems the packages are made for utopic and rtm doesn't like them [16:53] mzanetti: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-002 <- this [16:53] ogra_, did you say phablet-config writable-image --ppa worked for you? [16:53] sil2100: thanks [16:53] mzanetti: silo 002 for RTM :) [16:55] brendand, you need to hand over the password with -r [16:55] (in fact phablet-config should tell you that) [16:56] robru: oh, just in case - until we have the qtmir silo landed and a new image built, please only land things that don't seem super risky [16:56] sil2100: hah, ok [16:56] plars, hrm ... so the phablet config code actually contains an "adb.start()" which calls adb start-server ... [16:56] ogra_, yeah i did do that [16:56] i wonder if it behaves if we rip out that line [16:57] ogra_, in fact after it told me to do it :) [16:57] ogra_: oh, that's no good at all [16:58] ogra_: any of the adb commands should start the server, if brendand needs it for some reason though, we should probably check to see if it's necessary first [16:59] plars, that predates brendan using phablet-config i guess [16:59] old code === plars changed the topic of #ubuntu-ci-eng to: Train support: trainguards | Vanguard: cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: Latest flash update hung all makos on s-jenkins. [17:00] plars, try removing it (on the main() function) [17:07] john-mcaleely, sil2100 - so it seems very unlikely i'm going to find anything bad enough in this tarball to stave off a release [17:08] brendand, that sounds good! [17:08] sil2100, so, is now a good time to push it? [17:09] \o/ [17:09] brendand: thanks! [17:09] john-mcaleely: yes, let's ship it [17:09] ;) [17:11] sil2100, shipped [17:18] Hi folks [17:18] I need to coordinate getting NM with an updated custom tarball [17:19] so I intend to a) disable cron for systme-image + cdimage b) unblock NM c) update custom tarball d) rebuild rootfs e) rebuild image f) re-enable crons [17:19] I've disabeld crons now [17:19] lool, very very bad idea [17:19] ogra_: tell me [17:19] ogra_: how so? [17:19] lool, are you sure the just uploaded krillin device tarball did actually produce a system image before you did that ? [17:20] ogra_: EPARSE [17:20] ogra_: I want to rebuild the image [17:20] lool, watch the conversation here from about 10min ago [17:20] ogra_: do I need for something before I do that? [17:20] lool, there was an image in flight right now [17:20] that requires the cron to be on [17:21] once thats landed properly, do whatever yoou want though :) [17:21] well I can wait [17:21] there, re-enabled [17:21] you just said you disabled crons [17:21] thanks [17:21] well jsut for some minutes you know [17:21] like, time of a proposed migration [17:21] we just need to make sure this lands first [17:21] but sure [17:21] ogra_: mind pinging when it's done? [17:21] then the builders are all yours [17:22] looks like it just popped out http://system-image.ubuntu.com/ubuntu-touch/ubuntu-rtm/14.09-proposed/krillin/version-41.json [17:22] ogra_: seems to be going ok so far [17:22] lool, so now, feel free [17:22] plars, oh ? really ? heh [17:22] ogra_: with adb.start() removed that is [17:22] i wonder what that was for [17:23] sergiusens, do you remember why phablet-config forces "adb start-server" ? [17:23] ogra_: could be a fluke though, I still get the error spam [17:23] thanks [17:23] plars, right, thats another issue i think [17:23] looking at that now === Ursinha-afk is now known as Ursinha [17:24] did a) and b) now [17:24] waiting for migration [17:24] lool, btw, no need to disable cdimage i think [17:25] (it would just pick up the latest build as soon as you re-enable system-image ... ) [17:26] plars, hmm, i think the "adb wait-for-device" call in phablet-tools doesnt hand over a serial at all ... [17:27] ogra_: it should be ok, we set ANDROID_SERIAL [17:27] so it finds "somethig" [17:27] tries to connect, fails and starts over [17:33] robru: sil2100: silo 001 is good to go I don't know if you missed the ping from the bot [17:36] davmor2: yeah I was told not to do any 'risky' landings (which usually means no mir) [17:36] davmor2, robru: yeah, I trust davmor2's testing, but let's wait with it until we get qtmir in and an image built [17:37] sil2100: which qtmir landing are we waiting for? did it get in the image that just built? [17:38] oh, that one [17:38] robru: the RTM one [17:38] 002 [17:38] robru: mzanetti ist in the middle of testing that [17:39] ogra@styx:~/Devel/branches/phablet-tools$ phablet-config writable-image [17:39] PING launchpad.net (91.189.89.223) 56(84) bytes of data. [17:39] ogra@styx:~/Devel/branches/phablet-tools$ [17:39] * ogra_ sighs ... [17:39] why cant i reproduce at all what plars and brendand see [17:40] sil2100: ok. rtm image fine with me [17:41] sergiusens, when you get a chance, could you merge https://code.launchpad.net/~nskaggs/phablet-tools/remove-python2-support/+merge/233754 or leave a comment on what you'd like fixed? [17:42] grmbl [17:42] mzanetti: \o/ [17:42] ogra@styx:~/Devel/branches/phablet-tools$ phablet-config -s 0046ceedca13b976 writable-image [17:42] PING launchpad.net (91.189.89.223) 56(84) bytes of data. [17:42] ogra@styx:~/Devel/branches/phablet-tools$ [17:42] davmor2: ! [17:42] even with two emulators running and serail handed over i dont get the spam [17:42] davmor2: can you sign-off 002? [17:42] :) [17:42] mzanetti: thank you! [17:43] sil2100: so now I need to test again with utopic, right? [17:43] mzanetti: that would be best, yes, but in this case we will anyway land the RTM silo first as it's an exceptional situation [17:44] mzanetti: but utopic tested will be nice to get the features correctly landed in utopic later on as well [17:44] sil2100: ok. cool [17:47] hmpf, even purging all packages and re-installing them doesnt change a thing [17:47] ogra@styx:~/Devel/branches/phablet-tools$ phablet-config writable-image [17:47] * daemon not running. starting it now on port 5037 * [17:47] * daemon started successfully * [17:47] PING launchpad.net (91.189.89.223) 56(84) bytes of data. [17:48] plars, can you reproduce the spamming at home ? [17:48] cjwatson: hey, will hints from lp:~ubuntu-touch-release/britney/hints-ubuntu-touch also be used for 14.09-proposed? [17:50] ogra_: not sure, I've got my devices busy troubleshooting something else at the moment here [17:50] plars, ok [17:51] davmor2, you said you could see the "error: device not found" right ? [17:51] lool: no, there's a hints-ubuntu-rtm branch (though not currently one for ubuntu-touch) [17:51] * ogra_ cant reproduce it [17:51] lool: what do you need? [17:52] cjwatson: blocking network-manager so that I stop the system-image cron just for the right amount of time [17:52] cjwatson: basically I need to coordinate an update to the custom tarballs in 14.09 with the landing of network-manager [17:52] lool, if you are done before 5am you shoudl be fine :) [17:53] ogra_: that's another one [17:53] ogra_: problem is that system-image picks up custom tarballs IMMMEDIATELY [17:53] well [17:53] like every minute [17:53] lool, right, so disable cron now [17:53] ogra_: what are the current image numbers for our utopic-based devices? [17:53] sil2100, 240 for mako [17:54] ogra_: including the image one? [17:54] i think 34 for krilling [17:54] For flo and manta the latest one is different, right? [17:54] lool, yes, just kill everything now that the device tarball is done [17:54] ogra_: well I dont know when NM will be ready though [17:54] ogra_: this is the rtm side of its landing [17:55] lool, 3am UTC should be our nightly build, i dont expect anything to *need* an image build before that [17:55] lool: it's blocked [17:55] I would like an RTM image after we land qtmir [17:55] ogra_: everything forces adb start server if the first thing it needs is to query the device (e.g.; adb shell getprop ...) [17:55] lool, given that sil2100 tries to get a promotable image there might be other reqs though [17:55] lool: SMS me when it's ready to unblock, if you can't find anyone else from the release team [17:55] sil2100: how's your MP coming? ready to merge that? [17:56] sergiusens, i know ... thats why i ask why phablet-config has a forced "adb start-server" in it :) [17:56] robru: ah, let me try that in a moment, busy gathering e-mail intel ;) [17:56] cool [17:57] ogra_, cjwatson: To be clearer, I dont know yet when NM goes in; it's just entering QA for RTM AIUI [17:57] so could just land tomorrow [17:57] but ok [17:57] ogra_: so, the mako and flo/manta image numbers didn't get out of sync? [17:57] lool, right, we will need an image before that [17:57] that's ok [17:57] sil2100, they did, sorry, distracted ... one sec [17:57] in fact, now that cjwatson blocked it there, we're good [17:57] we can do the same thing as last time [17:57] davmor2: piiing [17:57] when it's ready to be published in rtm [17:58] sil2100, so, mako, manta, flo and emulator are 240, krillin is 34, right, seems we didnt get out of sync at all [17:59] ogra_: phew, since I didn't know if I just read the smoketesting dashboard wrong [17:59] lool, but i thought custom tarballs cant land without QA signoff anyway anymore, so that shouldnt cause you any issues ... [18:01] at least thats what was discussed here oon friday iirc [18:02] ogra_: oh, then I don't know; it shouldn't be a bad thing though [18:02] balloons: added comments [18:03] lool: yes, i fyou have custom tarball drop that needs to go into any channel, work with landing team to arrange qa sign off for rtm [18:03] sergiusens, its fine unless you have a server as root running and try to spawn one as normal user [18:03] i guess [18:04] hmm, no [18:04] doesnt seem to have any impact at all [18:04] davmor2: piiing ;) [18:05] ogra_: shouldn't be a problem, no [18:05] sil2100: man you need to get your i key fixed [18:06] davmor2: uh oh sorrrrrrry ;) [18:06] sil2100: and your R key needs real help :D [18:06] sil2100: whats up [18:07] sil2100: oh it's ready [18:07] is the input fix good? [18:08] asac: I don't know I just got back from tea to find out it had landed ;) [18:09] ok thats a good desert i guess :) [18:11] hm [18:11] again no progressbar on OTA upgrade [18:15] ogra_: can you file a bug and find someone who wants to own it [18:16] asac, for/against what ? [18:17] * ogra_ files a bug that "davmor2 should get a good dessert after tea" [18:17] * davmor2 confirms ogra_ s bug [18:17] haha [18:18] asac, some minimal kind of reference would be really helpful ;) [18:18] ogra_: black forest gateau [18:19] err ? LOL [18:27] cjwatson: random question; should the citrain mark the release as 'devel' in the changelog to make the sync easier to the "other" archive? [18:38] sil2100: hmmmm browser doesn't work [18:38] davmor2, white screen ? [18:39] i have seen that on the weekend i think [18:39] ogra_: nope Network Error it appears you are having trouble viewing google.com [18:39] oh [18:39] well, dont blame the browser [18:39] chekc with some webapps [18:40] thats most likely actually a wifi issue [18:40] lool: is this what your nm image fixes ^ [18:40] * ogra_ guesses thats rather for location service [18:41] davmor2: no [18:41] davmor2, the device tarball had some wifi fixes [18:41] davmor2: I'm getting slownesses with latest NM personallly [18:41] ah perhaps it's not NM [18:41] with latest image from this morning, I had network trouble [18:41] ogra_: you're saying latest device tarball from this pm will improve things? [18:42] lool, the changelog had two wlan fixes [18:42] ogra_: I'm guessing they didn't [18:43] davmor2, are you on 41 already ? [18:43] ogra_: I always fresh flash latest before testing a silo [18:43] k [18:44] ogra_: yeap 41 [18:44] ogra_: actaully sorry, that's on mako [18:44] so something has regressed there I guess [18:44] smells like [18:45] trainguards: I've just thought that the HERE bits in the custom tarball are actually useless with the broken location-service side anyway [18:45] so I guess it doesn't hurt to update these [18:45] but I'll coordinate with cwayne for the krillin/rtm one obviously [18:45] lool, and with QA i think [18:46] since friday they need signoff [18:46] (however that is supposed to be tested) [18:46] robru: sil2100 can I get something for line 52 now? [18:46] * ogra_ hands sergiusens some icecream for line 52 [18:48] ogra_, cyphermox_, asac, sil2100: ouch so after reboot wifi said it was connected and it wasn't turned it off and back on again now everything is fine :( [18:48] davmor2, i see that often here but nothing in the logs :( [18:50] sergiusens: there are no free rtm silos unfortunately [18:51] robru: ah, I set 2 to pass just a minute ago ;-) would need a sync to utopic and then can be fired away [18:51] and QA is busy on all fronts [18:52] sergiusens: ok i can publish those [18:52] robru: just keep in mind that these are the inverted pilots [18:52] robru: as in rtm first, utopic after [18:53] sergiusens: yeah [18:53] sergiusens: looks like there's 2 utopic silos for you if nobody beats me to them [18:53] ogra_: ok [18:54] lool, though i wonder if you could get an exception for simple HERE fixes, but thats a QA decision [18:55] practically all auto landing should be stopped since friday so yu shoudl be able to just generate a new one with only that changed [18:55] sil2100: does sync:N work from rtm->utopic yet? I have sergiusens landing... [18:56] robru: the branch I'll be testing and merging soon is supposed to allow that -> https://code.launchpad.net/~sil2100/cupstream2distro/cu2d-syncbothways/+merge/234708 [18:56] sil2100: merging soon -> merging today? [18:56] I hope so! Testing it now [18:57] sergiusens: ok i assigned you utopic 18 but don't build that yet [18:59] sergiusens: ok you also got utopic 19 but don't build that one either (not till after sil lands his branch) [18:59] sil2100: ping sergiusens and I when that branch is merged & deployed [18:59] robru: ACK! [19:00] thanks [19:00] brb, lunch [19:00] * lool kicks an image build [19:00] (utopic) [19:00] sounds good to me === Ursinha is now known as Ursinha-afk [19:04] robru: ok, seems to work for the case of ubuntu-rtm -> ubuntu, need to just check if it still works for ubuntu -> ubuntu-rtm [19:05] === trainguards: IMAGE 241 building (started: 20140915 19:05) === === Ursinha-afk is now known as Ursinha [19:08] davmor2: how's the testing going? [19:08] Is the issue GONE? [19:08] sil2100: good news I can't reproduce the error, however the lack of networking from time to time is not so good [19:08] davmor2: networking? Is that something new? [19:09] i see it all the time ... but i cant find any data for it [19:09] sil2100: it is for me it was working fine till I landed on 41 [19:09] all logs are completely silent [19:09] ogra_: on 41? [19:09] i always have to tap on my AP once to make it work [19:10] sil2100, on all images since i got my krillin [19:10] ogra_: ah, ok [19:10] this is the first time i see someone reproduce it [19:10] sil2100: I on the other hand only hit it on 41 and never before [19:13] sil2100: robru I guess I should hold on the merge and clean, right? [19:14] sergiusens: yeah [19:14] no locks there yet I guess [19:14] sergiusens: well, we can then do a sync from ubuntu-rtm archive, which will work now instantly [19:14] sil2100: oh? [19:14] sergiusens: the only bits that don't work yet is doing a sync from an ubuntu-rtm silo to a ubuntu silo ;) [19:14] sil2100: robru then lets do that [19:14] less error prone as well [19:15] robru: it should work, just do sync:ubuntu-rtm,14.09 [19:15] I mean [19:15] sync:ubuntu-rtm,14.09 source_package_name [19:15] sil2100: oh ok [19:15] sergiusens: yeah merge & clean away [19:16] * ogra_ shades his ears and waits for the universe to implode [19:17] sil2100, cyphermox_, ogra_: http://paste.ubuntu.com/8352554/ I get a setup error at the top [19:17] It *should* work... but no one cared about this use-case before, so it probably didn't get much testing [19:17] sergiusens: ok silos utopic 18 and 19 are ready to build [19:18] * sil2100 crosses fingers [19:18] sil2100: robru do I still need "watch only" ? [19:18] sergiusens: no you need to a real build. [19:19] sil2100: see silo-002 ^ [19:19] davmor2: I don't know why this is popping up, NM shouldn't be service activated it should be started by upstart pretty early. Something ought to be starting before it right now and causing this to happen, but right now from the log it doesn't appear to be a major issue. Is this translating into an error in UI> [19:20] And then probably a watch_only build as well as we still have that bug with source uploads [19:20] davmor2: :D [19:20] \o/ [19:20] robru: that's what I wanted to hear :-) [19:20] robru: will you do the honor and publish silo 002 rtm? [19:20] sil2100: done ;-) [19:21] cyphermox_: no connection to the net, you have to tap on the ap to restart the connection and then it all works fine [19:21] robru: if you could watch for this to land in the rtm archive and kick a new image once it's in it would be awesome [19:21] robru: (and try also spying on the ubuntu landing of this silo to get tested and landed as well) [19:22] sil2100: robru yeah, I need a watch now [19:22] sil2100: can we kick rtm images? [19:22] davmor2: what version of NM are you running? [19:22] robru: uhh, right... you'll have to pester poor ogra_ or rsalveti [19:23] sergiusens: ugh wtf? i thought that bug was only for sync:N silos [19:23] ogra_: i still dont quite know how to gate the custom tarball yet.. should we have a separate jenkins job attached to the promoted channel and have it copied there when blessed by QA? [19:23] robru: no, it's a bug in all source uploads o_O [19:23] sil2100: crap [19:23] Didn't find the time to understand that, since I thought it's an LP bug, but I can't understand why it works for branch-generated uploads [19:23] Sounds crazy [19:24] cwayne, well, first of all i assume you switched off all automated bits that put the traball into the download place, right ? so if you put it in place manually you can coordinate with QA somehow [19:24] cwayne, thats what we do for the device tarballs [19:25] cyphermox_: ii network-manager 0.9.8.8-0ubuntu23 armhf network management framework (daemon and userspace tools) [19:25] sil2100: well between the argparse-apocalypse and stopping citrain shelling out to itself (both things which touched build script's method of invoking watch-ppa) I probably broke something [19:25] ogra_: i hadn't yet, last i was told was to make it run at midnight utc.. i can switch it off now [19:25] cwayne, well, ask asac then ... i think he assumed it was off and all landings would be QA gated [19:25] probably i misunderstood that though [19:26] we dont want to really shoot the new custom tarballs into rtm channel without any gate, yes. [19:26] cwayne: ^ [19:26] make that a manual hand over... just put your new tarball out and ask landing team to arrange the qa testing etc. [19:26] robru: ok, the branch seems to work, let me approve it and see if it auto-merges [19:26] Fingers crossed! [19:26] then that gets put into the right place for system image to pick up [19:27] davmor2: looks as though NM is crashing, but you're not running a new version... are there files in /var/crash? [19:27] sil2100: cool [19:27] asac, well, there was the question from lool as well ... he has HERE bugfix only stuff to land as i understood ... and that goes via custom [19:27] asac: so not even on -proposed images? [19:27] yes, i already answerd that [19:27] and what about the HERE bits [19:27] same same [19:27] k [19:27] we have no real way to make that different [19:27] currently rtm -proposed is qa gated [19:28] devel-proposd in theory not, but since we dont have way to land in one way or the other and since rtm is what matters it doesnt make a diff [19:28] cyphermox_: mtp and trust_store nothing for nm [19:28] hmm [19:28] well then what we need to do is get stgraber to remove the tarballs from the channels then [19:28] davmor2: what image then? [19:28] cyphermox_: apparently ogra_ has had it for a while [19:28] cwayne: which tarballs? [19:28] cyphermox_: image 41 [19:28] aka nothing to do with the jenkins jobs building.. [19:28] yes [19:28] asac: custom [19:28] we need a dr4op location [19:28] could you file a bug about this and make sure to include that syslog, the image number, version of NM and such? [19:28] like we do for device [19:28] same approach [19:29] you drop them somewhere [19:29] and we copy them to the pickup location after we are all happy [19:29] I see no reason why that's happening, and it probably isn't crashing if there's nothing in /var/cras [19:29] cwayne: you jus need to put the tarballs out in a different spot than where the job picks them up from [19:29] cyphermox_: only happened for me on 41 and only happens on reboots [19:30] I've rebooted my devices many times, never had this happen [19:30] cyphermox_: I will happily file though [19:30] cwayne: and make the copy to that place something we only do that if it is fine for the gate [19:30] asac: well first we'd need to change the channel definitions, as right now they pick up from jenkins [19:30] cwayne: check how john is doing it with device tarball. its the same [19:30] it's not the same, because that's not built in jenkins [19:30] o/ === Ursinha is now known as Ursinha-afk [19:30] cwayne: we should build it into jenkins directly :) [19:30] cwayne: just change jenkins to put it elsewhere [19:31] asac: its not jenkins that would need to change, it s-i server [19:31] why? [19:31] you can change jenkins [19:31] stgraber can change si server [19:31] because si server is looking at that jenkins job [19:31] the jenkins job doesnt put anything anywhere [19:31] s-i polls it [19:31] cwayne: aha [19:32] well i have asked stgraber i -touch [19:36] cyphermox_, as davmor2 said, i see it all the time (a few times a day when waking up the device from sleep) .... i checked all logs i know more than once, there is *nothing* in them [19:36] and i also doubt its a NM thing ... [19:37] rather indicator [19:37] ogra_, cyphermox_: [19:37] https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1369718 [19:37] Launchpad bug 1369718 in network-manager (Ubuntu) "network not connecting on reboots from time to time" [Undecided,New] [19:38] hitting return instead of space is a real sign that I need to knock off. Right catch you all tomorrow, cyphermox_ if you need anything else add it to the report I'll throw it up there tomorrow am for you [19:39] alright, thanks! [19:44] sergiusens: The changelog header makes no difference either way to syncs [19:46] sergiusens: That just controls the default contents of the Distribution field in the generated .changes file (even that, it's possible to edit ...), which matters for uploads but not copies [19:46] thanks for the clarification [19:54] ToyKeeper: any chance of qa sign-off for rtm/landing-003? i added some steps to test [19:55] === trainguards: IMAGE 241 DONE (finished: 20140915 19:55) === [19:55] === changelog: http://people.canonical.com/~ogra/touch-image-stats/241.changes === [19:57] cwayne: Got any info about what the change actually does and what components of the system are affected? Are there any AP or manual tests for the changes? [19:58] ToyKeeper: it just copies apparmor pre-compiled profiles from /custom/cache/apparmor to /var/cache/apparmor [19:58] manual tests are described in that paste, pretty much just apply that tarball and check that stuff was copied over [19:59] cwayne: AppArmor changes have traditionally had a high rate of breaking stuff though. [19:59] trainguards: sorry, what do I need to do after adding another mp to the spreadsheet to get an updated package in the silo? this is for location-service in ubuntu silo 2 [19:59] I've added a second branch stacked on the first one [19:59] ToyKeeper: this isn't an apparmor change though, it's just doing the same thing we do for the core apps installed into the rootfs [19:59] lool: you need to run the reconfigure job and then run the build job again [19:59] thanks [20:01] cwayne: How will that custom tarball get landed? [20:02] ToyKeeper: we're still trying to work that out now, but this change will not break if the tarball doesn't have anything in /custom/cache/apparmor (which it doesn't now) [20:02] and custom tarballs are going to be gated, we just need to figure out exactly how it's going to be given to you guys to test [20:03] cwayne: I'm hoping we can find a way to test that... I heard something like this just a few hours ago: "the custom image that landed without QA sign off added about 8 regressions" [20:03] heads up peeps, I just deployed some new code to citrain production, please ping me if anything explodes in your face [20:04] lool: any eta on lxc-android-config being released from silo 2? [20:04] how can they be regressions in new apps [20:04] cwayne: So, I'm trying to make sure every part of this is testable. [20:04] they're new scopes that still have bugs, not regressions to be fair :) [20:05] but yes, we have everything gated now so now new custom tarball will land without qa's distinct approval [20:05] I'm not too sure I agree with the assessment that apparmor changes have a high rate of breaking stuff [20:05] in fact, I actively oppose that position [20:05] what we need to figure out is the eaiest way to get that to you to get your approval [20:05] cwayne: I don't know the details, unfortunately. New components will need new test plans though. Maybe the initial landing won't need it, but each one afterward will. [20:05] sergiusens, note that rtm 006 blocks lxc-android-config currently (waiting for QA signoff) [20:06] apparmor just gets blamed when it blocks something cause something else changes [20:06] sergiusens: I had to rebase it twice [20:06] and since there is a lot of change... [20:06] sergiusens: I'm finishing a build in landing 2 and then it can go in utopic [20:06] lool: oh nice; good thing it's on some form of vcs ;-) [20:06] sergiusens: haha [20:06] lool: good, you understood it :-) [20:06] yeah, I was sad too [20:06] * ogra_ throws little paperballs at sergiusens [20:07] ToyKeeper: where are you getting your data that apparmor changes have a high rate of breaking things? [20:08] jdstrand: Anecdotal. Perhaps it's a low rate, but when something breaks it tends to break in very noticeable ways? [20:09] ISTR some landings where apparmor rule updates made nearly the entire device non-functional, but not recently. [20:10] ToyKeeper: I can't remember an apparmor change breaking something. it has the potential to break things, but that is why we are so fanatical about testing. I think you may be seeing a lot of apparmor denials-- but that is not because of apparmor uploads-- those are because of other uploads that need new accesses [20:10] ToyKeeper: I don't recall those landings, and I'm the one who does the landings [20:10] well, often enough app policy breakage gets discussed as "apparmor breakage" [20:11] indeed [20:11] if we say it iften enough it must become true one day ;) [20:11] It's hard to recall the details from that long ago. It's very possible that it just got blamed on apparmor because the syslog had denials for a lot of other components. [20:11] I think it would be good to not perpetuate that if we can help it [20:11] finished the image build, re-enabled system-image cron [20:12] cwayne: In any case, my device is almost done flashing so I can test that. [20:12] yes, syslogs are riddled with denials due to lack of correct policy groups, changes in the system, new components being added. our landings *fix* those :) [20:13] cwayne: With no tests for the user-visible bits though, it'll probably default to a fairly long smoke test suite. [20:13] jdstrand, just change the text in syslog to "not-apparmor-really: DENIED" [20:13] ToyKeeper: the worst apparmor-related bug I know of was when the time wasn't being set right and the time was off and policy didn't get updated and there were denials as a result. that was not apparmor at all [20:13] there are no user-visible bits though.. [20:13] ogra_: hehe [20:16] just have it change the text in syslog to incriminate whoever youre the most mad at that day [20:16] mad at bill? dialer-app DENIED [20:17] "your.-custom-tarball-broke-me: DENIED !!!11!!one" [20:17] :) [20:25] rsalveti: ogra_: anybody around to kick an RTM image? we got qtmir in there [20:25] sure [20:25] ogra_: thanks [20:26] triggered [20:30] === trainguards: RTM IMAGE 43 building (started: 20140915 20:30) === === Ursinha-afk is now known as Ursinha [20:54] trainguards, Can I please get a silo for line 69? [20:59] tedg: OK you got 15 [20:59] robru, Awesome, thank you! [20:59] tedg: you're welcome! [21:00] robru: need silos for 64-66 when any become available [21:00] whoops... robru why did it set my silo 20 to landed? [21:00] i guess i did something wrong there when freeing... [21:00] i went to clean and chose only free ppa [21:00] kenvandine: not sure, well look soon [21:01] robru, no biggy... just weird that the spreadsheet status went to landed :) [21:01] it didn't land anything :) [21:01] which is good :-p [21:01] robru, i assume i did something wrong :) === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [21:33] kenvandine: hm, your job paramters look fine, not sure why it said landed. weird [21:40] === trainguards: RTM IMAGE 43 DONE (finished: 20140915 21:40) === [21:40] === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/43.changes === [21:40] robru, there you go :) [21:40] ogra_: thanks [21:41] * ogra_ vanishes into the night [21:41] robru, ok, thx [21:42] robru, when we have a free silo, can you please assign one for line 71? [21:42] kenvandine: [21:42] k [21:42] ;-) [21:42] * kenvandine needs to head out [21:42] thanks [21:54] davmor2: alf_ camako: I don't know what the hell you people think you tested in silo rtm1 but there sure isn't a mir package in there. [21:59] robru, I watched it build with my own eyes... [21:59] camako: not sure what to tell you, the PPA is empty and the clean job was last run 3 days ago. maybe you're thinking of the utopic build [22:00] robru, there was something fishy, though... [22:00] robru, silo dashboard page said packages built... but the PPA page said it was still building.. [22:01] robru, we waited for the PPA to report finished building [22:01] Robru, see I think it happened again [22:01] Mir doesn't take 2 mins to build [22:02] camako: right, there's a bug in citrain that makes it report Packages Built prematurely. but the PPAs operate independently, there's no bug that makes PPAs go blank [22:04] camako: anyway I started a build of it now: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-001/+builds?build_state=building [22:06] Robru, I don't know what happened either but alf brought it to our attention on a call and we were all looking at the PPA page and were all confused... But then the page reported that it finished building [22:06] Robru, and why is there a mir package in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-001 ? If it wasn't built? [22:07] Is that the source package? [22:10] I think it's the whole package and looking at the date, it shows that it was built on 9/12 (Friday)... [22:10] Robru ^^ [22:11] Anyways, I think we have some other yet-to-be-discovered bugs somewhere [22:12] camako: it's there because I *just* uploaded it now. the silo was empty when I went to publish it. [22:12] camako: so please retest it when it finishes building [22:12] camako: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-001 "Uploaded 6 minutes ago" [22:20] Robru, No it was there already... I had that page on my screen here before you started to build... I'll email the screenshot to you... It doesn't say "Uploaded 6 mins ago" on this page.. Because it was uploaded on Friday. [22:20] Robru, I'm confused, how did you upload a package that is yet to be built? [22:23] camako: there are source packages and binary packages; once a source package is uploaded, it has to be built by launchpad, that will then publish the binaries [22:24] camako: the same way I uploaded everything i've ever uploaded in my life? [22:25] robru, okay so it's a source package... I'm just trying to understand... [22:26] camako: yes.. you upload source packages, launchpad builds binaries from it [22:26] camako: we don't upload binaries, we upload source packages and they get built in the PPA. that's how they all are [22:28] Ursinha, robru, ok thanks... It's all a black box to me... Sorry if my questions were stupid. I'm trying to make sense of what happened. We'll retest tomorrow. [22:29] camako: yeah I'm not sure where the package went. it's very mysterious [22:30] cwayne: Not sure if you're still around, but is it expected that some of the files in /custom/cache/apparmor/ will differ from the same-named file in /var/cache/apparmor/ ? [22:34] camako: not stupid at all :) [22:36] Ursinha, perhaps slightly annoying :-) [22:36] camako: no.. what is annoying is this thing of packages disappearing and we having no clue why [22:39] ToyKeeper: yes, it only copied it from /custom if its newer [22:41] Ursinha: +1 [22:42] camako: we're trying to narrow this down [22:42] Ah, and since none of the custom files were newer, it only copied ones which were actually missing. [22:44] yes, since your phone would have already compiled them on first boot [22:48] Going to have to retest a bunch of stuff on the base image... so far I haven't had even one boot be solid enough to run for more than about 2 minutes. [22:51] I think I saw bug reports about these things earlier though, probably not the silo. [22:52] yeah, i'd be incredibly confused it it were the silo, it's literally 1 upstart job that does a cp -nu :) [22:53] Sorry for the long test process, part of that is me figuring out what's actually affected and catching up on new bugs from the weekend. [22:54] ToyKeeper: no worries! i'd rather we be thorough than have issues :) === kalikiana_ is now known as kalikiana === Ursinha is now known as Ursinha-afk