#ubuntu-ci-eng 2013-11-01 <ogra_> Laney, http://reports.qa.ubuntu.com/smokeng/trusty/touch/ has the feedback ;) <ogra_> (your #9 build was the best one we had in a long time) <ogra_> psivaa, looks like gallery didnt run again on maguro <ogra_> (and unity8 fails still the same way on mako) <psivaa> ogra_: i'll take a look at them <ogra_> thanks <popey> ogra_: #10 seems good here <ogra_> popey, havent done calls/sms yet,. but from what i see atm here too ... <ogra_> to sad the fix didnt work though <ogra_> (which apprently was the only change vs #9) <popey> calls/sms work fine here <popey> â¹ <ogra_> yup, looks fine here too <ogra_> if we could get the dashboard a bit greener i would actually propose to promote this <psivaa> ogra_: re: unity8 failures on mako, there was a new upload to unity (7.83+14.04.20131031-0ubuntu1) but it dint fix the issue apparently <psivaa> Mirv: ^ <ogra_> psivaa, yeah, see whay i wrote above :) <ogra_> *what <psivaa> ok, known then :) <ogra_> well, probably not by Mirv yet :) * josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: josepht | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - <fginther> morning <plars> balloons: a couple of things you might be interested in: 1. I got clock to finally pass today on maguro after a rerun, it's been failing for a while, includeding the first time it ran on image 10 <plars> 2. weather is failing some extra tests on mako - even after rerunning, I'll try again but that's kinda strange <ogra_> plars, psivaa, did anyone try to re-run munity8 on mako yet ? <ogra_> the image looks so good, would be a shame to not promote it ... <ogra_> but i dont want to with these unity test results <plars> ogra_: I can, did we expect it to be fixed now? <ogra_> plars, yes, apparently it didnt suffice though <plars> ogra_: I'm restarting it now <ogra_> Mirv was pinged about it above <plars> ogra_: but it looked the same on the custom image with mako also <plars> ogra_: so I suspect it's still broken <ogra_> (probably we should also poke Saviq ) <ogra_> yeah <ogra_> me too <plars> ogra_: failures are still the same <plars> ogra_: after the rerun <ogra_> *sniff* <ogra_> plars, how is the house btw ? <ogra_> all dry again ? <plars> ogra_: mostly, we came out ok. Some people not far from us were stuck in trees, on rooftops, etc <plars> we are up high enough that it wasn't so bad <ogra_> ugh <plars> ogra_: also we are a bit farther away that they are from the creek that got to 19 feet above flood level <ogra_> wow <plars> (about 5.7 meters for the metric folks) <ogra_> yep, my brain turned into ~5m :) <ogra_> we have that in the east of germany regulary every year since a few years ... <ogra_> and it seems to be higher with the years <ogra_> (and didnt occur at all 20years ago) <plars> ogra_: yeah, it comes in cycles. Nearest similar flooding in my immediate area was in 1925 or somthing like that <ogra_> yep <ogra_> well, i guess the water from the melting ice caps has to go somewhere ... and if it isnt the sea it is the atmosphere <sergiusens> heh, we get a bit of rain here from time to time and some areas with very little go up to 3m (it never rains here) <fginther> josepht, want to help review? https://code.launchpad.net/~fginther/cupstream2distro-config/core-apps-trusty/+merge/193612 <josepht> fginther: sure <doanac> plars: i just noticed our unity8 touch test still installs the unity8-autopilot package. is that really needed? <plars> doanac: iirc we needed that to bring in some dependencies right? <doanac> sergiusens: you remember? ^^^ <plars> doanac: but in reality, it's going to run the tests out of the click-test-setup installed bits since they are in the python path <doanac> plars: that's true, so it might just be to pull in some other dep <doanac> someone should thank thomi_ for making autopilot add ./ to the python path. its probably saved a lot of tech support questions over the years :) <thomi_> doanac: :) <doanac> thomi_: its quite hard to work around my ignorance - it knows no bounds! <thomi_> heh <Saviq> plars, ogra_ the known issue is fixed indeed - not sure yet what's the new thing (it only started happening yesterday or so that all the test started failing) <Saviq> obviously non-reproducible locally :/ <plars> Saviq: it seems to only happen on mako and not maguro though <ogra_> Saviq, and restricted to mako <Saviq> ogra_, yeah <Saviq> it's aborting somewhere in Mir, nothing obvious, though :/ <ogra_> maguro is probably just to slow to notice any breakage :P * retoaded changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: leworks | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - <plars> ogra_, Saviq: I think I have the tests working locally on mako... no idea why it was a problem on mako and not maguro, but it appears related to the screen not being on properly <ogra_> yeah, i said that yesterday <plars> we used to turn it on earlier, but were asked to quit doing that because there was some suspicion that it was causing some sort of powerd problem iirc <plars> ogra_: ok, I missed that conversation I guess, sorry <thomi_> fginther: Anny ideas what happened here? http://636-721-3251:8080/job/autopilot-testrunner-otto-trusty/279/console <ogra_> plars, yeah, that was easy to miss ... and totally out of your TZ anyway (in my morning) <fginther> thomi_, sorry, I can't take a look now. please see if cihelp can <thomi_> fginther: no worries. <plars> ogra_: do you have any ideas on how to really make sure the screen gets turned on? doanac had previously made a change to do this sooner after the boot, and I think that was pretty effective but iirc asac wanted us to turn that off. It seems like somtimes using powerd-cli to turn the display on after it's timed out already doesn't work <ogra_> no, i dont really know anything else but powerd-cli <ogra_> and i dont know why that was ripped out instead of fixing the apparent race <thomi_> cihelp: can someone help me figure out how CI runs the Ap tests for the ubuntu-clock app? <ogra_> since it clearly breaks us now <thomi_> cihelp: The specific problem is that ubuntu-clock-app isn't in the archive it seems <plars> ogra_: I think even if the timeout is configurable somehow, that would do the trick <plars> thomi_: hmm, isn't that one that we run as click now? <ogra_> yes, but thats a feature thats still missing <thomi_> plars: could be. If so, how do I configure that in http://636-721-3251:8080/job/autopilot-trusty-master ? <thomi_> or maybe I can't? <plars> thomi_: ah, I thought you meant the image tests, sorry <thomi_> no worries <plars> ogra_: so running everything locally on my mako all passes, even if I run it the same way we run it in smoke testing, provided I make sure the screen is on <ogra_> right <plars> ogra_: do you know if anyone is working on a configurable screen timeout? <ogra_> so we should probably add the code that does this back ... even if we have to rip it out next week again <ogra_> it is a supposed feature of the shell <doanac> thomi_: probably should ask fginther, but it almost looks like in that test it shouldn't matter if its click or not <ogra_> so i would expect someone to work on this, yes <thomi_> doanac: but it fails because it can't install ubuntu-clock-app package <thomi_> doanac: http://636-721-3251:8080/job/autopilot-testrunner-otto-trusty/279/console <doanac> thomi_: isn't it in the archive that gets copied over: http://636-721-3251:8080//view/mediumtests/job/generic-mediumtests-builder-trusty-amd64/296/artifact/*zip*/archive.zip <thomi_> doanac: so I don't have to specify it? <thomi_> I was just copying the deps from debian/control <doanac> thomi_: not sure. i'm surprised it failed. if you look at the ubuntuuitoolkit job that ran before that (job 278) it did something similar and worked <thomi_> doanac: yeah, but the sdk *is* in the archive :) <thomi_> doanac: it's OK, I'll mess around with it some more <elopio> hey ci team, all tests failed in mako here: <elopio> https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/2947/consoleFull <elopio> any idea why? <elopio> oh, nevermind. Tests are running again. I'll let you know if it fails again. <cjohnston> elopio: looks like a test failed to me <elopio> cjohnston: all tests failed. when that happens, just in one of the environments, it's more likely an environment issue. <om26er> this machines is running low on disk space, can anyone look into that ? <om26er> http://636-721-3251:8080/computer/ps-generic-precise-amd64/? <om26er> ci ^ (incase anyone have that for a highlight) <cjohnston> om26er: ping the vanguard <om26er> cjohnston, he is not online it seems <om26er> actually <cjohnston> retoaded: you should probably use your nick as 'vanguard' <om26er> retoaded, ^ <om26er> Saviq, ^ * retoaded changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: retoaded | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - <retoaded> cjohnston, thought I had. apparently something else was in mouse memory <retoaded> om23er ps-generic-precise-amd64 is a vm but I will take a look <Saviq> retoaded, whatever's happening, jobs for that machine are blocked http://636-721-3251:8080/job/generic-land/ <Saviq> retoaded, there's a job running for 2 days now, too <retoaded> Saviq, ack <Saviq> http://636-721-3251:8080/job/generic-covlpsync/1394/console <Saviq> retoaded, thanks <retoaded> Saviq, 70% of the disk space on that VM is sitting in /tmp; do the jobs not clean behind themselves? <retoaded> Saviq, used disk space that is <Saviq> retoaded, no idea <retoaded> Saviq, space is freed up and the node is processing jobs again <elopio> ci team, what does this failure mean? https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-maguro/2902/console <elopio> remote object '/.setup_complete' does not exist <elopio> SETUP FAILED - CAN'T CONTINUE <cjohnston> elopio: there was a an issue installing packages so it needs to be rerun <retoaded> elopio, looks like it failed to resolve ports.ubuntu.com <elopio> so, just rerun, ack. <elopio> thanks cjohnston, retoaded. <cjohnston> elopio: /11 <cjohnston> elopio: sorry. nvm <elopio> np/ <plars> ogra_, Saviq: ok, I'm pushing a change to move the display-on stuff again right now, and I'll rerun those unity8 tests <ogra_> awesome <plars> ogra_: the world just got a little greener: http://reports.qa.ubuntu.com/smokeng/trusty/touch/ <plars> ogra_: we see this hud-service crash there now though <plars> but that's known I think <Saviq> plars, awesome, thanks * retoaded changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - <thomi_> cihelp - I seem to be seeing some otto errors, and I don't understand the errors: http://636-721-3251:8080/job/autopilot-testrunner-otto-trusty/295/console <cjohnston> thomi_: E: Unable to locate package ubuntu-clock-app <thomi_> cjohnston: doh! I just saw the otto message <thomi_> ugh, thanks #ubuntu-ci-eng 2013-11-04 <sil2100> jibel, vila, Mirv, asac: hi! <sil2100> jibel, vila, Mirv, asac: I see that the otto cu2d check jobs are failing again with the Could not resolve 'archive.ubuntu.com' error <sil2100> Do anyone of you know what's up with that again? New DNS issues? <sil2100> retoaded: ^ <vila> sil2100: url ? <sil2100> For instance, http://636-721-3251:8080/job/autopilot-trusty-daily_release/396/label=qa-intel-4000/console <sil2100> On both nvidia and intel <Mirv> sil2100: hi! <sil2100> (so http://636-721-3251:8080/job/autopilot-trusty-daily_release/396/label=autopilot-nvidia/console as well) <vila> /var/log/syslog: Nov 4 00:08:25 trusty-i386-20131104-0008 kernel: [86262.203773] type=1400 audit(1383523705.376:356): apparmor="DENIED" operation="open" info="Failed name lookup - disconnected path" error=-13 parent=26433 profile="/sbin/dhclient" name="etc/ld.so.cache" pid=26437 comm="dhclient" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 <Mirv> sil2100: I don't know what's up this time, but the archive.ubuntu.com is not (again) reachable from magners either so maybe some firewall reconfiguration again? <sil2100> Mirv: yep, apparmour issues again... <sil2100> vila: what did we do last time to fix this actually...? ;) <vila> Mirv: wget archive.ubuntu.com works <vila> Mirv: works from magners, that's the only reliable check I know of, forget the others <sil2100> As we had this before, exactly the same issue I gues <Mirv> vila: ah, you're right, the firewall apparently just blocks ping <vila> Mirv: yes, for unknown IS reasons (probably good ;) <Mirv> vila: ping works from my own machine so I didn't think it'd be different. but right, so apparmor agian. <vila> Mirv: yes, I learned it the hard way too <sil2100> Everything is crimson red because of this sadly <vila> sil2100: probably not exactly the same, related to apparmor again though <vila> sil2100: same root cause as far as CI is concerned: a user job breaks the infrastructure because otto *requires* host and lxc to be up to date <sil2100> vila: *sighs* <vila> sil2100: yeah, don't tell me ;-/ <vila> sil2100: not to mention all upstream-merger are stucked :-/ <vila> sil2100: so, back to what was done last time: ping stgraber, he's the most efficient to diagnose the lxc/apparmor issues lately <veebers> vila: another question for you. I'm getting this error on the generic-mediumtest-runner-mako: qmlscene: could not find a Qt installation of '' <vila> sil2100: may be check if some updates occurred on apparmor or lxc ? <vila> veebers: you want to talk to autopilot devs to provide us a better error message ;) <vila> veebers: that's not the first time I see this undecipherable one <veebers> vila: heh, what I'm wondering is why /usr/bin/qmlscene doesn't work on that device? <veebers> that is the direct error message from running /usr/bin/qmlscene -testability /path/to/qml/file <vila> veebers: I didn't track what caused it the previous times sorry :-( <veebers> it works find on my device after a phablet-flash <sil2100> vila: will do ;) <vila> meh <vila> sil2100: not to mention all upstream-merger *maguros* are stucked :-/ <jibel> vila, sil2100 from networking.log dhclient: error while loading shared libraries: libc.so.6: cannot open shared object file: Permission denied <vila> jibel: even worse ;) <jibel> vila, can you downgrade the kernel and see it makes the error go away? <jibel> on the host <vila> jibel: not yet, I'm restoring access to upstream merge maguros <jibel> vila, sil2100 this problem start on Nov. 1rst with kernel 3.12.0-1, rebooting with 3.11.0-12.19 should work. If it does ping the kernel team <didrocks> good morning <didrocks> sil2100: Mirv: psivaa: popey: meeting time! <psivaa> didrocks: joining <didrocks> sil2100: just waiting for you now ;) <didrocks> sil2100: not around? you shouldn't suffer from jet lag <sil2100> Crap! <sil2100> I got used to NOT having the meetings <Mirv> didrocks: the build probs should be have a mention at https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dHFtUmlPOUtCRk8zR2dtaEpIbUVhMmc#gid=3 <sil2100> jibel, vila: we had the same issue last time with dhclient <sil2100> jibel, vila: I remember dhclient had problems also loading libc <jibel> sil2100, right but can you try to boot kernel 3.11, the incident began with 3.12 then notify the kernel team? <Mirv> sil2100: vila: I checked the other uploads and there are no dbus/lxc/apparmor uploads, so as jibel says downgrading the kernel would seem the first thing to try <ogra_> === Image #10 promoted === <didrocks> \o/ <ogra_> popey, promoted 10/20131031.1 <ogra_> === Image #11 building === <didrocks> great! <ogra_> hmpf ... compiz doesnt get the layer ordering right anymore ... funny ... all menus, tooltips and popups are behind all other windows ... even pulldowns in the browser <sil2100> \o/ <popey> ogra_: super <didrocks> vila: hey! I tried to get in touch with doanac and it seems you didn't tell him that the execution test service should use the same parameters than the otto jobs? <didrocks> vila: do you take care of explaining what every parameters do or should I? <vila> didrocks: err, surprising... <didrocks> vila: you meant, you talk about them with him? <vila> didrocks: unless you mean the parameter *names* were different, I'm pretty sure the discussions mentioned them all <didrocks> vila: names and syntax are different <didrocks> like the tests is not the command running autopilot tests <vila> right, but the features are there right ? So it should be a matter of adapting both sides to agree no ? <didrocks> vila: well, that's what I discussed with you. That we can quickly plug that in and so adapt the parameters to what we have for now <didrocks> the semantic for some parameters are unfortunately different, I see a bigger road block on that one <vila> didrocks: right, so, since I don't know enough of the specifics on both sides to act as a proxy, better get in touch directly. In the midlle/long term though, I think we want to better separate setting up the environment and running the tests, it seems weird to have to implement the later differently in different tools <didrocks> vila: interesting, not sure why we had that meeting where I needed to explain to you all parameters though. Will talk with him directly then <vila> didrocks: so that I start to understand how cu2d works, I didn't have the same one with doanac and I thought the parameters and their intent were clear enough for him to ensure it will be providing the same semantic <didrocks> no worry, I'll fix that with him directly. I may have misunderstood the goal of this meeting apparently <vila> didrocks: I reported that meeting to the whole team and we even had a session were we discussed it... <vila> didrocks: correction, wasn't the whole team but only doanac and fginther <didrocks> ok <vila> didrocks: notes here https://docs.google.com/a/canonical.com/document/d/1ISclO4aN2CQ2vJ5PeryF2gt81lqX-5_-mmGADNrK04o/edit#heading=h.3nv3w86usggi but further work hasn't been tracked there :-/ <vila> didrocks: so the overall feedback *I* got was that the features were ready or almost ready and my understanding was that some tweaks were required to have matching parameters. But I wasn't involved in the testing/coding so I din't (still don't) know the exact state. <didrocks> vila: I just opened the proposed job that was told ready and didn't see any evolution on the parameters <didrocks> compared to when we first discussed about it <vila> :-/ <ogra_> === Image #11 done === <didrocks> greatness! <didrocks> sil2100: http://bazaar.launchpad.net/~ubuntuone-hackers/ubuntu-download-manager/trunk/revision/151 can you SRU just that commit please? <didrocks> to saucy <didrocks> this is to avoid getting people on saucy in trouble <didrocks> (for the next 2 weeks) <didrocks> sil2100: old landing ask 266 (it's the short term fix) <sil2100> didrocks: ACK <sil2100> didrocks: ok, I see it's in saucy's trunk, so I guess I can use cu2d to get it in, right? There is only this commit in saucy trunk waiting for release <popey> ogra_: #11 I can't make phone calls. I can receive though <ogra_> popey, ouch <popey> hmm, cant send texts either, wonder if I have run out of credit <sil2100> didrocks: anyway, taking care of that this instance <didrocks> sil2100: just do what you prefer :) <vila> sil2100: qa-intell-4000 back to previous kernel, seems like otto is happy (minus the fact that it's supposed to always run in sync with the latest kernel....) <sil2100> vila: \o/ <vila> sil2100: I tweak /etc/default/grub and that will need to be reverted when you have a fix <vila> *tweaked <sil2100> vila: well, at least we have tests running, too bad that with not the latest kernel but we'll switch to that once it's fixed properly <vila> sil2100: or otto_setup is run and breaks again... I think my tweak is not robust enough against that <popey> ogra_: phew, credit ran out <ogra_> phew <popey> ogra_: #11 seems good on mako <ogra_> great, still upgrading here <vila> sil2100: dx-autopilot-nvidia also reverted (with a better tweak also applied to qa-intel-4000) <sil2100> vila: will it still get broken again when otto_setup is ran? <vila> sil2100: a job spontaneously triggered on qa-intel-4000 which served as a test, can you trigger one for nvidia ? <vila> sil2100: it should stay on the same kernel but hey, we're in production, I couldn't test as much as I'd like there <sil2100> Let me trigger a quick one <vila> sil2100: so we'll need to revert the line added in /etc/default/grub, I've put a comment there so that should be easy * vila lunches & <sil2100> Thanks! :) <sil2100> Running the test run in the meantime <ogra_> popey, maguro seems fine on image 11 <ogra_> (well SMS and calls do) <sil2100> vila: all works ok it seems \o/ <ogra_> BAH ! <ogra_> all unity8 tests fail again on mako <ogra_> this is getting tiring :( <sil2100> Mirv: https://code.launchpad.net/~sil2100/cupstream2distro-config/click_stack_for_saucy/+merge/193753 <- can you take a look? We created a saucy branch for this one <psivaa> ogra_: i think plars pushed a fix for turning the screen on for unity8, still failing, the reason appears different. could be temp, i am rerunning <ogra_> psivaa, yeah, i remember the fix worked in image #10 <psivaa> ogra_: yes, the error message is different this time compared to the failures pre image 10 <psivaa> ohh no some of them are the same :( <ogra_> the pattern looks the same at least <psivaa> yea <psivaa> there is a powerd crash in the runs with image 11 that i dont remember seeing with 10 <psivaa> and the fix is using powrd-cli so that may explain why that dint work <ogra_> yeah <ogra_> do you run powerd-cli as root ? <ogra_> iirc you need to <Mirv> sil2100: ok <psivaa> ogra_: powed-cli is running in the device now, but not sure if that was running whilst unity8 tests were running. will watch that <sil2100> hmmmm <sil2100> Mirv: good catch! Modified * josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: josepht | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - <Mirv> sil2100: top-approved now. <sil2100> Mirv: thanks! <plars> psivaa: odd, I got it to pass just fine on Friday <ogra_> plars, yeah, i wonder if the code was reverted or somethign <psivaa> plars: i think the issue is powerd crash this time but still yet to rerun <plars> I'll take a look <psivaa> waiting for all the tests to complete <psivaa> plars: ack <plars> ugh, more rain <sil2100> didrocks: do you know if we're dropping powerpc support in overall? <sil2100> Like, completely? <fginther> morning <sil2100> Morning <cjwatson> sil2100: No <sil2100> cjwatson: ok <sil2100> Then I guess I'll have to revert robru's change in libunity-webapps <cjwatson> Uh <cjwatson> You said "completely" which is a very broad question <cjwatson> It may be correct to drop it in specific cases where it wouldn't be buildable anyway <sil2100> cjwatson: well, here it would mean that suddenly unity7, bamf, and many many unity components would have to disappear for powerpc ;) <cjwatson> I don't know about the case of libunity-webapps <cjwatson> It's generally best to keep things Architecture: any unless there's a strong reason otherwise <cjwatson> Do you mean the webbrowser-app dependency? <cjwatson> You could always make that architecture-specific <cjwatson> i.e. Depends: webbrowser-app [amd64 armhf i386] Suggests: webbrowser-app [!amd64 !armhf !i386] <cjwatson> Or actually just drop the Suggests part of that, I guess, since it's unsatisfiable anyway <sil2100> Actually, we were already Suggests webbrowser-app to workaround this <cjwatson> Yeah, but now you want to hard-depend on it on architectures where it's available <cjwatson> Just Depends: webbrowser-app [amd64 armhf i386] would be fine for that <sil2100> Right, or webbrowser-app [!powerpc] I guess? <cjwatson> No <cjwatson> We have more than four architectures <cjwatson> It's more correct to specifically enable it on the architectures where we know webbrowser-app is available <sil2100> Yes, but we only ban it from this one particular? <cjwatson> But that would be wrong! <sil2100> Ok ok <cjwatson> webbrowser-app | 0.22+13.10.20131011.1-0ubuntu1 | trusty | source, amd64, armhf, i386 <cjwatson> Which does not include arm64 ... <cjwatson> Nor the further architecture we'll be adding in the next couple of months <sil2100> Right, but I guess it will be supported as soon as it's possible, so then we'll have to update the package again, right? <cjwatson> arm64 doesn't work right now for the same reason powerpc doesn't work <cjwatson> i.e. v8 not ported <cjwatson> No particular reason to expect either one to work before the other AFAIK <sil2100> Ok, I'm fine with any solution, just wanted to find the one that would be less troublesome to maintain :) <sil2100> But I guess this will be the correct one here <cjwatson> It makes more sense from an archive point of view to enable the dependency only where it's specifically available <cjwatson> Hopefully the v4 interpreter in Qt 5.2 will be more portable <sil2100> Thanks for the pointers! <cjwatson> (It's supposed to be, from what I hear) <plars> ogra_, psivaa: given how good the custom image looked at http://636-721-3251:8080/view/Touch/view/Ubuntu%20Touch%20Master%20Jobs/job/trusty-touch_custom-mako-smoke-master/ I'm surprised unity8 and webbrowser had problems on the mako image. I'm rerunning now, expect they will pass <plars> unity8 is looking fine for me locally so far <ogra_> well, lets see how the next image behaves ... probably a temporary glitch <plars> ogra_: is 12 building now? <plars> ogra_: I just restarted some tests on 11 <ogra_> plars, nope <ogra_> earliest after the next meeting <plars> ogra_: ok, I'll keep pushing on 11 then :) <plars> ogra_, popey: unfortunately we started having to handle a LOT of extra device-not-found errors, which mostly seem to be attributed to the mtp/adb conflict <ogra_> plars, the lxc-android-config package with the new upstart job from sergiusens is the first step towards fixing this <sil2100> cjwatson: could you maybe review this branch (if you have a minute and the permissions), since the upstream dev is not around right now: https://code.launchpad.net/~sil2100/libunity-webapps/webbrowser-app_depends_arch/+merge/193785 <ogra_> (uploaded today) <plars> popey: but if you look at the results of filemanger, it seems to always be up and down between 3 or 4 failures and 19 or 20 failures <plars> ogra_: that's good to hear :) <cjwatson> sil2100: I added an Approve review, but it shows as "(community)" so it probably doesn't count for landing <cjwatson> It can serve as your core-dev +1 though :) <sil2100> ;) <sil2100> Thanks! <doanac> vila, didrocks: let me know how we should resolve the parameters for this thing. I think we are already close to a 1-to-1 mapping of the parameters, but i need to know if theres something big missing <didrocks> doanac: sure, want to chat about it? <doanac> didrocks: sounds good. how about in 8 minutes? (half past the hour) <didrocks> doanac: good for me as well :) <vila> Mirv: <mlankhorst> vila: enjoy, I found a fix for glamor-egl :P <vila> <mlankhorst> https://bugs.freedesktop.org/attachment.cgi?id=88619 <doanac> didrocks, vila: i'll create a hangout for us <doanac> vila, didrocks: http://636-721-3251:8080/job/trusty-touch-mako/17/ <doanac> vila, didrocks: http://636-721-3251:8080/job/autopilot-trusty-daily_release/302/parameters/ <didrocks> doanac: vila: http://636-721-3251:8080/job/autopilot-trusty-daily_release/201/label=autopilot-nvidia/console <balloons> ping fginther <tedg> It seems that dbus-test-runner is configured to do CI on Quantal as well as Trusty. <tedg> Does anyone know why that could be? <tedg> http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/view/head:/stacks/head/qa.cfg#L98 * josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - <plars> didrocks: no landing meeting? <tedg> ev, Where should I file the bug that errors.u.c misspells "optimized" in "optimized out" ? <didrocks> plars: oh sorry, we told no meeting today, will resume tomorrow afternoon * ogra_ will be late, running meeting is running over <plars> didrocks: I missed that I guess, sorry <ogra_> oh, cool <didrocks> plars: I missed to ping you, my fault, sorry ;) <didrocks> I pinged the others :) <psivaa> plars: are you doing anything with the smoke maguro in the lab, can i rerun filemanager and gallery? <psivaa> balloons: we are still seeing filemanager test failures due to too many entries in /home/phablet/ . <plars> psivaa: go for it, I've mostly been focusing on mako at the moment <psivaa> plars: ack <balloons> psivaa, we're still trying to land a couple mp's to work on this.. <balloons> psivaa, https://code.launchpad.net/~vthompson/ubuntu-filemanager-app/fix-carlos-model/+merge/193783 <psivaa> balloons: ack, thanks :) <balloons> psivaa, the paste bug is fixed by that.. then I can land my big branch <balloons> and then hopefully it's all fixed :-) <cjwatson> FYI: publisher down pending investigation of I/O errors * fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: fginther | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - <fginther> josepht, any vanguard work I should know about? <josepht> fginther: not a thing <fginther> balloons, pong <fginther> alesage, do you know why dbus-test-runner is still configured to build on quantal? <alesage> fginther, no sir <alesage> fginther, propose to amend <fginther> alesage, ack, I'll drop it, tedg is hitting build failures to do it <alesage> fginther, thank you <balloons> fginther, https://code.launchpad.net/~vthompson/ubuntu-filemanager-app/fix-carlos-model/+merge/193783. qt5-proper ppa doesn't have a trusty build, but the virtual test enviroment is using it <fginther> balloons, looking <tedg> fginther, thanks! <fginther> tedg, your dbus-test-runner MP is passing now <fginther> balloons, https://code.launchpad.net/~vthompson/ubuntu-filemanager-app/fix-carlos-model/+merge/193783 is passing now <balloons> fginther, ty sir :-) <tedg> Great! Thanks fginther! <veebers> fginther: hey how are you, query: Would you know why `/usr/bin/qmlscene` works on my local device but doesn't on the jenkins devices? i.e. I'm getting this error: qmlscene: could not find a Qt installation of '' <fginther> veebers, hi, it could be missing a qt plugin dependency <fginther> veebers, what job is this? <veebers> fginther: this is an example: http://636-721-3251:8080/job/generic-mediumtests-runner-mako/2987/artifact/results/autopilot/sudoku_app_results.xml <fginther> veebers, when you run them on your device are you using the deb packages to install and test? <veebers> fginther: In my test last night yes. But I've just re-flash my device so I'm going to try something <veebers> fginther: on my locally freshly flashed device when running `/usr/bin/qmlscene` I don't get that error <fginther> plars, is there a reason sudoku_app tests are not run for the smoke testing? <plars> fginther: I think just nobody asked for them <plars> fginther: Are there tests that work? <fginther> plars, so far they don't <plars> fginther: then that's probably why nobody asked for them :) <plars> popey: can't seem to get filemanager down under 10 failures on mako, but on maguro it only had 3 today <plars> also weather app is considerably worse under mako for some reason <xnox> is there a bug tracker for CI infrastructure issues? <xnox> (bug reports / wishlist items / etc?) <robru> fginther, can you check why jenkins didn't run here? https://code.launchpad.net/~justinmcp/unity-chromium-extension/mediaplayer-init-fix/+merge/193549 guy's a new employee, might need to be added to some kind of whitelist? <fginther> robru, yep, that's probably the case, I'll get the list updated <robru> fginther, thanks <robru> fginther, what's the recommended way of handling community-submitted branches? obviously jenkins can't run on them by default, but is there some one-off way of saying 'jenkins should run for this one branch'? <robru> or do i have to steal the branch and take all the credit with my own MP? <fginther> robru, the only way to do this right now is to manually trigger the job from the jenkins UI <robru> fginther, hrm, can you link me to that part of the jenkins maze? <fginther> robru, you need to find the ${lp_project}-ci job here: http://636-721-3251:8080/ <fginther> robru, for example: http://636-721-3251:8080/job/unity-chromium-extension-ci/ <robru> fginther, ahhhh, that's a different jenkins! I don't have a login to be able to kick jobs there <fginther> robru, if you create one, I'll add build permission <robru> fginther, oh, hrm, it says 'robru' is taken, but doesn't have any kind of password recovery button... <fginther> robru, I can reset it <robru> fginther, ok, thanks. for the cu2d jenkins that one just lets me sign in with SSO... <fginther> robru, you should be setup now <robru> fginther, great, thanks! <fginther> robru, when building the -ci job, you'll need to supply the landing_candidate (the lp:blah branch name) and the merge_proposal (the URL of the MP in launchpad) * fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - #ubuntu-ci-eng 2013-11-05 <Saviq> cihelp <Saviq> hey, anyone - seems all maguros are down http://636-721-3251:8080/job/generic-mediumtests-runner-maguro/ ? <Saviq> ah, they're being flashed are they... <Saviq> it seems the flash process has failed, then... <Saviq> http://636-721-3251:8080/job/touch-flash-maguro-014E058C18015006/183/console <doanac> Saviq: i don't have access to those systems. I'm going to email the ci mailing list and hopefully someone can get them online <Saviq> doanac, thanks, it might be that the image is completely b0rked or something, if all of them fell down <veebers> doanac: oh hey, can you add to your email that I've modified http://636-721-3251:8080/job/generic-mediumtests-trusty-touch/ -> I removed generic-mediumtests-runner-maguro from the queue <doanac> veebers: shure <veebers> doanac: awesome thanks <Saviq> veebers, so new jobs will pass? <Saviq> veebers, or at least ignore maguro? <veebers> Saviq: well, new jobs won't use the maguro runner so will get further <veebers> Saviq: yes :-) <Saviq> veebers, that's useful, thanks * Saviq cancels all the hanging unity8 jobs <veebers> Saviq: we will either have to kill the current jobs or wait for them to timeout <veebers> Saviq: heh <Saviq> veebers, how long the timeout? <Saviq> veebers, they've been at it for 10hrs now or something... <veebers> Saviq: ugh right, not sure but 10 hours is too long <Saviq> veebers, yeah.... <Saviq> doanac, FWIW, I'm not sure ssh alone would've helped in that case... there's no adb to the devices (as a result of failed flashing), so unless they're stuck in bootloader, and willing to listen to fastboot reboot, they need physical intervention... <Saviq> doanac, there was talk of a supposedly standard 3.5mm jack contraption for low level access to the hardware <doanac> Saviq: usually i just see devices stuck in the bootloader. ie - i haven't seen to many stuck <Saviq> doanac, do they then accept `fastboot reboot` and such? <doanac> Saviq: i normally just do a "fastboot reboot" and it boots <Saviq> doanac, right <doanac> note: if its really stuck, a serial console might not be much help either <doanac> you really need to be able to hold the power button down somehow <Mirv> FYI I've been doing the needed hoops to transition to libmirserver10 this morning <sil2100> 10 already? <sil2100> How time flies... <sil2100> At least all the FTBFS problems right now seem to be related to the mir transition... <Mirv> sil2100: not all <sil2100> Right, unity7 and indicators are still real problems * psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: psivaa | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - <Mirv> sil2100: indicators not, should be hopefully fixed now, but mir unity-system-compositor + unity7 yes <sil2100> Mirv: is unity8 stack ready for re-build? It was failing because of libunity-mir-dev : Depends: libunity-mir1 (= 0.1+14.04.20131104-0ubuntu1) <sil2100> Mirv: well, there was a chroot problem besides the mir transition problem in indicators, but I guess that got fixed with the subsequent run <sil2100> Mirv: so it wasn't just mir problems in indicators ;) <sil2100> Mirv: for unity7 I'm still waiting for updates from bregma <Mirv> sil2100: it's not failing because of unity-mir, but because unity-mir FTBFS <didrocks> thomi_: not sure if you are around, but can we proceed with step 1, are you ready for transitioning to 1.4 tomorrow? <Mirv> hi didrocks! <didrocks> hey Mirv! <sil2100> Hi didrocks! <didrocks> morning sil2100 :) <Mirv> didrocks: we've a problem with mir again I think. I've been rebuilding stuff to transition to libmirserver10, but unity-system-compositor and unity-mir FTBFS against it (bugs filed) <didrocks> Mirv: Mir was pulled to trunk? <Mirv> didrocks: so it'd be the usual deadlock, can't publish, can't rebuild <sil2100> Mirv: oh, I see now that unity-mir looks like a 'real' compilation problem, missing/removed include it seems? <didrocks> without warning us? <Mirv> didrocks: I guess so, new commits in there <didrocks> Mirv: please revert trunk <didrocks> and remove everything from the ppa that built against it <sil2100> Mirv: did you fill in the bugs to "Stack status" ? <Mirv> sil2100: yes <Mirv> didrocks: ok <sil2100> Oh, it might not be needed soon <popey> didrocks: AIUI thomi_ was travelling yesterday so wasn't online, and won't be until ~20 UTC <Mirv> didrocks: I need to somehow find what the trunk used to be before the pull <didrocks> popey: ok, thanks :) <popey> np <didrocks> Mirv: you do have that info, right? the changelog + merge back should point to a rev? <Mirv> didrocks: sure * ogra_ -> coffee ... brb * Mirv removed hud, indicator-location, mir, platform-api, qtubuntu, ubuntu-keyboard, unity-mir from PPA <sil2100> ;/ <didrocks> popey: coming? <popey> ya <popey> stupid browser <xnox> didrocks: Hello! =) i made a merge proposal, and the merger is test-building my package against "trusty", but i need "trusty-proposed" enabled as well. <didrocks> xnox: you mean about the upstream merger, not daily release, right? <xnox> didrocks: i believe so, yes. Let me get URL. <xnox> https://code.launchpad.net/~xnox/ubuntu-keyboard/libpinyin4/+merge/193859 <xnox> and <xnox> https://jenkins.qa.ubuntu.com/job/ubuntu-keyboard-ci/210/ <didrocks> xnox: ok, yeah, upstream-merger: that would be for vila or fginther I guess ^^ (cu2d is using -proposed enabled) <vila> didrocks, xnox: We'll need fginther indeed :-/ But I'm surprised that -proposed is not enabled, that would diverge from cu2d and will break far more often no ? <didrocks> vila: IIRC, it's indeed not enabled. There were strong argument in both cases <didrocks> in practice, enabling -proposed isn't too much troublesome for cu2d, so I guess it won't for upstream merger <cjwatson> well, clearly needs to be *possible* to enable it at least <didrocks> but we still need a way to enable/disable it easily <didrocks> yeah <xnox> didrocks: vila: does upstream merger have any PPAs enabled? e.g. same ones that cu2d is using? Maybe pinyin from trusty-proposed can be copied into one of those? * xnox only needs libpinyin4-dev from trusty-proposed. <didrocks> xnox: well, I would prefer that we fix it properly, let's see once fghinter is around. But otherwise yes, from what I know, it's using the daily-build ppa, so we can copy it there if needed <xnox> I did file a bug against ci-services. <xnox> https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1247992 <ubot5> Ubuntu bug 1247992 in Ubuntu CI Services "upstream merger builds do not have -proposed enabled" [Undecided,New] <vila> xnox: perfect <asac> didrocks: so from what i know upstream merger uses ppa-purge etc. to get back to a pristine state... do you know if ppa-purge feature is usable with -proposed? otherwisxe the devices would accumulate all kind of not-wanted stuff - or would always need a complete reinstall, which would be time consuming:) <asac> maybe we need proposed-purge - if that doesnt work :) <vila> xnox: I'll make sure to ping fginther about it, also, use 'cihelp' to get vanguard attention <didrocks> asac: ? upstream merger doesn't use ppa apart from daliy-build one? <didrocks> asac: it's using a local repo from what I know <didrocks> not sure what ppas you are refering to :) <cjwatson> I would hope that the upstream merger is using a clean chroot each time, rather than relying on purging <asac> didrocks: hmmm.... good point :) <didrocks> cjwatson: from what I know it's a clean chroot + a local repo + daily-build ppa <didrocks> (local repo being mostly "per stack") <ogra_> asac, hey, happy jetlag :) <asac> didrocks: so guess we would still need something like proposed-purge as we would basically have to do one run of installing all deps that might come from proposed <asac> ogra_: thx. I really think it's over now :) <ogra_> heh <xnox> asac: why? cu2d is running with -proposed enabled, and so should the upstream merger. <asac> well, to a bearable degree <asac> xnox: its different :) <ogra_> didrocks, did you file a bug against friends ? else i'll do <didrocks> ogra_: I didn't, please feel free :) <asac> xnox: a) yues, we should install the depends from proposed for testing in upstream merger <ogra_> will do then <didrocks> ogra_: assign robru to it, I guess he was the one to release it <ogra_> ok <xnox> asac: .... but without inheritting all other uninstallables... true. <asac> xnox: b) no, its not very simple <asac> :) <asac> xnox: right. we want exactly all the depends and nothing else (as that might be broken and what not) <asac> xnox: and since we dont reflash devices, we need a reliable way to get back to the current clean archive/image :) * didrocks doesn't understand the "we want the depends thing", that's how sbuild is working: installing only the build-deps from what we want to build <asac> i relaly think a feature in ppa-purge to disable proposed would be helpful <asac> didrocks: installing is simple, yes. but we need to uninstall those things as we dont have the time to reflash devices for every run <didrocks> I guess it's more in the new infra world "we want to freeze the deps" (but still be able to test against latest) <asac> uninstall -> revert <didrocks> asac: ah, on the device, avoiding reflashing? <asac> didrocks: in the new world thats an additional feature, yes <didrocks> not related to upstream merger, it doesn't build on the device <asac> didrocks: upstream merger doesnt reflash so it can keep up with the big amount of merge proposals coming in <didrocks> but yeah, I think we should "just" remove the delta rw part <asac> right <asac> so i think: <asac> 1. devices get auto flashed if a new proposed (or released?) image is available <asac> 2. we add proposed into /etc/apt/sources.lists.d/ <asac> 3. install stuff from sbuild with proposed deps <asac> 4. test <asac> 5. ppa-purge --proposed :) <ogra_> asac, how do you make sure to not accidentially get other deps pulled in from proposed ? <didrocks> well, I think 5 is more reset-to-vanilla-image <didrocks> which remove the rw part <asac> ogra_: well, we get all the depends from what we work on... which is sane i think <ogra_> you need a per -ackage copy mechanism, not enable proposed altogether <asac> ogra_: we dont run apt-get dist-upgrade <asac> or upgrade <asac> just apt-get update <ogra_> but apt-get install <asac> apt-get install mycipackage <asac> ogra_: that will pull in all the deps <asac> afaict <asac> but nothing else... e.g. exactly what we want <asac> or very close at least :P ... no? <ogra_> well, i would find it safer to have them copied into a PPA first <asac> i dont think that adds safety unless we dont want to install all dependcs that are dangling in proposed * ogra_ would also not apt-get install but build a complete image from the PPA ... <asac> assuming that ppa-purge --proposed does the right thing <ogra_> making the image writable might taint your results <asac> ogra_: read backlog :) <asac> ogra_: we dont have the luxury to install complete images <asac> ogra_: yeah. wauit <ogra_> why not ? <asac> ogra_: so later we SHOULD indeed have the image delat produced and use system image updates <ogra_> build an image with the change, flash the device/emulator with it, run the tests <asac> but right now we dont have all of that in upstream merger code <asac> ogra_: flashing on device takes too long for upstream merger <asac> ogra_: too many merge requests <cjwatson> TBH, this is a problem you have regardless of whether -proposed is involved; -proposed exacerbates it but that's all <asac> cjwatson: right. <cjwatson> Consider the case of one stack that introduces a new dependency, and another stack with an unstated reliance on that new dependency <cjwatson> If you aren't arranging for a clean environment then the latter will pass tests when it shouldn't <cjwatson> So you shouldn't think of this as something specific to -proposed <asac> cjwatson: i am not :) <cjwatson> Good :) <ogra_> testing with apt-get'ed packages on a rw image isnt really getting you the same results i think ... that was the point i was making ... independently of where the packages come from <asac> cjwatson: i was just explaining that we would something like ppa-purge --proposed feature if we wanted to apply the concept used in upstream merger currently <asac> ogra_: thats a separate problem <didrocks> ogra_: this won't be the case in the "new CI world" <asac> ogra_: yes, we will produce more images and we can then use the image delta and system image approach <cjwatson> Sure, and I'm just saying that option name would either be misdescribing what the code does, or not really solving the problem :) <asac> would require a system image revert feature though if we dont want to reflash all :) <ogra_> revert feature ? <cjwatson> Similar problem for autopilot testing in general <ogra_> yes <ogra_> in any case we need the emulator first ... <ogra_> and the thing we have doesnt seem to be suiting our needs as it is ... i guess getting this into shape to even be remotely usable will still take quite some time <asac> ogra_: what do you mean? <asac> upstream merger? <ogra_> asac, emulator <ogra_> to get more test facilities that arent HW bound <asac> xnox has a short term problem that he cannot merge due to upstream merger not pulling in proposed bits. <asac> :) <ogra_> yes, i know, i was more referring to the general part of oour conversation :) <asac> hehe <asac> right. all the funky bits are blocked on emulator <ogra_> right <asac> and the ability to produce many images from everywhere :) <ogra_> that one we'll have with LP buildds <asac> yeah. thats the hope. I don't think we have super sharp plans on that aspect though. e.g. we also have to invest in our image tooling so it can be effectively run in such a scalable env. <asac> etc. <asac> anyway, didrocks pulling through CI team for the featutes needed to get to his vision will ensure that we get there - once we have the emulator :) * asac stops distracting channel <ogra_> right, but that "one we have" is imho in a far future ... at least regarding the current emulator we have ... the hardware it emulates is very far from our minimal specs <ogra_> s/one/once/ <psivaa> didrocks: ogra_: almost done with image 11 and friends-service is the one that's causing the pass rate to be lower than image 10 <ogra_> yeah <psivaa> both gallery and friends app tests fail systemsettle after for friends server taking up processor resource <ogra_> yup, as discovered in the meeting ... they either need to re-upload a rolled back version or a proper fix before we do a new image buuld <ogra_> it is very intresting that it oly affects mako though <cjwatson> FWIW I got the slave side of livefs-in-LP done over the weekend (pending review) <ogra_> oh <ogra_> [ Robert Bruce Park ] <ogra_> * Save battery life by decreasing default polling frequency. (LP: <ogra_> #1238083) <ogra_> i would guess that is what bites us <ogra_> bug 1238083 <ubot5> bug 1238083 in friends (Ubuntu) "friends-dispatcher is a little busy doing data updates on idle systems" [Undecided,Fix released] https://launchpad.net/bugs/1238083 <cjwatson> Bug 1247461 is tracking this work now <ubot5> bug 1247461 in Ubuntu CD Images "Move live filesystem building into Launchpad" [High,Triaged] https://launchpad.net/bugs/1247461 * ogra_ subscribes <didrocks> psivaa: ok, nice to know what's the cause :) <didrocks> psivaa: we'll need to talk with robru/ken I guess <psivaa> didrocks: ack <didrocks> psivaa: the regression we saw on maguro is as well due to it? <psivaa> didrocks: ogra_ yes, only in one attempt it's unity8 that's causing and the rest it's friends-service <psivaa> http://636-721-3251:8080/job/trusty-touch-maguro-smoke-friends-app-autopilot/13/artifact/clientlogs/top_after.log/*view*/ <psivaa> also i logged into the device and it's friends that's at the top <didrocks> psivaa: ok, nice to know that all those regressions are due to one and only one component :) <didrocks> psivaa: is there a way for you to downgrade the version of friends in one device and restart those tests? <psivaa> didrocks: was about to try that :) <didrocks> great ;) <ogra_> didrocks, psivaa asac bug 1248143 <ubot5> bug 1248143 in friends (Ubuntu) "the fix for Bug #1238083 seems to cause the systemsettle tests on mako to fail, blocking image releases" [Undecided,New] https://launchpad.net/bugs/1248143 <ogra_> (pleas someone confirm :) ) <psivaa> will do <ogra_> thx <psivaa> didrocks: confirmed that with the older version the issue does not occur: https://jenkins.qa.ubuntu.com/view/Trusty/view/Smoke%20Testing/job/trusty-touch-maguro-smoke-friends-app-autopilot/14/ <didrocks> psivaa: \o/ <didrocks> Mirv: mind you step ahead and revert friends? <didrocks> I guess we have enough elements now <didrocks> thanks for the hunt psivaa :) <psivaa> didrocks: yw, ogra_ found it first :) <ogra_> thanks for verifying ! <ogra_> :) <psivaa> :) <didrocks> ogra_: sharing the congrats of finding the guilty component ;) <Mirv> didrocks: is that lp:friends revert to previous release, rebuild, and release? <Mirv> some decrease of polling frequency is the only non-test change there * Mirv notes that ogra quoted that commit in particular <Mirv> ok then, understanding enough, reverting that one commit <Mirv> didrocks: before I forget what I was doing before that, can you check process-cpp from platform stack is whitelisted for publishing? <Mirv> we finally got it working <didrocks> Mirv: excellent! checking :) <ogra_> right, seems to be just a gconf key change after all <didrocks> Mirv: yeah, whitelisted <Mirv> didrocks: thanks <didrocks> yw <didrocks> sil2100: did you get in saucy download-manager? <sil2100> didrocks: it's in the unapproved queue <didrocks> sil2100: did you poke the SRU team? It needs to be in quickly as there is the 7 days period and we need to kick an image after that <sil2100> Didn't get an aswer yesterday, but I'll poke people directly today :) <didrocks> sil2100: thanks! <Mirv> didrocks: process-cpp in NEW queue <didrocks> Mirv: checking <didrocks> include/posix/linux/proc/process/state.h: LGPL (v3) <didrocks> [Copyright: 2012-2013 Canonical Ltd] <didrocks> (mutliple of them) <didrocks> when debian/copyright states only 2013 <didrocks> nitpicking, not important, but just FYI Mirv $ <didrocks> ^ <didrocks> -doc should suggests the -dev IMHO (but again, not that important) <didrocks> and the long description is quite shortâ¦ <didrocks> Mirv: otherwise sounds good (didn't change that much since my first checking and pass/reject). Can you make tvoss aware of those for a future fix? ^ <didrocks> (accepted) <Mirv> didrocks: ok, I'll let him know. <Mirv> or better yet, make a quick branch <didrocks> thanks ;) * psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - <sil2100> didrocks: what to do in case when I get test failures for calendar-app? The trunk calendar-app has much more tests than the one
{'channel': 'ubuntu-ci-eng', 'month': 11}