| t1mp | fginther: yes, I saw the approved message on https://code.launchpad.net/~fboucault/ubuntu-ui-toolkit/tabs_chevron_asset_update/+merge/190639 | 00:49 |
|---|---|---|
| t1mp | fginther: but normally all the test reports are linked, here there is nothing | 00:49 |
| fginther | 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 |
| fginther | t1mp, if you're curious, the results are here: https://jenkins.qa.ubuntu.com/job/ubuntu-ui-toolkit-autolanding/373/ | 02:27 |
| cjwatson | 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:38 |
| cjwatson | asac: We would have been able to do all the initialisation yesterday and probably open around now if not for that obstacle. | 07:39 |
| asac | cjwatson: high | 07:49 |
| asac | hi | 07:49 |
| asac | >) | 07:49 |
| asac | cjwatson: so instaed of today we move everything by one day and open on monday? | 07:52 |
| cjwatson | I have no idea. We were promised (yesterday) a name by close of play New York time. That promise was broken | 07:53 |
| cjwatson | So at this point I can't promise anything until we have a name | 07:53 |
| ogra_ | sigh ... | 07:55 |
| * ogra_ thought last cycle it was bad | 07:55 | |
| fginther | asac, morning | 07:59 |
| asac | fginther: hi! | 07:59 |
| asac | fginther: early bird? or a fire burning somehwere? | 08:00 |
| fginther | asac, are we ok to re-enable auto merging for unity8 | 08:00 |
| asac | fginther: i think so | 08:00 |
| fginther | asac, just up for a bit | 08:00 |
| asac | fginther: does it pass now? | 08:01 |
| asac | i think they are reasonably close so they can do the final fixes in upstream merger | 08:01 |
| asac | fginther: ok... so baby time? :) | 08:01 |
| didrocks | (they should pass now, with the getenv fix) | 08:01 |
| asac | fginther: anyway. yeah, i guess we can go for it given that didrocks reported that unityu7 passed | 08:01 |
| fginther | no, :-( both mir and ro images failed all tests for image 100 | 08:01 |
| didrocks | fginther: hum, you didn't get the memo | 08:02 |
| * didrocks fetches and forwards | 08:02 | |
| fginther | baby in the left arm, laptop on the right | 08:02 |
| didrocks | fginther: fwed you 2 emails | 08:03 |
| * fginther reads | 08:03 | |
| didrocks | fginther: and the last random crash was a getenv issue which is fixed (so all should pass now) | 08:03 |
| t1mp | fginther: ok, thanks :) | 08:16 |
| asac | 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 |
| asac | saucy-proposed == system image channel | 08:30 |
| didrocks | 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 |
| didrocks | (apart from the incoming download-manager one) | 08:31 |
| didrocks | 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 |
| didrocks | if we release images for saucy and T, they might end up with the same version number | 08:33 |
| didrocks | or different, but saucy > T for instance | 08:33 |
| ogra_ | didrocks, ++ (ondemand) | 08:33 |
| didrocks | not sure how our tooling supports that | 08:34 |
| asac | 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 |
| asac | didrocks: and yes, tooling needs to be discussed and version numbers etc. | 08:34 |
| didrocks | asac: not sure how this is linked to touch_ro? (probably missing a piece ;)) | 08:35 |
| cjwatson | I don't think anything much needs to be changed on the image-building side | 08:35 |
| cjwatson | Except possibly version numbering, not really familiar enough with system-image's numbering to help there | 08:35 |
| asac | cjwatson: does the image builder use a central counter for image numbers? | 08:35 |
| asac | e.g. is it unique? | 08:36 |
| ogra_ | cjwatson, the test infra works based on image numbering atm | 08:36 |
| asac | didrocks: we have two dashboards ... touch_mir and touch_ro | 08:36 |
| ogra_ | if we have two same numbers that might fall over | 08:36 |
| cjwatson | 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 |
| asac | 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 |
| didrocks | asac: right, not sure why we keep testing touch_ro btw :) | 08:36 |
| didrocks | asac: yeah, that's what I discussed yesterday with vila | 08:37 |
| cjwatson | asac: I don't know the uniqueness constraints on the system-image stuff, which is all stgraber's | 08:37 |
| didrocks | and I would +1 from that :) | 08:37 |
| cjwatson | asac: I would hope that it's only required to be unique per channel or similar | 08:37 |
| cjwatson | But I don't actually know | 08:37 |
| didrocks | or we can name that after the channel maybe | 08:38 |
| asac | 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 | |
| vila | didrocks: yes, that 's why asac is pinged on the topic ;) | 08:38 |
| didrocks | ah ok ;) | 08:38 |
| didrocks | 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 |
| didrocks | so image 110 | 08:41 |
| didrocks | and 5 in the proposed one (T) | 08:41 |
| didrocks | once we point stable to T… | 08:41 |
| didrocks | 105 < 110, not sure if the system-image-dbus daemon will pick it up | 08:41 |
| cjwatson | shouldn't we be talking about image saucy/110 instead? | 08:42 |
| didrocks | (and even if it does, it's not clear to the user) | 08:42 |
| cjwatson | I agree we need to make sure any software consumers work | 08:42 |
| didrocks | right, saucy/110 makes more sense | 08:42 |
| cjwatson | I mean, at some point we're going to have to maintain longer-lived stable branches | 08:43 |
| cjwatson | assuming this stuff gains any commercial popularity/deployment | 08:43 |
| didrocks | right, they will maybe have their custom name… | 08:43 |
| asac | didrocks: my understanding is that the device knows well on which channel it is | 08:43 |
| asac | didrocks: and hence doesnt care about version numbers being unique across all channels | 08:43 |
| asac | but we should check with stgraber... | 08:43 |
| didrocks | 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:43 |
| asac | similarly utah can extract that info etc. | 08:44 |
| didrocks | right, let's sync with StevenK :) | 08:44 |
| didrocks | stgraber* | 08:44 |
| didrocks | (sorry StevenK ;)) | 08:44 |
| asac | didrocks: well, people going from 110 on devel to 105 on saucy (or the other way around) are switching channels | 08:44 |
| didrocks | asac: not when we'll switch the stable channel to T | 08:44 |
| asac | we currently don't support that as a UI nor cli feature on the phone | 08:44 |
| didrocks | they won't know it :) | 08:44 |
| asac | didrocks: right. thats a visualization thing on the phone then | 08:44 |
| didrocks | indeed | 08:44 |
| asac | we should display the build ID like "saucy@ubuntu.com - build 98" | 08:45 |
| didrocks | (at least, the version is a string, phew! ;)) | 08:45 |
| ogra_ | ugh | 08:45 |
| ogra_ | we try to roll on top of the distro, lets not put version names in | 08:46 |
| asac | not sure. it's a build id ... not really a version | 08:46 |
| didrocks | why not use "1.0 - #98" ? | 08:46 |
| ogra_ | yeah | 08:46 |
| didrocks | then, switching to T will be "1.1 - #whatever" | 08:46 |
| asac | didrocks: that doesnt explain which channel you are on | 08:46 |
| didrocks | or 1.0.1 | 08:46 |
| asac | the UI should clearly display which channel | 08:46 |
| ogra_ | asac, didrocks then lets put in "stable, devel, devel-proposed" | 08:47 |
| didrocks | as it's rolling, and we change pointers on the channel… | 08:47 |
| ogra_ | but lets not tie to close to distro names | 08:47 |
| cjwatson | mm, there is the question of what happens when the stable channel flips | 08:47 |
| cjwatson | I guess we just need to make sure that the version is greater, artificially if necessary | 08:47 |
| didrocks | right, for potential manufacturers… they will probably stay on older version (whatever version will mean) | 08:48 |
| ogra_ | in fact i think our major version should always match framework/sdk numbers | 08:48 |
| asac | ogra_: so not sure... lets talk with stgraber. i am sure he has some thoughts given what channels were already there: | 08:48 |
| asac | http://system-image.ubuntu.com/ | 08:48 |
| ogra_ | (or APi or however you want to call it) | 08:49 |
| asac | so seems we have names of the release... and aliases (stable etc.) | 08:49 |
| asac | you can track stable | 08:49 |
| asac | or you can track saucy | 08:49 |
| asac | its not the same thing | 08:49 |
| ogra_ | asac, we talked already, the plan is to have a stable channel and branch saucy away into that | 08:49 |
| asac | stable will move on to tripidititity | 08:49 |
| asac | :) | 08:49 |
| asac | ogra_: i know | 08:49 |
| asac | wait | 08:49 |
| didrocks | and manufacturers can take "saucy" | 08:49 |
| asac | well. lets have a talk when stgraber is up | 08:49 |
| asac | :) | 08:49 |
| didrocks | and will stay spicy/saucy :) | 08:50 |
| ogra_ | we should simply not promote to use the release names, as that will get you stuck somewhere | 08:50 |
| ogra_ | its a one way street ... once we switch devel over you are stuck | 08:50 |
| didrocks | ogra_: TBH, that's why I pref (version - #id) (and we can map version to saucy, t…) | 08:50 |
| asac | switch devel over? | 08:50 |
| asac | whats that? | 08:50 |
| asac | you mean to T? | 08:50 |
| ogra_ | didrocks, exactly | 08:51 |
| ogra_ | asac, devel always points to the stable image of the devel release | 08:51 |
| ogra_ | bo matter is thats S, T or R or whatever | 08:51 |
| ogra_ | *no matter if that is | 08:51 |
| asac | right. so we need to first ensure that stable doesnt get updated once we move to T | 08:51 |
| asac | agreed | 08:51 |
| asac | lets talk to stgraber | 08:51 |
| ogra_ | stable will get the released sauct SUR image | 08:52 |
| ogra_ | *saucy | 08:52 |
| ogra_ | *SRU | 08:52 |
| asac | exactly | 08:52 |
| ogra_ | damn, cant type at all today | 08:52 |
| asac | but then once we start updating tsable from T | 08:52 |
| asac | it is not saucy anymore | 08:52 |
| didrocks | ogra_: get some sleep ;) | 08:52 |
| asac | hence every channel is special | 08:52 |
| ogra_ | asac, what i'm saying is that we need to discourage the usage of the names | 08:52 |
| didrocks | ogra_: +1 | 08:52 |
| ogra_ | people should use stable, devel or -proposed | 08:52 |
| didrocks | we can even use "13.10 - #buildid" | 08:53 |
| ogra_ | and we should not promote the names at all | 08:53 |
| didrocks | "14.04 - #otherbuildid" | 08:53 |
| asac | 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 |
| ogra_ | asac, no | 08:53 |
| ogra_ | decouple from ubuntu releases ... focus on our channels only | 08:53 |
| didrocks | well, there are 2 things I guess: | 08:53 |
| asac | anyway, lets wait for stgraber. i am sure he has thoughts that we should take as a starting point | 08:54 |
| ogra_ | nobody should need to cate if stable is saucy or T | 08:54 |
| ogra_ | of if devel is T or U | 08:54 |
| didrocks | - some people/manufacturers will always want the latest and best, so they will be on "stable - #100" | 08:54 |
| ogra_ | right | 08:54 |
| didrocks | - some manufacturers want their customers staying on 13.10, so we can show "13.10 - #100" | 08:54 |
| didrocks | maybe it's the same image | 08:54 |
| didrocks | maybe stable points to 14.04 | 08:54 |
| didrocks | so not the same image | 08:54 |
| ogra_ | oh, and on a sidenote ... | 08:54 |
| ogra_ | HAPPY BIRTHDAY lool !!!!!!!!!!! | 08:55 |
| didrocks | ogra_: quite laggy, he has already showed up (and left) :) | 08:55 |
| asac | lool: !!! /me singing !!! | 08:55 |
| ogra_ | he has a backlog :) | 08:55 |
| didrocks | yeah, crazy people with bip… | 08:55 |
| ogra_ | :) | 08:55 |
| asac | didrocks: bip is a good thing | 08:56 |
| ogra_ | yep | 08:56 |
| asac | with bip you can deprioritize emails a bit, which helps sanity a lot :) | 08:56 |
| didrocks | asac: it's not, I'm sure I lost life hope time due to it :) | 08:56 |
| didrocks | so if it's important, people can email | 08:56 |
| didrocks | harder than just pinging | 08:57 |
| asac | right | 08:57 |
| didrocks | or getting 100 "didrocks: ping" when you are back | 08:57 |
| didrocks | without any context | 08:57 |
| asac | i take a slightly different perspective that i am happy to discuss over a beer :) | 08:57 |
| asac | lol | 08:57 |
| didrocks | heh ;) | 08:57 |
| * didrocks feels now so good without bip :p | 08:57 | |
| didrocks | (I guess it's still configured on my server, just not running) | 08:57 |
| ogra_ | 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 |
| didrocks | ogra_: yeah, but mentally you are "connected" | 08:58 |
| ogra_ | no | 08:58 |
| didrocks | even if you are at a restaurant, dining | 08:58 |
| didrocks | dinning* | 08:58 |
| ogra_ | my bip does that for me ;) | 08:58 |
| didrocks | ok, I feel that way, can't be disconnected mentally | 08:58 |
| asac | right. i am super relaxed if i am not working | 08:58 |
| didrocks | knowing people are pinging me | 08:58 |
| ogra_ | i dont have to be mentally connected cince it collects the stuff to present it to me when i feel ready | 08:59 |
| asac | because of bip | 08:59 |
| asac | didrocks: so you have ping nightmares ... or rather daydreams, just because you know there is a bip running. | 08:59 |
| asac | wow :) | 08:59 |
| didrocks | asac: exactly! | 09:00 |
| didrocks | waow, my insanity is discovered :p | 09:00 |
| asac | i guess you really shouldnt have bip running then | 09:00 |
| asac | :) | 09:00 |
| didrocks | I know, that's why I don't anymore :) | 09:00 |
| ogra_ | i personally feel it speeds me up ... i only have to read ~100 of the 400 mails i usually get over night | 09:00 |
| ogra_ | in pre-bip times that was easily double | 09:00 |
| asac | didrocks: maybe the curation lies in exactly doing the opposite: enabling bip and learning not to care :) | 09:01 |
| didrocks | 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) | 09:01 | |
| === vrruiz_ is now known as rvr | ||
| didrocks | asac: hum, seb was asking about indicator fixes for touch only (robru had the request yesterday) | 09:45 |
| * didrocks thinks we're blurring the message… | 09:46 | |
| didrocks | I don't want us to spend time testing and landing the SRU | 09:46 |
| asac | didrocks: well, i explicitely kept the answer generic. yes, the decision whether you do a SRU upload is still the same from before | 09:46 |
| asac | didrocks: i even say that if he has concrete cases we have to talk | 09:47 |
| didrocks | asac: well, if you're telling that, robru will be pushed to land this fix | 09:47 |
| asac | didrocks: i hope not | 09:47 |
| didrocks | it was the case yesterday | 09:47 |
| didrocks | and it seems you're contradicting my email which tried to make a clear line :/ | 09:47 |
| asac | didrocks: to be honest imo there was not enough info to assume that i am answering or approving a concrete case | 09:47 |
| didrocks | we'll see | 09:47 |
| asac | didrocks: i am not contradicting | 09:47 |
| didrocks | the fix is http://bazaar.launchpad.net/~indicator-applet-developers/indicator-messages/trunk.14.04/revision/393 | 09:48 |
| didrocks | FYI | 09:48 |
| asac | i am saying that SRUs are done like before... (just that they shouldnt bother for touch) | 09:48 |
| asac | didrocks: is robru on ue-leads? | 09:48 |
| didrocks | you didn't tell that they shouldn't both for touch | 09:48 |
| didrocks | asac: no, he's not | 09:48 |
| didrocks | that's why I gave him the same details this morning | 09:48 |
| didrocks | about the SRU policy for touch and what to do for others | 09:49 |
| didrocks | bother* | 09:50 |
| asac | 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:23 |
| didrocks | asac: I agree, that's what I tried to do with that email :) | 10:24 |
| asac | and luckily in CI landing team we have a chance to talk to them 1-on-1 | 10:24 |
| * didrocks -> lunch | 10:24 | |
| asac | with them and convince them that it might be unwise | 10:24 |
| asac | hehe | 10:24 |
| asac | didrocks: enjoy | 10:24 |
| didrocks | thanks! | 10:24 |
| ogra_ | 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:25 |
| apw | use a ppa ? | 10:26 |
| ogra_ | apw, against what release ? | 10:27 |
| ogra_ | apw, the point is we want to roll on top if the archive with our stuff | 10:28 |
| apw | against S, doesn't matter, you make it in there, and when T finally appears you copy the lot out to there | 10:28 |
| ogra_ | 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 |
| apw | 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:28 |
| apw | and use it as the archive | 10:29 |
| ogra_ | apw, we have -updates and the possibility to do SRUs. but thats exactly the opposite of what we need to do | 10:29 |
| apw | not suggesting sru's, i am suggesting a PPA which you treat as T, just use S as the upload name | 10:29 |
| apw | that is functionally equivalent to a T pocket no ? | 10:29 |
| ogra_ | right, we dont want PPAs in official images anymore and -updayes provides tecnically what we need | 10:30 |
| ogra_ | it might be functionally equivalent but wont give us the bugs the new archive will | 10:30 |
| ogra_ | we would still have to fix them once our underlying stuff changes | 10:30 |
| apw | except it is protected by the sru team and a PPA isn't | 10:31 |
| infinity | That's no excuse to stop development. | 10:31 |
| infinity | Not having it in an image doesn't mean you can't do all the programming, building, and testing up to that point. | 10:31 |
| infinity | Anyhow, if you want to complain about the lack of T, I recommend phoning Mark. | 10:32 |
| infinity | Repeatedly. | 10:32 |
| ogra_ | heh | 10:32 |
| ogra_ | i assume someone does that already | 10:32 |
| cjwatson | yes | 10:32 |
| ogra_ | (s/assume/hope/ | 10:32 |
| ogra_ | ) | 10:32 |
| cjwatson | first thing I did this morning was escalate to silbs | 10:33 |
| asac | ogra_: upstream merger continues working, so there is at least no complete blockage | 10:39 |
| asac | landings are stalled, which is unfortunate, but i dont anticipate this to delay much longer (for nwo :)) | 10:39 |
| asac | otherwise we can revisit other mitigation options on monday | 10:39 |
| === sil2100_ is now known as sil2100 | ||
| didrocks | right, there is still option of daily-build-next -> next | 11:05 |
| didrocks | 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 |
| didrocks | then switching from the ppa to T is a 2 line diff | 11:05 |
| nik90 | @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:17 |
| nik90 | rev 38 | 11:18 |
| didrocks | nik90: hey, last time we tried it, it wasn't working | 11:24 |
| didrocks | nik90: see line 185 on the landing ask | 11:24 |
| didrocks | so we are waiting on kalikiana's feedback | 11:24 |
| didrocks | nik90: and now, we're waiting for T to open to push those kind of fixes (people will be transitionned to it) | 11:25 |
| didrocks | but I think first, we need the confirmation it really works :) | 11:25 |
| nik90 | didrocks: ah okay | 11:28 |
| nik90 | didrocks: where I can the landing ask? | 11:28 |
| didrocks | nik90: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=1 should be what you need | 11:29 |
| nik90 | thnx | 11:30 |
| didrocks | yw, keep us posted! ;) | 11:30 |
| t1mp | nik90: haptic feedback for buttons? that's sounds very awesome | 11:31 |
| nik90 | t1mp: I know :)...hopefully kalikiana can chime in to this discussion when available | 11:32 |
| kalikiana | nik90: t1mp hmm what's being asked from me exactly? | 12:01 |
| didrocks | 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:04 |
| kalikiana | 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:07 |
| didrocks | kalikiana: he'll be back on Monday. If it's working for you, maybe you can check with him? | 12:09 |
| kalikiana | 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 |
| kalikiana | *It | 12:10 |
| kalikiana | so I'm trying on the proposed image now | 12:10 |
| === alan_g is now known as alan_g|lunch | ||
| === gatox is now known as gatox_brb | ||
| kalikiana | hm "can't open /cache/recovery/ubuntu_command" after 2 attempts | 13:00 |
| lool | asac, ogra_: Thanks! | 13:00 |
| ogra_ | :) | 13:00 |
| kalikiana | is it worth rebooting and trying again or should I file a bug? | 13:00 |
| ogra_ | kalikiana, both ! | 13:01 |
| ogra_ | :) | 13:01 |
| kalikiana | :-D | 13:01 |
| ogra_ | the proposed and the devel image are indentical btw | 13:01 |
| === gatox_brb is now known as gatox | ||
| kalikiana | ogra_: https://bugs.launchpad.net/phablet-tools/+bug/1241568 | 13:07 |
| ubot5 | Ubuntu bug 1241568 in Phablet Tools "Flashing stuck: can't open /cache/recovery/ubuntu_command" [Undecided,New] | 13:07 |
| ogra_ | kalikiana, thanks | 13:08 |
| === alan_g|lunch is now known as alan_g | ||
| fginther | sil2100, you around? | 13:26 |
| sil2100 | fginther: yes! | 13:30 |
| sil2100 | Just finished lunch | 13:30 |
| fginther | sil2100, I left you a pm | 13:31 |
| sil2100 | fginther: yes, I see it - commenting! Thanks | 13:31 |
| ogra_ | asac, we have a name !!! | 14:03 |
| cjwatson | Already working on it, though I need to leave in <3 hours | 14:06 |
| asac | we have? | 14:08 |
| asac | :) | 14:08 |
| ogra_ | the trusty tahr | 14:09 |
| asac | nice | 14:13 |
| nik90 | I have come to know of these animals only after the announcement of the code names :) | 14:16 |
| ogra_ | thats the plan behind these names ;) | 14:20 |
| ogra_ | finding an animal plus an adjective thats unique on google as a combo | 14:20 |
| ogra_ | that way you will always find ubuntu using these two | 14:20 |
| === alan_g is now known as alan_g|tea | ||
| asac | cjwatson: how will we coordinate doing the first image after the toolchain? i assume thats something to look at monday? | 14:34 |
| ogra_ | asac, the default in cdimage will change at the toplevel | 14:35 |
| asac | (i suggest we dont really stress this... we have a name, and the day delay we got is fine imo) | 14:35 |
| ogra_ | the rest is bugfixing uninstallable packages | 14:35 |
| ogra_ | (if we even need that) | 14:35 |
| asac | ogra_: and we get stgraber do magic to the system-image job | 14:35 |
| asac | so it does the right thing | 14:35 |
| asac | still, we need to coordinate when the toolchain is done | 14:36 |
| ogra_ | right, not sure whats needed on stgrabers side | 14:36 |
| asac | so we can do one image etc. | 14:36 |
| asac | doanac: there? | 14:36 |
| asac | doanac: what do we need to do if we want touch_mir to point to trusty? | 14:36 |
| ogra_ | i think though that we could try building the first image by next friday | 14:36 |
| asac | doanac: and keep another one rolling that tests saucy-proposed channel? | 14:36 |
| asac | (replacing touch_ro) | 14:36 |
| cjwatson | 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 |
| cjwatson | I don't know if I'll have time for that | 14:37 |
| asac | cjwatson: hmm. so no clean first image? | 14:37 |
| ogra_ | ?? | 14:38 |
| ogra_ | asac, did you expect an image today ? | 14:38 |
| asac | ogra_: plan was to land toolchain, then kick an image and then start with the normal archive stuff like autosync etc. | 14:38 |
| asac | yes | 14:38 |
| asac | right after landing the toolchain | 14:38 |
| ogra_ | ah | 14:38 |
| asac | before auto-imports and what not | 14:38 |
| ogra_ | well, moday or tuesday will do i guess | 14:39 |
| doanac | asac: its basically a config change for us | 14:39 |
| doanac | should be fairly simple | 14:39 |
| asac | ogra_: right, but i feel cjwatson wants to turn the auto syncs etc. on before the weekend | 14:39 |
| asac | err | 14:39 |
| asac | during weekend | 14:39 |
| asac | so there wont be such an image with those properties | 14:39 |
| asac | doanac: can you already do that? | 14:39 |
| ogra_ | asac, why is that impirtant ? it would be identical to #100 | 14:39 |
| doanac | asac: yes. i'll get with josepht and plars to get it ready | 14:40 |
| asac | ogra_: new toolchain, good first image to start the release cycle | 14:40 |
| ogra_ | just with a different name stamped in | 14:40 |
| asac | various reasons, also social reasons | 14:40 |
| asac | ogra_: right. it ensurees we can rerun images from our new release on our new infrastructure | 14:40 |
| asac | before the rough weather arrives | 14:40 |
| ogra_ | i would wait until the first import chunk landed | 14:40 |
| asac | pipecleaning after the switch over basically | 14:40 |
| ogra_ | there wont be rough weather | 14:40 |
| asac | well, was discussed before | 14:40 |
| ogra_ | there wasnt in saucy, there wont be in T | 14:41 |
| asac | just asked cjwatson if he plans changing plans now that the name is late | 14:41 |
| asac | ogra_: not everyone believes your guts :) | 14:41 |
| * ogra_ trusts our infrastructure | 14:41 | |
| asac | haha | 14:41 |
| ogra_ | in that area it has matured 9 years | 14:41 |
| ogra_ | saucy was completely flawless in that regard and i expect the same for trusty | 14:42 |
| asac | 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 |
| asac | not sure why we should miss something that cheap to do | 14:42 |
| ogra_ | we never did that | 14:42 |
| asac | it doesnt require more than pushing the build image button once the toolchain is in | 14:42 |
| asac | doesnt mean we shouldnt do it :) | 14:42 |
| ogra_ | after all a new toolchain wont give you anything | 14:42 |
| asac | after all we want to move all UE over to T from day 1 | 14:43 |
| ogra_ | your binaries havent been rebuilt | 14:43 |
| asac | we didnt do that either in last cycles | 14:43 |
| ogra_ | and we dont ship the toolchain | 14:43 |
| asac | its not about that | 14:43 |
| asac | its about the rest :) | 14:43 |
| ogra_ | (well, we ship gdb) | 14:43 |
| asac | anyway. lets wait for cjwatson | 14:43 |
| ogra_ | what rest ? | 14:43 |
| ogra_ | all binaries will be identical to image 100 | 14:43 |
| ogra_ | so you can as well take 100 as the reference | 14:43 |
| cjwatson | asac: If we have time for a clean first image I'd like to do that | 14:43 |
| asac | cjwatson: from touch, UE perspective we have the time | 14:44 |
| asac | we can totally live with a delay of 1 day | 14:44 |
| cjwatson | asac: But it will probably involve you promising not to complain about auto-syncs running during the week | 14:44 |
| cjwatson | (the initial bulk, that is) | 14:44 |
| asac | cjwatson: did i say that i would complain? :) | 14:44 |
| cjwatson | I'm just being cautious :) | 14:44 |
| asac | i thought we just keep a very close eye on it and do things if stuff regresses | 14:44 |
| ogra_ | matter of experience ? :) | 14:44 |
| asac | etc. | 14:44 |
| cjwatson | The builders will be slower than usual, there'll probably be some build failures as things settle down | 14:44 |
| cjwatson | I need people not to be panicking about that | 14:44 |
| asac | cjwatson: i anticipated that we experiment how things go... probably starting with "auto syncs" for a bit and then see | 14:45 |
| cjwatson | It should be fine once the initial batch lands | 14:45 |
| cjwatson | ogra_: You ship libgcc | 14:45 |
| asac | 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 |
| cjwatson | That's about it though | 14:45 |
| ogra_ | cjwatson, yeah | 14:45 |
| cjwatson | asac: Yeah, but builds run against proposed, necessarily | 14:45 |
| asac | cjwatson: so those we will have a chance to take a look at etc. | 14:45 |
| cjwatson | asac: So some builds will normally fail | 14:45 |
| asac | ah ... sure | 14:45 |
| asac | we will see... we should just keep a bit of a forecast so we know whats coming | 14:46 |
| asac | etc. | 14:46 |
| cjwatson | we're doing gcc 4.8, boost 1.54, db 5.3, perl 5.18 in the toolchain bootstrap | 14:47 |
| cjwatson | https://launchpad.net/~ubuntu-toolchain-r/+archive/test/+packages?field.name_filter=&field.status_filter=published&field.series_filter=saucy | 14:47 |
| plars | asac: doanac and I were just discussing... do we need to keep saucy jobs? or just transition completely to trusty for touch? | 14:47 |
| ogra_ | plars, we'll need both as long as we do saucy images | 14:48 |
| ogra_ | to see if they regressed | 14:48 |
| kalikiana | I'm seeing this in an otherwise passing mr: | 14:48 |
| asac | plars: we want to keep saucy jobs i believe | 14:48 |
| asac | plars: whether we daily prodyuce new saucy-proposed images or just on demand is not yet clear, but in general i feel we should make touch_ro --channel saucy-proposed tests | 14:49 |
| kalikiana | /usr/lib/pbuilder/pbuilder-modules: line 424: 17749 Segmentation fault tar -x --use-compress-program "$COMPRESSPROG" -p -f "$BASETGZ" E: failed to extract /var/cache/pbuilder/saucy-armhf.tgz to /var/cache/pbuilder/build//17710 ERROR:pbuilderjenkins:Error during build execution | 14:49 |
| asac | and make touch_mir == touch with devel-propopsed | 14:49 |
| plars | asac, ogra_, doanac: ok, that was my next question, how frequent would they be :) | 14:49 |
| * ogra_ would only do on demand | 14:49 | |
| plars | asac, doanac: in that case, would we be safe to disable what was formerly called "touch_ro" jobs and just focus on the default mir installs? | 14:50 |
| asac | plars: doanac: i was suggesting: rename touch_ro to touch_saucy (--channel saucy-proposed) | 14:51 |
| asac | and rename touch_mir to touch (--channel devel-proposed) | 14:52 |
| doanac | i think touch_saucy is redundant. we already include the series name | 14:52 |
| doanac | but otherwise i agree | 14:52 |
| plars | asac: well, I think we are saying the same thing - it's not so much a rename, because we want the saucy jobs to be running mir (and the trusty ones) right? | 14:52 |
| plars | asac: right now, the touch_ro jobs are really the sf jobs, as they always were until mir came in | 14:52 |
| === alan_g|tea is now known as alan_g | ||
| rsalveti | is someone going to work on supporting mir for nexus 7 or 10? | 14:53 |
| rsalveti | otherwise it'd still be good to let the tests running against SF | 14:53 |
| josepht | we'll need to coordinate variant name changes for the dashboard (i.e. touch_mir -> touch) | 14:53 |
| rsalveti | even if we don't officially support it | 14:53 |
| rsalveti | in theory we need to care about tablets this cycle as well | 14:54 |
| asac | rsalveti: first we have to fix galaxy nexus performance | 14:54 |
| rsalveti | at least more than we did for saucy | 14:54 |
| asac | rsalveti: then i would vouch for tackling n10 or so | 14:54 |
| asac | or both | 14:54 |
| asac | if we still want to do tablets :) | 14:54 |
| asac | (which i am sure we do) | 14:54 |
| asac | rsalveti: but first we need emulator | 14:54 |
| rsalveti | right, so don't disable the smoke tests on SF then | 14:54 |
| asac | nothing will move on new devices before we have that | 14:54 |
| plars | rsalveti: we're not running anything on the tablets right now | 14:55 |
| rsalveti | and I'm sure when people decide to bootstrap touch to new hardwares, they will try SF first | 14:55 |
| plars | rsalveti: but they are available for as soon as people are going to care for those | 14:55 |
| rsalveti | plars: right, but we at least know our stack is supposed to work with SF | 14:55 |
| asac | rsalveti: SF is kind of dead... if community shows up and want to port features that we only have in MIR to it, it might come back as a community thing - but i doubt it actually | 14:56 |
| rsalveti | all I'm saying is that it'd be good to have the results for that, so we know how broken it is | 14:56 |
| rsalveti | asac: I'm not just concerned with that, I mean when our oem decide to bootstrap to a new hardware | 14:56 |
| rsalveti | they will always test with SF first | 14:56 |
| rsalveti | as mir might be completely broken until someone ports to it | 14:56 |
| ogra_ | asac, we need to make sure SF still works as long as we tell the community to do ports | 14:56 |
| rsalveti | not only that, but that's a big +1 to keep it around for a bit more yeah | 14:57 |
| rsalveti | we'll stop supporting it completely soon, but let's not do this now | 14:57 |
| rsalveti | while we have mir only working nicely at one device | 14:57 |
| ogra_ | yes, we should keep SF for at least one more release cycle | 14:58 |
| asac | rsalveti: is MIR really so hard to prot? | 14:58 |
| asac | rsalveti: given that we support android drivers it shouldn't be so hard for OEMs to get that going, no? | 14:58 |
| rsalveti | asac: it's not trivial, no | 14:58 |
| asac | really? | 14:58 |
| ogra_ | asac, for the kind of porters we have it is a hard task ... not everyone is a graphics driver specialist | 14:58 |
| asac | i know that its not easy for porters | 14:59 |
| asac | just asking about real oems | 14:59 |
| rsalveti | yeah, even we can't fix and port to the stuff we support | 14:59 |
| asac | or rather SoC folks | 14:59 |
| asac | or MALI folks from arm... they can surely do that easily if they want, no? | 14:59 |
| * ogra_ doesnt care about SoC folks | 14:59 | |
| rsalveti | probably, but yeah, we only care about oem and community ports at this point | 14:59 |
| * ogra_ does care about such projects like the fairphone | 14:59 | |
| asac | rsalveti: lol... well, our part is a bit harder because its the FIRST and SECOND platform we are dealing with | 14:59 |
| ogra_ | who will give us a big boost with their ports | 14:59 |
| asac | once we have those done well, we are surely far more efficient and the code is far better suitable for enablement | 15:00 |
| ogra_ | ebnthusiats buy these | 15:00 |
| rsalveti | asac: right, that's exactly why we shouldn't disable SF now :-) | 15:00 |
| ogra_ | ++ | 15:00 |
| ogra_ | it is the saem as with the cdimage zips ... | 15:00 |
| rsalveti | and I don't mean fully supporting SF, I just want smoke tests running against it so we know how broken it is | 15:00 |
| rsalveti | and know what to expect | 15:01 |
| ogra_ | we dont really support them but keep them available until ports can do the full thing | 15:01 |
| rsalveti | yeah, and it's also always useful when bootstraping to a new hardware | 15:01 |
| ogra_ | right | 15:01 |
| rsalveti | doing the entire system image as a first try is just too much | 15:01 |
| ogra_ | yep | 15:01 |
| rsalveti | now put system image + mir just to bootstrap it | 15:01 |
| ogra_ | and to limited for actually fixing the initial issues you will hit | 15:01 |
| rsalveti | yeah | 15:02 |
| asac | rsalveti: you mean disable the dashboatrd runs? | 15:02 |
| asac | i am fine with keeping dashboard running with minimal amount of jobs | 15:02 |
| asac | but not everything | 15:02 |
| asac | more like what we hav for _custom | 15:02 |
| asac | http://reports.qa.ubuntu.com/smokeng/saucy/touch_custom/ | 15:02 |
| rsalveti | asac: just for the core stuff | 15:02 |
| asac | right. we can do that i think fora bit if you find it useful | 15:03 |
| asac | have to check if we run out of resources though :) | 15:03 |
| rsalveti | yes, please | 15:03 |
| asac | doanac: plars: so minor change in plan :) | 15:03 |
| asac | doanac: we want to rename touch_ro to touch_sf4p and run the same jobs against the SF variant of devel-proposed there | 15:04 |
| asac | doanac: and create a new touch_saucy instead (with the content from above | 15:04 |
| asac | plars: ^^ | 15:04 |
| asac | rsalveti: ok, so but you own it now perswonally | 15:04 |
| doanac | asac: touch_saucy doesn't make sense. | 15:04 |
| asac | rsalveti: e.g. its your obligationm to ensure taht if there are jobs failing that they are getting brought to our attention | 15:04 |
| josepht | doanac: +1 | 15:04 |
| asac | doanac: it does | 15:05 |
| doanac | why not just "touch" and "touch_sf4p" | 15:05 |
| ogra_ | doanac, because we still want saucy tests too | 15:05 |
| rsalveti | asac: sure | 15:05 |
| doanac | asac: we already include the release name as its own column | 15:05 |
| doanac | you'll be able to differentiate | 15:05 |
| asac | doanac: we have touch (devel-propsed), touch_saucy (saucy-propsed), touch_custom (devel-custom), touch_sf4p (mimimal job for devel-proposed with SF) | 15:05 |
| asac | doanac: well, then tell me how you want to name it :) | 15:05 |
| asac | doanac: its not good to name two with the same name | 15:06 |
| kgunn | didrocks: ping | 15:06 |
| doanac | asac: let me talk with josepht and plars | 15:06 |
| plars | doanac, asac: well, if it's sf then touch_sf would probably be ok | 15:06 |
| asac | rsalveti: at best find someone through G+ or so that wants to own that build and work with CI etc. to escalate, look at test regressions | 15:06 |
| plars | not sure what sf4p even means | 15:06 |
| asac | plars: doanac: see the lisst above | 15:07 |
| asac | plars: please use sf4p (its SF) | 15:07 |
| asac | its a political name :) | 15:07 |
| asac | (for my personal safety) | 15:07 |
| ogra_ | 4p ? | 15:07 |
| asac | for porters | 15:07 |
| ogra_ | ah | 15:07 |
| rsalveti | asac: we're fine to own that for a while | 15:07 |
| asac | rsalveti: priority must stand back behind many things. better really find someone outside mid term | 15:08 |
| asac | for now its probably okaish | 15:08 |
| asac | as long as someone owns it that isnt official :) | 15:08 |
| rsalveti | asac: it's a low priority, don't worry | 15:09 |
| didrocks | kgunn: pong | 15:10 |
| kgunn | didrocks: hey so duflu did some changes to our branches | 15:14 |
| kgunn | didrocks: hopefully under your guidance | 15:14 |
| didrocks | kgunn: yeah, he did ping me this morning | 15:14 |
| kgunn | didrocks: he seemed to move our lp:mir to point to saucy | 15:15 |
| didrocks | kgunn: I told him it's useless as we discussed, but if he wants to have a "saucy" series… | 15:15 |
| kgunn | didrocks: yeah...but we can't find "trunk" | 15:15 |
| didrocks | kgunn: just that we won't SRU the saucy branch | 15:15 |
| didrocks | lp:mir is what we are going to release for T | 15:15 |
| didrocks | it's my only requirement | 15:15 |
| kgunn | didrocks: hmmm....well...that's not what he did | 15:16 |
| didrocks | then, if duflu wants to support something ubuntu doesn't… not my word apparently :) | 15:16 |
| didrocks | kgunn: hum? he told me that the saucy serie was for saucy, that it wasn't lp:mir | 15:16 |
| didrocks | kgunn: lp:mir is https://code.launchpad.net/~mir-team/mir/development-branch? | 15:16 |
| didrocks | that changed | 15:16 |
| didrocks | kgunn: will https://code.launchpad.net/~mir-team/mir/development-branch always have ABI compatilibity or bumped assured? | 15:17 |
| kgunn | didrocks: ok...so you don't carer if its pointing to "trunk" | 15:17 |
| didrocks | kgunn: I just care about lp:mir | 15:17 |
| kgunn | didrocks: yes...he seemed to unilaterally decide to do all this w/o talking to anyone :-\ | 15:17 |
| didrocks | lp:mir should ensure ABI compatilibity (or bump the ABI properly in the packaging) | 15:17 |
| didrocks | should always pass tests | 15:17 |
| didrocks | and be always shippable | 15:17 |
| didrocks | that's the rule for all projects | 15:17 |
| kgunn | didrocks: ack...so right now he's put us at risk | 15:17 |
| didrocks | I expect you are following that too :) | 15:17 |
| didrocks | kgunn: exactly, it's probably already built in the ppa as well | 15:18 |
| kgunn | didrocks: of course... | 15:18 |
| didrocks | kgunn: can you undo that then? | 15:18 |
| kgunn | didrocks: damn it...i'll work with the guys to correct....is there anything you can do on your side to stem the flow from development branch | 15:18 |
| didrocks | kgunn: well, the ppa won't be of use before Monday, so it's fine, if you fix it today, the new rebuild should be good | 15:19 |
| kgunn | didrocks: ack... | 15:20 |
| * kgunn screams inside | 15:20 | |
| didrocks | kgunn: everything will be fine, no harm done yet ;) | 15:22 |
| didrocks | ok, time for exercise and week-end then! | 15:37 |
| * didrocks waves good evening :) | 15:37 | |
| seb128 | didrocks, have a good w.e | 15:38 |
| didrocks | thanks, you too seb128, have fun in Canada! | 15:39 |
| seb128 | didrocks, thanks | 15:39 |
| ogra_ | blame it ! | 15:39 |
| ogra_ | :) | 15:39 |
| kalikiana | jdstrand: ping, do I ask you about permissions of /sys/class/timed_output/vibrator/enable on the device? | 15:43 |
| kalikiana | seems like it changed from allowed to root-only at some point which basically breaks my code | 15:44 |
| === gatox is now known as gatox_lunch | ||
| === seb128_ is now known as seb128 | ||
| cjwatson | I broke trusty with a typo when copying the toolchain in. wgrant, infinity, and I are working on cleaning up; unfortunately I have to go | 16:30 |
| cjwatson | So I can't promise when you get to build post-toolchain images | 16:31 |
| cjwatson | Hopefully today if you have time and if livefs chroots have been created | 16:31 |
| === gatox_lunch is now known as gatox | ||
| jdstrand | kalikiana: we've never allowed that permissions, but certainly can. can you file a bug against apparmor-easyprof-ubuntu and mention if this should be allowed for all apps or if not, what types of apps? | 17:07 |
| kalikiana | okay, will do. | 17:09 |
| kalikiana | jdstrand: https://bugs.launchpad.net/ubuntu/+source/apparmor-easyprof-ubuntu/+bug/1241735 | 17:29 |
| ubot5 | Ubuntu bug 1241735 in apparmor-easyprof-ubuntu (Ubuntu) "Allow apps access to /sys/class/timed_output/vibrator/enable" [Undecided,New] | 17:29 |
| jdstrand | kalikiana: thanks | 17:37 |
| ogra_ | asac, FYI i just did an image testbuild for tasty, it wont build unless we rebuild android (since the android package uses the release name inside the img filenames) so plain toolchain build wont be possibile | 20:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!