[00:49] fginther: yes, I saw the approved message on https://code.launchpad.net/~fboucault/ubuntu-ui-toolkit/tabs_chevron_asset_update/+merge/190639 [00:49] fginther: but normally all the test reports are linked, here there is nothing [02:27] t1mp, successful test results are only posted for ci (non-approved) jobs. A long time ago, successful autolanding results were also posted, but people complained about too much email spam. [02:27] t1mp, if you're curious, the results are here: https://jenkins.qa.ubuntu.com/job/ubuntu-ui-toolkit-autolanding/373/ [07:38] asac: I can't meet my promises for opening the next series in a timely manner because Mark hasn't given us a name. [07:39] asac: We would have been able to do all the initialisation yesterday and probably open around now if not for that obstacle. [07:49] cjwatson: high [07:49] hi [07:49] >) [07:52] cjwatson: so instaed of today we move everything by one day and open on monday? [07:53] I have no idea. We were promised (yesterday) a name by close of play New York time. That promise was broken [07:53] So at this point I can't promise anything until we have a name [07:55] sigh ... [07:55] * ogra_ thought last cycle it was bad [07:59] asac, morning [07:59] fginther: hi! [08:00] fginther: early bird? or a fire burning somehwere? [08:00] asac, are we ok to re-enable auto merging for unity8 [08:00] fginther: i think so [08:00] asac, just up for a bit [08:01] fginther: does it pass now? [08:01] i think they are reasonably close so they can do the final fixes in upstream merger [08:01] fginther: ok... so baby time? :) [08:01] (they should pass now, with the getenv fix) [08:01] fginther: anyway. yeah, i guess we can go for it given that didrocks reported that unityu7 passed [08:01] no, :-( both mir and ro images failed all tests for image 100 [08:02] fginther: hum, you didn't get the memo [08:02] * didrocks fetches and forwards [08:02] baby in the left arm, laptop on the right [08:03] fginther: fwed you 2 emails [08:03] * fginther reads [08:03] fginther: and the last random crash was a getenv issue which is fixed (so all should pass now) [08:16] fginther: ok, thanks :) [08:30] didrocks: cjwatson: can we maybe chat a bit about how we do the saucy-updates images? will we just have daily images rolling with cron for that? would they go into "saucy-proposed" and stay there until we roll an update to users? [08:30] saucy-proposed == system image channel [08:31] asac: hum, I think we should still kick them on demand, as it's more to test the infra for stephan basically than having any useful fix for us [08:31] (apart from the incoming download-manager one) [08:33] asac: I'm more afraid (and I think we should discuss) about how the dashboard and other tools will support the image numbering [08:33] if we release images for saucy and T, they might end up with the same version number [08:33] or different, but saucy > T for instance [08:33] didrocks, ++ (ondemand) [08:34] not sure how our tooling supports that [08:34] didrocks: so we have touch_ro currently. so from resoruce perspective we could keep it running and could notice if things regress right away (feels also like a good exercise imo) [08:34] didrocks: and yes, tooling needs to be discussed and version numbers etc. [08:35] asac: not sure how this is linked to touch_ro? (probably missing a piece ;)) [08:35] I don't think anything much needs to be changed on the image-building side [08:35] Except possibly version numbering, not really familiar enough with system-image's numbering to help there [08:35] cjwatson: does the image builder use a central counter for image numbers? [08:36] e.g. is it unique? [08:36] cjwatson, the test infra works based on image numbering atm [08:36] didrocks: we have two dashboards ... touch_mir and touch_ro [08:36] if we have two same numbers that might fall over [08:36] asac: My stuff is all DATE[.COUNTER] where COUNTER is set if there's been more than one build that day. It is unique per flavour/image-type/series/architecture [08:36] i got asked if we want to kill touch_ro and rename touch_mir to touch; maybe we can say touch and touch_saucy [08:36] asac: right, not sure why we keep testing touch_ro btw :) [08:37] asac: yeah, that's what I discussed yesterday with vila [08:37] asac: I don't know the uniqueness constraints on the system-image stuff, which is all stgraber's [08:37] and I would +1 from that :) [08:37] asac: I would hope that it's only required to be unique per channel or similar [08:37] But I don't actually know [08:38] or we can name that after the channel maybe [08:38] right. so i think the version tarball has info about the channel etc. so it doesnt need to be unique across channels [08:38] * didrocks looks at the wiki page [08:38] didrocks: yes, that 's why asac is pinged on the topic ;) [08:38] ah ok ;) [08:41] asac: the thing I'm really afraid of (not related to the infra) is that we publish, let's say, 10 images on the stable channel (saucy) [08:41] so image 110 [08:41] and 5 in the proposed one (T) [08:41] once we point stable to T… [08:41] 105 < 110, not sure if the system-image-dbus daemon will pick it up [08:42] shouldn't we be talking about image saucy/110 instead? [08:42] (and even if it does, it's not clear to the user) [08:42] I agree we need to make sure any software consumers work [08:42] right, saucy/110 makes more sense [08:43] I mean, at some point we're going to have to maintain longer-lived stable branches [08:43] assuming this stuff gains any commercial popularity/deployment [08:43] right, they will maybe have their custom name… [08:43] didrocks: my understanding is that the device knows well on which channel it is [08:43] didrocks: and hence doesnt care about version numbers being unique across all channels [08:43] but we should check with stgraber... [08:43] asac: yeah, but even in the ui, there is just the image build communicated, so if people goes from 110 to 105, it won't be clear to them :) [08:44] similarly utah can extract that info etc. [08:44] right, let's sync with StevenK :) [08:44] stgraber* [08:44] (sorry StevenK ;)) [08:44] didrocks: well, people going from 110 on devel to 105 on saucy (or the other way around) are switching channels [08:44] asac: not when we'll switch the stable channel to T [08:44] we currently don't support that as a UI nor cli feature on the phone [08:44] they won't know it :) [08:44] didrocks: right. thats a visualization thing on the phone then [08:44] indeed [08:45] we should display the build ID like "saucy@ubuntu.com - build 98" [08:45] (at least, the version is a string, phew! ;)) [08:45] ugh [08:46] we try to roll on top of the distro, lets not put version names in [08:46] not sure. it's a build id ... not really a version [08:46] why not use "1.0 - #98" ? [08:46] yeah [08:46] then, switching to T will be "1.1 - #whatever" [08:46] didrocks: that doesnt explain which channel you are on [08:46] or 1.0.1 [08:46] the UI should clearly display which channel [08:47] asac, didrocks then lets put in "stable, devel, devel-proposed" [08:47] as it's rolling, and we change pointers on the channel… [08:47] but lets not tie to close to distro names [08:47] mm, there is the question of what happens when the stable channel flips [08:47] I guess we just need to make sure that the version is greater, artificially if necessary [08:48] right, for potential manufacturers… they will probably stay on older version (whatever version will mean) [08:48] in fact i think our major version should always match framework/sdk numbers [08:48] ogra_: so not sure... lets talk with stgraber. i am sure he has some thoughts given what channels were already there: [08:48] http://system-image.ubuntu.com/ [08:49] (or APi or however you want to call it) [08:49] so seems we have names of the release... and aliases (stable etc.) [08:49] you can track stable [08:49] or you can track saucy [08:49] its not the same thing [08:49] asac, we talked already, the plan is to have a stable channel and branch saucy away into that [08:49] stable will move on to tripidititity [08:49] :) [08:49] ogra_: i know [08:49] wait [08:49] and manufacturers can take "saucy" [08:49] well. lets have a talk when stgraber is up [08:49] :) [08:50] and will stay spicy/saucy :) [08:50] we should simply not promote to use the release names, as that will get you stuck somewhere [08:50] its a one way street ... once we switch devel over you are stuck [08:50] ogra_: TBH, that's why I pref (version - #id) (and we can map version to saucy, t…) [08:50] switch devel over? [08:50] whats that? [08:50] you mean to T? [08:51] didrocks, exactly [08:51] asac, devel always points to the stable image of the devel release [08:51] bo matter is thats S, T or R or whatever [08:51] *no matter if that is [08:51] right. so we need to first ensure that stable doesnt get updated once we move to T [08:51] agreed [08:51] lets talk to stgraber [08:52] stable will get the released sauct SUR image [08:52] *saucy [08:52] *SRU [08:52] exactly [08:52] damn, cant type at all today [08:52] but then once we start updating tsable from T [08:52] it is not saucy anymore [08:52] ogra_: get some sleep ;) [08:52] hence every channel is special [08:52] asac, what i'm saying is that we need to discourage the usage of the names [08:52] ogra_: +1 [08:52] people should use stable, devel or -proposed [08:53] we can even use "13.10 - #buildid" [08:53] and we should not promote the names at all [08:53] "14.04 - #otherbuildid" [08:53] ogra_: i think thats a long term discussionm to have and yes 13.10 might be a better name to use than saucy [08:53] asac, no [08:53] decouple from ubuntu releases ... focus on our channels only [08:53] well, there are 2 things I guess: [08:54] anyway, lets wait for stgraber. i am sure he has thoughts that we should take as a starting point [08:54] nobody should need to cate if stable is saucy or T [08:54] of if devel is T or U [08:54] - some people/manufacturers will always want the latest and best, so they will be on "stable - #100" [08:54] right [08:54] - some manufacturers want their customers staying on 13.10, so we can show "13.10 - #100" [08:54] maybe it's the same image [08:54] maybe stable points to 14.04 [08:54] so not the same image [08:54] oh, and on a sidenote ... [08:55] HAPPY BIRTHDAY lool !!!!!!!!!!! [08:55] ogra_: quite laggy, he has already showed up (and left) :) [08:55] lool: !!! /me singing !!! [08:55] he has a backlog :) [08:55] yeah, crazy people with bip… [08:55] :) [08:56] didrocks: bip is a good thing [08:56] yep [08:56] with bip you can deprioritize emails a bit, which helps sanity a lot :) [08:56] asac: it's not, I'm sure I lost life hope time due to it :) [08:56] so if it's important, people can email [08:57] harder than just pinging [08:57] right [08:57] or getting 100 "didrocks: ping" when you are back [08:57] without any context [08:57] i take a slightly different perspective that i am happy to discuss over a beer :) [08:57] lol [08:57] heh ;) [08:57] * didrocks feels now so good without bip :p [08:57] (I guess it's still configured on my server, just not running) [08:58] well, it takes me 20min in the morning to read my backlog ... and udually i catch the important bits there so i can just quickly skim through mail [08:58] ogra_: yeah, but mentally you are "connected" [08:58] no [08:58] even if you are at a restaurant, dining [08:58] dinning* [08:58] my bip does that for me ;) [08:58] ok, I feel that way, can't be disconnected mentally [08:58] right. i am super relaxed if i am not working [08:58] knowing people are pinging me [08:59] i dont have to be mentally connected cince it collects the stuff to present it to me when i feel ready [08:59] because of bip [08:59] didrocks: so you have ping nightmares ... or rather daydreams, just because you know there is a bip running. [08:59] wow :) [09:00] asac: exactly! [09:00] waow, my insanity is discovered :p [09:00] i guess you really shouldnt have bip running then [09:00] :) [09:00] I know, that's why I don't anymore :) [09:00] i personally feel it speeds me up ... i only have to read ~100 of the 400 mails i usually get over night [09:00] in pre-bip times that was easily double [09:01] didrocks: maybe the curation lies in exactly doing the opposite: enabling bip and learning not to care :) [09:01] asac: I was using screen + irssi for some years, and then bip for an additional one. It really didn't help [09:01] * didrocks digs up http://blog.didrocks.fr/post/Moving-away-from-(screen-irssi)-to-(bip-weechat) === vrruiz_ is now known as rvr [09:45] asac: hum, seb was asking about indicator fixes for touch only (robru had the request yesterday) [09:46] * didrocks thinks we're blurring the message… [09:46] I don't want us to spend time testing and landing the SRU [09:46] didrocks: well, i explicitely kept the answer generic. yes, the decision whether you do a SRU upload is still the same from before [09:47] didrocks: i even say that if he has concrete cases we have to talk [09:47] asac: well, if you're telling that, robru will be pushed to land this fix [09:47] didrocks: i hope not [09:47] it was the case yesterday [09:47] and it seems you're contradicting my email which tried to make a clear line :/ [09:47] didrocks: to be honest imo there was not enough info to assume that i am answering or approving a concrete case [09:47] we'll see [09:47] didrocks: i am not contradicting [09:48] the fix is http://bazaar.launchpad.net/~indicator-applet-developers/indicator-messages/trunk.14.04/revision/393 [09:48] FYI [09:48] i am saying that SRUs are done like before... (just that they shouldnt bother for touch) [09:48] didrocks: is robru on ue-leads? [09:48] you didn't tell that they shouldn't both for touch [09:48] asac: no, he's not [09:48] that's why I gave him the same details this morning [09:49] about the SRU policy for touch and what to do for others [09:50] bother* [10:23] didrocks: so for now all we are and should be doing is handing out an internal guideline and inform people about the relative priorities. this should be more than enough to convince people to not put too much effort into SRUing for touch on saucy - which is the goal here. [10:24] asac: I agree, that's what I tried to do with that email :) [10:24] and luckily in CI landing team we have a chance to talk to them 1-on-1 [10:24] * didrocks -> lunch [10:24] with them and convince them that it might be unwise [10:24] hehe [10:24] didrocks: enjoy [10:24] thanks! [10:25] asac, well, depends, while i'm completely in the "forbid all SRUs, concentrate on making the first T image rock" camp ... without T opening in time thats a moot thing :( [10:26] use a ppa ? [10:27] apw, against what release ? [10:28] apw, the point is we want to roll on top if the archive with our stuff [10:28] against S, doesn't matter, you make it in there, and when T finally appears you copy the lot out to there [10:28] apw, if the archive doesnt open ofr a week we fall behind .. no PPA will help uploading to T if T doesnt exist [10:28] you make a new PPA called "what we want in T" and you upload to that as if it was T, but in the S pocket [10:29] and use it as the archive [10:29] apw, we have -updates and the possibility to do SRUs. but thats exactly the opposite of what we need to do [10:29] not suggesting sru's, i am suggesting a PPA which you treat as T, just use S as the upload name [10:29] that is functionally equivalent to a T pocket no ? [10:30] right, we dont want PPAs in official images anymore and -updayes provides tecnically what we need [10:30] it might be functionally equivalent but wont give us the bugs the new archive will [10:30] we would still have to fix them once our underlying stuff changes [10:31] except it is protected by the sru team and a PPA isn't [10:31] That's no excuse to stop development. [10:31] Not having it in an image doesn't mean you can't do all the programming, building, and testing up to that point. [10:32] Anyhow, if you want to complain about the lack of T, I recommend phoning Mark. [10:32] Repeatedly. [10:32] heh [10:32] i assume someone does that already [10:32] yes [10:32] (s/assume/hope/ [10:32] ) [10:33] first thing I did this morning was escalate to silbs [10:39] ogra_: upstream merger continues working, so there is at least no complete blockage [10:39] landings are stalled, which is unfortunate, but i dont anticipate this to delay much longer (for nwo :)) [10:39] otherwise we can revisit other mitigation options on monday === sil2100_ is now known as sil2100 [11:05] right, there is still option of daily-build-next -> next [11:05] which is exactly how we handled daily releases for raring -> saucy transition, and what apw suggested in fact (but already exist and already supported ;)) [11:05] then switching from the ppa to T is a 2 line diff [11:17] @ci, can anyone push the latest trunk build https://code.launchpad.net/~phablet-team/qtubuntu-sensors/trunk to the phone? It will provide haptic feedback for buttons :) [11:18] rev 38 [11:24] nik90: hey, last time we tried it, it wasn't working [11:24] nik90: see line 185 on the landing ask [11:24] so we are waiting on kalikiana's feedback [11:25] nik90: and now, we're waiting for T to open to push those kind of fixes (people will be transitionned to it) [11:25] but I think first, we need the confirmation it really works :) [11:28] didrocks: ah okay [11:28] didrocks: where I can the landing ask? [11:29] nik90: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=1 should be what you need [11:30] thnx [11:30] yw, keep us posted! ;) [11:31] nik90: haptic feedback for buttons? that's sounds very awesome [11:32] t1mp: I know :)...hopefully kalikiana can chime in to this discussion when available [12:01] nik90: t1mp hmm what's being asked from me exactly? [12:04] kalikiana: look at the landing ask you filed, there are some comments on landing qtubuntu-sensors (mirv tested it, and it didn't work) [12:07] okay, I'll give it another test run; we were testing it in a devel image in parallel and I was running into several unrelated problems - I didn't know it didn't work for mirv at all [12:09] kalikiana: he'll be back on Monday. If it's working for you, maybe you can check with him? [12:10] I "used to" work, the problem is that a ton of "noise" makes it hard to make a statement on the latest image [12:10] *It [12:10] so I'm trying on the proposed image now === alan_g is now known as alan_g|lunch === gatox is now known as gatox_brb [13:00] hm "can't open /cache/recovery/ubuntu_command" after 2 attempts [13:00] asac, ogra_: Thanks! [13:00] :) [13:00] is it worth rebooting and trying again or should I file a bug? [13:01] kalikiana, both ! [13:01] :) [13:01] :-D [13:01] the proposed and the devel image are indentical btw === gatox_brb is now known as gatox [13:07] ogra_: https://bugs.launchpad.net/phablet-tools/+bug/1241568 [13:07] Ubuntu bug 1241568 in Phablet Tools "Flashing stuck: can't open /cache/recovery/ubuntu_command" [Undecided,New] [13:08] kalikiana, thanks === alan_g|lunch is now known as alan_g [13:26] sil2100, you around? [13:30] fginther: yes! [13:30] Just finished lunch [13:31] sil2100, I left you a pm [13:31] fginther: yes, I see it - commenting! Thanks [14:03] asac, we have a name !!! [14:06] Already working on it, though I need to leave in <3 hours [14:08] we have? [14:08] :) [14:09] the trusty tahr [14:13] nice [14:16] I have come to know of these animals only after the announcement of the code names :) [14:20] thats the plan behind these names ;) [14:20] finding an animal plus an adjective thats unique on google as a combo [14:20] that way you will always find ubuntu using these two === alan_g is now known as alan_g|tea [14:34] cjwatson: how will we coordinate doing the first image after the toolchain? i assume thats something to look at monday? [14:35] asac, the default in cdimage will change at the toplevel [14:35] (i suggest we dont really stress this... we have a name, and the day delay we got is fine imo) [14:35] the rest is bugfixing uninstallable packages [14:35] (if we even need that) [14:35] ogra_: and we get stgraber do magic to the system-image job [14:35] so it does the right thing [14:36] still, we need to coordinate when the toolchain is done [14:36] right, not sure whats needed on stgrabers side [14:36] so we can do one image etc. [14:36] doanac: there? [14:36] doanac: what do we need to do if we want touch_mir to point to trusty? [14:36] i think though that we could try building the first image by next friday [14:36] doanac: and keep another one rolling that tests saucy-proposed channel? [14:36] (replacing touch_ro) [14:37] asac: I don't have time to coordinate it today, but I'd hoped to get the auto-sync running over the weekend so that it can be mostly built by the time people care [14:37] I don't know if I'll have time for that [14:37] cjwatson: hmm. so no clean first image? [14:38] ?? [14:38] asac, did you expect an image today ? [14:38] ogra_: plan was to land toolchain, then kick an image and then start with the normal archive stuff like autosync etc. [14:38] yes [14:38] right after landing the toolchain [14:38] ah [14:38] before auto-imports and what not [14:39] well, moday or tuesday will do i guess [14:39] asac: its basically a config change for us [14:39] should be fairly simple [14:39] ogra_: right, but i feel cjwatson wants to turn the auto syncs etc. on before the weekend [14:39] err [14:39] during weekend [14:39] so there wont be such an image with those properties [14:39] doanac: can you already do that? [14:39] asac, why is that impirtant ? it would be identical to #100 [14:40] asac: yes. i'll get with josepht and plars to get it ready [14:40] ogra_: new toolchain, good first image to start the release cycle [14:40] just with a different name stamped in [14:40] various reasons, also social reasons [14:40] ogra_: right. it ensurees we can rerun images from our new release on our new infrastructure [14:40] before the rough weather arrives [14:40] i would wait until the first import chunk landed [14:40] pipecleaning after the switch over basically [14:40] there wont be rough weather [14:40] well, was discussed before [14:41] there wasnt in saucy, there wont be in T [14:41] just asked cjwatson if he plans changing plans now that the name is late [14:41] ogra_: not everyone believes your guts :) [14:41] * ogra_ trusts our infrastructure [14:41] haha [14:41] in that area it has matured 9 years [14:42] saucy was completely flawless in that regard and i expect the same for trusty [14:42] its simple. you start a new cycle, you produce a first new image that is the same, has the new tooclhain and gives you confidence that everything is good aka green :) [14:42] not sure why we should miss something that cheap to do [14:42] we never did that [14:42] it doesnt require more than pushing the build image button once the toolchain is in [14:42] doesnt mean we shouldnt do it :) [14:42] after all a new toolchain wont give you anything [14:43] after all we want to move all UE over to T from day 1 [14:43] your binaries havent been rebuilt [14:43] we didnt do that either in last cycles [14:43] and we dont ship the toolchain [14:43] its not about that [14:43] its about the rest :) [14:43] (well, we ship gdb) [14:43] anyway. lets wait for cjwatson [14:43] what rest ? [14:43] all binaries will be identical to image 100 [14:43] so you can as well take 100 as the reference [14:43] asac: If we have time for a clean first image I'd like to do that [14:44] cjwatson: from touch, UE perspective we have the time [14:44] we can totally live with a delay of 1 day [14:44] asac: But it will probably involve you promising not to complain about auto-syncs running during the week [14:44] (the initial bulk, that is) [14:44] cjwatson: did i say that i would complain? :) [14:44] I'm just being cautious :) [14:44] i thought we just keep a very close eye on it and do things if stuff regresses [14:44] matter of experience ? :) [14:44] etc. [14:44] The builders will be slower than usual, there'll probably be some build failures as things settle down [14:44] I need people not to be panicking about that [14:45] cjwatson: i anticipated that we experiment how things go... probably starting with "auto syncs" for a bit and then see [14:45] It should be fine once the initial batch lands [14:45] ogra_: You ship libgcc [14:45] cjwatson: right. but from what i understand things that fail to build will be stuck in proposed and all things that depend on it with it. [14:45] That's about it though [14:45] cjwatson, yeah [14:45] asac: Yeah, but builds run against proposed, necessarily [14:45] cjwatson: so those we will have a chance to take a look at etc. [14:45] asac: So some builds will normally fail [14:45] ah ... sure [14:46] we will see... we should just keep a bit of a forecast so we know whats coming [14:46] etc. [14:47]