=== _salem is now known as salem_ === salem_ is now known as _salem [02:30] trainguards, silly question, if I update the MP that is preposed for the silo, do I need to reconfigure or just re-build the silo ppa? [02:31] veebers: rebuild if it's the same mp. Reconfigure if there's a new mp, including of its superceding a previous mp. [02:32] robru: ah cool thanks, the MP was updated due to new code in trunk so I'll rebuild the silo. [02:32] veebers: sounds good [02:33] oops [02:34] ticked the right box this time :-) [06:03] (and morning too) [08:38] eh [08:38] ah, device tarball [08:45] Mirv: ;) === oSoMoN_ is now known as oSoMoN [09:05] sil2100, is launchpad down for you? [09:05] sil2100, my manners, good morning! [09:05] rearrange those please :) [09:05] mandel: morning! ;) [09:06] mandel: huh, indeed it is [09:06] launchpad down :( [09:06] I asked on launchpad-ops if anything [09:06] modern human is so impatient. "it's been down for 2 mins already!" [09:07] Ah, update [09:07] "but... but... I've important stuff building and I need to keep hitting refresh!" [09:07] 2 minutes?!?!?! OUTRAGE [09:07] Mirv, yes, I don't consider it important, yet manager do [09:08] Mirv, I just suffer their impatience :P [09:08] also, compiling cpp takes longer than getting lp back hehe [09:13] LP is an important factor for almost everyone, so good that it's back up agaon [09:14] * Mirv is satisfied with what the refreshing shows [09:27] oSoMoN: hey! Were you able to fill in an FFe for the oxide landing? [09:28] sil2100, I did (bug #1425599), but chrisccoulson said that we don't use this process for oxide (or firefox & chromium), because all releases get the latest updates anyway [09:28] bug 1425599 in oxide-qt (Ubuntu) "[FFE] oxide 1.5" [Undecided,New] https://launchpad.net/bugs/1425599 [09:28] so the FFe process is fairly redundant - if it's rejected, the latest release still lands anyway [09:29] hmm [09:29] Is that something that has been agreed with the release team? [09:30] hmpf [09:30] i just woke up my krillin for the first time today ... [09:30] the clock shows 5:04 [09:30] and i cant convince it to show the right time it seems [09:31] sil2100, pretty sure it has, chrisccoulson can you comment on this? [09:31] hmm, suspend/resume fixed it for the lockscreen, but the clock indicator is gone [09:35] sil2100, oSoMoN - yeah, I'm quite sure it has too, considering we are regularly pushing the same updates out to stable releases. And having an evergreen webengine was one of the reasons we created Oxide [09:35] ISTR going through this every cycle :) [09:37] chrisccoulson, and you havent set up macros for it in your IRC client yet ? [09:37] heh [09:38] sil2100, is there a way to create 2 silos, one for rtm with udm and its dependencies, and a second silo for vivid with the same branch of udm and its dependencies [09:38] sil2100, the issue is that its dependencies have a branch for rtm, yet I keep udm as updated as possible (trunk) in rtm [10:08] davmor2, jibel, john-mcaleely: so, following up on my earlier question, do we know if the U1 deletion bug has a fix ready/released? [10:15] sil2100: not yet [10:16] sil2100, bug fixed in devel but not in rtm [10:16] bug 1413655 [10:16] sil2100, I do not know [10:16] bug 1413655 in Canonical System Image "Updates panel does not prompt for login when U1 account is invalid/deleted" [Critical,In progress] https://launchpad.net/bugs/1413655 [10:18] Thanks [10:19] dobey: hey! [10:19] dobey: we would need LP: #1413655 fixed for ubuntu-rtm as well, do you have some work done on getting this bug backported to 14.09? [10:19] Launchpad bug 1413655 in Canonical System Image "Updates panel does not prompt for login when U1 account is invalid/deleted" [Critical,In progress] https://launchpad.net/bugs/1413655 [10:39] sil2100, Mirv is this normal -> https://ci-train.ubuntu.com/job/ubuntu-landing-014-1-build/163/console [10:39] sil2100, Mirv ignore me, ppc symbol issues [10:40] mandel: it looks like all architectures failed to build [10:40] mandel: because of symbol issues [10:40] sil2100, yet, it just fails on ppc and the symbols files are not separated per arch [10:41] sil2100, if it failed due to the symbols in should be in all the archs.. right? [10:44] mandel: it looks like it failed on all archs [10:44] ;) [10:44] https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-014/+sourcepub/4804160/+listing-archive-extra [10:44] sil2100, indeed, I'm stupid, I just updated the symbols [10:44] sil2100, I forgot a push [10:44] spanish lesson: soy gilipollas [11:01] sil2100: o/ hey can i get a silo for that quick fix? [11:02] i hear there is a window open to land that one in rtm [11:03] or any trainguards available [11:06] Sure [11:07] dbarth: ^ and sil2100 is already on it apparently [11:07] dbarth: we've been actually discussing this one [11:07] We even wanted to land it ASAP ;) [11:07] thanks guys [11:08] excellent [11:15] sil2100, thanks [11:47] trainguards, reconfigure on vivid silo 19 please, have added qtmir [11:47] Saviq: on it [11:47] sil 'Lightning' 2100 [11:48] ;) [11:48] ;p Only sometimes though ;) === MacSlow is now known as MacSlow|lunch [12:31] renatu, Hi! [12:38] om26er, hi [12:39] renatu, it was regarding sync-monitor, it failed to sync for me on the first try [12:39] renatu, http://paste.ubuntu.com/10428002/ [12:39] but now its working [12:40] om26er, strange it should not try to sync if there is no network [12:40] looks like it try to sync with device offline [12:40] renatu, device was always connected [12:42] om26er, the error says: Network is unreachable [12:43] renatu, we can blame my internet then :) [12:50] om26er, maybe in that time when you tried to sync the device was connected to wifi but without internet access [13:00] * sil2100 goes off to lunch === alan_g is now known as alan_g|lunch [13:02] sil2100, I understand I have a +1 on the device tarball. is now good to push it? [13:09] sil2100: yes i'll have a branch today === _salem is now known as salem_ [13:14] can you guys access the spreadsheet? [13:14] gdocs say it's too popular [13:14] Saviq: same here [13:14] it was "trying to reach" and after reaching it said that [13:14] yup [13:14] DoS :/ [13:15] s/reaching/refreshing/ :) [13:25] Mirv, seems to be back [13:26] confirming === MacSlow|lunch is now known as MacSlow === alan_g|lunch is now known as alan_g [14:06] sil2100, ping [14:08] john-mcaleely: pong [14:08] sil2100, can I push the tarball, davmor2 is +1 on it? [14:08] john-mcaleely: sorry, was on lunch - where would you push the tarball to? [14:08] normal RTM [14:08] john-mcaleely: 1 second [14:08] Sure :) [14:09] Oh [14:09] davmor2: ? [14:09] * john-mcaleely waits one second [14:09] ... [14:09] done! [14:09] ;D [14:09] sil2100: nearly tested silo10 for the u1 account fix [14:09] john-mcaleely: ^ [14:09] we can land them as two builds? good to get them separate in rtm [14:09] and device tarballs are quick builds [14:09] davmor2: we won't have time for that this round anyway, since we didn't prepare the derived series yet [14:10] sil2100, ? [14:10] I would say let's land the tarball now [14:10] yeah [14:10] And if anything, have a new image built later with the u1 fix [14:11] john-mcaleely: push it ;) [14:11] sil2100, pushed! [14:11] \o/ [14:31] sil2100: if you're going to need a derived series please give us maximal warning this time [14:32] don't want another last-thing-on-Friday panic [14:32] cjwatson: sure, for now we're trying to figure out how to copy only a device tarball from one channel to another ;) === chihchun_afk is now known as chihchun [16:38] rsalveti, do you plan to land the agent rework silo? the comment from Mirv on the status is a bit confusing [16:40] seb128: yup, in my list for testing & landing today [16:40] takes a while to validate with all the bt devices, but will get it done today [16:41] rsalveti, I tested & approved the mp yesterday :-) [16:42] seb128: sure, but I want to test with my other devices as well because I had quite a few issues with that previous version of that mr [16:42] rsalveti, do you plan to do the backport to rtm as well? [16:42] seb128: which car did you use to test? [16:42] seb128: that's the idea, yeah [16:43] rsalveti, a peugeot one [16:43] seb128: which model? [16:43] 207 [16:43] mine is a peugeot as well, but 208 [16:43] cool, different one [16:43] 207 business pack [16:43] great [16:43] I also tested ssp pairing on a k480 keyboard [16:43] and an audio receiver [16:44] so should be fine [16:44] the previous version of the mp was making the per-device agent buggy [16:44] that one should work for scenarios with adaptor agents and per device ones [16:45] yeah, cool [16:50] sil2100: robru: ^ silo 020 qml cache for vivid, when/if FFe approved. or rsalveti too, whoever stays the longest :) [16:58] ;) [16:58] \o/ [17:02] mandel: ping [17:08] trainguards: can you assist with silo 25 ? not really sure what happened [17:09] oSoMoN: looking [17:15] oSoMoN: yeah merge conflict against trunk, not sure, train has code to handle that, not sure what's wrong with it now. anyway I manually merged it and pushed [17:16] sil2100: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc&usp=drive_web#gid=0 [17:16] is that the right sheet? [17:17] sil2100: did you say I just email you and you enter it, or I enter it? Because this looks like a computed sheet [17:19] thanks robru [17:19] oSoMoN: you're welcome [17:19] popey: you can e-mail me all the info :) [17:20] sil2100: robru: can't create silo for line 64 [17:20] One day we can go through adding a line together [17:20] getting fata error in the spreadsheet and jenkins also failing [17:20] uh [17:21] The spreadsheet was acting strangely some hours ago indeed [17:21] rsalveti: let me try [17:21] rsalveti: log? line 64 was blank for me until I just reloaded the page just now [17:21] sil2100: correct answer! :D [17:21] huh [17:22] robru: not blank here [17:22] robru, rsalveti: getting the same thing here [17:22] I mean, it's not blank, but a fatal error [17:22] Let me refresh the spreadsheet completelt [17:22] sil2100: fatal error where? in jenkins? or in the spreadhseet? [17:22] robru: on the spreadsheet [17:23] sil2100: rsalveti: worked fine for me, assigned silo 17 [17:23] rsalveti: maybe it was broken since we had the spreadsheet open for too long? [17:23] robru probably loaded it just recently [17:23] rsalveti: yeah when in doubt, reload the spreadsheet. [17:24] popey: ;) [17:24] trainguards: can I have a silo for line 65, please? [17:24] sil2100: robru: I opened it again in another browser [17:24] and still had the same issue [17:24] huh [17:24] well, it seems it'sfine now [17:24] Well, spreadsheet [17:25] So, looking at the failure summary from Google I get, there was some fatal error happening in syncstatus [17:25] But it might just have simply fixed itself magically, as always [17:26] trainguards: can I get a silo for line 62 please [17:26] sil2100: you want to assign or should I? [17:27] robru: please do ;) [17:27] k [17:28] sil2100: oh I'm getting the fatal error now [17:28] greyback: bfiller: spreadsheet is imploding will assign when I can [17:29] robru: thanks :) [17:30] good riddance... [17:30] for the imploding spreadsheet :) [17:31] greyback: ok rtm 12 [17:31] robru: cheers [17:31] robru: thanks, noticing that [17:31] greyback: you're welcome [17:32] oSoMoN: silo 21 [17:33] bfiller: silo 25 [17:33] sil2100: seems I have to prepare manually by copy & pasting from the spreadsheet. yey [17:38] robru, cheers [17:39] oSoMoN: you're welcome [17:44] Saviq: https://ci-train.ubuntu.com/view/1.%20Build/job/ubuntu-landing-019-1-build/119/console eh, qtmir-gles isn't in the silo... [17:45] or in the ppa, I mean [17:45] also wtf, that's supposed to timeout... [17:45] robru, huh, that job was supposed to *build* qtmir-gles... but obviously I forgot to reconf [17:46] robru, but found a bug for you then ;) [17:46] Saviq: you have an MP prepared already? === alan_g is now known as alan_g|EOD [18:12] bfiller: 6, 26, 28 [18:12] robru: thanks [18:13] bfiller: you're welcome [18:39] bfiller: WATCH_ONLY in silo 26 means "don't merge my merges, only look at PPA", but there's nothing in your PPA yet. FORCE_REBUILD also wasn't necessary, just run that job with no options. [18:40] robru: I must have pressed that by accident [18:40] bfiller: no worries, I'm just watching over builds ;-) [18:40] robru: I usually click "force rebuild" and "ignore missing twins" by habit. I guess I don't usually need these? [18:41] bfiller: force rebuild is only needed if you're rebuilding an already-built MP (due to new commits). also ignore_missing_twins is only to do with -gles packages so pretty much only used by kgunn & friends. [18:42] robru: ok [18:42] bfiller: I mean they don't *hurt* per se, but yeah, not often necessary. [19:30] trainguards: could I have a hand for a second, I'm proposing something for qtmir for RTM, but the build appears to be taking qtmir trunk and applying my patch, not the qtmir-rtm branch. How do I specify the RTM branch to the train? [19:34] trainguards: unping, my bad [19:36] greyback_: train goes by MPs, if the train is grabbing trunk it's because your MP points at trunk. [19:37] robru: yeah I realized I pointed it to the wrong branch, and needed to reconfigure [19:37] should be ok now [19:40] sil2100: for silo rtm 12, we actually want to land that asap [19:40] sil2100: the battery related fixes are fine for RTM [19:40] and this is one of them [19:42] greyback_: no worries, I'm here to help if you need me [19:42] robru: thanks [19:42] greyback_: you're welcome [19:45] rsalveti: ok, then in my opinion the bug priority should be changed [19:45] rsalveti: since the battery fixes are critical prio IMO [19:45] yeah [19:52] rsalveti: you did a WATCH_ONLY in silo 17 but there's no package there... I think you should cancel that build and rebuild without WATCH_ONLY [19:52] robru: ops, wasn't supposed to be watch-only [19:53] robru: done, thanks [19:53] rsalveti: you're welcome [20:12] wgrant, ping [20:36] trainguards the commit message for a landing is pulled from the commit message from the proposed MP right? [20:37] veebers: yes [20:37] veebers: yes, unless it is specified in debian/changelog, then that is preserved [20:37] and that's grabbed at the silo build time? [20:37] veebers: yes [20:37] right, so I need to rebuild if I want that changed [20:37] veebers: yes [20:38] cool thanks robru, rsalveti [20:38] veebers: you're welcome [20:38] trainguards, with line 53/silo 7, what do I do about that source package? I've completed the testing, but that qtmir-gles source package has to land along with the other changes [20:39] veebers: also note, the train doesn't handle bulleted lists well. if you're going to set the commit message on an MP, try to write just one sentence on one-ish lines. if you need a bulleted list you have to write your debian/changelog yourself [20:39] veebers: (train can make a bulleted list, but each bullet represents one MP, so you'd have to have a bunch of MPs each with one sentence commit messages) [20:39] robru: ah ok, gotcha. How will it handle the current one? [20:40] veebers: which one? [20:40] kdub: I don't understand the problem. silo says packages built? [20:41] robru: sorry, any idea how the train will handle the current commit message? [20:41] veebers: what MP though? I don't know what silo you're talking about :-) [20:42] robru: lol sorry I thought the fact you mentioned the bulleted lists you were looking at it, sorry about that [20:42] kdub: something goofy going on there, spreadsheet says source package but the train config clearly has an MP listed in the dashbaord [20:42] veebers: nah just some code I poked at recently. [20:42] robru, right, something seems off, but I'm not quite sure how source packages work [20:42] in the ci train [20:43] robru: heh, right so fyi it's this one, and I want to remove one of the bullet points, so I'll update, rebuild and re-run the test run (https://code.launchpad.net/~autopilot/autopilot/trunk/+merge/250402) [20:44] kdub: well ostensible you manually upload those to teh PPA yourself. however in this case there's clearly an MP in the silo and the package is in the PPA as a result of that. it should be fine to just click publish. I have no idea why the spreadsheet shows different info. in cases of discrepancies, the dashboard is authoritative. [20:45] veebers: well, this is what your last build resulted in: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-009/+sourcepub/4803556/+listing-archive-extra so consider that... [20:45] veebers: you might want to make your own debian/changelog entry. [20:46] brb [20:46] robru, so I think what happened was, the mp was in the mp-to-land column at the time the silo was set up, and then I wanted qtmir-gles as a source package, so i moved it to that column [20:52] kdub: why do you want a source package? what's wrong with the MP? [20:54] kdub: at any rate, if you need it to be a source package, it means you need to reconfigure the silo. but all that's going to accomplish is that it won't merge the MP that you built from, I don't understand why that would be desireable. [20:55] camako, any insight? I'm not quite sure why it should be a source package myself [20:56] kdub: MPs are the primary use case for the train, I think you should change it back unless you have a good reason. [20:56] robru, this is for the qtmir twin (qtmir-gles) [20:57] camako: right, but you guys have an MP for that. what's wrong with it? [20:57] robru, the right thing to do would be to add it to the MP list [20:57] okay, so I'll add the MP to the list [20:57] camako: agreed [20:57] robru, nothing... we weren't sure [20:57] yep [20:58] camako: kdub: yeah source packages are typically only used for things that we don't have lp branches for and thus have nothing to make an MP against. [20:59] robru, yeah the intention was that we'd add the MP later and reconfig ourselves (i.e. don't ask the trainguards) .. But some info got crossed... [20:59] balloons: Hi [20:59] camako: oh I see, yeah that makes sense, to start as a source package and then switch it to the MP, since you need to know the silo # before you can make the MP. [20:59] camako: kdub: but yeah, once you have the MP you're golden ;-) [21:00] robru, exactly [21:00] robru: heh, thnks for the heads up, that isn't a very good change log, I'll make my own [21:00] wgrant, hey, I was just implementing what you proposed on https://bugs.launchpad.net/launchpad/+bug/810229 [21:00] Launchpad bug 810229 in Launchpad itself "no way to be both official-reviewer on a project and not recieve email (without using an external mailing list service)" [Low,Triaged] [21:00] thanks for the thorough investigation. I hope I got it all correct, testing it out now [21:00] okay, thanks for the help robru / camako [21:00] robru: is there any magic I need to do other than just a dch -i . . . commit and mp? [21:00] veebers: yeah sorry about that, train is optimized for small isolated branches authored by one or two people. the changelog it generates in the case of "many authors, one giant MP" is pretty puke-y [21:00] robru: cure, makes sense [21:00] s/cure/sure/ [21:01] veebers: nope, no magic. train will detect that debian/changelog is modified and won't modify it further. just review it after you dch to make sure you got the desired result. [21:01] balloons: Ah, great. Let me know if it doesn't go as planned. [21:01] kdub: your'e welcome [21:01] robru: ack, thanks [21:01] veebers: you're welcome [21:02] veebers: oh, the only magic bit I guess is that your series should be UNRELEASED, not vivid. [21:02] robru: hmm, I fear that the version number might cause me grief, let me check [21:03] veebers: hm, yeah, I don't understand that part of the code very well. I think if your first line of the changelog says 'vivid' then the train will think that's an old release and generate a new, empty changelog entry (literally a bullet point with no text). but if you say UNRELEASED it should mangle the version number and generally do the right thing. [21:04] i seem to recall having "vivid" as the release when i did custom debian/changelog for a landing, and it working fine :-/ [21:05] veebers: last build generated version number 1.5.0+15.04.20150226-0ubuntu1 so a rebuild should result in 1.5.0+15.04.20150226.1-0ubuntu1 and work fine. you shouldn't need to know that though, basically if the first line of your changelog says "autopilot (1.5.0) UNRELEASED; urgency=medium" then the train should convert that to "autopilot [21:05] (1.5.0+15.04.20150226.1-0ubuntu1) vivid; urgency=medium" by itself [21:06] robru: awesome, thanks again (I should have store the count of beers I owe you in something bigger than a unit32 as it's going to overflow soon) [21:07] dobey: yeah but I think if you say 'vivid' then you also have to pick your own version number. if you want the auto-version-number magic you need to say UNRELEASED. I can't remember exactly the details, I'd have to dig up the code [21:07] veebers: lol, you're welcome [21:11] robru: so, one more question the debian/changelog in lp:autopilot has UNRELEASED from _ages_ ago as we've been using the train to land from lp:autopilot -> lp:autopilot/1.5 so it's happened automagically for us until now. Is it save to change that UNRLEASED to something else so dch -i gives me a new entry? [21:13] veebers: you mean http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/debian/changelog ? [21:13] robru: that's the one [21:13] veebers: oh, don't use that one, since it's missing a ton of stuff. grab the one from the 1.5 branch and include that in the MP. [21:13] the changelog and release has been happening in http://bazaar.launchpad.net/~autopilot/autopilot/1.5/view/head:/debian/changelog [21:14] robru: ack, I'll merge that one back into lp:autopilot then go from there [21:14] veebers: ok sounds good [21:22] hrmm [21:22] i thought we had autopilot runs enabled for lp:pay-ui [21:23] but i don't see an autopilot job run for my MP :-/ [21:23] which is odd, because it did run on my MP from last week :-/ [21:23] robru: if you have a moment could you sanity check this please? Then once that's merged to trunk I'll rebuild the silo: https://code.launchpad.net/~veebers/autopilot/add-changelog-for-release/+merge/251178 [21:24] cihelp: why would the ap tests jobs not be run on https://code.launchpad.net/~dobey/pay-ui/mir-app-test/+merge/251163 when they should be enabled? [21:25] veebers: seems fine generally. Assuming that you just took lp:autopilot/1.5:/debian/changelog and dumped it without modifications on top of lp:autopilot:/debian/changelog it should be correct. [21:26] robru: right, just merged that back into trunk. Sorry I meant the version line, that's what you suggested right (1.5.0) . . . . [21:26] veebers: oh right, yeah that's fine [21:26] sweet, cheers [21:27] veebers: it should be. ping me when the rebuild is done, I'm curious how that turns out. I might need to hotfix some code if it screws up [21:27] robru: lol, aight, will do :-) [21:27] dobey, there are two jobs that failed. Unfortunately the ap tests aren't able to run unless all the required sub jobs pass first [21:29] fginther: oh ok. can you trigger a rebuild then? the failure is due to a test failing, which is completely unrelated to anything i changed in the branch (i only changed autopilot tests, and this is a unit test failure) [21:29] not quite sure why it failed. seems maybe a timing issue during that run perhaps :-/ [21:29] dobey, rebuilding now [21:30] thanks fginther === salem_ is now known as _salem [22:20] kenvandine, hey, would you have a moment to review and ack the packaging changes in https://code.launchpad.net/~osomon/webbrowser-app/use-grabToImage/+merge/250223 ? [22:31] trainguards: I’m trying to get hold of a core-dev to ack the packaging changes in silo 21, and it will be ready for publication [22:32] oSoMoN: k, mterry or kenvandine are my go-to guys for that... [22:32] oSoMoN: not sure who else is around [22:32] already ask the latter, let’s poke the former [22:32] darn, he’s not around it seems [22:33] oSoMoN: yeah I don't see him [22:33] robru, can you please publish Mir 0.12 (silo 7)? [22:33] oSoMoN: https://launchpad.net/~ubuntu-core-dev there's lots of options though, see any names you recognize? ;-) [22:33] ogra_, would you have a minute to review and ack the packaging changes in https://code.launchpad.net/~osomon/webbrowser-app/use-grabToImage/+merge/250223 ? [22:34] robru, a bunch of them, yes :) trying a few options now [22:35] camako: one sec [22:40] Thanks robru [22:40] camako: you're welcome! [22:44] robru, @Packaging changes need manual ACKing, do I need to do get a core dev to do this or is it done already? [22:45] camako: normally yes, however that was a trivial diff, so I just waived it through for you [22:46] robru, okay thanks... That's what I thought. [22:46] camako: you're welcome [22:56] robru, I’m off to bed, hopefully kenvandine sees my request and acks the changes and you can do the publication dance while I’m asleep, otherwise I’ll follow up on it first thing tomorrow morning. cheers [22:56] oSoMoN: k, goodnight