| fginther | plars, essentially, it was the desire to test a touch + mir enabled image in parallel with the regular images | 14:30 |
|---|---|---|
| fginther | mir requiring a small bit of extra work to turn on | 14:30 |
| plars | fginther: sure, we can turn on mir by just touching a file right? | 14:31 |
| fginther | Right. | 14:31 |
| fginther | I was assuming this is dependent upon the work to restructure the touch slaves | 14:31 |
| plars | fginther: it's a complete extra test run though, it's something we could look at, but we should talk about how to differentiate the results in the dashboard and all that | 14:32 |
| plars | fginther: yes, it's partly dependent on that, but could be done before | 14:32 |
| fginther | plars, that sounds very cool. | 14:33 |
| cjohnston | bug #12345 | 14:33 |
| ubot5 | bug 12345 in isdnutils (Ubuntu) "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] https://launchpad.net/bugs/12345 | 14:33 |
| cjohnston | sweet | 14:33 |
| plars | fginther: another possibility is that if we have some specific tests we'd like to target at running under mir, we could set it up as part of the regular test run | 14:33 |
| fginther | plars, didrocks also mentioned a ppa for testing with mir, but I didn't fully understand how that fit in | 14:33 |
| plars | fginther: that's a whole different issue | 14:34 |
| didrocks | fginther: plars: I'm writing an email | 14:34 |
| plars | fginther: one thing at a time :) | 14:34 |
| fginther | didrocks, thx | 14:34 |
| plars | fginther: if we have a specific test to run with mir, we could add setup/teardown for that test to enable mir, reboot, run the test | 14:34 |
| didrocks | done | 14:35 |
| fginther | plars, that would be interesting, perhaps running the unity8 suite under mir would be just as helpful as a full image test | 14:35 |
| plars | fginther, didrocks: doing it like that would be much better I think, because we wouldn't have to repeat a lot of the things that are not relevant to mir (install, default smoke, etc) | 14:35 |
| didrocks | plars: so, you handle that, adding the ppa and so on? | 14:36 |
| plars | didrocks: let me go read the mail, typically no | 14:36 |
| didrocks | as mir doesn't have specific tests, I think you will add unity8 and all apps tests | 14:36 |
| didrocks | plars: so, does the email makes sense? any way we can run that automatically? | 14:40 |
| plars | didrocks: sorta, I responded. For the image testing though, the input is exactly what you would expect: an image | 14:41 |
| plars | didrocks: I've set up a temporary one-off for some qt stuff recently, I could do the same but it's not a long term fix | 14:42 |
| plars | didrocks: ideally this shouldn't be running long-term though right? | 14:42 |
| didrocks | plars: ok, answered ;) | 14:42 |
| didrocks | let's do that | 14:42 |
| plars | didrocks: so you will get us an image with this? | 14:42 |
| didrocks | plars: hum? no, we need latest image + a ppa | 14:43 |
| didrocks | is this possible? | 14:43 |
| plars | <plars> didrocks: sorta, I responded. For the image testing though, the input is exactly what you would expect: an image | 14:43 |
| plars | <plars> didrocks: I've set up a temporary one-off for some qt stuff recently, I could do the same but it's not a long term fix | 14:43 |
| kgunn | fginther: ping | 14:43 |
| didrocks | and we can't add ppas to anything in UTAH? | 14:43 |
| didrocks | plars: ^ | 14:43 |
| plars | didrocks: we could, but we've actually been actively moving away from depending on any kind of ppa as that's where the images are going | 14:44 |
| didrocks | plars: right, but this kind is tested in isolation | 14:44 |
| didrocks | code* | 14:44 |
| didrocks | the goal for it is to not land for the coming week in distro | 14:44 |
| didrocks | but we need test | 14:44 |
| plars | didrocks: sorry, just trying to figure out where this fits best. It seems like it's sort of like autolanding testing, except you don't want to autoland it, right? | 14:45 |
| plars | but it's not really image testing either | 14:46 |
| didrocks | plars: right, it's while Mir is in its own silo | 14:46 |
| plars | fginther, didrocks: I think we need to discuss further where we can fit stuff like this into the ci - I don't think it's a perfect fit anywhere at the moment, and typically things like this have been hand tested in the past by the dev teams I think (by doing what you suggest, pulling the ppa into a latest image and running tests on it) | 14:47 |
| plars | it could probably be shoved in to a number of places, but it sounds like something we might need again | 14:47 |
| didrocks | plars: we need the support for dailies on the phone | 14:47 |
| didrocks | what jibel did at 95% | 14:48 |
| plars | didrocks: not sure what you mean | 14:48 |
| didrocks | but asac is telling me there is nobody at the moment to finish this support | 14:48 |
| asac | didrocks: fginther can look at it i assume | 14:48 |
| didrocks | plars: if the dailies support testing phone, we would be done (it's basically the same contect) | 14:48 |
| didrocks | context* | 14:48 |
| asac | after we got the MP straight | 14:48 |
| didrocks | asac: Mir needs 5 components to be built to test | 14:48 |
| asac | also we said that jibel would still support us | 14:48 |
| didrocks | asac: as they change ABI | 14:48 |
| asac | and we said we might be able to dodge it | 14:48 |
| asac | if we cant | 14:49 |
| asac | we have to go back | 14:49 |
| didrocks | asac: so you can't do that at the MP level without having the notion of "you need this, this and this" | 14:49 |
| didrocks | and for this week, what sergio needs, is testing | 14:49 |
| asac | didrocks: right. thought we asked them to change ABI/API decently | 14:49 |
| didrocks | asac: they still plan to do it everyday | 14:49 |
| didrocks | (and now, the devs tries to push back if you follow #ubuntu-mir btw) | 14:49 |
| didrocks | so short term solution, I would say, let's do manual testing if we can't get anything else | 14:50 |
| didrocks | pulling the iso | 14:50 |
| didrocks | installing the ppa (once Mir builds…) | 14:50 |
| didrocks | and running unity8 + apps tests | 14:51 |
| didrocks | fginther: plars: makes sense? ^ | 14:51 |
| asac | probably | 14:52 |
| asac | didrocks: check with fginther what it takes to bring his way of doing things into daily-release testing | 14:52 |
| fginther | didrocks, plars, if it's just a matter of we need an image first, we can build an image on jenkins and feed that into smoke | 14:52 |
| asac | didrocks: feels like its just changing the ppa to use for testing | 14:52 |
| asac | instead of merge ppa, test with the release ppa | 14:53 |
| asac | fginther: right. so what we want is to be able to produce an image from daily-release ppa | 14:53 |
| didrocks | asac: but the Mir MP will fail | 14:53 |
| didrocks | because it's changing the lib | 14:53 |
| asac | fginther: that either includes all or just a subset | 14:53 |
| didrocks | so, you don't have the unity-mir, u-s-c and platform-api you need to test with | 14:53 |
| didrocks | (yet) | 14:53 |
| asac | didrocks: sorry. i phrased correctly. was saying that if we need testing at daily-release level so badly | 14:54 |
| asac | we can see if our MP solution for phone provisioning could work there | 14:54 |
| asac | didrocks: i understand that part | 14:54 |
| asac | but guess we have to reside on manual testing | 14:54 |
| asac | though if we have a way to send a job to the lab saying: take image x), add ppa A and install packages C,D,E | 14:55 |
| asac | we could use that rather than manual | 14:55 |
| fginther | asac, if that's what we need, than we should just build the image that contains all of that | 14:56 |
| plars | asac: this is sort of what I suggested earlier when I thought it was just a matter of enabling mir. What is actually wanted is to run pretty much all the tests though, so it's a complete extra test run | 14:56 |
| plars | right | 14:56 |
| plars | so that's when it became apparent that it should probably just be a whole image set up the way it's needed (mir enabled, packages installed, deps in place) | 14:56 |
| plars | it's still a new test run, but unless what's wanted is a continuous run of this (unlikely?) It's a one-off sort of like what we did for qt51 | 14:57 |
| fginther | plars, asac, I can queue up a job to create this image. just want to make sure this works for everybody and what the schedule should be | 14:58 |
| plars | that would be in the case of "this is a quick test to make sure nothing breaks before we merge and land this" | 14:58 |
| asac | fginther: we need to select parts | 14:58 |
| didrocks | asac: yeah, otto provides that on the desktop for a long time | 14:58 |
| didrocks | asac: and the phone prototype that jibel has does as well | 14:58 |
| didrocks | it's juts a question of finishing up | 14:58 |
| plars | if this is way out still, then manual testing probably makes more sense until it's almost ready | 14:58 |
| asac | didrocks: jibel says its not htere | 14:58 |
| asac | jibel: ^^ | 14:58 |
| asac | jibel: so seems we wont be able to dodge getting your stuff in | 14:58 |
| asac | i hoped i could | 14:58 |
| fginther | kgunn, pong | 14:59 |
| didrocks | asac: weird, it was almost there before my holidays AFAIK | 14:59 |
| didrocks | but I'm unsure about the ro image though, maybe his work was pre-ro image | 14:59 |
| asac | didrocks: otto is lxc based etc. | 15:00 |
| asac | that seems to be not cleared on kernel side etc. | 15:00 |
| fginther | I'm not saying we abondond jibel's work, but I would prefer a solution that fits in with the existing infrastructure | 15:00 |
| asac | so its a dead end potentially... | 15:00 |
| didrocks | asac: no for the phone one | 15:00 |
| fginther | for the next 4 weeks | 15:00 |
| didrocks | AFAIK | 15:00 |
| asac | jibel: can you tell us what your stuff is? | 15:00 |
| didrocks | it's using the same code, but the lxc part | 15:01 |
| asac | jibel: and how far we are? | 15:01 |
| asac | ok | 15:01 |
| asac | so lets have a call on that one i guess | 15:01 |
| asac | didrocks: lets talk about todays landing first :) | 15:01 |
| asac | where do we stand with those? | 15:01 |
| asac | once we have those pushed we can talk about phone testing | 15:02 |
| didrocks | asac: remember I told I needed to go at 5PM? | 15:02 |
| didrocks | I can go back afterward | 15:02 |
| didrocks | but I have an appointment for the wedding | 15:02 |
| didrocks | I'm already late | 15:02 |
| didrocks | and stuck in discussion with the Mir guys | 15:02 |
| asac | didrocks: we can do that call tomorrow | 15:02 |
| asac | didrocks: just wanted to check where we stand with what sil2100 wanted to land etc. | 15:02 |
| didrocks | apparently, the devs don't want to do library proper development | 15:02 |
| asac | i can deal with him alone :) | 15:02 |
| asac | didrocks: yeah. however, thats for the special mir PPA | 15:02 |
| asac | so we can dodge that discussion for 2 more days | 15:03 |
| asac | :) | 15:03 |
| asac | didrocks: so go to a wedding | 15:03 |
| didrocks | asac: well, 2 more days :p | 15:03 |
| didrocks | I don't go to a wedding, I go to prepare my wedding :p | 15:03 |
| asac | right. hence, lets first sort the other landings | 15:03 |
| asac | ah | 15:03 |
| asac | and then talk about that lib thing | 15:03 |
| asac | sil2100: so ... where do we stand :) | 15:03 |
| asac | sil2100: can you try what we planned to get in? | 15:04 |
| asac | i assume stuff has built by now? | 15:04 |
| didrocks | asac: most of the thing built, see the link I pasted to you an hour ago | 15:04 |
| * didrocks goes now | 15:05 | |
| asac | sil2100: so content hub stuff is inproposed? | 15:06 |
| asac | nice | 15:06 |
| asac | sil2100: i think we wanted to try scopes and application #2 as well for today | 15:07 |
| asac | sil2100: i think plars and psivaa are happy to help testing if you explain how to do that | 15:07 |
| asac | Mirv: ^ | 15:07 |
| sil2100 | asac: ACK | 15:12 |
| sil2100 | asac: I'm testing those on the phone now | 15:12 |
| cwayne1 | asac: hi, just wondering if there was any update on lightdm? | 15:27 |
| jibel | asac, my stuff uses the same runner than we use on desktop, with the major difference that we cannot use overlays fs on phone and the device is reprovisioned between each run (takes between 6min on N4 and N10 to 9min on NG) instead of just dropping the overlay | 15:30 |
| asac | sil2100: are the content-hub things out of proposed now? | 15:30 |
| asac | jibel: where does it stand? how can we hook what you have up to the system? | 15:31 |
| jibel | asac, it requires full RW access to the FS which I think can be done by remounting / RW upon provisioning | 15:31 |
| asac | right | 15:31 |
| asac | thats a workaround for now | 15:31 |
| asac | ChickenCutlass: so let me know what you want to land | 15:32 |
| asac | before multimedia | 15:32 |
| ChickenCutlass | asac, ok, yes we will | 15:32 |
| sil2100 | asac: yes, it's all in archive | 15:33 |
| jibel | asac, the nodes are labeled by the name of the devices so we should be able to plug then to the daily-release machinery by /just/ adding the labels to the list of executors on the saucy_daily-release job | 15:33 |
| jibel | asac, that part is untested | 15:34 |
| cwayne1 | asac: any update on lightdm | 15:34 |
| asac | cwayne1: so that one is discussed in management | 15:34 |
| kgunn | fginther: sorry...i walked away | 15:34 |
| asac | cwayne1: do we need it or not ... given the locales are connected we want it i think | 15:34 |
| kgunn | fginther: we were wondering... | 15:34 |
| cwayne1 | asac: from a customization point of view we need it | 15:35 |
| kgunn | we basically want to bump the mir server so on every mp | 15:35 |
| asac | cwayne1: just need to be tested | 15:35 |
| asac | cwayne1: that involves running all autopilots | 15:35 |
| asac | and also ensuring it doesnt break utah | 15:35 |
| kgunn | we were wondering if we could modify the jenkins bot to do this | 15:35 |
| kgunn | as part of the merges done for mir ? | 15:35 |
| ricmm | kgunn: bump ABI in *each* commit ? | 15:35 |
| kgunn | ricmm: yep | 15:36 |
| cwayne1 | asac: ok, that sounds reasonable | 15:36 |
| asac | cwayne1: ok... thats ubuntu-touch-session? | 15:36 |
| asac | that feels like work we cant do short term | 15:36 |
| asac | cwayne1: so you can help us by supporting us in that effort | 15:36 |
| fginther | kgunn, probably, we just need to modify the value in the packaging before building? | 15:36 |
| asac | cwayne1: otherwise it will wait until we have cleared the stuff we need to land before beta freeze | 15:36 |
| cwayne1 | asac: how can i help support it? | 15:37 |
| asac | cwayne1: ubuntu-touch-session is not in CI? | 15:37 |
| cwayne1 | asac: ? | 15:37 |
| fginther | kgunn, but you also want this change to make it into trunk, correct? | 15:37 |
| kgunn | fginther: yes...it would be bumping on our mir trunk | 15:38 |
| asac | cwayne1: so ... the landing ask ask for an update to ubuntu-touch-session | 15:38 |
| asac | which probably will bring it into the image | 15:38 |
| asac | cwayne1: what we want is to have that change, and have someone test it on phones and run all autopilots | 15:38 |
| asac | if you have a good log of those succeeding you can just upload them after checking here | 15:38 |
| kgunn | fginther: could we do it as early as today? | 15:38 |
| fginther | kgunn, that's a little more work, but also doable. | 15:38 |
| fginther | kgunn, I think so | 15:39 |
| asac | kgunn: sounds not like short term | 15:39 |
| kgunn | fginther: you would be a life saver | 15:39 |
| asac | certainly doable though | 15:39 |
| fginther | kgunn, do you happen to have a script for automating the bump? | 15:39 |
| cwayne1 | asac: im happy to test it on the phone | 15:39 |
| kgunn | fginther: we can make one | 15:39 |
| asac | cwayne1: when are you awake? | 15:39 |
| kgunn | so says robert_ancell | 15:39 |
| asac | sil2100: are the app tests going well? | 15:39 |
| fginther | kgunn, thanks, I'll start getting the other bits lined up | 15:39 |
| cwayne1 | asac: EST | 15:39 |
| kgunn | fginther: awesome! | 15:39 |
| robert_ancell | fginther, I'll write one now | 15:39 |
| * kgunn 's "i owe you a beer" ledger grows longer | 15:40 | |
| sil2100 | asac: problematic, I might have found an issue | 15:46 |
| asac | sil2100: oki... | 15:47 |
| asac | lets not rush | 15:47 |
| asac | sil2100: if its hard to figure, lets try scopes instead i guess | 15:47 |
| asac | sil2100: mayube explain plars and sivaa how to test these | 15:48 |
| fginther | sil2100, is this the same problem you've been seeing on daily release (Unauthorized when talking to launchpad)? http://10.97.2.10:8080/job/autopilot-gtk-saucy-armhf-ci/25/console | 15:54 |
| fginther | sil2100, it's intetmittent | 15:54 |
| sil2100 | fginther: no, we had could not resolve host etc. issues on daily-release mostly | 15:55 |
| asac | anyone knows if we still see DNS issues? | 16:10 |
| asac | or are those gone? | 16:10 |
| sil2100 | asac: yesterday I saw some on intel sadly - today I didn't, but maybe didrocks saw? | 16:13 |
| robert_ancell | fginther, http://paste.ubuntu.com/6120034/ | 16:13 |
| sil2100 | asac: the apps issues are resolved, I'm preparing for release \o/ | 16:14 |
| asac | sil2100: nice... you think you can try the scopes as well? | 16:14 |
| asac | but guess that requires lots of testing :) | 16:14 |
| asac | sil2100: mayve you can explain to plars and psivaa how they can find which packages to try? | 16:14 |
| asac | they can certainly tests in parallel then | 16:14 |
| asac | sil2100: but dont hold back pushing the apps :) | 16:15 |
| fginther | robert_ancell, thanks | 16:16 |
| asac | sil2100: did you try to take all aopps | 16:17 |
| asac | or just the two we marked? | 16:17 |
| asac | dont care either | 16:17 |
| asac | just wondering if we might even get more than i hoped for :) | 16:17 |
| sil2100 | asac: I was testing history-service, dialer-app and messaging-app basically, and also re-testing ubuntu-keyboard in the meantime | 16:18 |
| mandel | asac, ping | 16:19 |
| asac | mandel: hi | 16:19 |
| asac | sil2100: kk | 16:20 |
| mandel | asac, hello! I was told that I should ping you (or didrock) if I needed to land bug fixes for the phone image (ubuntu-download-manager package), is that correct? | 16:20 |
| asac | mandel: who is your techlead/manager? | 16:20 |
| mandel | asac, _ralsina | 16:21 |
| mandel | asac, and _alecu | 16:21 |
| asac | mandel: ok... you can ask him to add your landing to the spreadsheet and we will process it asap | 16:21 |
| asac | mandel: just ensure its cleawr that its a bugfix only release | 16:21 |
| mandel | asac, ok, will do | 16:21 |
| mandel | asac, yes, no new features, just bugs | 16:22 |
| asac | mandel: how big is the diff? | 16:22 |
| mandel | asac, hm.. there are several mp but not less than 2000 | 16:22 |
| mandel | asac, I can have a small diff per bug | 16:22 |
| mandel | rather than a crazy diff | 16:22 |
| asac | mandel: think is not needed | 16:24 |
| asac | mandel: just add it to the landing list | 16:24 |
| mandel | ok | 16:24 |
| asac | mandel: once we get closer you might want to offer support to test autopilots locally to give up front confirm that stuff is good | 16:25 |
| mandel | asac, hmmm autopilot tests with the downloader are going to be interesting.. since is a daemon | 16:26 |
| asac | mandel: its not about your tests | 16:26 |
| asac | mandel: its about confirming that your cdhanges dont break tests of other apps | 16:26 |
| asac | etc. | 16:26 |
| mandel | ah, ok | 16:27 |
| asac | e.g. install your stuff, run a few autopilots for apps and unity | 16:27 |
| asac | if thats confirmed, we can fastpath it more easily | 16:27 |
| asac | sil2100: hey ... so folks say we should at least file a bug with the log and add it as a comment in case something odesnt make it | 16:43 |
| asac | guess makes sense | 16:43 |
| asac | not sure how to do that | 16:43 |
| asac | fginther: so what came out of the discussion on how we could easily test custom images with ppas and package list added? | 16:43 |
| asac | on demand? | 16:44 |
| asac | fginther: was the outcome that we should just finish jibel's stuff? | 16:44 |
| fginther | asac, the solution to me is to just build the image somewhere else first | 16:44 |
| fginther | no one replied to my suggestion yet | 16:45 |
| asac | fginther: hmm. what does that mean "build the image somewhere else first"? | 16:45 |
| asac | fginther: not as part of jenkins? | 16:46 |
| fginther | build the image as part of a separate jenkins job, not while trying to do the actual smoke test setup | 16:46 |
| fginther | a job that does nothing more than produce an image | 16:46 |
| asac | feels reasonable | 16:47 |
| asac | fginther: so we use that for both: MPs and daily-release? or are you talking daily-release stage only for now? | 16:47 |
| fginther | asac, I'm talking about smoke test | 16:47 |
| asac | fginther: but smoke test we have phone testing right now | 16:48 |
| fginther | the topic was triggered by wanting to test smoke with mir enabled | 16:48 |
| asac | smoek test == daily image testing on reports.qa.ubuntu.com | 16:48 |
| asac | fginther: hmm. ok then i think the topic was mixed up\ | 16:48 |
| fginther | indeed | 16:48 |
| asac | what i am talking about is to have something to test our daily-release ppa content | 16:48 |
| asac | before we publish it | 16:48 |
| asac | a) all that is in there | 16:48 |
| asac | b) just a subset of changes added against the last image | 16:48 |
| asac | right now sil, mirv and didrocks arrange that manual | 16:49 |
| fginther | right | 16:49 |
| asac | so i wondered if an dhow we can reuse either what utah does in image testing or what you did in MP | 16:49 |
| asac | sil2100: am i right that if i take last green image and dist-upgrade to the daily-release ppa | 16:50 |
| asac | i get everything currently staged? | 16:50 |
| fginther | asac, I think we can engineer a solution close to what we're doing in upstream merger. But honostly I haven't had time to look at jibel's stuff yet to see if that would be easier. | 16:52 |
| asac | yeah | 16:52 |
| asac | guess cant be created in a day anyway | 16:52 |
| asac | really think we want a microservice | 16:52 |
| asac | that takes and image +ppa + a set of packages to install from that | 16:53 |
| asac | and flashes, boots, etc. | 16:53 |
| asac | :) | 16:53 |
| asac | and reuse that everywhgere | 16:53 |
| fginther | that's pretty close to what we're already doing, we're just missing the ppa bit and that really isn't hard to add. | 16:53 |
| fginther | it's a bit of a hack | 16:54 |
| fginther | I'll talk to sil2100 and didrocks to make sure I'm not overlooking something | 16:54 |
| * fginther back in a bit | 16:54 | |
| lool | asac: here | 17:02 |
| asac | lool: hi :) | 17:02 |
| asac | yeah | 17:02 |
| asac | sil2100: so... lool and me had the idea if we could try "EVERYTHING" that is currently built in https://launchpad.net/~ubuntu-unity/+archive/daily-build/+packages | 17:02 |
| lool | asac: so perhaps we could start with listing all the changelogs + diffs of things in daily-build against saucy | 17:03 |
| asac | and see how autopilot acts up | 17:03 |
| asac | lool: yeah. if we had that we would clearly see more :) | 17:03 |
| lool | asac: so you're saying it's too costly for the time we have to spin up a side image that would have the PPA bits included | 17:03 |
| asac | lool: it would only help us if we could do one off image spins that only include parts of it | 17:04 |
| lool | I think we could | 17:04 |
| asac | lool: and at best be able to send that to our phones in the lab... | 17:04 |
| asac | but that part we can do with fginther i feel | 17:04 |
| lool | we could also build the image by hand until we find it's good enough, then let things through and build it | 17:04 |
| asac | lool: fginther basically said that his problem is getting the image to test | 17:04 |
| sil2100 | asac: please wait with that | 17:04 |
| asac | rather than running the test | 17:04 |
| lool | but that requires costly build image + upload image cycles | 17:04 |
| asac | sil2100: wait :) | 17:05 |
| sil2100 | asac: we have an unwanted package in daily-build... | 17:05 |
| asac | sil2100: we discuss the plan | 17:05 |
| asac | so you are welcome to contribute :) | 17:05 |
| asac | sil2100: so if we had something to produce images nicely with a subset of stuff in there | 17:05 |
| asac | we could send that to our phones | 17:06 |
| asac | right? | 17:06 |
| asac | and we could at least stop manually running the tests | 17:06 |
| asac | but rather using our infrastructure to test | 17:06 |
| asac | sil2100: oh wait ... just ONE unwanted package? | 17:06 |
| asac | lool: so i think we can also make a job that does something like fginther does in MPs | 17:07 |
| lool | what is that? | 17:07 |
| asac | lool: he takes an image that is there, and then dist-upgrades it | 17:07 |
| asac | and after ppa-purges | 17:07 |
| asac | not nice | 17:07 |
| asac | but seems to work | 17:07 |
| asac | 99% of cases | 17:07 |
| asac | lool: only problem when we get to RO | 17:07 |
| lool | well that's fine, we could even publish the modified image | 17:07 |
| asac | right | 17:07 |
| asac | lool: anyway. i think thats all not good to do if we dont have everyone here :) | 17:08 |
| asac | certainly nothing to start today | 17:08 |
| lool | ok | 17:08 |
| asac | for today what would help is getting a view | 17:08 |
| asac | of what is in thtere | 17:08 |
| lool | I can start the script thing | 17:08 |
| asac | that isnt in sauch | 17:08 |
| asac | saucy | 17:08 |
| lool | it's something I can continue tomorrow and can stop anytime | 17:08 |
| asac | then we can look and see what subset we can try to pipeclean | 17:08 |
| asac | lool: i will get you into the standup for tomorrow morning | 17:09 |
| lool | bah, someone removed http://people.linaro.org/~lool/ and I just googled and found a link to a script I had published there, erf | 17:09 |
| lool | now I need to find the original :-) | 17:09 |
| asac | hehe | 17:10 |
| kgunn | fginther: one thing about our mp builds....can someone tell us, which is which ? | 17:13 |
| kgunn | alan_g & I noticed there seems to be an android & armhf build | 17:13 |
| kgunn | what's the diff ? | 17:13 |
| kgunn | also alan_g thinks there's a setup prob with the armhf one | 17:13 |
| alan_g | fginther: kgunn this looks like a config issue? https://jenkins.qa.ubuntu.com/job/mir-saucy-armhf-ci/7/console | 17:14 |
| asac | sil2100: what was the bad package you talked about? | 17:25 |
| asac | ogra_: did the 53 image come out yet? | 17:25 |
| ogra_ | yep | 17:25 |
| asac | ogra_: not yet in qa it seems... guess not long ago | 17:26 |
| ogra_ | https://system-image.ubuntu.com/saucy-proposed/ ... | 17:26 |
| ogra_ | 16:48 UTC | 17:26 |
| asac | ogra_: hmm. adb shell makes me shell@... | 17:26 |
| asac | think i am in the android container | 17:26 |
| ogra_ | sounds like | 17:26 |
| asac | ogra_: just try rebooting? | 17:27 |
| asac | unity is running | 17:27 |
| ogra_ | whats after the @ ? | 17:27 |
| asac | and stuff | 17:27 |
| asac | shell@android:/ | 17:27 |
| ogra_ | yeah, thats the container | 17:27 |
| asac | is it sometimes that might go away on reboot? | 17:27 |
| ogra_ | should be disabled by default | 17:27 |
| ogra_ | try it | 17:27 |
| asac | our whole UI is surely working | 17:27 |
| asac | ok just reboot? | 17:27 |
| ogra_ | might be that some test you ran left the property enabled or so | 17:27 |
| ogra_ | yeah, just reboot and see | 17:28 |
| asac | ogra_: oh... yeah i had some complains | 17:28 |
| asac | something about adb props ... ro | 17:28 |
| ogra_ | yeah | 17:28 |
| asac | ok i am root@ again | 17:28 |
| asac | guess was a one time thingy | 17:28 |
| sil2100 | asac: xpathselect - the new version of that package landed in daily-build, breaking unity stacks | 17:30 |
| asac | sil2100: where did that come in through? | 17:33 |
| asac | sil2100: do we have CI for that? | 17:33 |
| asac | sil2100: also ... arent unity stacks diverted to the experimental ppa right now? | 17:33 |
| asac | sil2100: anyway, did you kill it? i am dist-upgrading righ tnow | 17:34 |
| asac | and i dont see it coming :) | 17:34 |
| * asac is brave and upgrades the whole lot :) | 17:34 | |
| sil2100 | asac: it got in by accident, we had a bug in the config - the config wasn't redeployed because of a typo etc. | 17:35 |
| sil2100 | asac: I removed it from the PPA and fixed daily-build | 17:35 |
| sil2100 | asac: I'm re-spinning unity now | 17:35 |
| kgunn | sil2100: ^ is that related to my query on experimental ?> | 17:37 |
| asac | sil2100: ok so i distupgraded everything. .. we have right now, i assume thats broken then? | 17:37 |
| sil2100 | kgunn: I don't think so... but I would have to double-check | 17:38 |
| asac | unity at least still boots with all :) | 17:39 |
| sil2100 | asac: not sure if it's broken, since it only causes a FTBFS for unity7 - but it still has xpathselect with features that are not supposed to be in saucy | 17:39 |
| asac | kk | 17:39 |
| asac | sil2100: let me do a start on some tests | 17:40 |
| asac | to see | 17:40 |
| plars | asac: all the latest touch_ro images just failed to install properly in the lab, I'm investigating locally but I can't see those devices any more | 17:53 |
| plars | asac: I pinged rfowler, but I don't want to kick it off on another device since it's likely to kill those also | 17:53 |
| plars | s/another device/another device in the lab/ | 17:53 |
| asac | plars: right | 17:53 |
| asac | thats awful | 17:53 |
| plars | local is fine to break, I'll fix that | 17:54 |
| asac | plars: do we have any log? | 17:54 |
| plars | jenkins.qa.ubuntu.com/job/saucy-touch_ro-maguro-smoke-install-and-boot/148/consoleFull | 17:54 |
| plars | err | 17:54 |
| plars | http://jenkins.qa.ubuntu.com/job/saucy-touch_ro-maguro-smoke-install-and-boot/148/consoleFull | 17:54 |
| plars | asac: not much of use though, it seems to have just timed out | 17:55 |
| asac | plars: so did we manage to get a new phablet-flash? | 17:55 |
| asac | or do we still run a hacked version? i am sure its related? | 17:55 |
| plars | asac: no, it's an official version that we have running on there now | 17:56 |
| plars | asac: it ran fine for a couple of runs after installing it | 17:56 |
| plars | asac: this is new with the current build | 17:56 |
| plars | asac: anyone who tries to run a phablet-flash on touch_ro *needs* the new version, or else it will not work | 17:57 |
| asac | ogra_: ^^ | 17:58 |
| asac | maybe the build is busted? | 17:58 |
| ogra_ | no, i just flashed it fine here | 17:59 |
| ogra_ | ogra@chromebook:~$ adb shell system-image-cli -i|grep version | 17:59 |
| ogra_ | version version: 53 | 17:59 |
| ogra_ | version ubuntu: 20130917 | 17:59 |
| ogra_ | version device: 20130917 | 17:59 |
| ubot5 | Error: Ubuntu bug 20130917 could not be found | 17:59 |
| ogra_ | using: sudo phablet-flash ubuntu-system --channel=saucy-proposed --no-backup -d maguro | 17:59 |
| ogra_ | but yeah i always update phablet-flash before using it | 17:59 |
| ogra_ | that should be a general rune of common sense for everyone anyway though | 18:00 |
| ogra_ | *rule | 18:00 |
| sil2100 | asac: running tests for the new scopes | 18:01 |
| * asac hopes that bogus devices in the lab doesnt become a daily phenomenon :) | 18:02 | |
| plars | rfowler: strange, this is working for me locally | 18:05 |
| ogra_ | do we dump the package version of phablet-tools into the log somewhere ? | 18:06 |
| ogra_ | if not, we should :) | 18:06 |
| plars | Installed: 1.0+13.10.20130916-0ubuntu1 | 18:08 |
| sil2100 | asac: unity8 tests with the new scope version and libunity looks ok, passes tests | 18:08 |
| plars | Candidate: 1.0+13.10.20130916.2-0ubuntu1 | 18:08 |
| sil2100 | asac: with new unity-scope-home | 18:08 |
| plars | so there was a newer one even since the one sergio did yesterday? | 18:08 |
| * plars wonders what changed | 18:08 | |
| asac | ogra_: plars: so maybe mtp busted our automation | 18:10 |
| asac | i just saw a nice mount thing coming up | 18:11 |
| asac | and then the device was not adb'able | 18:11 |
| asac | ogra_: plars: can you log into the machine and see if you can umount whatever it mounted? | 18:11 |
| asac | maybe that helps | 18:11 |
| plars | asac: log into what machine? | 18:12 |
| ogra_ | asac, my devices are all adbable all the time | 18:12 |
| plars | asac: oh, the host? | 18:12 |
| ogra_ | no matter if the mtp mount is up or not | 18:12 |
| asac | plars: the host | 18:12 |
| asac | plars: see if something got mtp mounted etc. | 18:12 |
| ogra_ | its a server, very unlikely it even has libmtp | 18:13 |
| plars | asac: I don't see anything | 18:13 |
| plars | asac: where did you see the mount message? | 18:13 |
| asac | plars: on the desktop :) | 18:14 |
| asac | screen | 18:14 |
| asac | ogra_: so maybe false alert :) | 18:14 |
| ogra_ | yeah, would surprise me if that influenced adb much | 18:15 |
| ogra_ | it might delay adb in coming up perhaps ... | 18:15 |
| asac | so sigh :) | 18:16 |
| ogra_ | if timing is critically narrow for these jobs that *could* have some impact ... though i dont think thats very likely | 18:16 |
| asac | phones dead ... noone knows | 18:16 |
| ogra_ | do we have feedback whats on the screen ? | 18:16 |
| asac | plars: do we not even see the commands we ran for flashing? | 18:16 |
| asac | in some log? | 18:16 |
| ogra_ | do they sit in recovery ... fastboot ? | 18:16 |
| ogra_ | google logo ... etc | 18:17 |
| sil2100 | asac: ok, so after testing the libunity and unity-scope-home versions that are requested for release by "scopes #1" it seems to look ok from the touch point of view - but we still need to make sure it doesn't cause a regression in unity7 (which is still building now) | 18:17 |
| asac | ogra_: you can try to use the in-lab camera :) | 18:17 |
| plars | asac: not directly, but it's not hard to get at, and not anything too strange. It's doing just flashing the daily-proposed image for touch_ro | 18:17 |
| asac | pretty nice | 18:17 |
| plars | asac: I ran the same command locally that gets run from jenkins and it worked here | 18:17 |
| asac | plars: but both mako and maguro failed at same time? | 18:18 |
| asac | that sounds odd | 18:18 |
| rfowler | plars: looks like you are talking in here... | 18:18 |
| ogra_ | heh, we'r etalking split across both channels | 18:19 |
| plars | yeah | 18:19 |
| plars | let's just talk in #ubuntu-touch | 18:19 |
| plars | more people are in that channel that would care | 18:19 |
| ogra_ | yeah | 18:19 |
| plars | rfowler, asac: ^ | 18:19 |
| asac | ok | 18:20 |
| asac | fine | 18:20 |
| asac | rfowler: guess you are far away from those phones :)? | 18:21 |
| asac | i think we would like to extract some logs etc before trying to flash again | 18:21 |
| ogra_ | asac, i have a theory, but need rsalveti to come back from lunch to confirm | 18:27 |
| * rsalveti back | 18:34 | |
| rsalveti | ogra_: what's up? | 18:34 |
| ogra_ | rsalveti, we need to drop the "adbd spawns inside the container" stuff | 18:35 |
| ogra_ | rsalveti, seems all tests fail | 18:35 |
| ogra_ | my theory is: mtp sets the mtp property ... adbd respawns ... utah conncts exactly now and ends up inside the container | 18:36 |
| ogra_ | so adbd on ubuntu never comes back since the one in the container is used | 18:36 |
| rsalveti | oh, right, let me think | 18:36 |
| rsalveti | so it's a consequence of mtp | 18:36 |
| ogra_ | it is fine using it manually since you never connect that fast | 18:36 |
| rsalveti | right | 18:37 |
| ogra_ | so thats why we never spotted it | 18:37 |
| ogra_ | for disabling adb the container bit needs to go anyway i think | 18:37 |
| rsalveti | but it's interesting that's getting inside the container | 18:37 |
| rsalveti | as at that time it'd have 2 adbd running | 18:37 |
| ogra_ | why ? | 18:37 |
| ogra_ | setprop changes the property, the current adbd dies and respawns | 18:38 |
| ogra_ | upstart sets the property again on startup of the job | 18:38 |
| ogra_ | that kills the in container adbd and spawns the ubuntu one again | 18:39 |
| ogra_ | effectively plars connects exactly in that moment where upstart respawns the job but isnt done | 18:39 |
| ogra_ | and hits the race | 18:39 |
| rsalveti | right, but why is the first adbd dying | 18:39 |
| ogra_ | because setprop brings down the gadget | 18:40 |
| ogra_ | uh, we need to make the mtp upstart job safer and make it read existing props ... (not related to this issue though) | 18:41 |
| ogra_ | it assues there is always adb and mtp ... if you want rndis it would break | 18:41 |
| rsalveti | yup, as I said during the sprint | 18:42 |
| ogra_ | it needs to read the existing property | 18:42 |
| rsalveti | seems it only supports 2 modes | 18:42 |
| rsalveti | at the same time | 18:42 |
| ogra_ | yeah, but that might not be adb | 18:42 |
| ogra_ | anyway, unrelated ... just saw we hardcode it | 18:42 |
| * ogra_ will submit a fix later | 18:43 | |
| ogra_ | lets first get the images testable again :) | 18:43 |
| rsalveti | so trying to think a way to not get the android adbd completely disabled | 18:43 |
| rsalveti | as that's useful | 18:43 |
| ogra_ | just make it a manual thing | 18:43 |
| rsalveti | but guess chmod -x might do the work | 18:43 |
| ogra_ | that would be a quick fix indeed | 18:43 |
| rsalveti | interesting, looking at the android init, there's not mtp + rndis in there | 18:44 |
| rsalveti | just rndis + adb | 18:44 |
| ogra_ | its in the device specific init.rc | 18:44 |
| rsalveti | yup | 18:44 |
| ogra_ | oh, you mean that | 18:44 |
| rsalveti | so you either use mtp or rndis | 18:45 |
| rsalveti | as done in android | 18:45 |
| ogra_ | yeah, i see | 18:45 |
| rsalveti | that's why you have that option in android | 18:45 |
| ogra_ | thats indeed intresting | 18:45 |
| ogra_ | yep | 18:45 |
| rsalveti | that you need to select which mode you want | 18:45 |
| ogra_ | so no mtp in debugging mode in android ... never noticed that | 18:46 |
| rsalveti | ogra_: yeah, which is fine, as long we have an ui for that | 18:46 |
| rsalveti | but topic for 14.04 | 18:46 |
| ogra_ | anyway, should we go with the -x fix ? | 18:46 |
| rsalveti | ogra_: so let's get back to your previous change, that removes adbd in lxc-android-config | 18:46 |
| ogra_ | i know sergiusens might work on a finer grained change for the disabled adb | 18:46 |
| rsalveti | but that would only be for the ubuntu side, right? | 18:47 |
| ogra_ | which means we perhaps get a better fix before release | 18:47 |
| ogra_ | well, it would have to handle the android side too as it is now | 18:47 |
| rsalveti | right | 18:47 |
| ogra_ | we cant leave it as is in either case | 18:47 |
| rsalveti | indeed, let's just remove it for now | 18:47 |
| sergiusens | rsalveti, ogra_ I'll get that fixed since it sort of blocks me | 18:47 |
| ogra_ | so lets do the quick fix with the option to get something better | 18:48 |
| rsalveti | sergiusens: what is your fix? | 18:48 |
| sergiusens | rsalveti, I'm looking at that now | 18:50 |
| sergiusens | don't have the answer yet | 18:51 |
| rsalveti | sergiusens: should we push a workaround now then? | 18:51 |
| asac | i am not sure | 18:52 |
| asac | does plars have a workaround for automation? | 18:52 |
| plars | asac: it seems to be working fine now, are we just getting lucky? | 18:52 |
| ogra_ | asac, not easily, has to be in the image | 18:53 |
| asac | plars: what did you change? | 18:53 |
| sergiusens | asac, plars yes, just getting lucky | 18:53 |
| ogra_ | asac, its a timing issue ... plars hit a race | 18:53 |
| plars | asac: nothing, once I restarted adb and got the devices visible again, it just worked | 18:53 |
| sergiusens | ogra_, asac plars there is a quick workaround | 18:53 |
| asac | did we change anything? or is likelyhood still the same as before? | 18:53 |
| asac | hmm | 18:53 |
| sergiusens | just add the pre.d script that deletes adbd | 18:53 |
| asac | so what is interesting is that it happened on both sides | 18:53 |
| asac | err both phones at same run | 18:53 |
| plars | asac: well, something had adbd running on the host as another user, which didn't have the proper permissions | 18:53 |
| sergiusens | lucky as I was in android user shell, ran adb root and got to the ubuntu shell | 18:54 |
| asac | i personally would prefer a workaround | 18:54 |
| asac | i dont want this kind of luck :) | 18:54 |
| ogra_ | asac, yes, we have a fix | 18:54 |
| plars | generally I'd say this happens because either adbd dies, or someone kills it, then the next one to run adb <anything> gets the adbd ownership | 18:54 |
| plars | that's why we couldn't see the devices | 18:54 |
| ogra_ | yeah | 18:54 |
| plars | but as for why that happened, don't know yet | 18:54 |
| asac | plars: yeah. we should investigate how that host behavioru can happen too ... and eliminate | 18:54 |
| sergiusens | you should still see the devices though | 18:54 |
| asac | however, since it happened right on mtp landing day | 18:54 |
| ogra_ | right | 18:54 |
| asac | lets land a fix on image | 18:54 |
| ogra_ | yes | 18:55 |
| asac | plars: so tests are running happily? | 18:55 |
| ogra_ | lets see after the first reboot :) | 18:56 |
| asac | hehe | 18:56 |
| plars | asac: yes, so far | 18:56 |
| asac | yeah | 18:56 |
| ogra_ | for this boot they will surely just run | 18:56 |
| asac | plars: what is "far" ? 1,2,3,4 reboots? | 18:56 |
| plars | asac: maguro is 3 or 4 tests in, and mako is installed and running the second set of tests | 18:56 |
| asac | ok | 18:56 |
| asac | nice | 18:56 |
| ogra_ | plars, did we have reboots inbetween ? | 18:56 |
| plars | sorry, that's backwards, mako is on the 4th, maguro now on 3rd test | 18:57 |
| asac | hmm. thought he meant autopilots. we reboot in between autopilots | 18:57 |
| plars | ogra_: yes, reboots between each | 18:57 |
| ogra_ | great | 18:57 |
| asac | goodie | 18:57 |
| ogra_ | so its actually only the first boot thats affected | 18:57 |
| plars | and working ok for me locally too | 18:57 |
| ogra_ | yeah, here as well | 18:57 |
| asac | sergiusens: https://bugs.launchpad.net/autopilot/+bug/1226505 is fixed in trunk? | 18:57 |
| ubot5 | Ubuntu bug 1226505 in Autopilot "New autopilot version breaks three ubuntu-ui-toolkit tests" [Critical,Fix committed] | 18:57 |
| asac | e.g. can we try landing again? | 18:57 |
| * ogra_ tries to find the revert for lxc-android-config with the fix in it | 18:58 | |
| * plars -> doctor - back in a bit | 18:58 | |
| kgunn | fginther: ping | 18:58 |
| thomi | asac: yes | 18:58 |
| fginther | kgunn, pong | 18:59 |
| thomi | asac: I reverted the changes | 18:59 |
| asac | thomi: did you run all autopilots succeessfully afterwards? | 18:59 |
| asac | :-P | 18:59 |
| kgunn | fginther: hey..sorry, been xmir-ing so on and off irc | 18:59 |
| kenvandine | asac, those content-hub features has a status of in image 53 | 18:59 |
| thomi | asac: The changes would have made test authors lives *much* easier, but if you don't want incompatible changes in S then you'll have to wait until T | 18:59 |
| asac | kenvandine: right | 18:59 |
| kenvandine | but the code for those haven't been merged yet | 18:59 |
| fginther | kgunn, I don't remember pinging you, did i? | 18:59 |
| sergiusens | rsalveti, ogra_ wouldn't rm $LXC_ROOTFS_PATH/init.usb.rc solve it better? | 18:59 |
| kgunn | fginther: was there an issue with the mir armhf build config we were pinging about earlier | 18:59 |
| ogra_ | sergiusens, not sure what else we remove with that ... seems a bit broad | 19:00 |
| fginther | kgunn, let me refresh my memory, one moment | 19:00 |
| asac | kenvandine: well, it was added to the landing asks | 19:00 |
| kenvandine | asac, well one of them hit trunk a little bit ago | 19:00 |
| sergiusens | ogra_, all the usb settings which we probably want to control from ubuntu anyways | 19:00 |
| kgunn | fginther: it was this...? We're seeing what look like setup problems: https://jenkins.qa.ubuntu.com/job/mir-saucy-armhf-ci/7/console | 19:00 |
| asac | kenvandine: i wonder why you would add it to landing asks if its not there | 19:00 |
| asac | :/ | 19:00 |
| asac | kenvandine: we landed content-hub today | 19:01 |
| asac | that was suppose to be it | 19:01 |
| kenvandine | asac, there are others that are waiting for code | 19:01 |
| kenvandine | well, i was told to make sure the pending features are on your radar :) | 19:01 |
| ogra_ | sergiusens, hmm, wont init parf if it cant find the include file ? | 19:01 |
| ogra_ | *barf | 19:01 |
| kenvandine | asac, the stuff that was published today was just minor changes to the API from 2 weeks ago | 19:01 |
| asac | kenvandine: they didnt have waiting for code as status this morning or any hint that we should wait | 19:01 |
| fginther | kgunn, that's a transient launchpad communication problem that I just started seeing today. I don't know what we did to upset the gods | 19:01 |
| ogra_ | we might have to sed the init.rc as well if it cant hanlde that | 19:01 |
| asac | or was that an oversight? | 19:01 |
| asac | kenvandine: anyway | 19:02 |
| asac | a bit painful, but what not | 19:02 |
| kenvandine | asac, sorry.. that's what i told jason when he asked me for the details | 19:02 |
| ogra_ | sergiusens, i think i prefer the proven fix we had before so we can get another image out with that fixed | 19:02 |
| kenvandine | the peer registry branch is ready, wayting for a review from tvoss | 19:02 |
| ogra_ | sergiusens, we can do the complete removal of the file after some more testing imho | 19:03 |
| kenvandine | the store stuff for confined apps should be proposed for merging by tomorrow morning | 19:03 |
| sergiusens | ogra_, ack | 19:03 |
| kenvandine | and gusch has some SDK components he is trying to get merged too | 19:03 |
| ogra_ | sergiusens, i.e. land it with the other changes to adb | 19:03 |
| kgunn | fginther: ok, cool that you're aware | 19:03 |
| asac | kenvandine: can you come back if all is in? | 19:03 |
| asac | kenvandine: or whenever you want an update in? | 19:03 |
| kenvandine | asac, will do... i changed the status to waiting for code | 19:04 |
| asac | sure. an you make another entry that asks for a general code landing right before that | 19:04 |
| fginther | kgunn, also, the android build was added before I started paying attention. perhaps thomi knows what it's for (https://jenkins.qa.ubuntu.com/job/mir-android-saucy-i386-build/) | 19:04 |
| asac | kenvandine: and set that to INIMAGE | 19:04 |
| asac | and list 53? | 19:04 |
| kenvandine | i would like to plan to get it landed in the image this week, really want to get this out in the wild to get more testing | 19:04 |
| asac | well, we can land it if its there, but not before :) | 19:05 |
| kenvandine | of course ;) | 19:05 |
| asac | kenvandine: please add a new entry that requested the landing we just did :) | 19:05 |
| asac | ok | 19:05 |
| kenvandine | will do | 19:05 |
| asac | and set it to DONE ... assign it to lukasz etc. | 19:05 |
| asac | kenvandine: just put it before the current content hub things | 19:05 |
| asac | thanks | 19:05 |
| asac | cyphermox: :) | 19:06 |
| asac | cyphermox: do you know what we usually would do for the scopes on desktop? | 19:06 |
| asac | cyphermox: sil left saying that touch was validated and good and only waiting on unity7 and its tests | 19:06 |
| asac | 20:17 < sil2100> asac: ok, so after testing the libunity and unity-scope-home versions that are requested for release by "scopes #1" it seems to look ok from the touch point of view - but we still need to make sure it doesn't cause a regression in unity7 (which is still building now) | 19:06 |
| cyphermox | so we're just wiating for the results of the check job for the unity stack | 19:07 |
| cyphermox | asac: I'm theoretically off today, not currently in a position to connect to the VPN to get to see the jenkinds output | 19:08 |
| asac | k | 19:08 |
| asac | guess has to wait then | 19:08 |
| rsalveti | sergiusens: I wouldn't recommend you to remove the device specific usb file yet | 19:08 |
| rsalveti | as I'm sure that is still used to setup the usb properties | 19:08 |
| asac | cyphermox: where do i find that jenkns thing? | 19:08 |
| kenvandine | asac, ok, so i added it to the asks sheet and updated the status of the others, so now the one of the plan sheet basically references that asks entry | 19:09 |
| rsalveti | sergiusens: ogra_: to be safe, just remove the adbd binary when mounting the container | 19:09 |
| cyphermox | asac: : http://10.97.0.1:8080/ | 19:09 |
| sergiusens | rsalveti, that's done in the upstart script | 19:09 |
| cyphermox | kenvandine: do you know if the unity stack is done with its tests? | 19:09 |
| ogra_ | rsalveti, yes, i have a package ready | 19:09 |
| ogra_ | rsalveti, just testing | 19:09 |
| kenvandine | cyphermox, i don't | 19:09 |
| asac | kenvandine: good. so the one DONE reflects what was done and the outstanding ones reflect the outstanding ones | 19:09 |
| ogra_ | to make sure it still works all fine | 19:09 |
| asac | kenvandine: can you just update each if the code is tehere and ready? | 19:09 |
| asac | so we see it in the morning? | 19:09 |
| rsalveti | sergiusens: not that sure for mtp | 19:10 |
| rsalveti | ogra_: cool | 19:10 |
| ogra_ | rsalveti, ugh ... we also need to unset mtp on shutdown ... | 19:10 |
| ogra_ | in the property | 19:10 |
| ogra_ | else nautilus acts up | 19:10 |
| rsalveti | why unset? | 19:10 |
| rsalveti | yeah, might be better | 19:10 |
| ogra_ | because the gadget stiull exposes it and gvfs tries to connect to a non existing daemon | 19:10 |
| kenvandine | asac, i will | 19:10 |
| asac | cyphermox: where do i look there? | 19:10 |
| asac | in cu2d? | 19:10 |
| ogra_ | so nautilus spits out an mtp mount error on device reboot | 19:11 |
| rsalveti | cyphermox: something for you to fix in the mtp service | 19:11 |
| ogra_ | yeah | 19:11 |
| asac | cyphermox: seems cu2d-unity-saucy #3 is still running :) | 19:11 |
| cyphermox | asac: ack | 19:11 |
| cyphermox | rsalveti: yeah? bug? | 19:11 |
| asac | cyphermox: so if that is finished someone can promote that in theory? | 19:11 |
| rsalveti | cyphermox: just disable mtp when the device is shutting down | 19:12 |
| ogra_ | asac, plars, lxc-android-config 0.98 has the fix for adb | 19:12 |
| rsalveti | so we can still tell the host side that mtp is now gone | 19:12 |
| ogra_ | right | 19:12 |
| asac | ogra_: ok... debdiff? uploaded? | 19:12 |
| asac | guess is already up | 19:12 |
| asac | so next image will have it | 19:12 |
| ogra_ | asac, yeah | 19:12 |
| ogra_ | right | 19:12 |
| asac | did we validate the fix? :) | 19:12 |
| ogra_ | asac, debdiff is this one reverted: http://launchpadlibrarian.net/144051867/lxc-android-config_0.42_0.43.diff.gz | 19:12 |
| asac | in tehe sense that i can relax now? or do we expect another bustage with >2% ? P) | 19:12 |
| ogra_ | asac, i tested locally adbd still behaves, mtp still works | 19:13 |
| asac | ogra_: where you able to reproduce the broken behavioru before? | 19:13 |
| ogra_ | no | 19:13 |
| asac | see :) | 19:13 |
| asac | but well.. story sounds a bit sane | 19:13 |
| ogra_ | only plars can do final verification here i fear | 19:13 |
| asac | so i am happy | 19:13 |
| asac | in theory we should try to validate that our fixes fix something though :) | 19:14 |
| ogra_ | yeah, but that kind of requires that you can reproduce it | 19:14 |
| asac | exactly :-P | 19:14 |
| ogra_ | which you cant manually | 19:14 |
| ogra_ | its one of these fixes ... | 19:15 |
| ogra_ | :) | 19:15 |
| asac | do we have a story why that cant be done manually as well? :) | 19:15 |
| ogra_ | timing | 19:15 |
| asac | yeah. thats where the story usually ends :) | 19:15 |
| ogra_ | i suppose you could kind of do it semi scripted | 19:15 |
| asac | randomness struck two devices duringt he same image test run :) | 19:16 |
| ogra_ | but since it also only seems ot happen on first boot thats time consuming | 19:16 |
| asac | yeah. lets hope | 19:16 |
| ogra_ | and it is a change in lxc-android-config we need anyway for disabling adb by default | 19:17 |
| ogra_ | so even if it wouldnt work the change would be needed ofr something else | 19:17 |
| asac | right | 19:17 |
| asac | all fine | 19:17 |
| ogra_ | yeah, lets just all sit in awe and wait for the next image test :) | 19:18 |
| asac | lets stay awake for the next 10 image runs :) | 19:18 |
| ogra_ | haha | 19:18 |
| ogra_ | my jetlag waves | 19:18 |
| asac | cyphermox: which check do i care about? | 19:21 |
| asac | 0% | 19:21 |
| asac | cu2d-unity-head-2.2check ? | 19:21 |
| cyphermox | yep | 19:23 |
| asac | wow i am confused | 19:23 |
| asac | that one was listed as failed, but now i found another path to that job and there its still running :) | 19:23 |
| asac | http://10.97.0.1:8080/job/cu2d-unity-saucy-2.2check/ | 19:24 |
| asac | vs. | 19:24 |
| asac | http://10.97.0.1:8080/view/cu2d/view/Head/view/Unity/job/cu2d-unity-head-2.2check/ | 19:24 |
| asac | cyphermox: the latter didnt run since sep 12 | 19:24 |
| asac | guess we dont use head anymore? | 19:24 |
| asac | cyphermox: i think it failed like this: http://paste.ubuntu.com/6120814/ | 19:26 |
| asac | cyphermox: is that usually a thing to retry? | 19:26 |
| thomi | fginther: just watching this: http://s-jenkins:8080/job/autopilot-1.3-ci/19/console it seems like it runs the various CI configurations serially, rather than in parallel - is that just because not all the configuration machines are available at the same time? | 19:47 |
| thomi | or rather, not available at once | 19:47 |
| fginther | thomi, all of the "$series-$arch" jobs are run in parallel as long as that resource is available | 19:49 |
| thomi | I see | 19:49 |
| fginther | the console log is only updated as the builds complete | 19:49 |
| kgunn | fginther: so wrt transient launchpad communication problem that you just started seeing today is making it hard to land code changes....and suggestions ? | 19:50 |
| fginther | kgunn, I was working on a retry fix, want to review :-) | 19:51 |
| kgunn | fginther: if needed i can select a victim | 19:51 |
| asac | rsalveti: can you update in asks exactly what is coming and where from? | 19:51 |
| fginther | kgunn, I don't know what's the root of the problem, if we are beating on it too hard or something else, I need to ping launchpad ops | 19:51 |
| asac | rsalveti: so for qtmultimedia bzr branches and so on | 19:51 |
| kgunn | fginther: we notice it started yesterday and is always armhf...so | 19:52 |
| asac | build issues? | 19:52 |
| rsalveti | asac: yup, cleaning that up still so we can have them all done in good shape to just be pushed to the archive | 19:52 |
| kgunn | wonder we should turn it back off | 19:52 |
| asac | fginther: is that ppa build issues? | 19:52 |
| rsalveti | but still work to be done from jim's side | 19:52 |
| fginther | asac, no, it's an issue with our build scripts getting data from launchpad | 19:53 |
| asac | ic | 19:53 |
| asac | fginther: soyuz/archive or code/merge api? | 19:54 |
| fginther | code/merge api | 19:54 |
| * fginther wonders if this is actually a race condition that we just didn't hit until now | 19:55 | |
| asac | fginther: i asked wgrant and stevenk to come in here when they get up | 19:58 |
| asac | they are aus timezone | 19:58 |
| asac | they are our launchpad experts | 19:58 |
| asac | and should be able to get you a better idea | 19:58 |
| fginther | asac, thanks | 19:59 |
| thomi | fginther: how often does the upstream-merger job scan for new MPs to land? | 20:17 |
| fginther | thomi, 15 minutes | 20:19 |
| fginther | thomi, however, it's now taking 25+ minutes to run | 20:20 |
| thomi | :( | 20:20 |
| thomi | makes me sad | 20:20 |
| thomi | fginther: out of interest, how come it takes 25 minutes to run? | 20:22 |
| * fginther suddenly realizes why it's taking so long | 20:22 | |
| fginther | thomi, the recent switch to the 'saucy' stacks caused the change | 20:23 |
| fginther | it wasn't in the magic list of 'run these in parallel | 20:24 |
| thomi | so.... we can fix that, right? | 20:24 |
| fginther | now it is, the next one should run faster | 20:24 |
| * thomi crosses fingers | 20:24 | |
| thomi | \o/ | 20:24 |
| rsalveti | asac: what do you mean by waiting for code? | 20:24 |
| rsalveti | asac: for example, for the "Adding gstreamer1.0-pulseaudio to the seeds" we already have a MR for it | 20:25 |
| rsalveti | further steps would be getting that merged and pushing a new meta | 20:25 |
| cjohnston | doanac: should we merge in the two branches and release utah? | 20:26 |
| doanac | cjohnston: your branch and pauls? | 20:27 |
| cjohnston | doanac: yes | 20:27 |
| doanac | sure | 20:27 |
| cjohnston | unless there is other stuff outstanding that we need? | 20:27 |
| doanac | i don't think so. i'll pull the trigger | 20:27 |
| cjohnston | ack | 20:27 |
| === ogra_ is now known as ogra | ||
| asac | rsalveti: FFe? thats not approved i think yet | 20:34 |
| asac | rsalveti: isnt that just going on the touch image? | 20:35 |
| asac | ah its a patch | 20:35 |
| rsalveti | asac: that line is just about adding gstreamer1.0-pulseaudio to the seeds :-) | 20:35 |
| kgunn | alan_g: fginther has a plan b :) | 20:35 |
| rsalveti | we have gstreamer0.10-pulseaudio already, but we need the 1.0 now | 20:35 |
| asac | rsalveti: you could call that out. i thought you want to land a new package | 20:36 |
| fginther | kgunn, I should have it ready in a few minutes | 20:36 |
| rsalveti | asac: no, just including it to the seeds (we need a new package, but later on) | 20:36 |
| rsalveti | asac: can we push that forward then? | 20:36 |
| asac | rsalveti: is that ok frmo legal? :) ... otherwise go for it | 20:37 |
| rsalveti | asac: yup, that's just the pulseaudio plugin for gstreamer | 20:38 |
| rsalveti | all good | 20:38 |
| rsalveti | ok | 20:38 |
| asac | rsalveti: its about -bad | 20:38 |
| asac | i thought | 20:39 |
| rsalveti | that on I'm breaking into a separated package | 20:39 |
| asac | rsalveti: i am talking about " gst-plugins-bad1.0 with libstagefright support (android hardware decode/rendering)" | 20:39 |
| rsalveti | so we don't need to include the entire bad set | 20:39 |
| asac | rsalveti: ok you talk labout the seeds thing | 20:39 |
| rsalveti | that's indeed still waiting on code, and FFe | 20:39 |
| rsalveti | yeah, my request was a different one | 20:40 |
| asac | rsalveti: that impacts music app and videoplayback? | 20:40 |
| asac | the seed? | 20:40 |
| rsalveti | nops, as that is still using the gstreamer0.10 packages | 20:40 |
| rsalveti | we're still migrating stuff to gst1.0 | 20:40 |
| rsalveti | all I want to do now is making sure we also have the same set of gst1.0 packages | 20:40 |
| rsalveti | to avoid dependency issues later on | 20:40 |
| doanac | plars, cjohnston: building a new utah for you guys | 20:40 |
| cjohnston | doanac: plars at some point I'd like to chat about parallelizing the smoke tests... figure out exactly what we want to do | 20:40 |
| cjohnston | sweet. ty | 20:40 |
| doanac | cjohnston: yep. we should talk soon | 20:41 |
| asac | rsalveti: so i assume its ok. i set status to "self upload" so the team can look at what happened tomorrow | 20:41 |
| rsalveti | ok | 20:41 |
| asac | rsalveti: the rest all is waiting for code, right? | 20:41 |
| rsalveti | yup | 20:41 |
| fginther | kgunn, does mir need to build with ppa:ubuntu-unity/daily-build. I'm assuming the answer is no | 20:43 |
| asac | sergiusens: looking at your phablet-flash request. how can we be sure that phablet-flash doesnt break utah? you think you could learn how to run utah and try that locally to give me confidence? | 20:44 |
| kgunn | fginther: mmm...eventually | 20:44 |
| kgunn | fginther: we'd hope that when we do land our stuff in our trunk, we then build in experiemental...test it, then tell didrocks we want to go to archive | 20:45 |
| kgunn | fginther: so at that point of going to archive..i assume the path resumes normally (via daily-build) | 20:45 |
| fginther | kgunn, right, but to actually build mir for upstream merger, do you need anything from that ppa that wouldn't already be in the archive? | 20:45 |
| fginther | kgunn, the other components in the mir stacks all build into a shared local archive (so unity-system-compositor builds with the most recent commit of mir) | 20:47 |
| cjohnston | doanac: https://code.launchpad.net/~cjohnston/qa-dashboard/ci-dashboard/+merge/186057 | 20:51 |
| cjohnston | fginther: ^^ didn't get run through CI | 20:51 |
| doanac | cjohnston: was the rename a request? ie - i wonder if renaming is going to cause confusion? | 20:53 |
| cjohnston | doanac: it wasn't... but as we push more to make the dashboard do more things, it really becomes more of a CI tool | 20:54 |
| fginther | cjohnston, thanks for the reminder, I think I found the problem | 20:54 |
| doanac | cjohnston: probably should send this to the QA and CI mailing lists to see what people think | 20:55 |
| mmcc | Hi folks, I have a package that needs to be added to CI - lp:ubuntuone-credentials. We're going to be adding it to the landing pipeline spreadsheet soon and want to be sure it's integrated correctly. | 20:56 |
| cjohnston | seems a little overboard to me. but not my decision I guess | 20:56 |
| mmcc | my question is - what's my next step? I have a branch of cupstream2distro-config that adds it to the webcred stack, but it at least needs a thorough review if not just having someone do it correctly for us. :) | 20:57 |
| cjohnston | fginther: ^ | 20:57 |
| cjohnston | heh.. | 20:57 |
| fginther | mmcc, I can help | 20:58 |
| fginther | mmcc, just send me the branch | 20:59 |
| mmcc | fginther: great, thanks. my changes are here: https://code.launchpad.net/~mikemc/cupstream2distro-config/add-ubuntuone-credentials | 20:59 |
| fginther | mmcc, I can add the changes right now to start the upstream merger builds, but the integration team will need to do additional reviews to make sure these two projects are ready to go into the archive | 21:00 |
| asac | rsalveti: you see anything else low hanging with code in the landing asks? | 21:01 |
| rsalveti | let me check | 21:01 |
| asac | just thinking that you usually test your uploads so maybe we hsoudl test something at the same time on your device :) | 21:01 |
| asac | lol | 21:01 |
| mmcc | fginther: that sounds like progress to me. do you know of anything I can do to help make that review process smoother? | 21:01 |
| fginther | mmcc, but if you want to wait, you can just convert that into a MP | 21:01 |
| asac | plars: back :)? | 21:02 |
| asac | j.k. | 21:02 |
| cwayne1 | asac: there's code for landing lightdm :P | 21:02 |
| asac | cwayne1: i know... its in a MP | 21:02 |
| mmcc | fginther: sorry, didn't follow - if I want to wait for what? | 21:02 |
| asac | cwayne1: i am saying we can try. we will look at it tomorrow. most likely it requires you to merge to trunk | 21:03 |
| asac | so we can pick it in the staging ppa | 21:03 |
| asac | and test it with something else together | 21:03 |
| fginther | mmcc, if you want to wait for the integration team to also review the projects you're adding. I suggest adding the upstream merger bits now, and letting didrocks team review when they have time | 21:03 |
| plars | asac: yes | 21:03 |
| asac | rsalveti: so something in daily-build ppa broke 3 unity8 tests :) | 21:04 |
| asac | rsalveti: i uphgraded the whole lot | 21:04 |
| asac | if you find what to kick out so we can let everything else in, you get something nice :) | 21:04 |
| asac | hehe | 21:04 |
| fginther | mmcc, there's a couple changes needed to your branch to make that happen. I'll do it on my end first | 21:04 |
| asac | i wouldnt start looking though | 21:04 |
| rsalveti | hahah, right | 21:04 |
| sergiusens | asac, give me instructions to setup utah and I'll run it, but given the code I saw in utah it shouldn't break | 21:05 |
| mmcc | fginther: OK, thanks. I'll go with your recommendation, since I'm not aware of any special circumstances for our projects. | 21:06 |
| asac | nothing should break | 21:06 |
| asac | but then there are those bugs :) | 21:06 |
| asac | lol | 21:06 |
| mmcc | fginther: ie, I don't know if I want to wait for them to review it or not, so it's all the same to me :) | 21:06 |
| asac | sergiusens: i think plars knows how to use utah commands to flasha nd run tests on your local devices | 21:07 |
| asac | and doanac | 21:07 |
| sergiusens | plars, give me the goods :-) | 21:07 |
| fginther | mmcc, http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/revision/786 | 21:07 |
| plars | sergiusens: you want to do it exactly the same way we do in the lab right? | 21:08 |
| sergiusens | plars, I don't really want to, but it seems necessary ;-) | 21:08 |
| plars | sergiusens: https://wiki.canonical.com/UbuntuEngineering/QA/ImageTestingRun is almost accurate - if you want touch_ro builds, there's one more thing you need | 21:09 |
| plars | sergiusens: one sec and I'll update | 21:09 |
| plars | sergiusens: of course if you don't want to run an autopilot test, just provision, you just need to run provision.sh, not jenkins | 21:09 |
| mmcc | fginther: should those be project names? it looks like it's missing the 's' at the end of 'ubuntuone-credentials' | 21:10 |
| sergiusens | plars, yeah, I'm stopping after provision :-) | 21:10 |
| fginther | mmcc, ughhhhhhhhh | 21:10 |
| sergiusens | plars, can this run fine in a schroot? | 21:10 |
| plars | sergiusens: ok, reload | 21:11 |
| plars | sergiusens: don't see why not, as long as you have an adb connection | 21:11 |
| plars | sergiusens: the thing you need for touch_ro is to set TOUCH_IMAGE=--ubuntu-bootstrap (obviously based on a historical flag... we'll probably change that to something nicer soon) | 21:12 |
| plars | sergiusens: also note that I changed the branch mentioned in that wiki | 21:12 |
| plars | sergiusens: otherwise, should be good to go | 21:12 |
| sergiusens | plars, ok, I'm setting up a schroot for precise to test this | 21:13 |
| fginther | robru, can you assist mmcc in what is needed to get signon-plugin-password and ubuntuone-credentials in daily release? | 21:13 |
| mmcc | fginther: and I made a noob mistake on the signon plugin - that's a package dep, but it's from lp:signon which is already included in the stack :\ | 21:14 |
| mmcc | I got fooled by signon-plugin-oauth2 being a separate LP project | 21:15 |
| sergiusens | asac, fginther can we add utah env setup tests for phablet-tools ci? | 21:16 |
| fginther | mmcc, turns out I messed up too :-) | 21:16 |
| asac | sergiusens: i think for that you need to have real phones and flash and test them? | 21:18 |
| sergiusens | asac, yes | 21:18 |
| mmcc | fginther: :) hopefully I'm not too contagious in here | 21:18 |
| asac | i guess might be possible | 21:18 |
| sergiusens | asac, provision, network setup and test setup (they do all that) | 21:18 |
| sergiusens | asac, and a simple test run | 21:18 |
| sergiusens | asac, just one test | 21:19 |
| fginther | sergiusens, is that already part of phablet-tools? | 21:19 |
| asac | sergiusens: do you plan to still test locally? :) | 21:19 |
| asac | otherwise i can see how you shoot down our nice phones :) | 21:19 |
| asac | fginther: it is | 21:19 |
| sergiusens | asac, yes I am, but having it as part of ci would be better | 21:19 |
| asac | phablet-flash, phablet-network, phablet-test-run ... | 21:19 |
| asac | sergiusens: absolutelu | 21:19 |
| asac | also utah | 21:20 |
| asac | so at best both :) | 21:20 |
| asac | test utah and phablet on phablet-tools ci | 21:20 |
| sergiusens | asac, that's the beauty, if you run a utah cycle, you have great confidence on almost all the tools | 21:20 |
| fginther | sergiusens, I know nothing about these tests, can we execute them from "autopilot run" or do we just need to build a special job? | 21:21 |
| sergiusens | fginther, very custom job | 21:21 |
| fginther | sergiusens, that's what I though | 21:21 |
| sergiusens | fginther, a precise instance that sets up utah, then installs the built phablet-tools and instances utah to do stuff | 21:21 |
| asac | sergiusens: do you know how to publish stuff from daily-release? | 21:21 |
| asac | sergiusens: i assume not? | 21:21 |
| sergiusens | fginther, that 'precise' env would need to have a device hooked up | 21:22 |
| sergiusens | asac, I'm not allowed to, don't have the permissions | 21:22 |
| fginther | sergiusens, our devices are all hosted on the same system. | 21:23 |
| asac | cyphermox: can you help phablet-flash after sergiusens confirms that utah still works? | 21:23 |
| fginther | not necessarly a problem, but need to be careful | 21:23 |
| asac | cyphermox: from what i understand its already staged in the ppa | 21:23 |
| asac | sergiusens: can you confirm its in daily-build? | 21:23 |
| sergiusens | asac, it's not in daily-build, daily release wasn't triggered for it today | 21:25 |
| sergiusens | asac, so it would need a full daily-release cycle | 21:25 |
| fginther | sergiusens, can you create a work item or bug for this somewhere? I need to take off for a while | 21:25 |
| sergiusens | fginther, sure | 21:26 |
| doanac | plars, cjohnston: the utah update is available for deployment if you want it | 21:26 |
| kgunn | fginther: any news on armhf ? | 21:27 |
| asac | plars: webbrowser failed i think | 21:27 |
| asac | on maguro | 21:27 |
| asac | otherwise looks good | 21:27 |
| plars | asac: I know, I've already retriggered it | 21:27 |
| plars | doanac: you got https://code.launchpad.net/~cjohnston/utah/1225700 also right? | 21:27 |
| kgunn | fginther: did i fail to answer your ques above...which is yes, we should only need to build mir | 21:27 |
| doanac | plars: yes | 21:28 |
| plars | doanac: great! | 21:28 |
| plars | asac: you mean on mako? | 21:29 |
| plars | asac: on maguro, it had the testcase failure that I mentioned on #ubuntu-touch | 21:29 |
| asac | plars: maguro i wondered if thats a retry | 21:29 |
| plars | asac: I can retrigger it if you like there, but it's one that we've seen before as being flaky | 21:29 |
| asac | thing | 21:29 |
| plars | asac: it is - known flaky test | 21:29 |
| asac | plars: yeah better retry | 21:29 |
| asac | not sure if maguro is busy otherwise :) | 21:30 |
| asac | mako is more improtant to get in shape though :) | 21:30 |
| kgunn | fginther: just checked it seems to be failing in a different way | 21:36 |
| alan_g | kgunn: FWIW "old" way - https://jenkins.qa.ubuntu.com/job/mir-saucy-armhf-ci/7/console and "new" way https://jenkins.qa.ubuntu.com/job/mir-saucy-armhf-ci/8/console | 21:39 |
| robru | fginther, mmcc, sorry I was on lunch. glad to help -- still need me? | 21:44 |
| mmcc | robru: yes, thanks - I need to add lp:ubuntuone-credentials to CI, as fully integrated as possible, and basically I need to know first what that means, and second what to do to make it happen :) | 21:45 |
| robru | mmcc, ok, are talking CI or daily release? For CI you want fginther, but for daily release I can help ;-) | 21:46 |
| robru | mmcc, assuming you meant daily release, first I need to do a packaging review, then I need to twiddle some bits in the daily_release machine | 21:46 |
| mmcc | I believe fginther handled the CI upstream merger stuff - and he pinged you for daily release, yes | 21:47 |
| robru | ok, great. I'll look over the packaging then. what's the lp branch for the signon one? | 21:47 |
| mmcc | signon-password-plugin is in lp:signon, which may already be included. | 21:47 |
| robru | ok, i'll check | 21:47 |
| robru | mmcc, ok, ubuntuone has no packaging at all ;-) has it ever been released in distro? | 21:48 |
| sergiusens | plars, asac ok, setup took some time... utah is running in my schroot now | 21:49 |
| robru | hmmm, i see it in distro. i'll have to track down where the packaging lives | 21:49 |
| mmcc | robru: my apologies, you're talking to a packaging noob - are you looking for the debian/ directory? our projects have been keeping that in a separate branch | 21:49 |
| mmcc | I'm not sure why, but i can point you to it, one sec | 21:49 |
| robru | mmcc, yes, we need to merge debian/ into trunk and make some changes there in order to have daily release work. | 21:50 |
| robru | mmcc, https://wiki.ubuntu.com/DailyRelease/InlinePackaging this is the checklist we go by, but don't worry, I'll do the work. | 21:50 |
| mmcc | robru: FYI, it's over here - https://launchpad.net/ubuntuone-credentials/packaging-dailies | 21:50 |
| robru | mmcc, thanks | 21:51 |
| mmcc | robru: great, thanks. I'll be following along in case you need anything. | 21:52 |
| robru | mmcc, k, shouldn't be long | 21:52 |
| robru | mmcc, hmmm, odd version number. 99.12? is that right? | 21:53 |
| mmcc | robru: I'm pretty sure that's intentional but unfortunately the people who can give a definitive answer are past EOD right now... dobey (Rodney Dawes) has been doing most of the packaging work for our group | 21:54 |
| mmcc | and he just left 30 minutes ago ... | 21:55 |
| robru | mmcc, ok, no worries | 21:55 |
| robru | mmcc, it looks like a date -- this hasn't been in development since december 1999 has it? ;-) | 21:56 |
| mmcc | :) no, definitely not | 21:56 |
| robru | mmcc, hehe, ok. mostly looks good over here, just doing a couple test builds to confirm some stuff. | 22:04 |
| mmcc | robru: great. | 22:05 |
| mmcc | robru: I just remembered the method there - trunk has that 99.blah version number, and separate stable branches get set up where he updates the version number to make releases. e.g.: http://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-credentials/stable-13-10/revision/32?start_revid=32 | 22:06 |
| robru | mmcc, hmmm, that's gonna have to go away. daily release will be making releases direct to distro daily ;-) | 22:07 |
| robru | mmcc, so I changed the version number to what's in distro, should be ok I think. | 22:07 |
| robru | mmcc, http://paste.ubuntu.com/6121449/ some discrepancy in the symbols file. can you comment here? is this symbol necessary or is it a mistake? | 22:07 |
| mmcc | hmmm | 22:07 |
| mmcc | re the release branches going away, I assume that'll be fine. has to be, anyway | 22:08 |
| mmcc | as for that symbol, I think I do recognize that change, but I don't understand the context (like I said, I'm a linux packaging noob) | 22:09 |
| robru | mmcc, well, this is less of a packaging issue and more of a "did you or didn't you introduce new API recently?" issue | 22:09 |
| mmcc | we did add a new constructor for that class, yes. I'm double-checking now to be sure that signature matches | 22:10 |
| robru | mmcc, ok, I need help demangling the name for the symbols file because I'm not a C++ guy ;-) | 22:11 |
| mmcc | it's UbuntuOne::AccountRequest::AccountRequest(QString, QString, QString, QString) | 22:12 |
| robru | great, thanks. | 22:12 |
| mmcc | so, yes that was introduced in r 60 http://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-credentials/trunk/revision/60 | 22:12 |
| robru | brb | 22:13 |
| robru | ok | 22:17 |
| mmcc | so, I'm not clear on why both those lines in the diff get translated by c++filt into the same signature, though. | 22:17 |
| robru | dunno | 22:18 |
| mmcc | Well, a duplicate symbol shows up in the symbols file for the other constructors too | 22:22 |
| robru | mmcc, it's ok, I think I've got it fixed, now I'm just cleaning up a few minor lintian warnings. | 22:23 |
| mmcc | I guess duplicates in that file is not a problem | 22:23 |
| mmcc | cool | 22:23 |
| sergiusens | asac, plars doanac just found a small issue with deploying with utah, we need to use the --no-backup or --bootstrap option (the latter is pending landing) | 22:27 |
| sergiusens | without that, $HOME is saved | 22:27 |
| sergiusens | which could lead to inconsistent system tests | 22:28 |
| sergiusens | both options achieve the same btw | 22:28 |
| plars | sergiusens: ok, so if I add --no-backup, will we need to change it later? | 22:29 |
| plars | sergiusens: we already use --bootstrap for non-ro, but it wasn't available for ro | 22:30 |
| sergiusens | plars, no, but for a future reader, adding it as --bootstrap would be better | 22:30 |
| sergiusens | plars, there was no concept up until 3 weeks ago | 22:30 |
| sergiusens | that's why, the whole thing was a bootstrap always | 22:30 |
| doanac | plars: you need me to make the fix or are you working on it? | 22:32 |
| plars | doanac: I'm looking at something else right at this moment, I can get to it shortly though | 22:32 |
| doanac | plars: i'll try it out. | 22:33 |
| doanac | i'm having other issues at home so not sure how well the test will go. but ogra said the next image should help my issue | 22:33 |
| plars | doanac: it should be pretty easy. And I can roll that out tonight along with the utah fix and from_host | 22:33 |
| plars | doanac: I'm just finishing up retries on 53 at the moment, for some reason mako ended up in recovery mode, trying to figure out which job left it there | 22:34 |
| plars | doanac: it might be safer to do adb reboot at the beginning, rather than (as I think I recall we do) adb shell reboot | 22:34 |
| robru | mmcc, ok, so, with CI what you need to do is watch this: https://code.launchpad.net/~robru/ubuntuone-credentials/packaging/+merge/186173 wait for jenkins to approve it, and then set it to 'approved'. it will merge itself within an hour usually. | 22:34 |
| robru | well, also, you can review it yourself if you like ;-) | 22:35 |
| doanac | plars: i *think* we are doing "adb reboot" now | 22:35 |
| plars | doanac: odd | 22:35 |
| plars | ok | 22:36 |
| plars | doanac: oh, it might have tried to get info from it first or something... not sure, I'll look into it | 22:36 |
| sergiusens | asac, plars my phablet-tools is safe http://paste.ubuntu.com/6121516/ | 22:36 |
| doanac | sergiusens: --bootstrap isn't available in for the system-image option? | 22:36 |
| plars | doanac: not yet | 22:36 |
| sergiusens | doanac, it is in the unrelease package I'm testing | 22:37 |
| doanac | ah - okay. | 22:37 |
| doanac | i'll test with that. thanks | 22:37 |
| sergiusens | doanac, which from the looks of it it's ok (pastebin ^^) | 22:37 |
| mmcc | robru: thanks for your help! So, I may review it but I'm sure dobey will want to look. There's no harm in waiting until tomorrow to land that, I assume? | 22:37 |
| sergiusens | asac, are we good to daily release? | 22:37 |
| sergiusens | doanac, plars that said, what utah does after fails... | 22:38 |
| sergiusens | ERROR: running adb -s 0149C2230F018007 shell apt-get update -qq \; echo ADB_RC=\$? stdout was: | 22:38 |
| plars | sergiusens: hmm, check utah.log? | 22:39 |
| robru | mmcc, no harm at all, I just assumed you were in a rush | 22:39 |
| plars | sergiusens: clientlogs/utah.log that is | 22:39 |
| sergiusens | plars, hmm, it's empty | 22:39 |
| doanac | there might not be much if "apt-get update -qq" failed. | 22:39 |
| doanac | syslog might have something about it | 22:39 |
| sergiusens | doanac, running adb -s 0149C2230F018007 shell apt-get update (without -qq) works if I run manually | 22:40 |
| mmcc | robru: great. We are in a bit of a rush, but it doesn't have to go through today. Thanks again! | 22:40 |
| sergiusens | doanac, plars plenty of Sep 17 22:40:17 ubuntu-phablet kernel: [ 507.997802] adb_open | 22:40 |
| robru | mmcc, ok, so lp:signon is definitely already doing daily release. you're sure that's all you needed? once that packaging lands all I have to do is throw a switch and it'll start daily releasing. | 22:41 |
| sergiusens | plars, doanac I'm betting it's just mtp | 22:41 |
| asac | sergiusens: can you release just that? | 22:41 |
| mmcc | robru: that should be it, yes. so then I'll ping you tomorrow once your MP lands (or dobey may ping you first if he has questions) - that OK? | 22:41 |
| asac | otherwise, let me put your paste into the spread | 22:41 |
| asac | for tomorrow | 22:41 |
| robru | mmcc, no worries, I'll be around | 22:42 |
| mmcc | robru: cool, thanks again | 22:42 |
| robru | mmcc, you're welcome | 22:42 |
| sergiusens | asac, well phablet-tools from the utah run is solid, what comes after isn't but not related to phablet-tools | 22:42 |
| asac | sergiusens: thats not what i am asking :) | 22:42 |
| asac | i wondered if you can do the daily release to distro ... otherwise we have to find someone :) | 22:42 |
| sergiusens | asac, I can't, but for your peace of mind, it's the only MR that landed http://bazaar.launchpad.net/~phablet-team/phablet-tools/trunk/changes/187?start_revid=187 | 22:43 |
| sergiusens | kenvandine, robru cyphermox can you trigger a daily release for phablet-tools and phablet-tools only? | 22:44 |
| sergiusens | asac, there ^^ | 22:44 |
| robru | sergiusens, yes I can do that | 22:44 |
| sergiusens | thanks | 22:44 |
| asac | cool | 22:45 |
| asac | robru: can you put that into the landing plan? | 22:45 |
| robru | sergiusens, no, wait, you mean not the whole misc stack? hmmmm I'm not sure if I can do that | 22:45 |
| robru | asac i don't have edit rights on that doc | 22:45 |
| asac | hmm. please not all :) | 22:45 |
| sergiusens | robru, I thought it was possible | 22:45 |
| asac | robru: you should.. | 22:45 |
| sergiusens | well I know it is | 22:45 |
| robru | sergiusens, let me double check. I know how to do the whole stack for sure, never done just one branch before | 22:45 |
| robru | sergiusens, oh yeah yeah, nm, it's easy | 22:46 |
| asac | robru: you work with didrocks, right? | 22:46 |
| robru | asac, yep | 22:46 |
| robru | asac, i'm a direct report to didrocks | 22:46 |
| asac | ok | 22:46 |
| asac | robru: added you | 22:46 |
| asac | robru: so this one is fine. just document the landing progress in the landing plan | 22:46 |
| asac | put it where it fits by time :) | 22:47 |
| asac | guess 18 am | 22:47 |
| asac | put his paste in a comment | 22:47 |
| asac | and refer to his landing ask on the other sheet | 22:47 |
| robru | asac, ok. hey, i'm having trouble with the webapps stack. i fixed the latest build failure but when I rerun the stack, it just gives the same error again -- as if it's ignoring the latest commit in trunk. any ideas? | 22:47 |
| asac | e.g. update that that is "In Landing Plan" | 22:47 |
| asac | now | 22:47 |
| asac | thx | 22:47 |
| asac | zero idea :) | 22:48 |
| robru | bah | 22:48 |
| asac | i hope i never have to dive soo deep :) | 22:48 |
| asac | sergiusens: i think its save to wait till cyphermox comes back or we will pick it up tomorrow | 22:48 |
| asac | if robru is not familier with publishing a single thing then lets not risk :) | 22:49 |
| robru | asac, hmmm, I ran the command, doesnt' seem to have worked... | 22:49 |
| sergiusens | asac, ok, I think robru triggered and was asking about something else though | 22:49 |
| robru | sergiusens, yeah, I was asking about a different issue | 22:49 |
| robru | asac, ^ | 22:49 |
| asac | still... didnt sound like you know how to publish a single package from misc :) | 22:50 |
| plars | asac: I'm still getting lots of this adb_open message in the syslog when rerunning that webbrowser test | 22:50 |
| plars | http://10.97.0.1:8080/job/saucy-touch_ro-mako-smoke-webbrowser-app-autopilot/112/console - in progress | 22:50 |
| robru | asac, well, i've never done it before. but i just read the docs. sounds easy enough | 22:50 |
| sergiusens | plars, that will be fixed with ogra's package | 22:50 |
| plars | sergiusens: ah, ok | 22:50 |
| plars | asac: ^ so this build may be difficult to get much more out of until we get that | 22:50 |
| asac | robru: ok. | 22:50 |
| sergiusens | plars, adb from the container gets enabled and mtp resets the bus so we have plenty of errors then | 22:51 |
| asac | plars: can we switch device? | 22:51 |
| asac | sergiusens: oh so thats mtp? | 22:51 |
| sergiusens | asac, it's a mix | 22:51 |
| asac | is ogras fix in ? | 22:51 |
| robru | asac, sergiusens: ok, looks like it's running. just takes a sec to show up in web view. | 22:51 |
| asac | maybe we need a new image then :) | 22:51 |
| asac | robru: go ahead i guess | 22:51 |
| sergiusens | asac, no, that's u-t-s which I'm testing now | 22:51 |
| asac | kk | 22:51 |
| asac | robru: can you try to update the landing spread? the ask is in row 32 -> update that when you add it to the landing plan | 22:52 |
| robru | asac, in here? https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=0 row32 is blank | 22:53 |
| plars | asac: we can definitely switch devices, but from what sergiusens said it wouldn't help | 22:53 |
| asac | sergiusens: the adb thing is u-t-s? | 22:54 |
| asac | sergiusens: sure? | 22:54 |
| doanac | plars: building utah 0.15+20130917.1 right now. | 22:54 |
| asac | sergiusens: thought we add lightdm there | 22:55 |
| asac | sergiusens: :/ | 22:55 |
| sergiusens | asac, no, sorry | 22:55 |
| asac | sergiusens: i think the adb fix was uploaded a while ago | 22:55 |
| doanac | its got --bootstrap. so you can deploy once we have a new phablet-tools | 22:55 |
| sergiusens | too many packages | 22:55 |
| sergiusens | asac, it's lxc-android-config and it seems to be in | 22:55 |
| sergiusens | asac, at least the udd branch | 22:55 |
| lool | 'night all | 22:55 |
| asac | night lool | 22:55 |
| asac | sergiusens: right. lets get a new package for that i guess | 22:55 |
| asac | err build | 22:56 |
| asac | unless we plan to get something else in right now | 22:56 |
| asac | but i dont see that :) | 22:56 |
| sergiusens | https://launchpad.net/ubuntu/saucy/+source/lxc-android-config/0.98 | 22:57 |
| asac | sergiusens: right. can you do a new image? | 22:57 |
| asac | the last image busts our automation :) | 22:57 |
| asac | or did we do a new run afer? | 22:58 |
| sergiusens | asac, no, according to http://people.canonical.com/~ogra/touch-image-stats/20130917.changes last build has 97, we want 98 | 22:58 |
| asac | sergiusens: right. so give it a kick if you can | 22:59 |
| sergiusens | asac, sure, let me just confirm it reached the archives/ports | 22:59 |
| asac | we couldnt finish running llast image in utah because of adb | 22:59 |
| asac | thanks | 22:59 |
| plars | sergiusens: it's not enough that it says it's in the release pocket? | 22:59 |
| plars | I guess there's a sync delay due to that also | 23:00 |
| sergiusens | plars, no, not really... already been bit by that | 23:00 |
| sergiusens | plars, needs to make it all the way to Packages.gz | 23:00 |
| plars | yeah | 23:00 |
| sergiusens | it's in, I'm triggering | 23:00 |
| plars | all these "it's there, but it's not *really* there yet" things make automating simple stuff a pain | 23:01 |
| sergiusens | plars, yup, that and no API for many things; scrapping stuff is just too old school | 23:01 |
| sergiusens | plars, that's why I love our move to the image server, the json stuff really helps a lot | 23:02 |
| plars | sergiusens: we even have to wait for that one | 23:02 |
| plars | sergiusens: just because the json is there, the files may not be yet | 23:02 |
| sergiusens | plars, hmmm, I would of thought you'd get the files in and then push the json :-/ | 23:03 |
| sergiusens | build triggered btw | 23:04 |
| plars | sergiusens: I believe that's so, but then it gets rsynced or something | 23:04 |
| plars | sergiusens: if we have a new phablet-tools, I can apply that, utah, and the supporting bits we all discussed earlier before the new image arrives | 23:15 |
| robru | sergiusens, asac: anyways, it's building, but it's going really sloooowww... http://10.97.0.1:8080/job/cu2d-misc-saucy-2.1build/8/console | 23:17 |
| asac | robru: what stuff is in the misc branch? | 23:18 |
| asac | ok i think i see it | 23:18 |
| asac | well.. if its finished we can pick it up tomorrow easily | 23:19 |
| asac | dont know why we hurry :) | 23:19 |
| plars | "<asac> dont know why we hurry :)" - that's one for the quotes page :) | 23:20 |
| asac | lol | 23:20 |
| asac | sure | 23:20 |
| plars | heh seriously though | 23:20 |
| plars | asac: sergiusens noted earlier that we should use the --bootstrap flag as it would be safer | 23:21 |
| asac | about phablet-tools landing that got fastpathed and folks want it even faster :) | 23:21 |
| plars | the new phablet-tools has that - basically wiping home so that we get a cleaner system between boots | 23:21 |
| asac | plars: protects us from what kind of things? | 23:21 |
| plars | asac: gremlins | 23:21 |
| asac | plars: ok. but i dont think its all hands on deck pririoty :) | 23:21 |
| asac | its not fixing a critical bug like the adb | 23:22 |
| plars | asac: it's not, but if we're already respinning the build, and have an automation branch that depends on it, it's easier to land it tonight while I'm here and it's fresh on my mind and I'm waiting on the next build to watch the results anyway | 23:22 |
| asac | plars: so you can test it with an existing image? | 23:23 |
| asac | otherwise it doesnt really help i guess | 23:23 |
| asac | and risks our test run | 23:23 |
| plars | asac: I could test it locally, and the risk is lower if all of it is fresh on our minds | 23:24 |
| plars | asac: I could even test it on the server if we have a gap still before the next image comes, just we might still get the adb_open stuff | 23:24 |
| asac | landing all at once with a tired mind sounds risky. first time i heard about landing uitah update to use new phablet-flash | 23:24 |
| asac | plars: anyway. your call :) | 23:24 |
| asac | you are the one who suffers, because i am off soonish :) | 23:25 |
| asac | happy to see this go in etc. | 23:25 |
| asac | just scared to wake up with psivaa not able to poke the image | 23:25 |
| plars | asac: it depends on timing - if it looks like it's going to land too close for me to ensure it doesn't break something, I'm waiting | 23:25 |
| asac | yeah | 23:25 |
| plars | asac: but we have to take windows when we can to roll these things into production | 23:25 |
| plars | asac: there is always a next build coming | 23:25 |
| asac | i trust you make a good decision. as long as we have spare phones still on standby we can at least risk something | 23:25 |
| asac | plars: yeah, but if we miss a build, we dont know if our landings so far broke it | 23:26 |
| asac | and we cant risk more in next landing batch | 23:26 |
| asac | wanted to have a big landing batch tomorrow :) | 23:26 |
| asac | plars: we have busted our infrastructure more than once. cant we have a fresh day to look at that and then do it :)? | 23:27 |
| asac | but anyway | 23:27 |
| asac | just my preference | 23:27 |
| asac | i will survive whatever i guess | 23:28 |
| asac | if you feel its well tested etc. and ready :) | 23:28 |
| asac | sergiusens: otherwise i have listed phablet-tools for tomorrow to be picked up when it built by us | 23:29 |
| asac | plars: sergiusens: give me a heads up when you know more | 23:29 |
| asac | cu | 23:29 |
| sergiusens | asac, not sure I got that entirely, the part of 'know more'... which I guess is adb related | 23:31 |
| asac | sergiusens: lost backoog | 23:33 |
| asac | backlog | 23:33 |
| asac | sergiusens: nevermind. we will pick it up tomorrow from the misc stack and land it. then land the utah changes with a fresh eyes | 23:35 |
| plars | yeah, the image came out before phablet-tools | 23:56 |
| plars | doanac: we'll land all that stuff in the morning after we have a good build | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!