#ubuntu-ci-eng 2013-11-18
<Mirv> cihelp why does q-jenkins say it's being shut down?
<didrocks> hey Mirv, are you building Mir? (is cowbuilder back up?)
<Mirv> didrocks: I was, but there is a test failure
<Mirv> didrocks: a fix is being merged now, but q-jenkins states it's shutting down to which I haven't yet gotten a response from cihelp
<Mirv> I don't know about the cowbuilder
<didrocks> Mirv: ok, you didn't see issues in the previous cu2d run?
<didrocks> ev: vila: seems no cihelp, hence the direct ping (excuse us), but the cu2d jenkins is marked for shutting down, any idea?
<Mirv> didrocks: so actually mir visited my mind on Saturday (shame on me) when I pushed the cu2d mir build and back then cu2d was fine. today I checked the build result + noticed q-jenkins is marked as shutting down ie further builds blocked.
<didrocks> Mirv: ok, so cowbuilder fixed, great!
<Mirv> didrocks: ken and robru marked that because of AP machine problems they didn't continue on mir on Friday, although they could have just built and skipped check jobs I believe back then
<didrocks> yeah, let's see for today what's up with q-jenkinsâ¦
<Mirv> didrocks: another note that mir stack build job was pending with arm64 build jobs, not sure why those weren't auto-ignored. but we'll see it again soon enough when q-jenkins is operational again.
<didrocks> urgh
<didrocks> ev: vila: ~desktop-team/cupstream2distro was **weeks** old
<didrocks> at least 6-8 weeks
<didrocks> on jatayu
<didrocks> Mirv: that's why arm64 wasn't ignored
<didrocks> asac: I can't tell when we are going to do releases again, see issues like that ^ (we are in an unknown state)
 * didrocks worries as well about the network, seems bzr pull took ages (not sure if it's launchpad or the local CI network)
<tsdgeos> waht's the new sjenkins ip?
<Mirv> tsdgeos: seems 10.98.3.13, but you can also configure the DNS
<tsdgeos> Mirv: yep, i saw the part of the email to do that, but just changing the hosts file seems easier :D
<tsdgeos> manual dns ftw!
<tsdgeos> tx
<vila> didrocks: and I suppose there is no health check to warn you about that ?
<didrocks> vila: to ensure that your home directory was restored with a version that is 3 months ago? No really
<vila> didrocks: we all highlight 'cihelp' no need for a direct ping
<didrocks> vila: seems you didn't have an health check either to ensure that what you migrate are consistant with latest in production?
<vila> didrocks: could we get a bit more professional and stop pointing fingers, I can do that too but I don't think it's productive especially during fire fight
<didrocks> vila: well, seems like you do something similar with "urgh", "we should stop doing that" and other expression like that without providing solutions
<didrocks> I wish just that we could get back to work after a week and half, and I don't think we didn't help you
<vila> didrocks: you did help
<vila> didrocks: but not by yelling
<didrocks> so, can you help in keeping/figuring out why jenkins want to shut down and ensuring that we do have the latest code in production?
<vila> didrocks: and if I wasn't fire fighting an undocumented engine I would have more time to implement solutions I did propose
<didrocks> vila: see, pointing fingersâ¦
<vila> didrocks: yeah, "yelling" is finger pointing at you, nothing good comes out of panic mode so please just stop, let's get back to facts and solutions
<didrocks> vila: so, facts is that ~desktop-team wasn't up to date with latest in magners
<didrocks> can you help ensuring it's now the case
<didrocks> and no other thing like cowbuilder are forgotten between the 2 copies?
<didrocks> second fact: can you figure out why jenkins is setup to stop?
<didrocks> (and so, we can build anything)
<vila> I asked why jenkins was in shutdown mode on Friday, didn't get an answer
<vila> "no other thing like" is what I meant by undocumented, my crystal ball doesn't know either, do you ?
<didrocks> vila: well, I think making a diff between old machine, at least in system path, would have been a first step for the transition
<didrocks> vila: like as well asking for the tool prerequisite for the undocumented part from stackholders
<didrocks> vila: on jenkins, so, what's the next step?
<vila> I don't care about "would have", do you have "will" ?
<didrocks> vila: "will" you make a diff between old machine and new one then?
<didrocks> vila: and what are going to you do about jenkins?
<didrocks> if you prefer future :)
<vila> yes I do, thanks
<vila> I'll ask again why it is in shut down
<vila> and since I won't get an answer I will restart it
<vila> which is not the smartest thing to do
<didrocks> vila: so, in term of speaking futures, please apply this to you and stop telling "this stucks", "this should have never been done like that", "this was undocumented". That will help both sides, thanks :)
<didrocks> vila: +1 on restarting if needed, everything is blocked (the new planned jobs are stucked and don't move)
<didrocks> vila: from the list of stuck jobs, all the cu2d can be killed
<didrocks> not sure about:
<didrocks> daily-release_update-touch-images
<didrocks> autopilot-ubuntu-applications
<didrocks> jenkins-autocheck
<didrocks> power-trusty-desktop-amd64-power-test-1
<didrocks> power-trusty-desktop-i386-power-test-1
<vila> didrocks: I said it *is* undocumented and this makes it harder to check after the 1ss move and harder to get it back up. That how I explain to the stakeholders why it's not up yet
<didrocks> vila: but you keep ranting about everything single piece of the architecture, which isn't helpful either and doesn't fix anything
<didrocks> anyway, let's move on, I hope the list above can help you ^
<vila> didrocks: you're still pointing fingers, do we need to solve that with a third party ?
<didrocks> vila: come on, I was just showing you that the issue is not unilateral, but it seems you want to continue when I'm proposing to move on and close the topic
<didrocks> vila: and that's why I started to list the jobs I don't know if you can kill and you bring back the topic :/
<didrocks> anyway, *sigh*
 * vila moves on
<vila> autopilot-nvidia needs a new power supply
<vila> the alternatives are 1) setup a new host with any nvidia card 2) disable autopilot-nvidia in cu2d-config
<didrocks> vila: go the road you prefer, you are handling the production of this. We can go over and hope that if you choose 2), there will be no real card regression (which is unlikely until we release an unity7)
<Saviq> cihelp: hey guys, seems the otto runner for unity8-autolanding often fails with a lock password entry... https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/682/artifact/results/autopilot/artifacts/unity8.shell.tests.test_hud.TestHud.test_show_hud_button_appears%20%28Desktop%20Nexus%2010%29.ogv
<Saviq> is that known? resolved?
<vila> Saviq: not known to me
<Saviq> vila, http://s-jenkins:8080/job/autopilot-testrunner-otto-trusty/683/ seems to be the last job that failed like this, maybe it got resolved since
<Saviq> vila, or maybe simply one of the machines is locked...
<Saviq> no, seems all the jobs ran on ps-radeon-hd8350
<Saviq> and now are green
<vila> Saviq: good, no time to investigate that one right now, especially if you think it's back to green
<vila> didrocks: you did update q-jenkins:~desktop-team/cusptream2distro right ?
<Saviq> vila, yeah, will let you guys know
<didrocks> vila: yeah, I had to to unblock Mirv (but that was before seeing jenkins was getting shut down)
<didrocks> vila: only thing I did this morning on the machine
<vila> ok
 * didrocks spent some time to look if there was a bug in the code first
<vila> didrocks: sorry about that
<didrocks> no worry
<vila> restarting q-jenkins
<vila> didrocks: I won't do a diff between two systems that had different purposes and now have  new different purposes, I would have no idea about how to interpret the diff (and I'm not even sure I know how to compare two systems anyway)
<vila> didrocks: q-jenkins is back
<didrocks> vila: hum, so we will go on try and error procedure then?
<didrocks> vila: nice! want me start a stack?
<vila> didrocks: yes please, as gently as possible, we're still on thin ice
 * didrocks starts just one stack: Mir
<didrocks> (no AP for that one)
<didrocks> Mirv: starting Mir ^
<sil2100> \o/
<didrocks> vila: I'll let you decide on the autopilot-nvidia side
<didrocks> * Mir started *
<Mirv> didrocks: thanks, although the test fix is not yet in https://code.launchpad.net/~vanvugt/mir/fix-1252144.trunk/+merge/195547
<didrocks> Mirv: at least, we'll ensure we can start building something :)
<Mirv> yes, and it'll be nice to see no arm64 stuckness
<didrocks> right
<didrocks> vila: confirming the network is really really slow: http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/Mir/job/cu2d-mir-head-1.1prepare-unity-system-compositor/47/console
<didrocks> Fetched 12.0 MB in 1min 1s (196 kB/s)
<didrocks> Fetched 11.8 MB in 1min 48s (110 kB/s)
<didrocks> on another job
<didrocks> and some error: http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/Mir/job/cu2d-mir-head-1.1prepare-unity-greeter-session-broadcast/119/console
<didrocks> ev: coming?
<ev> on my way in
<vila> didrocks: https://code.launchpad.net/~vila/cupstream2distro-config/no-nvidia/+merge/195563
<Mirv> cihelp please check I'm seeing jenkins network problems and timeouts at merge proposal https://code.launchpad.net/~vanvugt/mir/fix-1252144.trunk/+merge/195547 - especially concerning connecting naartjie
<didrocks> vila: just to confirm, the radeon machine is now working? (as it's in the config?)
<vila> didrocks: well, last I checked it was... you mean the qa-radeon-7750 right ?
<didrocks> vila: yep, ok, good, deploying with it, thanks
<didrocks> Mirv: sil2100: think about reconfiguring your ~/.cu2d.cred with q-jenkins.ubuntu-ci btw
<Mirv> didrocks: did that already
<didrocks> vila: reprovisionning a recent trusty otto container: http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-setup_otto/23/console
<sil2100> didrocks: updated \o/
<didrocks> and removed nvidia from it
<didrocks> sil2100: great! :)
<asac> didrocks: the tests we usually would have run on those nvidia machines are AP tests, right?
<ogra_> === Image r23 building ===
<didrocks> asac: yeah
<didrocks> cihelp: ok, can't reprovision the otto machines, seems it can't download the iso (it tries from q-jenkins)
<didrocks> see http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-setup_otto/label=qa-intel-4000/23/console
<didrocks> + wget --progress=dot:mega http://q-jenkins//iso/trusty//trusty-desktop-i386.iso -O autopilot-trusty-setup_otto_label=qa-intel-4000.QgzUAk
<didrocks> --2013-11-18 09:57:35--  http://q-jenkins//iso/trusty//trusty-desktop-i386.iso
<didrocks> Resolving q-jenkins (q-jenkins)... 10.98.3.12
<didrocks> Connecting to q-jenkins (q-jenkins)|10.98.3.12|:80... connected.
<didrocks> HTTP request sent, awaiting response... 404 Not Found
<didrocks> 2013-11-18 09:57:36 ERROR 404: Not Found.
<didrocks> ogra_: great!
<didrocks> Mirv: we'll have to wait on the provisionning before running the Mir stack (all setup done apart from this FYI) ^
<Mirv> ok
 * asac wonders why it doesntloads from q-jenkins
<didrocks> we should do a wrapper one day for wget, that a 404 doesn't create an empty fileâ¦
<asac> didrocks: do you know how this normally works?: e.g. who ensures that there is an .iso on q-jenkins?
<didrocks> asac: I think QA cached it some times ago for their smoke testing and they had a process for that
<didrocks> asac: maybe it's a jenkins job, I don't really know
<didrocks> ah, also:
<didrocks> Errors were encountered while processing:
<didrocks>  grub-pc
<didrocks> E: Sub-process /usr/bin/dpkg returned an error code (1)
<didrocks> _____________________________________________________________________________
<asac> ok
<didrocks> on radeon
<didrocks> vila: I guess this is the conffile you changed ^
<asac> wonder why they dont use squid
<vila> didrocks: looking
<vila> didrocks: first attempt at reprovisioining since the move probably
<didrocks> vila: yeah, confirmed
<vila> didrocks: /iso content is good, searching for :80 config :-/
<xnox> Can this be merged please? https://code.launchpad.net/~xnox/ubuntu-keyboard/libpinyin4/+merge/193859
<xnox> the r101 was a merge from trunk to resolve a merge conflict.
<xnox> and the bot now thinks it needs to be re-reviewed.
<didrocks> xnox: I approved it for you :)
<didrocks> (seeing it was already reviewed)
<retoaded> didrocks the URL for the ISO works now
<didrocks> retoaded: thanks! vila: did you look at the grub-pc thing or should I just retake a setup snapshot?
<vila> retoaded: thanks, haven't figured that one out, there is no /var/www/iso/trusty on m-o yet the log says there was one a couple of days ago 8-/
<vila> didrocks: what grub-pc stuff ?
<didrocks> 11:02:38 didrocks | ah, also:
<didrocks> 11:02:40 didrocks | Errors were encountered while processing:
<didrocks> 11:02:40 didrocks |  grub-pc
<didrocks> 11:02:40 didrocks | E: Sub-process /usr/bin/dpkg returned an error code (1)
<retoaded> vila, it is an alias setup within apache; see /etc/apache2/conf.d/isos.conf
<didrocks> 11:02:43 didrocks | on radeon
<didrocks> 11:02:47     asac | ok
<didrocks> 11:02:51 didrocks | vila: I guess this is the conffile you changed ^
<vila> didrocks: the only ring it bells was to pin a kernel version... hold on reading
<didrocks> vila: yeah, that's why I'm pinging you, in case you changed a conffiles and grub isn't happy about it
<vila> retoaded: thanks
<vila> didrocks: ok, no I've restored everything to pristine after giving back qa-radeon-7750, thanks for thinking about that
<vila> asac: the isos are downloaded by otto, the magic links were missing server side, just fixed
<didrocks> vila: ok, so you think we can ignore this grub error then?
<vila> didrocks: first time I see this grub error :-/
<vila> didrocks: oh, locally modified...hmm, may be a leftover from debugging by the kernel team, I remember they had to force things a bit at one point to get a specific kernel
<didrocks> vila: ah, so you are reverting back to vanilla? \o/
<vila> didrocks: sounds like the safer bet
<didrocks> and then I guess sudo apt-get install -f
<didrocks> keep me posted
<didrocks> I'll rerun a setup() then to try to get your image
<didrocks> (on both)
<ev> retoaded: good morning
<vila> didrocks: reproduced with 'apt-get install grub-pc', confirmed it complained about the comment
<retoaded> ev, it is definitely morning. I'm not sure about the "good" part though
<ev> :)
<cjwatson> vila: what's this?
<cjwatson> <- grub maintainer
<ev> retoaded: ev@jatayu:~$ time curl https://launchpad.net -> 21s; ev@mayura:~$ time curl https://launchpad.net -> 0.7s
<ev> any idea what's going on?
<vila> cjwatson: http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-setup_otto/label=qa-radeon-7750/23/console
<retoaded> ev, no but will tale a peek
<vila> cjwatson: caused by a comment in /etc/default/grub
<cjwatson> vila: remind me how I set up DNS for .ubuntu-ci?
<vila> cjwatson: https://wiki.canonical.com/UbuntuEngineering/QA/VPN
<cjwatson> ta
<vila> cjwatson: you had one working before ? NM or openvpn ?
<cjwatson> NM, I'll just update it now
<cjwatson> ah, right, yeah, that error isn't my problem :)
<cjwatson> good
<cjwatson> although the update from 2.00-19ubuntu3 -> 2.00-20 shouldn't have triggered a conffile prompt ...
<cjwatson> <cjwatson@amber ~>$ diff -u <(deb-extract-file grub2-common_2.00-19ubuntu3_amd64.deb /usr/share/grub/default/grub) <(deb-extract-file grub2-common_2.00-20_amd64.deb /usr/share/grub/default/grub)
<cjwatson> <cjwatson@amber ~>$
<vila> cjwatson: but it did, I installed the maintainer version which removed the comments, hold on
<cjwatson> no substantive change to postinst either
<vila> cjwatson: scratch, that,
<vila> was looking at the wrong machine
<vila> on qa-radeon-7750:/etc/default/grub comments after the GRUB_DEFAULT line
<cjwatson> I did change config a bit, but that change would have been a no-op unless GRUB_CMDLINE_LINUX_DEFAULT had been removed from the config file
<cjwatson> Anyway, I probably can't debug any further unless there's some way to see the diff between the versions here
<vila> cjwatson: ctrl-alt-del
<vila> cjwatson: I did say: keep the installed version and the comments are still there
<cjwatson> And of course if you change package-supplied configuration files directly then it's inevitable that you'll occasionally have to resolve conflicts
<vila> cjwatson: (since I was looking at the wrong machine and stop seeing the comment I revised my memory and said I did chose the maintainer version, clearly not the case)
<cjwatson> Could you show me "diff -u /usr/share/grub/default/grub /etc/default/grub" then?
<vila> cjwatson: ha ! great: here is the *needed* change:
<vila> -GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
<vila> +GRUB_CMDLINE_LINUX_DEFAULT="quiet swapaccount=1"
<cjwatson> OK, so you can fix this by making that change in debconf
<cjwatson> dpkg-reconfigure grub-pc
<cjwatson> Though it should have done that automatically ...
<cjwatson> Before you do the above, "debconf-show grub-pc"
<vila> cjwatson: http://paste.ubuntu.com/6436818/
<cjwatson> Huh, so that's already in debconf
<vila> cjwatson: because I did 'apt-get install grub-pc' ? That change was made.... when the machine was setup, say, two weeks ago ?
<vila> cjwatson: no need for dpkg-reconfigure grub-pc then ?
<cjwatson> No
<cjwatson> Was the change originally made directly to /etc/default/grub, or via some user interface?
 * vila forgot dentist, needs to run
<cjwatson> (Either should have worked, but I need to know how to reproduce this)
<vila> directly in file
<cjwatson> vila: Oh, but you say there was a comment added above it?
<cjwatson> I guess that would have been sufficient to confuse matters
<cjwatson> (I'd hoped for the diff pastebinned, not just a part of the diff pasted into IRC)
<Saviq> vila, it's back again... https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/691/ :/
<Saviq> didrocks, session locking under otto â, ideas?
<didrocks> Saviq: I guess it's something for cihelp ^
<Saviq> didrocks, yeah, vila responded to cihelp before, asked me to follow up if it happened again
<didrocks> Saviq: hard to tell without having access to kvm, which I don't anymore (for good reasons btw ;))
<Saviq> didrocks, mhm, thanks
<Saviq> cihelp, so yeah, otto runner has issues with session getting locked in some jobs - all autopilot videos are either black or show the screen lock password entry, and obviously the tests fail
 * Mirv back in 1h
<dednick> Cim
<dednick> bleh
<retoaded> ev, leworks@jatayu:~$ time curl https://launchpad.net -> real	0m0.611s
<ev> retoaded: whoop. What was the problem?
<retoaded> ev, /etc/resolv.conf. utah seems to modify it to put a nameserver 192.168.122.1 first in the order
<retoaded> so resolving launchpad.net tries that first then fails over to the next nameserver in order
<retoaded> I removed it
<retoaded> ev, that could just be remnants of an older utah install and was sync'd over from m-o
<ev> ugh, I knew there'd be something I hadn't checked
<ev> thanks
<vila> cjwatson: sorry, being late didn't help, here is the full diff http://paste.ubuntu.com/6436934/
<vila> cjwatson: and I probably missed that GRUB_CMDLINE_DEFAULT when apt-get install presented the diff :--/
<cjwatson> I tried a saucy chroot, apt-get install grub-pc vim, edit /etc/default/grub to apply that diff, edit /etc/apt/sources.list to upgrade to trusty, apt-get update, apt-get install grub-pc - no prompt
<vila> cjwatson: so, reformulating to ensure I get it right: pat-get saw a conflict on GRUB_CMDLINE_DEFAULT and warned. It won't do it next time correct ? (Unless a new change introduce a new conflict)
<cjwatson> I don't think so but I can't tell for sure because this is a bit out of the ordinary
<cjwatson> Is the immediate problem dealt with?  If so I propose ignoring this until/unless it happens again :-)
<vila> cjwatson: good enough for me, will tell you if I encounter such a case
<cjwatson> (Or until/unless somebody can get me a reproduction recipe I can run locally)
<cjwatson> FWIW I suspect the conflict would have related to the comment and not to the GRUB_CMDLINE_LINUX_DEFAULT change, since the latter appears to have been correctly carried over into debconf
<cjwatson> Can't prove it right now though
<vila> cjwatson: the weird thing is that qa-intel-4000 has the same changes and didn't encounter the issue: http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-setup_otto/label=qa-intel-4000/23/console
<ogra_> == Image r23 DONE ===
<cjwatson> vila: Ah well, let's see if it happens on the next grub2 change
 * popey updates to 23
<cjwatson> Probably not worth ratholing on now
<vila> cjwatson: agreed
<vila> didrocks: so, grub-pc issue cleared for now, re-trying an otto setup
<didrocks> vila: keep me up to date!
<vila> didrocks: images downloaded on both, progress
<vila> didrocks: and both failed later, reading the logs
<vila> lxc_container: command get_cgroup failed to receive response >-/ not sure that's the trigger but...
<vila> didrocks: nope, that one should be harmless, happened during the last successful run
<tsdgeos> guys, i had a test segfault in jenkins autolanding while it passed fine on jenkins CI and the crash seems to be no related to my changes, we've just re top approved the change but t1mp thinks its a good idea to mention here, in case it happens again to someone else which may mean faulty hardware or something else
<tsdgeos> i.e. not asking for help, just saying this happened in case it repeats
<vila> tsdgeos: thanks, cihelp ^
<t1mp> ^the MR that had issues https://code.launchpad.net/~aacid/ubuntu-ui-toolkit/ima_do_not_filter_disabled/+merge/194830
<didrocks> vila: otto should be ready then? ;)
<Mirv> tsdgeos: yep, I think it's good to report the hitches so that they can be tracked down one by one
<vila> didrocks: :-/ apparently not despite update_host returning 0 (AFAICS) the jobs fail
<didrocks> ah ok :/
<vila> didrocks: last run succeeded, while I'm happy to report, I'm unhappy to not understand why :-/
<vila> didrocks: I did some apt-get upgrade/dist-upgrade manually though...
<vila> didrocks: so let's move on the next step
<Mirv> cihelp more 'naartjie' host issues (ssh connection fails) https://code.launchpad.net/~thomas-voss/process-cpp/add_fork_and_run_facilities/+merge/194842
<vila> didrocks: I also noticed that autopilot-nvidia last otto setup run failed before the move... we may have other issues to investigate when we get a nvidia replacement :-/
<vila> didrocks: so, what's the next step ? Do you have a small stack in mind that is expected to succeed ?
<didrocks> vila: was discussing in a hangout
<didrocks> vila: so, otto should be up for those 2 machines? Mirv: can you launch Mir now?
<didrocks> Mirv: Mir & co of course :)
<didrocks> if the fix branches were merged
<didrocks> vila: on the failure: I know that sometimes, the machine exits before the job finishes to process
<didrocks> so you see the java stack
<didrocks> and it's marked as failed
<Mirv> didrocks: ok!
<Mirv> the branch is still not merged, though
<Mirv> I'm wondering if I could help from ci_help to get ETA if it'll work soon, or merge manually
<psivaa> Mirv: naartjie is resolved ok from s-jenkins but not from the slave cyclops nodes
<psivaa> retoaded or fginther could add more information
<didrocks> Mirv: yes, please ;)
<vila> didrocks: otto setup succeeded so yeah, that should mean otto is up, but I'd rather not rely on that without at least one successful run of one job
<Mirv> doing manually for now, and good if the naartjie problems are on radar
<retoaded> psivaa, which cyclops node(s)? node-06 resolves it.
<didrocks> vila: yeah, we need to be able to start the Mir stack (pending Mirv to get merged/merge the Mir branch) ^
<vila> didrocks: ok
<vila> retoaded: node07 is the only one my test script can't reach
<retoaded> vila, ack.
<psivaa> retoaded: ohh? http://s-jenkins:8080/job/process-cpp-trusty-armhf-autolanding/11/console says 'Unable to connect to naartjie:http:'
<retoaded> vila, it's possible node07 is not up.
<psivaa> which uses node-06
<vila> psivaa: ha, good, retoaded, my test script exercises ssh only
<vila> retoaded: from my desktop
<vila> Mirv: let me know when you start so I can monitor
<retoaded> psivaa, I don't think that is an issue with being able to connect to naartjie but, instead, not finding what it is looking for:  http://naartjie trusty/ InRelease has spaces in it
<retoaded> but that mey not be the actual URL
<retoaded> s/mey/may
<Mirv> vila: I kicked the https://code.launchpad.net/~thomas-voss/process-cpp/add_fork_and_run_facilities/+merge/194842 now for example
<retoaded> psivaa, because the other job https://jenkins.qa.ubuntu.com/job/process-cpp-trusty-armhf-ci/16/console has the URL  http://naartjie/archive//head.mir/trusty/InRelease and InRelease does not exist under  http://naartjie/archive//head.mir/trusty
<vila> Mirv: err, on s-jenkins ?
<psivaa> retoaded: yea, that's true. so an issue with the job config i guess.
<retoaded> psivaa, possibly
<vila> didrocks, Mirv: I was asking for some validation on q-jenkins, can't we do that ?
<psivaa> retoaded: thanks, i'll dig in if there is anything that is obvious
<didrocks> vila: Mirv is going to run the Mir and dependant stacks, which will trigger that job
<didrocks> vila: but the CI isn't able to merge one of the upstream branch it seems which enables to build Mir
<Mirv> vila: ok I'm just not clear which issue you're referring to. I also kicked the Mir stack now running, after merging the CI failing commit manually.
<didrocks> so Mirv told he will merge manually the mir branch
<didrocks> and run the stacks :)
<didrocks> and, already done
<vila> ha ok, sorry, was confused
<didrocks> Mirv: then, you take care of the platform stack? (so that it does build against latest Mir)
<Mirv> vila: yeah platform + unity-mir (and recheck unity-system-compositor too)
<didrocks> Mir Mirvâ¦ this is so confusing! :)
<didrocks> thanks ;)
<Mirv> hopefully then there'd be something ready for robru to test for example
<didrocks> yep
<didrocks> Mirv: is the network seems to still be slow btw?
<vila> didrocks: hehe, yeah, funny, didn't fall for that Mir Mirv one ;)
<Mirv> didrocks: yes, the prepare jobs seem to take ages
<Mirv> "Fetched 12.0 MB in 2min 43s (73.2 kB/s)"
 * didrocks goes for a run outside
<Mirv> 512kbit/s not really 'internal network' speeds
 * vila sighs, and we postponed the upgrades for the monitoring we had...
<vila> bah, would probably won't help, I doubt we are monitoring the part that is acting right now
<vila> Mirv: unity-system-compositor failed to build on amd64 and i386
<vila> Mirv, didrocks: do we have something simpler to try ?
<vila> Mirv: ?
<vila> Mirv: is there a way to manually trigger a simple stack on q-jenkins ?
<Mirv> vila: unity-system-compositor in itself is not too big. but the problem there is maybe related to boost transition, not these other problems?
<Mirv> vila: the prepare jobs now completed without timeouts
<vila> Mirv: no idea :-/
<vila> Mirv: I try to stay focus on the otto nodes if I can :-/
<Mirv> vila: or maybe it's CI after all, I can install libboost-all-dev just fine locally
<vila> Mirv: the failed to build are on lp, so not related to otto is my point :-/
* josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: josepht | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move)
<Mirv> vila: ok, but why did you ask about it failing then, or what were you searching to try?
<vila> Mirv: ctrl-alt-del
<vila> Mirv: I asked for a simple stack to run and validate the otto stuff, you pointed to an MP and I didn't make the connection. When mir-head came, I thought I got that job anyway and looked at how it went
<vila> Mirv: it ended up failing *before* reaching otto IIUC, so I'm now asking if have a simpler way to validate otto
<Mirv> vila: ok, so you want to see check job running?
<Mirv> vila: sdk stack now running just the check job
<vila> Mirv: thanks, sorry for not expressing my need more clearly
<Mirv> except that it failed to start
<vila> dang
<vila> Mirv: http://q-jenkins:8080/job/cu2d-qa-head-2.2check/358/ ?
<Mirv> vila: qa stack now running
<Mirv> and yes,that
<vila> Mirv: thanks
<Saviq> josepht, we've see https://jenkins.qa.ubuntu.com/job/unity8-trusty-armhf-autolanding/86/console a few times now - connection time out to naartje
<Saviq> josepht, that expected / known?
<josepht> Saviq: looking, I know there've been some reports of networking issues in the lab so perhaps this is related.
<vila> Mirv: http://q-jenkins:8080/job/autopilot-trusty-daily_release/513/console hu ho, autopilot-nvidia and qa-intel-4000, what did we miss ?
<vila> Mirv: my understanding is that we should have qa-intel-4000 and qa-radeon-7750 there instead
<cjohnston> cu2distro-config was updated, did that maybe run after it was updated? (or was the config maybe never merged?)
<vila> and http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/label=qa-intel-4000/513/console failed, no containers which IIRC is an issue with right access somewhere triggered by an lxc update (but it should not have triggered again >-/)
<vila> cjohnston: or the jobs may need to be re-deployed, didrocks said he will after the hangout, let's wait for confirmation
<vila> Mirv: qa-intel-4000 fixed (lxc upgrade striked again, already documented in the playbook), qa-radeon-7750 is not affected
<vila> Mirv: do you know how to check that lp:cupstream2distro-config revno 925 has been deployed or do we need to check some other job (I think they are documented somewhere)
<vila> Mirv: by deployed I mean I think some jobs needs to be injected again in jenkins but I don't know how
<vila> Mirv: and didrocks mentioned having to tweak some other jobs too
<vila> Mirv: http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/configure is the one that mention autopilot-nvidia instead of qa-radeon-7750 should I fix it or is it one that should re-generated by cu2d ?
<josepht> Saviq: retoaded sorted it out
<Saviq> josepht, ok thanks, will report back if we stumble upon it again
<vila> Mirv: I fixed the slaves in the configuration matrix, we'll check with didrocks if that was appropriate when he's back
<Mirv> vila: I guess no deploying of the configuration?
<vila> Mirv: no idea
<vila> Mirv: can you rebuild cu2d-qa-head or should I just click the build button (no specific parameters ? )
<Mirv> vila: so lp:cupstream2distro-config is correct at the moment?
<Mirv> vila: I can to the config redeploying, please don't run anything yet in that case yet
<vila> Mirv: trunk has my proposal for disabling nvidia so AFAIK yes
<vila> Mirv: ok, not touching my mouse , just my keyboard to reply here ;)
<vila> Mirv: and sorry for the flood here, not pushing you, just trying to stay in sync
<vila> (and have notes to summarize and document when the fires go down)
<vila> no no no, I won't believe that I can't reach q-jenkins anymore, I just won't
<vila> pfew, local network hiccup
* josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: - use 'cihelp' | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move)
<Mirv> vila: all deployed, and started qa stack again
<Mirv> also continuing on the mir builds but seeing problems still
<vila> Mirv: thanks, I'll look at the q-jenkins part while you do that
<vila> Mirv: autopilot tests running on both hosts
<vila> Mirv: I haven't seen any failure yet but I didn't check thoroughly, wating for the jobs to finish
<sergiusens> didrocks, seems it's nice day to upload clicks
<vila> Mirv: http://q-jenkins:8080/job/autopilot-trusty-daily_release/lastCompletedBuild/testReport/ I think that's good enough to validate the otto setup
<vila> didrocks: ^
<Mirv> robru: passing the mir ball to you/ken. status is that bug #1252144 still affects mir in daily-build PPA, please continue to ping upstream about it. then I don't know what's this u-s-c fail about: https://launchpadlibrarian.net/156843289/buildlog_ubuntu-trusty-amd64.unity-system-compositor_0.0.1%2B14.04.20131118.1-0ubuntu1_FAILEDTOBUILD.txt.gz
<ubot5> bug 1252144 in mir (Ubuntu) "A test failing on builders with mir 0.1.1: PublishedSocketConnector.drm_auth_magic_is_processed_by_the_server" [Critical,In progress] https://launchpad.net/bugs/1252144
<Mirv> robru: however mir build for armhf, and so did u-s-c. platform-api and unity-mir are about to compile now in cu2d, so if the build for armhf you could run the mir 0.1.1 touch tests even without mir x86 builds or u-s-c, and report them to the landing plan.
<Mirv> sil2100: didrocks: FYI too
<Mirv> robru: correction, please force a rebuild of platform-api, it didn't have changes so didn't rebuild like others in the stack. unity-mir has changes so it'll rebuild.
<didrocks> vila: I did redeploy, any pointer?
<didrocks> vila: well, I deployed the one you changed, maybe I missed one
<vila> didrocks: as mentioned above, http://q-jenkins:8080/job/autopilot-trusty-daily_release had autopilot-nvidia instead of qa-radeon-7750 I fixed that
<didrocks> vila: hum, interested, I changed the setup job, and then check the otto job and I didn't see nvidia on it, I thought you did change it
<didrocks> vila: maybe was missing coffee :)
<didrocks> sergiusens: exactly! notes-app and all with AP failing please :)
<didrocks> sergiusens: I guess http://reports.qa.ubuntu.com/smokeng/trusty/touch/maguro/22:20131115:20131111.1/4976/ gives a good list :)
<didrocks> vila: nice on the otto setup! :)
<didrocks> Mirv: thanks for your work!
<vila> didrocks: yeah, at least we have some green around there (I'm not clear if we suffer from the slow network there but at least it doesn't break otto)
<didrocks> yep
<sergiusens> didrocks, landing plan doesn't show notes app from what I saw
<didrocks> sergiusens: in fact, it was on it and treated deb-side
<didrocks> sergiusens: but as it's both .deb and .click, I think you need to do it .click side as well
<sergiusens> didrocks, ack, I'll tackle it as well
<didrocks> thanks!
<dobey> is there a way to see what args are being passed to the autoland script for current/past CI jobs? or any way to get that information at all?
<dobey> fginther: ^^
<ogra_> ev, there seem to be quite a lot of whoopsie crashes in r23
<ogra_> (along with unity and maliit)
<ev> ogra_: crashes of whoopsie, or crashes that whoopsie is uploading?
<ogra_> whoopsie .crash files
<ev> well that's really the problem of the crashing program, surely
<ogra_> (which indicates crashes of whoopsie)
<ev> oh, I see what you're saying
<ev> in a meeting, will come back to this
<ogra_> _usr_share_apport_whoopsie-upload-all.0.crash
<didrocks> sergiusens: btw, just updated it as landing 304
<sergiusens> ok
<fginther> dobey, one moment, in a meeting
<sergiusens> balloons, didrocks this fix won't work on click http://bazaar.launchpad.net/~ubuntu-filemanager-dev/ubuntu-filemanager-app/trunk/revision/88
<didrocks> sergiusens: do not hesitate to annotate the landing spreadsheet with those infos btw (and turn the thing to a big, blinking, RED! :)
<balloons> sergiusens, looking
<sergiusens> didrocks, give me comment access and I will :-)
<didrocks> sergiusens: oh? you don't have this? one sec
<didrocks> sergiusens: you have POWER!
<balloons> sergiusens, you mean temp_dir = tempfile.mkdtemp(dir=os.path.expanduser("~"))?
<sergiusens> balloons, no, you can't patch home with click
<balloons> sergiusens, ahh, so         patcher = mock.patch.dict('os.environ', {'HOME': temp_dir}) is no go :-)
<didrocks> sergiusens: click has access to a separate tmp btw?
<sergiusens> balloons, you need to re set the upstart environment and that might be a mess ;-)
<sergiusens> balloons, the environment is managed by upstart
<sergiusens> balloons, so you can get away with it; but if you don't reset properly; you break the entire env until you reboot/restart the session
<balloons> sergiusens, ok makes sense. Well, hmm. I guess we've no choice but to redo the tests without patching home. I'm not sure if there are any implications we can't work around or not
<balloons> sergiusens, I will say the patching home is not new.. the current tests do the same
<sergiusens> balloons, was my implementation that bad?
<balloons> sergiusens, ohh, you mean the if not click logic?
<sergiusens> balloons, yes
<balloons> it's been a bit since I did this. I assumed if I removed it, it didn't work
<balloons> but perhaps this was me trying to be more elegant
<sergiusens> balloons, it worked for me when I did it
<balloons> sergiusens, ok, well let me re-enable it and do a quick test. if it works, I've no complaints
<dobey> fginther: sure. i had a meeting as well. i'm just wondering how all that code is being called in practice at the moment, to see what exactly there is left to do to switch it to running tarmac for the landing
<fginther> dobey, can you view http://s-jenkins:8080/job/generic-land/ ?
<dobey> fginther: i don't have whatever vpn config is required for that, no
<dobey> fginther: is it not visible from the public URLs?
<fginther> dobey, no, those details are not published
<fginther> s/details/jobs/
<fginther> dobey, I can pastebin some to you
<dobey> fginther: that would be fine. i'm only interested in the arguments passed to autoland such as --ppa and whatnot
<fginther> dobey, http://paste.ubuntu.com/6438151/ and http://paste.ubuntu.com/6438155/
<dobey> thanks
<alesage> fginther, tedg noting this Jenkins failure, that dir apparently created in a second pass, maybe something in the "custom hooks" script to fix? https://jenkins.qa.ubuntu.com/job/indicator-sound-trusty-amd64-ci/16/console
<fginther> alesage, looking into it
<alesage> fginther, thanks
<didrocks> sil2100: kenvandine: joining?
<didrocks> plars: ^
<plars> didrocks: yes, brt
<didrocks> robru: you can't hear us/rejoin?
<robru> didrocks, nope, can't hear a thing. gonna update & reboot
<sil2100> Aaaah
<sil2100> Joining
<kenvandine> robru, uitk is building in the PPA now
<robru> kenvandine, oh, great
<kenvandine> robru, i need to run out for lunch, when the build is done can you get started testing?
<kenvandine> robru, and when i get back i'll jump in too
<robru> kenvandine, sure thing
<kenvandine> cool
 * kenvandine runs
<Saviq> cihelp, can I file a bug somewhere to track issues with the CI infra? i.e. otto encounters locked unity7 session from time to time
<fginther> Saviq, https://bugs.launchpad.net/ubuntu-ci-services-itself/+bugs
<fginther> alesage, tedg, indicator-sound-ci is working now. still trying to figure out why it failed earlier
<tedg> fginther, Cool, thanks!
<vila> Saviq: from *time to time* ??? I could understand everytime, but from time to time... screen saver ?
<alesage> fginther, yes maybe one pass was necessary to create that hook directory?  and then subsequent runs passed b/c it existed
<Saviq> vila, yes, screen saver
<fginther> alesage, hmm
<Saviq> vila, I would expect for some projects the time to set up (apt-get etc.) is long enough that the lock screen kicks in
<vila> Saviq: why now ?
<Saviq> bug #1252386
<ubot5> bug 1252386 in Ubuntu CI Services "otto runner has locked unity7 session from time to time" [Undecided,New] https://launchpad.net/bugs/1252386
<vila> Saviq: ha ! slow network then, worked on
<Saviq> vila, just wanted to say that maybe network is slow
<Saviq> vila, still, we should disable screen lock completely on otto, shouldn't we ;)
<vila> Saviq: oh yes
<Saviq> or at least inhibit it during test runs
<vila> Saviq: there is no screen to save there !
<Saviq> vila, I imagined so
<vila> Saviq: so when it happens it's for all tests but it doesn't happen for all jobs ?
<Saviq> vila, yes, when it happens it's 100% failure
<plars> didrocks: it looks like pitti has already fixed the whoopsie-upload-all crash I mentioned, should be better as soon as we pull in a newer apport
<vila> Saviq: thanks
<Saviq> vila, and it happens most often on unity8, gallery - the biggest dependencies probably
<didrocks> plars: wellâ¦ that's pitti, no surprise :)
<didrocks> plars: thanks for the head's up!
<sil2100> fginther: hello!
<sil2100> fginther: https://code.launchpad.net/~sil2100/cupstream2distro-config/add_unity-scopes-api/+merge/195643 <- can you take a look and then maybe enable the automerger for this project :) ?
<sil2100> fginther: thanks!
<dobey> fginther: so there's a single jenkins job, and it runs the autoland script synchronously for every single MP that is approved?
<fginther> dobey, yes, that's how it works
<dobey> ok
<dobey> fginther: and puppet isn't being used to manage jenkins config or anything, is it?
<fginther> dobey, nope
<dobey> ok
<balloons> sergiusens, https://code.launchpad.net/~nskaggs/ubuntu-filemanager-app/disable-patch-home-click/+merge/195658. I remember the issue now. The tests fail if your /home directory is full of files I believe
<balloons> I'm running now, we'll see
<sergiusens> balloons, it shouldn't, I added a different count mechanism as well
<sergiusens> balloons, did popey tell you the music app tests fail btw?
<balloons> sergiusens, yes I know you count the files before running
<balloons> sergiusens, yes, I'm looking after this run.
<balloons> the trouble is so many files you'd have to scroll and the tests don't account for that
<sergiusens> balloons, oh, that explains it
<balloons> I think I should just next a folder under home and have the tests do there thing in there
<balloons> *nest
<fginther> robru, kenvandine, can either of you review: https://code.launchpad.net/~fginther/cupstream2distro-config/remove-duplicate-compiz/+merge/195673
<kenvandine> fginther, looking
<kenvandine> fginther, are we sure you should remove lp:compiz instead of lp:compiz/0.9.11?
<kenvandine> fginther, i suspect so
<robru> fginther, kenvandine: I'm not familiar with the 'no-dailies' stack, is that new?
<kenvandine> i'm not either
<fginther> robru, kenvandine "no-dailies" is to hold projects that need upstream merger support but are not part of daily release
<fginther> for various reasons
<fginther> lp:compiz/0.9.11 was updated on 10/22 by timo
<fginther> so it's the "newer one"
<robru> fginther, well, considering that we have been in manual publishing mode for *months* (eg, no dailies EVER), I don't see any value in having a "no-dailies" stack, so anything that makes it smaller looks good to me.
<fginther> robru, kenvandine, the problem is that lp:compiz and lp:compiz/0.9.11 are the same branch. Having two different configs results in upstream merger running 2 different jobs for the compiz MPs
<robru> fginther, ahh ok
<kenvandine> fginther, makes sense
<robru> (I'm not familiar with compiz version numbers)
<robru> fginther, there's also a compiz-0.9.10 in the no-dailies stack as well, should that also be removed?
<fginther> robru, looking
<robru> fginther, oh, no, my mistake. so after your change lands, then no-dailies stack will have lp:compiz/0.9.10 and then head stack will have lp:compiz/0.9.11
<robru> fginther, ok ok, looks good to me, approved.
<fginther> robru, right, they are two different branches in that case
<kenvandine> robru, ubuntu_keyboard passed, trying notes_app again
<robru> kenvandine, hmmm ok. strange, so many flaky tests or weird issues today
<robru> kenvandine, ok, gone for lunch for real this time
<tedg> So it seems that dbus-test-runner has it's own PPA.
<tedg> It is the only person building there.
<tedg> Which, well, sucks.
<tedg> Anyone know why that might be?
<tedg> alesage perhaps?
<alesage> tedg investigating
<tedg> Or, wait, does that mean it gets released normally?
<alesage> tedg not fully grokking the problem there
<tedg> alesage, I need other packages to be able to dep on it.
<alesage> fginther, quick q: does this ppa get added to every build under trusty, at least? https://launchpad.net/~ubuntu-unity/+archive/daily-build
<alesage> or fginther am I recalling a bygone era
<fginther> alesage, yes, that's the default behavior. There are a couple projects configured to *not* do that.
<fginther> tedg, it's probably historical reasons or someone needed to build it for multiple series
<alesage> tedg would you want to transpute your dbus-test-runner to this ppa?  or would indicators et.al. want a separate ppa?
<tedg> I think there should probably one PPA to rule them all.
<fginther> tedg, alesage, there are still some PPAs configured to 'backport' the current trunk
<tedg> So let's get everything pointing there.
<alesage> fginther, tedg but for the record, should what's in this ppa be "fresher" than daily-release?
<tedg> The only reason I'd want a custom PPA is if it could remove my projects from the release craziness.  But I'm guessing that's inescapable.
<alesage> I mean for projects so configured--is dbus-test-runner one?
<fginther> alesage, it's not fresher.  The difference is that only trusty packages are in daily-build, the indicator-staging-ppa has raring, saucy and trusty
<alesage> fginther, o ok I see
<fginther> tedg, alesage, the custom PPAs are really only used to provide trunk to older series, if you don't need that for dbus-test-runner, we should eliminate that step
<tedg> I'm not using the older builds for anything.
<tedg> Seems distro version should be fine on older releases.
<fginther> tedg, thanks
<tedg> fginther, Is it possible to trigger a push of dbus-test-runner trunk until the daily-build PPA?  I'd like to use API that's in trunk.
<fginther> tedg, not directly, that PPA is managed by the daily release tools...
<tedg> Oh, my faves.
<tedg> fginther, Then will we get a daily release to that PPA even if the target PPA isn't there?
<popey> sergiusens: basically only one app passed
<fginther> robru, is the daily release machinery working yet?
<robru> fginther, hahahahhahhahahahaha
<robru> fginther, oh, it probably 'works', sure. but it'll be manually published for the forseeable future
<fginther> robru, what about builds to the daily-build PPA?
<tedg> robru, Let's separate broken process and broken tools :-)
<sergiusens> popey, notes?
<robru> fginther, hmmmm. last time i tried to build friends, it built but the check step failed. so it should be building in the PPA fine.
<sergiusens> popey, well, for the weather app, they lowered the failures by 1
<robru> fginther, haven't had a chance to investigate fully. /still on lunch
<sergiusens> popey, all the terminal ones passed for me
<tedg> Yeah, it looks like Friends hit the PPA about 4h 40m ago.
<fginther> robru, any chance you could build the qa stack?
<robru> fginther, sure
<fginther> tedg, that should get you dbus-test-runner
<popey> sergiusens: let me reboot and re-run all the tests and get you logs
<tedg> Sweet!  Thanks guys!
<robru> tedg, fginther: ok, just started the build. not sure how long it usually takes. watch the PPA I guess (it shows up in the PPA before the job finishes running)
<popey> sergiusens: http://paste.ubuntu.com/6439836/ notes crapped out part way through
 * popey reboots and tries again
<sergiusens> popey, worked fine for me, but I only have maguro
 * tedg hits reload repeatedly to make it build faster
<sergiusens> popey, wait; after you reboot, don't start the tests until mtp is ready
<sergiusens> popey, it will reset your adb connection
<popey> ah
<popey> sergiusens: http://paste.ubuntu.com/6439879/ one failure on notes
<popey> sergiusens: balloons http://paste.ubuntu.com/6439903/ music app 2 fails
<sergiusens> popey, ack, going to run notes tests again
<sergiusens> popey, that said, it's a lot better than current http://reports.qa.ubuntu.com/smokeng/trusty/touch/maguro/23:20131118:20131111.1/5017/notes-app-autopilot/
<sergiusens> popey, and http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/23:20131118:20131111.1/5018/notes-app-autopilot/
<sergiusens> popey, so I'd approve that one regardless if you agree
<sergiusens> popey, you are right, test_delete fails on trusty, but works on saucy for notes app
<sergiusens> popey, the slide emulation isn't enough
<robru> tedg, ok, looks like dbus-test-runner is in the ppa
<tedg> robru, Yup, thanks!  Requeueing all the other builds. :-)
<popey> sergiusens: ok, notes I'll approve
<popey> sergiusens: but not weather or music for now... also, bed
<sergiusens> popey, I'm rerunning weather now, I'll leave a comment on that one :-)
<popey> ok
<sergiusens> popey, thanks for the run!
<popey> will refresh and look in the morning
<popey> thanks
<sergiusens> popey, enjoy sleep while you can!
<popey> :D
<robru> fginther, seems not all is well just yet: http://q-jenkins.ubuntu-ci:8080/job/cu2d-sdk-head-3.0publish/295/console
<robru> fginther, also, it seems like some communication issue between jenkins and test machines? http://q-jenkins.ubuntu-ci:8080/job/cu2d-friends-head-2.2check/253/console shows check job failing because it can't find the junit results from the (successful!) subjob.
#ubuntu-ci-eng 2013-11-19
<Mirv> didrocks: ok desktop tests went fine (one flaky webbrowser on radeon, not on intel), and there are no packaging changes on ui-toolkit. before I publish, could you take a glance on the slightly worrying looking "duplicate" entries of other packages that I'm not going to publish: http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/SDK/job/cu2d-sdk-head-3.0publish/
<didrocks> Mirv: ah, it seems just that the cleanup never happened, not important
<didrocks> Mirv: I suggest that after publishing the sdk, you quick a full stack build to "clean" this up
<didrocks> Mirv: I guess you'll track Mir, just in case there are news? (on your bug, duflu changed the status)
<didrocks> Mirv: do you have a slot available for doing upstart-app-launch?
<Mirv> didrocks: yeah, will do. and tracking, duflu is looking at it again after I pinged him.
<didrocks> thanks!
<didrocks> Mirv: I think we'll kick an image build as soon as you confirm that ubuntu-ui-toolkit is in the release pocket
<Mirv> didrocks: ok, I can do the upstart-app-launch at some point today
<didrocks> great!
<Mirv> didrocks: the sdk publish job just keeps on timeouting/stalling
<didrocks> Mirv: networking issue?
<Mirv> didrocks: maybe, it doesn't say directly http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/SDK/job/cu2d-sdk-head-3.0publish/297/console
<Mirv> and it's still running after 15 mins
<didrocks> Mirv: not related but why did you list some services, like telephony-service, address-book-app, content-hub and not the rest of daily-release components?
<didrocks> cihelp: any idea? 09:15:05     Mirv | didrocks: the sdk publish job just keeps on timeouting/stalling
<didrocks> cihelp: http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/SDK/job/cu2d-sdk-head-3.0publish/297/console
<Mirv> didrocks: so I started by listing components that have a QML plugin since I started with the idea of Qt related PPU, but then again most of those have. so in the end it does miss some of the current cu2d packages, and of course any that are added later.
<didrocks> Mirv: ok, let's do it in 2 rounds
<didrocks> Mirv: ok, I hope my comment for your ppu rights will suit you :)
<Mirv> didrocks: thanks a lot, it does :)
<didrocks> great, you deserve it ;)
<didrocks> Mirv: oh, it's a token issue
<didrocks> Mirv: seems the launchpad cred was changed
<didrocks> ah, it was, of course, the machine changed
<vila> didrocks, Mirv : sounds a lot like the slow network issue has reached q-jenkins. I'm waiting for feedback on that, it's high on the priority list AFAIK if not top
<didrocks> cihelp: we need someone having the creds for the ps-jenkins bot
<didrocks> vila: well, this one is different
<didrocks> as we changed the machine
<didrocks> the launchpad cred is invalidated
<didrocks> so we need to register this machine for ps-jenkins account
<didrocks> Mirv: I'm killing the job btw, it will hang forever I guess
<didrocks> Mirv: can you relaunch a publication please?
<didrocks> I'm logged in as ps-jenkins
 * didrocks tries to unblock production
<didrocks> vila: something to add to the list for the migration: ensuring that the launchpad creds (like ps-jenkins) are refreshed
<vila> didrocks: from the jenkins user ?
<didrocks> vila: ps-jenkins in launchpad
<vila> didrocks: lp side yes, but ci side ?
<didrocks> vila: ci side is using launchpadlib
<didrocks> under jenkins@ on the host
<didrocks> when using launchpadlib, we need to use the credential of ps-jenkins
<didrocks> for being able to do merge proposal
<vila> didrocks: understood
<vila> idcan't remember where those credentials are stored though
<didrocks> vila: well, cu2d tweaks that
<didrocks> but default it's ~/.launchpadlib/
<didrocks> we changed it to /var/lib/jenkins/cu2d/launchpad.cache
<didrocks> in cu2d
<didrocks> (well ~jenkins/cu2d/launchpad.cache)
<didrocks> set as an env variable
<didrocks> but the issue there is that we changed the host
<didrocks> so the cred is found, but doesn't match
<Mirv> didrocks: ok, doing
<Mirv> (republishing)
<didrocks> ok, there is the auth link
<didrocks> and done!
<didrocks> cihelp: ok, I renewed the creds myself
<vila> didrocks: how ?
<didrocks> vila: logged in as ps-jenkins on launchpad
<didrocks> then following that job: http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/SDK/job/cu2d-sdk-head-3.0publish/298/console
<didrocks> there was the authorization link (issued by bzr lp-proposed when using launchpadlib)
<Mirv> right, now it went through
<didrocks> clicked on it
<didrocks> authorized "until I disable it"
<didrocks> and then, it went through
<Mirv> I also opened the last link, but hesitated on clicking
<didrocks> Mirv: yep ;)
<didrocks> Mirv: well, you need to be ps-jenkins on launchpad
<Mirv> didrocks: yeah, that's what I thought
<didrocks> otherwise, the MP will fail :)
<vila> didrocks: and who owns the ps-jenkins credentials on launchpad ?
<Mirv> nice
 * didrocks thinks now about delogging as ps jenkins to not post some "good comments" on lauchpad
<didrocks> what I did a year ago :p
<didrocks> vila: I guess it's now you. It was mostly francis and I before
<didrocks> (you as CI team)
 * vila nods
<didrocks> vila: IIRC, the creds are on the canonical wiki as well
<vila> didrocks: will check with fginther
<didrocks> vila: yeah, I have them stored in my browser creds if needed
 * didrocks back as "didrocks" in launchpad
<vila> didrocks: I am not sure you want to give me access to your browser creds ;)
<didrocks> vila: let me think about itâ¦ humâ¦ NO ;)
<vila> didrocks: as long as q-jenkins is unblocked, I can wait for fginther to sort this out
<didrocks> right, I didn't want that we loose half a day because of this
<vila> didrocks: what I don't get is why we didn't run into that earlier. First publication ?
<didrocks> vila: yeah, first publication
<vila> didrocks: are there any other... "operation" that hasn't been tried at least once ?
<didrocks> vila: well, copying to distro (passing the 2 firewalls and so on)
<didrocks> but it just succeeded
<didrocks> vila: https://lists.ubuntu.com/archives/trusty-changes/2013-November/002397.html
<didrocks> vila: I think now that Mir is almost fixed and once Mirv finishes upstart-app-launch, we'll start rebuilding everything automatically every 8 hours as we used to
<didrocks> that will be the last job to enable
<vila> didrocks: aka manualpublish=False ?
<didrocks> vila: no, this only impacts publication
<didrocks> not building everything
<didrocks> building everything is the *build_all jobs
<didrocks> which starts building all the stacks in order
<vila> didrocks: so still manual publishing. Disabling the *build_all was a q-jenkins only change, nothing to look for in any branch right ?
<didrocks> vila: indeed
<vila> ok
<vila> didrocks: and what was the issue with autopilot-daily-release (sp?) not mentioning the right otto nodes ?
* psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: - psivaa | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move)
<didrocks> vila: not sure to understand, the email I forwarded you or something else?
<vila> didrocks: almost, haven't seen this email before you mentioned it, topic.pushed
<vila> didrocks: but same job
<didrocks> vila: not sure, I didn't look at it. I'll leave it to you guys :)
<vila> didrocks: yesterday it wasn't using the right nodes in the config matrix, couldn't understand why
<didrocks> vila: not sure I was aware about that one
<didrocks> seems the AP tests pass for the sdk here
<vila> didrocks: we did look at it in https://wiki.canonical.com/UbuntuEngineering/CI/NewRelease hence my question, something to add to the playbook when handling cu2d otto nodes no ?
<didrocks> vila: nothing out the existing instructions as far as I know
<vila> didrocks: well, I can of answered myself. I just want you to ack that one so I don't search for some script that is updating that job if there is none ;) (Always hard to find something that doesn't exist ;)
<didrocks> vila: that job was setup initialy by Francis, but I guess he did it manually
<vila> didrocks: ack, thanks
<didrocks> yw
<vila> didrocks: thanks for unblocking that ps-jenkins creds issue.
<didrocks> yw!
<vila> didrocks: if we want to get away from such situations, we need to document them, we have enough in the discussion above to do so. That's my whole point: getting things documented so we don't require human intervention from people in other time zones.
<didrocks> not sure what that was about, but "ok"
 * didrocks told for that on purpose:
<didrocks> 09:36:34 didrocks | vila: something to add to the list for the migration: ensuring that the launchpad creds (like ps-jenkins) are
<didrocks>                   | refreshed
<didrocks> so that it was getting noted down
<vila> didrocks: yup, we're in a violent agreement :)
<vila> didrocks: I asked for clarifications as it wasn't clear to me what the implications were. Last time I ran into such an issue, I was blocked at not being able to access to the browser referred to in the message. I didn't think about launching the browser myself (and would have been blocked by the lack of ps-jenkins creds anyway)
<vila> didrocks: so I thought there was another way to do that from a script (apparently not)
<didrocks> vila: yeah, you would have been blocked by the lack of ps-jenkins creds, but yeah, you can either endure using a local lynx, or use another browser in another machine
<didrocks> vila: well, it's creds to be acked by a human, I don't think launchpad will like if we screenscrap
<vila> didrocks: yeah, I may have been tainted by how u1 do that, there is a way to get an oauth token for them
<vila> didrocks: without using a browser at all, but that's sso not launchpad
<didrocks> yeah, it's not oauth2, it's a special auth per machine/apps
<sil2100> Damn, the pl archive mirror is slow as hell...
<sil2100> Can't upgrade anything
<mardy> hi! Can someone please modify this job, and remove the online-accounts-qt5-staging PPA from it? https://jenkins.qa.ubuntu.com/job/accounts-qml-module-trusty-amd64-autolanding/1/console
<psivaa> mardy: let me take a look
<seb128> does anyone knows why CI is not running on https://code.launchpad.net/~agateau/libdbusmenu-qt/cmake-config/+merge/192895 ?
<seb128> there was a landing failed and a commit to fix it then
<seb128> but it didn't get retried since
<seb128> is that part of the infra supposed to be back?
<psivaa> vila: would you mind reviewing the change, https://code.launchpad.net/~psivaa/cupstream2distro-config/remove-online-accounts-qt5-staging-ppa/+merge/195736 for mardy's request above please?
<psivaa> this is the first time, so apologies if i made any mistakes :)
<mardy> psivaa: however it goes, thanks a lot! :-)
<vila> psivaa: done
<psivaa> vila: thank you
<didrocks> Mirv: ubuntu-ui-toolkit not there yet?
<seb128> hello there?
<seb128> is that the right channel to ask about CI?
<psivaa> seb128: sorry just looking at your issue
<seb128> psivaa, hey, thanks!
<Mirv> didrocks: autopkgtests still running
<didrocks> ok, let's cross fingers :)
<Mirv> didrocks: it seems I'm getting this glitch now both for ui-toolkit (which I approved already manually which worked) and now upstart-app-launch: https://code.launchpad.net/~ps-jenkins/upstart-app-launch/latestsnapshot-0.2+14.04.20131119-0ubuntu1/+merge/195732
<Mirv> and then for cihelp: can you investigate why http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/SDK/job/cu2d-sdk-head-2.2check/394/console is marked as failure even though the tests were green? is that result file not existing a clue?
<didrocks> Mirv: yeah, check with the CI team I guess (for the glitch as well)
<didrocks> ev: can you add those 2 to the list? it's still blocking/slowing down a lot the deliveries ^
<didrocks> (understanding the second one, the first one seems a regression since passing on the new infra, and we can't reapprove every failed MP)
<psivaa> seb128: i've kicked off the job, http://s-jenkins:8080/job/libdbusmenu-qt-autolanding/11/console for more information
<seb128> psivaa, thanks
<ev> psivaa: ^ since you're in vanguard mode, would you mind grabbing that one?
<psivaa> ev: doing that
<Mirv> didrocks: psivaa: ok, thanks for adding.
<ev> thanks muchly
<psivaa> Mirv: the failure is due to the result file being unavailable, but i'm still looking into why that's unavailable
<psivaa> Mirv: it could be a temp issue, thinking of kicking off the master job again if you are ok with it
<Mirv> psivaa: ok, feel free to retry
<psivaa> Mirv: running again, http://q-jenkins.ubuntu-ci:8080/job/cu2d-sdk-head/443/console
<vila> didrocks: back to ps-jenkins creds, the cred file is ~jenkins/.cupstream_cred but launchpad needed to be told that the access should be granted from a new host ? (The cred file itself has not been modified since last year)
<didrocks> vila: ~jenkins/.cupstream_cred is the cu2d cred, not the launchpad cred, right?
<didrocks> vila: not sure, I don't have access to that file
<didrocks> vila: but I know that launchpad have creds per machines
<didrocks> vila: and it seems bzr lp-propose needed that cred
<didrocks> can only tell you that with the FHS access I have
<vila> didrocks: well, not sure, but launchpadmanager.py refers to that file so I'd say that's the cu2d creds to access launchpad
<didrocks> vila: again, it's not cu2d but bzr lp-propose
<didrocks> at this stage
<vila> didrocks: ha, then it may not care about the env var used by cu2d, resuming investigations
<didrocks> psivaa: are you working on the second issue that Mirv discussed and sent to ev? I only see you discussing the -check one
<psivaa> didrocks: ok, i thought that was the second issue
<didrocks> 11:23:04     Mirv | didrocks: it seems I'm getting this glitch now both for ui-toolkit (which I approved already manually which worked) and now upstart-app-launch:
<didrocks>                   | https://code.launchpad.net/~ps-jenkins/upstart-app-launch/latestsnapshot-0.2+14.04.20131119-0ubuntu1/+merge/195732
<didrocks> that one ^
<psivaa> didrocks: i'll take a look at that now
<didrocks> thanks
<Mirv> didrocks: both ubuntu-ui-toolkit and upstart-app-launch now in release pocket
<didrocks> Mirv: \o/
<didrocks> ogra_: when you are around, mind kicking a build?
<ogra_> sure
<ogra_> === Image r24 building ===
<didrocks> thanks ogra_!
<psivaa> seb128: just in case you haven't noticed, the jobs succeeded http://s-jenkins:8080/job/libdbusmenu-qt-autolanding/11/console
<seb128> psivaa, I did notice, thanks!
<psivaa> seb128: yw
<Mirv> cihelp still getting "Unable to connect to naartjie:http:" https://jenkins.qa.ubuntu.com/job/mir-trusty-amd64-autolanding/13/console
<Mirv> repeatedly, https://code.launchpad.net/~vanvugt/mir/fix-1252144-v2.trunk/+merge/195718
<psivaa> Mirv: similar issue to what we saw yesterday
<psivaa> Mirv: i'll take a look at that
<Mirv> thanks psivaa
* ev changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: - psivaa (http://goo.gl/zSO6I0) | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move)
<retoaded> Mirv, the node that job was run on should be able to hit naartjie now. Had a static (and old) entry for naartjie in it's /etc/hosts
<Mirv> thanks retoaded, trying again
<retoaded> Mirv, now as long as the VM doesn't "revert" the /etc/hosts entries right back into place.
<psivaa> Mirv: i already kicked one off
<Mirv> psivaa: ok
<psivaa> and it failed for the same reason..
<psivaa> when fginther tried it yetsterday it worked. something flaky.. ill run it again
<retoaded> psivaa, did it run on the same host as the previous run?
<Mirv> it never succeeded at https://code.launchpad.net/~vanvugt/mir/fix-1252144.trunk/+merge/195547 and I ended up merging it manually yesterday
<mardy> psivaa: are you waiting for more reviews, or can you set https://code.launchpad.net/~psivaa/cupstream2distro-config/remove-online-accounts-qt5-staging-ppa/+merge/195736 as approved?
<psivaa> Mirv: it was an armhf run but failing to reach naartjie was the issue
<psivaa> retoaded: the nodes were different
<psivaa> mardy: i think i can top approve it too, and merge it
<psivaa> retoaded: the latest amd64 failure to reach naartjie is from ps-precise-server-amd64-smp-2
<retoaded> psivaa, my guess would be that the problem is twofold: (1) most of the VMs have an incorrect (old) entry for naartjie in their /etc/hosts file and (2) the VMs that have snapshots will revert back to their original state so removing the entry from a running VM won't necessarily work for the next run
<retoaded> psivaa, that would prove point 2 since that was the VM I had just changed.
<psivaa> retoaded: ohh, so the vms snapshots need to be changed
<retoaded> psivaa, for some of these.
<psivaa> quite a job i suppose
<retoaded> I'm in ps-precise-server-amd64-smp-2 now and it wasn't reverted and CAN connect to naartjie
<psivaa> mardy: i've merged the change, and kicked off another run http://s-jenkins:8080/job/accounts-qml-module-trusty-amd64-autolanding/2/console
<Mirv> feel free to try to get https://code.launchpad.net/~vanvugt/mir/fix-1252144-v2.trunk/+merge/195718 merged
<psivaa> retoaded: which host are these ps-precise-server-amd64-smp-2 like vms are on?
<mardy> psivaa: thanks a lot
<ogra_> === Image r24 DONE ===
<popey> \o/
<mardy> psivaa: mmm... it seems that the PPA is still there :-( https://jenkins.qa.ubuntu.com/view/Trusty/view/All/job/accounts-qml-module-trusty-amd64-autolanding/lastFailedBuild/console
<psivaa> mardy: yea, looking why the change dint take into effect
<psivaa> Mirv: you might have noticed that http://q-jenkins.ubuntu-ci:8080/job/cu2d-sdk-head-2.2check/396/console is still having the same issue,
<psivaa> would need fginther again i'm afraid
<psivaa> mardy: http://s-jenkins:8080/job/accounts-qml-module-trusty-amd64-autolanding/4/console
<mardy> psivaa: \o/ thanks!!
<Mirv> psivaa: yep, please keep that one too on the radar
<psivaa> Mirv: ack. that's on my list to discuss this afternoon.
<didrocks> ev: vila: Mirv: ogra_: coming?
<Mirv> didrocks: aha, the new time
<Mirv> yes
<cwayne_> Mirv, thanks for getting the upstart-app-launch landed :D
<Mirv> cwayne_: you're welcome
* cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: - cjohnston | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move), network slowness
<fginther> morning
<Ursinha> fginther, morning
<josepht> good morning
<fginther> Mirv, psivaa, I found an old /etc/hosts entry that was breaking the mir-autolanding. Re-testing
<sil2100> fginther: hello!
<didrocks> cihelp: I can't start http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/All/job/cu2d-build_all-head/, seems the network is timing out
<sil2100> fginther: do you know if the merger is enabled for unity-scopes-api?
<didrocks> cyphermox: FYI, we are blocked by that ^
<cjohnston> didrocks: you can try it again, but we are still having network issues
<didrocks> cjohnston: yeah, so it means we can't start cu2d due to that
<cjohnston> what's the url it is trying to open?
<didrocks> cjohnston: accessing launchpad it seems from the console
<didrocks> hum, no jenkins in fact?
<didrocks>     response = self.jenkins_open(urllib2.Request(self.server + JOB_INFO%locals()))
<didrocks> I bet self.server is refering an old ip
<didrocks> cjohnston: are you handling it or should I? ^
<cjohnston> didrocks: I'm looking into it, but don't really know what I'm looking at.. jenkins seems to have the correct address setup
<cjohnston> is it in one of the config branches?
<fginther> Mirv, psivaa, lp:cupstream2distro needs update, it assumes jenkins jobs are archived under â/var/lib/jenkinsâ. The jenkins root was moved to â/iSCSI/jenkinsâ
<fginther> Mirv, psivaa this is causing the cu2d-sdk-head-2.2check failures
<didrocks> fginther: they are still archived in /var/lib/jenkins, right?
<vila> fginther: which are both ~jenkins
<didrocks> ah
<psivaa> fginther: ok, thanks
<vila> fginther: or not ?
<didrocks> cjohnston: I guess it's in cu2d
<fginther> sil2100, ahh, getting to it now
<didrocks> cjohnston: in the code referenced in the console
<didrocks>         self.jenkins_url = "%s/job/%%s/buildWithParameters?token=%s" \
<didrocks>                     % (self.jkcfg['url'], self.jkcfg['token'])
<sil2100> fginther: thank youu! Could you also do the same for unity-scopes-shell if you have a moment?
<didrocks> built from JKCFG
<didrocks>     JKCFG = load_jenkins_credentials(DEFAULT_CREDENTIALS)
<xnox> OTA updates should be renamed to "didrocks updates" =)
<sil2100> fginther: it's not added to cu2d though yet...
<kenvandine> xnox, indeed
<didrocks> xnox: heh, seems so ;)
<didrocks> def load_jenkins_credentials(path):
<didrocks>     cred = yaml.load(file(path, 'r'))
<didrocks> DEFAULT_CREDENTIALS = os.path.expanduser('~/.cu2d.cred')
<didrocks> ok, so that's what need to be updated
<didrocks> vila: cjohnston: so ~jenkins/.cu2d.cred
<didrocks> I guess we need to change the url
<didrocks> so match the new jenkins instance
<didrocks> can one of you do that please? ^
<cjohnston> workin on it
<didrocks> thanks!
<didrocks> cjohnston: then, can you try relaunch the job? it should work then
<cjohnston> grr
<cjohnston> fginther: do you have sudo on q-jenkins?
<fginther> cjohnston, nope
<cjohnston> hrm
<cjohnston> retoaded: ^
<fginther> sil2100, do you have an MP for unity-scopes-shell?
<retoaded> cjohnston, on it
<retoaded> cjohnston, done
<vila> cjohnston: we need to document that, I left a req for fginther about lp credentials for ps-jenkins already but this seems to be a new file (and I'm already knee deep in dx-autopilot-nvidia re-provisioning)
<fginther> Mirv, psivaa, filed a bug for the path update: https://bugs.launchpad.net/cupstream2distro/+bug/1252750
<ubot5> Ubuntu bug 1252750 in Canonical Upstream To Distro "atest_autopilot_results hardcodes a jenkins root directory" [Undecided,New]
<cjohnston> retoaded: while your in there could you please give me sudo?
<vila> didrocks: how come we're talking about a different creds file  now ? I didn't mention that one this morning because IIRC jibel is mentioned in .cu2d.cred and I thought that was an obsolete file since you unblocked a different job
<didrocks> vila: this is the "build all"
<didrocks> vila: what we didn't run yet
<didrocks> as told this morning
<didrocks> vila: this is not a launchpad cred
<didrocks> but the cu2d creds
<retoaded> cjohnston, done
<vila> didrocks: and what about .cu2d.jenkins and .cupstream_cred ?
<didrocks> vila: not having access to the file system in read mode, I can't tell you
<cjohnston> ta
<cjohnston> didrocks: running
<didrocks> cjohnston: \o/ let's cross figners
<didrocks> fingers*
<didrocks> ok, everything triggered now
<didrocks> let's see how the network will support that :)
<didrocks> cyphermox: FYI (as you are tracking indicators) ^
<didrocks> cyphermox: can you ask seb/add yourself a landing task for tracking this request?
<cyphermox> alright
<didrocks> thanks!
<didrocks> cjohnston: thanks for making the change ;)
<cjohnston> didrocks: :-)  still need help sometimes, but best way to learn is to do
<didrocks> yep!
<cyphermox> done
<cyphermox> which slot?
<didrocks> cyphermox: just add one
<didrocks> (but pick a cool one! ;))
<cyphermox> 312
<cyphermox> but I mean the landing slot or whatever
<cyphermox> column two?
<didrocks> cyphermox: ah, next image (so 25)
<didrocks> if possible
<cyphermox> aye
<didrocks> cyphermox: of course, needing dogfooding :)
<cyphermox> yeah yeah
<cyphermox> dogfooding is what I do :)
<Mirv> hmm, who started mir stack build? the merge is not yet in.
 * didrocks waits for catfooding
<cyphermox> nummy
<didrocks> Mirv: we restarted to build everything to test the infra
 * Mirv notices the queue
<didrocks> Mirv: I guess Mir will need to be rebuild once the merge is in
<Mirv> alright :)
<cyphermox> speaking of catfooding, I need to get breakfast
<didrocks> cypherfooding
<seb128> didrocks, cyphermox: do you know why those sort of things happen? https://code.launchpad.net/~ps-jenkins/ubuntu-system-settings/latestsnapshot-0.1+14.04.20131119-0ubuntu1/+merge/195787
<didrocks> seb128: yeah, vila and fginther are looking at those
<seb128> didrocks, should we retry the approval there?
<didrocks> seb128: seems we lost a patch in the migration in bzr, fginther will do it in another way
<seb128> ok
<didrocks> seb128: well, that will work, but that won't help them testing their change I guess
<seb128> I'm just going to wait for them to fix it then
<didrocks> I think that fginther and vila will relaunch the failing one then ^
<fginther> didrocks, seb128, ack. Once we get it sorted we'll process the failed ones
<ev> cwayne_: reposting here
<ev> 3:42 PM <cwayne_> ev, any idea why nasuka can't get to s-jenkins still?
<ev> nope, but I'm trying to coordinate a UDS session, so asking our vanguard, cjohnston
<ev> cjohnston: I tried to fix this with https://code.launchpad.net/~ev/canonical-is-puppet/ci-fw-rules but there's apparently something I'm missing :)
<cjohnston> cwayne_: can I get more context please?
<cwayne_> cjohnston, it needs to poll s-jenkins to get the customization tarball to build customized images
<cjohnston> cwayne_: is this a jenkins instance that does this or?
<cwayne_> cjohnston, trying to loop in stephane as he knows more than i do
<cwayne_> but my understanding is system-image polls s-jenkins to get the latest custom tarball then builds it
<cwayne_> cjohnston, it being the image
<cwayne_> cjohnston, <stgraber> cwayne_: nusakan can't talk to s-jenkins, I don't have any more detail than that
* doanac` changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: - doanac | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move), network slowness
<cjohnston> cwayne_: this appears to be an issue for IS
<cwayne_> cjohnston, can you get me some information so that i know what to ask is?
<fginther> sil2100, can you also review these 2:
<fginther> https://code.launchpad.net/~fginther/cupstream2distro-config/add-mediascanner-v2/+merge/195662
<fginther> https://code.launchpad.net/~fginther/cupstream2distro-config/unity-7.1/+merge/195663
<sil2100> fginther: looking!
<sil2100> fginther: do you know why the saucy support branch changed to /7.1 ?
<ev> heads up: we're discussing the new architecture for the CI system in http://summit.ubuntu.com/uds-1311/meeting/22092/core-1311-ci-airline/
<ev> right now
<fginther> sil2100, I think the unity team started using that w/o knowing lp:unity/saucy was there
<sil2100> ah, ok
<sil2100> fginther: I'll be approving the unity cu2d merge in a moment :)
<Mirv> kenvandine: robru: I updated the landing plan to reflect that the (another) mir fix was now finally merged so it should be possible to try building the chain (although cu2d is now a bit busy)
<kenvandine> Mirv, so what needs rebuilding now?
<Mirv> kenvandine: first mir, and then platform-api, unity-mir and unity-system-compositor against it. then it should be ready to test.
<robru> kenvandine, do you have that under control? I'm on my way out for lunch but I can help test when I get back.
<kenvandine> robru, i'm on my way out too
<kenvandine> robru, lets sync up after lunch
<ev> cjwatson, didrocks: I couldn't find a space you'd both fit in for the CI airline implementation UDS session, so I'll schedule it for after UDS
<cjwatson> OK, thanks
<didrocks> ev: yeah, my track is full, so after UDS sounds good
<vila> didrocks, Mirv: https://code.launchpad.net/~vila/cupstream2distro-config/no-nvidia/+merge/195838
<vila> autopilit-nvidia is coming back
<didrocks> vila: this time, you are handling the deployment of it right?
<didrocks> vila: btw, on your MP, you changed raring
<didrocks> this is harmless but useless as well
<didrocks> those otto machines won't run raring changes, right?
<vila> didrocks: deploying will require me to be part of desktop-team right ?
<didrocks> vila: no, you can redeploy with -US
<vila> didrocks: I strictly reverted my first proposal
<didrocks> vila: you just need the cu2d creds
<didrocks> vila: yeah, and I already wrote that on IRC in the first proposal
<didrocks> (but it was already merged)
<didrocks> vila: please don't deploy stacks that are running, remember the jenkins limitation around running jobs while deploying
<vila> didrocks: ha, the ones fginther and I suspect are invalid and not used anymore because your team deploy from their desktop ? ~jenkins/.cu2d.jenkins ?
<vila> didrocks: yeah, right, will sync with Mirv tomorrow morning then, safer and easier
<Mirv> vila: yes, let's look at it in the morning
<didrocks> vila: I only know about ~/.cu2d.cred
<didrocks> not .cu2d.jenkins
<om26er> fginther, got a minute ?
<didrocks> (and it's about running a stack as well, it's not only deploying)
<vila> didrocks: ack, thanks, will take the opportunity to investigate a bit then, fginther thought ~jenkins/.cu2d.jenkins was exactly for that: updating jobs
<didrocks> not that I know of
<vila> didrocks: ack
<robru> kenvandine, back yet? I'll be watching a UDS session but can kick a build if necessary
<kenvandine> robru, it's building
<kenvandine> finishing now :)
<robru> kenvandine, so looks like mir built but unity-system-compositor failed, and platform-api is still in progress. just waiting for platform-api then? or do we need u-s-c?
<kenvandine> robru, humm... i hadn't built those yet
<kenvandine> they needed new mir
 * kenvandine starts it
<robru> kenvandine, well it looked to me like somebody just kicked the whole mir stack, which includes u-s-c, but that failed
<kenvandine> it failed 41m ago though
<kenvandine> the mir build wasn't published yet in the PPA
<robru> kenvandine, says published 36 minutes ago for me.
<kenvandine> right
<kenvandine> the failure was 41m ago
<kenvandine> 48 now
<robru> kenvandine, wait, what? if the build failed 50m ago, then were did the upload in the PPA come from?
<kenvandine> from prior to that
<kenvandine> i did a run with just mir
<kenvandine> not the whole stack
<robru> kenvandine, ugh: https://launchpadlibrarian.net/156925071/buildlog_ubuntu-trusty-amd64.unity-system-compositor_0.0.1%2B14.04.20131119-0ubuntu1_FAILEDTOBUILD.txt.gz boost!
<kenvandine> robru,  that was from an upload from 3 hours ago
<kenvandine> ignore that
<robru> heh
<kenvandine> crap
<kenvandine> now the amd64 upload i just did failed :/
<kenvandine> same failure :(
<kenvandine> boost1.54 is held in proposed
<fginther> om26er, pong
<om26er> fginther, here: https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/3451/console it seems to not able to install unity8-autopilot. Can you think of a reason why it was not ?
<robru> kenvandine, so what then? we have to wait for this boost transition to complete?
<fginther> om26er, looking
<kenvandine> robru, lets look at why it's held
<robru> kenvandine, how?
<kenvandine> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<kenvandine> look at boost1.54
<kenvandine> those are the deps that need transitioning
<kenvandine> lets narrow that down by seeing what's already been uploaded to proposed
<robru> kenvandine, so what, those need no-change rebuild uploads?
<kenvandine> maybe
<kenvandine> usually
<kenvandine> sometimes they might need build deps changed
<kenvandine> like libboost1.53-dev to libboost1.54-dev
<kenvandine> but i hope not
<kenvandine> boost is annoying
<robru> kenvandine, yeah, I've had lots of bad experiences with boost in the past
<kenvandine> although
<kenvandine> this is just an ubuntu rev
<kenvandine> not major version
<kenvandine> i just enabled proposed on my laptop, to see what complains
<fginther> om26er, ah
<fginther> om26er, the unity8 armhf build failed in the PPA
<om26er> darn
<fginther> om26er, https://launchpad.net/~ubuntu-unity/+archive/daily-build/+packages?batch=75&memo=225&start=225
<fginther> om26er, I'll try to rebuild it
<om26er> fginther, thanks :)
<fginther> om26er, but I don't have permissions :-( let me find someone who can
<fginther> sil2100, kenvandine, cyphermox can one of you look at the unity8 armhf build in the daily PPA? It failed to build, can it be retried?
<cyphermox> sure I'll look
<sil2100> cyphermox: thanks!
<fginther> cyphermox, looks like unity-mir armhf failed also
<cyphermox> right
<cyphermox> and that's why unity8 failed
<cyphermox> I'm retrying unity-mir to see, but I think all of the unity stack needs to be rebuilt now that platform-api has changed / been uploaded to the PPA
<robru> kenvandine, something is goofy with the timestamps here. your latest rebuild says mir built fine 30 mins ago, but ppa only has mir from 1hr ago
<kenvandine> boost-mpi-source1.54 needs a rebuild
<kenvandine> robru, the PPA finished building before cu2d noticed it was built
<kenvandine> it checks every 5 minutes
<kenvandine> and it only notices after it has been published in the PPA
<kenvandine> so a bit after the build finishes
<robru> kenvandine, so checking every 5 minutes means that it finished in the PPA 30 minutes before jenkisn notices?
<kenvandine> robru, oh... that time is when the package was uploaded
<kenvandine> source that is
<kenvandine> not when the build finished
<robru> kenvandine, it says "Published: 1 hour ago" https://launchpad.net/~ubuntu-unity/+archive/daily-build/+packages?field.name_filter=mir&field.status_filter=published
<kenvandine> this is annoying... the boost-mpi-source1.54 binaries depend on binariers from the boost1.54 package, but $Binary:Version
<kenvandine> robru, yeah, that is when the source was published
<robru> kenvandine, oh, ok
<kenvandine> not when the binary was published
<robru> kenvandine, so do you have to distropatch it to be $Source:Version?
<cjwatson> boost-mpi-source1.54 requires careful manual handling
<cjwatson> ask xnox to help you
<kenvandine> robru, he's handling it
<cyphermox> fginther: right, unity-mir passed to I'll have unity8 and unity-mir rebuilt now
<fginther> cyphermox, thanks!
<sergiusens> doanac`, hey, any insight why the clicks failed so badly? They worked fine on yesterday's latest proposed
<doanac`> sergiusens: let me take a look. plars have you happened to investigate that already?
<plars> doanac`: no hadn't looked yet
<doanac`> i'll poke around
<sergiusens> doanac`, thanks
<doanac`> sergiusens: here's one that looks like a legitimate regression to me: http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/24:20131119:20131111.1/5037/ubuntu-weather-app-autopilot/521212/
<sergiusens> doanac`, fwiw, the weather app has more tests now ;-)
<sergiusens> doanac`, and the whole swipe to delete thing has caused many apps to be an inconsistent state
<doanac`> sergiusens: you mean we should have run more tests for that today?
<sergiusens> doanac`, they pass merger I think because fginther has the proposed PPA for testing/building, but the image of course doesn't :-)
<sergiusens> doanac`, actually, weather is an improvement :-)
<sergiusens> doanac`, http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/23:20131118:20131111.1/5018/ubuntu-weather-app-autopilot/ vs http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/24:20131119:20131111.1/5037/ubuntu-weather-app-autopilot/
<doanac`> rss and filemanager seem to have regressed
<doanac`> i'm seeing some "StateNotFoundError" for filemanager
<sergiusens> doanac`, filemanager has regressed for a while, the ap 1.4 thing never finished for it I think
<sergiusens> doanac`, I wrote that in the transition pad
<sergiusens> doanac`, this is the one that worries me: http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/24:20131119:20131111.1/5037/notes-app-autopilot/
<sergiusens> doanac`, rssreader as well as it had only one fail on my device after multiple runs; and the one on the image had 2 atm
<doanac`> sergiusens: ooh, that's no good. I've seen that locally where notes-app takes forever to run
<doanac`> its timing out after 30 minutes
<sergiusens> hey, I just noticed "Result History"
<sergiusens> awesome
 * doanac` came up with that :)
<sergiusens> doanac`, kudos
<sergiusens> doanac`, so this all coincides with a uitoolkit version upgrade as well; might be that some tests need updating.
<doanac`> sounds quite possible
<robotfuel> rfowler: ping
* doanac` changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: - cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move), network slowness
<kenvandine> robru, i'll probably be gone when boost gets promoted
<kenvandine> robru, you don't need to run the stack to get it to build, just click rebuild for each of the failed builds in the PPA
<robru> kenvandine, no worries. I'm here for hours yet. I'll kick builds soon
<robru> kenvandine, or that ;-)
<kenvandine> once it's built in the PPA testing can start
<kenvandine> and then you could do a stack run so it shows up in the publish job
#ubuntu-ci-eng 2013-11-20
<rsalveti> will trigger a new image so I can have a working emulator
<plars> something happened with the download taking way too long for the latest image it seems... I restarted them, so results should start to show up in a bit
<Mirv> good morning
<Mirv> robru: I'll test unity8 AP too..
<Mirv> robru: I've gotten sometimes problematic results where another run(s) have been fluent
<Mirv> cihelp daily-release-executor is reported offline
<Mirv> so all builds halted as well
<rsalveti> plars: there was a regression in the recovery image, which is fixed in the archive but needs a newer image
<rsalveti> not sure if the regression would cause the device to fail in someway
<didrocks> Mirv: hey! around already? :)
<didrocks> cihelp: hey, all executors on q-jenkins are down, (so everything is blocked). Seems the reason why robru/ken couldnt publish Mir yesterday
<vila> didrocks, Mirv: on it
<didrocks> thanks
<didrocks> vila: I guess the daily-release executor is the first one to investigate why it went down
<vila> didrocks: yes, Mirv said that already, we all agree
<Mirv> didrocks: yeah, as written on langing plan
<Mirv> didrocks: robert also had some unity8 AP problem, but I couldn't reproduce it so it's probably his environment (like wrongly updated unity8 from daily-build, or click tests being run and messing up unity8 testing)
<didrocks> Mirv: ah, the notes were not from yesterday
<didrocks> Mirv: yeah, probably
<didrocks> Mirv: I'm not sure to understand the unity-mir rebuild?
<didrocks> if it wasn't rebuilt already, you can't test, right?
<Mirv> didrocks: the mir 0.1.1 build-dep was not in, otherwise it's ok. same for u-s-c.
<didrocks> Mirv: ah, it's just the bump build-dep MP
<didrocks> Mirv: well, if we release without that one, I won't die TBH ;)
<didrocks> as long as the things are rebuilt as expected
<Mirv> didrocks: ok ;) yeah the libmirserver10 dependency is there anyway, as it was built after the mir build
<didrocks> Mirv: ok, just don't stress on that, if you feel that we should skip the build, please do (if we are ready to publish)
<didrocks> ogra_: asac: did one of you requested a new image?
<didrocks> ogra_: asac: I see a new image and 2 android uploads in particular to the archive (the second to fix a regression it seems)
<Mirv> didrocks: ok. we're ready to publish, aside from that I don't see a note if unity-system-compositor was smoke tested.
<Mirv> so that needs to be done still
<didrocks> ogra_: asac: but the image which was built was between the 2 android uploads, so the "recovery regression" is in the current proposed image?
<didrocks> Mirv: ok, maybe you should kill in jenkins if there are some mir/platform/unity8 stacks planned to be rebuilt?
<didrocks> so that one q-jenkins is repaired, you are not trapped by a rebuild :)
<Mirv> didrocks: yes, I did that already
<Mirv> (except for platform it seems, now did that too)
<didrocks> thanks Mirv :)
<didrocks> waow, it's snowing here
<Mirv> didrocks: cool, it's just rain currently here :)
<Mirv> I'd welcome snow already, it's been unusually warm (which means also dark)
<didrocks> Mirv: well, I think it'll transform soon in rain as well :)
<didrocks> ah ah, for some kind of "warm" ;)
<didrocks> here, for us, it's freezing (like we have the temperature we do have generally in 3 weeks)
<vila> daily-release-executor is back
<didrocks> thanks vila
<Mirv> ok got to the desktop with updated mir + u-s-c too
<didrocks> Mirv: and still get graphics? ;)
<Mirv> didrocks: even that :) not much multimonitor though
<didrocks> Mirv: not a surprise, but not a bad surprise either :)
<didrocks> sweetness!
<Mirv> didrocks: the mir stack had already queued the prepare tasks before daily release executor broke earlier, so they got rebuilt. mir is a no-change rebuild and u-s-c got now the mir 0.1.1 b-d in. I'm rerunning unity8 AP still and after then asking for packaging acks to publish.
<didrocks> Mirv: sounds good, just do minor dogfooding
<didrocks> don't stress it too much in some words :)
<didrocks> thanks!
<Mirv> didrocks: ok then, http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/Mir/job/cu2d-mir-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_mir_0.1.1+14.04.20131120-0ubuntu1.diff + http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/Mir/job/cu2d-mir-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_unity-system-compositor_0.0.2+14.04.20131120-0ubuntu1.diff + http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view
<Mirv> so the actual u-s-c session moved to ubuntu-desktop-mir which I already noticed
<didrocks> Mirv: sorry, my system is in autodestruction mode after removing the emulator, I can't use sudo, ls or any other tool like chromium, can you get someone to review it?
<didrocks> I can't even open a webpage
<Mirv> didrocks: ok, have a nice debugging session..
<didrocks> well, nice with no "ls", I hope that my home dir is still intactâ¦
<asac> didrocks: from backlog:
<asac> 09:59 < -bip> 20-11-2013 00:08:09 -!- alesage!~alesage@c-98-212-4-39.hsd1.il.comcast.net has quit  [Quit: Leaving]
<asac> 09:59 < rsalveti> 00:15:21> will trigger a new image so I can have a working emulator
<asac> :/
<didrocks> asac: well, and no second image with "recovery fixed"
<didrocks> right?
<didrocks> or did you find anything in the backlog?
<asac> didrocks: let me look more careful :)
<didrocks> asac: let's discuss in a few, my install is broken by the emulator I guess
<asac> 09:59 < plars> 03:25:24> something happened with the download taking way too long for the latest image it  seems... I restarted them, so results should start to show up in a bit
<asac> 09:59 < rsalveti> 05:33:30> plars: there was a regression in the recovery image, which is fixed in the  archive but needs a newer image
<asac> 09:59 < rsalveti> 05:33:42> not sure if the regression would cause the device to fail in someway
<asac> didrocks: next line spoken here was you pinging Mirv
<asac> so guess not
<asac> though the need for an image was identified
<asac> didrocks: so feels we want another image? whatelse happened in the meantime?
<didrocks> asac: yeah, I guess we want one (but again, I can't even ls right now, let me fix my box)
<didrocks> and post a warning if it's really due to the emulator replacing libc6 with the armhf version on your system
<asac> didrocks: ok. guess just boot in a live session and fix it from there
<asac> :/
<didrocks> asac: I'm trying with busybox here
<asac> or from initrd if you are brave
<asac> yeah
<didrocks> but dpkg from busybox doesn't show which arch is installed :p
<asac> didrocks: guess check in /var/lib/dpkg on your own
<didrocks> 2013-11-20 09:48:34 status half-configured libc-bin:amd64 2.17-93ubuntu4
<didrocks> from removing the emulator
 * asac wonders what the emulator does that can cause this
<seb128> didrocks, weird, usually app ask you to type the "yes, I'm sure I want to do that" before removing libc-bin
<didrocks> seb128: I think it didn't remove, it has overriden with the armhf version
<didrocks> seb128: I clearly didn't get "remove libc6"
<asac> half-configured probably means that things fell over during upgrade
<didrocks> ok, busybox didn't work from my needs, let me try to find an usb stick and fix from there
<didrocks> yeah
<didrocks> I guess there are some divert magic for the emulator
<asac> didrocks: where did you get the emulator from?
<didrocks> and something when went on removing
<asac> ack
<didrocks> asac: followed the wiki page
<didrocks> (but then, tried to remove the android-emulator package)
<seb128> I hope other people don't try the emulator
<didrocks> well, it's not 100% confirmed, but it was the only thing I was doing at this time
<seb128> didrocks, do you want me to follow up on the list to "be careful, Didier bricked his system with that"?
<asac> didrocks: you hvae a URL to the wiki?
<didrocks> seb128: would be nice to have someone confirming (in a vm first)
<didrocks> asac: well, I just have a weechat window here :p it was on the ML
<asac> kk
<didrocks> ok, see you (hopefully) in a few
<seb128> asac, https://wiki.ubuntu.com/Touch/Emulator
<didrocks> you should try on amd64 to reproduce, as jibel noted, it's probably a i386<->amd64 issue
<didrocks> so seb128 is safe, you can try in production! :p
<seb128> lol
<asac> it refers to an android-emulator package
<asac> but thats noot in the archive... which ppa is it?
<jibel> asac, binaries are only available for i386
<jibel> in the archive
<seb128> asac, it's in multiverse for i386
<seb128> https://launchpad.net/ubuntu/+source/android/20131120-0225-0ubuntu1
<asac> oh its part of android
<asac> yeah i can imagine that that might cause accidential havoc
<seb128> on i386 it wants to install libc6-amd64
<seb128> not sure I want to risk trying on my system :p
<asac> so the package doesnt look harmful by itself
<jibel> trying in an amd64 VM, it's installing 723MB of i386 packages
<asac> seb128: it includes stuff like: ./usr/share/android/emulator/out/host/linux-x86/bin/emulator64-arm
<asac> so it somewhat makes sense that it brings in amd64 stuff
<didrocks> Commandline: apt-get install android-emulator
<didrocks> Install: android-emulator:i386 (20131120-0225-0ubuntu1), lib64gcc1:i386 (4.8.2-1ubuntu2, automatic), lib64stdc++6:i386 (4.8.2-1ubuntu2, automatic), libc6-amd64:i386 (2.17-93ubuntu4, automatic)
<didrocks> (that was what I had)
<didrocks> and it worked after that, it's really when I removed the package and autoremove the deps
<seb128> asac, it's a bit weird that it's an i386 package and that it pulls in amd64 binaries
<jibel> didrocks, I reproduced your problem
<asac> http://paste.ubuntu.com/6447226/
<jibel> and broke the VM after removing the emulator
<jibel> asac, ^
<seb128> jibel, can you paste the log of what apt did when you removed the emulator?
<asac> right. that would be good to know
<jibel> seb128, sure
<didrocks> jibel: ah, so not rebooting immediatly, would be interesting to get your VM fix rather than me being offline :)
<jibel> didrocks, indeed, 1 minute
<didrocks> (ok, just finished getting an usb stick ready with an old trusty image)
<asac> so the emulator package has nothing in the postrm postinst scripts
<asac> so the bustage must come genuinely from apt and libc6-amd64 removal
<didrocks> right
<asac> my guess is that if i just instlal libc6-amf64 and remove it will also be broken
<jibel> seb128, http://paste.ubuntu.com/6447229/
<asac> -> e.g. if thats the case thats a doko bug, no?
<didrocks> at least, I'm looking at busybox dpkg and it doesn't have a lot of options
<didrocks> asac: you're probably right, indeed
<jibel> seb128, asac to reproduce on an amd64 VM, dpkg --add-architecture i386 && apt-get update && apt-get install -y android-emulator && apt-get autoremove --purge android-emulator
<asac> libstdc++6:i386*
<asac> odd.
<didrocks> yeah, so it probably removed the libc6-amd64 files configured to be used against
<didrocks> and then, can't run the postrm script to configure the new links?
<asac> jibel: can you reproduce by just installing the libc-amd64 and purging that?
<asac> (in case you have a VM image easily available)
<jibel> asac, hold on, I'm trying to recover the system first to help didrocks save his machine
<didrocks> I would appreciate, indeed :)
<asac> sure
<seb128> that package has a postrm
<seb128> if [ "$1" = remove ]; then
<seb128>     ARCH=${DPKG_MAINTSCRIPT_ARCH:-$(dpkg --print-architecture)}
<seb128>     if [ "${ARCH}" = "amd64" ] && [ "libc6-amd64" = "libc6-i386" ]; then
<seb128> 	if [ -h /lib/ld-linux.so.2 ] && [ ! -f /lib/ld-linux.so.2 ]; then
<seb128> 	    rm /lib/ld-linux.so.2
<asac> however, maybe first narrowing it down will help :)
<asac> greedilyu removing ld-linux
<didrocks> hum, I still have /lib/ld-linux.so.2 here
<asac> seb128: that only happens on amd64, no?
<asac> i think that might not be it
<didrocks> but the postrm failed itself
<didrocks> so it's not executed
<didrocks> (as per log)
<asac> all those postrm fail
<didrocks> right
<asac> seems stuff is already busted after prerm
<didrocks> yep
<asac> and after just removing the files
<asac> int he packages
<asac> maybe having the log from installing might show some diversions
<asac> etc.
<didrocks> I guess when removing libc6-amd64 files
<ogra_> are you 100% sure the last android build made it into the image ?
<jibel> asac, trying now
 * ogra_ sees that publishing and image build are very close 
<didrocks> ogra_: was it supposed to be reflected in your diff?
<ogra_> no
<ogra_> the android package isnt inside anywhere
<ogra_> so the manifest generator cant pick it up
<ogra_> Get:1 http://ftpmaster.internal/ubuntu/ trusty/multiverse android all 20131120-0225-0ubuntu1 [348 MB]
<ogra_> Fetched 348 MB in 48s (7243 kB/s)
<ogra_> ok, seems it made it
<ogra_> (you can find it in the livefs build log)
<ogra_> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/trusty/ubuntu-touch/20131120.1/livecd-20131120.1-armhf.out
<didrocks> ogra_: I guess you need a new image then
<ogra_> ?
<didrocks> ogra_: see the followup android upload at 5 UTC
<ogra_> 20131120-0225-0ubuntu1 is the last upload
<didrocks> ah, you got with that one?
<ogra_> see above
<didrocks> ogra_: can't click on links right now :p
<didrocks> if you follow what was discussed, system hosed ^
<jibel> asac, confirmed: apt-get install libc6-amd64 && apt-get remove libc6-amd64
<jibel> and get a broken system for free
<didrocks> I would have prefered to not have it at all than for free ;)
<didrocks> thanks for digging jibel :)
<ogra_> didrocks, yeah
<asac> jibel: thats on i386?
<jibel> asac, amd64 with i386 enabled
<jibel> which is the same cofigiration than didrocks. I can try on i386 too
<asac> kk
<asac> dont worry. guess file a bug so we can have doko etc. look at it
<jibel> k
<Mirv> didrocks: I filed bug #1253008 about pitti's worry about u-s-c configuration file removal (or actually it's a move to another package)
<ubot5> bug 1253008 in Unity System Compositor "Clean configuration file on upgrade" [Undecided,New] https://launchpad.net/bugs/1253008
<didrocks> Mirv: thanks
<ogra_> r26 looks ok on magureo
<ogra_> (havent done any call or sms tests, but it boots fine)
<popey> blimey, 101MB to go to 26
<popey> did you add the kitchen sink to it?
<didrocks> ogra_: mind updating the spreadsheet with latest infos? I'm a little bit lost as the android update is still to TODO
<didrocks> so not sure if the upload was that one (it seems so though)
 * ogra_ can look, but i wasnt involved in any of the last three android uploads
<ogra_> (i didnt even know about them until i saw them on the changes ML)
<didrocks> ogra_: I guess the planned image # needs to change as well
<didrocks> ogra_: hum, ok, I think, I'll bump everyting to 27
<didrocks> well, system settings is in 25 from what I see
<ogra_> didrocks, oh, you wanted me to bump the others ?
<ogra_> sorry, i understood i should sort the android line
<didrocks> ogra_: yeah, as they are not exact, but no worry :)
<ogra_> sorry
<didrocks> jibel: lool: can one of you confirm https://bugs.launchpad.net/ubuntu/+source/ubuntu-download-manager/+bug/1240656? that will get it moved and then we can kick a saucy image build
<ubot5> Ubuntu bug 1240656 in ubuntu-download-manager (Ubuntu) "disable debug logging by default" [Critical,In progress]
<psivaa> ogra_: didrocks: not sure if that's known, but with image 26, we see "failed to copy '/var/lib/jenkins/phablet-flash/imageupdates/pool/ubuntu-418162f2a9ba9a320a2b460938e3d333f84b6f35826200c2a6b6c342ba1e21ef.tar.xz' to '/cache/recovery//ubuntu-418162f2a9ba9a320a2b460938e3d333f84b6f35826200c2a6b6c342ba1e21ef.tar.xz': No space left on device" on mako
<psivaa> have seen that in two devices
<didrocks> interesting, as the broken recovery was installed in image 25? that can be it, right?
<ogra_> psivaa, the recovery from r25 was broken ... could be that you still havethat in place
<ogra_> i just did an OTA upgrade on maguro, that one worked fine
<psivaa> i tried on two devices, not sure if both of them had attempted r25 as well, i'll try another device
<ogra_> didrocks, you should probably not use IRC nicks (or make clear they are IRC nicks) in mails to ubuntu-phone :)
<didrocks> ogra_: good point
<ogra_> "infinity is looking into it" sounds a bit cryptic for non IRC users
<ogra_> :)
<ogra_> (like "eternity will solve it")
<Mirv> go, builders, go
<Mirv> waiting for amd64+i386 on https://launchpad.net/~ubuntu-unity/+archive/daily-build/+sourcepub/3671940/+listing-archive-extra ...
<didrocks> ogra_: well, it can be true :)
<ogra_> haha
 * didrocks doesn't want to hear about amd64 and i386 in the same sentence today
<Mirv> oh, how rude of me
<ogra_> yippiiee
<ogra_> root@ubuntu-phablet:/# lxc-console -nandroid -t0
<ogra_> Connected to tty 0
<ogra_> Type <Ctrl+a q> to exit the console, <Ctrl+a Ctrl+a> to enter Ctrl+a itself
<ogra_> root@android:/ #
<ogra_> it works !
<Saviq> cihelp, hey, unity8 otto is getting stuck due to some dependency issue http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty/817/console
<Saviq> I *feel* like it might be caused by https://code.launchpad.net/~kgunn72/unity-mir/bump-mir-dep-0.1.1/+merge/193521
<Saviq> if unity-mir built against mir > 0.1.1 somehow
<Saviq> and is kept in the mbs repo
<Saviq> but then there's no mir > 0.1.1 in the archive yet, so I'm not sure how that could happen
<Saviq> Mirv, ideas â?
<Saviq> how did that even get through autolanding?
<didrocks> Saviq: the transition is in the daily-build ppa normally
<Saviq> didrocks, right... but otto isn't using it
<Saviq> grr
<didrocks> Saviq: otto for integration tests is
<Mirv> Saviq: aanyhow, once the amd64 PPA build of this https://launchpad.net/~ubuntu-unity/+archive/daily-build/+sourcepub/3671940/+listing-archive-extra finally starts, we're really close of having Mir 0.1.1 in archives
<didrocks> maybe not for upstream merger? not sure
<Mirv> my plan is 1. wait for amd64 build of that, 2. upgrade desktop, 3. reboot and login, 4. publish mir + platform-api + unity-mir + unity-system-compositor
<Saviq> Mirv, ok
<Saviq> we'll just have to wait then
<Saviq> didrocks, you mean in cu2d it does?
<didrocks> Saviq: yeah, when releasing, we are adding the ppa in the otto integration tests
<Saviq> didrocks, in -ci -autolanding it doesn't, as I understood it using daily is unsafe 'cause you never know if what you've built against is really going to end up in distro
<didrocks> Saviq: yeah, and we have issues when there are some transitions
<didrocks> like today
<didrocks> that's why we need CI Airline :p
<Saviq> didrocks, ok, so nobody is doing anything wrong, just that our tools are not letting do us what we really need, gotcha
<Saviq> we'll just wait, then
<didrocks> Saviq: I guess yeah
<psivaa> didrocks: ogra_: so the issue of no space in /cache/recovery/ on mako is not due to image r25 remnants, i flashed a device which had r23 and it still occurs
<ogra_> weird
<didrocks> psivaa: ok, if you changed the recovery as well and you're sure you don't have image 25 recovery, one less ;)
<psivaa> on maguro this is not happening though
<psivaa> didrocks: the only files in /cache/recovery/ are very small log files so they can not be the reasons.
<psivaa> i mean before flashing with r26
<ogra_> check one level up in /cache
<ogra_> i think /cache is the partition, recovery/ is only a dir
<psivaa> ogra_: 32k on /cache
<ogra_> used you mean ?
<psivaa> yes
<psivaa> before flashing with r26
<ogra_> thats not much ... and should really not cause out of space warnings
<psivaa> right during the flashing on *maguro i see 1069 M in /cach
<psivaa> *cache
<psivaa> ogra_: not sure what's the capacity though on each devices
<ogra_> http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_build.git;a=log;h=refs/heads/phablet-trusty
<ogra_> i see nothing that even touches recovery ... strange
<psivaa> but as you said it could be anything that goes into /cache
<psivaa> now it's 1386M
<ogra_> aha
<ogra_> http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_system_core.git;a=blobdiff;f=init/init.c;h=e5f265858d0e0890deff18424ab09b174a4ce3f0;hp=462130711e331820467e2b8c427c1e2f7be9cdf2;hb=a1527ce86c90842b693941723888f7739f3bf473;hpb=7a318cec11f017c5ae9c186dae2b01f2dc4d3ef4
<ogra_> psivaa, does /sbin/recovery exist ?
<Mirv> sil2100: I hoped you wouldn't block the stacks, that's why I asked for publishing jobs only
<psivaa> ogra_: the installation on maguro is finished and now /sbin/recovery is not there.. but i dont know if it would have existed during the flash
<ogra_> psivaa, well, it should be existent in the recovery mode only
<ogra_> oh, meeting ...
 * ogra_ totally forgot ... gimme a sec to relocate
<didrocks> sil2100: coming?
<jdstrand> hey-- I'm looking at landing no 303 and wondering if now is the time to upload
<jdstrand> (it is marked TODO)
<sil2100> didrocks: I'll be a bit late, start off without meee
<sil2100> Mirv: you told me that too late I guess, I just redeployed unity8 though
<Mirv> sil2100: you didn't wait for answer :) you also started a build, so it's now waiting for the scope build
<sil2100> Mirv: ok, so I'm not building/doing anything until I get a greenish light from you now ;p
<sil2100> Mirv: since I would need to rebuild ubuntu-settings-components as well...
<sil2100> But I'll do that after you're done ;)
<Mirv> sil2100: ok :) let's wait for the current build to finish, then I'll publish, then I'll let you a sign that you can publish / do what you want
<sil2100> ;)
<Mirv> sil2100: when the build job is published, isn't it in theory ok if I cancel the check job since you need to rebuil more anyway?
<Mirv> s/published/finished/
<sil2100> Mirv: you can cancel everything besides build ;p
<sil2100> Mirv: since it's not being tested anyway anywhere
<Mirv> sil2100: yeah. what I think I'll do that I'll wait for build to finish, then cancel check, then do my publishing and then I can let it run check again via foo
<sil2100> Mirv: ok, but I think that for my needs a check re-run won't be needed anyway
<sil2100> Since for me it's enough that it builds, so I can just do a direct force publish after your publishing is done
<Mirv> right
<ogra_> rsalveti, could the above git commit have any impact on that "/cache running out of space" issue when flashing ?
<Mirv> sil2100: and actually the check didn't run since unity8 build happens to fail
<sil2100> Oh
<Mirv> we should look into that at some point too, and file a bug as usual, there just hasn't been time for that
<Mirv> and we probably need to remind the other team mates too that the usual cu2d vanguarding starts again now that it's up
<didrocks> Mirv: quite, publish mir then!
<didrocks> quick*
<didrocks> as the stack stopped :p
<Mirv> didrocks: already ... done!
<didrocks> sooo fast, it's not an airline, it's a jet \o/
<Mirv> sil2100: so I'll wait still to see with my own eyes that the packages are in LP, and ping you after that
<ogra_> rsalveti, oooh, i think i see whats wrong with your patch ... you actually want the mkdir for /proc and /sys outside of the "if" in http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_system_core.git;a=blobdiff;f=init/init.c;h=e5f265858d0e0890deff18424ab09b174a4ce3f0;hp=462130711e331820467e2b8c427c1e2f7be9cdf2;hb=a1527ce86c90842b693941723888f7739f3bf473;hpb=7a318cec11f017c5ae9c186dae2b01f2dc4d3ef4
<ogra_> psivaa, could you boot one of the failing devices into recovery and check that ?
<psivaa> ogra_: the devices are in the lab and the failing devices are not reachable by adb.
<ogra_> hmm
<psivaa> i dont know any other way to connect them.
<ogra_> so we need someone in the lab to check them ... ok
<psivaa> ogra_: yea waiting till rfowler comes online
<Mirv> sil2100: so "ping", feel free
<rsalveti> ogra_: that patch is fine
<rsalveti> ogra_: the problem was the previous one that got us into a broken recovery
<rsalveti> ogra_: http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_system_core.git;a=commitdiff;h=aefb9653a367a6fd528f2ad48a1cce8945aecb3c;hp=87b40ee4a93bd682506fa082f2c2d1a0f5a60f04
<ogra_> rsalveti, well, that still  doesnt create /proc or /sys
<ogra_> it tries to mount them to a nonexisting mountpoint
<rsalveti> didrocks: I did trigger another one with the fix included in it
<didrocks> rsalveti: hum, it seems to have never gotten anywhere (we only had one new image)
<ogra_> rsalveti, though i still dont have any explanation for the out of space issue
<didrocks> or ogra's script is broken :p
<ogra_> didrocks, ?
<rsalveti> ogra_: that is ok in our default image, because they are created by lxc
<ogra_> there are 20 and 20.1
<ogra_> 20 is the broken one
<rsalveti> yes
<rsalveti> 20.1 is fine
<didrocks> ogra_: but you did build 20.1, no?
<ogra_> rsalveti, in recovery ?
<rsalveti> ogra_: in recovery it'll be created
<ogra_> oh, i see what you are saying
<ogra_> yeah
<rsalveti> ogra_: +    if (stat("/sbin/recovery", &s) == 0) {
<ogra_> well, still, all makos run our of space when flaching
<rsalveti> that's the fix I did yesterday when I noticed the regression
<rsalveti> how?
<didrocks> 12:40:27   psivaa | ogra_: didrocks: not sure if that's known, but with image 26, we see "failed to copy
<didrocks>                   | '/var/lib/jenkins/phablet-flash/imageupdates/pool/ubuntu-418162f2a9ba9a320a2b460938e3d333f84b6f35826200c2a6b6c342ba1e21ef.tar.xz' to
<didrocks>                   | '/cache/recovery//ubuntu-418162f2a9ba9a320a2b460938e3d333f84b6f35826200c2a6b6c342ba1e21ef.tar.xz': No space left on device" on mako
<didrocks> rsalveti: ^
<ogra_> rsalveti, <psivaa> ogra_: didrocks: not sure if that's known, but with image 26, we see "failed to copy '/var/lib/jenkins/phablet-flash/imageupdates/pool/ubuntu-418162f2a9ba9a320a2b460938e3d333f84b6f35826200c2a6b6c342ba1e21ef.tar.xz' to '/cache/recovery//ubuntu-418162f2a9ba9a320a2b460938e3d333f84b6f35826200c2a6b6c342ba1e21ef.tar.xz': No space left on device" on mako
<rsalveti> didrocks: why did you remove the emulator?
<rsalveti> :P
<rsalveti> ogra_: right, but is 26 = 20.1?
<ogra_> rsalveti, he did an apt-get autremove ...
<ogra_> rsalveti, it is
<didrocks> rsalveti: yeah, I know you wanted to punish people doing that! :p
<didrocks> I'll note this for next time "never ever remove what rsalveti installed on your system" :)
<rsalveti> ogra_: right, not sure if that is indeed using the cache partition, need to give it a try here
<ogra_> rsalveti, r26 works fine on my maguro with OTA upgrade
<rsalveti> ogra_: I know the cdimage one works fine
<rsalveti> just flashed it
<rsalveti> ogra_: are we flashing the lab devices with -b?
<ogra_> could be, not sure
<ogra_> doanac` should know
<ogra_> or sergio
<psivaa> the devices in the lab use - phablet-flash ubuntu-system -b --channel trusty-proposed
<plars> psivaa: I just got to my desk, looks like there's some trouble this morning?
<plars> rsalveti, ogra_: we are using -b for quite some time now
<psivaa> plars: yes, a couple but the latest impacting one is that flashing on mako fail due to no space available error on /cache/recovery
<rsalveti> let me flash my mako to see
<rsalveti> the cdimage one worked fine
<Mirv> Mir 0.1.1 now in release pocket
<Mirv> and time for UDS
<plars> psivaa: we seem to have a lot of devices showing up with the 0123456789ABCDEF adb id again now
<psivaa> plars: yes, vila mentioned about it. dont seem to be an id that's used for smoke
<plars> psivaa: it's a generic one that's used when it can't sort out the real one
<plars> psivaa: we'll probably need rfowler to reflash them
<psivaa> plars: ahh ok, could be that we have a bunch of mako's that failed to flash due to the no space reason and they could be it
<psivaa> plars: on another issue, we had adb protocol fault in kinnara in the morning
<plars> psivaa: just one? :)
<plars> psivaa: we do get it a lot less frequently I think, but it still happens from time to time
<psivaa> even running 'adb devices' from kinnara constantly threw this error
<psivaa> plars: how do you normally recover from it
<plars> psivaa: oh, that's different
<plars> psivaa: in a case like that, I guess we'd just need to restart adb server... I'm not sure I've seen that happen before
<plars> psivaa: we added quite a few more devices to that system though
<ogra_> plars, psivaa, this will be fixed within the next weeks
<psivaa> plars: yea, it turned out to be one of the old adb processes was causing the issue
<rsalveti> plars: ogra_: mako worked fine here with system-image
<ogra_> very weird
<psivaa> plars: killing that process fixed it
<plars> rsalveti: you flashed with -b also?
<psivaa> Installed: 1.0+14.04.20131108-0ubuntu1 is the phablet tools in the lab
<rsalveti> plars: yes
<ogra_> i dont think it has anything to do with phablet-tools, after all the out of space message seems to come from the device itself
<rsalveti> plars: http://paste.ubuntu.com/6448304/
<plars> brb
<psivaa> ogra_: ok
<rsalveti> ogra_: so I think the cache related issue could be a side effect from the broken image
<ogra_> rsalveti, thats what i thought too, but -b pushes a new recovery
<ogra_> so it should boot the fixed one
<ogra_> (it actually boots the new recovery via fastboot)
<rsalveti> ogra_: right, but that doesn't necessarily mean that it'll clean up the cache partition
<rsalveti> INFO:phablet-flash:Clearing /data and /cache
<ogra_> h,mm, i thought we do that from ubuntu_commands or how thats called
<rsalveti> but it should in theory clean it as part of the flashing process
<plars> so was the bad recovery actually on image 25 then?
<ogra_> right
<ogra_> plars, yes
<psivaa> plars: ogra_ i tried flashing from image 23 as well
<psivaa> and the same thing happend
<ogra_> psivaa, if you use -b it weill use the new recovery ... and if you were unlucky you had r25
<ogra_> though looking at the above it smells more like the cleanup step failed
<plars> indeed
<ogra_> but you should have seen that in the log
<plars> ogra_: I don't see anywhere in phablet-tools where fastboot erase is called, could be that we need to really erase those partitions
<ogra_> i dont think it calls erase
<rsalveti> plars: the clean is a shell call done in recovery
<ogra_> yeah
<rsalveti> not via fastboot
<rsalveti> so that might be failing
<plars> rsalveti: yeah, it just does rm
<rsalveti> plars: you might want to force a clean with fastboot then and retry to see
<plars> rsalveti: yeah, I'm trying to reproduce locally. Flashing 25 right now.
<sergiusens> fastboot -w created too many support issues
<ogra_> yeah
<ogra_> well, i can imagine that if there was no /dev and no /proc in r25's recovery that the rm might indeed have failed ... i just dont get why it would also fail in r26
<rsalveti> plars: were you able to reproduce the issue locally?
<plars> rsalveti: yes, but psivaa said he's seeing the issue going from 23->26 also
<rsalveti> oh =\
<plars> rsalveti: I was also able to get it to flash just fine from 25->26 after it failed once... it was in recovery and not getting the bad adbid like we see in the lab
<plars> rsalveti: and I just added -d mako
<plars> rsalveti: it all just worked... so I'm trying to figure out what's going on
<plars> psivaa, rsalveti: so I just watched it get the same error when trying to go from 26->25
<plars> wait, maybe not
<plars> this one might have just been an adb failure
<plars> adb/mtp thing probably
<rsalveti> right
<rsalveti> I think you might be able to extract the logs from the broken flags if you're able to boot the device
<rsalveti> check /cache/recovery/last_log
<plars> rsalveti: ok, after coming back up, all I have is busybox and there's no fstab or /cache. If I mount mmcblk0p22 by hand though, I found what seems to be a cache partition there, and here's the last_log: http://paste.ubuntu.com/6448925/
<plars> rsalveti: this was after installing 25, and then trying to install 26
<plars> oddly: 'Skipping missing file: version-25.tar.xz' was in the log
<rsalveti> plars: hm, right, but the log is from 25 I believe
<rsalveti> weird
<plars> rsalveti: yeah, so maybe we didn't get far enough for that log to happen
<ogra_> if you are in busybox you are not in recovery
<ogra_> so indeed there is no /cache
<rsalveti> yeah
<plars> since it happened on the adb push, that makes sense
<rsalveti> plars: let me try to flash 25 to see
<rsalveti> plars: got the issue here
<rsalveti> plars: so, what happens, when flashing 25 with -b it will first flash the recovery image with fastboot
<rsalveti> plars: then it'll try to load recovery, which will fail
<rsalveti> plars: meanwhile it waits for adb, thinking that the recovery will be up
<rsalveti> as recovery fails to boot, the device boots the previous image instead
<rsalveti> and phablet-tools thinks that the recovery is then up, because adb is there
<plars> rsalveti: ah, I see. so we think we're booting 25 but really we're not
<plars> rsalveti: I see
<rsalveti> http://paste.ubuntu.com/6449025/
<rsalveti> sergiusens: we should be checking for /sbin/recovery when flashing
<rsalveti> sergiusens: to check if we're indeed in recovery
<sergiusens> rsalveti, sure, I'm already checking for something; checking for recovery specifically shouldn't be complicated
<sergiusens> rsalveti, my wonder is, what did it boot?
<sergiusens> plars, any indications of why it failed to boot?
<rsalveti> sergiusens: it fails to load the recovery, then it tries to boot the previous image
<rsalveti> but it seems that the 25->26 migration worked fine
<sergiusens> rsalveti, yeah, but why? :-)
<rsalveti> so the error when copying the file into /cache happens because it's not really in the recovery
<plars> rsalveti: really? for me, I get a broken system - just boots to busybox
<rsalveti> sergiusens: that's the default behavior
<sergiusens> rsalveti, how could've recovery been broken :-)
<rsalveti> sergiusens: we had a regression
<sergiusens> rsalveti, that's the how I'm asking :-)
<sergiusens> ack
<plars> rsalveti: you are flashing cdimage? or ubuntu-system image?
<sergiusens> plars, rsalveti super easy to have a better check if we are in recovery, no worries
<rsalveti> sergiusens: http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_system_core.git;a=commitdiff;h=aefb9653a367a6fd528f2ad48a1cce8945aecb3c;hp=87b40ee4a93bd682506fa082f2c2d1a0f5a60f04
<rsalveti> which was fixed at http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_system_core.git;a=commitdiff;h=a1527ce86c90842b693941723888f7739f3bf473;hp=7a318cec11f017c5ae9c186dae2b01f2dc4d3ef4
<rsalveti> plars: ubuntu-system
<didrocks> ogra_: can we get a new image build?
<didrocks> ogra_: now that Mir entered :)
<plars> strange... for me, I'm getting exactly what we have seen on multiple devices in the lab
<rsalveti> didrocks: sure :-)
<didrocks> rsalveti: thanks!
<ogra_> didrocks, yeah
<sergiusens> why does everyone get to push but me? :-P
<didrocks> it's christmas
<ogra_> rsalveti, do you already ?
<didrocks> I saw some snow this morning ;)
<rsalveti> didrocks: having newer images is always a good thing
<rsalveti> didrocks: easier to test and revert broken changes as well
<ogra_> we should just build one every hour !
<rsalveti> ogra_: nops
<rsalveti> ogra_: yeah
<ogra_> then i'll do
<sergiusens> rsalveti, ogra_ you will starve the testing infra though
<didrocks> rsalveti: fully agreed, we just need to have a way to communicate those to you and us more easily
<rsalveti> didrocks: why do we need the communication here?
<ogra_> sergiusens, nah, we'll have our fast emulator and all will be fine
<rsalveti> we don't
<rsalveti> the communication is the changelog :-)
<sergiusens> ogra_, big LOL
<ogra_> :)
<didrocks> rsalveti: well, we do plan landings on certain image/try to communicate that
<rsalveti> didrocks: and that's wrong
<sergiusens> ogra_, the emulator would be mostly useful for apps, but not image testing ;-)
<rsalveti> didrocks: you should only know when something lands, not planning when it'll land
<ogra_> === Image r27 building ===
<didrocks> rsalveti: will be easier once we have the CI Airline I hope to know more on feature-based what landed
<sergiusens> ogra_, we can certainly only run on real hw if the emulator test pass
<ogra_> sergiusens, well, i thought the plan was to use it in all testing infra
<rsalveti> we don't need to know when it'll be landing
<rsalveti> we just need to know when it *landed*
<didrocks> well, we want to know when big thangs are landing at the same time
<didrocks> to avoid clashes
<didrocks> but apart from that, yeah
<ogra_> right, only have a test on real HW if all emu tests were good
<ogra_> didrocks, and that ifno comes from the changelogs
<rsalveti> right, but even if we get clashes, we want more images to test all the steps
<didrocks> ogra_: note on a "feature-approach", and not planning clashes
<ogra_> rsalveti, the point is that asac wants us to have stuff tested in full context before we upload
<ogra_> nobody does that
<ogra_> (or do you run the full AP suite for an android change you do)
<rsalveti> ogra_: right, but that's not a blocker here
<rsalveti> having more images is *always* a good thing
<ogra_> thats true
<ogra_> but sergiusens has a point
<ogra_> we'd saturate the lab
<rsalveti> right, that's our only limitation
<rsalveti> but we can do as most images we can depending on how long it takes to validate an image
<rsalveti> what would that be?
<rsalveti> at every 4 hours?
<asac> rsalveti: in theory we can produce images in parallel and validate them
<asac> the problem is not parallelizing the validation
<asac> but the building
<asac> its not really clear what atomic snapshot you will take when you start the job i think :)
<ogra_> asac, we only talk about the actual images
<ogra_> not about any parallel test builds etc
<asac> (though you could mitigate that by pulling the packages file out of the tool and passing itas an input)
<ogra_> we currenntly only build two per day at most
<asac> right
<rsalveti> and need to speed this up
<asac> so for now we talk about the future anyway because emulator is not there etc.
<ogra_> having a more fine grained view in the changelogs through building more of them will make identifying issues a lot easier
<rsalveti> right, but I think we can already improve by building at least a few images a day
<asac> however, if the emulator is fully landed, i anticipate that we can produce as manages as we want a day.
<ogra_> from a builder POV we could build one every hour
<rsalveti> as we always get stuff that lands in the archive which is not  part of the landing spreadsheet
<asac> just not test all on all phones
<rsalveti> so it's *always* good to produce and test newer images
<ogra_> 30min for cdimage + 15min for system-image post processing
<asac> we would basically validate all iamges in emlator and then pick those that we are interested in (for instance, because we consider them a release image) and test them  everywhere
<asac> we discussed hooking image productionm up with the publisher runs
<asac> so we get one image somewhere stored for each injection of what really goes in the archive
<asac> has to wait for cloud buildd which is worked on somewhere
 * cjwatson forces android-emulator back in despite p-m not quite understanding multiarch
<asac> p-m?
<cjwatson> proposed-migration
<asac> ah
<cjwatson> asac: https://rt.admin.canonical.com/Ticket/Display.html?id=62272 and https://bugs.launchpad.net/bugs/1247461
<ubot5> Ubuntu bug 1247461 in launchpad-buildd "Move live filesystem building into Launchpad" [High,In progress]
<ogra_> right, that will give us parallel builds
<josepht> asac: once an image + new packages is promoted don't all previous images need to be updated and retested?
<asac> not really. all we do is snapshotting the archive after a publisher run in the form of an image
<ogra_> why would they ?
<asac> so whatever is in there is already finally committed
<asac> until overwritten for which a new image would exist
<josepht> we create an image for archive+A and archive+B in parallel, archive+A passes all tests so now archive = archive+A, if archive+B passes all tests we don't know that archive+A+B will pass all tests and need to test that scenario, right?
<rsalveti> asac: right, but let's try to improve our current situation
<asac> josepht: yeah you are right, but you are thinking about a different level
<rsalveti> how long does it take to test an image currently?
<rsalveti> plars: ^
<asac> josepht: you are thinking about the premerge level... there indeed we need to invalidate A after we land B
<plars> rsalveti: somewhere around 3 hours I believe
<asac> hwoever, we can try to be smart and only invalidate if the changes are in the same dependency tree for instance
<plars> rsalveti: assuming everything goes right :)
<didrocks> plars: but then, you rekick jobs, right?
<plars> didrocks: yes
<asac> josepht: we talk about images produced after the fact from whatever landed in the real archive
<didrocks> so how long until we get a clean state, I guess
<didrocks> and you rekicked enough? :)
<plars> didrocks: if I'm up and see it needs to be done, and there's not another image already coming
<josepht> asac: ah I see
<rsalveti> right, can we build a new image at every 6 hours then?
 * asac hope that makes sense
<rsalveti> or 8?
<plars> didrocks: for instance, if the devices could work right now, I wouldn't bother retesting because I see there's a new image on the way, and it would just delay
<asac> rsalveti: well. so i dont want random images
<asac> i want precisely cut images
<rsalveti> asac: why not?
<rsalveti> asac: that's *wrong*
<asac> its not :)
<asac> not sure how that can be wrong :)
<rsalveti> asac: we want one image per change
<rsalveti> or the most images we can
<asac> right.
<rsalveti> otherwise it's a pita to find regressions
<rsalveti> one image a day is *wrong* and only causes pain
<asac> one image per chagne... but now that we can't get that (for various reasons) short term, it doesnt mean we should give up
<cjwatson> an image isn't any more precisely cut just because somebody asked for it manually
<asac> and cut images in the middle of changes :)
<cjwatson> there shouldn't be a "middle of changes"
<rsalveti> asac: give me one example
<asac> rsalveti: i am supportive of more images per day. just not at cronjob kicked
<rsalveti> exactly
<asac> cjwatson: depends on which level you define changes :)
<rsalveti> once it's in the archive, there's no "middle of changes"
<cjwatson> get your packaging metadata right so that proposed-migration can migrate it properly
<rsalveti> exactly
<cjwatson> and then roll
<rsalveti> we should put it in cron
<cjwatson> manual image building requests are a workaround for lazy metadata maintenance
<rsalveti> image is just an archive snapshot
<asac> "get your packaging metadata right" ... please give up on that hope. all you can hope for is "get youir packaging meta data right most of the times please"
<asac> but even if everyone does it right most of the times, if the engineering team is big enough you will always have problems :)
<cjwatson> I'm not going to give up on that hope, because working on that basis made, empirically, a *massive* difference to the day-to-day quality of Ubuntu.
<ogra_> cjwatson, *my* manually built images are *allways* more precisely cut, i sand and olish them :P
<ogra_> *polish
<cjwatson> In fact I think it's mostly reality rather than hope.
<rsalveti> as long we're not saturating our test lab, we should be fine to produce the most images we can
<asac> exactly... its mostly
<asac> :)
<cjwatson> Yes, there's the odd exception, but they're, well, exceptional
<cjwatson> We shouldn't structure processes around exceptions
<rsalveti> +1
<asac> and will alwayus be mostly... but 600* mostly might mean rarely :)
<ogra_> the point of automated builds is to simply have an as small changeset as possible ...
<ogra_> doing only two manual builds completely goes against that
<ogra_> and causes lots and lots of guesswork on our side until we found the actual issue
<rsalveti> yeah
<asac> its human. noone is perfect. hence designing the process must work in continuous exceptions due to human failures induced
<rsalveti> horrible
<rsalveti> see the udev one we had a few weeks ago
<ogra_> which wastes more developer time than having more images per day
<rsalveti> the package was uploaded at wednesday and we found the issue at saturday
<ogra_> asac, its wasting human resources
<asac> ogra_: the problem can be solved by using a cronjob or by kicking builds again at a 3 times a day schedule
<asac> with shbuman smartness
<ogra_> asac, how often did we get onto the wrong path in the recent times if an image was broken
<ogra_> wasting hours to find it was the other change that we didnt look at yet
<rsalveti> right, even if we build it at every 12 hours, it's already better than what we have now
<ogra_> rsalveti, we do
<asac> i agree that we should revisit the image schedule :)
<rsalveti> ogra_: not currently
<ogra_> we usually have two manual built ones per day
<rsalveti> well, it's manual
<asac> not sure if crontab is the right approach. lets talk about it tomorrow on the standup
<ogra_> (if there isnt UDS)
<asac> i would love to see at least 3 images :)
<ogra_> so the timing is already 12h
<rsalveti> ogra_: right, I want it to be automatically triggered
<rsalveti> ogra_: as the archive is always moving
<ogra_> right
<ogra_> 4 per day should be fine
<ogra_> automated and all
<cjwatson> I'm completely boggled at the insistence that things must *not* be automated, frankly
<rsalveti> can we try to put it back to the cron and see how it goes?
<cjwatson> It goes against all the engineering practice I know
<rsalveti> haha, exactly
<ogra_> cjwatson, all but asac and didrocks in here say we want automated
<didrocks> ogra_: I didn't say we don't want automation, I said that we want to cut after each big change as a first approach
<cjwatson> I understand "automation is hard and we can't quite manage it yet" (have said that myself on various occasions) - I just don't understand "the ideal is manual"
<ogra_> right, but why ?
<asac> for the record: noone says "we dont want automation" :)
<ogra_> didrocks, you land all your stuff in one chunk anyway
<asac> lets discuss it tomorrow
<asac> i will join you guys there
<ogra_> where ?
<cjwatson> OK, so you're arguing against regularity but not against automation, I see
<asac> standup
<cjwatson> I disagree but at least that isn't so boggling :-)
<asac> hehe
<asac> its also not exactly what i am saying :)
<ogra_> asac, ah, the landing team one
<asac> but closer
<rsalveti> asac: why tomorrow?
<rsalveti> asac: let's just put it back to cron today and see how it goes
<didrocks> ogra_: if you land all the stuff in one chunk, well, you have to debug it, you decided the size of the chunk :)
<rsalveti> why would that cause us any pain now
<asac> i want to first ensure people understand what we are saying :)
<didrocks> ogra_: we need to be able to produce images after each "chunk" landing, but a chunk is defined by the developer itself
<asac> I dont see us having any pain from having manual image building
<asac> it gives us many good
<rsalveti> you can still manually trigger new images
<rsalveti> but we should *always* have it in cron
<ogra_> didrocks, thats not true ... your chunks are controlled in the spreadsheet
<rsalveti> because the archive is *always* moving
<ogra_> not defined by a developer
<didrocks> ogra_: I just want to avoid A + B entered, "A says I don't care, it's B", it's not me, and B says "I don't care, it's because of A"
<asac> so ... i know for sure that we will spin more than enough images once the landing stuff is fully back operational again
<rsalveti> all I'm asking is to add it back in cron at every 8/12 hours
<didrocks> ogra_: well, not really in our current model, but yeah, we would need to define priorities rather than image #, agreed
<asac> hence, i believe the issue you try to solve is the low velocity due to the 1ss move paired with a UDS going on now :)
<didrocks> ogra_: and I think we do align with what rsalveti told seeing it that way
<asac> and yes, we should build at least 2 images a day even if not much is going on
<ogra_> didrocks, so we can switch cron back on and set it to say 6h ?
<rsalveti> I just want to make sure we always have a fallback in case we don't have humans to trigger a new image
<ogra_> (to have 4 images / day)
<asac> well. as i said befeore the capacity on testing is really bound to emulator :)
<didrocks> ogra_: well, for me, it would be a +1 but rather 8 hours TBH, to let the CI team to rekick the tests jobs and giving some slack for that). 3 images a day will be a start
<ogra_> asac, we should have as many as the infra allows imho
<asac> so ... dont hurry
<rsalveti> ogra_: yeah
<didrocks> ogra_: but I don't think I'm the one able to take the decision :)
<rsalveti> ogra_: I'd first try with 8h
<ogra_> didrocks, why do you care if it is 4 or 8 ?
<rsalveti> ogra_: and we can improve that as we go
<didrocks> ogra_: because then, the testing infra can't rekick the jobs
<ogra_> if your team only lands something every second image thats fine
<asac> i care because i want to ensur3e the CI folks that support those images whenthey hit validation
<didrocks> if a new image is produced
<asac> know what to do and how to prioritize
<didrocks> ogra_: they can't "restest an older image"
<ogra_> asac, but the CI team knows when cron runs
<asac> anyway
<didrocks> ogra_: it's not only that, most of their time is just "relaunch the jobs"
<didrocks> because the whole thing is flacky
<asac> not sure why is it suddenly such a big issue todya?
<rsalveti> that's why let's try with either 8h or 12h
<ogra_> and as the one who does the manual builds i must say that the requirement for manual builds is largely always at the same time
<didrocks> asac: and so you need to reboot the device
<didrocks> rsalveti: +1
<ogra_> so why not just have images inbetween too ?
<ogra_> rsalveti, i dont get it
<didrocks> ogra_: because you don't let the CI team to get test results
<rsalveti> ogra_: we can, I just want to make sure we're not saturating our test lab
<ogra_> why does having 2 images help more than 4
<didrocks> if you kick a new image
<didrocks> because we give them more time to rekick the jobs
<didrocks> when you finished building a new image
<didrocks> they can't retest an older one
<ogra_> didrocks, but if they dont make this image they will make the one in 4h
<ogra_> i dont get it
<rsalveti> yeah
<asac> if noone can tell me why this is so much more important today than yesterday, lets really talk tomorrow in the standup.
<asac> :)
<ogra_> there is nothing that puts time pressure on anyone
<didrocks> ogra_: but then, there is the same issues, they need to rekick
<rsalveti> that's why as long we're not saturating the lab, we're fine
<didrocks> ogra_: and you just rebuild the next next image
<didrocks> and the story repeats :)
<ogra_> just make sure you land your stuff inbetween two builds if you want to make sure all of it lands at the same time
<rsalveti> asac: why can't we just add it there and see what happens
<asac> rsalveti: right now until we have the emuilator fully rolled out its about saturating support folks
<ogra_> and the schedule is known
<ogra_> didrocks, why do they need to rekick
<ogra_> or even care for the images
<didrocks> ogra_: repeating "because it's flacky"
<asac> rsalveti: understand taht i have to figure how to deal with that with CI process
<rsalveti> asac: sure, but all I'm asking is more images than we have today, and that's for sure something we can improve even without the emulator
<ogra_> they just need to check the results for the image their change landed in
<didrocks> ogra_: see a vanilla test run
<ogra_> no matter when they landed their stuff
<didrocks> before plars or psivaa starts looking at it
<didrocks> you have a lot of tests not running
<asac> rsalveti: not without undersanding and clarifyuing with my team what they should focus on testing etc.
<didrocks> or with just 1 test
<asac> rsalveti: on technology side its easy
<didrocks> (and beeing representated as "green" btw :/)
<didrocks> ogra_: so, they restart the jenkins jobs as of now
<asac> if you guys feel so strongly about more images
<rsalveti> right, but you don't get that we're also wasting resources by not triggering more images
<asac> lets really check how we can get that
<rsalveti> because it's really a pain to find and revert regressions
<asac> i am not sayuing we shouldnt have more images
<rsalveti> if we get tons of changes at every image we produce
<asac> just lets discuss how to do that brest
<didrocks> (btw, while we discuss, we still can't test an image I guess and powerpc is broken in distro ;))
<ogra_> asac, it wastes immense amount of manpower to just make the CI team happy
<ogra_> while they would just have to obey to a cronned build schedule
<ogra_> finding an issue in an image that has 50 packages changed is lots and lots harder than finding it in one that only has 10
<rsalveti> +100
<rsalveti> it's just stupid to fight automation
<ogra_> right
<rsalveti> as the archive is always moving
<ogra_> asac, i worked with this system for 4 months now ... and thats the result of my experience
<ogra_> we waste manpower and that doesnt need to happen
<asac> i am the first who wants more images. if the landing team would be operational they would at least spin 2 images a day
<asac> it should be closer to 3
<ogra_> and its a trivial change ... just a crontab entry
<asac> and as we add more "smart automation" we woulc increase the pace
<ogra_> but why do we have to make it depend on the landing team
<ogra_> the landing team can land stuff even with automated builds
<rsalveti> yeah, that's the wrong, as the landing team doesn't have the power to freeze the archive :-)
<rsalveti> *that's wrong
<ogra_> its not like it is hard, the schedule will be known so you know when your stuff gets into the next image
<rsalveti> didn't make at one image? wait for the next
<ogra_> right
<rsalveti> just don't make everyone to wait on your call
<jibel> cihelp: publisher on d-jenkins fails to create new jobs on public instance
<rsalveti> about triggering a new image
<jibel> example http://d-jenkins.ubuntu-ci:8080/job/trusty-adt-python-misaka/1/?
<retoaded> jibel, looking
<jibel> retoaded, it is only the creation of a new jobs, publication of new builds work fine.
<retoaded> jibel, it wouldn't happen to be a matrix job would it?
<tedg> Not sure who to blame, but having DNS on the CI VPN is pretty cool.  Thanks!
<jibel> retoaded, it is
<retoaded> jibel, http://10.98.3.6:8080/plugin/build-publisher/instance/0/publisherThread/currentState/output  makes me think that it could be related to the just updated matrix-reloaded plugin.
<retoaded> jibel, i will probably have to revert it back.
<jibel> retoaded, I'm not sure, I see no reference to the plugin in the trace. But if it's a recent change revert it back and we'll see
<retoaded> jibel, it near the bottom: Caused by: java.lang.NullPointerException at hudson.matrix.MatrixProject.onLoad(MatrixProject.java:474)
<retoaded> jibel, and as soon as the currently running jobs complete I'll revert
<jibel> retoaded, it is a reference to a Matrix object from jenkins core, not the plugin.
<ogra_> === Image r27 DONE ===
 * popey updates
<ogra_> (totally forgot that over the abive discussion)
<ogra_> *above
<jibel> retoaded, it is not a new problem apparently
<jibel> retoaded, trusty-adt-simplejson failed to publish too
<jibel> retoaded, oh, and it vanished from d-jenkins
<jibel> WTF
<Ursinha> ogra_, can I update my phone then? :P
<jibel> retoaded, so on the filesystem there is a /var/lib/jenkins/jobs/trusty-adt-simplejson but not on the UI
<ogra_> Ursinha, well, my maguro just updated fine here
<jibel> retoaded, and publication fails with the same error 500
<ogra_> bah, since when is facebook on the home lens
<Ursinha> ogra_, are you using -proposed? read-only?
<ogra_> yes
<Ursinha> ogra_, at least since yesterday when I flashed mine with the current devel
<ogra_> well, i do OTA updates
<ogra_> Ursinha, heh, that was ricardos fault ... r25 was broken
<Ursinha> ogra_, it rarely is rsalveti's fault, hehe
<ogra_> haha
<ogra_> never ever :)
<Ursinha> rarely ;)
<rsalveti> lol
<Ursinha> ogra_, so I heard you test all the images :P I have a nexus 4 and whenever I put some music on and change to another app the music stops playing after a few seconds, is that a known issue?
<popey> it shouldn't
<ogra_> Ursinha, i test only on maguro ...
<Ursinha> I just updated with the latest -proposed image
<popey> what image are you running Ursinha ?
<ogra_> popey, is the makoman
<popey> Ursinha: are you using the music app or something else?
<Ursinha> popey, Home lens, click on music and then play
* fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: fginther | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move), network slowness
<Ursinha> about this phone says r27
<popey> my phone is dead.. one moment
<popey> works fine here
<Ursinha> popey, music app has the same behavior, but the interesting thing is that the music stops playing but when I return to the music app it resumes playing as if it never stopped
<Ursinha> there's no sound but it seems the app was playing it
<popey> i am listening to music which is playing in the music app but I'm on the home screen
<popey> it even plays when locked
<popey> and continies to play after a song finishes
<Ursinha> popey, what should I do then?
<popey> is it launching the music app ?
<Ursinha> popey, yes, it launches and I'm able to listen to music, the only problem is when I change screens it stops after a few seconds
<popey> http://popey.com/~alan/phablet/device-2013-11-20-184641.png
<popey> like that
<Ursinha> it's playing as it should (I think), displaying the cover and band/song name
<popey> was this a clean install or an update to an existing install?
<Ursinha> popey, it was a clean install yesterday, with the current devel image
<popey> odd
<Ursinha> I switched to -proposed today and the problem is the same
<popey> I dont understand why it's working for me and not you
<Ursinha> hehe
<Ursinha> popey, btw it keeps playing when screen is locked
<Ursinha> popey, I'll try a clean install and let you know
<cjwatson> http://people.canonical.com/~cjwatson/tmp/emulator-yay.png
<cjwatson> didn't *quite* manage to get it up on the hangout just now ...
<ogra_> :)
<ogra_> thats quite a wide screen
<cjwatson> dual monitor
 * ogra_ has triple ... but screenshots always only show one screen 
<cjwatson> import(1) doesn't really understand that and just gives me the whole thing.  I should probably use the screenshot thing in the desktop but old habits die very hard
<ogra_> might be nvidias fault
<ogra_> ah
<ogra_> yeah, i only use alt+print
<fginther> cyphermox, kenvandine, robru, we need to restart q-jenkins as soon as possible
<robru> fginther, fine by me...
<kenvandine> fginther, go for it
<cyphermox> yeah, fine
<fginther> there is a build in progress (for 11 hours) is it safe to kill ti?
<fginther> it
<robru> fginther, yeah, whatever. we can restart it if necessary. i'm not waiting on anything myself
<robru> fginther, also 11 hours usually indicates a problem anyway
<fginther> robru, I kinda figured that :-)
<fginther> robru, kenvandine cyphermox thanks for the input
<rsalveti> Ursinha: background music working fine with image 27, let me help you debugging the issue
<Ursinha> rsalveti, okay, thanks
<fginther> cyphermox, is it difficult to re-deploy all of the cu2d jobs?
<cyphermox> well, i'd love to avoid it if possible, why?
<fginther> cyphermox, the jenkins root moved from /var/lib/jenkins to /iSCSI/jenkins. and some of the scripts had the old path hard coded
<fginther> cyphermox, I have MPs to update the scripts and the job. I just want a plan for how best to do this
<fginther> would prefer to actually do the update tomorrow when more help is available
<cyphermox> are you saying you would prefer or are you asking my opinion?
<fginther> cyphermox, I just want some idea of what is involved? does it require lots of downtime, do we need to make special arrangments to make it happen, etc.?
<cyphermox> not really, I think we just need to update the paths in lp:cupstream2distro and lp:cupstream2distro-config (if any there), redeploy all the jobs, etc, make sure all the necessary machines have their copies of those branches updated
<cyphermox> it would take an hour of work maybe?
<fginther> cyphermox, good. I do have MPs here:
<cyphermox> but I could see it being done much more cleanly if we use a symlink as a temporary step to avoid breaking things
<fginther> https://code.launchpad.net/~fginther/cupstream2distro/jenkins-home/+merge/195848
<fginther> https://code.launchpad.net/~fginther/cupstream2distro-config/update-stack_status/+merge/195956
<fginther> cyphermox, things are already broken :-(
<cyphermox> how so?
<fginther> the check jobs are looking for job data under /var/lib/jenkins. it's not there
<cyphermox> right
<cyphermox> that's partly why i mentioned a symlink
<cyphermox> if not /var/lib/jenkins -> /iSCSI/jenkins then one for just cu2d
<cyphermox> that allows a smooth transition, but not meant to stay in place
<fginther> cyphermox, hmm, ok
<cyphermox> so, both branches look fine
<fginther> thanks, I'll email out a plan
<cyphermox> fwiw I see other places in cupstream2distro-config that need a path change
<fginther> cyphermox, ack! can you add them to the bug: https://bugs.launchpad.net/cupstream2distro/+bug/1252750
<ubot5> Ubuntu bug 1252750 in Canonical Upstream To Distro "latest_autopilot_results hardcodes a jenkins root directory" [Undecided,New]
<cyphermox> do you have an equivalent bug for cupstream2distro-config?
<fginther> cyphermox, no
<robru> fginther, no CI after 5 hours? can you look please? https://code.launchpad.net/~robru/friends-app/autopilot-py3/+merge/195979 thanks
<fginther> robru, all the phones are blocked due to an image flash problem
<fginther> robru, it is being worked
<robru> fginther, oh ok thanks. just really curious about what happens with that branch ;-)
<robru> no worries
<Saviq> fginther, afraid makos started to get stuck in flashing, too: http://s-jenkins.ubuntu-ci:8080/computer/mako-04cb53b598546534/? http://s-jenkins.ubuntu-ci:8080/computer/mako-04cbcc545f5328a5/?
<fginther> Saviq, thanks for the ping. Someone is working on it right now, but they have to manually reflash each device this time
<fginther> Saviq, all three of them were dead a couple hours ago
<asac> curious: what happened to them?
<Saviq> fginther, ah
<fginther> asac, AIUI there was a problem with the image today, plars do you know more?
<asac> ok thanks. nevermind then
<fginther> were also still being hit by https://bugs.launchpad.net/phablet-tools/+bug/1249162
<ubot5> Ubuntu bug 1249162 in android-tools (Ubuntu) "Devices lose adb connection after phablet-flash loop" [Undecided,New]
 * asac wonders what a phablet-flash loop is :)
<asac> ok i think i see what it tries to describe
<fginther> the phablet-flash loop is a way to reproduce the problem we see on our devices
<asac> check my comment please
* fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move), network slowness
<sergiusens> asac, fginther Saviq recovery was broken, that was the problem
<sergiusens> I'm adding a safeguard to phablet-flash to avoid flashing if recovery is broken
#ubuntu-ci-eng 2013-11-21
<plars> looks like devices are back up now, restarting everything on the latest build
<plars> 27 looks to have some bad problems
<rsalveti> plars: still around?
<plars> rsalveti: yep
<rsalveti> plars: just replied your email, can you get your /proc/last_kmsg?
<rsalveti> after a crash/reboot
<plars> rsalveti: yes, looking now
<plars> I always forget about that!
<rsalveti> yeah, it's quite useful
<plars> rsalveti: http://paste.ubuntu.com/6451729/
<rsalveti> [20678.650539] mdm_power_down_common: MDM2AP_STATUS never went low. Doing a hard reset
<plars> wlan stuff it seems
<rsalveti> https://android.googlesource.com/kernel/msm/+/3ab322a9e0a419e7f378770c9edebca17821bf6e/arch/arm/mach-msm/mdm2.c
<rsalveti> plars: modem driver
<plars> http://forum.xda-developers.com/showthread.php?p=44918540
<rsalveti> now why the hell it's powering it down
<rsalveti> interesting, but the fix in there is not related with the kernel
<plars> yeah, doesn't look plausible
<rsalveti> last time we had a kernel upload was at 10-18
<rsalveti> so wonder how this could be specific to 27
<rsalveti> do you know if that's the same error you're getting with the devices from the lab?
<rsalveti> you also got a few errors in the wlan driver
<rsalveti> wonder if the modem shutdown is just a consequence of another failure
<rsalveti> we can investigate a bit more tomorrow, but let me know if you're getting different failures in the lab
<rsalveti> later!
<plars> rsalveti: same error in the lab
<Mirv> morning
* psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: psivaa | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move), network slowness
 * didrocks uses this time for exercising (missed yesterday and tuesday: 3 days with sitting for more than 14 hours isn't good for your health)
<didrocks> will make a longer tour then, 1h30
<didrocks> asac: just in time for our meeting I guess ^
<asac> didrocks: sounds good... ttyt
<Mirv> cihelp please investigate "misc stack is already running" http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/All/job/cu2d-build_all-head/281/console - and still happening, preventing builds from happening
<Mirv> so it's not there visibly running at least anywhere
<psivaa> Mirv: ack will do
<Mirv> psivaa: thanks, and sorry I forget to check the topic whether it's ci_help or some person at the moment
<psivaa> Mirv: np, will do after a meeting
<psivaa> Mirv: just to give you an update.. there are some old files that needs clearing up to solve the issue. Will do that once the US side comes online
 * retoaded wants to let everyone know that some hardware replacement work is getting ready to start on the public jenkins server. While the work is happening the public instance will be unavailable. This is https://jenkins.qa.ubuntu.com
* cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | Landing instructions:  http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move), network slowness, work on public Jenkins
<psivaa> ogra_: http://pastebin.ubuntu.com/6453240/ is the dmesg during the failed network setup stage
<ogra_> well, there is an OOPS
<ogra_> hmm, actually only a warning
 * retoaded announces that the public jenkins instance is back up and operational. And it seems to perform significantly better. Just check https://jenkins.qa.ubuntu.com/view/All/ if you want to get an idea of how much more responsive it is now.
* cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | Landing instructions:  http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move), network slowness
<fginther> cyphermox, jibel, can one of you re-review https://code.launchpad.net/~fginther/cupstream2distro-config/update-stack_status/+merge/195956
<rsalveti> plars: happy birthday!
<plars> rsalveti: thanks :)
<ogra_> plars, happy b-day !!!
<rsalveti> plars: talking about the last_kmsg from the other devices, besides the modem shutdown message, do you know if the rest is also similar?
<rsalveti> I wonder if this is actually a wifi bug
<rsalveti> we got a change in wpa from cyphermox a few days ago, but not sure if that would cause any issue
<ogra_> rsalveti, psivaa noted networking issues too in the utah tests ... though seems thats more affecting maguro
<ogra_> rsalveti, i was wondering if the new udev has a new way of loading firmware so that our overrides stop working
<plars> rsalveti: I've seen this for sure on two devices - the mako in the lab that runs the image smoke tests, and the one sitting right next to me. They both had the same error
<rsalveti> ogra_: right, would be nice to know the issue with maguro, to see if it's related in some way
<rsalveti> ogra_: afaik it's using the same upstream base version, it was just a merge with debian
<ogra_> rsalveti, http://pastebin.ubuntu.com/6453240/ there is a warning OOPS, but nothing else intresting
<rsalveti> we could have issues, sure, but at least we didn't get a major version update
<rsalveti> plars: interesting
<ogra_> i think it pumped a bunch of debian versions at least
<ogra_> *bumped
<rsalveti> too bad I can't reproduce it here, let me reflash from scratch
<ogra_> 5 debian revisionas actually
<rsalveti> I think that warning is happening at every boot
<rsalveti> ogra_: right, but no major upstream version update, right?
<ogra_> rsalveti, well ... https://launchpad.net/ubuntu/+source/systemd/204-5ubuntu1 thats quite a changelog
<rsalveti> yeah hehe
<sergiusens> rsalveti, the only thing uploaded that was relevant to my eyes was wpa_supplicant
<ogra_> when was that uploaded ?
<sergiusens> ogra_, on you changes 19
<ogra_> i didnt see it in any of the changes files since image 22
<ogra_> oh, wow
<ogra_> how could i miss that
<ogra_>     deinitialize the P2P context when the management interface gets removed for
<ogra_>     whatever reason, such as a suspend/resume cycle. (LP: #1210785)
<ubot5> Launchpad bug 1210785 in wpa (Ubuntu Saucy) "wpa_supplicant crashed with SIGSEGV" [High,In progress] https://launchpad.net/bugs/1210785
<ogra_> thats the change
<sergiusens> plars, happy bday, here's your small token of appreciation https://code.launchpad.net/~sergiusens/phablet-tools/recovery_check/+merge/196102
<rsalveti> sergiusens: yeah, as I said before, cyphermox's changes :-)
<rsalveti> let me review that one now as well
<plars> sergiusens: cool, give me a sec and I'll take a look
<rsalveti> where is the broken recovery :-)
<sergiusens> rsalveti, was it image 23?
<sergiusens> or 22
<rsalveti> 25 iirc
<sergiusens> just phablet flash with that branch ad --revision 25 then
<sergiusens> should eventually timeout
<doanac`> sergiusens: as per that MP. does the .shell method detect errors?
<doanac`> usually you have to do that ADB_RC type hack
* doanac` changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: doanac | Landing instructions:  http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move), network slowness
<doanac`> added a note to the MP. with what i *think* is needed. not verified though
<sergiusens> doanac`, it doesn't; if it did, I would need to add an exception catch to the loop
<sergiusens> doanac`, as it's polling adb 'run something' when it may not be avail
<doanac`> sergiusens: okay. i see how it works now. /me sucks at reading diffs
<sergiusens> doanac`, the diff isn't that easy to read
<sergiusens> doanac`, either way, your proposal is still valid
<sergiusens> but I'd need to catch it every loop
<doanac`> the less we use the "ignore_errors=False" the better
<sergiusens> doanac`, too hacky?
<doanac`> sergiusens: it always feels that way to me. but then again, we have some amount of code that probably has no idea its ignoring errors
<cyphermox> rsalveti: ogra_: I very very strongly doubt this wpa change would break your stuff, whatever it is
<cyphermox> rsalveti: if something's broke, file a bug so I can take a look, please
<cyphermox> what the oops ogra_ posted before looks like it more an issue with bringing up the device at all, that's driver level stuff
<cyphermox> there was a message about writing the mac address, which happens long before wpasupplicant gets stsarted
<rsalveti> cyphermox: the oops is not an issue, the problem seems to happen with mako
<rsalveti> the device is rebooting now from time to time
<cyphermox> so how would this be related to wpa?
<rsalveti> cyphermox: http://paste.ubuntu.com/6451729/
<rsalveti> because it seems the wireless driver is causing the crash
<rsalveti> the last message, which causes the reboot, is just the modem doing shutdown
<rsalveti> but not the issue itself
<cyphermox> I see nothing there that points to wifi being broken
<cyphermox> if you feel like it, downgrade wpa, but then there's still a bug that really needs to be fixed in that commit
<cyphermox> I mean, downgrade as a test, not in the distro
<rsalveti> cyphermox: right, no clue exactly to what is happening, all we know is that we got a bunch of messages related with the mako's wifi driver
<cyphermox> right
<cyphermox> but those are all just info, not errors
<rsalveti> plars: which image was the last one we know that was working fine?
<cyphermox> on the contrary, it tells me that wifi should have properly disconnected
<rsalveti> right
<plars> rsalveti: looking at http://reports.qa.ubuntu.com/smokeng/trusty/touch/ 23 and 24 looked pretty good. iirc 24 didn't get a lot of reruns because of timing so it might have done slightly better with a little love
<plars> rsalveti: but then we had this adb issue in the lab, and the image 25 stuff, and devices were down for most of yesterday
<plars> rsalveti: so 26 didn't happen before 27 came out
<rsalveti> plars: can we give 26 a try/run?
<rsalveti> not sure how hard would be that
<rsalveti> so at least for this issue specifically we believe it's something between 24-27
<plars> rsalveti: we're not well set up for it, but I'm sure we could pull it off somehow. The other problem is that psivaa isn't seeing the issue happen this morning, and even last night it was pretty random for me. I saw it lots of times within minutes of boot both at home and in the lab, then my phone at home was up for a long time with no crash (it's been up for 13 hours now)
<plars> rsalveti: so I don't think we have a deterministic test for it at the moment
<rsalveti> plars: heisenbug?
<rsalveti> :-)
<plars> rsalveti: seems so, yes
<plars> rsalveti: but at least I had logs with proof that something bad was going on - from 2 different makos even
<rsalveti> yeah
<cyphermox> fginther: think we're good for just about everything soon to update all the jobs and all of that
<fginther> cyphermox, thanks, when that MP is merged, can you deploy the updates?
<cyphermox> fginther: once your cupstream2distro-config branch gets merged I'll deploy everything, yeah
<cyphermox> I already disabled all the build_all jobs to avoid it starting in 20 min
<didrocks> cyphermox: you need to redeploy saucy as well :)
<cyphermox> yep
<fginther> cyphermox, the MP is merged now
<dobey> fginther: hey. quick question about the PPA usage for upstream merger 2.0. what's the specific reasoning behind using dput directly instead of using recipes there?
<cjwatson> recipes have a cap on how many builds per day you get
<cjwatson> I wouldn't advise using them for this
<fginther> dobey, mainly because that is what our tools currently do, is there advantages to using recipes?
<dobey> cjwatson: it depends on exactly what the goals of the PPA builds are
<dobey> fginther: i'm just curious because tarmac already has existing support for triggering recipe builds on launchpad, after the successful merger of branches in a target
<fginther> the goal is to create a builds of MPs to be tested
* plars changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: plars | Landing instructions:  http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move), network slowness
<fginther> so prior to merging to trunk
<dobey> fginther: so the "custom rotated PPAs for testing MPs" part of the CI Airline stuff?
<fginther> dobey, right, they are just build slaves
<dobey> yeah, recipes would be problematic to use for that
<dobey> i didn't realize it was for that purpose. i thought it was for the post-merge builds into the daily PPA, as upstream merger is doing currently
<dobey> wasn't clear in the session :)
<fginther> dobey, sorry about that, thanks for the question though, there may be a use case for that functionality
<cyphermox> fginther: didrocks: deploying head now
<didrocks> \o/ deploying THE head please! ;)
<fginther> cyphermox, thank
<cyphermox> alright didrocks. deploying TEH head.
<didrocks> ;)
<fginther> dobey, upstream merger does dput sources on merge of specific projects, a recipe might be a better way to handle this in the future
<fginther> these dputs are based on specific needs of the project owners, recipe might give them more control over that
<dobey> fginther: right. we're using recipes extensively with the u1 tarmac setup
<cyphermox> dobey: depends if you mean launchpad recipes or bzr builder recipes, I guess.
<dobey> cyphermox: they are the same thing, but i mean recipes hosted on launchpad of course :)
<cyphermox> well, you could get the best of both worlds and use bzr builder recipes, but just dput the built source package after..
<cjwatson> I'd still caution against it for anything that might be high-volume for a single recipe.  you might not be running into that with tarmac right now, but ...
<cjwatson> (the limit is IIRC five a day, and if we wanted to unhardcode that we'd need to very carefully consider the impact on the build farm as some users abuse recipes to the maximum extent possible and our build farm is already oversubscribed)
<cyphermox> didrocks: fginther: deploying TEH sauce now.
<fginther> cjwatson, noted
<didrocks> !
<cyphermox> saucy done..
<didrocks> sweet!
<cyphermox> so you're saying not to bother with raring?
<fginther> cyphermox, we should be ok to start a build
<cyphermox> yup, thatÅ the next step, I'll start QA now
<fginther> doh~
<fginther> doh!
<fginther> fixing
<fginther> cyphermox, https://code.launchpad.net/~fginther/cupstream2distro/fix-missing-paren/+merge/196180
<cyphermox> fginther: so since I mentioned a symlink before, and all the paths are supposed to be up to date, if you added a symlink it would be best to remove it, to avoid keeping old crap working by chance
<fginther> cyphermox, there is no symlink at the moment, I'm also going to hide the old /var/lib/jenkins
<cyphermox> ok
<cyphermox> at least I don't need to redeploy everything for this fix :)
<fginther> cyphermox, :-), just waiting for the MP to merge
<fginther> cyphermox, is lp:cupstream2distro merged by hand?
<cyphermox> no, it should also be under ci... didrocks?
<fginther> cyphermox, ack, I'll merge then
<didrocks> cyphermox: it's by hand IIRC
<cyphermox> oh ok
<fginther> cyphermox, ready again
<cyphermox> ok
<cyphermox> well, crap.
<cyphermox> Building on master in workspace /iSCSI/jenkins/jobs/cu2d-qa-head/workspace
<cyphermox> [workspace] $ /bin/bash -eu /tmp/hudson3259210953020072847.sh
<cyphermox> only one instance of a stack can be queued for building
<cyphermox> not sure what to do with this
<fginther> cyphermox, are these just stale files?
<cyphermox> no idea
<cyphermox> http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/QA/job/cu2d-qa-head/435/console
<cyphermox> oh wait
<cyphermox> yeah just stale files
<cyphermox> I don't have access to remove them though
<fginther> is it safe to remove ALL the stack.status files (I can do that)?
<cyphermox> see /iSCSI/jenkins/cu2d/work/head/qa
<fginther> I'll remove that first
<cyphermox> btw (pending - daily-release-executor is offline )
<fginther> cyphermox, ugh
<dobey> cjwatson: i'm not sure what the limit for recipe builds is, but it is per-user, and i'm sure we could get an increase in the limit for the necessary bots, if needed. tarmac also works on multiple MPs before triggering the recipe, not single MPs one-at-a-time as j-l-p currently does
<cjwatson> dobey: like I say, it's five a day and there is no provision right now for any kind of configurability
<cjwatson>     def isOverQuota(self, requester, distroseries):
<cjwatson>         """See `ISourcePackageRecipe`."""
<cjwatson>         return SourcePackageRecipeBuild.getRecentBuilds(
<cjwatson>             requester, self, distroseries).count() >= 5
<cjwatson> recipes aren't really meant for this kind of use case AIUI, but you'd have to talk to a real LP developer rather than a stunt one :-)
<cjwatson> (i.e. that's per[C per-requester per-recipe per-series)
<cjwatson> modulo lag
<dobey> right
<dobey> it's also something we could improve in launhpad itself, as well
<cjwatson> maybe, though as I say there are other considerations and dput should be perfectly functional already
<cjwatson> without any of these limitations
<cjwatson> one great thing about it being hardcoded is that there's no temptation for admins to allow 10 chromium recipe builds a day if somebody is really annoying about it :-)
<cyphermox> ahah :)
<dobey> cjwatson: and yet, it's also easy enough to work around and build chromium 10 times a day :)
<cjwatson> true, though there were many and various reasons why I put effort this year into making build cancellation reliable :-)
<cjwatson> it's much more of a pain to deal with when recipes are generating the builds as you're trying to get queues clear enough for other people's builds to happen
<cjwatson> but shrug
<fginther> cyphermox, \o/ daily-release-executor is online
<cyphermox> yay
<cyphermox> thinks look pretty good so far
<fginther> cyphermox, http://q-jenkins.ubuntu-ci:8080/job/cu2d-qa-head-1.1prepare-autopilot-gtk/418/console
<cyphermox> fginther:
<cyphermox> dpkg-source: error: can't build with source format '3.0 (native)': native package version may not have a revision
<cyphermox> dpkg-buildpackage: error: dpkg-source -b autopilot-gtk-1.4+14.04.20131121 gave error exit status 255
<cyphermox> debuild: fatal error at line 1361:
<cyphermox> dpkg-buildpackage -rfakeroot -d -us -uc -v1.4+14.04.20131106.1-0ubuntu1 -S failed
<cyphermox> bzr: ERROR: The build failed.
<cyphermox> I don't think that's your fault
<fginther> cyphermox, what about the "prepare-package", line 193, traceback?
<fginther> was that caused by the bzr failure?
<cyphermox> afaik yes
<cjwatson> you need pristine-tar information in the branch so that bzr-build{er,deb} can reconstruct an .orig.tar.gz
<cjwatson> dpkg-source got stricter about this in trusty
<cjwatson> i.e. if you declare 3.0 (quilt) it actually wants this to be possible and won't just silently fall back to 3.0 (native)
<cjwatson>   * Catch mismatches between version strings and format versions in
<cjwatson>     dpkg-source. Ensure that a 3.0 (quilt) package has a non-native version
<cjwatson>     and that a 3.0 (native) package has a native version. Closes: #700177
<cjwatson>     Thanks to Bernhard R. Link <brlink@debian.org>.
<cyphermox> this is in time going to break each of the packages
<fginther> \o/
<cyphermox> cjwatson: ack, makes sense
<cjwatson> there's some support for pristine-tar information as a bzr property somewhere but I don't remember the details
<cjwatson> infinity: ^- I wonder if we should consider temporarily reverting that change; it's been causing trouble for people showing up in #launchpad too
<infinity> cjwatson: pristine-tar, or people can stop using non-native versions for their recipes.
<infinity> cjwatson: But I could revert the dpkg strictness too...
<cyphermox> cjwatson: don't revert that for us though. I've been kind of against using native for non-native packages.
<cyphermox> unless didrocks says otherwise, it's his baby after all
<cyphermox> but none of this really needs to be native packages
<cjwatson> the pristine-tar bit is kind of cumbersome and non-obvious
<cjwatson> there's "bzr import-upstream" according to https://answers.launchpad.net/launchpad/+question/203083
<didrocks> it doesn't seem straightforward indeed
<didrocks> cyphermox: we should just use 1.0 package for those as we are in split bzr mode
<cjwatson> "bzr help import-upstream" actually looks pretty easy to run
<cjwatson> could you try that before changing the source format?
<cyphermox> oh, you're right, they should be 1.0 anyway
<cyphermox> if the import-upstream bits work I'd be all for moving to 3.0 though
<cyphermox> provided there wan't another such strictness that we chose 1.0 for
<cyphermox> I'll look at import-upstream
<didrocks> cjwatson: import-upstream is to import an upstream tarball
<didrocks> we don't have upstream releases
<cjwatson> oh, then you should be native in some way, indeed
<cyphermox> right
<cjwatson> I'd suggest changing the version number scheme and using 3.0 (native) then, if possible
<cjwatson> it would be a better reflection of reality
<cjwatson> that said: you *do* seem to have upstream tarballs
<cjwatson> in that e.g. "apt-cache showsrc unity8" shows me .orig.tar.gz
<cjwatson> but I guess it's cumbersome to import those in advance of "releases"?
<didrocks> cjwatson: we create them
<didrocks> with bzr bd, split mode
<didrocks> for other distro if they want to use it, one dayâ¦
<didrocks> and bzr bd is then, getting this 3.0 conflict now, even in split mode ^
<cyphermox> didrocks: autopilot-gtk
<cjwatson> 1.0 probably isn't terrible for that, but this seems like a bunch of work for now when we could revert the dpkg change and get moving again
<cyphermox> because it's in 3.0... but most other pacakges should be 1.0 as per the wiki
<cyphermox> didrocks: couldn't cu2d import-upstream as it goes to do the package build?
<didrocks> cjwatson: if you can revert it, then, we can have a task to update everything for 1.0
<didrocks> cyphermox: well, it's a chicken and egg problem
<cjwatson> though it would be pretty rubbish to end up in a place where the CI infrastructure can't deal with packages that *do* have a separate upstream existence
<didrocks> you need import-upstream for running bzr bd now
<cjwatson> didrocks: I'm out of time for this week, but if infinity wants to do it ...
<didrocks> and you need to run bzr bd to get an upstream image
<didrocks> cjwatson: previously, I was doing it myself, without bzr bd
<didrocks> but it's hackish
<didrocks> cyphermox: maybe we can use --export-upstream=
<didrocks> that maybe won't run debian/rules and get into this dpkg change
<cyphermox> yeah... that or some for of bzr export as the get-orig-source rule, or whatever it is that creates a tarball
<didrocks> cyphermox: do you have some time to investigate today?
<cyphermox> didrocks: already done
<cyphermox> well, kindof
<cyphermox> hold on a second :)
<didrocks> oh nice! it's working?
<didrocks> ok ;)
<cyphermox> well itÅ working and you don't have to run bzr bd twice...
<didrocks> excellent!
<cyphermox> let me make sure
<didrocks> cyphermox: feel free to MP against cupstream2distro once confirmed :)
<dobey> fginther: btw, did you get to make any progress on the u1 branches in tarmac with daily-release support stuff?
<fginther> dobey, ah, yes. forget to send you the infos
<cyphermox> didrocks: we'll still need to make it (quilt) instead of (native)
<didrocks> so, it's a change either way
<didrocks> but in even more packages
<fginther> dobey, https://code.launchpad.net/~fginther/cupstream2distro-config/ubuntuone-no-upstream-merger/+merge/196189
<didrocks> we should maybe revert the dpkg change and transition then to (quilt)
<didrocks> with your change
<didrocks> infinity: ^
<cyphermox> didrocks: why do we need to revert the dpkg strictness then?
<cjwatson> oh, I got it backwards, you're 3.0 (native) right now not 3.0 (quilt)
<dobey> fginther: i don't really understand what that does exactly
<infinity> If they're 3.0 (native), just fix the version number.
<cjwatson> well having 3.0 (native) with a revision number is just unambiguously wrong :-)
<cyphermox> yes
<infinity> I *can* revert the dpkg change, but I don't want that to be an excuse for people to keep being wrong. :P
<didrocks> cyphermox: well, because evrything will fail?
<cyphermox> didrocks: well we have the occasion of fixing it by fixing the source format where necessary?
<didrocks> infinity: they are not native, but bzr bd doesn't know how to split the package correctlyâ¦
<sergiusens> agree, fix version number to match what you are doing
<infinity> didrocks: If the format is 3.0 (native), they're native...
<cyphermox> didrocks: actually, that particular pacakge does specify 3.0 (native)
<didrocks> cyphermox: is debian/source says natives?
<didrocks> ah
<infinity> didrocks: If they have orig tarballs, stop calling them native, and import the tarballs.
<didrocks> so please drop that
<infinity> didrocks: There's not really an in between here, is there?
<didrocks> cyphermox: that should be enough right?
<cjwatson> just to clarify, if we're reverting the dpkg change then that should IMO be primarily because it's a support cost for #launchpad (if that can't be handled some other way)
<didrocks> infinity: well, I didn't set it to native, clearly
<cjwatson> in terms of recipes in general
<cyphermox> right. the 3.0 (native) is absolutely wrong, and that's it
<didrocks> infinity: I agree :)
<fginther> dobey, sorry, it's not well explained. Essentially this will allow ubuntuone-client-data and ubuntuone-credentials to be picked up by the daily-release process when they are ready
<didrocks> cyphermox: so, please change that :)
<didrocks> and be done
<cyphermox> didrocks: as far as I know it's enough yeah
<cjwatson> however, the next couple of people who come into #launchpad with this problem, I'll point them at bzr import-upstream now that I've found it
<fginther> dobey, but it will not do any upstream-merger on them
<cjwatson> and we'll see if that helps, and FAQify or whatever
<dobey> fginther: does that change mean ps jenkins bot won't run the tests in ps jenkins, as is currently happening?
<fginther> dobey, yes, ps jenkins will ignore these
<dobey> fginther: i don't think we want/need to stop that happening. is that required to make daily-release possible, while using tarmac?
<cyphermox> https://code.launchpad.net/~mathieu-tl/autopilot-gtk/source-format/+merge/196190
<infinity> cyphermox: Of course, 3.0 (quilt) might *still* fail because you lack an orig...
<infinity> cyphermox: Unless you're also going to fix that.
<infinity> (Or does this have an orig?)
<fginther> dobey, I can revisit it, but I don't have time to spend on it right now. I thought that disabling upstream merger might be a viable short term solution, but it appears to not be the case
<fginther> dobey, my other thought would be to make some change to tarmac to operate on specific branches
<sergiusens> infinity, cyphermox looking at the history, it was initially 3.0 (native), when added to daily release switched to 1.0 then someone changed it to 3.0 (native) again
<sergiusens> meaning that maybe some general communication on this would help
<dobey> fginther: it would be possible and very easy to add such a feature to tarmac, if it's necessary. it doesn't really fit with the general design of how tarmac works, but it's very simple for me to implement.
<cyphermox> infinity: AFAICS bzr bd in split mode should be writing the orig anyway... and it seems to on my system
<infinity> cyphermox: Ahh, cool.  So, that's a solved problem for you guys, just don't call those native. :P
<fginther> dobey, ok. let me create a bug with what I think would help
<infinity> Non-split recipes run into dpkg whining at them, and importing the actual upstream tarball is the solution there.
<cyphermox> I've always said those weren't supposed to be considered native packages in any way, since they have a debian rev
<dobey> fginther: could you enumerate in an e-mail ro something for me, what exactly is required for daily-release to work with the current setup, on a purely technical level (must be specific branch merge, must have debian/ in-tree, etcâ¦ sort of stuff)?
<fginther> dobey, sure
<infinity> cjwatson: I guess we could make lp-buildd try to spit out a useful "hey, maybe you need to bzr import-upstream" message on failed recipe-derived builds of that sort?  I dunno.
<dobey> fginther: thanks. that should make it clearer as to what we need to exactly to make it work and fit tarmac in for doing the merges
<cyphermox> brb
<dobey> fginther: and i voted disapprove on that MP as it doesn't seem to facilitate what we want to do there. :)
<fginther> dobey, agreed
<thomi> didrocks: still around?
<fginther> dobey, https://bugs.launchpad.net/tarmac/+bug/1253770
<ubot5> Ubuntu bug 1253770 in Tarmac "Feature request: provide API to use raw tarmac features without the workflow" [Undecided,New]
<retoaded> all, I am starting to mark the various jenkins instances as "prepare to shutdown" so no additional jobs start before we have to take things down for the (hopeful) network fix.
* plars changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions:  http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move), network slowness
#ubuntu-ci-eng 2013-11-22
<Mirv> cihelp failure with successful tests, permission denied on autopilot-nvidia http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/OIF/job/cu2d-oif-head-2.2check/368/console
<vila> Mirv: hurrah! That's evidence we can find the remaining hardcoded /var/lib/jenkins
<didrocks> interesting, that was though what was updated by Francis during the migration
<vila> didrocks: probably something else
<vila> didrocks: could it be a reference in results produced earlier ?
<didrocks> vila:     echo "Calculating results for machine $machine"
<didrocks>     JUNIT=$(/iSCSI/jenkins/cu2d/cupstream2distro/latest_autopilot_results $JENKINS_HOME $JOBROOT $machine)
<didrocks> vila: no, I don't think so
<didrocks> but latest_autopilot_results has been updated
<didrocks> is JENKINS_HOME pointing to the right one?
<didrocks> yeah, seems so: http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/OIF/job/cu2d-oif-head-2.2check/368/injectedEnvVars/?
<didrocks> let's check first latest cu2d is in prod
<didrocks> yep
<didrocks> hum, not sure TBH
<didrocks> vila: I would suggest set -x
<didrocks> to debug the issue
<didrocks> to know exactly where it's failing
<didrocks> forget that, it's failing in cu2d-autopilot-report
<didrocks>     histdir = os.path.abspath(os.path.expanduser(histdir))
<didrocks> vila: here yo uhave your issue ^
<didrocks> so, it's args.logfile
<didrocks> which is the first non optional argument
<didrocks> so $JUNIT
<didrocks> and     JUNIT=$(/iSCSI/jenkins/cu2d/cupstream2distro/latest_autopilot_results $JENKINS_HOME $JOBROOT $machine)
<didrocks> would be interesting to really run that with set -x then
<vila> ~jenkins should expand to iSCSI
<didrocks> vila: can be $JUNIT which is wrong
<didrocks> anyway, I'll let the CI team try that, I can help if needed
<vila> and it does (~jenkins that is)
 * didrocks stops stepping on shoes :)
<vila> didrocks: how did you checked the latest cu2d is in prod ?
<didrocks> Mirv: how is the situation for those prepare job failing due to bad debian/source/format? really bad or okish?
<didrocks> vila: yep:
<didrocks> 09:43:52   didrocks | let's check first latest cu2d is in prod
<didrocks> 09:44:05   didrocks | yep
<vila> didrocks: *how* ?
<vila> :)
<didrocks> vila: logged in as desktop-team@
<didrocks> and checked the rev
<vila> didrocks: I thought 'bzr pull'ing there was different from deploying the jobs though (but fginther said cyphermox did that yesterday anyway)
<didrocks> vila: hum, no, normally the version in ~jenkins is a symlink to that
<didrocks> vila: not sure if that changed though
<didrocks> vila: if not, there are potential for failures btw
<vila> didrocks: nah, pretty sure I checked that and that's a symlink to /home/desktop-team (so a potential issue if ~desktop-team change but that's not the case for now)
<didrocks> ah great :)
<vila> ./bin/find_publisher_failures.sh:find /var/lib/jenkins/cu2d/work -name "publisher.xml" -print -exec grep -i fail {} \;
<didrocks> what's this bin/ ?
<vila> different one, is that script used in jenkins or just something
<vila> sry ~d-t
<didrocks> waow, doesn't ring a bell at all
<vila> different one, is that script used in jenkins or just something used manually ?
<vila> ok, will fix anyway just in case
<didrocks> vila: I don't think it's used
<didrocks> I would say 2)
<didrocks> but nice catch anyway :p
<Mirv> didrocks: I didn't find other occurences besides autopilot-gtk, just other problems like the one pointed to ci_help with autopilot-nvidia, manual upload to archive, and autopilot failures
<Mirv> didrocks: but the mergers have problem with mathieu's commit even though bzr bd works fine
<didrocks> Mirv: if there is only one, I would say "phew"!
<didrocks> Mirv: for the manual upload to archive, can you reconcile them?
<didrocks> so that at least all prepare jobs are green
* ev changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: ev | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move), network slowness
<didrocks> elopio: you can remove network slowness from the title I guess :)
<didrocks> ev: ^
<didrocks> sorry elopio :)
<elopio> np
<Mirv> didrocks: I fixed the changelog entry for indicator-datetime already
<elopio> hey didrocks, would you know why an autopilot feature that landed in 2013-11-07 is not yet available in the mako runners?
<didrocks> Mirv: rock \o/
<didrocks> elopio: not released due to the CI infra, mostly (and no landing ask from autopilot on the landing spreadsheet)
<elopio> didrocks: so, is the landing ask the only thing I'm missing now?
<thomi> didrocks: I added a landing ask yesterday I think?
<didrocks> elopio: thomi: ah, nice, I didn't check
<thomi> didrocks: :)
<didrocks> just be aware that the queue is a little bit long
<didrocks> until the whole infra is up and we catch up on our debt
<didrocks> so probably next week
<elopio> thanks thomi and didrocks.
<thomi> didrocks: that's cool - I wanted to land AP before I merged some more.... experimental features :)
<didrocks> thomi: hum, you meant:
<didrocks> experimental *safe* features?
<didrocks> right right? ;)
<thomi> didrocks: right, of courtse :)
<didrocks> heh
<thomi> I made sure they're not getting merged yet
<thomi> until I see the new AP released to distro
<thomi> then I'll merge them and make sure they don't break anything
<thomi> and submit a new landing aslk
<thomi> anyway, I'm off to bed. Hooray for the weekend!
<thomi> catch you later y'all ;)
<vila> didrocks: I think I have some winners here:
<vila> jenkins@jatayu:~$ grep /var/lib/jenkins ~jenkins/cu2d/*rc
<vila>  
<vila> grrr stupid results starting with '/'
<vila> cu2d/100scopes.autopilotrc:history=/var/lib/jenkins/cu2d/history/100scopes
<vila> cu2d/default.autopilotrc:history=/var/lib/jenkins/cu2d/history
<vila> cu2d/indicators.autopilotrc:history=/var/lib/jenkins/cu2d/history/indicators
<vila> cu2d/oif.autopilotrc:history=/var/lib/jenkins/cu2d/history/oif
<vila> cu2d/unity.autopilotrc:history=/var/lib/jenkins/cu2d/history/unity
<vila> didrocks: so, what are these files ?
<didrocks> vila: oh, you got it!
<didrocks> vila: yeah, those conf files are what set the threshold
<didrocks> like number of accepted failures
<didrocks> number of regressions between 2 runs
<didrocks> and so on
<didrocks> so they need to be adjusted
<didrocks> vila: really nice catch!
<vila> didrocks: not under version control then and not part of the job definitions, so... edited manually ?
<didrocks> vila: yeah, we changed those values a lot, they are configurations
<didrocks> vila: the final goal is to remove them
<didrocks> and not have any flacky test
<didrocks> so all to "0"
<vila> didrocks: grey area then, sounds like ~desktop-team should maintain them rather than ~ci ? Or both ? Hard to to get a clear cut there, thoughts :-/
<didrocks> vila: in fact, the ones you need to changes are in cu2d/history/*/
<didrocks> vila: I can change them
<didrocks> if I have access
<didrocks> let me check
<didrocks> vila: mind giving me the new path?
<didrocks>  /I*?
<vila> ~jenkins
<vila> ~jenkins/cu2d even, haaa, so no access
<vila> urgh
<didrocks> vila: I'm read-only
 * vila nods
<didrocks> one those files
<didrocks> vila: if you can just sed them, that would be appreciated
<didrocks> vila: I don't see those values changing right now
<vila> didrocks: sure, doing it right now
<didrocks> and then, the config files will be dead
<vila> didrocks:  ?
<didrocks> vila: think about doing those in cu2d/history/*/
<didrocks> vila: end goal: 0 flacky tests accepted
<didrocks> so no file :)
<vila> didrocks: why can't that be done in cu2d-config instead, will address the access issue
<didrocks> vila: it can TBH, I don't think it worth it to add another move
<didrocks> let's get the prod running again IMHO
* ev changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: ev | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: https://wiki.canonical.com/UbuntuEngineering/CI/1ss-move-current-issues
<vila> didrocks: oh sure, first thing is to fix prod, the question was for the middle/long term
<vila> didrocks: should be fixed
<vila> Mirv: ^
<ogra_> === Image r28 building ===
<Mirv> vila: thanks!
<vila> Mirv: yw
<Mirv> vila: rerunning at http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/OIF/job/cu2d-oif-head-2.2check/369/console
<vila> Mirv: rock&roll ;)
<vila> Mirv: and success right ?
<vila> Mirv: I mean for the path fix that is
<Mirv> vila: that seems success, something else isn't. the subtasks were still successful but it's marked a failure (as seen at http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/OIF/job/cu2d-oif-head-2.2check/369/)
<Mirv> but yes the path seems now work. there's some problem of changed amount of tests ("-121"), some information from somewhere tells there should have been more tests that were run
<vila> Mirv: yeah, same diagnostic as you. I would wait for one more run before worrying about it though because that previous run failed because of the path and that failure may not be taken into account by the check code
<Mirv> didrocks: so will I merge that autopilot-gtk branch manually ie you don't need it for debugging whether merger works properly?
<Mirv> vila: ok, doing that at /370/
<didrocks> Mirv: no, don't bother
<didrocks> Mirv: do you have the url?
<didrocks> Mirv: that will enable with fginther to validate the change
<Mirv> didrocks: ok. https://code.launchpad.net/~mathieu-tl/autopilot-gtk/source-format/+merge/196190 - it'll probably fail again soon.
<didrocks> ev: FYI, this can delay a little bit what I needed to work with with fginther (but I do think we'll be ready by Monday evening), but production first ^
<didrocks> ev: we'll still start together today, just maybe not end
<didrocks> Mirv: thanks!
<Ursinha> popey, good morning
<Ursinha> oops, wrong channel hehe
<ev> otp
<Mirv> vila: still the same: http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/OIF/job/cu2d-oif-head-2.2check/370/console
<vila> Mirv: otp
<ev> didrocks: *nods* absolute agreement there
<vila> Mirv: yeah, no idea but I get the feeling it's more a cu2d issue than a ci one so unless we find better evidence I won't dig further (also didrocks said don't bother ;)
<Mirv> vila: I think he said don
<Mirv> t bother to the autopilot-gtk one, not this one :)
<Mirv> vila: another problem radeon connectivity broken, I saw it in another one as well in the morning: http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/label=qa-radeon-7750/562/console
<Mirv> connectivity or some another problem of course, it's just that the IP address renewal tends to show up when things are halted
<Mirv> so that's blocking now, after which if this http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/OIF/job/cu2d-oif-head-2.2check/370/console happens elsewhere too then none of the check jobs will pass
<Mirv> vila: feel free to stop that radeon job if you don't need it, but I'll keep it running for now for possible debugging needs. also, I see you're not vanguard anymore so feel free to pass it on :)
<vila> Mirv: the X server crashed inside the container on qa-radeon-7750, you should get that log in the artifact once the job finish
<Mirv> vila: regarding the test count issue, you're right that it's probably cu2d side although we may not have access rights to fix that manually. it's possible we need to do one publish by looking at the results beneath (if they are green)
<Mirv> vila: the job finishing I guess still takes 2 hours or so?
<Mirv> anyhow, it seems there's a problem on radeon since the previous problem was on radeon too
<vila> Mirv: right, that's my take too
<Mirv> previous one was http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/label=qa-radeon-7750/551/console
<asac> any idea what result output format autopkgtests has?
<asac> jibel: ?
<Mirv> vila: and yes there's a crash http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/label=qa-radeon-7750/551/artifact/results/Xorg.0.log
<seb128> didrocks, do you know if there is going to be an ubuntu-keyboard landing soon? I see it on the landing asks but with no landing slot assigned yet
<vila> Mirv: enough for you to ping upstream right ?
<Mirv> vila: well I don't think it's much help that "it crashes", more probable that the radeon isn't up to the task still and glamor-egl would need to mature still
<didrocks> seb128: see my email, I think it will be after the indicators
<didrocks> so monday
<vila> Mirv: but some jobs succeed so that
<Mirv> vila: there's (yet) another problem that this error still happens after aborted job in the next job: http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/label=qa-radeon-7750/563/console - was it on radar somewhere to investigate?
<vila> 's good input for upstream to reduce the scope
<seb128> didrocks, ok, thanks (what email? the one to -phone earlier? I read it but it didn't have any detail that would me guess if keyboard would in 1 day or 1 week ;-)
<Mirv> vila: yes some succeed some not. who was the upstream, I think you contacted last time?
<vila> mklanhost (wrong spelling probably ;)
<didrocks> seb128: not keyboard specifically, but that we are slowing resuming landings
<seb128> didrocks, btw I'm asking because libpinyin had a soname change in trusty and is blocked in proposed until ubuntu-keyboard gets rebuild with the new soname
<seb128> it can wait next week though, no worry
<seb128> didrocks, thanks!
<Mirv> vila: ok, reporting the radeon problem upstream, we may need to disable using it again until it's fixed
<Mirv> vila: so what about that next-job-after-abort-fails-to-bring-up-lxc?
<didrocks> seb128: sorry (was in a hangout)
<didrocks> seb128: ok, setting it for Monday, thanks for the head's up!
<seb128> didrocks, thanks!
<didrocks> seb128: in landing plan
<vila> Mirv: fixed, the container needs to be stopped, sounds like either an otto bug or a misuse, this should not happen right ?
<seb128> didrocks, 'ci ;-)
<vila> stopped manually that is
<Mirv> vila: it still looks the same: http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/label=qa-radeon-7750/564/console
<Mirv> vila: so that should be at least on some list of issues to track down I think
<vila> Mirv: http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/label=qa-radeon-7750/566/console
<vila> Mirv: are you sure you checked on a job started *after* I stopped the container ?
* ev changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: https://wiki.canonical.com/UbuntuEngineering/CI/1ss-move-current-issues
<Mirv> vila: it happens every time when any job is aborted, so the next job that gets started
* josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: josepht | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: https://wiki.canonical.com/UbuntuEngineering/CI/1ss-move-current-issues
<vila> Mirv: right and the current timeout is 330 mins leading to aborts, I wonder if the solution here is not to 1) reduce the timeout 2) consider that encountering a running container is plainly wrong and have otto stop it instead of emmitting that error message
<vila> Mirv: otherwise I'd be tempted to say: it blocks if you abort a job ? Don't do that then ! ;)
<Mirv> maybe both I'd think, there's not much sense (?) in 330 mins of timeout, but also it'd be nice if it wouldn't break but either wait or stop the container automatically, since it anyway happens for the next one after the breaking one
<Mirv> vila: it blocks if I don't abort a job ;)
<vila> Mirv: but if you let the timeout expire it doesn't block right ?
<vila> Mirv: so something is wrong in how the abort is handled no ?
<vila> Mirv: i.e. I agree with 'not much sense (?) in 330 mins of timeout' and 'it'd be nice if it wouldn't break'
<vila> Mirv: IIUC, a manual intervention (or two) is required right now, that's wrong :)
<Mirv> vila: yeah, in that case the next one doesn't break, as seen in the radeon job from 08:09:08 from this morning (the previous one timeouted)
<Mirv> vila: indeed the abort case should behave more like what happens when it timeouts
<vila> jibel: thoughts ^ should I start with filing a bug against otto ?
<Mirv> even if it would be a shorter timeout, it would still make sense that it's possible to abort jobs when needed
<didrocks> vila: agreed with 2)
<didrocks> Mirv: vila: no way to try to catch the abort
<didrocks> jenkins SIGKILL
<josepht> or 3) have otto clean up containers when it exits abnormally
<didrocks> not SIGTERM
<jibel> vila, not a bug. The problem is that it runs through sudo and when you abort a job it is the user 'jenkins' that kills the process
<didrocks> josepht: see above ^
<jibel> vila, and it cannot kill processes it doesn't own
<josepht> so the job needs to clean up the container then
<vila> jibel: so, otto should not block when it encounter a running container since the only valid use case is that a previous job was aborted ?
<jibel> vila, josepht I wrote a script to handle this situation that will kill all the process started from the top parent process
<jibel> vila, yes it should because you cannot share the same physical device twice
<vila> jibel: but why not just stopping the container instead of emitting the error message ?
<josepht> is the container named the same thing every time?
<jibel> vila, because you don't know if it is runnig on purpose or not, do you?
<vila> josepht: doesn't really matter, only a single container should run
<jibel> vila, try this http://bazaar.launchpad.net/~otto-dev/otto/trunk/view/head:/jenkins/children_monitor
<vila> jibel: see above, it seems the only case when it happens is when the previous job was aborted
<jibel> if is not already there
<jibel> vila, there is no link between jobs, a new job doesn't know why a container is already running
<jibel> if it has been started manually from the machine or another job is running or whatevere
<jibel> you cannot just kill what is running
<vila> ha, hence that script
<vila> jibel: but who should call it and when ?
<josepht> can't we use trap to remove the container (from the jenkins execute shell script) on exit?
<jibel> in the jenkins build step that escalate privileges with sudo
<jibel> josepht, that's basically what this script does
<jibel> but it also ensure that all children processes started from this jenkins script are killed
<josepht> jibel: okay, sounds good to me
<vila> jibel: that would be http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/configure right ? (and friends but let's start with this one)
<didrocks> josepht: it's not an exit, it's a SIGKILL (so you can't trap)
<jibel> correct
<vila> you lost me here, can we or can't we use that script ? (almost no experience with signal handling in shell scripts)
<jibel> vila, you can use the script, create a test script to verify
<jibel> vila, in a shell build step put this script on first command, then sudo <forever> and abort
<jibel> I'm pretty sure I had an exmaple somewhere
<vila> 'sudo kill' is the trick, got it
<vila> jibel: but what about didrocks remark about not being able to catch SIGKILL ? Or is instead that jenkins will send SIGABRT ?
<jibel> vila, just try it
<vila> jibel: doesn't work http://q-jenkins.ubuntu-ci:8080/job/otto-test-radeon/
<vila> jibel: as in: the container is still running
<vila> $HOME/bin/children_monitor & at the beginning of the execute shell build step '&' required otherwise the script doesn't background itself. But if I read it correctly the script monitors the children of its parent
<jibel> vila, okay, I'll check in a moment
<fginther> morning
<didrocks> hey fginther!
<vila> jibel: otherwise, I'm tempted to ignore the use cases 'started manually from the machine' (de-provision first) and 'another job is running' (it shouldn't, and both will break if it happens)
<vila> jibel: or rather, if otto stops the running container, 'another job is running' the later job will be able to run
<fginther> didrocks, Mirv what's the state of the cu2d jobs building?
<didrocks> fginther: everything's fine, apart from the autopilot-gtk MP due to the dpkg change
<Mirv> fginther: building pretty good, check jobs not so, plus the merger problem
<didrocks> yeah, check jobs is another story
<didrocks> Mirv: you are working with vila on it, right?
<Mirv> fginther: mostly radeon AP would probably need disabling since it crashes again frequently (glamor-egl, filed a bug)
<josepht> vila, jibel: this script http://paste.ubuntu.com/6458664/ results in this output http://paste.ubuntu.com/6458662/ when aborted
<Mirv> didrocks: well vila is working on the long annoying detail of the next job breaking after abort, otherwise I've just suggested the disabling of radeon but not done it
<didrocks> ok
<Mirv> didrocks: I updated cu2d-config for those that need it, so the remaining problems are mostly radeon breaking up, and then the problem seen in oif that amount of tests has changed so we may need to publish once (I don't know how to fix that manually)
<didrocks> Mirv: 2 runs of the check job should fix it
<Mirv> didrocks: it did not, for some reason
<didrocks> hum, interesting
<Mirv> didrocks: http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/OIF/job/cu2d-oif-head-2.2check/370/console + 369
<Mirv> hmm, looking at it again, maybe it's thrice this time? ;)
<didrocks> Mirv: ah did you retry?
<didrocks> Mirv: in fact, it stops at first issues
<didrocks> so don't go to the next machine
<didrocks> as you see here, it went to the next machine
<didrocks> failed first on nvidia
<Mirv> didrocks: yes, so it didn't stop on nvidia anymore
<didrocks> second run, nvidia passed and intel stopped
<didrocks> right
<Mirv> ran again. so that's probably solved by rerunning, so remaining problem would be deciding of disabling of radeon
<vila> josepht: so both EXIT and TERM are received and handled ?
<josepht> vila: yes, it doesn't work with only EXIT or TERM trapped
<vila> josepht: jibel script traps both
<didrocks> josepht: you are the vanguard and looking at radeon?
<josepht> didrocks: I'm helping :)
<didrocks> great ;)
<vila> josepht: may be I should indeed let you handle that with jibel, I've still a pile of incident backlog  to process
<josepht> vila: ack
<vila> josepht: and that script of yours should end up in some jenkins test suite, useful knowledge to share that ;)
<Mirv> josepht: so I filed bug #1253974 for the glamor-egl crash, it may need further debugging / backtracing on the machine directly
<ubot5> bug 1253974 in glamor-egl (Ubuntu) "glamor-egl 0.5.1-0ubuntu6 crashes when running autopilot tests" [Undecided,New] https://launchpad.net/bugs/1253974
<fginther> Mirv, do we still have a problem with building autopilot-gtk to fix?
<Mirv> fginther: yes, check that with didier
<Mirv> (https://code.launchpad.net/~mathieu-tl/autopilot-gtk/source-format/+merge/196190 build with bzr bd and would build in daily-build, but not in merger)
<fginther> Mirv, thanks
<didrocks> fginther: we can hangout if you don't mind
<didrocks> working on that + the little "rest" :)
<fginther> didrocks, ack, I'll set it up
<Mirv> josepht, vila: for radeon, if it seems that there's nothing that can be done at the moment about the constant autopilot crashes, apply http://pastebin.ubuntu.com/6458715/ to cu2d-config and deploy all stacks (when they're stopped)
<cyphermox> didrocks: I think we're good to re-enable the build_all jobs, yo
<josepht> Mirv: ack
<didrocks> cyphermox: there is the radeon issue ^
<cyphermox> radeon issue...
<vila> Mirv: huh ? Why not a regular MP ?
<vila> Mirv: 'long annoying detail of the next job breaking after abort' as in this problem has been know  ? Since when ?
<didrocks> cyphermox: btw, thinking about it
<didrocks> we need rather version 1
<didrocks> think about that case:
<didrocks> I'm upstream
<didrocks> I add a patch
<didrocks> I want to build the package
<didrocks> bzr bd -> fail
<cyphermox> why>
<didrocks> because of the older orig.tar.gz
<didrocks> and so inline patches for dpkg
<cyphermox> *I'm not sure I follow, it should still work
<cyphermox> but hey, I don't care what version it is in the end ;)
<didrocks> cyphermox: you can try yourself
<didrocks> bzr branch your autopilot-gtk branch
<didrocks> bzr bd -S
<didrocks> then add a fix in the code
<didrocks> retry bzr bd -S
<didrocks> -> it will fail
<cyphermox> well yeah but cu2d bumps the versions
<didrocks> right, but I'm speaking about upstream testing their package
<cyphermox> it's not an issue
<didrocks> and so, it's an issue
<didrocks> they will have to bump themselves to test
<cyphermox> heh
<didrocks> something that they don't know/just making it harder :p
<didrocks> that's why I picked v1
<cyphermox> alright
<didrocks> everytime I have to think back btw why I forced v1
<didrocks> I should write that down somewhere
<fginther> didrocks, still failed: http://s-jenkins.ubuntu-ci:8080/job/autopilot-gtk-trusty-amd64-ci/8/console
<didrocks> fginther: the recipe doesn't use bzr bd it seems
<didrocks> fginther: not sure how you can force it to use it
<didrocks> I don't konw recipes ;)
<fginther> didrocks, perhaps it's time to stop using recipes...
<didrocks> fginther: I do agree ;)
<didrocks> so, let's force v1 for now, you won't need that patch normally
<didrocks> cyphermox: please oh please ^
<cyphermox> what do you mean recipes don't use bzr bd?
<cyphermox> fginther: using bzr builder for the ci stuff?
<didrocks> cyphermox: upstream merger are using recipes
<didrocks> and if you force version to be like <something>-0ubuntu1
<didrocks> is seems recipes are ignoring the "split" mode
<didrocks> and don't create the tarball automatically
<cyphermox> hmm
<cyphermox> I'm pretty sure that's configurable :)
<fginther> cyphermox, http://paste.ubuntu.com/6458847/
<jibel> vila, can I use your test job and the machine associated with it?
<didrocks> cyphermox: well, we need to fallback to v1 anyway for upstream, but if you want to figure that one outâ¦
<vila> jibel: you should, check with Mirv for no running stacks and josepht as vanguard
<dobey> didrocks, lool: i need to fix some dependencies in a -dev package for ubuntuone-credentials, do i need a landing ask for that? the -dev isn't on the image, but other binaries from the source are of course.
<didrocks> dobey: if that's the only change, it's fine (and you ensure what builds against this -dev can still build)
<cyphermox> didrocks: https://code.launchpad.net/~mathieu-tl/autopilot-gtk/source-format/+merge/196297
<didrocks> cyphermox: ok, let's wait for the CI machinery to give feedback. fginther ^
<dobey> didrocks: yeah, they should still build. it's just removing libsecret-1-dev (which we don't use any more anyway), and adding the correct -dev depends for libsignon/libaccounts/qtbase5
<didrocks> dobey: go ahead then ;)
<fginther> cyphermox, didrocks, it's building http://s-jenkins.ubuntu-ci:8080/job/autopilot-gtk-trusty-amd64-ci/9/console
<dobey> didrocks: am doing :)
<josepht> Mirv: is qa-radeon-7750 free for me to do some job testing one?
<josepht> *on
<cwayne> hey guys, any chance to get ubuntu-keyboard landed in an image today?  it's int he landing asks now
<cwayne> asac, ^
<didrocks> kenvandine: robru: hey! meeting :)
<kenvandine> didrocks, 2m, just got out of another meeting
* josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: https://wiki.canonical.com/UbuntuEngineering/CI/1ss-move-current-issues
<plars> Saviq: around?
<robru> didrocks, hummm, it's not on my calendar!
<didrocks> robru: can you grab it from mine?
<didrocks> (all occurences)
<robru> didrocks, i'm not sure how to find your calendar
<didrocks> robru: you were invited
<didrocks> robru: you told "no"
<robru> didrocks, strange. i thought you cancelled today's meeting. i see them pick up again next week
<didrocks> robru: only the 3 days of vUDS as told during the hangouts
<didrocks> ;)
<didrocks> robru: anyway, kenvandine has the details
<robru> didrocks, ok
<didrocks> and there are the spreadsheets :)
<kenvandine> robru, can you build the keyboard?  (if it hasn't since the fix was merged)
<robru> kenvandine, sure
<didrocks> omg robru builds A keyboard!
<kenvandine> i haven't looked yet, catching up my notes from 3 hours of meetings
<robru> kenvandine, ppa has latest commit to lp:ubuntu-keyboard. unless there's an MP that's about to land i don't think it needs a build.
<didrocks> robru: we don't care of latest of latest, you can go ahead :)
<robru> didrocks, go ahead and test? ok
<didrocks> yep ;)
<plars> kgunn: do you have someone who can look at the unity crashes we're seeing?
<kgunn> plars: i'm pretty sure Saviq is looking already (altho...are we talking about the same crashes ?:)
<kgunn> bug ?
<plars> kgunn: not sure there is one yet, but just about every ap test seems to be getting a .crash file in the image tests
<Saviq> plars, if you can get me the .crash file (assuming it's not truncated), I can see if it's one that's on our radar
<Saviq> plars, I believe you're seeing one on shutdown (as the tests pass, AFAICS?)
<Saviq> plars, some of them will be gone with Qt 5.2 that's coming up soon
<plars> Saviq: shouldn't be truncated, here's one: https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-unity8-autopilot/39/artifact/clientlogs/_usr_bin_unity8.32011.crash/*view*/
<Saviq> that's a recent image?
<plars> Saviq: yes
<plars> Saviq: and yes, the test pass rate doesn't seem to be affected by it
<Saviq> plars, ok, trying to retrace
<Kaleo> hi
<Kaleo> approved MRs don't seem to be landing: https://code.launchpad.net/ubuntu-ui-toolkit/+activereviews
<cjohnston> Kaleo: a specific exampleplease?
<cjohnston> nm.. found one
<dobey> doh. just missed didrocks i guess
<cjohnston> Kaleo: there are a bunch of jobs pending
<cjohnston> looks like waiting on hardware to be available
<Kaleo> cjohnston, is it going to be resolved with time?
<cjohnston> Kaleo: should
<Kaleo> cjohnston, thank you
<cjohnston> np
<Saviq> plars, unfortunately this doesn't retrace at all :/
<plars> Saviq: :(
<Saviq> plars, i.e. https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1253666
<ubot5> Ubuntu bug 1253666 in unity8 (Ubuntu) "unity8 crashed with SIGSEGV" [Undecided,Invalid]
<Saviq> plars, so, this is something that happens on the android side I'm afraid
<Saviq> plars, and gonna be pretty tricky to hunt down
<plars> ogra_: do you know if something changed on the android side in the past few days that could affect unity8? I don't know how much insight we have into those changes
<ogra_> plars, well, android is a package ... it usually has changelog entries and all on the trusty-changes ML or on launchpad etc
<ogra_> plars, but to my knowledge the changes were either completely emulator related or packaging changes over the last days
<plars> ogra_: Saviq was thinking the new unity8 crashes we're seeing could be related to some change in android
<ogra_> there were none that could affect the image ... all emulator or packaging stuff
<xnox> well if it fails to retrace it's hard to tell, is it actually the unity8 from the archive or custom compiled elsewhere?
<fginther> cyphermox, does this describe the issue you found trying to update autopilot-gtk: https://bugs.launchpad.net/pbuilderjenkins/+bug/1254162 ?
<ubot5> Ubuntu bug 1254162 in PBuilderJenkins "Support debian/source/format of "3.0 (quilt)"" [Undecided,New]
<cjohnston> Kaleo: looks like its down to two jobs in the queue
<Kaleo> cjohnston, thanks!
<Kaleo> cjohnston, 4 actually :)
<cjohnston> Kaleo: ? I only see two in jenkins
<Kaleo> cjohnston, https://code.launchpad.net/ubuntu-ui-toolkit/+activereviews
<cjohnston> https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/fix1244615-autopilot_qtc/+merge/192713 hasnt been approved   nor has https://code.launchpad.net/~fboucault/ubuntu-ui-toolkit/icon_api_sanitization/+merge/194253
<Kaleo> cjohnston, they have been top approved
<cjohnston> they have to be 'comment' approved as well AFAIK
<Kaleo> cjohnston, never been a requirement
<Kaleo> cjohnston, unless it's changed
<cyphermox> fginther: I couldn't put it better ;)
<fginther> cyphermox, thanks
#ubuntu-ci-eng 2013-11-23
<cyphermox> cihelp  looks to me like daily-release-executor is offline again, for q-jenkins.
<fginther> cyphermox, backup
<fginther> cyphermox, back up
#ubuntu-ci-eng 2013-11-24
<infinity> So, who wants to test a new eglibc on a touch device for me?
<infinity> ogra_: I know you want to. :)
<ogra_> infinity, but most likely not today anymore
<ogra_> (happy to do it tomorrow morning)
<infinity> :)
<xnox> infinity: where is it available from?
 * xnox is happy to run rdeps auto-pkg-tests
<xnox> toolchain-r/ppa?
<infinity> xnox: toolchain-r/test
#ubuntu-ci-eng 2014-11-17
<imgbot> === trainguards: IMAGE 23 building (started: 20141117 02:05) ===
<imgbot> === trainguards: IMAGE 23 DONE (finished: 20141117 03:25) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/23.changes ===
<robru> Mirv: good god qtbase takes forever to build. remind me never to use that for testing citrain changes ever again ;-)
<Mirv> robru: it might be just the worst possible choice, yes :)
<Mirv> robru: oxide-qt might be slightly worse still, try that next time ;)
<Mirv> robru: armhf build of qtbase will take around 4.5 hours
<robru> Mirv: oh god
<robru> ok, cancelling ;-)
<Mirv> excellent choice!
<robru> Mirv: so I didn't deploy anything to production yet, but when my shift starts monday morning I'm gonna deploy a ton of fun new stuff ;-
<robru> ;-)
<Mirv> robru: exciting times! ;)
<sil2100> o/
<sil2100> ogra_: hey! The landing gates are still closed?
<Mirv> sil2100: o/
<Mirv> sil2100: yes
<sil2100> Mirv: o/
<Mirv> sil2100: just catch up with emails, no hurry :)
<Mirv> the gates are even tighter closed now!
 * sil2100 is worried about this e-mail catch-up
<sil2100> Need to wait for all the filters to do their magic
<Mirv> sil2100: well you know, once you catch up with the most important lists, you've the big picture anyhow
<Mirv> well that too
<Mirv> sil2100: refreshed?
<Mirv> sil2100: ogra_ can offer you some landing tea he started brewing last week
<sil2100> Mirv: a little bit, yes :) Although I just recently understood that 2-months of vacation when one was a student was the perfect length for holidays!
<Mirv> sil2100: yes, exactly :) although most of those I spent doing summer work to have some experience + money.. so it never quite works "optimally" :)
<Mirv> there was this one summer though, no work, just play, 3-4 months... phew
<sil2100> Mirv, robru: any news of the spreadsheet replacement?
<Mirv> I haven't heard. robru keeps on cleaning CI Train code though (next big deployment when he wakes up in 9h)
<sil2100> Thunderbird is slow with it's filters, for now it's 3k of unfiltered e-mail
 * popey hands sil2100  some procmail rules
<popey> welcome back
<sil2100> popey: o/
<tvoss> o/
<Mirv> tvoss: o/
<sil2100> The filters still didn't do their job, but I see news of a second image promotion last week
<sil2100> Good job everyone!
<sil2100> ogra_: so the MilestoneSchedule has been +1'ed by olli and the product team?
<sil2100> That would be great
<ogra_> sil2100, well, we are running by it  ... not sure it needs additional +1 ing :)
<sil2100> As long as people were properly informed, I guess it's ok - and we're anyway concentrating on a limited list of top-blockers anyway
<sil2100> -anyway
<ogra_> right, 3 or 4 this week, the remaining of the 6 next week
<brendand> ogra_, sil2100 - i'm off today btw, so won't attend the landing meeting
<sil2100> Actually I see this plan got a +1 from Pat so that's all I wanted ;)
<sil2100> brendand: ok! Do you know who will be available from QA today for EU? Since Dave is on holidays too, right?
<ogra_> brendand, yeah, i know
<ogra_> sil2100, jibel takes over
<brendand> sil2100, not a lot of people :)
<brendand> sil2100, jibel, vrruiz
<sil2100> brendand, ogra_: thanks ;)
<brendand> sil2100, om26er later
<sil2100> Well, we only target topblockers, so I suppose there won't be too many silos
<ogra_> right
<ogra_> and we are only letting 4 of them in anyway
<ogra_> (and the fs corruption one will actually be a *lot* of fun to test :P (not sure how to test it at all))
<sil2100> ogra_: but does it have a fix already?
<sil2100> I didn't see any merges associated with it, but on the other hand not sure if it has any bzr-controllable projects related
<ogra_> sil2100, most of the bits are in place, it is in android (recovery), initramfs-tools ... and adbd
<ogra_> as i said, fun to test :)
<jibel> sil2100, and rhuddie
<rhuddie> jibel, hey. just catching up on what
<rhuddie> I am doing this week :)
<Mirv> sil2100: meeting :)
<Mirv> sil2100: there you are..
<Mirv> jibel: rhuddie does either of you want to join follow https://plus.google.com/hangouts/_/canonical.com/landing-meeting ?
<jibel> Mirv, joining
<Mirv> excellent. ogra_ is currently just summing up latest things to sil2100
<sil2100> ogra_, Mirv: btw. do you guys know if all the CPU-hogger bugs have been fixed? i.e. the location-service spinning 100% CPU etc.?
<Mirv>  sil2100: in theory yes, unless something yet uncovered lurks somewhere
<sil2100> tvoss: ping!
<tvoss> sil2100, hey there
<tvoss> sil2100, for the cpu hogging: we still haven't identified the root cause for dbus-daemon spinning.
<sil2100> tvoss: ok, so this one thing still remains - but it's not happening too frequently, right?
<sil2100> tvoss: since I don't see it as a topblocker right now
<tvoss> sil2100, nope, that's part of the problem in tracking it down :)
<sil2100> tvoss: ok, thanks o/
<tvoss> sil2100, o/
<seb128> speaking of cpu hogging, I had a few weird issues this w.e on the phone (running current rtm image)
<seb128> like it wouldn't turn out of suspend
<seb128> I hammered a bit the power button and got the reboot dialog but the buttons were not reacting to click
<seb128> and the screen would turn off again after like 10 seconds
<seb128> it sort of acted like it was busy and slooow to react to action
<seb128> waiting some 30 seconds I managed to get the unlock/reboot
<seb128> did that like 2 or 3 time over the w.e, first time I've such issues
<seb128> did anyone experience/report issues like that before?
<Mirv> jibel: so, it'd be useful to start testing networking in general for bug #1357321 using the rtm-022 silo that fixes 3G usage for at least scopes image loading.
<ubot5> bug 1357321 in qtbase-opensource-src (Ubuntu) "[TOPBLOCKER] QNetworkAccessManager doesn't support roaming on Ubuntu" [Critical,In progress] https://launchpad.net/bugs/1357321
<Mirv> jibel: I've just added a new section "Testing networking code in Qt Base" to the test plan, summarizing some of the tips discussed in the bug report
<Mirv> I should have a new build also by EOD, since Lorn was still awake pushing fixes and they may again fix remaining unit tests issues
<Mirv> and if not all unit tests are fixed, I'll disable them again and build a newer to-be-tested build
<Mirv> I had forgotten I already had a test silo from last week, I don't need three silos..
<jibel> Mirv, rvr will start testing silo 22.
<ogra_> seb128, well, you might have hit exactly the bug sil2100 was mentioning
<ogra_> there is another one where the UI stops taking input completely
<Mirv> jibel: rvr: ok. I just pushed the next build and explaining in the bug report.
<Mirv> cihelp jenkins is trying to erronously fetch upstream sources with wrong url. it should first check whether the sources are available in the archives like they now already are https://code.launchpad.net/~bzoltan/kubuntu-packaging/qt5-qmake-cross-armhf/+merge/241568
<Mirv> and the url is wrong because the orig tarball has dfsg changes
<Mirv> note that the Qt jenkins runs are mostly done to get code coverage numbers from what I've understood, since all the unit tests are run at the build time anyway
<bzoltan> Mirv:  geez, what is that ^
<Mirv> bzoltan: you being too hasty :) I was going to run the watch_only build at the right moment. you're not supposed to run "real" build over there.
<bzoltan> Mirv:  ahh... I am sorry dude
<Mirv> bzoltan: no problem. CI Train does the correct thing now even with you commanding it to build it "normally" - it actually just watches it, and now it's watchable as it's Published instead of Pending
<sil2100> Phew, almost up-to-date with e-mail
<sil2100> Time for lunch o/
<rvr> Mirv: Hi. I'm trying to reproduce "video scope fails when using only 3G" without installing silo packages: only 3G connection activated, cache directory deleted, go to video scope and pull to refresh. Result: it loads the images.
<Mirv> rvr: hmm, maybe that is not completely enough to see the problem. can you try rebooting with wifi disabled while I try to reproduce the problem again?
<rvr> Mirv: I rebooted the phone with wifi disabled, and removed the cache before rebooting and after too.
<ogra_> oh, damn
 * ogra_ forgot to start an image build ... 
<ogra_> let me do that now then :P
<imgbot> === trainguards: RTM IMAGE 162 building (started: 20141117 12:50) ===
<Mirv> rvr: I did not initially manage to reproduce the problem after downgrading, but now again I managed. the test case needs more exact steps and I'm not sure yet of the steps.
<Mirv> rvr: try 1. boot with 3g + wifi enabled, 2. disable wifi 3. rm -rf .cache/unity8-dash 4. go to video scope and refresh
<rvr> Mirv: Checking
<Mirv> I'd really like know something _else_ than the scopes that misbehave. messing with the scopes' cache and updating them seems always a bit hit and miss
<Mirv> updated the test plan, it seemed I could reproduct this procedure and then see it fixed after updating.
<rvr> I could reproduce it once
<rvr> Problem that I have is data connection seems to be flaky here
<Mirv> rvr: flaky scopes + flaky data connection makes for hard testing :)
<rvr> Meh, the images load almost all the times
<Saviq> trainguards â please :)
<Mirv> Saviq: done.
<Saviq> Mirv, thank you
<rvr> Mirv: I tested in another room with better data connection, and haven't been able to reproduce the problem :(
<rvr> Mirv: I'll begin testing the silo, anyway
<imgbot> === trainguards: RTM IMAGE 162 DONE (finished: 20141117 14:05) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/162.changes ===
<jibel> silo 3 contains also a fix for bug 1389767. I thought it was clearly said only topblockers? did some one accepted this fix?
<ubot5> bug 1389767 in ubuntu-system-settings (Ubuntu RTM) "Differentiate titles from normal text" [Medium,In progress] https://launchpad.net/bugs/1389767
<seb128> jibel, pat said it was ok to land the other day iirc
<Mirv> rvr: ok :( note vrtm~4 will be there to update to now in around 1h
<seb128> jibel, http://irclogs.ubuntu.com/2014/11/12/%23ubuntu-touch.html#t15:44
<Mirv> om26er: do you have any tips to rvr on how to best reproduce the original problem in bug #1357321?
<ubot5> bug 1357321 in qtbase-opensource-src (Ubuntu) "[TOPBLOCKER] QNetworkAccessManager doesn't support roaming on Ubuntu" [Critical,In progress] https://launchpad.net/bugs/1357321
<rvr> Mirv: So, do silo packages will be updated soon? Then better to wait to test those, right?
<ogra_> jibel, nothing but the provided list lands ... but things should go into silos and be signed off
<jibel> ogra_, it's in the same silo than topblocker bug 1336715. So we either land both or none
<ubot5> bug 1336715 in ubuntu-system-settings (Ubuntu RTM) "[TOPBLOCKER] switch-items in indicators sometimes get out of sync with system-settings" [Critical,In progress] https://launchpad.net/bugs/1336715
<ogra_> none then ... it needs to be split in two
<plars> did something ugly happen with the mako image recently? all our makos in the lab are unresponsive right now, and even having trouble coming back with the relays
<jibel> seb128, ^^
<ogra_> plars, we noticed that in todays landing meeting ...
<ogra_> psivaa, wanted to inspect that ... but if he didnt tell you anything i guess he didnt find anything either
<seb128> jibel, ogra_, shrugh, I've nothing to do with that, Pat said it was ok to land if it's not talk to him not me
<ogra_> theoretically there should be nothing wrong with the images
<seb128> or land none
<ogra_> seb128, not pats decision (nor mine)
<seb128> ogra_, not mine either
<ogra_> i'm just the messenger
<seb128> why is Pat saying ok to things if he's not allowed to?
<seb128> anyway, politics
<seb128> as far as I'm concerned feel free to not land any of the fixes or do whatever suits the rules-of-the-day best
<ogra_> i'll bring it up at the bug review meeting
<psivaa> ogra_: plars: image 23 was not flashed on the devices that are being offline. and image 22 was fine. i dont *think we have any issue with the images
<plars> psivaa: I'm almost wondering if something that drained the power completely
<seb128> kenvandine, hey
<seb128> kenvandine, seems like you need to redo silo 3 without the title fix, jibel and ogra_ don't like having 2 bugs fixed in one landing
<ogra_> lol
<kenvandine> bummer... pat told me to include it
<kenvandine> i can remove it
<ogra_> not my choice, really
<jibel> seb128, it is not a matter of me liking or not liking. The rule is only topblockers
<ogra_> kenvandine, when did he tell you ...
<seb128> jibel, why is Pat approving things then?.
<kenvandine> jibel, last tuesday
<ogra_> the plans of all of us were changed friday late afternoon
<kenvandine> it's been tehre a week
<kenvandine> there
<jibel> seb128, I don't know. I don't see any comment from him on the bug report, his only action is to downgreade the priority from critical to medium
<kenvandine> he said to go ahead and land that too
<ogra_> lets wait for pat  and olli and see what we can do here ... before you invest huge amounts of work into splitting that
<kenvandine> jibel, it was on the wish list for rtm and they approved it
<kenvandine> he told me to go ahead and land it too
<seb128> jibel, shrug, I pointed the IRC log, no it was not on the bug comment
<seb128> jibel, http://irclogs.ubuntu.com/2014/11/12/%23ubuntu-touch.html#t15:44 in case you didn't see it before
<kenvandine> jibel, someone from QA verified it with pat as well
<ogra_> the rules changed :/
<sil2100> ogra_, seb128: well, I just know that Pat mentioned in his e-mail that we only can land topblocker fixes
<sil2100> kenvandine: when did that happen?
<kenvandine> sil2100, ogra_: yeah, this was expected to land before the last image
<kenvandine> sil2100, that was tuesday i think
<seb128> wednesday
<sil2100> Ok, then we need to split it out... there were some top-management decisions made
<kenvandine> it just took ages for qa verification
<kenvandine> yeah
<jibel> seb128, I saw the link. But I think you all received the list of 7 bugs to accept this week too
<popey> bfiller: I flash my phone clean last week and added google accounts to it, I'm seeing no contacts synced in the contacts all at all...
<popey> bfiller: i have the tickbox ticked in my google accounts
<seb128> jibel, I'm unsure what do think when top managers give different instructions via IRC and emails, but whatever
<ogra_> kenvandine, seb128, we'll have a bug review meeting later today with pat and olli, lets see what they say ... worst case you need to unbundle it tomorrow ...
<kenvandine> jibel, this was meant to land in last thursdays image
<bfiller> popey: are you on wifi?
<jibel> kenvandine, and it missed the window. as other apps / fixes did. This is something to discuss with the management. If they tell us to accept this fix, I'm happy to continue with silo 3 as it is now.
<popey> bfiller: yes
<popey> bfiller: want me to file a bug and get logs?
<bfiller> popey: yeah, specifically .cache/upstart/sync-monitor.log
<kenvandine> jibel, lets see what it says
<bfiller> renatu: ^^^^
<ogra_> jibel, right, we need input from olli and pat here
<popey> bfiller: what do you want the bug filed against?
<bfiller> popey: were you prompted when you started address-book app to create a google account?
<bfiller> popey: sync-monitor
<popey> bfiller: i think i had already setup my google account before I opened address-book
<renatu> popey, does the sync button appear on the address-book-app header?
<popey> renatu: http://popey.mooo.com/screenshots/device-2014-11-17-143151.png that button next to search?
<renatu> popey, yes, whats happen if you hit it?
<renatu> popey, please send me you sync-monitor log file
<popey> it greys out
<Mirv> rvr: yes, maybe better at this point to wait. I
<renatu> syncing
<popey> do you want all of the zipped ones renatu
<popey> because the latest one is pretty short
<renatu> could you paste the last one
<popey> http://paste.ubuntu.com/9057008/
<Mirv> rvr: 'd estimate the armhf packages would be published to the PPA archive in around 40mins or so. but indeed the packages still aren't final since we're waiting/hoping for more unit test fixes, but it'd be good to start getting idea that at least there wouldn't be regressions.
<renatu> popey, yes this looks ok, you should get your contacts now
<renatu> popey, yeah I will need to old ones
<popey> i hit refresh 30 mins ago
<popey> hah, now they appear!
 * popey suspects renatu has root on my phone
<renatu> :D
<popey> do you still need the logs? seems to be okay now I pressed the damm button
<renatu> popey, yes please report a bug, we need to investigate why this does not sync when you create the account
<renatu> popey, btw did you create the account after flashing it?
<renatu> popey, or the account was already there
<popey> renatu: it was a --wipe flash, so there were no accounts, I had to create them
<rvr> Mirv: I cannot reproduce the bug with current silo, either ;)
<renatu> popey, did you created the account on wifi or 3g?
<Mirv> rvr: so, you agree that the PPA may definitely do something. great! :)
<popey> probably wifi, i rarely leave the house â»
<rvr> Mirv: As I haven't been able to reproduce it without the silo, right now I agree that the PPA at least doesn't break that :PP
<renatu> popey, ok I will need to investigate it to understand whats happen, please report a bug and if possible send me your log files
<popey> renatu: https://bugs.launchpad.net/ubuntu/+source/sync-monitor/+bug/1393433 has the full log attached
<ubot5> Launchpad bug 1393433 in sync-monitor (Ubuntu) "Sync-monitor didn't sync contacts" [Undecided,New]
<renatu> popey, thanks
<kgunn> Mirv: sil2100 so what is the current thinking, that we are going to have QA test the Qnam patchset and potentially land ? or no landing until we fix the unit tests ?
<popey> np
<ogra_> sil2100, FYI https://code.launchpad.net/~canonical-platform-qa/camera-app/fix-ap-tests/+merge/241965
<Mirv> rvr: yeah. if you read the bug origins, you'll notice that people haven't ever had a very specific test case other than "unoptimal behavior". then the first fix proposals broke more things and there were messaging about that, and now the latest fixes bring it back to that now the original problem would be testable, as soon as a proper test ase would be there.
<sil2100> kgunn: so, currently we asked QA to start the testing now, but I would prefer not to land it before the unit tests are fixed - but if we don't make it in time, I would let it pass through the gates anyway
<Mirv> kgunn: well first of all we'd need a good test case that actually shows the problem. rvr for example has problems reproducing the original problem, partially because the scopes themelves are flaky.
<kgunn> ok, sil2100 i agree, i would rather withhold landing until the unit tests pass...seems there are so many in qt, does anyone really know if it's even safe to
<kgunn> let it pass at all?
<rvr> Mirv: Ack
<kgunn> (e.g. if we run out of time)
<sil2100> kgunn: all seems to work ok from the user POV and from what Mirv mentioned the unit tests didn't really test much before in the past because things were anyway b0rken, so it's not such a big deal... but the very thought of releasing something with disabled unit tests sounds a bit juvenile
<kgunn> right
<kgunn> did anyone double check what lorn said about them passing locally ?
<Mirv> kgunn: sil2100: even with unit tests passing, we'd need a better test case for the problem. I've done my best at https://wiki.ubuntu.com/Process/Merges/TestPlans/Qt#Testing_networking_code_in_Qt_Base but rvr still doesn't succeed in reliably reproducing the actual problem without the PPA so he could validate the PPA fixes the issue
<kgunn> Mirv: sil2100 i know om26er was able to repro quite easily
<kgunn> as he was kind enough to test maybe the 2nd or 3rd ppa we had
<kgunn> ...again, did anyone build/run unit tests locally ? i see lorn said they were passing on his phone
<Mirv> kgunn: note that there was intermediate problem with the earlier version of the fix, and on the bug report he mostly reports he was reliably able to reproduce the regression in the earlier fix, not that he could reliably reproduce the originally reported bug.
<om26er> sil2100, yes, I faced the disconnect issue
<Mirv> om26er: ^ the disconnect issue was the regression, not the original problem
<rvr> om26er: Do you remember the steps required to reproduce the problem?
<kgunn> Mirv: ah, i see...right...regression vs original roaming issue
<om26er> Mirv, yes and the original bug where I don't have thumbnails in remote scopes over 3G
<om26er> I have seen that forever.
<Mirv> kgunn: no I haven't tried locally, I guess it'd need a full build on a phone. it's understandable though, since the remaining unit test failures are likely because network-manager is tried to be used from Qt while builders don't have network-manager installed. earlier there was the generic plugin in use by unit test that didn't interact with network manager.
<rvr> om26er: I'm not able to reproduce it with the test case in the wiki
<Mirv> om26er: can you then guide rvr better to reproduce the original problem, and maybe update the test case https://wiki.ubuntu.com/Process/Merges/TestPlans/Qt#Testing_networking_code_in_Qt_Base to be something that is really step-by-step?
<kgunn> om26er: or...even test the latest ppa :) associated with solving that bug
<kgunn> https://bugs.launchpad.net/indicator-network/+bug/1336715
<ubot5> Launchpad bug 1336715 in ubuntu-system-settings (Ubuntu RTM) "[TOPBLOCKER] switch-items in indicators sometimes get out of sync with system-settings" [Critical,In progress]
<kgunn> oops not that one
 * Mirv launches one build in the experimental PPA with network-manager in build dependencies... that might get better unit test results
<ogra_> we want that fixed too though :)
<kgunn> https://bugs.launchpad.net/savilerow/+bug/1357321
<ubot5> Launchpad bug 1357321 in qtbase-opensource-src (Ubuntu) "[TOPBLOCKER] QNetworkAccessManager doesn't support roaming on Ubuntu" [Critical,In progress]
<kgunn> Mirv: ta
<rvr> Mirv, kgunn: om26er is not able to reproduce the bug anymore in 161
<ogra_> heh
<sil2100> ;/
<om26er> could be the network status fix, fixed this issue as well.
<Saviq> sil2100, hmm, no descriptions in citrain dashboard?
<sil2100> Saviq: uh oh!
<om26er> citrain says: /usr/bin/citrain: 45: .: Can't open /usr/share/phabletutils/shell-adb-common.sh
<om26er> help ?
<sil2100> SOmething must have broken it
<Saviq> om26er, apt-cache policy phablet-tools
<Saviq> ?
<ogra_> looks a lot cleaner at least :P
<om26er> Saviq, not installed
<Saviq> om26er, sounds like phablet-tools-citrain's missing a runtime dep on phablet-tools
<ogra_> file a bug please
 * Saviq clicked /usr/share/... from om26er... firefox landed me in http://www.usr.com/share/phabletutils/shell-adb-common.sh
<Saviq> WTF
<sil2100> Saviq: checking if your big description b0rk it (just in case)
<Saviq> BIG? that's a big description?
<sil2100> But it still seems missing...
 * sil2100 investigates
<sil2100> Damn, there's a lot of errors on this page, but not sure if those aren't some old ones
<Mirv> rvr: om26er: :/ which network status fix?
<om26er> Mirv, bug 1386109 but I might be wrong, its a guess.
<ubot5> bug 1386109 in network-manager (Ubuntu RTM) "[TOPBLOCKER] com.ubuntu.connectivity1.NetworkingStatus.Status is always online" [Critical,Fix released] https://launchpad.net/bugs/1386109
<rvr> Mirv: What do you think?
<Mirv> rvr: I don't know. I jumped in only when there was a supposed fix, and then battled with getting the regression going away. I thought from the start that the scopes are a bit hard way to reproducing the original problem, and again today thought that I was able to see the problem (with the now updated test case in the wiki) - I rebooted twice with the old version, with wifi on, did the test and it failed. then updated to the PPA and it didn't fail 
<jhodapp> sil2100, can you please reconfigure vivid silo 1
<sil2100> jhodapp: sure, what changed?
<jhodapp> sil2100, added the qtubuntu-media MR to it
<jhodapp> sil2100, but go ahead and rebuild everything
<Mirv> rvr: I'll let QA decide what to do with the original bug an supposed fix, while I try concentrate on getting the unit tests situation clear for the possibility of landing the new network manager backend that actually works unlike the current one.
<Mirv> if nothing else, Qt 5.4 will have super improved network manager bearer backend thanks to Lorn's work :)
<sil2100> jhodapp: reconfigured
<jhodapp> sil2100, thanks
<Mirv> mzanetti: if there's a possibility the current 3G connection scopes problem is somehow gone/workarounded already, can you give kgunn/om26er/rvr some sort of idea what _other_ problems we may be currently facing with the broken network manager bearer plugin that we're currently using, or can we just do without it?
<Mirv> s/without it/without the new fixed backend/
<Mirv> I never really understood how the problem lead to the images not loading but web otherwise working, so the bug description would enjoy more accurate wording too
<mzanetti> Mirv: I couldn't reproduce the roaming issue any more with your ppa
<mzanetti> Mirv: on details about other issues I'd have to redirect you to lpotter
<Mirv> mzanetti: the thing is that om26er and rvr now claim they can't reproduce it anymore without the PPA either
<rvr> mzanetti: And without the silo?
<mzanetti> need to test again to be sure
<rvr> mzanetti: om26er and me can't reproduce it in 161
<om26er> mzanetti, yes, I am not able to reproduce that issue today with 3G.
<Mirv> kgunn: om26er rvr: I finished one more build and updated https://bugs.launchpad.net/savilerow/+bug/1357321/comments/87 - feel free to find ways to help with a) test case, b) validating what om26er/rvr are seeing without the PPA, c) bug description about what was the original problem exactly and how it related to us needing the fixed Network Manager backend... phew..
<ubot5> Launchpad bug 1357321 in qtbase-opensource-src (Ubuntu) "[TOPBLOCKER] QNetworkAccessManager doesn't support roaming on Ubuntu" [Critical,In progress]
<ogra_> Mirv, with or without silo ... we are sure the fix is the right thing to do in general ... no ?
<Mirv> ogra_: well I guess a working NM backend in Qt sounds good, so that Qt's network status information would reflect what's actually happening in network manager. so in general yes it's the correct thing to fix, but I don't know what are the problems we're actually facing with staying with the current broken backend, if even this problem is gone.
<sil2100> Saviq: the dashboard is acting strange, it seems to have problems fetching info from the SS
<ogra_> Mirv, right
<pmcgowan> ogra_, I thought we decided to land silo 3 as it was to avoid make work
<ogra_> pmcgowan, well, i dont know what was decided after the bug meeting on friday
<pmcgowan> we discussed here in the channel with brendan
<ogra_> all i know is that it was decided that nothing but topblockers can land from now on
<ogra_> if we are fine with the bundled silo (which IMHO we should) that needs to be said so :)
<pmcgowan> that silo was already tested and just missed the previous deadline
<pmcgowan> I am fine to land it
<ogra_> me too
<ogra_> olli, ?
<pmcgowan> he also +1 on fri
<ogra_> land it then :)
<kenvandine> we need QA to mark it as verified :)
<ogra_> sil2100, silo3 can go in once verified
<ogra_> seb128, ^^
<rvr> rhuddie stopped testing silo 3 until its status was clear
<kenvandine> rhuddie, ^^^
<pmcgowan> Mirv, if we cannot reproduce that qnetwork issue with the latest NM fixes, we should probably defer that landing
<ogra_> we shoulldnt throw it away though
<pmcgowan> indeed
<ogra_> since we are sure it is the right thing to do
<rvr> pmcgowan: ogra_: So do we block silo 22 for now?
<pmcgowan> rvr, I would if the symptoms no longer reproduce
<olli> yeah
<ogra_> rvr, well, unless om26er finds a way to repro the issue i guess we have to
 * olli waves goodbye
<om26er> ogra_, the issue is: the problem was never difficult to reproduce. The bug was just there, for example opening the Ubuntu Store would not show icons of the apps but today its working just fine.
<ogra_> right
<om26er> maybe lets ask victorp if its fixed for him as well ?
<ogra_> yeah
<rhuddie> rvr, kenvandine, jibel, yes. testing on silo 3 was stopped until we had a clear direction.
<rvr> rhuddie: Ok, we can test it now "safely" :)
<kenvandine> it was stopped for several times last week, never really knew why...
<kenvandine> rhuddie, rvr:  thanks
<pmcgowan> om26er, iit does seem to be working
<rhuddie> kenvandine, rvr, jibel, Ok, I'll start with silo3 again
<rhuddie> kenvandine, on silo 3 I am seeing incorrect sync on flight mode state between u-s-s and network indicator. This wasn't mentioned in http://pastebin.ubuntu.com/8967576/
<rhuddie> kenvandine, is this still expected?
<kenvandine> what do you mean by incorrect?
<kenvandine> it still looks a little wonky imo
<kenvandine> but the state stays consistent for me
<rhuddie> kenvandine, well, u-s-s says flight mode is enabled, but the indicator says it is disabled
<kenvandine> that stayed in sync for me when i tested it
<rhuddie> kenvandine, it started doing that after a couple of attempts of switching flight mode on/off and unlocking the sim
<kenvandine> i didn't do anything with unlocking the sim
<kenvandine> so maybe that triggered a problem in the indicator
<kenvandine> now i can't install from the silo!
<kenvandine> i flashed this morning, so lost the silo
<kenvandine> W: Failed to fetch http://ppa.launchpad.net/ci-train-ppa-service/landing-003/ubuntu-rtm/dists/devel/main/binary-armhf/Packages  403  Forbidden
<ogra_> i think there was a comment in the bug about the fliht mode switch
<ogra_> (and that it is speacial and slower)
<cwayne1> ogra_: btw spanish image should now be setup as gated
<kenvandine> ogra_, any idea why i'm getting 403 errors from the ppa?
 * ogra_ hugs cwayne1 
<ogra_> kenvandine, s/devel/14.09/
<kenvandine> oh, is the citrain tool broken?
<ogra_> kenvandine, LP drawback ... if you use the correct channel and add-apt-repo does the right thing and use the channel name ... LP cant resolve that to 14.09
<kenvandine> ah
<kenvandine> sigh
<kenvandine> i shouldn't have flashed :)
<ogra_> iirc cjwatson had opened a bug for that
<sil2100> ogra_, pmcgowan: ACK
<sil2100> Let me mention that in the landing
<sil2100> Although the dashboard seems to be a bit mean today
<kenvandine> rhuddie, i toggled it twice, each time it took at least 5 seconds but they stayed in sync
 * kenvandine tries a few more times
<rhuddie> kenvandine, hmm, it didn't take long for me to see the problem.
<kenvandine> rhuddie, i think the switch in the indicator is a little buggy
<kenvandine> it moves then moves back
<kenvandine> and moves again when the state really changes
<rhuddie> yeah I saw that too
<cjwatson> ogra_,kenvandine: it's not that it can't resolve it - it shouldn't need to
<kenvandine> i'm waiting long enough for the state to really change.. maybe if i rush it :)
<cjwatson> ogra_,kenvandine: the problem is that there's a wrong .htaccess somewhere on the server side that's incorrectly denying access
<cjwatson> and I keep forgetting to track that down at some point when the right people are around
<sil2100> robru: the dashboard seems to have now completely stopped showing silo descriptions
<kenvandine> rhuddie, ok, i reproduced that
<cjwatson> I didn't file a bug, though I did ask Ted to file one
<sil2100> robru: you have any idea what's up? I didn't have time to investigate that properly
<kenvandine> rhuddie, but the state is right and staying in sync with what's in settings
<kenvandine> the indicator isn't always staying in sync
<kenvandine> rhuddie,  but you're right, i didn't hit it until i changed it a few times
<kenvandine> i doubt that's a regression, the flight mode switch in indicator-network has been buggy
<kenvandine> rhuddie, it's worse without silo 3 :)
<kenvandine> so not a regression
<kenvandine> got out of sync on the first try for me without the silo
<rhuddie> kenvandine, yes. agreed. do we have a bug for the network indicator issue?
<kenvandine> rhuddie, not sure, there have been a number of bugs filed related to this
<kenvandine> rhuddie, i just tried it in vivid and i can't reproduce it in vivid
<kenvandine> so maybe indicator-network or urfkill has a fix in vivid that hasn't been backported yet?
<kenvandine> don't know
<rhuddie> kenvandine, could you update your testing notes http://pastebin.ubuntu.com/8967576/ to reference the issue?
<rhuddie> at least then it is logged with all the other issues
<kenvandine> i need to head out for an appointment, lets just reopen the indicato-network rtm task for bug 1336715
<ubot5> bug 1336715 in ubuntu-system-settings (Ubuntu RTM) "[TOPBLOCKER] switch-items in indicators sometimes get out of sync with system-settings" [Critical,In progress] https://launchpad.net/bugs/1336715
<kenvandine> or ask dednick to weigh in
<kenvandine> dednick, please read the scrollback there
<kenvandine> dednick, basically we can still get flight mode out of sync in indicator-network in rtm
<kenvandine> but it's only the indicator getting out of sync, settings is staying in sync with the actual state
<kenvandine> and i can't reproduce it in vivid
<kenvandine> dednick, so maybe indicator-network bug?  do you know if we already have a bug for that?
 * kenvandine heads out, bbiab
<rsalveti> cjwatson: hey, quick question for you, tried to update the android package, but got stuck in proposed with 'android-emulator/amd64 unsatisfiable Depends: ubuntu-emulator-images'
<rsalveti> cjwatson: android-emulator is 'all'
<rsalveti> and nothing changed from the previous upload I had
<rsalveti> ubuntu-emulator-images is indeed i386 only
<rsalveti> which explains the message, but why is that an issue now?
<rsalveti> android-emulator is an old transitional package, and can probably be removed if needed
<cjwatson> rsalveti: give me a few minutes to investigate
<rsalveti> cjwatson: sure, thanks
<cjwatson> it might have been forced in before
<cjwatson> rsalveti: oh, it would have worked before because architecture-all packages previously only had dependencies checked on i386; now they only have dependencies checked on amd64, to match the nominatedarchindep changes
<rsalveti> cjwatson: oh, right then
<rsalveti> should I just drop this package then for now? or is there anything else that can be done?
<cjwatson> rsalveti: I have told proposed-migration a suitable lie which should make this problem go away
<cjwatson> rsalveti: specifically http://bazaar.launchpad.net/~ubuntu-release/britney/britney1-ubuntu/revision/270
<rsalveti> oh, cool then
<rsalveti> cjwatson: got it, thanks so much
<cjwatson> no problem
<plars-sprint> ogra_: sil2100: at a sprint this week so I don't know if I'll easily be able to make it to hangouts, but I'll be around on irc mostly so if you need anything please ping me here. We have those makos in a better state now, so I'll have them back up and running jobs soon
<sil2100> plars-sprint: ok, so are all those devices up now?
<dednick> kenvandine: is this not related to the the battery using libnm directly maybe?
<dednick> kenvandine: it's possibly a indicator-network bug. i hanvent seen it out of sync with the wifi settings in uss.
<dednick> not since the uss updates anyway
<ogra_> popey, soooo ... you can land the music app ... but please well coordinated with QA and the smoke testing guys ;)
 * ogra_ just came out of a meeting :)
<popey> thanks!
<plars-sprint> sil2100: no, but they will be soon, it's mostly just mako and flo that were affected I think. Krillin seems ok
<om26er> jdstrand, Hi! regarding silo-002 is any anything using the newly added functionality ?
<jdstrand> om26er: no. the stuff to use it is for ota-1, but we want these changes now to avoid a policy recompile as part of ota-1
<plars-sprint> psivaa: sil2100: ogra_: to me, it looks like starting with image 132 on mako, it started being uninstallable
<bzoltan> sil2100: may i ask for quick silo? I could build a release candidate for the Chinese fellows for early morning tests
<plars-sprint> I think I just killed two more devices with the latest, so I'm trying vivid now
<plars-sprint> sil2100: wasn't 132 promoted also? that could explain why the latest stable image we flash is also broken
<ogra_> plars-sprint, the promoted image was definitely sanity tested on mako
<plars-sprint> ogra_: with --bootstrap?
<ogra_> plars-sprint, that you would have to ask davmor2 :)
<plars-sprint> ogra_: look at 132 in the ci runs, for 3 devices, none of them even booted
<plars-sprint> and 134 looks to have the same problem
 * ogra_ taps foot waiting for the dashboard 
<jdstrand> win 14
<jdstrand> meh
<ogra_> plars-sprint, well, no android changes and http://people.canonical.com/~ogra/touch-image-stats/rtm/160.changes (132) and http://people.canonical.com/~ogra/touch-image-stats/rtm/161.changes (133) ...
<ogra_> plars-sprint, i dont see how anything could have broken it
<plars-sprint> ogra_: if not, then we just had a LOT of devices simultaneously fail
<plars-sprint> ogra_: what about something that could have broken adbd?
<ogra_> nope
<plars-sprint> ogra_: the image is booting from the sounds of it, but we don't see it
<ogra_> notihing than the above changed last week
<ogra_> we were hard frozen from wed. early monring on
<plars-sprint> ogra_: I'm flashing vivid on one that just failed twice in a row with the latest rtm, so we'll see what happens
<ogra_> k
<ogra_> there is really nothing that could have broken it on the image side
<plars-sprint> ogra_: yep, confirmed... mako-14 just failed 2 times in a row, (more if you count the previous failures), but with vivid it works fine
<ogra_> well, not sure what to say
<ogra_> nothing in the image changed that could even remotely cause this
<plars-sprint> ogra_: well I know 132 failed, I know the stable image 8 fails, and I know the latest image 134 fails, but vivid works fine. So until it's sorted, we can either test on rtm and watch it kill all the makos, or we can turn that off
<ogra_> and i know that davmor2 definitely tested 133
<bzoltan> trainguards: could any of you help me out with a vivid silo what would release in 12 hours?
<ogra_> plars-sprint, did ubuntu-device-flash get updated on the server or some such ?
<plars-sprint> ogra_: not since early last week
<plars-sprint> well before this I believe
<ogra_> i see there was a landing for it in vivid on thu
<ogra_> but that should not even touch touch
<ogra_> (was for ubuntu-core)
<ogra_> but that would be my only explanation
<plars-sprint> well, on the 13th, but I would think there were tests between that and the one on friday that failed. iirc that one wasn't there early in the day when I looked
<robru> bzoltan: what kind of help do you need?
<bzoltan> robru: I could use a silo :)
<robru> bzoltan: sure, what spreadsheet row?
<bzoltan> robru:  56
<ogra_> well, it landed in vivid at Thu, 13 Nov 2014 19:10
<plars-sprint> davmor2: do you have a working mako at home you could try this with? (flashing latest rtm with --bootstrap)
<ogra_> plars-sprint, he is off this week
<plars-sprint> sadly, my mako has a busted battery
<plars-sprint> ah, someone else in qa then maybe?
<ogra_> (half of QA is)
<robru> bzoltan: ok you get to be my guinea pig for some changes I just landed in citrain production ;-) https://ci-train.ubuntu.com/job/ubuntu-landing-022-1-build/23/console building with DEBUG enabled!
<bzoltan> robru:  wow :) it is a privilege
<plars-sprint> sergiusens_: any chance this could be the same issue we saw with krillin last week and the latest ubuntu-device-flash?
 * ogra_ feeds bzoltan some carrots and seeds
 * bzoltan knows that in some cultures the guinea pig is considered as food
<robru> hehee
<ogra_> yup, we used to have peruvian colleagues :)
<bzoltan> but you are German, right? So I am safe..
<ogra_> haha, yeah
 * bzoltan lets the bratwursts to be scared
<sergiusens_> plars-sprint: which one, sorry, missing context
<rhuddie> kenvandine, I will be leaving shortly, but om26er will continue testing on silo 3
<plars-sprint> sergiusens_: on mako latest rtm images boot, but can't be seen from adb on mako and flo with the latest ubuntu-device-flash
<plars-sprint> sergiusens_: (with --bootstrap)
<bzoltan> ogra_:  where do I find the u-s-c logs?
<ogra_> bzoltan, i guess in some lightdm log ...
<ogra_> bzoltan, best to ask mterry, he knows that bpart of the system in and out
<sergiusens_> plars-sprint: hmmm, I didn't change anything... but, rsalveti did the e2fsck stuff get in? plars-sprint can we check it's not stuck on broken fs?
<ogra_> sergiusens_, no, it didnt
<ogra_> sergiusens_, this is rtm only
 * rsalveti reading
<bzoltan> ogra_:  there is a unity-system-compositor.log under /var/log/lightdm
<rsalveti> oh, yeah, the fsck stuff is vivid only
<ogra_> sergiusens_, mvo changed something for ubuntu-core though
<rsalveti> not yet fully landed
<sergiusens_> rsalveti: did the "bug" fix for recovery make it to rtm?
<ogra_> but that also looks unrelated
<rsalveti> sergiusens_: not yet
<sergiusens_> ogra_: that's harmless
<plars-sprint> sergiusens_: I can't physically see the device, but I was told it was sitting at the  "Hi! Welcome to Ubuntu." screen, but we couldn't see them with adb
<ogra_> sergiusens_, nope, there were no android uploads to rtm in quite some time
<sergiusens_> ogra_: then it's missing the recovery fix; plars-sprint you said you didn't update u-d-f since, right?
<ogra_> nor were there any changes to adb or adbd
<sergiusens_> plars-sprint: rsalveti I'm referring to the emails we exchanged a while back
<plars-sprint> sergiusens_: I'm talking about the s/set_adb_onlock/adb_onlock thing
<plars-sprint> sergiusens_: it did get updated the day before, not sure if there was anything that happened in between
<ogra_> thats not used yet
<sergiusens_> plars-sprint: yes; but you said you rolled back?
<ogra_> and wont be til ota-1
<sergiusens_> plars-sprint: keep it rolled back until the rtm adb fix makes it to rtm if someone released a device tarball that doesn't really work...
<rsalveti> sergiusens_: but I believe that also didn't land on rtm
<sergiusens_> rsalveti: ogra_ oh, if nothing landed in rtm it is not that
<ogra_> rsalveti, but perhaps in the phablet-tools ppa
<ogra_> sergiusens_, right, i was more looking for possible server side issues plars-sprint could have here
<sergiusens_> ogra_: no, I'm talking about recovery.img here
<ogra_> since there were no actual changes to the image either when the devices started failing
<robru> ogra_: where do we find the records for LP rejecting PPA uploads? do we know where the ps-jenkins mail goes?
<sergiusens_> ogra_: if none of the adb work entered there, then it's fine; if something slipped in, the all is wrong and the adb fix needs to either go in or rolled out from rtm from recovery.img
<ogra_> robru, uh, no, i dont know ... usually it should go to the MP approver, no ?
<ogra_> sergiusens_, nothing changed in the images ... we were hard frozen when mako started failing
<robru> ogra_: no, not related to MPs.
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/rtm/160.changes and http://people.canonical.com/~ogra/touch-image-stats/rtm/161.changes
<ogra_> it started failing with the first one ...
<sergiusens_> ogra_: mako on rtm?
<ogra_> sergiusens_, lol
<sergiusens_> ogra_: so krillin is fine and mako isn't?
<ogra_> on mako rtm
<ogra_> right
<sergiusens_> ogra_: this is what happens with $name ^^
<plars-sprint> sergiusens_: correct, and I believe flo is broken also
<ogra_> :)
<sergiusens_> nothing is clear a that point ;-)
<plars-sprint> but I haven't checked that one specifically
<ogra_> obviously davmor2 was also able to install and test the image before promotion
<ogra_> (on mako)
<ogra_> and i belive he uses --bootstrap
<sergiusens_> plars-sprint: ogra_ so ubuntu-device-flash touch --channel ubuntu-touch/ubuntu-rtm --bootstrap --password 0000 --developer-mode and it doesn't work?
<sergiusens_> on mako
<ogra_> for plars-sprint it doesnt, right
<plars-sprint> sergiusens_: correct, that's producing something to me that I can't adb into
<sergiusens_> ogra_: and the e2fsck stuff not the adb work (none of it) has landed in rtm?
<sergiusens_> ogra_: adb in the android package
<ogra_> sergiusens_, neither has landed
<robru> fginther: https://launchpad.net/~ps-jenkins do you have access to ps-jenkins bot mail? can you check for a PPA upload rejection mail?
<ogra_> https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-November/thread.html
<ogra_> thats all rtm landings
<ogra_> for this month
<fginther> robru, chcking
<robru> fginther: thanks
<sergiusens_> ogra_: yeah, for rtm, I don't really trust the tools anymore given all the issues we'd had ;-)
<ogra_> last android landing was nov 6th ... for new hybris ... no changes
<fginther> robru, can you narrow it down to a package?
<ogra_> sergiusens_, thats why i use the rtm-changes ml as master ;)
<robru> fginther: qtcreator-plugin-ubuntu from the last few minutes
<ogra_> old tools are still most reliable ;)
<fginther> robru, I see no upload rejections
<robru> bah!
<robru> fginther: thanks for looking. figures I'd test this all weekend and then the first production deployment would just explode.
<cjwatson> robru: What package name?
<cjwatson> Oh you said
<sergiusens_> ogra_: rsalveti plars-sprint https://launchpad.net/ubuntu-rtm/+source/android/20141104-2240-0ubuntu2 I just check the orig tarball there and it has the broken adb logic
<cjwatson> robru: 2014-11-17 17:44:33 INFO    Failed to parse changes file '/srv/launchpad.net/ppa-queue/incoming/upload-ftp-20141117-174412-014889/~ci-train-ppa-service/ubuntu/landing-022/qtcreator-plugin-ubuntu_3.1.1+15.04.20141117-0ubuntu1_source.changes': GPG verification of /srv
<sergiusens_> ogra_: so the changelog is indeed wrong ;-)
<cjwatson> /launchpad.net/ppa-queue/incoming/upload-ftp-20141117-174412-014889/~ci-train-ppa-service/ubuntu/landing-022/qtcreator-plugin-ubuntu_3.1.1+15.04.20141117-0ubuntu1_source.changes failed: Verification failed 3 times: ["(7, 9, u'No public key')", "(7, 9, u'No public ke
<cjwatson> y')", "(7, 9, u'No public key')"]
<cjwatson> robru: i.e. looks like it was unsigned
<sergiusens_> ogra_: and you would need this https://code-review.phablet.ubuntu.com/gitweb?p=CyanogenMod/android_bootable_recovery.git;a=commit;h=ab1d4747d5581cdbbf233eaedbf3e38cf324efef
<ogra_> sergiusens_, well, but that landed on the 6th ... images stopped working on the 13th
<robru> cjwatson: can this be some kind of temporary glitch? https://ci-train.ubuntu.com/job/ubuntu-landing-022-1-build/23/console shows it being signed and the signature being good
<plars-sprint> sergiusens_: ogra_: so I could revert the ubuntu-device-flash again, or we can fix it there.
<cjwatson> robru: It's possible.  There have been acceptances since then
<cjwatson> The keyserver is occasionally flaky
<ogra_> plars-sprint, try it ...
<cjwatson> robru: Is it reasonably straightforward for you to retry?
<robru> cjwatson: yeah
<sergiusens_> ogra_: well I don't know, the code doesn't lie; the broken adb landed in source on Oct 30
<ogra_> sergiusens_, right and in binary on nov 6th
<ogra_> but images failed only on the 13th+
<sergiusens_> ogra_: oh, because plars-sprint told me he'd keep the old u-d-f until further notice
<ogra_> sergiusens_, hmm, you held back u-d-f from the PPA ... i wonder if mvo tried to be a good citizen and copied it over after his stuff landed
<ogra_> without knowing that he shouldnt
<sergiusens_> ogra_: plars-sprint I can disable this with one line removal from u-d-f
<sergiusens_> ogra_: I did it; as plars-sprint told me they manually updated u-d-f
<ogra_> or plars-sprint can just roll back
<plars-sprint> sergiusens_: no, until that fix went in, which it did. I tested it on krillin and thought it had already been tested on mako. So we will revert again. At some point we need the update though because of some further changes you have planned right?
<plars-sprint> I'm rolling it back right now
<plars-sprint> to 0.4+14.10.20140929-0ubuntu1
<ogra_> plars-sprint, right, that requires full coordination actross all images and all devices :)
<ogra_> that will be a lot of fun to land :P
<sergiusens_> plars-sprint: ogra_ I'll do a revert on u-d-f of the one line rule; it sucks that such a dumb fix can't land in rtm
<robru> cjwatson: retried and it worked. thanks for checking
<robru> bzoltan: https://launchpadlibrarian.net/190564701/buildlog_ubuntu-vivid-amd64.qtcreator-plugin-ubuntu_3.1.1%2B15.04.20141117-0ubuntu1_FAILEDTOBUILD.txt.gz Error looks like a missing dependency. Did you add a new dependency without adding it to debian/control?
<cjwatson> robru: good, sorry for the inconvenience
<bzoltan> robru:  No, I do not think so... but let me check what zbenjamin has done ...
<bzoltan> zbenjamin:  robru: libudev1
<rsalveti> sergiusens_: changelog is fine
<rsalveti> sergiusens_: so it's a combination of latest u-d-f and the broken adb logic
<rsalveti> that would explain
<sergiusens_> rsalveti: yes; and broken telephone (the game) :-)
<rsalveti> sergiusens_: yeah, easier to use the older u-d-f until we update android for RTM
<rsalveti> indeed annoying
<mterry> bzoltan, ogra_: sorry, was afk for gym.  There's a question about usc?
<ogra_> mterry, bzoltan was looking for explicit usc logs
<bzoltan> mterry:  working out is healthy :)
<bzoltan> mterry: since than i figured out the problem
<mterry> bzoltan, awesome.  Glad I could help  ;)
<bzoltan> mterry:  you guru :)
<ogra_> and he doesnt even have long hair and a beard !
<ogra_> sil2100, FYI ... i found the ML archive shows the landing mail within minutes *if* you sort by date (there is a selection at the top of the page to sort by thread or date)
<sil2100> UUuggh
<sil2100> ogra_: ok, thanks!
<ogra_> :)
<ogra_> by default you indeed get "by thread" ...
<sil2100> Yaay, no more waiting for hours \o/
<ogra_> yeah
<ogra_> worked fine for me last week
<bzoltan> robru:  something must have changed in vivid ...
<robru> bzoltan: vivid does that ;-)
<bzoltan> robru:  it said that "Project ERROR: libudev development package not found" when we do depend on libudev-dev
<sil2100> grrr, and now I'm having problems with sending e-mails, wth
<robru> bzoltan: maybe the structure of libudev packages changed in vivid? not sure, I'm unfamiliar with udev
<bzoltan> robru:  me too
 * bzoltan goes and makes a vivid cowbuilder
<sil2100> Moo
<rsalveti> ogra_: will trigger another vivid image
<robru> sil2100: yeah I don't have a clue what's wrong with the dashboard. the spreadsheet doesn't seem to be missing info (the usual cause of missing dashboard info). also the fact that just some work and some don't is bizarre.
<ogra_> rsalveti, go wild
<rsalveti> ogra_: done :-)
<ogra_> :)
<imgbot> === trainguards: IMAGE 24 building (started: 20141117 18:40) ===
<robru> sil2100: all my troubleshooting skills say "look at the couple silos that do work and compare them to the rest" and I don't see any difference.
<sil2100> robru: at first I thought that some description might have caused the issue by having some strange malformed syntax in it, but I think it's not the case
<sil2100> robru: my original culprit was the unity8 silo, but all looks ok there
<ogra_> https://lists.launchpad.net/ubuntu-phone/msg10521.html
<ogra_> hah
<ogra_> minutes :)
<Saviq> trainguards, I can has silo 14 published, please (/me hates the dashboard for not reading the status out of the SS)
<robru> Saviq: please direct your hatred at the spreadsheet. I'm pretty sure it caused WW2 and has been plotting evil schemes ever since.
<Saviq> robru, ok /me hates SS then...
<Saviq> hmmm
<Saviq> I think that should be built into my polish self anyway
<ogra_> robru, did you just invoke godwins law here ?
<Saviq> </bad nazi joke>
<robru> ogra_: well I didn't mention anybody by name...
<ogra_> heh
<bzoltan> robru:  that error just does not make sense to me ... the libudev-dev package is available in Vivid and according to the logs it is installed to the builder too
<sil2100> bzoltan: did you try in a cowbuilder/pbuilder ?
<robru> bzoltan: yeah I dunno. hang on I'll hit retry, maybe today is a day for transient issues
<bzoltan> robru: it faild on vivid cowbuilder too ...
<robru> bzoltan: yeah the retry failed in the ppa as well, same failure
<robru> bzoltan: great news, if you reproduced it locally you're one step closer to fixing it ;-)
<kenvandine> rvr, any word on silo 3?
<kenvandine> ah, he said om26er_
<kenvandine> om26er_, any word?
<om26er_> kenvandine, I am working on silo2, will work on 3 afterwards. rhuddie was working on it, he went away.
<kenvandine> om26er_, ok, thx
<bzoltan> robru:  we have this PKGCONFIG += libudev glib-2.0
<robru> bzoltan: try libudev1 maybe? that's the binary package name
<bzoltan> robru:  hmmm... wait a second... this is the first time we try to land somethinga since qt5.3.2
<robru> bzoltan: looks like pitti was the last person to touch systemd in vivid, worst case maybe ask him if anything about libudev changed since utopic
<bzoltan> robru:  I am afraid that it is not about libudev ... but about Qt and the pkgconfig of the qtcreator-plugin-ubuntu project
<robru> bzoltan: something you can fix? i'm not familiar with any of that stuff ;-)
<robru> bzoltan: i'm just glad this issue isn't caused by my new citrain code ;-)
<bzoltan> robru:  I will need Mirv for that
<bzoltan> robru:  your CI train code is safe here :)
<robru> bzoltan: hehe thanks
<pmcgowan> ogra_, popey how does music app get silod/tested
<ogra_> pmcgowan, i imagine popey gives the click to QA
<popey> pmcgowan: I have created a set of manual tests to perform, we have candidate click.
<popey> I am happy to throw at QA, but who? some people are on vacation?
<pmcgowan> was just trying to figure that out
<popey> I want to do a load more testing before giving to QA
<popey> intended to hand to QA tomorrow morning, but if someone in US TZ can test on my overnight then that would be preferable.
<ogra_> popey, talk to jibel, he should be able to point you at someone
<popey> jibel: yo!
<pmcgowan> popey, lets get a trello card for it so its queued up
<popey> pmcgowan: got a link to the trello board? I don't seem to be subscribed to it.
<ogra_>  https://trello.com/b/AE3swczu/silo-testing
<pmcgowan> popey, need QA to update it I suspect https://trello.com/b/AE3swczu/silo-testing
<pmcgowan> ogra_, you so fast
<ogra_> heh
<popey> jfunk: are you able to add a trello card to the QA board for testing the music app for me?
<jdstrand> olli, pmcgowan: fyi, the apparmor-easyprof-ubuntu changes (rtm silo 002) is awaiting qa signoff. I'm just waiting on that to then coordinate with cwayne to push to rtm
<robru> Saviq: well, dashboard seems to be back. I didn't fix anything. I guess it's just a transient issue with google or something. no idea
<pmcgowan> jdstrand, looks like om26er_ is testing now
<om26er_> pmcgowan, yes, tests are running, taking a long time
<jdstrand> ok, cool
<pmcgowan> thanks
<jdstrand> the apparmor-easyprof-ubuntu image tests takes a while
<bzoltan> robru:  The qtc plugin MR got a quick facelift ... somehow the vivid builders have different packages .. .like pkg-config and libglib2.0-dev was missing
<bzoltan> robru:  I triggered a new build with debug info
<robru> bzoltan: cool thx
<jfunk> popey: is it not going to be tested as part of silo?
<ogra_> jfunk, clicks are never siloed
<ogra_> there were plans at the sprint to make that possible ... but not implemented yet afaik
<jfunk> ack
<ogra_> for some of the apps we have desktop packages (i.e. gallery9 there we can have debs in silos for testing ... but not for click only ones
<jfunk> popey: sure we can do that, when do you need it by?
<ogra_> for this milestone would be good
<ogra_> (before wed. evening EU TZ)
<ogra_> so it gets a week of testing before the golden milestone
<ogra_> (like ... enduser testing ... for the weird guy that has 15632 albums of only one artist etc :) )
<ogra_> kenvandine, you broke it :P
<ogra_> heh, funny seems they all built on all arches ...
<ogra_> so the bot lies ...
<kenvandine> 2014-11-17 19:57:21,296 ERROR Expected {'indicator-power': set(['12.10.6+15.04.20141103~rtm-0ubuntu1']), 'powerd': set(['0.16+15.04.20141031.2~rtm-0ubuntu1']), 'ubuntu-system-settings': set(['0.3+15.04.20141112.1~rtm-0ubuntu1']), 'upower': set(['0.99.1~rtm-3'])}+[u'upower', u'powerd', u'indicator-power', u'ubuntu-system-settings'] in PPA but found {u'indicator-power': set([u'12.10.6+15.04.20141103~rtm-0ubuntu1']), u'ubuntu-system-settings
<kenvandine> ': set([u'0.3+15.04.20141113.1~rtm-0ubuntu1']), u'upower': set([u'0.99.1~rtm-3']), u'powerd': set([u'0.16+15.04.20141031.2~rtm-0ubuntu1'])}. Perhaps uploads failed?
<ogra_> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-016/+packages
<ogra_> the ppa looks fine
<kenvandine> yeah, it does lie :)
<imgbot> === trainguards: IMAGE 24 DONE (finished: 20141117 20:10) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/24.changes ===
<ogra_> rsalveti, ^^^ yours
<rsalveti> ogra_: thanks
<robru> kenvandine: looks like unexpected version of u-s-s in the ppa...
<robru> kenvandine: yeah, your sync attempted to upload 1112.1 but 1113.1 was already in the PPA. I guess you'll need to bump the version manually
<robru> kenvandine: easiest thing I guess would be to free the silo and start over in a different silo. then the 1112.1 upload would succeed
<robru> kenvandine: either that or change it from a sync silo to a manual source silo and then just do all the uploads yourself with copypackage
<robru> kenvandine: ogra_: bot doesnt lie, it's reporting what the build job tells it to. build job failed because the version in the PPA is not the version that the build job uploaded
<robru> kenvandine: apologies that raw data structure dump is totally unreadable, I should fix that
<kenvandine> robru, i can fix it :)
<kenvandine> thx
* robru changed the topic of #ubuntu-ci-eng to: Need a silo? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: RTM Archive semi frozen (only pre-selected fixes) ! RTM cron builds disabled. robru landed a major overhaul of citrain today, please ping him with ALL jenkins job failures you encounter.
<robru> I gotta grab lunch, please ping me if anything explodes.
<popey> jfunk: sorry, was afk
<popey> jfunk: ask ogra_ says, asap really. We haven't used silos before for the community click apps. We'd ordinarily just push the click under test to the phone and go through the usual manual tests
<popey> jfunk: left a comment on the trello card with the link to the click which needs testing
<pmcgowan> popey, seems nuclearbob waslooking for you on that
<popey> super
<jfunk> popey: ack thx
<nuclearbob> popey: do you have the test plan handy?
<popey> kinda, working on it right now.
<popey> this is a bit new to me â»
<iahmad> popey, is there some design doc/functional spec for new music app?
<popey> iahmad: yup
<iahmad> popey, would you please point me to that
<popey> iahmad: https://docs.google.com/a/canonical.com/presentation/d/1L3eGhOe-0eEmKtUurthpUEaweFradSFb3t6W-KiIZMU/edit#slide=id.g4d67bb613_11
<iahmad> +?
<popey> does that link work for you?
<iahmad> popey, it did, thanks
<popey> no problem
<robru> kenvandine: ah sorry this time it's my fault. I'm working on a fix for that bug already. WATCH_ONLY might be able to workaround that for now
<iahmad> popey, what is the lp project for new music app?
<popey> lp:music-app
<kenvandine> robru, ok
<robru> *phew* ;-)
<kenvandine> :)
<kenvandine> now if i can figure out how to install powerd from that ppa :)
<kenvandine> ogra_, ideas?
<kenvandine>  unable to make backup link of `./usr/share/powerd/device_configs/config-default.xml' before installing new version: Invalid cross-device link
<robru> kenvandine: oh I saw instructions for that once forever ago. you have to like, copy the files into the rootfs while in recovery mode or something.
<om26er> kenvandine, I had a system-settings crash, not sure if its related to the change in the silo.
<om26er> https://errors.ubuntu.com/oops/5b9b2d7c-6ea1-11e4-bce8-fa163e4ccdf2
<kenvandine> om26er, doubtful, what were you doing when it crashed?
<kenvandine> like what panel?
<om26er> kenvandine, after toggling many settings, I came to the main screen and tapped on 'Brightness'  panel and app freezed and eventually crashed.
<kenvandine> robru, but how do you actually update the package?
<kenvandine> ok, that isn't different
<kenvandine> known issue :)
<kenvandine> s/isn't/is/
<robru> kenvandine: can't remember, sorry.
<kenvandine> robru, thx anyway
<robru> kenvandine: there should be a wiki for it somewhere. does it not mention installation instructions in the test plan?
<robru> kenvandine: http://paste.ubuntu.com/8224550/ here you go
<jdstrand> cwayne1: can you ping me when you are ready for me to push apparmor-easyprof-ubuntu?
<cwayne1> jdstrand: will do
<jdstrand> cwayne1: also, if I go eod, feel free to ask trainguards to do it without me
<robru> jdstrand: do what now?
<jdstrand> robru: we like to coordinate the apparmor-easyprof-ubuntu publication with the custom tarball
<robru> jdstrand: you got a silo ready to be published?
<jdstrand> robru: since, apparmor-easyprof-ubuntu is ready and signed off, I was just saying that if I wasn't around, cwayne1 didn't have to wait on me
<jdstrand> robru: and could ask one of you to press the publish botton
<jdstrand> robru: yes, rtm silo 002
<robru> jdstrand: ah ok. thought you might need me to upload something into a silo, which I'm not prepared for. but I can publish silos when needed ;-)
<jdstrand> hehe, no, silo is completely ready :)
<nuclearbob> trainguards: com.ubuntu.music-2.0.744.all should be ready to land, there's no silo associated since it's a click package
<popey> nuclearbob: balloons can upload to store
<popey> (if he's around)
<nuclearbob> let's see if he is
 * balloons floats
<popey> \o/
 * popey hugs balloons 
<balloons> yay! music!
<nuclearbob> woo music!
<popey> balloons: the click is linked from the trello card for it
<balloons> pushed, popey, review time
<nuclearbob> woo!
<popey> balloons: i dont see it
<popey> assume it passed
<popey> oh, now i do
<popey> odd
<popey> uh, we need to speak to martin tomorrow, there's some inconsistencies in the store.
<popey> Thanks nuclearbob balloons â»
<nuclearbob> :)
<nuclearbob> and now, eod
<popey> \o/
<ogra_> is it in ?
<balloons> popey, ack
<popey> yes
<ogra_> hmm, my phone doesnt think so
<popey> bet i busted the store by rolling back
<popey> yeah, i think i broke the store
<popey> balloons: you still about?
<popey> i think i need to file a bug for this...
<balloons> popey, awesome
<popey> yeah, not â»
<balloons> popey, what would you like me to do?
<popey> balloons: my theory was that we should apporove the broken 2.0.738 then try and upload 2.0.744, but I fully expect that to fail
<popey> because you already uploaded 2.0.744
<popey> so rather than that I'm gonna file a bug and send a mail to phablet about it
<popey> because the store is basically broken
<popey> so nothing required for you to do
<balloons> popey, ah that does make sense
<balloons> no bueno bueno
<balloons> bah, I failed
<popey> bug 1393606
<ubot5> bug 1393606 in Software Center Agent "Store inconsistent after rolling back an app" [Undecided,New] https://launchpad.net/bugs/1393606
 * popey emails phablet
<om26er> trainguards please rebuild ubuntu-rtm/landing-006
<robru> om26er: done
<om26er> robru, thanks.
<robru> om26er: you're welcome
<ogra_> robru, for rtm 2 there is a coordinated landing with a custom tarball needed (for which we do not yet have QA) ... so dont land it :)
<robru> ogra_: yeah was waiting for a ping from cwayne1 on that one
<ogra_> cool
<ogra_> we will need to coordinate that with an image build too
<ogra_> (stop the importer, wait for rootfs, start importer with rootfs and custom tarball in place)
#ubuntu-ci-eng 2014-11-18
<robru> that was a quick qa signoff ;-)
<robru> kenvandine: ok finally landed the nicer error pretty printing in production, you should break another silo so we can enjoy the enhanced clarity of the error message ;-)
<kenvandine> robru, i'll pass :)
<kenvandine> robru, silo 3 has passed QA, can i publish that?
<robru> kenvandine: I dunno I thought we were in some kinda mega-super-freeze? I don't understand why that was approved. but if you want to publish it, I guess go ahead
<kenvandine> it was supposed to be in last thursday's image :)
<robru> ah
<kenvandine> but qa verification took nearly a week :/
<robru> kenvandine: ok well it doesn't bother me if you publish it. I'm just worried about management approval
<kenvandine> management approved it :)
<imgbot> === trainguards: IMAGE 25 building (started: 20141118 02:05) ===
<imgbot> === trainguards: IMAGE 25 DONE (finished: 20141118 03:25) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/25.changes ===
<Mirv> bzoltan: first time since 5.3.2 yes, but note that uitk was landed with 5.3.2 too so it worked
<Mirv> bzoltan: oh, the qtc plugin, right. qtc itself + remotelinux plugin were landed as part of 5.3.2, but not the ubuntu plugin
<bzoltan> Mirv: Ok, Qt was not the problem... for some reason the vivid builder was missing the pkg-config
<bzoltan> Mirv:  I am running the UITK AP tests against silo16
<bzoltan> Mirv:  I could not figure out better way to validate the new qtbase ... unless if if you have an indea
<bzoltan> Mirv:  I am confused ... the silo22 is marjed as failed ... but I see the deb packages in the PPA. I just tested them and they are good to land.
<Mirv> bzoltan: I don't have better ideas, only the qmake changed
<Mirv> bzoltan: possible ci train regression
<Mirv> checking watch only
<bzoltan> Mirv:  yes, but some test must be run :) so to check if n regression is introduced
<Mirv> better safe than sorry
<bzoltan> Mirv:  after all we run the configure twice :)
<Mirv> robru: we may have some sort of build job problem(s)
<robru> Mirv: got a log?
<Mirv> robru: https://ci-train.ubuntu.com/job/ubuntu-landing-022-1-build/26/console + https://ci-train.ubuntu.com/job/ubuntu-landing-022-1-build/27/console + any failed from http://people.canonical.com/~platform/citrain_dashboard/#?q=
<Mirv> robru: unping 27, it succeeded ie watch_only still works, was just very slow
<Mirv> robru: but then a lot of like https://ci-train.ubuntu.com/job/ubuntu-landing-001-1-build/98/console where everything seems correct but ends with failure status. but it's good if the next watch_only works, nothing fatal.
<Mirv> bzoltan: please mark the 022 now as tested
<robru> Mirv: https://ci-train.ubuntu.com/job/ubuntu-landing-022-1-build/26/console was one of the issues I discovered and already fixed during my shift
<Mirv> robru: oh, excellent! that was already some time ago indeed, not a recent build.
<bzoltan> Mirv:  done
<Mirv> robru: the 001/98 is also quite old, maybe that would also work now already. well, good job then, fixing all the bugs :)
<bzoltan> Mirv:  I have tested it with emulator, I assume that in the case of SDK tools, that qualifies
<robru> Mirv: in fact there's two parts to that fix, one to make it actually read the ppa properly, and one to make it report that error in a much more readable way when there is a legitimate problem with the ppa contents ;-)
<Mirv> bzoltan: it should
<Mirv> robru: human readable errors in ci train, that'd be the first! :) usually it's "I exploded, file/network/everything error" which means "oh you forgot a space character from changelog"
<robru> Mirv: hehe, yeah
<robru> Mirv: yeah, silo 1 build run 98 also looks quite old, it doesn't even include my log-print-ordering fixup, looks like that run was from even before my shift started this morning
<robru> (definitely before I deployed)
<Mirv> robru: yes, it seems everything is in order, watch_only build works, publish works.. thanks!
<robru> Mirv: no worries! I'm super glad to have deleted literally 400+ lines of untested code and replaced it with tested code ;-)
 * Mirv runs build watch_only for all "failed" silos
<Mirv> robru: sounds excellent
<bzoltan> Mirv:  we will need a jedi's eye onthe new qtc plugin package as we had to add two new build deps
<bzoltan> Mirv:  the qtbase from silo16 is good to go
<Mirv> bzoltan: I was the jedi (or, master of the universe) as it's not in main
<Mirv> bzoltan: an dok
<bzoltan> Mirv:  \o/ small step for a man and giant leap for qmake users
<tvoss> trainguards, can I haz silo for line 59?
<sil2100> tvoss: looking at it now
<tvoss> sil2100, thanks
<tvoss> sil2100, also, could someone take a look at an MP that does not get Jenkins love?
<sil2100> tvoss: you mean, CI is not running for it?
<tvoss> sil2100, yup
<sil2100> tvoss: ok, this might require cihelp then
<tvoss> sil2100, ack
<robru> tvoss: i already talked to ci about that, apparently Jenkins is just slammed by a large rush of mps all at once... Give it some time
<tvoss> robru, ack, but the MP has been up for a few days :)
<robru> tvoss: Hmmmmmmm then definitely ping ci ;-) i had an mp today take 45 minutes when it normally takes 15.
<tvoss> robru, ack
<tvoss> cihelp, hey there :)
<Mirv> ogra_: a couple of topblocker fixes went in in the morning, you'll probably want to build an image
<brendand> Mirv, good morning
<sil2100> Mirv: do you know which ones?
<ogra_> Mirv, for silo2 we need a custom tarball landing at the same time, i want to know the status of the QA testing for it before kicking one ...
<ogra_> (for the tarball that is)
<sil2100> Oh, silo 2 and 6 I see
<ogra_> right, but 2 cant land alone
<sil2100> When does cwayne1 start his day?
<sil2100> Or do we have also someone else that can upload the tarball?
<ogra_> oh, the uploading ... heh ... i was so focused on signoff info that i forgot about that small bit :)
<ogra_> i guess then we should push 006 in and roll one :)
<ogra_> oh, err
 * ogra_ just notice that both are landed
<ogra_> +s
<ogra_> hmm
<Mirv> brendand: morning
<Mirv> sil2100: rotation lock + apparmor fix, but ogra is right about the tarball
<sil2100> ogra_: yeah...
<sil2100> ogra_: so we need to wait for the tarball before we can proceed
<ogra_> right
<ogra_> unless you like 10min boots :)
<brendand> Mirv, did anyone follow up with you about silo 22 yesterday?
<ogra_> brendand, afaik the bug couldnt be reproduced even without the silo
<brendand> ogra_, yeah. i'm not sure i can even test it since it has to do with roaming
<ogra_> send me your sim ;)
<tvoss> sil2100, ping
<sil2100> tvoss: pong
<tvoss> sil2100, hey, could you have a look here: https://ci-train.ubuntu.com/job/ubuntu-landing-014-1-build/111/console
<tvoss> sil2100, seems like vivid has got a version released that is not in sync with trunk
<jibel> has silo 3 been published o rtm ?
<jibel> *to
<sil2100> tvoss: yeah, see it - it seems to be a no-change rebuild from Brian, I guess we can force ignoring this
<ogra_> jibel, was that system-settings ?
<ogra_> (if so, yes)
<sil2100> tvoss: in this particular case, you can use the FORCE_REBUILD flag during build
<sil2100> tvoss: or, if you prefer, we can simply sync this change to trunk and build normally
<sil2100> tvoss: it's cleaner, but not required
<jibel> ogra_, ok, I didn't receive the notification. thx
<sil2100> jibel: btw. do we have someone doing sanity testing of newly created images right now?
<jibel> sil2100, yes rhuddie and rvr
<sil2100> jibel: are they also doing vivid sanity testing?
<jibel> sil2100, yes on mako
<sil2100> Ok, thanks
<Mirv> brendand: I had a lot of followups, but none that answer directly the most important question "do we still need it?"
<Mirv> brendand: I did 5+ new builds yesterday evening and this morning, and I have a good feeling about this last one now building that it could succeed on all three archs while keeping the tests enabled (aside from disabling four new known faulty ones)
<Mirv> so that'd be a candidate for landing, if we just know we want to land it or not..
<Mirv> brendand: if you have any further followups from QA side, feel free to share. victor at least was not able to reproduce the original problem anymore.
<brendand> Mirv, i'm not sure what he tried though, i'll have to talk to him first
<Mirv> and here's the discussion between pat and lorn that does not answer directly whether we need it or not: https://pastebin.canonical.com/120606/
<Mirv> brendand: I believe he tried (after a few iterations) my updated test steps from https://wiki.ubuntu.com/Process/Merges/TestPlans/Qt#Testing_networking_code_in_Qt_Base
<Mirv> and there's the "Without the PPA..." line especially
<brendand> Mirv, the bug mentions roaming though
<Mirv> which I thought I was still able to reproduce
<brendand> Mirv, is that roaming like data roaming, or a different kind of roaming?
<Mirv> brendand: I'm not sure if that was a guess from Victor why scopes didn't work. the roaming word was noticed in comment #63...
<Mirv> "only on Symbian"
<Mirv> brendand: the whole QNAM (short for the QtNetworkAccessManager) and how we use it is completely unknown to me, and I'm not even sure who to ask.
<Mirv> brendand: it seems important/useful that QNAM works as it should, but the effect of it depends on how much we control network directly and how much via Qt, I'd think
<ogra_> olli, pmcgowan, please see popey's mail from last night "Cannot approve Music 2.0.744 to store" ... i consider bug 1393606 a topblocker (at least until music app couold land somehow)
<ubot5> bug 1393606 in Software Center Agent "Store inconsistent after rolling back an app" [Undecided,New] https://launchpad.net/bugs/1393606
<popey> just mentioned it to them in #phablet
<ogra_> ah ... i dont go to the office channels until after the meeting :)
<pmcgowan> yep
<sil2100> ;)
<bzoltan> ogra_:  just out of curiosity ... do you know where is the kernel source?
<ogra_> bzoltan, for what ? mako, flo and friends are on kernel.ubuntu.com
<bzoltan> ogra_:  ohh, that is perfect. for mako only
<ogra_> there is also a source package
<om26er> when will the new image build be kicked ?
<popey> ogra_: music app approved into store now, thanks to bueno and team.
<popey> cc olli & pmcgowan ^
<pmcgowan> popey, awesome
<ogra_> popey, yay !
<sil2100> \o/
<sil2100> popey: thanks!
<sil2100> popey: but is this bug resolved in the end, or did it get worked-around?
<popey> well the bug in the store still exists I guess
<popey> it was worked around
<jgdx> cihelp: hi, it seems that otto has issues passing USS CI[1]. Seems related to the regression fginther fixed a couple of days ago. [1] https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-vivid/146/console
<psivaa> jgdx: let me take a look
<sil2100> cwayne1: ping, give us a sign when you're around
<sil2100> brendand, ogra_: just in case - we don't have the tarball around already for testing, or do we?
<ogra_> i thought cwayne1 had prepared it last night
<brendand> sil2100, how would i land a new version of reminders-app?
<brendand> sil2100, it's required to fix those tests
<brendand> sil2100, not the click package you see, but the debian source package
<brendand> sil2100, any idea who's responsible? or do i need to become a lander (dun dun dun!)
<jgdx> psivaa, thanks
<cwayne1> sil2100: heya
<cwayne1> ogra_: we were missing one update we needed in the custom tar so I couldn't get it fully prepared last night, checking now if it's been fixed
<sil2100> brendand: wait, reminders is a typical click package, right?
<sil2100> brendand: at least I always remembered it being that - why do you need to fix the debian source package?
<sil2100> cwayne1: hey! Wanted to poke you about the same thing, since we landed the silo that needs the new custom tarball
<sil2100> So we're waiting before we can build a new image :)
<ogra_> sil2100, and pray that tthe tarball passes QA :P
<cwayne1> :)
<cwayne1> sil2100: so is the new apparmor-easyprof-ubuntu in the archive now?
<cwayne1> or did you just publish
<ogra_> was published a few hours ago
<om26er> ogra_, I just signed in, when does the new image get build ?
<om26er> *t
<om26er> I was expecting it to be EU morning.
<ogra_> om26er, well, apparmor-easyprof-ubuntu... so now we have to wait for the new custom tarball first
<ogra_> else we cause 10min boot time uf we build without it
<om26er> ouch, ok.
<sil2100> cwayne1: it should be in the archive since long, yes
<cwayne1> sil2100: ack,thanks
<cwayne1> just preparing the last bits now, then will build and test, then hand off to QA
<cwayne1> but need to run a quick unexpected errand first, bbiab
<psivaa> jgdx: i still see those failures, was digging what the fix would have been in the previous runs, will ping fginther when he comes online
<cjwatson> ogra_,wgrant: https://code.launchpad.net/~cjwatson/canonical-is-puppet/ppa-symlinks/+merge/242069 FYI
<ogra_> Error ID: OOPS-1c13fefbd94d1b1e5178737a674fae10
<ogra_> :)
 * ogra_ reloads
<ogra_> \o/
<ogra_> cjwatson, thanks !!
<jgdx> psivaa, thanks so much.
<brendand> sil2100, it has a binary package for the account provider
<sil2100> brendand: oh?
<sil2100> hm, ok, nice then
<sil2100> Let me try finding who was landing it before
<sil2100> One moment
<ogra_> i think thats dpm
<dpm> hi, what's up?
<ogra_> new reminders :)
<dpm> ?
<ogra_> (teh matching deb for your recent click upload)
<brendand> dpm, are you able to do a landing for reminders-app in RTM? the source package provides a fake account provider
<sil2100> brendand: ok, last person was dpm
<sil2100> ogra_: right!
<sil2100> ;)
<ogra_> ;)
<brendand> dpm, so we need the source package updated, as opposed to the click
<ogra_> well, along with ...
<dpm> brendand, sil2100, why do you need the .deb package?
<brendand> dpm, i just did my best to explain :)
<brendand> dpm, it has account-plugin-evernote-sandbox
 * brendand actually isn't sure reminders-app ever landed in RTM
<dpm> brendand, right, but what is it needed for?
<ogra_> which i assume AP will pull from the archive for the AP tests
<brendand> dpm, to make the tests work
<dpm> brendand, is that not pulled from the core apps PPA?
<brendand> dpm, hmm, could be
<brendand> dpm, do any other core-apps AP tests do the same?
<brendand> dpm, which ppa is that?
<dpm> brendand, https://launchpad.net/~ubuntu-touch-coreapps-drivers/+archive/ubuntu/daily?field.series_filter=vivid
<dpm> I thought Jenkins published and used the .debs there, but the best person to ask is fginther
<brendand> dpm, ahhhh
<brendand> dpm, what about RTM?
<brendand> dpm, i guess you don't have a PPA for that
<brendand> certainly looks like that's the case
<brendand> sil2100, so we probably don't need a landing
<brendand> sil2100, but i don't think what we do need is any simpler
<sil2100> brendand: yeah... I think we need to get some answers on what happens for rtm in this case
 * brendand waits for fginther 
<cwayne1> sil2100: hi, whos going to be doing the custom testing?
<brendand> cwayne1, that'll be me
<sil2100> cwayne1: I would point at brendand ;)
<cwayne1> brendand: cool beans, thanks. just wanted to know who to include on the changelog email :)
<jibel> cwayne1, please cc me
<popey> sil2100: we planning on cranking another image out today?
<sil2100> popey: yes
<sil2100> popey: we need the new custom tarball landed though
<popey> ah okay
<cwayne1> jibel: done
<cwayne1> brendand: sil2100: custom tarball(s) ready, email sent
<jibel> cwayne1, thanks
<sil2100> cwayne1: excellent, thanks!
<sil2100> brendand: ^
 * cwayne1 crosses fingers
 * ogra_ crosses more
<cwayne1> also good news is we got many of these into the store, so we can now update individual scopes independently of the custom tar if needed :)
<sil2100> oSoMoN: ping :)
<brendand> cwayne1, turns out om26er will test it
<sil2100> alecu: hello!
<cwayne1> brendand: coolio, would you mind fwd'ig that changelog over?
<jibel> cwayne1, done
<cwayne1> thanks
<alecu> hi sil2100
<om26er> cwayne1, Hi! Can you tell how to get started with testing the custom tarball ?
<brendand> om26er, i think the instructions were in the email
<sil2100> alecu: so, I was wondering how far from landing is silo 11 for RTM
<cwayne1> om26er: hiya, it should be in the email, but tl;dr flash ubuntu-touch/ubuntu-rtm/14.09-proposed-customized
<alecu> sil2100: I think it's not far from landing... I'm following the test plan again on it now.
 * jdstrand wonders if it still is 10 minutes-- I would think it would be closer to 4 now if it used to be 10
<sil2100> alecu: excellent, thanks :)
<ogra_> jdstrand, it is definitely less if you dotn have any apps from the store installed :)
<oSoMoN> sil2100, pong
<sil2100> oSoMoN: hey! Wanted to get some info related to the fix for LP: #1391230
<ubot5> Launchpad bug 1391230 in oxide-qt (Ubuntu RTM) "[TOPBLOCKER] web audio, pulse runs at 6% and screen will not blank on idle" [Undecided,In progress] https://launchpad.net/bugs/1391230
<sil2100> oSoMoN: is the fix for oxide-qt ready? Do we also need a fix for pulseaudio for RTM for this to be fixed?
<jdstrand> ogra_: well, I meant that we made a rather important compile improvement a few weeks back (~65% faster on krillin)
<ogra_> jdstrand, bah, now that nobody hits the issue anymore you made it fast :P
<ogra_> :)
<oSoMoN> sil2100, my understanding is that the fix for oxide is sufficient, not sure if someone is working on an additional patch for pulseaudio
<sil2100> oSoMoN: do we have that fix in a silo already?
<oSoMoN> sil2100, not in a silo yet, but it should be built in the security-team PPA, let me check
<oSoMoN> chrisccoulson, is the oxide 1.3 build ready in the security-teamÂ PPA?
<brendand> fginther, ping
<fginther> brendand, hey
<chrisccoulson> oSoMoN, it is https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa
<chrisccoulson> although, I still don't know if chrome 39.0.2171.62 will be the actual release. so there's still a possibility of doing another upload
<oSoMoN> chrisccoulson, when do you reckon the stable release will be announced?
<chrisccoulson> oSoMoN, I'm not sure, as we don't have that information. But I'm guessing it will be today
<chrisccoulson> it's usually tuesday
<sil2100> I would like the fix for the topblocker to be available in a silo till EOD today
<sil2100> So that it can make it for our milestone this week
<oSoMoN> sil2100, we can copy it in a silo now, but if the chromium version is bumped, weâll need another build
<sil2100> Let's maybe wait - the PPA builds for ubuntu-rtm as well? Or will we need a source copy?
<oSoMoN> sil2100, the PPA builds for regular trusty, utopic and vivid, not for RTM
<oSoMoN> IÂ guess that means a source copy is needed
<sil2100> oSoMoN: ok, thanks for all the info :)
<sil2100> Let's just try at least having a silo for it today
<oSoMoN> sil2100, how about we request a silo now, do a source copy, and cancel the build later if a version bump is needed?
<sil2100> ogra_, olli: so far we seem to have all the topblockers under control
<ogra_> sil2100, yeah
<sil2100> ogra_, ogra_: too bad the file corruption one doesn't have a definite fix yet from what I saw on #phablet...
<sil2100> But this one is *optional* for this milestone from what I saw
<ogra_> well, it has a possible easy fix by changing the default mount options
<brendand> fginther, we were wondering, do the ci jobs install dependencies from the core-apps ppa for click apps?
<ogra_> but we're not sure about the impact yet
<ogra_> (speed etc)
<ogra_> GRRR !
<sil2100> ogra_: so the change to data=journal helps in the end?
 * ogra_ struggles a bit with his part of the file corruption bug 
<ogra_> sil2100, yes, but it might have some performance impact
<fginther> brendand, the core-apps daily PPA has been used by the jenkins jobs that do the MP testing for the core-apps. It has never been used for image smoke testing. The PPA was intended to just be a convience for the core-apps developers and not an official publishing mechanism
<brendand> fginther, ah right
<brendand> dpm, ^
<brendand> sil2100, so maybe we still use the landing route
<sil2100> fginther, dpm, brendand: so we need to release it to the archive then?
<brendand> sil2100, i would, but i'd like to hear what dpm thinks
<fginther> sil2100, right, if the test needs the package for smoke testing, then it needs to be in the archive.
<sil2100> I suppose we could, I can set-up a landing for you brendand if you give me the merge
<sil2100> brendand: or is it already merged in trunk?
<brendand> sil2100, yeah
<brendand> sil2100, i hope none of those packages are seeded in the image
<oSoMoN> sil2100, Iâve filed a landing request for the oxide fix, feel free to go ahead with the source copy
<sil2100> oSoMoN: o/ thanks! Let me assign and do that indeed
<bfiller> sil2100: can you create a silo for line 63 when you have a chance please? thanks
<sil2100> bfiller: sure thing, will be assigning silos in a moment :)
<sil2100> brendand: just checked, and none seem to be seeded in our images
<brendand> sil2100, good so landing it can do no harm then
<jgdx> psivaa, hey, how'd it go?
<psivaa> jgdx: just came back from lunch, will have a chat with fginther
<jgdx> psivaa, great
<fginther> psivaa, jgdx, I think we can try the same fix as last week. Working with someone to get it tested
<psivaa> fginther: thanks
<brendand> sil2100, is there anything i need to do?
<sil2100> brendand: hm, currently not, I'll be thinking how to release this in a moment, since I don't want to mix up the 'click' release process with the normal ubuntu one and make a mess in trunk
<sil2100> hmmm
<sil2100> Crap...
<sil2100> Come to think of it, we'll need to re-package the oxide-qt source with a different version number for ubuntu-rtm ;/
 * sil2100 does that now
<sil2100> hm, or maybe since it builds for utopic, maybe a binary copy would be sufficient?
<oSoMoN>  sil2100: Iâd be tempted to think so, letâs ask chrisccoulson for confirmation ^^
<sil2100> This would save us A LOT of work, and we could instantly check if that's true on an ubuntu-rtm device
<wgrant> cjwatson: Thanks.
<sil2100> oSoMoN, chrisccoulson: let's try this, I'm pretty sure that since we used binary-copies previously, the dependencies didn't change much in the meantime to make this impossible
<sil2100> We can rebuild by source copy if it's broken or something
<cjwatson> sil2100: Seems likely
<cjwatson> And would be nice to avoid big rebuilds
<jgdx> fginther, thanks!
<sil2100> brendand: just to make sure - the same reminders-app tests fail on vivid, right?
<ogra_> no
<ogra_> on rtm
<ogra_> oh, ignore me :P
<sil2100> ogra_: btw. I was supposed to go to practice today, but I seem to have a slight fever an will be skipping that, so I'll be around for the meeting
<sil2100> (most probably)
<sil2100> ogra_: if this changes, I'll give you a sign
<ogra_> sil2100, oki
<jibel> sil2100, silo 11 is the fix for bug 1393410 ?
<ubot5> bug 1393410 in unity-scope-click (Ubuntu RTM) "[TOPBLOCKER] Apps with prices are not shown by default" [Critical,In progress] https://launchpad.net/bugs/1393410
<sil2100> jibel: yes
<jibel> sil2100, ok, rhuddie ^ can you test it
<rhuddie> jibel, ok, starting silo 11
<sil2100> jibel, om26er: how's the custom tarball testing going?
<om26er> sil2100, I told cwayne1 that unity8-dash crashes the first time I try to open a scope from 'Manage scope' --> 'All'
<sil2100> ugh
<sil2100> :<
<om26er> logs are useless https://errors.ubuntu.com/oops/9f6e4d6a-6f3a-11e4-a1d2-fa163e525ba7
<cwayne1> huh? i wasn't aware of that
<cwayne1> let me try a fresh flash
<brendand> sil2100, yes it does fail in vivid
<cwayne1> om26er: which scope?
<ogra_> chrisccoulson, was oxide already released upstream ?
<om26er> cwayne1, BBC News
<cwayne1> this is the first i'm hearing of this btw
<cwayne1> but doing a fresh flash now, will check
<cwayne1> om26er: can you reproduce this reliably?
<om26er> cwayne1, yes, reproduced 4 times, right now it has crashed again.
<om26er> Well it could be that its not related to the custom tarball, would need to check.
<cwayne1> i don't see how it could be to be honest
<cwayne1> especially since bbc scope hasn't changed in over a month..
<cwayne1> and I cannot reproduce on a fresh flash
<om26er> cwayne1, here is the way: open bbc scope, scroll to the bottom. now flick so that it scrolls back to the top, tap on the back button twice.
<cwayne1> om26er: can't reproduce
<rvr> om26er: Just opened "Manage scopes" ... no crash
<kgunn> om26er: so are you seeing unity8 crash files in /var/crash ?
<cwayne1> om26er: yeah so, a) can't reproduce, b) that scope certainly hasn't changed
<om26er> kgunn, yes, but its useless. http://errors.ubuntu.com/oops/7778a022-6f3e-11e4-bd6f-fa163e78b027
<victorp> cwayne1, what sope?
<victorp> scope
<om26er> cwayne1, ok lets just assume its an old issue then.
<cwayne1> so it seems unlikely that this has anything to do with custom
<cwayne1> victorp: bbc
<kgunn> Saviq: if om26er is seeing a crashing dash is there anything else he could do (load debug libs or gdb)
<victorp> ugh..
<victorp> yeah nothing changed there
<rvr> cwayne1: I can't reproduce that in the Spanish image
<cwayne1> yeah, bbc hasn't changed in months
<cwayne1> rvr: yeah, i can't reproduce here in english
<rvr> Ah, just did
<rvr> om26er: But scrolling very very quickly
<jdstrand> I'm sure this is probably unrelated, but Istarted seeing several scopes using translated entries for description, searchhint and displayname in the store. these were queued up and they are now available. I mention it only because the timing seems odd
<om26er> a flick that is.
<victorp> om26er, but what crashes?
<victorp> unity8?
<rvr> _usr_bin_unity8-dash.32011.crash
<om26er> victorp, unity8-dash
<jdstrand> (they were previously blocked because click-reviewers-tools was complaining, but I fixed that and let them go in. it was just a few scopes though
<victorp> om26er, you know that there is a bug reported that unity8-dash crashes sometimes when switching scopes rights?
<victorp> right?
<pmcgowan> https://bugs.launchpad.net/barajas/+bug/1386638
<ubot5> Error: launchpad bug 1386638 not found
<victorp> om26er, rvr ^^
<victorp> so, I am not sure we should be blocking the new custom on this
<om26er> victorp, no, didn't know about that one. but this crash is different and yes as cwayne1 said it may not be related to this custom tarball.
<victorp> om26er, so let raise a bug and move on with custom testing so we can release the new image?
<om26er> victorp, sure, the testing is mostly done.
<jibel> rvr, while om26er is finishing the review of the custom tarball if everything looks ok on your side can you reflash latest proposed and try to reproduce.
<brendand> sil2100, did you do that landing already?
<rvr> jibel: When I'm finished with the current image, I'll do that
<sil2100> brendand: had a meeting, but doing the landings now :)
<brendand> sil2100, it might not be necessary, just hold on
<sil2100> brendand: k, landings are prepared if anything
<sil2100> brendand: should I assign..?
<om26er> cwayne1, I tap on 'Add google account' it actually opens the system settings app and then I have to select account type there. Same for evernote. Is that supposed to be like that
<pstolowski> trainguards, hello, can i ask for a silo for #61, #60, #55 (in that order of priority)?
<ogra_> sil2100, just finishing up another meeting .. i'll be there in 5
<sil2100> pstolowski: hey, tried assigning for 61/60 but there's already a landing for -scopes-api
<sil2100> ogra_: k
<pstolowski> sil2100, where is it? i couldn't find it
<robru> pstolowski: http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=scopes-api
<pstolowski> robru, ah, but that one is for testing purposes atm. kgunn is that right?
<robru> pstolowski: yeah seems so
<robru> pstolowski: sil2100: I'll assign it
<robru> well as soon as the spreadsheet wakes up
<pstolowski> heh, thanks
<robru> pstolowski: ok vivid 25 for starters
<robru> pstolowski: and rtm 6
<pstolowski> robru, thanks!
<robru> pstolowski: and vivid 26 for line 55. you're welcome!
<kgunn> robru: you can dump me outta that silo 18
<robru> kgunn: thanks
<sil2100> robru: btw.! Did you do anything to fix the dashboard? Since it seems to work fine now
<robru> sil2100: nope I didn't do a thing. must have been some kind of transient google issue
 * sil2100 curses google
<robru> sil2100: yeah it was pretty awful. I looked over the code, looked over the spreadsheet, couldn't find a single thing wrong. Even tried downloading the CSV from the spreadsheet to see if google was giving incomplete info. everything looked fine. then suddenly it fixed itself
<sil2100> ogra_: btw. next time let's make sure that the landing has a big DO NOT LAND THIS! in the landing comments
<sil2100> I'm sure Timo would have noticed it then :)
<brendand> sil2100, i guess we should do the landing
<brendand> sil2100, theoretically i could hack the tests to work with the old version in the archive, but probably better to move forward than backwards
<brendand> sil2100, will you do the landing for both vivid and RTM
<brendand> ?
<sil2100> brendand: sure, let me assign a silo for those then - I'll first build the vivid one and then build the sync for ubuntu-rtm
<ogra_> sil2100, importer is off, rootfs build started ... cwayne1 is currently putting the tarballs in place
<sil2100> \o/
<imgbot> === trainguards: RTM IMAGE 163 building (started: 20141118 18:15) ===
<sil2100> ogra_, cwayne1: thanks!
<cwayne1> wait i haven't pushed yet! see the discussion in #phablet
<sil2100> cwayne1: ok, I see the issue... since QA says it won't pass sanity testing, then it means we need this fix
<sil2100> ogra_: you kicked a new image anyway, right..?
<sil2100> This probably can't be stopped? :|
<sil2100> We could have an image anyway, but this needs to be fixed for this milestone anyway
<ogra_> right
<ogra_> freeze is only tomorrow morning :)
<ogra_> pleanty of time
<cwayne1> oh man i thought today was wednesday
<ogra_> :)
<brendand> sil2100, silo 11 signed off. make sure it's in tonights image
<sil2100> brendand: o/
 * ogra_ watches https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu-rtm/14.09/ubuntu-touch/ and twiddles thumbs
<sil2100> Let's publish that in a few moments, don't want to partially land it in the image we're building now
<ogra_> i dont mind doing a back to back build if needed
<alecu> brendand: thanks for the review
<imgbot> === trainguards: RTM IMAGE 163 DONE (finished: 20141118 19:35) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/163.changes ===
<ogra_> brendand, do you immediately want one on top ?
<ogra_> hmm, no notification yet ...
<brendand> ogra_, umm yeah it would be good to have the paid apps change in the image we test
<ogra_> ok, i'll trigger a new one
<ogra_> probably my phone decides to notify me about that one then :P
<oSoMoN> trainguards: IÂ need a reconfigure of RTM silo 3, IÂ added a webbrowser-app MR to it (required to fix a regression in autopilot tests with oxide 1.3)
<robru> oSoMoN: done
<oSoMoN> robru, thanks!
<robru> oSoMoN: you're welcome!
<imgbot> === trainguards: RTM IMAGE 164 building (started: 20141118 19:55) ===
<ogra_> hmpf
<ogra_> that first boot didnt take 10 but surely 4 minutes :/
<cwayne1> hrm
<cwayne1> did it actually copy over the caches?
<ogra_> geez ... all that stuff on the home scope now ...
<cwayne1> just first boot
<cwayne1> OOBE :)
<ogra_> yeah
<oSoMoN> robru, can you advise on what failed here? https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-003-1-build/96/console
<robru> oSoMoN: well the upload failed. I don't have access to the rejection message but cjwatson might be able to look that up for you if he's around.
<robru> oSoMoN: might be worth trying again, we had a transient upload failure yesterday
<robru> oSoMoN: wgrant might also be able to help. but yeah just retry the job for now
<robru> brb, lunc
<robru> lunch
<oSoMoN> robru, ok, thanks (and enjoy the lunch)
<cjwatson> 2014-11-18 19:56:16 DEBUG   Rejected:
<cjwatson> 2014-11-18 19:56:16 DEBUG   PPA exceeded its size limit (2303.00 of 2048.00 MiB). Ask a question in https://answers.launchpad.net/soyuz/ if you need more space.
<cjwatson> robru,oSoMoN: ^-
<cjwatson> let me fix that for you
<cjwatson> robru,oSoMoN: ok, retry please
<oSoMoN> cjwatson, thanks, itâs now building in the PPA (I hadnât checked the size of the PPA)
<oSoMoN> this one keeps biting us everytime we put oxide in a silo
<cjwatson> roll on ephemeral PPAs which we might be able to have sensible per-package configuration for
<wgrant> What on earth are you building that exceeds 2GB in a silo?
<cjwatson> wgrant: $ grep-aptavail -XS oxide-qt -nsSize | numsum
<cjwatson> 1178574260
<cjwatson> and that's just one arch
<cjwatson> oh, wait, that's twice what it should be because two versions in my apt cache, but still
<cjwatson> oxideqt-dbg is half a gig
<wgrant> Oh, -dbg, of course.
<imgbot> === trainguards: RTM IMAGE 164 DONE (finished: 20141118 21:05) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/164.changes ===
<popey> \o/
<tedg> trainguards, can I get silos for lines 69/70 please?
<popey> does #164 add payments?
<tedg> popey, If you wire your money directly to me we can work something out.
<popey> ;D
<popey>  * Enable purchases by default (LP: #1393410)
<ubot5> Launchpad bug 1393410 in unity-scope-click (Ubuntu) "[TOPBLOCKER] Apps with prices are not shown by default" [Critical,In progress] https://launchpad.net/bugs/1393410
<popey> looks that way
<robru> tedg: rtm 13 and vivid 7
<tedg> robru, Great, thanks!
<robru> tedg: you're welcome
<ahayzen> Hey, where do the latest rtm ci results appear, the latest i can see is #134 http://ci.ubuntu.com/smokeng/utopic/touch_stable/ ?
<ToyKeeper> cwayne1: Could you provide info on getting the custom tarball installed?  I'm having trouble finding info on it.
<ToyKeeper> cwayne1: Nevermind, looks like you already answered.  :)
<cwayne1> ToyKeeper: :)  i'd have put more info and mailed you, but i didn't know who'd be doing the testing (or when)
<jgdx> fginther, psivaa, hey, any progress on the uss ci? :)
<fginther> jgdx, yep. Performed another update and the tests are passing again - https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-vivid/156/
<fginther> jgdx, I've also requested that we automate the update process to better avoid this problem in the future
<jgdx> fginther, awesome, thanks. So the update is the cause of all this?
<fginther> jgdx, it's the 'lack' of an update. The test environment is base on a daily iso that appears to be getting stale very quickly.
<jgdx> fginther, right. Is it possible to follow the request you made somewhere? RT?
<fginther> jgdx, I added it to our backlog, I'll send you a link
<jgdx> fginther, thanks!
#ubuntu-ci-eng 2014-11-19
<imgbot> === trainguards: IMAGE 26 building (started: 20141119 02:05) ===
<imgbot> === trainguards: IMAGE 26 DONE (finished: 20141119 03:30) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/26.changes ===
<Mirv> morning here too
<Mirv> why, certainly
<zsombi> cihelp: need clarification on this https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-mako/6140/console
<zsombi> cihelp: seems there are package conflicts there?
<Mirv> cihelp: ^ to zsombi's request, the error looks like if a vivid rootfs (qt 5.3.2) would try to install utopic UITK packages (compiled against qt 5.3.0)
<robru> cjwatson: infinity: around? what's the correct value to pass to 'pbuilder create --mirror _____' if I want to create an rtm chroot?
<Mirv> is the dashboard down?
<Mirv> I mean the jenkins one
<sil2100> Seems to work here
<cjwatson> robru,infinity: the URL is http://derived.archive.canonical.com/ubuntu-rtm/, but that won't quite help because debootstrap doesn't understand 14.09.  It's probably simplest to create a chroot with something uniformly older (say, trusty), flip sources.list over, and upgrade; or grab the chroots from Launchpad ("manage-chroot -d ubuntu-rtm -s 14.09 -a amd64 get", from lp:ubuntu-archive-tools) and use those as a starting point.
<cjwatson> Might even be possible to do the latter directly with sbuild using StÃ©phane's sbuild-launchpad-chroot gadget.
<cjwatson> Oh, FYI folks, "devel" now works in PPAs; no need to edit sources.list any more after using add-apt-repository.
<sil2100> jibel: hey! Do you know if the new custom tarball has been picked up for testing yesterday night?
<sil2100> Oh, wait, I see it did
<sil2100> jibel: nvm!
<jibel> sil2100, it's in 165, isn't it?
<sil2100> Right
<jibel> sil2100, we didn't test 165 yet
<jibel> we'll do it this morning
<Mirv> cjwatson: great! for the 'devel' working.
<sil2100> Looking good so far, we seem to be missing only 2 topblocker fixes right now, both having fixes ready
<sil2100> jibel: do you have someone that could take a look at rtm silo 11?
<oSoMoN> sil2100, FYI, my testing of oxide 1.3 (in silo 3) is complete and good, dbarth is still testing webapps a bit more extensively, but it looks like we should be ready to land it soon
<pmcgowan> nice
<sil2100> oSoMoN: \o/
<popey> Mirv: when you get a moment could you please upload calendar to the store (note, it's not in the rtm image so it's not covered by freezes) http://s-jenkins.ubuntu-ci:8080/job/calendar-app-click/lastSuccessfulBuild/artifact/generic-click-builder-utopic-armhf/output/com.ubuntu.calendar_0.4.549_all.click
<popey> Mirv: also sudoku pls. http://s-jenkins.ubuntu-ci:8080/job/sudoku-app-click/lastSuccessfulBuild/artifact/generic-click-builder-utopic-armhf/output/com.ubuntu.sudoku_1.1.319_all.click
<sil2100> john-mcaleely: ping
<sil2100> olli, pmcgowan: so, we're closing the landing gates now - all fixes for the listed topblockers either already landed or are in silos
<sil2100> olli, pmcgowan: actually, only 2 topblockers are left and both have fixes in silos
* sil2100 changed the topic of #ubuntu-ci-eng to: Need a silo? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: RTM Archive frozen (no new silos landing) ! RTM cron builds disabled
<Mirv> popey: calendar and sudoku uploaded
<popey> thanks Mirv
<sil2100> john-mcaleely: re-ping
<sil2100> john-mcaleely: we would need a device tarball generated from silo 11 for QA to start testing
<ogra_> sil2100, OH !
<ogra_> sil2100, did you notice silo 13 ?
<ogra_> (that is the "UI freezes randomly" topblocker)
<ogra_> (not marked as such ... bad tedg )
<olli> sil2100, good job!
<sil2100> ogra_: oh my, well - it's targetted for the next milestone anyway ;)
<sil2100> I wouldn't try forcefully pushing it in here
<ogra_> sil2100, well,if we have spare QA capacity i dont think a week more testing would be bad
<jibel> sil2100, rvr will review silo 3 and rhuddie silo 11 when it's ready
<ogra_> it is *very* intrusive
<rvr> ogra_: sil2100: I noticed
<rvr> The changelog is huge
<sil2100> True, actually, if john-mcaleely won't pop up pretty soon we might ask for testing this silo now
<ogra_> yes
<sil2100> Since without him it might be troublesome to test 11 anyways...
<rvr> Ooops, I'm talking about silo 3
<ogra_> heh
<sil2100> rvr: ok, that's a different story ;) silo 3 is a new oxide, and that's always huuuge
<rvr> sil2100: ogra_: Silo 3 contains an update to oxide, is that known? ... Ok
<ogra_> yes
<ogra_> known and wanted
<rvr> Ack
<ogra_> (and dont dare to find any problems, rebuilding ocide will take a month at least :P )
<ogra_> *oxide
<pmcgowan> sil2100, so whats left
<ogra_> pmcgowan, tons of new bugs with the OOBE here for me
<ogra_> i just hung the dash hard
<ogra_> and i can repro
<ogra_> sigh
<pmcgowan> ogra_, you mean the wizard or the new scopes stuff
<ogra_> new scopes
<pmcgowan> f***
<ogra_> going to the bottom of "today" ... then tapping "tell me more" at the button ... in the following page scrilling completely down and tapping "finished ... " gets me a hard hang of the dash
<ogra_> oh, wait ... this time it doesnt ... it instead crashed the dash
<sil2100> WTH
<ogra_> the OOBE as a whole kind of trashes the whole experience IMHO ... it makes it feel very unfinished (but thats personal opinion, not a bug)
<victorp> ogra_, sorry but that is just not true...
<victorp> just because that is the first time you see that bug, doesnt mean is the OOBE
<ogra_> victorp, heh, well, thats my user impression
<ogra_> the way we scatter buttons everywhere
<victorp> ogra_, I meant = tons of new bugs with the OOBE here for me
<ogra_> the way you can not easily find a way to disable it
<ogra_> plus the new bugs
<victorp> a scope can *not* hang the dash
<ogra_> (fitbit doesnt work anymore, reproducable crash ... and we havent looked deeper yet, i'm sure there will be more stuff bubbling up)
<ogra_> victorp, well, i can reliably hang or crash it using the very bottom button on the hints page
<ogra_> the blue one
<victorp> ogra_ ok.. let take it out, so then you can not reliably reproduce the bug!
<ogra_> victorp, no, lets get it fixed ...
<victorp> ogra_, but you know what I mean.. the scope is just using the fw.. if it hangs is a bug in the framework that was there before
<victorp> and other scopes will hit
<victorp> btw, what button. I will try to reproduce
<ogra_> i have not seen the dash crash in a month now
<ogra_> and i use plenty of scopes regulary
<ogra_> now we have one action that makes it hang hard
<victorp> ogra_, you must not be using scopes much ;P I have seen it crash a fair amount
<ogra_> and it is one that is very exposed in our default scope
<victorp> ogra_, sure, so lets fix it
<victorp> but, can you tell me how to reproduce please :)
<ogra_> <ogra_> going to the bottom of "today" ... then tapping "tell me more" at the button ... in the following page scrolling completely down and tapping "finished ... " gets me a hard hang of the dash
<victorp> yeap hanging for me too
<ogra_> every second or third time i get a complete dash restart (showing the "scopes" splash)
<victorp> interesting...
<ogra_> victorp, there seems to also be an issue with accounts integration ... (like ther eis none)
<victorp> ogra_, ?
<pete-woods> ogra_: I can confirm I get this hang
<ogra_> wait for seb128 to return ... seems fitbit ids completely gone for him
<pete-woods> also :(
<victorp> oh, wierd.. it doesnt hang on nexus4 but it hangs in krillin
<ogra_> i cant repro that since i dont have a fitbit account (or device)
<victorp> ogra_, ok but that is not related to this bug or the changes we landed
<pete-woods> ogra_: while you're here, had a low level question. according to /proc/cpuinfo the krillin has 1 CPU core, however it has 4 afaik. is /proc just lying to us / are we using only 1 CPU?
<ogra_> pete-woods, compile a kernel and look again while the compiler runs ;)
<ogra_> they are dynamically offlined if not in use
<victorp> ogra_, what worries me is that krillin is  behaving differently to n4 at scope level..
<pete-woods> ah, cool. that's good to know :)
<ogra_> victorp, yeah
<sil2100> ogra_, pmcgowan: does anyone of you know if john-mcaleely will be around today?
<sil2100> We'll have to give some other instructions to QA if not
<ogra_> i dont ...
<pmcgowan> let me check
<john-mcaleely> sil2100, I appear to be here
<pmcgowan> yes he is
<ogra_> but pmcgowan should be able to shout through the office :)
<sil2100> Oh!
<sil2100> :)
<john-mcaleely> sil2100, just a little late
<pete-woods> victorp, ogra_: FYI https://bugs.launchpad.net/ubuntu/+source/unity-scopes-shell/+bug/1394155
<ubot5> Launchpad bug 1394155 in unity-scopes-shell (Ubuntu) "Deadlock / crash of the dash possible through Today scope" [Undecided,New]
<john-mcaleely> sil2100, it appears you need a device tarball for the rtm release?
<ogra_> pete-woods, confrimed
<ogra_> john-mcaleely, with a new initrd ...
<sil2100> john-mcaleely: ping pong then! We have silo 11 which we would need a device tarball from for krillin, with a new initrd
<ogra_> john-mcaleely, wehere does the krillin build pull that from ?
<john-mcaleely> ogra_, and new pngs, and some changes to system-image-update, by the looks
<sil2100> john-mcaleely: comment says this: "Needs a device tarball for krillin, john-mcaleely will generate a new one (please ping him if not yet available when you start testing this)"
<pete-woods> victorp: also, we have seen different behaviour on the two platforms before. I think the QML caching / preloading thing differs between them at very least
<john-mcaleely> ogra_, from a private gerrit. rsalveti appears to have pushed all the merge proposals we need
<ogra_> perfect
<victorp> pete-woods,  not sure is related
<ogra_> thats what ii wanted to make sure :)
<victorp> Got scope URI "scope://com.canonical.scopes.dashboard_dashboard?q=start"
<victorp> QObject: Cannot create children for a parent that is in a different thread.
<victorp> (Parent is QNetworkAccessManager(0x20ae87c), parent's thread is QThread(0x1f53500), current thread is QThread(0x20aa888)
<victorp> pete-woods, ^^
<john-mcaleely> sil2100, ack. if it's ok, I'd like to be thorough here, so that might take a couple of hours
<john-mcaleely> sil2100, if you want it quicker, it can be done quicker
<john-mcaleely> ogra_, I'm building the first set now
<pete-woods> victorp: I have seen that before, and have a fix. have just tried this with that fix applied and it still happens
<ogra_> victorp, lol ... that might be the just demoted QNetworkAccessManager bug ... we should probably push it back to topblocker
<pete-woods> ogra_: no, it's a bug in the GeoIP code in the shell
<ogra_> oh, ok
<sil2100> john-mcaleely: how many couple of hours that would take approximately?
<john-mcaleely> sil2100, (conservative eta, considering I want to do a master build first, and a test pass) 2pm UK. 2.5 hrs from now
<john-mcaleely> sil2100, quickest you can have an untested (ie, rely on rsalveti's testing) device tarball: 30 mins
<sil2100> I would prefer we do it safe, even if it takes longer
<sil2100> john-mcaleely: so proceed with the standard approach, we'll simply have the promotion candidate a bit later
<sil2100> ogra_: and this basically means we might have time for the silo 13
<john-mcaleely> sil2100, ack
<john-mcaleely> sil2100, will keep you updated
<sil2100> jibel: hey! I think we'll also try including the fix from silo 13 - it's a fix for a topblocker from the next milestone
<jibel> sil2100, it's ready to test?
<sil2100> jibel: at least tedg maked it as ready for testing
<jibel> sil2100, okay, we can pick 13 one until we have a new device tarball for 11
<jibel> rhuddie, since we won't be able to test 11 before 2 to 3 hours can you take 13 instead?
<sil2100> I suppose silo 13 needs some additional testing as the change is bigger and it's a very high-risk component
<sil2100> jibel: thanks!
<jibel> rhuddie, then omer will join and pick 11 if you are not done with 13
<rhuddie> jibel, sil2100, ok, I'll look at 13 now
<sil2100> rhuddie: thanks :)
<ogra_> sil2100, john-mcaleely, we can start testing without the device tarball and later to atomic testing for only this landing i think
<ogra_> jibel, ^^ (about silo 11)
<ogra_> s/to/do/
<jibel> ogra_, anyway we cannot test 11 and 13 simultaneously. We'll start by 13 which is ready and test 11 when the tarball is available.
<ogra_> yeah
<sil2100> ogra_: later I might take a half-day sick-day, don't feel too well so I might just go lay down for a while
<ogra_> sil2100, thats fine, get some rest
<john-mcaleely> ogra_, sil2100 so the device build passed some initial smoke tests, so I've kicked off an official build. on track so far
<sil2100> john-mcaleely: great news :)
<ogra_> john-mcaleely, awesome
<seb128> bah
<seb128> I had a few boots today where the apps view in the dash takes like > 10s to load the top icons
<seb128> like the phone/messages/browser etc ones
<ogra_> slow network ?
<seb128> could be I guess, but for sure those are not coming from the internet?
<ogra_> they get checked for new content afaik
<ogra_> bug 1357321 might be related
<ubot5> bug 1357321 in qtbase-opensource-src (Ubuntu) "QNetworkAccessManager doesn't support roaming on Ubuntu" [Critical,In progress] https://launchpad.net/bugs/1357321
<ogra_> (only remotely ... though since it shows the same breakage if you switch networks )
<sil2100> I saw something similar today as well, but I don't switch networks
<sil2100> Only one AP and only WiFi enabled
<ogra_> right, the bug just shows that the icons depend on networking .. thats what i wanted to point out
<popey> can someone put more coal in ci.ubuntu.com/smokeng/utopic/ ?
<popey> it's like swimming in treacle
<ogra_> it just wants you to stop looking at old utopic results :P
<sil2100> jibel: I just CCed you to the new custom tarball changelog
<sil2100> jibel: can you have someone from your team looking at it? It's removing some of the troublesome changes from the tarball
<sil2100> So it basically has only reverts
<ogra_> well
<ogra_> but not everything is reverted
<ogra_> which means th remainders need some special attention
<ogra_> (to make sure they still work even with the other bits removed)
<cwayne1> right, so really just some exploratory testing on the aggregators specifically
<sil2100> Right
<sil2100> That's why we need QA sign-off
<cwayne1> yep
<cwayne1> well, we always need QA sign-off for custom :)
 * cwayne1 is glad he starts working early in the morning so he could get this to QA in time
<sil2100> jibel: ^ :)
<jibel> sil2100, yup, on it
 * cwayne1 just verified the fix in 14.09-proposed-customized and 14.09.es-proposed-customized
<sil2100> Thank you!
<john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20141119-db417fa.tar.xz
<john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20141119-db417fa.changes
<john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-testresults-20141119-db417fa.ods
<john-mcaleely> sil2100, ogra_ jibel ^ new device tarball for rtm and also silo 11
<ogra_> yay, its all rolling in :)
<john-mcaleely> vivid tarball to follow in a while
<john-mcaleely> rsalveti, (fyi) ^
<ogra_> yeah, landed already in vivid anyway
<jibel> om26er, ^^ can you take silo 11?
<john-mcaleely> ogra_, not as a krillin tarball :-)
<ogra_> (just not krillin vivid)
<john-mcaleely> :-)
<ogra_> :)
<sil2100> \o/
<sil2100> Rockin'!
<sil2100> We're lacking QA people now actually!
<sil2100> ;)
<john-mcaleely> heh
<ogra_> yup, as expected
<om26er> jibel, sure.
<om26er> that looks like a dangerous bug to test.
<ogra_> heh
<jibel> om26er, it is, you're lucky.
<ogra_> there is some test script (or description) in the bug though
<sil2100> om26er: feel free to poke people if you have any problems with that one, since the bug itself is a bit 'tricky'
<jibel> sil2100, don't add more topblockers to wave1 and it'll be okay :)
<sil2100> hah ;)
<sil2100> No more, we promise! But this way, we basically have no topblockers for wave2 now
<sil2100> So this means we can concentrate on image quality
<ogra_> jibel, you mean we should stop the meeting where we invent them right now ?
<jibel> sil2100, heh, no topblockers for wave2? I'm pretty sure the bucket will be full again
<ogra_> yeah, we are good at inventing them ;)
<sil2100> ;)
<om26er> sil2100, ogra_ How do I install the android part ?
<ogra_> om26er, ubuntu-device-flash has an option for that ... john-mcaleely is more familiar with this than i am
<john-mcaleely> om26er,
<ogra_> you just need the tar,xz locally and point an option to it though
<john-mcaleely> ubuntu-device-flash touch --channel ubuntu-touch/ubuntu-rtm/14.09-proposed --bootstrap --device-tarball path/to/downloaded/device_krillin-xx.tar.xz
<john-mcaleely> om26er, ^
<john-mcaleely> (you can vary --channel if you need to, of course. add --revision N at the start if you need
<john-mcaleely> )
<om26er> john-mcaleely, in case of silo 11 here: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-011/+packages
<om26er> is android_20141117-0039.orig.tar.xz the right file ?
<john-mcaleely> om26er, no
<john-mcaleely> om26er, this is the file you need
<john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20141119-db417fa.tar.xz
<john-mcaleely> for *krillin*
<john-mcaleely> om26er, ^
<om26er> john-mcaleely, alright, thanks. downloading.
<john-mcaleely> om26er, :-)
<ogra_> om26er, and ignore the PPA it only has the raw input files for this
<om26er> ogra_, ok, so I don't need initramfs-tools-ubuntu-touch - 0.80 from there ?
<ogra_> no, thats already inside your tarball
<om26er> cool.
<jibel> sil2100, I flashed customized en, and there is no keyboard in the wizard to type my wifi key
<ogra_> bah
<ogra_> wasnt that fixed like three promotions ago ?
<ogra_> cwayne1, ^^^^
<jibel> hm, there is some weird here. cancel and select the network again and the keyboard appears
<cwayne1> hm? that's got nothing to do with custom...
<ogra_> is the base image in that channel actually recent ?
<cwayne1> it's the latest rootfs
<pmcgowan> are silos 3 and 13 intended to land today?
<ogra_> yeah, looks like
<pmcgowan> great
<ogra_> pmcgowan, yes
<jibel> pmcgowan, they are. ETA for QA sign off 1 hour or so
<pmcgowan> thanks
<ogra_> pmcgowan, 11 too
<ogra_> and the custom traball rollback
<pmcgowan> ah right
<jibel> ogra_, I'm reflashing, I'm wondering if it's the problem with dbus going crazy when you boot the device and it's connected.
<ogra_> yeah, that could be
<ogra_> try without cable :)
<jibel> works fine on second try and without cable
<sil2100> pmcgowan: they're in the queue right now
<ogra_> silo16 would amke it go away :)
<ogra_> *make
<sil2100> pmcgowan: anyway, we now wait for silo 3, 11 and 13 to land, then we can kick the promotion candidate
<ogra_> but thats not due to land currently
<pmcgowan> sil2100, awesome
<pmcgowan> ogra_, btw seeing some bad dbus stuff here all week
<pmcgowan> about to file a new bug
<ogra_> pmcgowan, different from "eats your CPU when cable attached" ?
<ogra_> (that is what rtm 16 would fix)
<pmcgowan> yes, eats cpu without cable attached
<pmcgowan> ogra_, just grab some stuff, its network manager AP changes
<sil2100> pmcgowan: is it eating up CPU badly?
<pmcgowan> yes, this is mako
<pmcgowan> will file a bug
 * ogra_ recommends mayonnaise or mustard :)
<sil2100> It might be the dbus-CPU issue that we know of, that tvoss is still trying to find (as it's really hard to reproduce)
<ogra_> right
<ogra_> but we also have the upower induced one ... though that onyl shows if the device is on cable
<ogra_> bug 1337200 is fallout of that afaik
<ubot5> bug 1337200 in ubuntu-system-settings (Ubuntu) "High CPU due to excessive device changed signals from upower" [High,In progress] https://launchpad.net/bugs/1337200
<om26er> rsalveti, Hi! how do I verify the fix for bug 1387214 ? I don't seem to find anything clear in the bug report.
<ubot5> bug 1387214 in initramfs-tools-ubuntu-touch (Ubuntu RTM) "[TOPBLOCKER] file corruption on touch images in rw portions of the filesystem" [Critical,In progress] https://launchpad.net/bugs/1387214
<rsalveti> om26er: added that to the spreadsheet, 1 sec
<rsalveti> om26er: http://paste.ubuntu.com/9096495/
<om26er> rsalveti, and How do I finally check if corruption happened or not ?
<rsalveti> om26er: after validating the image, you can reproduce by using the test script described by the bug
<rsalveti> om26er: http://paste.ubuntu.com/9096553/
<rsalveti> that will start the script in a loop, let it running for a few iterations
<om26er> rsalveti, do I need to run that script after each validation step or after running all the steps ?
<rsalveti> om26er: after running all the steps
 * sil2100 goes lay down for some moments
<om26er> ack
<sil2100> ogra_: in case I oversleep, I leave you in charge of teh meeting :) Thanks!
<ogra_> np
<om26er> rsalveti, last question: should I *not* wipe the device after the first step i.e. --bootstrap with new device tarball. ?
<rsalveti> om26er: doesn't matter
<rsalveti> john-mcaleely: thanks for creating the tarball
<john-mcaleely> rsalveti, yw
<rhuddie> jibel, I am finishing silo 13, no issues found
* plars changed the topic of #ubuntu-ci-eng to: Need a silo? ping trainguards | Need help with something else? ping plars | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: RTM Archive frozen (no new silos landing) ! RTM cron builds disabled
<jibel> rvr, are you done with silo 3
<jibel> ?
<rvr> jibel: Only one test left, 5 minutes and done
<rvr> jibel: Finished
<ogra_> passed ?
<rvr> popey: New Music app introduced untranslated strings
<rvr> ogra_: Yes, passed
<ogra_> yay
<oSoMoN> trainguards: RTM silo 3 just got approval from QA, can we publish?
<ogra_> indeed
<Mirv> oSoMoN: sure
<Mirv> oSoMoN: so it was deemed that binary copy of utopic build is fine for rtm?
<Mirv> well sil2100 did that, so I assume yes
<ogra_> yup, i think that was the plan
<Mirv> trello looks good
<ogra_> Mirv, 13 is good to go as well
<Mirv> ok then
<Mirv> ogra_: 13 is approved but from earlier today has "
<Mirv> Blocked for this week because it's topblocker but approved for Wave 2.
<ogra_> Mirv, we dont mind extra enduser testing :)
<ogra_> not sure who put that in place
<ogra_> definitely not what we discussed
<Mirv> ogra_: rvr wrote that.
<ogra_> well, if it passed, let it in
<Mirv> then 44 mins ago rhuddie wrote that it's tested
<Mirv> ogra_: my understanding kind of was that wave 2 is not supposed to go in before next week or such, maybe deemed as risky and promotion wanted without first?
<rvr> Mirv: Yes, I wrote that in trello this morning. But jibel told us later that it was approved for this wave.
<ogra_> Mirv, no
<Mirv> I might be wrong, but I'd like to be pointed to be wrong :)
<Mirv> rvr: ok then
<Mirv> rvr: ogra_: that part was simply not written in there.
<ogra_> the waves are recommendations to give the "hard" bugs more time
<ogra_> not mandatory ... if it is ready., let it in
<ogra_> point people to me iff they complain ;)
 * Mirv the gatekeeper
<Mirv> 013 published too
<ogra_> cool
<ogra_> so we arre waiting for 11 and the custom tarball
<cwayne1> jibel: any eta on the custom tars?  ive been testing english + spanish here and looks good
<popey> rvr: oh? ahayzen ^^
<om26er> rsalveti, does the script keep on running forever ? It has rebooted for like 6 times already.
<rsalveti> om26er: yeah
<rsalveti> then it means it worked for 6 times
<om26er> rsalveti, so how do we conclude the results ?
<jibel> cwayne1, english is ok. waiting for rvr for spanish
<rvr> cwayne1: jibel: Flashing the phone
<rsalveti> om26er: let it running for at least 10 times
<cwayne1> rvr: jibel: cool, ill wait til theyre both +1'd to push it
<rsalveti> om26er: then just abort, which means it worked fine
<rsalveti> om26er: without the changes I did it was breaking on the first run
<ahayzen> popey, hmmm? strange
<om26er> rsalveti, aha, then the fix is working, good.
<rvr> cwayne1: #8, right?
<cwayne1> rvr: yessir
<rvr> Ack
<cwayne1> rsalveti: that fix is for the corruption bug?
<rsalveti> cwayne1: yes
<rsalveti> more of a workaround for now
<cwayne1> \o/
<popey> rvr: can you provide more detail to ahayzen ?
<popey> or a bug
<rvr> popey: I filled a bug
<ahayzen> ...they look translatable ... http://bazaar.launchpad.net/~music-app-dev/music-app/remix/view/head:/common/SongsPage.qml#L283 http://bazaar.launchpad.net/~music-app-dev/music-app/remix/view/head:/common/SongsPage.qml#L309
<ahayzen> so either the pot is out of date or your language has just not been translated yet
<popey> right, so we need to get them translated and crank a new click
<ahayzen> popey, bug 1394265
<ubot5> bug 1394265 in Ubuntu Music App "Untranslated strings" [High,New] https://launchpad.net/bugs/1394265
<rvr> ahayzen: We are supposed to be in UI freeze, so no new strings :P
<rvr> https://translations.launchpad.net/music-app/utopic/+pots/music-app/es/+translate?batch=10&show=all&search=shuffle
<rvr> No "Shuffle" there
<ahayzen> I see it in the .pot http://bazaar.launchpad.net/~music-app-dev/music-app/remix/view/head:/po/com.ubuntu.music.pot#L142 http://bazaar.launchpad.net/~music-app-dev/music-app/remix/view/head:/po/com.ubuntu.music.pot#L146
<ahayzen> ah hang on that web UI maybe incorrect as it maybe showing lp:music-app/utopic :/
 * ahayzen wonders how you switch it to the other branch
<ahayzen> rvr, look at https://translations.launchpad.net/music-app/remix
<ahayzen> rvr, https://translations.launchpad.net/music-app/remix/+pots/music-app/es/+translate?start=0&batch=10&show=untranslated&field.alternative_language=&field.alternative_language-empty-marker=1&old_show=all
<Saviq> trainguards, I can has silo for line 79 please?
<rvr> ahayzen: I'll do that later
<ahayzen> rvr, thanks i'm checking with dpm but i think i know how to make that view default now
<om26er> rsalveti, you said the change affects write performance, does it also affect read performance ?
<ogra_> no
<ogra_> only write apparently
<ogra_> do you notice significant performance hits when using the device ?
<oSoMoN> trainguards: can I have a silo for line 81 (landing oxide 1.3.4 in vivid) ?
<oSoMoN> (please)
<rsalveti> om26er: no, it can actually improve read a bit
<om26er> rsalveti, after running those tests many of the apps fail to start
<om26er> weather, gallery, calculator etc..
<om26er> there is no crash file.
<ogra_> denials in syslog ?
<ogra_> iirc the test fiddles with apparmor stuff
<rsalveti> yeah, I'd recommend reflashing it after running this test specifically
<om26er> ogra_, no, none.
<ogra_> well, the test definitely has potential to break the install, so i agree with rsalveti
<om26er> ok, then.
<rsalveti> ogra_: john-mcaleely: did we publish the device tarball for vivid?
<ogra_> i guess john was waiting for the rtm results
<rsalveti> right, makes sense
<john-mcaleely> rsalveti, ogra_ I've also been distracted by other firedrills. so there is a tarball built officially, and i just need to smoketest it
<john-mcaleely> and then push it
<ogra_> yeah, no hurry
<alan_g> fginther: I've got what appears to be a problematic difference between Mir CI and Mir autolanding. Some tests fail in the latter, but not the former (bug 1394278). Is there a difference in setup that would cause "open("/dev/shm", O_TMPFILE | O_RDWR | O_EXCL, S_IRWXU);" to fail in the latter only?
<ubot5> bug 1394278 in Mir "[testsfail] Autolanding failure in MesaBufferAllocatorTest.software_buffers_dont_bypass ett alia" [Undecided,New] https://launchpad.net/bugs/1394278
<oSoMoN> trainguards: can I have a silo for line 81 (landing oxide 1.3.4 in vivid) pretty please ?
<robru> oSoMoN: vivid 17, do you need me to do the binary copy too?
<oSoMoN> robru, yes please, IÂ donât think I am allowed to do it myself
<robru> cjwatson: can you check why the upload to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/staging-000/+packages failed? got another one of these 'dput reports success, package never shows up, i don't get the rejection mail" things
<robru> oSoMoN: ok, binary copy requested. Once you see that in the PPA please do a WATCH_ONLY build
<oSoMoN> robru, thanks!
<robru> oSoMoN: you're welcome!
<cjwatson> 2014-11-19 17:19:12 DEBUG   Considering changefile ~ci-train-ppa-service/ubuntu/staging-000/ubuntu/ubuntu-app-launch_0.4+15.04.20141119-0ubuntu1_source.changes
<cjwatson> 2014-11-19 17:19:12 DEBUG   Launchpad failed to process the upload path '~ci-train-ppa-service/ubuntu/staging-000/ubuntu':
<cjwatson> 2014-11-19 17:19:12 DEBUG
<cjwatson> 2014-11-19 17:19:12 DEBUG   Could not find suite 'ubuntu'.
<cjwatson> robru: ^- looks like a dput configuration error - compare these two log lines:
<cjwatson> 2014-11-19 16:10:12 DEBUG   Considering changefile ~ci-train-ppa-service/ubuntu/landing-009/mir_0.9.0+15.04.20141119.1-0ubuntu1_source.changes
<cjwatson> 2014-11-19 17:19:12 DEBUG   Considering changefile ~ci-train-ppa-service/ubuntu/staging-000/ubuntu/ubuntu-app-launch_0.4+15.04.20141119-0ubuntu1_source.changes
<robru> cjwatson: wow, ok thanks (we're trying to bring up a staging instance of citrain and basically everything is broken)
<cjwatson> I wonder if you're missing dput from trusty-updates or similar
<robru> cjwatson: yeah I would say so, since it's running on precise ;-)
<ogra_> om26er, oh ! all good ?
<robru> cjwatson: is there a trick for getting the right dput in precise?
<om26er> ogra_, yes, the write performance had a hit when I paste stuff onto the device, other than that all good.
<ogra_> yay
<cjwatson> robru: Probably easier to drop a .dput.cf in place
<ogra_> rsalveti, want to take the honor to publish silo 11 ?
<ogra_> (rt)
<cjwatson> with the [ubuntu] stanza
<ogra_> *rtm
<cjwatson> er, rather, the [ppa] stanza
<robru> cjwatson: yeah I'm looking for what we're using in the production instance (which is also precise) but I can't find it. That would just be in ~ right?
<rsalveti> ogra_: sure
<robru> cjwatson: nm, found it
<ogra_> yay, thats our last silo for the milestone :)
<robru> cjwatson: this looks right to you? https://ci-train.ubuntu.com/job/cyphermox-test/409/console
<cjwatson> robru: Yeah
<robru> cjwatson: thanks
<john-mcaleely> ogra_, om26er is the device tarball signed off?
<om26er> john-mcaleely, yes
<ogra_> john-mcaleely, waiting for rsalveti to hit the button on the silo
<rsalveti> doing that now
<ogra_> john-mcaleely, then i'll trigger an image and you and cwayne1 can land your tarballs
<rsalveti> done
<ogra_> yay, thanks
<john-mcaleely> ogra_, ok
<john-mcaleely> ogra_, ping me when you want it :-)
<ogra_> john-mcaleely, in 30-60min ...
<cwayne1> ogra_: still waiting on the +1 from rvr for the spanish one
<cwayne1> jibel +1'd the english one though
<ogra_> oh
<ogra_> ok
<rvr> cwayne1: Oh, for me is +1 for the Spanish
<ogra_> cwayne1, well, see above ... 30-60min anyway ...
<ogra_> just waiting for the last silo to migrate
<cwayne1> ogra_: okay cool, let me know when to push and i will
<cwayne1> thanks rvr :)
<ogra_> will do
<john-mcaleely> ogra_, ack
<ogra_> sil2100, hey, survived your ebola attack ?
<sil2100> Ubola
<ogra_> :)
<sil2100> ;)
<ogra_> sil2100, importer stopped, waiting for the last silo to migrate and will kick *the* image
<sil2100> Yeah, somehow at least
<sil2100> Did all the silos land?
<sil2100> YEAH
<ogra_> last one is migrating at,
<ogra_> *atm
<sil2100> Ok, happened later than I expected, but still ok I guess
<ogra_> we got all topblokers in :)
 * sil2100 keeps fingers crossed that we won't see any new serious issues
<ogra_> so we can all take vacation next week
<sil2100> \o/ wait, that's... hmm... ;)
<ogra_> :)
<rvr> cwayne1: Crash in ubuntu-rtm/14.09.es-proposed
 * cwayne1 needs to run for about 15 min
 * ogra_ wonders why intramfs-tools-ubuntu-touch is two versions apart between vivid and rtm ... instesad of one
<ogra_> ah, the fix was split in two uplaods
<olli> ogra_, sil2100, we are about to eod
<olli> any news?
<ogra_> olli, waiting for the last silo to migrate to the archive ... then there will be a new image in ~2h
<john-mcaleely> and it will be the perfect image
<olli> new image?
<ogra_> olli, and then we can all take a week of vacation since all topblockers are in
<olli> had some issues in the current one
<ogra_> olli, yes, the candidate image ...
<olli> ogra_, you yourself announced 2 GMs
<sil2100> olli: image will be spinned pretty soon
<ogra_> olli, right ... now we dont need the second one and can alll go off and slack for a week :P
<olli> that's right
<olli> ;)
<sil2100> ;)
<ogra_> this image with be *perfect*
<sil2100> ogra_, olli: ...assuming that QA won't find anything during regression testing!
<ogra_> naaaah
<ogra_> nevar !
<olli> so, we are done silo testing
<olli> need to do a sanity check and then the regression check
<olli> is that where we are at?
<ogra_> yes
<olli> nice
<ogra_> well, first an image ....
<olli> well done everyone
<olli> details
<ogra_> ToyKeeper will pick that up and do sanity testing over night
<olli> I assume the image building process is something we already have under control ;)
<ogra_> and tomorrow morning we know where we stand
<ogra_> yeah
<ogra_> everything is under control ... enjoy the hotelbar :)
<olli> if only
<sil2100> olli: go get drunk!
<olli> neva
<sil2100> hah!
<ogra_> lol
<john-mcaleely> they've promised me a drink. how long before I push the tarball?
<ogra_> lol
<ogra_> oh, and it see there are also new langpacks ... just in time for this image
<pmcgowan> niiice
<ogra_> hmm, or not
<oSoMoN> robru, has the binary copy of oxide-qt to silo 17 failed, or is it just still pending?
<rvr> ahayzen: Translating the strings
<sil2100> oSoMoN: binary copies are almost instant
<ahayzen> rvr, thanks :) i switched the default view of the translations page over to the remix series
<sil2100> oSoMoN: so it either failed, or maybe robru didn't do it yet
<robru> sil2100: i did it
<oSoMoN> sil2100, yeah, thatâs what I thought, so Iâm surprised itâs not appeared in the PPA yet
<robru> oSoMoN: must have failed. maybe another ppa too small? ;-)
<oSoMoN> robru, is there any way to check for errors? maybe the size of the PPA is insufficient (oxide with its debug packages is typically larger than 2GB)
<cjwatson> [2014-11-19 17:11:19,756: INFO/PoolWorker-2] <PlainPackageCopyJob to copy package oxide-qt from ~ubuntu-mozilla-security/ubuntu/ppa, RELEASE pocket, in ubuntu vivid to ~ci-train-ppa-service/ubuntu-rtm/landing-017, RELEASE pocket, in ubuntu vivid, including binaries>
<cjwatson>  (ID 25591849) failed with user error CannotCopy(u'oxide-qt 1.3.4-0ubuntu1 in vivid (Series ubuntu vivid not supported in archive for ubuntu-rtm.)',).
<cjwatson> You need to use --to-suite=14.09
<cjwatson> Assuming you did this by hand with copy-package
<oSoMoN> wait, this needs to happen for vivid, not for RTM (oxide 1.3.4 already landed in RTM)
<cjwatson> OK, or you need to copy to somewhere else :-)
<cjwatson> Anyway, distribution and suite need to match.  I expect you'll get mail about this shortly, assuming you ran the copy with your normal user privileges
<fginther> camako, hey. alan_g had a question about some test results on jenkins. The difference is probably the host itself. I've disabled it for now for mir, so you can try and re-approve those MPs
<oSoMoN> robru, wrong target PPA indeedâ¦
<rvr> ahayzen: Done
<ahayzen> rvr, awesome thanks :) are you wanting these translations in this image?
<fginther> camako, it's not a good solution, but hopefully it removes the immediate problem and allows for less stressful debugging
<robru> ah did i copy it to rtm? crap
<robru> off-by-one error in the copy-packages page ;-)
<robru> ok I can copy again
<rvr> ahayzen: Yeeees, please
<rvr> If possible
<fginther> camako, Here's at least one MP that failed due to this issue and can be re-approved - https://code.launchpad.net/~alan-griffiths/mir/migrate-more-acceptances-tests/+merge/242094
<ahayzen> rvr, hmmm we need to manually trigger lp to merge them and push a new click... dpm popey possible?
<camako> fginther, it's pretty easy to make the tests pass on our end... we'd like to understand and root-cause it though
<ogra_> oookay ... all landed
 * ogra_ fires up the rootfs build
<rvr> ahayzen: You can download the .pot file https://translations.launchpad.net/music-app/remix/+pots/music-app/es/+export
<fginther> camako, the host that ran the failed test runs was a newly created cloud instance. It was probably built from a newer image then the other builder nodes
<oSoMoN> robru, yes please, if you donât mind
<ahayzen> rvr, usually launchpad merges the other languages in the morning for us automatically
<fginther> camako, I've gotta run. Can try to pick this up as soon as possible
<camako> fginther, ok thanks
<ahayzen> rvr, that maybe the way of doing it ? .. but i don't know how it works i usually ask dpm :)
<dpm> ahayzen, it's not possible to trigger a translations export (it happens every morning at around 8:00), but you can manually download a tarball of all the .po files, commit them to the source tree, submit a new MP and let Jenkins build the click
<robru> oSoMoN: ok done, sorry about that
<oSoMoN> robru, no worries, thanks!
<ahayzen> dpm, is there a place where i can download all of the .po's?
<dpm> ahayzen, I'd say unless it's urgent to get a release out today, it's not worth the hassle and we can wait until the automatic export tomorrow
<imgbot> === trainguards: RTM IMAGE 166 building (started: 20141119 18:20) ===
<ahayzen> dpm, ok :) ... rvr ^^ ?
<sil2100> \o/
<ogra_> there we go
 * john-mcaleely waits for a ping
<dpm> ahayzen, you can use the download link at https://translations.launchpad.net/music-app/remix/+pots/music-app
<ogra_> john-mcaleely, cwayne1, land your tarballs at your conveninece
<john-mcaleely> ogra_, thank you. starting now
<rvr> ahayzen: dpm: Yup, a bit late for today, image 166 is building right now
<sil2100> jibel, ToyKeeper: promotion candidate building, in ~2h you should have something for sanity testing o/
<john-mcaleely> ogra_, done
<ogra_> yay
<ahayzen> rvr, cool we'll push out a click tomorrow when it lands then :) thanks for doing the translations
<sil2100> ogra_: how's the adbd change going btw.?
<cwayne1> ogra_: done
<ogra_> sil2100, havent found the time for it today, i'll make it ota-1 (or land it next week) it is corner case enough ... and the bits that just landed should prevent it from having actual impact
<sil2100> ogra_: right, just been wondering - anyway, I think it's time for you to rest today as well o/
<sil2100> All in the hands of QA
<ogra_> once everything is done i will :)
 * ogra_ watches https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu-rtm/14.09/ubuntu-touch
<ogra_> sil2100, so langpack imports are set up for tuesday nights now for the future ... that way we will have the before the candidate images on wednesdays in the future
<ogra_> s/the/them/
<ogra_> i was hoping to get a full langpack set before todays image ... but that kind of slipped
<sil2100> Langpack-only changes seem safe, so we can spin an image sometime later if needed
<ogra_> yep
<ogra_> sil2100, hmm, "We will unblock ubuntu-rtm landings ..."
<ogra_> will we ?
<sil2100> ogra_: for future topblockers we will, those that we mark for the next milestone (if we find any)
<sil2100> I guess
<ogra_> yeah
<ogra_> i would expect our manager trio to define new ones for next week
<ogra_> level2 topblockers :)
<sil2100> hah ;)
<ogra_> rootfs built ... re-enabling the importer
<Saviq> trainguards, could I have a silo for line 79 please?
<sil2100> ogra_: o/
<ogra_> sleep well
<robru> Saviq: ok, vivid 30, dont' forget about vivid 11 too ;-)
<Saviq> robru, that one's a testing silo only, will probably clean it out soon
<Saviq> robru, thanks
<robru> Saviq: you're welcome
<elopio> plars: do we have phones on the lab with real sims and a carrier contract so they can receive real SMS ?
<plars> elopio: no
* plars changed the topic of #ubuntu-ci-eng to: Need a silo? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: RTM Archive frozen (no new silos landing) ! RTM cron builds disabled
<imgbot> === trainguards: RTM IMAGE 166 DONE (finished: 20141119 19:55) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/166.changes ===
<ogra_> ToyKeeper, thats yours :D ^^^
<ToyKeeper> ogra_: Thanks.  :)
<ogra_> oh, how did sudoku get in there ?
<ToyKeeper> I've had issues lately getting xchat to notify me on imgbot messages.
<ogra_> popey, balloons ^^^
<ToyKeeper> ogra_: Er, don't tell me we need to rebuild to remove sudoku...  (?)
<balloons> ogra_, oO sudoku :-)
<ogra_> ToyKeeper, lol, nope
<balloons> it was obviously in the previous image..
<ogra_> ToyKeeper, i just want to know why it landed, it didnt have a topblocker bug and wasnt approved for landing
<ToyKeeper> It's far from the only custom tarball change which landed without a topblocker bug...
<ogra_> balloons, it wasnt supposed to be updated without whishlist approval
<balloons> ogra_, I didn't land it. However my guess is it was not expected to be in the image, and thus free of whitelisting landings
<ogra_> ToyKeeper, well, in this case it means someone didnt follow the process and uploaded an update to the store
<balloons> it's not on the list for 'in image'
<ToyKeeper> I was very surprised to see new design changes in yesterday's image; thought those were on hold until after release.
<ogra_> it definitely is on the image ...
<ogra_> was there since day one
<ogra_> ToyKeeper, most of them were ripped out again
<ToyKeeper> However, I was also pleasantly surprised to see how things are going on mako lately.  Mako rtm seems really smooth and solid.
 * ogra_ was surprised to see *these* design changes .. it felt like no designer had ever seen them 
<balloons> ogra_, yes that's obvious. I'm saying I don't think it's on popey's list of apps to hold.. For example,  calendar is updated freely; indeed it was updated today too
<ogra_> yeah, thats fine until we pull it on again
<ogra_> (whouch should happen with some ota release
<balloons> yes, *soon*
<ogra_> hopefully :)
 * ogra_ wants it by default again ... 
<ogra_> and a timer and stopwatch
<ogra_> oh, and a pony
<ToyKeeper> I still wonder if there's anything we can do about unity8 creating and destroying so many threads all the time.  I got the impression that's caused by a layer too low for us to fix.
<ogra_> thats a tedg and ricmm thing ...
<ogra_> i guess
<tedg> Shouldn't be a tedg thing...
<ogra_> hah, shouldnt ...
<ogra_> :P
<tedg> Might be a scopes thing :-)
<ogra_> see, it was a tedg thing to point in the right direction ;)
<nik90_> ogra_: you know everytime someone uses the keyword "timer", "stopwatch" or "wake", I am pinged....stop doing that :P
<ogra_> LOL
<ogra_> argg
<ogra_> dbarth, the G+ app on my phone only shows the desktop page
<dbarth> ogra_: recent change?
<ogra_> dbarth, the image is still warm, yes ... i just updated to 166 which had the new oxide and webbrowser-app landed
<ogra_> same thing if i open plus.google.com in the browser btw
<dbarth> ogra_: which new webbrowser-app? ie from which silo?
<ogra_> the one that landed today in rtm http://people.canonical.com/~ogra/touch-image-stats/rtm/166.changes
<ogra_> i think that was in silo rtm 3 when it landed
<dbarth> ah i see the change
<dbarth> right
<ogra_> wow, most annoying, you cant even scroll in the G+ page without pulling up the keyboard with every swipe
<dbarth> i tested this one this afternoon
<dbarth> hmm
<ogra_> other webapps are fine it seems
<dbarth> ogra_: i have the very same version of webapp-container running right now
<dbarth> on rtm/krillin
<dbarth> the g+ webview looks fine here
<ogra_> weird, for me it opens the desktop page in both, the webapp and the browser
<ogra_> heh, it offers me hangouts
<ogra_> and clicking "start hangout" indeed crashes the browser
<ogra_> oh !
<ogra_> and after the restart i get the mobile page !!
<ogra_> ha
<dbarth> i've seen that occasionnally with youtube
<dbarth> where it gets confused because of a cookie or so
<ogra_> yeah, the G+ app still has the desktop page
<dbarth> ogra_: can you try the refresh button in the header
<ogra_> there is none in that G+ app
<ogra_> its fullscreen
<dbarth> also maybe navigating to the settings page from the drawer menu
<dbarth> the g+ header itself
<ogra_> (not using xnox' one ... )
<dbarth> the black one
<iahmad> cwayne1, re wrong distances bug, on very first boot, I can still see distances though on refresh they disappear
<ogra_> dbarth, thats the point, there is no such header on the desktop version of the page
<cwayne1> iahmad: was that after an ota?
<ogra_> i can click the Google+ logo but that only refreshes the page
<iahmad> cwayne1, nops, flash with --wipe
<dbarth> ah well, i'm seeing the mobile version
<dbarth> let me check on my desktop
<ogra_> i must say that the content rendering is miles better in the desktop page
<dbarth> eh
<ogra_> and our browser can obviously easily cope with it
<ogra_> to sad the fonts are unreadable small
<dbarth> it's blink behind, so it does, yes
<ogra_> damn ...
 * ogra_ goes and removes the app and all traces of it 
<dbarth> ogra_: i suspect a cookie pb still
<ogra_> lets see if it goes away after re-installing it afresh
<dbarth> right, we are adding hooks to clean up caches and settings once you remove a webapp
<ogra_> cool
<dbarth> this way, people should have a way to get out of that sort of trap
<dbarth> without requiring devmode
<dbarth> ogra_: try to ping alexabreu if the problem persists after that
<ogra_> i'm actually ponderign to keep it that way ... it is so much snappier !
<dbarth> :)
<ogra_> and pics are not cut off
<dbarth> maybe keep a tarball of the .local/share app directory for later inspection
<ogra_> gifs are actually playing
<ogra_> you just have to zoom to read
<ogra_> hmm, nope
<ogra_> didnt workk
 * popey catches up with conversation about sudoku
<popey> I asked balloons to update it in the store.. what's the issue?
<ogra_> popey, did it have approval and whitelisting ?
<popey> no, it's not in the image
<ogra_> (it is on the image)
<popey> mako, yes, krillin, no
<popey> phablet@ubuntu-phablet:/usr/share/click/preinstalled$ ls -l *sudoku*
<popey> ls: cannot access *sudoku*: No such file or directory
<rsalveti> tedg: what is the reason for the indicators to have such a small upstart respawn limit?
<rsalveti> respawn limit 2 10
<popey>  http://people.canonical.com/~ogra/touch-image-stats/rtm/166.changes is the mako changelog, right?
<ogra_> popey, oh, bah ... it is included int the rootfs, so updates show up in the changelog
<rsalveti> tedg: http://paste.ubuntu.com/9103715/
<popey> right.
<ogra_> popey, no
<ogra_> it is the rootfs changelog :)
<popey> *boggle*
<popey> I'm confused â»
<rsalveti> tedg: we're about to land https://bugs.launchpad.net/ubuntu-rtm/+bug/1394350, but then if we get an indicator crashing at least twice in a row it'll be already enough for a reboot
<ubot5> Launchpad bug 1394350 in Ubuntu RTM "[ubuntu-touch] system not recovering automatically when a critical service reaches the upstart respawn limit" [Critical,Confirmed]
<ogra_> on krillin the custom tarball removes the unwanted clicks
<popey> right. super. So panic over.
<ogra_> all images use the same rootfs
<popey> no rules broken
<ogra_> yeah
<ogra_> phew
<popey> \o/
 * ogra_ goes back to bang his head aganins G+ 
<popey> :D
<tedg> rsalveti, We kinda put our finger in the air and guessed, but we figured they shouldn't crash more than once, so twice seemed like a good limit...
<tedg> rsalveti, No "reason" more a guess
<rsalveti> right, the default from upstart is 10
<ogra_> i wonder if xnox' G+ app would work
<popey> thats broken in terms of image upload
<popey> whats up with whatever you're playing with?
<rsalveti> tedg: if you think we should reboot the phone in case they crash at most 2 times, fine
<rsalveti> just a heads up :-)
<ogra_> popey, with the new oxide it defaults to the desktop page
<popey> ugh
<ogra_> which is kind of ok
<popey> oxide 1.3?
<ogra_> i really like that you dont have cut off content etc
<ogra_> but you miss all notifications (they vanish behind the screen edge) and the fonts are to small to read
<ogra_> popey, yeah, image 166
<tedg> rsalveti, Eh, I don't know a better number. If it crashes twice it'll probably do so three times.
<rsalveti> that's indeed true
<ogra_> the browser itslef shows the mobile page again after me madly reloading it like 20 times
<popey> heh
<ogra_> i might just keep a browser tab for seeing the notifications :)
<ogra_> and the app for reading content (after zooming)
<ogra_> ah ... all back to normal ... i had forgotten to wipe the QML cache
<ogra_> great then ...
 * ogra_ wanders off to the TV
<robru> infinity: cjwatson: can I get a new-binary-package ack on https://ci-train.ubuntu.com/job/ubuntu-landing-002-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-keyboard_0.99.trunk.phablet2+15.04.20141119-0ubuntu1.diff ? thanks
<bfiller> popey, ogra_ : I'm seeing the desktop sites instead of mobile as well. Is that a regression with oxide 1.3?
<infinity> robru: On vacation, find another core-dev sucker. ;)
<infinity> robru: Like rsalveti perhaps.
<popey> bfiller: looks like it
#ubuntu-ci-eng 2014-11-20
<imgbot> === trainguards: IMAGE 27 building (started: 20141120 02:05) ===
<imgbot> === trainguards: IMAGE 27 DONE (finished: 20141120 03:30) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/27.changes ===
<Mirv> morning
<Mirv> barry: hi! you've had vivid silo 004 in use for three weeks, is it abandoned and can it be freed?
<Mirv> lool: same ^ for your vivid silo 020, assigned 3 weeks ago, no actions for 2 weeks
<Mirv> I'm just checking the statuses as we are out of silos
<Mirv> bregma: could you consider testing the indicator-session trusty silo 023, or abandoning it?
<Mirv> bzoltan: you've had qtcreator-plugin-ubuntu in vivid silo 021 for two weeks, but it looks it should be abandoned?
<bzoltan> Mirv:  let me check...
<bzoltan> Mirv:  yes, that MR got merged together with the latest landing. Sorry.
<Mirv> bzoltan: ok, freeing up
<Mirv> AlbertA: I think you will need to rebase mir and rebuild - it seems bdmurray has pushed a no change rebuild to archives so the changelog in your branch is out-of-date and CI Train would complain: https://lists.canonical.com/archives/vivid-changes/2014-November/001800.html
<dbarth> good morning
<dbarth> justinmcp_: hi, i'm here
<sil2100> yay, sanity tests for 166 were really good \o/
<ogra_> sil2100, yeah, but we have one toopblocker left
<ogra_> (see ricardos mail)
<ogra_> and the browser cache bug is also not so nice
<sil2100> ogra_: yeah... I actually asked oSoMoN a few days ago if the oxide fix is enough
<oSoMoN> sil2100, ogra_: talking about rsalvetiâs comments on the bug? Iâm looking into it
<ogra_> oSoMoN, which one now ? :)
<ogra_> bug 1391230 or bug 1394380
<ubot5> bug 1391230 in pulseaudio (Ubuntu RTM) "[TOPBLOCKER] web audio, pulse runs at 6% and screen will not blank on idle" [Critical,Confirmed] https://launchpad.net/bugs/1391230
<ubot5> bug 1394380 in lxc-android-config (Ubuntu RTM) "QML cache not regenerated correctly on image update" [Critical,Confirmed] https://launchpad.net/bugs/1394380
<oSoMoN> I was talking about the first one
<sil2100> ogra_: how much does it take to re-generate the QML cache btw.?
<ogra_> sil2100, one start of the spp
<ogra_> *app
<ogra_> the cache is per app ... created on first start if it doesnt exist
<oSoMoN> re- the QML cache, I donât understand how that could possibly affect the oxide upgrade, oxide is pure C++, thereâs no QML to compile and cacheâ¦
<sil2100> Right, but it's not a time-consuming operation anyway I suppose
<ogra_> it speeds up the startup once it is in place, so the drawback of wiping it means the apps start a bit slower the first time after an updated
<ogra_> oSoMoN, the webbrowser is QML ... and a small piece of the container too
<ogra_> (and i'm not sure it is just QML in that cache ... ricmm ??)
<oSoMoN> ogra_, sure, but the issue reported by Bill about UA strings doesnât make sense to me
<ogra_> well, i have seen it myself
<sil2100> ogra_: then I would personally give a +1 on your workaround until a proper solution is prepared, but anyway poke Pat and olli first
<ogra_> sadly i bluntly deleted all dirs that had any trace of browser or webapps in them on my phone
<ogra_> bill seems to have seen that and done it dir by dir
<olli> ogra_, sil2100, what's up
<ogra_> sil2100, i dont think  it is a reason to re-spin ... so we can discuss it in the bug meeting
<olli> read backscroll, don't think I have all context
<ogra_> https://launchpad.net/bugs/1394380
<ubot5> Launchpad bug 1394380 in lxc-android-config (Ubuntu RTM) "QML cache not regenerated correctly on image update" [Critical,Confirmed]
<sil2100> ogra_: that's for sure, I think this milestone should stay closed, but maybe next weeks
<sil2100> olli: so there's this bug that we noticed ^
<ogra_> olli, after OTA some webapps and the browser behave weird (like serving the desktop variant of pages etc) ... until you wipe the QML cache for them
<sil2100> olli: ogra_ prepared a quick-fix that simply clears out the QML cache on every update
<ogra_> right, i think we should have a solution for the final image ...
<sil2100> olli: we don't think it's needed for this milestone, but we might consider adding this (or something better) for the next milestone
<ogra_> but rsalveti disagrees in the bug, i'd like his input first
<ogra_> right, there might be something better (though i would prefer the safe solution and just wipe everything to prevent future surprises)
<olli_> ogra_, sil2100, let's try again, I am on ethernet now
 * olli_ throws unfriendly words at the BF wifi
<sil2100> Let me copy-paste
<olli_> you can pm that too
<ogra_> done
<ogra_> bah, to the wrong olli
<sil2100> hah ;)
<ogra_> better now :)
<olli_> ok
<olli_> so.. that bug seems to be triggered in updates only
<ogra_> yes
<olli_> is there a way the upstart change can be applied via OTA
<olli_> in a pre-hook or so
<ogra_> you mean before an OTA ?
<ogra_> no
<ogra_> it has to come in with a system upgrade
<olli_> sure
<olli_> will that be sufficient though
<olli_> or does it have to be in GM
<ogra_> yes
<ogra_> oh, well
<ogra_> if we i.e. upgrade oxide or webapps after the GM it needs to be in place to prevent it
<ogra_> (and we dont know how/if it affects other apps, webapps are the only ones exposing something really visible)
<olli_> ogra_, can't the update wipe the cache (once) while being installed?
<ogra_> well, the thing runs on every first boot after upgrade ... so yes, it runs when it is shipped
<ogra_> why would you want to do that only once ?
<ogra_> that defeats the whole purpose
<ogra_> you want this on every system-image upgrade
<ogra_> (which this upstart job will do)
<ogra_> "start on boot-hooks WHEN=new-version"
<ogra_> (new version points to the system-image, it will only run after an OTA happened)
<ogra_> psivaa, we seem to be missin results for one device in the krillin rtm smoketests
<psivaa> ogra_: yes, one device failed to provision with wifi, i've kicked the missed tests off
<ogra_> thx
<sil2100> jibel: in the meantime, are you continuuing the regression tests on #166?
<jibel> sil2100, we do
<sil2100> jibel: excellent :)
<sil2100> Give us a sign if any serious issues emerge
<sil2100> popey: meeting!
<popey> sorry, network connection went funny
<cjwatson> robru: I'm assuming somebody dealt with that ubuntu-keyboard core-dev ack, since that URL is 404 now
<Mirv> cjwatson: yes, it was an universe package
<sil2100> psivaa: if you could give us a poke when the test results are all in it would be awesome
<sil2100> :)
<psivaa> sil2100: ack will do. they are roughly 1 hour and 30 mins away, but i'll ping to let you know
<ogra_> sil2100, the QA regression tests will take the whole day anyway ... no need to hurry :)
<sil2100> ogra_: ;)
<ogra_> sigh
<ogra_> i just had my session restart
<psivaa> sil2100: ogra_ the testing with 166 is complete, but hasn't synced to the dashboard yet
<ogra_> ok
<sergiusens_> can I get a silo for line 54?
<sergiusens_> ah, it moved :-P
<psivaa> ogra_: sil2100: one new failures that i can see is this in dialer: http://rtm-dashboard.ci.ubuntu.com/smokeng/utopic/touch_stable/krillin/166:20141119:20141119-db417fa/184/dialer_app/
<ogra_> thanks !
<ogra_> i guess we should let bfiller know
<ogra_> i looks like the app went away (dbus cnt find it anymore) but i see no .crash or anything
<ogra_> (unlike the constant camera-app crash we have on krillin)
<sil2100> psivaa: thanks!
<psivaa> np, there is no kernel logs for a minute from 20:31:04, roughly when this happened. not sure if there is any relevance
<ogra_> is there anything like zzzZZZZZZ in it perhaps
<ogra_> :D
<psivaa> :)
<Mirv> joke of the day:"I'll have a quick oxide-qt build"
<sil2100> Mirv: :D
<olli> lol
<olli> ogra_, sil2100, what's the plan now
<olli> I am trying to round up the team here for a quick call
<ogra_> we wait til QA finished the regression tests and publish
<ogra_> future plans need to be discussed then imho
<olli> publish with the topblocker still open
<olli> ?
<ogra_> sure
<sil2100> olli: we need to assess how much the leftover oxide issue is still top-priority
<ogra_> it is being actively worked on
<sil2100> olli: if it's not
<ogra_> so we can expect it to be fixed by next week i think
<john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20141119-f75a559.tar.xz
<john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20141119-f75a559.changes
<ogra_> it is also not a regression over our last promoted image
<john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-testresults-20141119-f75a559.ods
<sil2100> olli: ...premature enter, but yeah: we can tackle it for next week's milestone I suppose
<john-mcaleely> sil2100, ogra_ jibel ^ vivid krillin device tarball
<sil2100> olli: as rebuilding oxide can take ages
<john-mcaleely> does that need QA signoff?
<ogra_> john-mcaleely, just go ahead
<olli> sil2100, so you are saying it's not feasible to fix it in this weeks build
<sil2100> john-mcaleely: hey! Not really ;) But if you want you can ask QA to help out
<olli> and then spot test
<ogra_> olli, we dont have a fix yet
<john-mcaleely> sil2100, It's got a test pass from me. I'm happy to push it
<john-mcaleely> you're short handed at the moment
<ogra_> olli, if we had we might be able to consider it ... but even then ... it isnt a regression, we had it in many former images and we are confident to get a fix before final
<john-mcaleely> ogra_, to be clear - it's ok to push now (build machine wise)
<sil2100> olli: yeah... since if we have a fix and it requires an oxide rebuild (which is probable from what oSoMoN mentioned), then it would really push things behind
<sil2100> john-mcaleely: then you have a green light :)
<ogra_> john-mcaleely, sure
<john-mcaleely> ogra_, sil2100 jibel done. new vivid tarball in the next build
<john-mcaleely> (32?)
<ogra_> might be :)
 * ogra_ didnt look at vivid for a while
<oSoMoN> sil2100, olli: it requires an oxide rebuild indeed, chrisccoulson is taking care of it as we speak. Iâd like to mitigate to impact of the issue though: as pointed out by rsalveti in the bug, the issue is there only the first time after boot, subsequent uses of the browser wonât exhibit it
<olli> ogra_, sil2100, are you guys available for a quick HO right now
<ogra_> gimme 5 min
<olli> oSoMoN, ^
<olli> k
<oSoMoN> olli, so maybe it doesnât deserve to be an urgent topblocker anymore?
<oSoMoN> (Iâm available for a quick HO if you need me)
<sil2100> john-mcaleely: thanks :)
<sil2100> oSoMoN: fact
<pmcgowan> oSoMoN, in my view it will still make an impact 100% of the time so we really need the fix but we can discuss
<oSoMoN> pmcgowan, indeed, it will always be an issue the first time the browser is launched after rebooting, Iâm not denying that this needs to be fixed quickly (in fact the fix is ready), just saying that maybe we donât want to delay the image validation and promotion any longer
<sil2100> pmcgowan: I just think we shouldn't delay this week's milestone but maybe include it in the one next week
<ogra_> pmcgowan, no doubt that we need it
<ogra_> pmcgowan, but there is no way it can make this milestone
<pmcgowan> well lets discuss, the curent image will not make gm
<ogra_> obviously not, but we''ll promote it
<olli> ogra_, there is no point
<ogra_> this isnt a regression
<ogra_> last milestone had this prob, and many before
<ogra_> so for the good of oour users we'll definitely promote it to get testin for the rest of the image
<olli> ogra_, this is applying the LT criteria
<ogra_> yes
<olli> I think we wanted to include the product team criteria as well for a promotion
<ogra_> only talking about this atm
<olli> ogra_, , sil2100, oSoMoN pmcgowan, victorp https://plus.google.com/hangouts/_/canonical.com/olli
<ogra_> *we* will promote it, *you* definitely should wait til there is a fix on the horizon
<ogra_> olli, reading that bu again from top to bottom i actually think having media-hub/pulse never go to sleep (which this bug causes) is as bad as keeping the display on, so we should try to get some fix from rsalveti as well if that is possible in time
<ogra_> *bug
<ogra_> else your phone will never sleep if there is a webapp backgrounded
<ogra_> olli, pmcgowan as per the discussion i turned bug 1394380 into a topblocker
<ubot5> bug 1394380 in lxc-android-config (Ubuntu RTM) "[TOPBLOCKER] QML cache not regenerated correctly on image update" [Critical,Confirmed] https://launchpad.net/bugs/1394380
<olli> thx ogra_
<sil2100> olli, ogra_: I'll put it on the list for the next milestone then
<ogra_> yep
<olli> what is the next milestone?
<sil2100> wave2, next week
<oSoMoN> olli, pmcgowan, sil2100: oxide 1.3.5 building at https://launchpad.net/~phablet-team/+archive/ubuntu/ppa/+sourcepub/4579784/+listing-archive-extra
<ogra_> sil2100, ^^
<sil2100> o/
<sil2100> ogra_: no free silos for vivid right now...
<ogra_> sil2100, thats fine ... vivid can land later
<ogra_> (they are diverted enough that i needed to create two different uploads anyway)
<ogra_> argh, i think i clicked "build" to fast ... the PPA didnt produce binaries yet
 * ogra_ tries that again ... but now with binaries in place :P
<rsalveti> ogra_: olli: right, it'll never to go deep sleep because, because pulse will stay up
<ogra_> right
<rsalveti> I'm checking that now, should hopefully have a fix for next week iteration
<sil2100> rsalveti: o/
<rsalveti> ogra_: and regarding the qml cache thing, let's land your change if that indeed only runs after every flash/update
<ogra_> rsalveti, right
<ogra_> safety net :)
<rsalveti> yeah
<ogra_> (it is already in silo2)
<rsalveti> great
<tedg> trainguards, can you republish vivid/25, marcustomlinson fixed the top approval.
<sil2100> tedg: ACK
<bfiller> sil2100: I need to sync a package from rtm to vivid, please see line 56, not sure I got the format right
<sil2100> bfiller: sure thing, let me take a look
<bfiller> sil2100: also, is there a script that can be run that compares rtm versions to vivid? I'm worried that some fixes may have only landed in rtm and not in ubuntu vivid (like qtorganizer5-eds)
<ogra_> bfiller, given you only care about stuff on the touch image, you could worst case pull both manifest files from cdimage.ubuntu.com and diff them ...
<sil2100> bfiller: ok, the format looks right, let me assign the silo - as for the second question, one time I prepared a list of approximate missing landings from both sides (rtm->vivid and vivid->rtm), but it's probably outdated now
<sil2100> It's actually generated from a diff between the manifests
<sil2100> I can regenerate that list later today and put somewhere
<bfiller> sil2100: that's great, thanks
<sil2100> bfiller: so, I see you already have a silo with qtorganizer5-eds for vivid (silo 15)
<sil2100> bfiller: it seems to be a normal merge-based silo - you want to have this sync assigned first though?
<bfiller> sil2100: yes, we can ignore that for now. having problems with that
<sil2100> ACK
<sil2100> bfiller: silo 11 assigned, it should sync the package from rtm when 'build' is pressed
<sil2100> tedg: I approved the packaging changes now and publishing
<tedg> sil2100, Great, thanks!
<tedg> marcustomlinson, ^
<marcustomlinson> sil2100: thanks :)
<sil2100> yw :)
<bfiller> sil2100: great
<bfiller> thanks
<cyphermox> sil2100: I'm taking care of vivid silo 003 myself
<sil2100> cyphermox: ok, will try to keep my hands out of it :)
<cyphermox> ;)
<cyphermox> ugh, more snow :(
 * sil2100 wants snow
<sil2100> I'm in a strange christmas-ish mood right now (which is strange, considering it's Nov still) - but I'm missing snow outside of my windows
 * ogra_ is happy he doesnt have to turn th heating on yet ... 
<ogra_> or to shovel snow
<sil2100> hah, yeah, the few downsides of having a house :)
<sil2100> As an apartment user I don't have much more work when snow is around
<ogra_> yeah
 * cwayne1 is getting prepared for first snow as a homeowner
<sil2100> Just when wanting to use the car
<sil2100> Damn, 30 silos for ubuntu and all are occupied :o
<ogra_> you need to stock up ... to 60 :)
<cyphermox> sil2100: it's not that I don't like snow, but it's cold in my office and I wasn't mentally prepared for the snow
<om26er> cwayne1, which project should I use to report bugs for Grooveshark scope ?
<cwayne1> om26er: ubuntu-rest-scopes
<fginther> alan_g, I have some more info on the mir test failures you mentioned yesterday. The builds that were failing were all running on a newer instance with a 3.13.0-39-generic kernel instead of a 3.13.0-36-generic kernel
<alan_g> fginther: odd. Thanks for the update
<greyback> trainguards: can I get a silo for line 58 please? Is for a qtmir build system switch
<sil2100> greyback: is that for vivid?
<greyback> sil2100: yep
<sil2100> greyback: since currently we're still lacking silos... all are full
<greyback> sil2100: ah ok
<sil2100> greyback: I'm waiting for some to empty up
<greyback> no rush
<sil2100> Oh, ok, I see one is ready now
<sil2100> jibel: btw. do we have someone performing sanity testing for the 166 equivalent for mako?
<jibel> sil2100, not yet.
<oSoMoN> gotta leave for now, Iâll be back online later tonight to handle the silo request for oxide 1.3.5
<sil2100> hmmm...
<sil2100> I wonder if oSoMoN needs a silo for the oxide-qt landing already
<sil2100> As it's not set to Ready: 'Yes'
<ogra_> i guess it still builds
<ogra_> oh, thanks
<sil2100> greyback: I can't assign a silo for you now since I see silo 009 already has qtmir in it (new Mir release)
<sil2100> ogra_: we had some free silos finally :)
<greyback> sil2100: ack
<sil2100> ogra_, olli: hey! I sent out an e-mail to you guys regarding the milestone update
<ogra_> k
 * sil2100 needs to drive to the store now
<sil2100> See you tomorrow o/
<AlbertA2> trainguards: can someone review this: https://code.launchpad.net/~mir-team/ubuntu-seeds/use-new-Mir-metapackages/+merge/242408
<AlbertA2> trainguards: and related question, can I include that branch in my mir release silo (009) so that upgrading does not result in
<AlbertA2> unable to boot a phone
<robru> AlbertA2: no, we definitely want upgrades to break phones ;-)
<AlbertA2> robru: :) in that case I'm ready then heh
<robru> AlbertA2: so that branch looks fine to me but you need a core dev for seed changes. I recommend ogra_, he does most of the seed changes I know of
<AlbertA2> robru: thanks!
<robru> AlbertA2: you're welcome
<ricmm> manual acking?
<robru> ricmm: it's ok
<ricmm> robru: ok
<oSoMoN> trainguards: hey, can I haz a silo for line 56, please
<robru> oSoMoN: rtm 3
<oSoMoN> robru, thanks, would you mind doing the binary copy of oxide-qt from https://launchpad.net/~phablet-team/+archive/ubuntu/ppa ?
<robru> oSoMoN: sure one sec
<robru> oSoMoN: which one? the newest one has a lower version. confused
<robru> oh rtm ;-)
<oSoMoN> robru, sorry, I should have specified: 1.3.5-0ubuntu0.14.10.1~rtm
<oSoMoN> (I hadnât noticed that there was a 1.4.0 test build in there)
<robru> oSoMoN: hm, not sure if this'll work, as it won't let me choose 14.09 as the series.
<robru> oSoMoN: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-003/+packages yeah the copy failed.
<oSoMoN> robru, why not? it worked yesterday when copying 1.3.4 from the ubuntu-mozilla-security PPA
<robru> oSoMoN: yeah that one you were copying from vivid to vivid. This is a copy from utopic to 14.09, the series don't match
<robru> oSoMoN: there's probably some other way to sync it but I don't know what it is. the web form on the ppa won't work
<oSoMoN> robru, I wasnât referring to the vivid one, actually the 1.3.4 that landed in RTM yesterday was also binary-copied from that PPA (the copy was not done yesterday though, it was two days ago)
<oSoMoN> robru, wasnât there a script that you guys use to perform this kind of copy, instead of going through the web form?
<robru> oSoMoN: who did that one for you?
<oSoMoN> robru, probably sil2100
<robru> oSoMoN: I just use the web form. the only script I ever had for this kind of thing was the one that did source copies and mangled the series.
<oSoMoN> robru, I guess that at this point a source copy wonât hurt anyway, as Iâm not gonna test it before tomorrow morning
<robru> oSoMoN: but will it fail to build due to running out of space? ;-)
<oSoMoN> robru, that PPA has 4GB of space, that should be enough
<robru> oSoMoN: if you're not building until tomorrow morning anyway, just check with sil at the start of your shift. he should be able to do it again
<oSoMoN> robru, Iâd rather have it build tonight so that itâs ready for testing tomorrow morning at the start of my shift
<robru> oSoMoN: but binary copies are really fast, just minutes even.
<robru> and will tax the build farm less
<oSoMoN> robru, right
<oSoMoN> robru, ok, Iâll check with sil2100 tomorrow morning then, thanks for the help
<robru> oSoMoN: ok sorry I couldn't help, get sil to teach me the secret of cross-series binary copies ;-)
<oSoMoN> will do :)
#ubuntu-ci-eng 2014-11-21
<imgbot> === trainguards: IMAGE 28 building (started: 20141121 02:05) ===
<imgbot> === trainguards: IMAGE 28 DONE (finished: 20141121 03:30) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/28.changes ===
<oSoMoN> Mirv, hey, is it possible to do a binary copy of oxide-qt 1.3.5-0ubuntu0.14.10.1~rtm from https://launchpad.net/~phablet-team/+archive/ubuntu/ppa to RTM silo 3 ?
<oSoMoN> Mirv, robru tried to do it last night for me, but he says it failed because itâs considered cross-series, but Iâm pretty sure we did that for 1.3.4 and it worked
<Mirv> oSoMoN: yes, it's possible
<Mirv> just needs correct parameters on the command line, LP web UI does not work
<oSoMoN> Mirv, right, thatâs what I thought, but robru wasnât sure how to do it, so he said better to wait till you or sil2100 can do it
<oSoMoN> Mirv, could you do it for me, please?
<robru> Mirv: yeah please share the command, i only know the web ui
<Mirv> oSoMoN: done
<Mirv> robru: ./copy-package -b --from=~phablet-team/ubuntu/ppa --from-suite=utopic --to=~ci-train-ppa-service/ubuntu-rtm/landing-003 --to-suite=14.09 oxide-qt
<oSoMoN> Mirv, thanks!
<Mirv> took a while, I needed to convert also this to the new style syntax so that I don't make Colin grumpy again :)
<Mirv> the new syntaxt is much better
<robru> Mirv: Hmmmmmmm thanks, seems simple enough
<robru> Weird that that would work in cli but not in the web ui
<kalikiana> cihelp, I need somehelp with autopilot. I get "Start directory is not importable" and it won't say *why* when files are there, and I didn't change the .py files http://paste.ubuntu.com/9143520/
<sil2100> jibel, ogra_: how's the testing going?
 * sil2100 didn't see a status e-mail in his inbox
<vila> kalikiana: cihelp is for CI related issues, i.e. ones you can't reproduce locally ;) I have no idea about what is wrong here but I would try by getting rid of: "09:46:50.312 WARNING emulators:26 - The ubuntuuitoolkit.emulators module is deprecated. Import the autopilot helpers from the top-level ubuntuuitoolkit module."
<vila> 'top-level' and import errors.... sound like either your PYTHONPATH is wrong or something related (i.e. you're trying to import something that can't be imported from any starting point in PYTHONPATH)
<kalikiana> vila: I used cihelp as leo is in the wrong timezone for this point in time and it's kinda urgent :-]
<vila> kalikiana: or you run into a collision where two modules have the same name at different places starting from different PYTHONPATH entries ;)
<vila> kalikiana: ack, but elopio is in QA not CI ;)
<vila> kalikiana: thomi may be ?
<kalikiana> vila: the paths etc. are all untouched, normal device, vivid, previously ran other ap tests perfectly - but this particular test gives the error, others still run
<vila> kalikiana: aprt from the general python issues, I probably know less than you about autopilot ;)
<vila> kalikiana: but still in your paste: raise ImportError('Start directory is not importable: %r' % start_dir)
<kalikiana> vila: alright, I'll ask qa then, thanks anyway
<kalikiana> yes it's there, except the files exist, as the paste shows :-(
<vila> kalikiana: ooooh, you're trying to run a single test ! Do you still encounter the issue if you try to run the whole suite ?
<vila> kalikiana: they may exist but unittest doesn't know how to import them, it probably try to start with '... Oh wait, it's even clearer, it tries to import 'ubuntuuitoolkit.tests.test_launcher.LauncherQtTestTestCase.test_can_run_qt_test_case'
<vila> kalikiana: that's a test method in a test class, far from being a module
<kalikiana> no, but it takes ages to find out if it would then run the testâ¦ and I *know* that the test name is correct
<kalikiana> it's been run on another machine
<vila> kalikiana: indeed, the test name is correct, but that still doesn't make it a correct *module* name
<kalikiana> oh, I'll try if I can't list the modules somewhereâ¦ I know there was a command
<vila> kalikiana: that same invocation with that single test on the command line has run on a different machine ?
<kalikiana> yes
<ogra_> sil2100, me neither (at least about the testing ... there were unnsurprisingly 400 other mails in mine :P (like every day))
<vila> kalikiana: does 'phablet-test-run ubuntuuitoolkit.tests.test_launcher -v' works ?
<kalikiana> even autopilot3 list agrees the test is there
<vila> kalikiana: I'm not arguing the test name is not valid ;)
<vila> kalikiana: I'm reading your paste and interpret it as: look, I cannot import a test method, it's not a python module
<kalikiana> test_launcher â same exception
<vila> kalikiana: same traceback ? Some value in the exception ?
<kalikiana> same as before, no actual error message besides failure to import
<vila> kalikiana: can you just paste it ?
<vila> kalikiana: especially the ImportError: Start directory is not importable: part
<kalikiana> vila: http://paste.ubuntu.com/9143709/
<kalikiana> as far as I see exactly the same
<vila> well, no, now it complains that the *module* can't be imported
<vila> which at least makes a little more sense
<vila> python's unitest is notoriously bad at reporting import errors: it doesn't report *why* the import failed
<vila> kalikiana: I don't know how autopilot handle partial loading of a test suite :-/ But if you know how to run the full test suite and that pass, the issue is there: running a subset doesn't work for 'ubuntuuitoolkit.tests.test_launcher'.
<vila> kalikiana: I would try ''ubuntuuitoolkit.tests' and then 'ubuntuuitoolkit' if that makes sense
<vila> kalikiana: oh ! And that's python3.4 ! Gee, I'm out of my league :-/ Still stuck with 2.7 in all projects I'm involved :-(
<vila> kalikiana: on the other hand, it's unlikely that this particular piece of code has changed a lot (test discovery)
<ogra_> jibel, sil2100 https://bugs.launchpad.net/ubuntu-rtm/+source/cgmanager/+bug/1394919
<ubot5> Launchpad bug 1394919 in cgmanager (Ubuntu RTM) "constant crash in trying to collect info for recoverable error" [Undecided,New]
<ogra_> i think that is caused by the "UI freezes" fix
<vila> kalikiana: the way it work[ed] is that unittest starts with 'ubuntuuitoolkit.tests.test_launcher' and attempts to import the higher level modules (ubuntuuitoolkit.tests first, is it there ? No ? Try 'ubuntuuitoolkit', it it there ? No ? Highest level ? Yes -> fails)
<vila> kalikiana: if ''ubuntuuitoolkit.tests' has been imported but doesn't have a 'test_launcher' symbol defined -> fail (which could be why it says: AttributeError: 'module' object has no attribute 'test_launcher')
<jibel> sil2100, I didn't send any status yet, I must talk to Europeans first
 * kalikiana just discovered a "feature", ap runs even after the script was stopped - it would be useful if there was a way to actually control it :-P
<sil2100> jibel: ACK
<ogra_> https://bugs.launchpad.net/ubuntu-rtm/+source/unity-scopes-shell/+bug/1394922
<ubot5> Launchpad bug 1394922 in unity-scopes-shell (Ubuntu RTM) "scoperunner produces a lot of crash files in rtm 166" [Undecided,New]
<sil2100> hm, this doesn't look too good
<ogra_> neither does the cgmanager one
<ogra_> tehr scoperunner one seems to be the same we see in smoke testing
<Saviq> sil2100, hey, any idea about this failure https://launchpadlibrarian.net/190816573/buildlog_ubuntu-vivid-i386.unity8_8.01%2B15.04.20141121-0ubuntu1_FAILEDTOBUILD.txt.gz ?
<sil2100> jibel: just give us a sign on your verdict and we'll all forward it to victorp
<sil2100> Saviq: looking
<kalikiana> vila: FYI seems that I'm hitting a phablet-test-run bug, ap itself isn't to blame if I run it by hand on the device; http://paste.ubuntu.com/9144667/ https://bugs.launchpad.net/ubuntu/+source/phablet-tools/+bug/1394932
<ubot5> Launchpad bug 1394932 in phablet-tools (Ubuntu) "ImportError: Start directory is not importable on valid test folder" [Critical,New]
<seb128> could somebody review https://code.launchpad.net/~nik90/ubuntu-seeds/add-qml-connectivity/+merge/237442 ?
<seb128> does that make sense?
<seb128> I guess it needs to be done for vidid and not utopic in any case?
<seb128> ogra_, ^
<vila> kalikiana: \o/ Glad you're unblocked, sorry I couldn't help better...
<Saviq> sil2100, looks like I can reproduce that in a amd64 chroot locally (not in a native i386 chroot)
<jibel> popey, rhuddie will test the music-app
<rhuddie> popey, I'll start music-app shortly, so please let me know where to get latest version
<Saviq> hah
<Saviq> Mirv, https://launchpad.net/ubuntu/+source/connectivity-api
<Saviq> Mirv, this needs a rebuild against new Qt I believe
<Saviq> oh and we got a circular dep..
<Saviq> Mirv, http://paste.ubuntu.com/9145379/
<Saviq> which is the same as https://launchpadlibrarian.net/190816573/buildlog_ubuntu-vivid-i386.unity8_8.01%2B15.04.20141121-0ubuntu1_FAILEDTOBUILD.txt.gz
<Mirv> Saviq: it does not depend on the abi virtual packages, it shouldn't need a rebuild
<Saviq> Mirv, right, I think the problem might be the circular dep then
<Mirv> yeah, circular deps are always bad anyhow
<Saviq> unity8 â libconnectivity-qt1-dev â libconnectivity-qt1Â âÂ indicator-network â unity8
<Mirv> ouch
<Mirv> break it! :)
<Saviq> but how would that build on amd64...
<Saviq> yeah, I don't think indicator-network should dep on unity8...
<Saviq> but then that's what it uses to ask for passwords
<ogra_> seb128, needs a bug and approval from the mgmt if it is for rtm ...
<ogra_> for vivid it can indeed just go in
<ogra_> (if the packages are there and work :P )
<popey> rhuddie: its linked in the trello card
<rhuddie> popey, great. just wanted to check that was correct one. Thanks.
<victorp> jibel white or black smoke?
<ogra_> grey
<jibel> victorp, there is this crash ogra_ found
<jibel> bug 1394919
<ubot5> bug 1394919 in cgmanager (Ubuntu RTM) "constant crash in trying to collect info for recoverable error" [Undecided,New] https://launchpad.net/bugs/1394919
<Saviq> huh!
<jibel> likely a regression
<ogra_> victorp, bug 1394919 and bug 1394922 ... and Chipaca just reported a system-settings hang in bug #1394944
<ubot5> bug 1394922 in unity-scopes-shell (Ubuntu RTM) "scoperunner produces a lot of crash files in rtm 166" [Undecided,New] https://launchpad.net/bugs/1394922
<ubot5> bug 1394944 in ubuntu-system-settings (Ubuntu) "blank screen in battery â screen brightness" [Undecided,New] https://launchpad.net/bugs/1394944
<ogra_> i have also seen a good bunch of webapp crashes but then noticed that i had not cleaned the whole QML cache ... will keep an eye on that if anything happens again
<Saviq> Mirv, sil2100, not sure what I'm doing here, the FTBFS only occurs here when trying to build i386 from amd64 chroot, and comes down to indicator-network depending on python3-xdg:i386, which doesn't exist
<ogra_> the cgmanager stuff seems serious though ... i had three session crashes since upgrading to 166
<victorp> ogra_, is this all stuff from 166?
<ogra_> yes
<Saviq> Wellark, hey, who's maintaining connectivity-api?
<victorp>  ogra_ btw, I cant reproduce the screenbrightness issue
<victorp> (not that that means it is not a bug)
<ogra_> victorp, me neither, i asked for more info, it doesnt dsay rtm or krillin
<Saviq> Wellark, also, could we make indicator-network not depend on unity8? otherwise we're getting a circular build-dep since we're trying to use libconnectivity-qt1
<sil2100> victorp: in any case, bugs #1394919 and #1394922 look like pretty serious issues
<ubot5> bug 1394919 in cgmanager (Ubuntu RTM) "constant crash in trying to collect info for recoverable error" [Undecided,New] https://launchpad.net/bugs/1394919
<ubot5> bug 1394922 in unity-scopes-shell (Ubuntu RTM) "scoperunner produces a lot of crash files in rtm 166" [Undecided,New] https://launchpad.net/bugs/1394922
<victorp> ogra_, so far worring bugs, but none of them topblockers
<sil2100> jibel: any other serious issues reported during regression testing?
<sil2100> Saviq: hmmm
<ogra_> victorp, you think the session crashing isnt one ?
<victorp> well, what is the impact to the user?
<victorp> seems like the systems manages not to let the crashes impact UX
<jibel> sil2100, if you give me 30 minutes I'll finish the list of issues we found :)
<victorp> jibel, that sounds like a good idea :)
<sil2100> Saviq: sorry, was in a meeting - this sounds a bit strange, I think connectivity-api was managed by Wellark and pete-woods
<pete-woods> sil2100: don't finger me on that one :p
<sil2100> jibel: waiting with anticipation ;)
<ogra_> victorp, apps that were running dont work anymore after a session crash
<pete-woods> it's Antti's baby
<ogra_> until you reboot
 * jibel kills OSD
<sil2100> pete-woods: ok, sorry ;p Just remember seeing you in the initial commits ;)
<ogra_> or kill them explicitly
<victorp> ogra_, ah! yes that is nasty
<victorp> which one is that?
<victorp> 919 or 922?
<ogra_> victorp, the session does the lifecycle mgmt ... if it dies the apps stay suspended ... dangling dead
<ogra_> thats 919
<Saviq> sil2100, so, if I understand correctly, anything that would like to link against libconnectivity-qt1 will fail on i386 if the builder's amd64
<victorp> ogra_, ah, now I have seen your comment in the bug..
<ogra_> victorp, i havent heard from others about such an issue though ... (and i used the phone a lot last night to keep it busy)
<victorp> could we put the impact on the bug please
<ogra_> victorp, we usually do afrer we have confirmation ...
<victorp> ogra_, apps stop working? nope I have not seen it either
<ogra_> victorp, kill unity8 from the commandline with some apps open
<victorp> ogra_, oks, well let see if it gets confirmed, then yes it looks like a blocker
<ogra_> then try to start the apps that were open
<ogra_> they wont start
<ogra_> (after the session respawned i mean)
<ogra_> we are missing a watchdog for this that cleans up running apps when the session dies
<ogra_> (there is work on forcing a reboot when the session crashes ... but thats still in early stages)
<Saviq> Wellark, where RU?
<Saviq> when you're needed :P
<ogra_> victorp, hmm,, llooks like the brightness issue was actually 166 and krillin ...
<ogra_> victorp, system-sessings is mostly pure QML ... given the QML cache issues it could well be caused by the not cleaned up cache
<jibel> ogra_, I cannot reproduce the brightness issue either, but I completely wiped the phone.
<victorp> ogra_, or it could be the dbus high load that he mentions, but seems like noone can repro
<ogra_> we should take all issues in apps with a grain of salt on 166 ... especially from people that OTAed to 166
<victorp> jibel, I ota'd.. but GM will be a fresh install anyway :)
<ogra_> there is confirmation from a community person
<victorp> ogra_, right, but not wide spread to make it a blocked imho
<victorp> plus as you said might be precompiling
<ogra_> right
<ogra_> we need to be careful about judging apps in general on this image
<ogra_> victorp, oh, and seems rickspencer ran into a 100% CPU dbus bug yesterday ... most likely the one we have open already ...
<ogra_> (we duplicated it during landing meeting)
<victorp> yeah, I run into one too
<victorp> they need to be fixed for ota-1, that is for sure
<sil2100> Yeah, but the 100% CPU issue in dbus is investigated all the time, not sure if we'll be able to get a fix quick
<sil2100> It seems to be a tricky issue
<ogra_> sil2100, well, i guess silo16 will at least killl a part of that
<ogra_> but thats not for landing yet
<sil2100> tvoss: hey! Did you have any luck with the 100% CPU dbus investigation?
<sil2100> ogra_: right...
<tvoss> sil2100, nope, not yet
<ogra_> and as i said ... just a part ..
<Saviq> sil2100, what's even weirder... it built fine yesterday https://launchpadlibrarian.net/190747862/buildlog_ubuntu-vivid-i386.unity8_8.01%2B15.04.20141120-0ubuntu1_UPLOADING.txt.gz Â¿?
<Saviq> on an amd64/i386 machine, too
 * Saviq does not get it :|
<Saviq> /food
<sil2100> Saviq: wait, are you sure it's not transient? Ah, right, you an repro on a local chroot... Let's take a look if there have been any changes in the archive
<tvoss> sil2100, victorp we are all looking into the issue
<sil2100> tvoss: ogra_ mentioned that dbus is a lot quieter with the new upowerd, as seen in silo rtm 16 (not for landing)
<sil2100> Saviq: I have no idea what changed and suddenly cause this to fail, nothing got uploaded to vivid in the meantime that could have changed the situation
<sil2100> Saviq: I also saw that it actually passed yesterday on an older builder
<sil2100> But that shouldn't have any effect
<Saviq> sil2100, yeah, it's *weird*, it's like apt resolution stopped working suddenly
<Saviq> sil2100, as the actual failure for me seems to be that the dep chain results in python3-xdg:i386, which for some reason is not fulfilled by python3-xdg:all ??
<oSoMoN> trainguards: can oxide-qt 1.3.5-0ubuntu1 be binary-copied from https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa to vivid silo 17 ?
<sil2100> Saviq: something is b0rken it seems, will still look into that after lunch
<sil2100> oSoMoN: sure
<Saviq> sil2100, thanks
<sil2100> But so far this looks like a ghost story ;) But I'm sure there's a logical explaination
<oSoMoN> sil2100, thanks! the PPA size might need to be increased first, as it already contains a copy of oxide (1.3.4)
<sil2100> I just saw that, yeah, we'll have to poke someone regarding that
<sil2100> Let me go to webops
<Mirv> actually binary copies might work regardless
<Mirv> yes, it'd work
<sil2100> Mirv: they overwrite older packages? Or not obey the size limit?
<Mirv> sil2100: they don't obey / check only if it's under the limit before starting the copy. so yes it'd work.
<Mirv> sil2100: so I've had 20GB of stuff in 2GB PPA when doing Qt landing backups ;)
<sil2100> Mirv: yay \o/ Ok, let me do that then
<sil2100> Wow
<Mirv> don't file a bug, for me it's a feature
<ogra_> haha
<sil2100> I'm pretty sure no one here would want this feature to go away ;)
<sil2100> oSoMoN: ok, copied, should be published in the PPA soonish
<oSoMoN> sil2100, awesome, thanks!
<oSoMoN> thatâs an awesome feature IÂ would say :)
<john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20141121-7e18b86.tar.xz
<john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20141121-7e18b86.changes
<john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-testresults-20141121-7e18b86.ods
<sil2100> Wow, another vivid tarball?
<john-mcaleely> vivid device tarball for krillin. ogra_ sil2100 jibel ^
<john-mcaleely> one, small, important change
<ogra_> john-mcaleely, go ahead
<john-mcaleely> we can get some run time before we migrate it to OTA
<ogra_> the gpg stuff ?
<sil2100> john-mcaleely: sounds nice
<sil2100> It's generally good to use vivid as the testing platform
<john-mcaleely> ogra_, yeah, the gpg stuff
<john-mcaleely> sil2100, ogra_ I'll push it now then
<ogra_> sil2100, it isnt ... he hates developers and wants to make our life harder by adding secutity checks !!!
<ogra_> :)
<john-mcaleely> lol
<sil2100> It's all for our good
<john-mcaleely> or maybe
<john-mcaleely> bwahahaha
<sil2100> !!!
<ogra_> hah
<sil2100> ;)
<john-mcaleely> sil2100, ogra_ pushed.
<ogra_> thanks :)
<sil2100> psivaa: come to think of it, hmmm
<sil2100> psivaa: we don't have vivid krillin smoketesing results? Since the rtm-dashboard only has utopic results - and those seem really old (from last month)
<psivaa> sil2100: let me take a look, not sure if that was requested to be setup
<ogra_> it was surely there before
<psivaa> sil2100: ogra_: they are running,  but not being pushed to the rtm dashboard. now that http://dashboard.ubuntu-ci:8080/ is disfunctional, and vivid not being rtm, we need to find a home for that
<psivaa> i'll raise it in the meeting today
<ogra_> thanks !
<sil2100> Right, thanks!
<sil2100> rsalveti: hey!
<bzoltan> sil2100:  may i ask for a reconfig of the Silo28. I just added the gles branch what comes from the different project.
<bzoltan> or Mirv ^
<popey> hmm, my phone isn't showing up in adb devices...
<popey> even after a reboot
<sil2100> bzoltan: doing!
<bzoltan> sil2100:  thanks
<Mirv> bzoltan: I lost my mouse pointer and I'm in the hangout... it's a bit hard to find buttons to push :D
<sil2100> bzoltan: done :)
<sil2100> Mirv: ouch!
 * sil2100 goes to lunch finally
<Davmor3> Hey guys I see an issue with ciborium it keeps saying my card is connect and disconnect
<Davmor3> abyway back to the holiday now
<popey> ok, can't get the phone to show up at all over adb
<popey> mako is fine, krillin not
<bzoltan> sil2100: Mirv: I am done with silo28. I have pasted the URL to the test logs. The silo is still creating the -gles package, but that is not the scope of the tests... Once the -gles are done, would you please push the new UITK to Vivid?
<rsalveti> sil2100: hey
<om26er> ogra_, Hi! I am testing silo 2 -- What is the regression potential for this change ?
<ogra_> the first startup of apps after OTA will be slower than usual to create the new cahe
<ogra_> 1sec max
<ogra_> om26er,  oh, and beyond the above ... zero
<om26er> ogra_, alright, good to know.
<sil2100> jibel, ogra_, om26er: are both the oxide and qml-cache silos being signed-off right now?
<ogra_> no
<ogra_> only qml
<ogra_> oxide gets its own image after promotion
<om26er> one... at a time.
<Mirv> bzoltan: ok. and I'm ready with 002 to vivid.
<sil2100> Ok, now I see :)
<om26er> ogra_, Well the silo seems to do whats written on the tin. Should I just approve or try it a second time ?
 * om26er is clueless ;-)
<rhuddie> jibel, popey, I finished testing the music app. No issues found. I recorded results here: https://docs.google.com/a/canonical.com/spreadsheets/d/1gFoUz9zQ38LovfLLIcHU5SHTuDDBQvHTSPVcrIxJUlc/edit#gid=0
<ogra_> om26er, if the cache is empty after OTA we're fine
<popey> rhuddie: magic, thanks very much
<ogra_> om26er, a second run should just give you the same result ... else we have a very serious upstart probllem ;)
<popey> rhuddie: "Needed to reboot after install for app to work (othwise it just displays spinner)" - pull down on app scope should have worked.
<popey> can't believe we still have that bug
<popey> been there since day 1.
<om26er> ogra_, it was all clear till your first reply. Second reply made it a little confusion, retry or retry not ? :p
<rhuddie> popey, the app launched, but displayed the spinner instead of displaying "No music found"
<popey> rhuddie: even after pulling down to refresh click scope?
<ogra_> om26er, dont, unless you want to waste time :)
<rhuddie> popey, I didn't do that, so let me check again
<popey> rhuddie: i have experienced that myself, its because the click scope still points to the old app version you had. either pull down or search for music in the scope at the top and it launches
<om26er> okki, approved.
<ogra_> yay, thanks
<sil2100> rsalveti: hey, just wanted to know if there was some progress related to the pulseaudio part of bug #1391230
<ubot5> bug 1391230 in pulseaudio (Ubuntu RTM) "[TOPBLOCKER] web audio, pulse runs at 6% and screen will not blank on idle" [Critical,Confirmed] https://launchpad.net/bugs/1391230
<sil2100> ogra_, om26er: \o/
<sil2100> Let me publish
<rsalveti> sil2100: nops, still investigating
<ogra_> publishing
<rsalveti> should know more on monday
<sil2100> ...and ogra_ was faster
<sil2100> rsalveti: thanks :)
<ogra_> heh, sorry :)
<AlbertA2> ogra_: I'm making a new mir release, but want to coordinate the seed change (https://code.launchpad.net/~mir-team/ubuntu-seeds/use-new-Mir-metapackages/+merge/242408)
<sil2100> ogra_: ;p
<ogra_> AlbertA2, yeah, i saw that, this is vivid only, right ?
<sil2100> Sorry is not enough! *runs away in tears*
<AlbertA2> ogra_: right
 * ogra_ hugs sil2100 
 * sil2100 hugs ogra_ back
<Mirv> ogra_: UITK would need core-dev ack. https://ci-train.ubuntu.com/job/ubuntu-landing-028-2-publish/4/artifact/packaging_changes_ubuntu-ui-toolkit_1.1.1338+15.04.20141121-0ubuntu1.diff
<Mirv> they manually fixed some changelog entries plus added new test related dependencies
<ogra_> Mirv, looks ok to me, i hope their bzr tree can cope with teh changelog hacking :P
<Mirv> ok. I hope so too :)
<rhuddie> popey, confirmed it is working after doing as you suggested
<AlbertA2> ogra_: so how do we go about that? publish mir first then you'll make the seed change?
<ogra_> AlbertA2, is Mir ready to land in a silo already ?
<AlbertA2> ogra_: yes I just ok'ed. silo 009
<ogra_> AlbertA2, then publish it, i'll do the seed change and upload a new meta to vivid
<ogra_> seed changess and their packages should always land together in the same image ... beyond that the order does not matter
<ogra_> (we build vivid images at 2am UTC, still plenty of time)
<AlbertA2> ogra_: ok good to know thanks
<AlbertA2> trainguards: vivid silo 009 is ready to publish
<popey> rhuddie: awesome
<sil2100> Mirv: so, the vivid plans to have Qt 5.4.0, right?
<AlbertA2> trainguards: oops sorry, branches TAed now...for mir
<Mirv> ogra_: I wonder if you'd be ok with reviewing that new Mir packaging changes too.. https://ci-train.ubuntu.com/job/ubuntu-landing-009-2-publish/51/artifact/packaging_changes_mir_0.9.0+15.04.20141120.1-0ubuntu1.diff it's quite big, but _mostly_ because lot of cmake file changes (included for possible interest, debian/ is what needs acking) and because of renamed packages
<Mirv> sil2100: yes, so this week I've been trying to get to the point where I have fast&ugly packages that can be used to detect bugs early
<Mirv> sil2100: next week there should be hopefully release candidate from upstream, instead of the beta I've now used
<ogra_> Mirv, phew ... not a small one ... but ack
<sil2100> Mirv: ok, then I'll prepare a merge with a fix for appmenu-qt5 not building but not release it for the time being
<jibel> ogra_, what's the ETA for the new build?
<alan_g> cihelp: this has been saying "Recording test results" for at least half an hour (which suggests there's a problem somewhere) - http://s-jenkins.ubuntu-ci:8080/job/mir-vivid-amd64-ci/193/console
<ogra_> jibel, the package just landed, starting a build now ... ~90min to 2h
<jibel> k
<ogra_> build triggered
<fginther> alan_g, the problem in this case is that build 192 is going very slow. and jenkins can't complete build N if build N-1 is not finished
<sil2100> rtm -proposed migration... so nice
<fginther> alan_g, I've been looking at the slow build for the last 20 minutes or so and I think I've got it unwedged
<fginther> alan_g, dammit, it timed out
<sil2100> jibel: so QA is not doing exploratory testing anymore, right? I remember Dave doing that in the past
 * alan_g is sympathetic to fginther's frustration
<jibel> sil2100, we do, when there is time left between silos and images
<Wellark> Saviq: I had away message in canonical-irc, as you get kicked out on multiple channels if you use "public" away in your nick
<Wellark> Saviq: I will see what I can do with the deps
<Wellark> libconnectivity-qt is not coming from i-network source
<Saviq> Wellark, I'm not really sure what's teh culprit
<Saviq> Wellark, no, but connectivity-api depends on i-n
<Saviq> libconnectivity-qt1 that is
<Wellark> Saviq: it probably should just recommend
<Wellark> would that fix it?
<Saviq> Wellark, well, can it just recommend?
<Wellark> Saviq: sure. if i-network is not around (hence no connectivity dbus-service running) libconnectivity-qt1 falls back to "connected"
<Wellark> there is no hard coupling
<Wellark> other than we know that i-network provides the connectivity-service libconnectivity-qt1 tries to poke over dbus
<imgbot> === trainguards: RTM IMAGE 167 building (started: 20141121 15:20) ===
<Wellark> Saviq: i-network must depend on unity8
<Wellark> as it depends on the snap-decisions that unity8 provides
<Saviq> Wellark, yeah I know why
<Wellark> one way to break this circular dependency problem would be to introduce two meta packages
<Wellark> unity-notifications-service
<Wellark> and connectivity-service
<Wellark> as, i-network depends on the unity-notification-service, which is actually implemented by unity8
<Wellark> and then again libconnectivity-qt1 dependes on connectivity-service which just happens to be impemented by i-network right now
<Wellark> but didrocks might not like the idea ;)
<Wellark> although IMO it would make the dependencies more explicit
<Wellark> when something depends on a well-known dbus-service, it should not matter which package implements it
<Wellark> from the user point of view
<Mirv> sil2100: if possible, I prefer conditional changes that can be landed beforehand, so that nochange rebuild is enough when landing Qt
<Wellark> or "client"
<Wellark> sil2100: can we throw in two metapackages --^
<fginther> alan_g, I ended up cleaning up a couple runaway process and restart that build that timed out.
<fginther> alan_g, things look better now, but will need to figure out something to prevent this in the future
<Mirv> so.. next vivid image will have new qtbase, new ui-toolkit and new mir. what could possibly go wrong.
<balloons> cihelp, I need a job on s-jenkins updated (the docviewer-app-click job)
<retoaded> balloons, updated in what way?
<balloons> retoaded, it looks like it's still building with trusty, and in general might not be the current way to build clicks. It's sat unused for some time
<balloons> retoaded, you can look at clock-app-click as an example
<retoaded> balloons, ack, will work it in amoung the morning full of meetings
<balloons> retoaded, ty
<alan_g> fginther: thanks.
<bfiller> sil2100: can you republish ubuntu silo 15, MR's are approved now. also need a silo for line 60 please
<pstolowski> trainguards, hello, may i ask for a silo for line #59?
<oSoMoN> trainguards: can vivid silo 17 be published, please?
<oSoMoN> that was quick, thanks to whoever did it :)
<sil2100> o/
<bzoltan> sil2100: Mirv: thanks for midwifing the UITK landing.. you guys just rock!
<sil2100> jibel: btw. what about sanity testing of vivid images? Does that still happen for every vivid image?
<Mirv> bzoltan: you're welcome
<om26er> mterry, Hi!
<mterry> om26er, hello!
<imgbot> === trainguards: RTM IMAGE 167 DONE (finished: 20141121 16:30) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/167.changes ===
<om26er> mterry, I was playing around and found that pin code lock can be bypassed easily when unity8 is start.
<mterry> om26er, seems bad
<ogra_> jibel, sil2100 victorp ^^^^^ image 167 for you
<sil2100> Wow, that seemed somehow fast!
<victorp> ogra_, what a service!!
<victorp> :)
<sil2100> jibel: can we have someone sanity testing that + delta?
<ogra_> 70min only !
<ogra_> thats a new record
<sil2100> But the changelog is huge
<om26er> mterry, when the phone starts just swiping the greeter shows 'Scopes' with loading spinner and after that dash just shows. isnt' that alarming ?
<ogra_> yeah, scary
<ogra_> sil2100, but we can blame om26er, he tested all the changes that landed there
<ogra_> in case something is broken :)
<mterry> om26er, I feel like that might be a race between PAM and your finger.  But we have(had?) code that prevented that race...
<mterry> om26er, is this vivid or rtm?
<om26er> ogra_, I hope I did not break anything
<om26er> mterry, rtm and its always reproducible
<ogra_> om26er, no worries :) just kidding
<mterry> om26er, but it's a speed thing?  Like, if you wait a second or so, you do get the lockscreen right?
<om26er> mterry, yes, right.
<om26er> might make sense if lockscreen was part of unity8 and not unity8-dash ?
<mterry> om26er, OK.  file a bug and I'll look at it today.  It is part of unity8, not the dash
<om26er> oSoMoN, Hi! while testing silo3 I found pulseaudio is still eating 6% cpu when i swipe away the browser while grooveshark is playing
<om26er> The actual fix is working though i.e. the screen blanks as it should, even on the first try.
<oSoMoN> om26er, yes, thatâs expected, the fix in oxide only fixes the screen blanking bit, the rest will be addressed separately in pulseaudio itself
<om26er> oSoMoN, ack, thanks :)
<om26er> oSoMoN, can you tell whats the regression potential of that fix ? looking at the diff it looks pretty straight and safe to me.
<oSoMoN> om26er, never ask that question to a developer who wants to land a fix :)
<oSoMoN> om26er, that said, Iâd say the regression potential is 0
<ogra_> ask his manager instead :P
<oSoMoN> om26er, yeah, itâs very safe indeed
<om26er> Hey Bill ? :p
<ogra_> lol
<sil2100> ;)
<jibel> om26er, don't expect a developer to answer anything else than 0 to this question ;)
<om26er> In some cases that reply is actually a helper in putting stress on certain features.
<sil2100> jibel: who is taking care of testing 167?
<ogra_> sil2100, i'll be a little late, other meeting runnin over
<sil2100> ogra_: ok
<jibel> sil2100, rvr rhuddie robotfuel are on it
<ogra_> tedg, soo ... seems we have some new cgmanager issue
<tedg> :-/
<tedg> ogra_, bug number?
<ogra_> tedg, bug 1394919 ... jibel has a bunch more info he hasnt added there yet
<ubot5> bug 1394919 in cgmanager (Ubuntu RTM) "constant crash in trying to collect info for recoverable error" [Undecided,New] https://launchpad.net/bugs/1394919
<ogra_> seems OOM related
<tedg> Hmm, we could disable that recoverable errorâ¦
<tedg> Was trying to help track down that cgmanager connection issue.
<tedg> That we worked around with the timeout.
<ogra_> well, thats only fallout
<jibel> tedg, it's just a side effect, at some point you cannot launch any app and you have to reboot
<ogra_> there is some issue in cgmanager ... that apport cant collect info is another issue
<tedg> It seems probably a root/user thing?
<tedg> PermissionError: [Errno 13] Permission denied: '/proc/642/exe'
<tedg> Is recoverable_error setuid ?
<tedg> Nope
<tedg> bdmurray, ev, have you guys discussed making recoverable_problem setuid ?
<tedg> It seems to be erroring when we try to ask it to report on a root process as the user.
<tedg> https://errors.ubuntu.com/oops/c25e8678-70f2-11e4-976f-fa163e4aaad4
<sil2100> robru: don't publish silo 003 rtm yet
<tedg> Nicely, it turns itself in :-)
<sil2100> robru: just in case - let's wait for confirmation from jibel and QA if the current image is promotable
<robru> sil2100: i was wondering ;-)
<sil2100> If we get a green flag from them, I guess we can publish this + the music-app in the store ;)
<sil2100> (never enough of safety)
 * tedg puts on his IRC helmet
<robru> bzoltan: vivid 15
<bzoltan> thanks robru
<robru> bzoltan: you're welcome
<ogra_> plars, happy birthday !
<plars> ogra_: thanks!
 * Mirv wonders why he's here
 * ogra_ wonders why Mirv wonders why he's here 
<Mirv> ogra_: because I kind of EOD'd earlier, then came back to see qtbase migrate to release pocket properly, and then sort of hanged around to do other stuff
<ogra_> heh
<ogra_> like we all do :)
<popey> heh
<Mirv> also, snow
<ogra_> brrr
<Mirv> http://people.canonical.com/~tjyrinki/snowproof.jpg from visit to the nearby store
<popey> awwww
<popey> wish we had snow
 * ogra_ doesnt 
<Mirv> the fun thing was that there zero snow at 2.30pm. then I had SDK hangout, and at 4pm it didn't snow anymore but it looked like that.
<Mirv> and I didn't look out of the window meanwhile
<popey> do your cats like the snow?
<popey> mine go mad for it
<ogra_> mine love it
<ogra_> they need a few days to adapt
<ogra_> werid to walk on etc
<ogra_> but once they overcame that they love it
<bzoltan> popey: ogra_: So you like cats... Now I start to understand things
<Mirv> they kind of love it but we don't take them outside in the winter
<Mirv> mostly
<ogra_> i like dogs ... but i lack time
<bzoltan> popey: ogra_: according to Olga's survay you both have Cheguevara shirts too
<ogra_> lol
<popey> wat
<Mirv> and the white one doesn't like "outside" anyway. but he likes snow on the balcony.
<ogra_> never had one, no
<mterry> om26er, you still around?  I'm hopeful that https://code.launchpad.net/~mterry/unity8/early-disable/+merge/242517 fixes your security exploit
<popey> i have an RMS Che t-shirt
<sil2100> Oh oh! Snow!
<om26er> mterry, hey, yes.
<ogra_> bzoltan, but i suspect popey is one of these communist male east uk'ers that like ubuntu :)
<sil2100> I mean, on Mirv's picture
<sil2100> Here it's still just cold...
<popey> http://1.bp.blogspot.com/-nneSxLZA9zk/TxenMQR94gI/AAAAAAAADnY/DLjgtSbcV-A/s1600/che-stallman-tshirt-show.jpg
<mterry> om26er, you shouldn't need to rebuild, could simply edit the file in place
<bzoltan> popey: https://yougov.co.uk/profiler#/Ubuntu/lifestyle
<Mirv> sil2100: :)
<om26er> mterry, ok i'll edit the file and delete the qml cache.
<popey> haha brilliant
<ogra_> bzoltan, geez, that food pic is right on the spot !
<bzoltan> ogra_:  no shit :)
<popey> brilliant
<ogra_> i dont live in east UK though
<Mirv> wow, I didn't know it's a thing outside Finland http://en.wikipedia.org/wiki/Pulla
<ogra_> (and i think i overcame my commie phase with 19 or so ...)
<bzoltan> ogra_: but have the ticket already, right?
<Mirv> I mean that's 1st on the Ubuntuer list of foods..
<om26er> no cwaye1 today ?
<Mirv> Favourite Dishes
<ogra_> yummy !
<popey> never heard of pulla
<Mirv> I wonder how it got to the top of that list
<bzoltan> Mirv:  Damn it.. I forget this one -> we need this landed in order to make the silo15 build -> https://code.launchpad.net/~zeller-benjamin/kubuntu-packaging/qtcreator-qmakeprojectpatch/+merge/240827
<Mirv> bzoltan: let's put it into that silo then
<bzoltan> Mirv:  I added  it...
<Mirv> bzoltan: not as MP, fixing
<Mirv> bzoltan: it's in PPA now https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-015/+packages
<bzoltan> Mirv:  thank you!
<bzoltan> Mirv:  could you please reconf the silo too?
<bzoltan> or robru ^
<om26er> mterry, confirmed that fixes the issue.
<mterry> om26er, sweet, thanks!
<robru> Mirv: bzoltan on it
<om26er> mterry, can you please propose that for rtm branch as well ?
<mterry> om26er, uh...  maybe?  Saviq, we're doing separate rtm branches now?
<robru> mterry: you're sure not landing new features in rtm ;-)
<mterry> robru, no, not that we'd sync trunk.  Just last time I remember Saviq was making the rtm backport branches himself
<robru> ah
<bzoltan> robru: ogra_^ WOW, that is new
<robru> bzoltan: it's just a network error, try again
<bzoltan> robru:  OK... looks scary .. i am faint hearted at 9pm Friday
<robru> bzoltan: yeah sorry, error handling from the chroot is a bit rubbish. the python script just sees 'returned exit code 1! raise exception!' so you have to check the log for the real error, which it turns out it just failed to download some file
<Mirv> robru: the other mp just needs to be removed.. I thought I did that. it's manually uploaded.
<robru> Mirv: which mp?
<robru> bzoltan: weird, different network issue this time. try again! I guess our network is having trouble at the moment.
<Mirv> robru: qtcreator mp, qtcreator is in manually uploaded sources now
<robru> Mirv: spreadsheet row looks fine to me? did you fix it already?
<Mirv> robru: citrain blows up if same project in both. sorry, on mobile now.
<robru> Mirv: is 'qtcreator-plugin-ubuntu' the same as 'qtcreator'?
<Mirv> robru: no, that needs to be there. there was qtc mp too there
<robru> Mirv: I think it's fixed now. I only see qtcreator-plugin-ubuntu and kubuntu-packaging
<robru> oh I guess the silo needs a reconfig though
<robru> bzoltan: hang on
<Mirv> robru: remove the kubuntuthing, = qtcreator
<robru> oh, weird
<robru> this is why the earlier versions of citrain considered it a hard error for the lp project name not the match the debian source package name
<robru> now we just warn on that...
<robru> bzoltan: ok building https://ci-train.ubuntu.com/job/ubuntu-landing-015-1-build/70/console
<Mirv> the qtc needs to finish first before the plugin succeeds
<Saviq> mterry, in general I stick to a single "staging" branch to merge into rtm, but we've a silo waiting for QA for over a week now :/
<Saviq> mterry, so if there's a TOPBLOCKER it might need to get in separately
<bzoltan> thanks robru for fixing it
<robru> bzoltan: you're welcome
<ogra_> sil2100, so i guess we can let oxide and music app in now ... (providing they passed QA)
<ogra_> === Image RTM #9 Promoted !!! ===
<ogra_> (that is krillin: 167, mako: 138 and emulators: 132)
<balloons> retoaded, you find anything with the docviewer job?
<retoaded> balloons, am actually working on it now.
<retoaded> should have it updated shortly
<oSoMoN> trainguards: can you please publish RTM silo 3 ?
<robru> oSoMoN: I dunno am I allowed to? I thought rtm was locked down? ogra_ ^
<ogra_> robru, oxide and music-app are alllowed in
<robru> ogra_: ok... i don't see a bug reference or anything ;-)
 * oSoMoN bribed the PM team to get his fix in
<ogra_> bug 1391230
<ubot5> bug 1391230 in pulseaudio (Ubuntu RTM) "[TOPBLOCKER] web audio, pulse runs at 6% and screen will not blank on idle" [Critical,Confirmed] https://launchpad.net/bugs/1391230
<robru> oh it is there, nm
<robru> ok, publishing
<ogra_> :)
<ogra_> cool
<oSoMoN> thanks!
<ogra_> popey, what about music ?
<robru> oSoMoN: you're welcome
<retoaded> balloons, http://s-jenkins.ubuntu-ci:8080/job/docviewer-app-click/25/console
<om26er> mzanetti, what packages should I install to get useful stacktrace for unity8-dash crashes ?
<mzanetti> om26er: unity8-dbgsym, qtdeclarative5-qtmir-plugin-dbgsym. you need to add ddebs.ubuntu.com as apt source
<mzanetti> om26er: well, reading the stacktrace it should tell you what libs are involved
<mzanetti> if it just says ??? then you're missing the according dbgsym package
<om26er> mzanetti, great, i'll try that.
<balloons> retoaded, awesome! We haz a click package, wahoo!
<balloons> popey, if you are reading this, I'd like to put a docviewer click in the store. What says ye?
<om26er> mzanetti, seems there no ddebs.ubuntu.com repo for 14.09 (rtm) ?
<mzanetti> I think there should be, although I haven't ever tried for rtm myself
<alexabreu> can a trainguard reconfig silo 29 ?
<tedg> trainguards, can I get a vivid silo for line 64 please?
<robru> tedg: vivid 2
<tedg> robru, Thanks!
<robru> tedg: you're welcome
<ogra_> SIGH
<ogra_> hard UI hang again ... with 167
<ogra_> bah, wasnt a hard hang it was apport creating the useless recoverable problem thing
<ogra_> hmm, but it seems to have killed the session without having it restart ... seems my lifecycle mgmt was gone for short ... i have a bunch of dangling apps in the bg that i cant start anymore
<ogra_> tedg, http://paste.ubuntu.com/9156976/ ...
<ogra_> that is what i have in cgmanager log after the crash happened
<popey> balloons: does it work?
<tedg> ogra_, hallyn said that "sendmsg" failed one is cgmanager crashing.
<popey> 20:38:57 < ogra_> popey, what about music ?
<tedg> ogra_, There's where we were getting the cgmanager connection hang.
<popey> ogra_: i thought we agreed during the landing call not to upload music to the store until an image had been promoted
 * popey scrolls back further and sees 20:13:08 < ogra_> === Image RTM #9 Promoted !!! ===
<ogra_> popey, we did :)
<popey> \o/
<popey> balloons: you about? :D Might have two uploads for you.
<tedg> ogra_, I'm trying to land the vivid fixes in ppa 2. You might try the packages and see if it helps.
<ogra_> tedg, i added syslog from the time where it happens too ... dmesg is largely the same though
<balloons> I could be
<balloons> popey, lol, it just built, I didn't try it, haha
<popey> balloons: ok, priority 1 is music app pls. Specifically http://popey.com/~alan/com.ubuntu.music_2.0.745_all.click which has had QA sign off
<balloons> k, next?
<popey> I'd like to test docviewer some more before uploading
<balloons> popey, no worries
<popey> i see 0.1.41 in jenkins
<balloons> yes
<popey> right, now, why does adb not work on my krillin please?
 * balloons is installing
<balloons> popey, https://myapps.developer.ubuntu.com/dev/click-apps/143/changerequest/ btw
<balloons> doc viewer runs, that's encouraging
<ogra_> did you already upload ?
<ogra_> (doc viewer that is)
<popey> ogra_: no
<popey> however, music approved to store
<balloons> sweet.. download pdf in browser, open with doc viewer
<balloons> boom pdf
<ogra_> you are not supposed to download bomb building instructions from the internet
<balloons> so popey at least the basics work. I couldn't get photo viewer to work, might try something different
<balloons> no search or page goto
 * popey pushes to phone
<popey> as magically adb suddenly works
<popey> anyone know where "summary goes here" comes from when you use pkcon?
<tedg> popey, Guessing an unimplemented feature in the click backend.
<ogra_> sil2100, triggering 168 now ... both bits we want are in place
<popey> great
<popey> tedg: ok. should I file a bug do you think?
<tedg> popey, Naw, I don't think a bug will help.
<imgbot> === trainguards: RTM IMAGE 168 building (started: 20141121 22:10) ===
<balloons> tedg, you win IRC today.. awesome
 * balloons enjoys the sarcasm real or invented
<tedg> Heh
<balloons> popey, ogra_ docviewer published
<balloons> enjoy your weekend!
<popey> BOOOOOOOOOOOOOOOOOOOOOOOOM!
<popey> thanks balloons !
<ogra_> yay !!!!
<tedg> trainguards, can you please publish vivid/2 ?
<tedg> Ah, symbols fix.
<popey> ogra_: i know I have mentioned this multiple times today but adb is really unreliable since 166
<imgbot> === trainguards: RTM IMAGE 168 DONE (finished: 20141121 23:20) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/168.changes ===
<robru> wow, latest lunch ever. bbiab
#ubuntu-ci-eng 2014-11-22
<alex-abreu> trainguards can you reconfigure L 49?
<robru> alex-abreu: done
<alex-abreu> robru, thx
<robru> alex-abreu: you're welcome!
<imgbot> === trainguards: IMAGE 29 building (started: 20141122 02:05) ===
<robru> bfiller: congrats on being the first person to enjoy automatically merge&cleaned silos ;-)
<imgbot> === trainguards: IMAGE 29 DONE (finished: 20141122 03:25) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/29.changes ===
<bzoltan> robru:  do you know why the CI sheet and the silo dash tells that some builds are failed in silo15 when all packages are there and good
<robru> bzoltan: oh yeah, https://ci-train.ubuntu.com/job/ubuntu-landing-015-1-build/72/console shows a build failure, but if you check the versions, it's actually the failure from the previous build. that's a known issue with the new watch_ppa, I'll fix that soon. For now just do a WATCH_ONLY build and it'll straighten itself out
<robru> (the issue is that lp is reporting the previous upload even after a new upload supercedes it)
<bzoltan> robru:  Super... the silo15 is good to go then
<robru> bzoltan: great, you can help me test automatic merging and cleaning ;-)
<bzoltan> robru:  On Monday i will land the rest of the qmake support
<bzoltan> robru:  with pleasure :)
<bzoltan> robru:  just tell me what to do
<robru> bzoltan: just do a WATCH_ONLY build on the silo for now
<bzoltan> robru: ok
<robru> bzoltan: ok! so in ~5 minutes that build job should report success, and then when it does I'll hit publish. then once it migrates it should just automatically merge. it should be so fast that the bot doesn't even ping 'you can merge and clean' at all... it should just go from 'one package in the proposed pocket' to 'merging...'
<bzoltan> robru:  sounds great
<robru> bzoltan: hopefully it works! I worked already once today but then I made some changes...
<robru> bzoltan: just approve that merge ;-) https://code.launchpad.net/~zeller-benjamin/qtcreator-plugin-ubuntu/qmake-support/+merge/240839
<bzoltan> robru:  ehh.. I missed that
<robru> booyeah
#ubuntu-ci-eng 2014-11-23
<imgbot> === trainguards: IMAGE 30 building (started: 20141123 02:05) ===
<imgbot> === trainguards: IMAGE 30 DONE (finished: 20141123 03:25) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/30.changes ===
 * ogra_ sighs
<ogra_> bug 1394919 is biting me heavily today ... 3rd reboot because no apps started
<ubot5> bug 1394919 in cgmanager (Ubuntu RTM) "constant crash in trying to collect info for recoverable error" [Critical,Confirmed] https://launchpad.net/bugs/1394919
#ubuntu-ci-eng 2015-11-16
<Mirv> cihelp: cleaning up Ubuntu's sponsoring queue, can you set the following to Work in Progress or Rejected? https://code.launchpad.net/~om26er/ubuntu-test-cases/fix_minimal_image_size_test/+merge/235298  and  https://code.launchpad.net/~psivaa/ubuntu-test-cases/remove-ceph-lxc-floodlight/+merge/240144  and  https://code.launchpad.net/~psivaa/ubuntu-test-cases/lvm-grub-preseed-fix/+merge/258620 (or otherw
<Mirv> ise handle them)
<blr> t
<blr> err nevermind that, screen misbehaving. :)
<jibel> infinity, could you have a look at bug 1516526 ?
<ubot5`> bug 1516526 in Canonical System Image "devel-proposed images fail to build" [Critical,New] https://launchpad.net/bugs/1516526
<infinity> jibel: That's ogra's mess, generally.
<infinity> (And you also share a timezone :P)
<jibel> infinity, okay :)
<jibel> ogra_, can you look at ^^
 * infinity goes to bed.
<psivaa> Mirv: I'll reject my MP's out of them. If the server team need them, they'll have to do it themselves then. Have notified them a few times
<Mirv> psivaa: thanks!
<psivaa> Mirv: for the other MP, that om26er, you'd need him or QA team
<psivaa> s/that  om26er/that  om26er's MP/
<om26er> Mirv, psivaa deleted.
<Mirv> om26er: thanks for that too!
 * Mirv is patch piloting today
<bzoltan> Mirv: I need help with that silo55
<Mirv> bzoltan: ok
<Mirv> sil2100: ok I now got raof to copy-package last xenial package from stable overlay :) needs to be kept watching still if someone happens to land something there.
<Mirv> bzoltan: you plan to later ship the new source that ships identically named "ubuntu-sdk-qmake-extras" binary package?
<Mirv> I think that was the plan. In that case I don't think we even need to remove the old binary from archives.
<bzoltan> Mirv:  we have this project and can land it anytime to anywhere - https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-sdk-qmake-extras/trunk
<bzoltan> Mirv:  And yes, it should be landed on the archive too
<Mirv> bzoltan: ok. so 055 was published now, feel free to land that next at some point when you have time.
<bzoltan> Mirv:  thanks
<alf_> cihelp: Hi! All mir-mediumtests-vivid-touch jobs are failing due to what seems to be a CI infrastructure issue (perhaps due to the upgrade?), and this is blocking all Mir CI/autolanding jobs. For example, http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-vivid-touch/4821/console . Any idea what's going on?
<psivaa> alf_: looking
<alf_> psivaa: thanks
 * cjwatson truncates the apt-mirror history (used for creating archive snapshots) to 2015-04-01, in an attempt to avoid periodically killing snakefruit
<sil2100> cjwatson: ok!
<psivaa> alf_: jfyi, i've made a change to that job config and testing that atm
<alf_> psivaa: ack, thanks
<greyback_> trainguards: any ideas why qtmir isn't migrating: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtmir ?
<greyback_> "invalidated by dependency"?
<sil2100> greyback_: looks to me it's caused by liburcu
<sil2100> greyback_: I suppose invalidated by dependency means that it's not a valid candidate because one of its dependencies cannot migrate
<sil2100> greyback_: in this case it's mir, which is invalidated by liburcu
<sil2100> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#liburcu
<sil2100> But that's my guess, I didn't really see the 'invalidated by dependency' sign before
<greyback_> sil2100: understood, thanks for looking. I shall be patient so
<cjwatson> sil2100: yes, that's what it means
<cjwatson> greyback_: Ah, so liburcu needs us to upgrade the ppc64el builder guests to wily
<greyback_> aha ,now I follow what "not considered" actually implies
<cjwatson> greyback_: That's in gradual progress, but I didn't realise it was going to be blocking mir
<greyback_> I didn't expect that either tbh
<cjwatson> greyback_: Let me see if I can move that on today
<greyback_> cjwatson: no big hurry, but thanks
<cjwatson> Oh, I know where that ticket stopped, there was a failure to deploy wily guests on arm64 which we needed to look into ... sigh, getting back to downloading a cloud image there
<nerochiaro> cihelp: any idea why the logs on the CI run on this MR are not accessible ? https://code.launchpad.net/~uriboni/messaging-app/stickers/+merge/277446
<josepht> nerochiaro: jenkins.qa.ubuntu.com currently has the CLI disabled due to a zero-day security issue hence our private jenkins aren't able to publish to it.  If you have VPN access you should be able to replace 'jenkins.qa.ubuntu.com' with 's-jenkins.ubuntu-ci:8080' to see the logs
<nerochiaro> josepht: thanks
<josepht> nerochiaro: and http:// rather than https://
<nerochiaro> josepht: An error occurred during a connection to s-jenkins.ubuntu-ci:8080. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long
<nerochiaro> josepht: on firefox
<josepht> nerochiaro: did you use http:// ?
<kgunn> trainguards is something wrong with silo 49 ? "in proposed" would have thot it'd be landed this morning
<rvr> mardy: ping
<nerochiaro> josepht: my mistake. works with hhp
<nerochiaro> http, even
<nerochiaro> thanks
<mardy> rvr: pong
<rvr> mardy: Hey
<rvr> mardy: I just finished testing the pending silo
<rvr> mardy: With silo 1, it doesn't crash with the old and new click, so it's ok
<rvr> mardy: However, it doesn't propmpt to create any Flickr account
<rvr> mardy: Can you confirm that is right?
<mardy> rvr: yes, because of the apparmor denial that you saw
<rvr> mardy: I see ... Error: "An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.230"
<rvr> mardy: Another question. Test ubuntu-system-settings-online-accounts/password-query has been failing for a while. Can you fix it or update the test case?
<mardy> rvr: the apparmor thing is bug 1512667
<ubot5`> bug 1512667 in apparmor-easyprof-ubuntu (Ubuntu) "Enable Online Accounts v2 on vivid overlay PPA" [Undecided,New] https://launchpad.net/bugs/1512667
<psivaa> alf_: so http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-vivid-touch/4823/console now ran the jobs that were required but one of them has failuers
<mardy> rvr: it's actually fixed with silo 58
<mardy> rvr: the test is correct, the current trunk is wrong
<rvr> mardy: Ah, great. Approving this silo :)
<psivaa> alf_: the actual failure is in http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-runner-touch/7404/consoleText
<mardy> rvr: cool, thanks!
<psivaa> alf_: could have caused due to '/bin/bash: line 1: 5897 Segmentation fault (core dumped) mir_demo_server --test-client /usr/bin/mir_demo_client_eglflash' and the likes
<alf_> psivaa: Thanks, that's a known/pre-existing failure. As long as the build runs I am happy. Thanks for fixing this.
<psivaa> alf_: np
<kgunn> trainguards just fyi, silo 49 sticking in proposed causing some issues for high priority item behind it...effecting silo 20
<cjwatson> kgunn: I explained the current blocker for that above, not sure what you expect trainguards to do ...
<kgunn> cjwatson: thanks, sorry for the noise
<mterry> sil2100, how come devel-proposed hasn't had images in a week? (if because of the fail-to-boot bug, that is recently maybe fixed?)
<kgunn> cjwatson: as for expectations, what is the best practice for getting help when things get stuck in proposed (in a generic sense)
<kgunn> ?
<cjwatson> kgunn: well it entirely depends.  greyback_ asked here and that was reasonable enough.  learning more about how to debug it yourselves is good too (e.g. https://wiki.ubuntu.com/ProposedMigration)
<jibel> mterry, it's bug 1516526
<ubot5`> bug 1516526 in livecd-rootfs (Ubuntu) "xenial ubuntu-touch rootfs fail to build" [Critical,In progress] https://launchpad.net/bugs/1516526
<cjwatson> kgunn: but it's a bit like asking what the best practice for getting help with a build failure is, there can be a variety of causes
<cjwatson> kgunn: this one is unusually opaque, I'll admit
<mterry> jibel, ah cool thanks.  Poor devel-proposed can't catch a break
<ogra_> jibel, mterry, i'll merge that in a moment (sorry, was busy weith meetings)
<cjwatson> kgunn: (the question I asked to Odd_Bloke on #ubuntu-devel just now pertains to this, a little indirectly)
<jibel> sil2100, can you rebuild a devel-porposed image once it's fixed, better know sooner than later if there is anything left to have a bootable image
<ogra_> sil2100, jibel, mterry livecd-rootfs fix uploaded
<jibel> bfiller, Kaleo ^
<sil2100> \o/
<sil2100> Should I publish?
<bfiller> sil2100: ppa hasn't published yet
<bfiller> sil2100: actually it has
<bfiller> sil2100: yes please
<sil2100> bfiller: could you upload to the store? Or do you need this to land first?
<sil2100> Publishing in progress
<bfiller> sil2100: I need it to land in trunk then need to build a click from trunk
<bfiller> sil2100: can you force merge please on the camera silo?
<sil2100> bfiller: hm, ok, in this case let's do that
<bfiller> sil2100, jibel : building final click now
<sil2100> \o/
<sil2100> jibel, davmor2, robru, rvr: I suppose all OTA-8 related work is known now, let's skip the meeting and just concentrate on getting an image built and copied to RC
<rvr> sil2100: Ok
<jibel> sil2100, soulds like a plan
<jibel> sounds*
<bfiller> jibel, sil2100: camera-app uploaded to store, needs approval from popey
<popey> on it
<popey> bfiller, approved
<bfiller> popey: ty
<Kaleo> bfiller, jibel: outstanding!
<Kaleo> popey, thank you :)
<oSoMoN> rvr, hey man, how is testing of silo 39 going? need anything from me?
<rvr> oSoMoN: Finished
<rvr> oSoMoN: It's ok
<oSoMoN> excellent, thanks a lot!
<jibel> bfiller, sil2100 for next OTA it is not 2 days earlier wee need for freeze but 2 weeks ;)
<oSoMoN> jibel, whatâs this "Requesting autopkgtests for this silo..." status on silo 39? is this new? should IÂ wait for something to complete before I request publication?
<jibel> oSoMoN, it's a bug in the UI apparently
<jibel> oSoMoN, I tried the new autopkgtest feature robru added to the train, but apparently it is not ready for prime time
<jibel> oSoMoN, you can publish if it's ready
<oSoMoN> ok, thanks!
<oSoMoN> trainguards: who can publish silo 39 for me?
<sil2100> oSoMoN: hmm... I think we need to poke mterry or kenvandine again :)
<sil2100> kenvandine, mterry: ^
<oSoMoN> sil2100, can you confirm that with the configuration of the request, the packages will land in the xenial archive and in the overlay PPA for vivid?
<oSoMoN> (never too sure about it)
<robru> oSoMoN: you ned a core dev, I usually poke kenvandine at this time of day
 * oSoMoN pokes kenvandine
<robru> oSoMoN: yes it's configured correctly. all you need to remember is that the vivid half of a dual always goes to overlay, so the destppa field controls only where xenial goes.
<oSoMoN> robru, thatâs what I thought, thanks for confirming
<robru> oSoMoN: you're welcome
<robru> kgunn: if you are particularly blocked by silo 49 we can force merge the silo but would rather not if we can avoid it
<mterry> sil2100, I can look
<mterry> sil2100, 39?
<robru> mterry: yeah, thanks
<sil2100> bfiller: did the click get approved?
<bfiller> sil2100: yes
<sil2100> Can I kick a new image then?
<sil2100> hmmm
<sil2100> Copying to the stable snapshot now
<sil2100> Will be kicking the image shortly...
<kgunn> robru: we gotta workaroudn
<kgunn> thanks tho
<cjwatson> kgunn: https://portal.admin.canonical.com/85976 if you want to track the work we're doing to fix liburcu
<kgunn> ta
<oSoMoN> mterry, thanks!
<robru> sil2100: slangasek: is there anything for the meeting? I propose we skip
<slangasek> robru: how's silo autopkgtest coming?
<robru> slangasek: you mean britney?
<slangasek> yes
<robru> slangasek: still in the investigation phase. a little behind on the silo status rework I started last week
<slangasek> robru: ok.  I'm ok to cancel for today if sil2100 is, then, but let's sync up later in the week
<robru> slangasek: alright
<dobey> did ota8 get released yet?
<robru> brb
<sil2100> ACK here
<sil2100> I'm anyway busy with preparing the OTA-8 re-spin now ;)
<kenvandine> cihelp: anyone know why the jenkins links to CI jobs are broken?
<fginther> kenvandine, There are some pending updates needed to the public jenkins service that is preventing the internal jenkins from publishing out to the public one. This is all after having to apply a critical update
<kenvandine> that's what i was wondering
<kenvandine> but trying to find the same on the private jenkins looks weird
<kenvandine> fginther, looking at the downstream build view of the latest failed, shows a bunch of NOT_BUILT status
<kenvandine> fginther, http://s-jenkins.ubuntu-ci:8080/job/ubuntu-system-settings-ci/lastFailedBuild/downstreambuildview/
<fginther> kenvandine, oh, there was a secondary problem too
<fginther> kenvandine, I think that's the other problem, but am looking
<kenvandine> ok
<kenvandine> fginther, is there a way to find the failed jobs?
<kenvandine> http://s-jenkins.ubuntu-ci:8080/job/ubuntu-system-settings-ci/2483/
<kenvandine> for example
<fginther> kenvandine, you can just do a string replace from "https://jenkins.qa.ubuntu.com" to "http://s-jenkins.ubuntu-ci:8080/"
<fginther> kenvandine, the other problem I mentioned was that the jobs to execute the autopilot tests on phones was missing from some of the job configurations (and showing up as missing jobs)
<kenvandine> fginther, thx
<kenvandine> fginther, ah... looks like there was a configuration issue for settings
<kenvandine> ERROR: Build aborted. No projects to trigger. Check your configuration!
<kenvandine> fginther, is that being worked on already?
<fginther> kenvandine, that was caused by the second problem, which has been fixed. Retriggering the parent job should work to re-run everything now
<kenvandine> fginther, thx
#ubuntu-ci-eng 2015-11-17
<kgunn> robru: argg...for tomorrow, i think i'm gonna need that qtmir ppa force merged after all
<robru> kgunn: want me to merge it now? or tomorrow?
<jibel> dbarth__, https://requests.ci-train.ubuntu.com/#/ticket/591 is approved, you can publish unless there is something blocking it
<dbarth__> jibel: ack
<mzanetti> cihelp, hey, I'm getting 404 when I click on Jenkins links in MPs since yesterday evening. example: https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-xenial-touch/131/console
<psivaa> mzanetti: due to a jenkins upgrade last week, publishing to jenkins.qa.u.c from s-jenkins,ubuntu-ci:8080 is disabled for the time being until IS does some maintenance activities.
<psivaa> mzanetti: you should be able to access http://s-jenkins.ubuntu-ci:8080/job/generic-deb-autopilot-xenial-touch/131/console if you're in company VPN
<alan_g> cihelp I see an error on https://code.launchpad.net/~alan-griffiths/mir/fix-1463873/+merge/277552/comments/702616 that I get a 404 for: https://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/4834/console. Possibly related: https://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/ stops on the 12th.
<psivaa> alan_g: looking
<alf_> psivaa: alan_g: Note that all our jobs fail to get published to the public servers and there is a related error in s-jenkins, e.g., http://s-jenkins.ubuntu-ci:8080/job/mir-autolanding/2126/
<nerochiaro> cihelp: I am trying to access job/webbrowser-app-vivid-amd64-ci/1173/console via http://s-jenkins.ubuntu-ci:8080/ via the VPN, but i get a page saying the job is not there. am i missing something ?
<psivaa> alan_g: alf_ : sorry for the delay. Yes, jobs are not published to publish jenkins waiting for a fix to land in jenkins.qa.u.c
<psivaa> alan_g: alf_: http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-builder-vivid-armhf/4834/console should have the information that you may be interested
<psivaa> nerochiaro: Build 1173 looks a little too old that it has been pruned.  http://s-jenkins.ubuntu-ci:8080/job/webbrowser-app-vivid-amd64-ci/
<psivaa> the earliest one we have is 1181
<nerochiaro> psivaa: can i request a rebuild of https://code.launchpad.net/~osomon/webbrowser-app/use-qml-SortFilterModel/+merge/273203 ?
<oSoMoN> nerochiaro, IÂ can do that
<nerochiaro> cool
<oSoMoN_> nerochiaro, building: http://s-jenkins.ubuntu-ci:8080/job/webbrowser-app-ci/2473/
<oSoMoN_> ubuntu-qa: whatâs up with the autopkg tests for qtcreator-plugin-ubuntu and unity8 for the proposed migration? they have been marked as "test in progress" for the migration of webbrowser-app for almost a day now (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#webbrowser-app)
<xavigarcia> sil2100: ping
<sil2100> xavigarcia: pong
<xavigarcia> sil2100: Hi! so silo 000 is the one containing the new project I asked you about
<xavigarcia> sil2100: it should be ready to go
<xavigarcia> sil2100: it does no need QA as it's just a library to build integration tests
<sil2100> Let me take a quick look at it in a moment
<sil2100> Yeah, I suppose that should be good
<xavigarcia> sil2100: I guess somebody should review all the packaging stuff
<xavigarcia> sil2100: ok, thanks!
<mardy> trainguards, has silo 1 landed successfully, or how is its state? The changes are not in trunk
<Mirv> mardy: queuebot answered you 2 mins later, still in proposed
<Mirv> mardy: it's always several hours minimum now that we land to real archives so that we don't skip proposed tests
<Mirv> the dual landing to PPA only was an exception that skipped a lot of our test infrastructure
<mardy> Mirv: ok, thanks
<sil2100> xavigarcia: hey, just a quick question about silo 000
<sil2100> xavigarcia: I see that the merge from silo 000 has another branch as a prerequisite, but that branch is not in the silo
<sil2100> xavigarcia: (talking about https://code.launchpad.net/~xavi-garcia-mena/gmenuharness/update-changelog/+merge/277441 )
<sil2100> xavigarcia: shouldn't that merge be also included in the silo?
<seb128> cihelp, what's the deal with https://code.launchpad.net/~seb128/camera-app/red-delete-button/+merge/277668/comments/702629 ?
<seb128> "Problem accessing /job/camera-app-vivid-armhf-ci/149/console. Reason: "
<seb128> "    Not Found"
<psivaa> seb128: please use s-jenkins.ubuntu-ci:8080/job/camera-app-vivid-armhf-ci/149/console until IS sorts out publishing issue
<seb128> psivaa, k, thanks, shouldn't that be announced somewhere?
<seb128> also shouldn't the CI use what is in the vivid-overlay?
<seb128> it doesn't find the 1.3 toolkit there...
<psivaa> seb128: Agree, we should announce. Will do that in a bit
<seb128> thanks
<seb128> psivaa, saw my overlay use question as well?
<psivaa> seb128: yea, looking into it
<seb128> thanks
<psivaa> seb128: https://trello.com/c/x8VCBKzk/865-vanguard-camera-app-not-using-vivid-overlay has been created. One of us will attend as soon as possible
<seb128> psivaa, thanks
<seb128> Kaleo, ^ just fyi, unsure if you still work on camera and if that's something you noticed
<Kaleo> seb128, I still work on the camera
<Kaleo> seb128, thanks
<seb128> Kaleo, yw ;-)
<pete-woods> sil2100: I fixed xavigarcia_lunch's missing MR from the silo
<pete-woods> sil2100: the packaging is very standard apart from one thing
<sil2100> pete-woods: you'll need to rebuild now, right?
<pete-woods> sil2100: I guess that's techinically true
<pete-woods> even if the result will be identical
 * pete-woods hits rebuild
<pete-woods> sil2100: the special part of the packaging, btw, is to handle the ABI changes in xenial without separate branches
<seb128> Kaleo, btw https://code.launchpad.net/camera-app/+activereviews has some things waiting for 1.5 years for review, maybe would be good to clean those out
<pete-woods> we switch based on the distro name, and use a separate symbols file for each
<pete-woods> sil2100: (https://code.launchpad.net/~pete-woods/gmenuharness/distro-specific-symbols-files/+merge/277663)
<pete-woods> :) packages rebuilt ^ sil2100
<pete-woods> http://bazaar.launchpad.net/~pete-woods/gmenuharness/distro-specific-symbols-files/files/head:/debian/ <- debian dir for packaging review
<kgunn> greyback_: is it ok to get robru to force merge that qtmir in silo 49 ?
<greyback_> kgunn: it is if robru says so :)
<kgunn> long story...kdub's gotta fix in mir that richard needs, but in silo it builds against the old
<kgunn> cool
<kgunn> sil2100: you about ?
<sil2100> kgunn: hey, yeah
<kgunn> sil2100: hey, i was pestering rob but he was on late...so any way you could force merge silo 49 for us ?
<kgunn> sutck in proposed
<kgunn> and now hampering another bug fix in a seperate silo
<sil2100> kgunn: yeah, ok, will do that as the migration problem is unrelated to mir
<sil2100> kgunn: done
<jibel> tvoss, mardy silo 57 approved
<kgunn> ta
<seb128> jibel, bzoltan, pmcgowan, what's the status of the fix for https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1512924 ? are we going to get that in ota8 (+ translators doing their job + langpack updates)?
<ubot5> Ubuntu bug 1512924 in ubuntu-ui-toolkit (Ubuntu) "Timestamps not localized in notifications" [High,In progress]
<sil2100> xavigarcia, pete-woods: ok, package looks okayish from my POV, although I always feel a bit meh with all the scripts to support two different distros
<sil2100> xavigarcia, pete-woods: but in this case it seems not so invasive anyway
<sil2100> xavigarcia, pete-woods: that being said... I would like someone from the archive admin team to take a look before I publish, as my button press will result in an instant copy to the overlay
<sil2100> So I want a preNEW review first
<sil2100> seb128: ping :)
<seb128> sil2100, contentless ping warning
<seb128> I was also just talking so you know I'm around ;-)
<seb128> what's the package to review?
<sil2100> seb128: uh oh, apologies! Anyway, we'd need a preNEW review of silo https://requests.ci-train.ubuntu.com/#/ticket/650
<seb128> k
<sil2100> seb128: a new one, libgmenuharness
<seb128> yetanothergmenulib?! ;-)
<sil2100> xavigarcia, pete-woods: one remark I have though... why is the source name different from the LP project name?
<jibel> seb128, status is moved to OTA9
<sil2100> I mean, it's not a blocker, but when a project is hosted on LP it's much easier as both are the same
<seb128> jibel, that's a joke?
<jibel> seb128, why?
<seb128> jibel, how come we can't land a template update in 15 days and then need to rollout an ota with obvious UI part untranslated?
<xavigarcia> sil2100: there is no reason
<seb128> it's like timestamp in the messaging indicators
<seb128> difficult to do more visible
<xavigarcia> sil2100: I just created the project like that and I kept it... I know what you mean... but we thought it was OK
<pmcgowan> seb128, once we have a fix we will consider releasing it early, want to get input from folks
<seb128> pmcgowan, you are speaking about what? the utik translation issue?
<pmcgowan> yes
<pmcgowan> the timestamps thing
<seb128> we have a fix commited since 2015-11-05
<seb128> see https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/kickLocaleTemplate/+merge/276733
<seb128> it seems it just didn't make it an upload since
<pmcgowan> hmm thats bad
<seb128> unsure why, I though jibel was pushing bzoltan to have an hotfix landing for that
<seb128> rather than a full uitk update
<seb128> also it doesn't even need an upload
<seb128> it needs the new template to be commited which can be done manually
<pmcgowan> seb128, actually I just discovered that yesterday and spoke to bz about it
<pmcgowan> seb128, it can be fixed without landing uitk?
<seb128> pmcgowan, well, that's a translation template
<seb128> some project just commit the pot updates directly to trunk
<seb128> to bypass the upload delays
<seb128> but then it needs translator work and a langpack update
<seb128> so unsure it's pratical for ota8 now
<pmcgowan> I see
<seb128> I just don't get why it stalling since 11-05
<seb128> it was even on the ww46-2015 list
<pete-woods> sil2100: it's a good question
<pete-woods> we should probably change it to gmenuharness everwhere
<pete-woods> xavigarcia: it's only the source package name that needs changing
<seb128> pmcgowan, can we at least get somebody from the uitk to commit the template update so translators can do their work and we can see in maybe updating some langpacks if there is a window for that?
<pmcgowan> seb128, sure it needs to go from staging to trunk?
<seb128> pmcgowan, yes
<pete-woods> sil2100: I have added a branch to the MR that fixes the source package name
<pete-woods> but I'm not quite sure how to rebuild it
<sil2100> pete-woods: \o/ if you added a new branch to the silo then just press build on the silo
<sil2100> pete-woods: we'll remove the old binaries
<sil2100> binaries/sources
<pete-woods> sil2100: it won't rebuilt with an empty list of packages
<pete-woods> and building with libgmenuharness didn't seem to do anything
<pete-woods> trying gmenuharness now
<pete-woods> that didn't work either
<pete-woods> sil2100 ^ see build errors
<pete-woods> might be easier to make a new silo?
<pete-woods> and bin this one
<pete-woods> edited a line of the train config
<pete-woods> maybe that was is..
<pete-woods> *it
<sil2100> pete-woods: maybe, did you try force-rebuild?
<pete-woods> no
<pete-woods> it's getting further now
<pete-woods> but it doesn't seem to have built the source package in the build log
<pete-woods> https://ci-train.ubuntu.com/job/ubuntu-landing-000-1-build/556/console
<pete-woods> it's just trying to wait on it
<pete-woods> which is obviously not going to work
<pete-woods> right, nuking the silo
<pete-woods> it's not worth messing around
<pete-woods> sil2100: it's obviously getting upset
<pete-woods> I tried a new silo
<pete-woods> (ended up with 000 again)
<pete-woods> and it is still half looking for libgmenuharness
<pete-woods> I don't know where it's getting this info from, though
<pete-woods> as the source package is definitely just gmenuharness
<rvr> kenvandine: Silo 24 approved
<kenvandine> rvr, thx!
<pete-woods> (see https://ci-train.ubuntu.com/job/ubuntu-landing-000-1-build/557/console)
<pete-woods> robru: I seem to have upset citrain ^ we decided to rename a source package before first release, and citrain seems to have remembered the old value somehow?
<seb128> pete-woods, the descriptions are not very useful is you don't know what "GMenu harness" is (why I don't, still trying to guess what that component does)
<seb128> pete-woods, sil2100, otherwise packaging seems fine to me
<pete-woods> seb128: it's a test harness for things that expose gmenu models
<pete-woods> in particular, indicators
<seb128> you might want to write a few liner description saying that
<pete-woods> I wrote it to finally add tests to indicator-network
<pete-woods> and it's going to be used for indicator-sound
<pete-woods> seb128: thanks for looking over the packaging, by the way :)
<seb128> pete-woods, yw!
<renatu> cihelp, I am getting 'Unsupported device, autodetect fails device' on jenkins build: http://s-jenkins.ubuntu-ci:8080/job/generic-deb-autopilot-runner-vivid-touch/4125/console
<robru> pete-woods: yes the source package name lookup is very slow so there's a disk cache, I'll clear it in a moment
<nerochiaro> cihelp: anyone has any ideas why this fails to build in ci ? https://code.launchpad.net/~uriboni/messaging-app/stickers/+merge/277446 doesn't seem like a problem with the code
<fginther> nerochiaro, indeed that MP was impacted by an issue related to the recent upgrade. I've restarted the job
<nerochiaro> fginther: thanks
<nerochiaro> bfiller: ^
<dobey> trainguards: what does this error mean exactly? https://ci-train.ubuntu.com/job/ubuntu-landing-049-1-build/55/console
<robru> dobey: "native" versioning means that the version number has "-NubuntuN" in it or not, it looks like the "-0" is missing from that version string
<dobey> native means it doesn't have it
<dobey> which is correct
<robru> dobey: the "-gcc" madness it non native due to the dash
<dobey> robru: that's not a dash
<dobey> it's a tilde
<robru> dobey: s/madness/makes/
<robru> dobey: sorry I'm on mobile
<dobey> madness might be correct here :)
<dobey> ok
<dobey> how do i see what version number the tool is generating, in the log?
<robru> dobey: 2015-11-17 21:09:14,343 WARNING Created tag 15.11+16.04.20151117-0ubuntu1.
<dobey> i guess this is a bug in the cupstream2distro script?
<dobey> ah
<dobey> yes that is wrong
<dobey> hrmm
<robru> dobey: the version logic hasn't changed in a long time
<robru> dobey: perhaps you changed something that triggered a different code path
<dobey> i'll try to specify a complete version in changelog and see what happens
<robru> dobey: no
<robru> dobey: hang on let me look
<robru> dobey: weird, there are tests to ensure that if the version doesn't start with -0ubuntu1 that it doesn't add that incorrectly http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/view/head:/tests/unit/test_version.py#L152
<robru> dobey: yeah I guess try the full version, not sure what's going on there
<robru> dobey: oh, just looked at your last commit, yeah
<dobey> yeah, full version seems to work
<dobey> Created tag 15.11+16.04.20151117.1.
<dobey> i guess the gcc5.1 manual upload version exposed a bug
<robru> dobey: no, if you put in a version that doesn't have a +, the train generates "+16.04.YYYYMMDD-0ubuntu1". if you want the native version you have to start with a native version that has a + in it
<dobey> robru: that part is fine. i tried the "15.11" by itself, because i got the error without tweaking the changelog
<robru> ugh
<dobey> robru: anyway, worked around. i'll poke at it more later
<dobey> thanks :)
<robru> dobey: you're welcome
#ubuntu-ci-eng 2015-11-18
<dobey> CommandError: Multiple image matches found for 'ubuntu/ubuntu-vivid-15.04-ppc64el-server-20151117-disk1.img', use an ID to be more specific.
<dobey> trainguards: ^^ this seems to be blocking some autopkgtests on ppc64el
<robru> Wat
<robru> dobey: where are you seeing that?
<dobey> http://autopkgtest.ubuntu.com/running.html
<dobey> scroll to the bottom, and ubuntuone-credentials shows that
<dobey> i saw the "request autopkgtests" button on citrain and thought i'd try it. now my request's status is stuck at "Autopkgtest: in progress." because ppc64el test runner is stuck in an infinite loop trying to spawn an image or something
<robru> dobey: that's nothing to do with the train. I guess you should poke pitti
<robru> dobey: also don't click that it's experimental and not working very well
<dobey> robru: is there any way to unblock the train status? or should i just ignore that and move along with requesting QA?
<robru> dobey: well i could clear it manually. The only way for you is to rebuild the silo. Want me to clear it?
<dobey> robru: yes please. thanks
<robru> dobey: OK. Which silo was that?
<dobey> https://requests.ci-train.ubuntu.com/#/ticket/668
<kgunn> robru: hey, i got a little bit of a strange one...in silo 20, the qtmir for vivid didn't rebuild even tho i chose FORCE_REBUILD
<kgunn> i had swapped out original mp's...and retargeted to dual landing...so maybe it's just a bug
<kgunn> not sure if you wanna debug? or if you would, just delete the qtmir for vivid out of that ppa
<kgunn> and i'll rebuild
<robru> dobey: ok that should clear up in a sec
<robru> kgunn: looking
<kgunn> np
<kgunn> thanks
<dobey> robru: thanks
<robru> dobey: you're welcome
<robru> kgunn: https://ci-train.ubuntu.com/job/ubuntu-landing-020-1-build/284/consoleFull this log looks like it's building qtmir and qtmir-gles. what went wrong?
<robru> kgunn: huh that's weird the log shows "2015-11-17 22:47:22,811 INFO Creating secondary build in /var/lib/jenkins/silos/ubuntu/landing-020/qtmir_+vivid." but I see it is missing from the PPA
<robru> kgunn: http://paste.ubuntu.com/13322918/ that log shows the vivid version being uploaded, since it didn't make it into the PPA we need somebody like cjwatson to dig in and see why lp rejected the upload.
<robru> kgunn: although there sure are a lot of strange errors about missing dependencies in that log, not sure how it got past that to do the package upload...
<kgunn> robru: so am i stuck ?
<kgunn> i kinda need to rebuild that qtmir before euro morning
<robru> kgunn: yeah sorry, I don't have access to the info to figure out what went wrong in order to fix it
<robru> kgunn: if it's urgent you could also try pinging infinity or wgrant, they might be more likely to be around at this time than colin
<kgunn> robru: hmm...could i just create a new silo request as a way to start over
<robru> kgunn: I don't know if that would fix it, it's possible the reason it's being rejected is unrelated to the silo.
<kgunn> kk
<robru> kgunn: I mean you could certainly try that, but I'd try to reach those other people I mentioned first, they'll be able to say definitively why the package didn't make it to the ppa
<robru> kgunn: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-020/+packages?field.name_filter=qtmir&field.status_filter=&field.series_filter=vivid looks like the ppa already has 0.4.7 in it and you're trying to upload 0.4.6.
<robru> which is weird because I thought the train had a check against that...
<robru> kgunn: so you need to either go back to 0.4.7 or get a different silo, yeah
<robru> off to the gym, brb
<robru> (brb in 2 hours)
<FourDollars> Hi, how can I reuqest a landing for https://code.launchpad.net/~fourdollars/unity-settings-daemon/fix-lowest-brightness/+merge/277326 ?
<FourDollars> Where is trainguards?
<robru> FourDollars: Hi
<robru> FourDollars: did you ever use the train before?
<FourDollars> robru: Can you give me the required permissions for operating the CI Train?
<FourDollars> robru: No
<robru> FourDollars: OK, one sec. What's your launchpad name?
<FourDollars> robru: fourdollars
<robru> OK
<FourDollars> robru: Then?
<robru> FourDollars: instructions are here: https://wiki.ubuntu.com/citrain/LandingProcess but may be stale. Feel free to ping trainguards if you need help. I'm EOD but others should be around soon
<FourDollars> robru: Have you given me  the required permissions for operating the CI Train?
<robru> FourDollars: yes
<FourDollars> robru: thx
<robru> FourDollars: if it isn't working, log out and log back in. You're welcome
<Mirv> FourDollars: I'm here
<FourDollars> Mirv: Thx
<FourDollars> Mirv: I have created https://requests.ci-train.ubuntu.com/#/ticket/672. What should I do next?
<FourDollars> Mirv: Never mind. I got it.
<FourDollars> Mirv: Could you help to check https://requests.ci-train.ubuntu.com/#/ticket/672?
<Mirv> FourDollars: checking
<FourDollars> Mirv: thx
<Mirv> FourDollars: looking correct for a xenial landing otherwise, but set the QA setting to "No QA Needed" first. once you've assigned a silo, built and tested it, you can set it to "Publish without QA" so that it'll set to published
<FourDollars> Mirv: OK. Let me try it.
<Mirv> FourDollars: that setting and its options are confusing, we know, there's a bug about it.
<robru> FourDollars: is this change needed for ubuntu touch?
<FourDollars> robru: I don't know.
<Mirv> robru: looks like desktop
<FourDollars> robru: It is for the desktop users.
<Mirv> FourDollars: ok, the next step is to assign the silo. then you can click build and it starts building.
<robru> ok
<FourDollars> Mirv: Still failed. :-(
<FourDollars> Mirv: I saw "2015-11-18 08:22:55,354 ERROR Prepare failed: Low on silos: Ask a trainguard to assign."
<Mirv> FourDollars: oh! sorry about that, let me check if there's anything to free up some silos.
<Mirv> FourDollars: ok you got one?
<FourDollars> Mirv: yes
<Mirv> I freed one silo
<Mirv> FourDollars: great!
<FourDollars> Thx a lot~
<FourDollars> What should I do now?
<Mirv> FourDollars: so now you've a new action "Build" available. that runs a jenkins job which eventually gets the package to the assigned silo (010, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-010/) from where you can test it
<FourDollars> Mirv: OK
<Mirv> FourDollars: so now you received an error regarding the MP that you need to fix
<Mirv> FourDollars: the commit message will be used in the changelog entry
<Mirv> (you've only set the description so far)
<FourDollars> Mirv: I see. Thx.
<Mirv> FourDollars: hey, rather just add the commit message on this page: https://code.launchpad.net/~fourdollars/unity-settings-daemon/fix-lowest-brightness/+merge/277326 than in changelog
<Mirv> FourDollars: in changelog it's ok but actually it's cleaner if you just revert your last commit and use the commit message field in LP, so that the changelog gets generated automatically
<FourDollars> Mirv: OK
<bzoltan> jibel: the UITK with the updated translation files is available in silo5.
<FourDollars> Mirv: What is the next step?
<mardy> Mirv: hi! Is there something I should correct with this? https://requests.ci-train.ubuntu.com/#/ticket/591
<Mirv> FourDollars: it would be ready for testing (it's useful to always test the fresh build once more). but the changelog currently looks funny: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-010/+sourcepub/5707430/+listing-archive-extra - if you want to fix that, set the text you want in the MP's commit message instead and remove the debian/changelog change from the MP, so that the tra
<Mirv> in can generate the changelog by itself.
<FourDollars> Mirv: Haha
<Mirv> FourDollars: anyway, when ready, upgrade to the PPA, and if the testing is fine you can set the status to "Publish without QA". after that is set, you can either try to publish yourself (it will tell you if you can't), or you can get a trainguard to publish it.
<FourDollars> Mirv: OK. Thx.
<FourDollars> Mirv: I saw "2015-11-18 09:32:15,795 ERROR Merging failed: No commit message found. Please specify one either in your merge proposal or in debian/changelog." again.
<FourDollars> Mirv: Could you tell me where is problem I should fix on https://code.launchpad.net/~fourdollars/unity-settings-daemon/fix-lowest-brightness/+merge/277326?
<seb128> FourDollars, do what the error says?
<seb128> FourDollars, you need a commit message on the mp and you don't have one, there is a button to set one
<FourDollars> seb128: I got it. Thx a lot. :D
<seb128> yw
<Mirv> FourDollars: yes, now it looks correct! the next build should be fine in the PPA.
<FourDollars> Mirv: Thx.
<FourDollars> Mirv: I was not aware there is a button to set the commit message on https://code.launchpad.net/~fourdollars/unity-settings-daemon/fix-lowest-brightness/+merge/277326.
<Mirv> mardy: it claims to have a gregression in armhf autopkgtests which is why it hasn't migrated http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#online-accounts-api
<Mirv> FourDollars: right, that bit of LP I've found a bit weird - when you create the MP, you only can fill the "Description" field - only after the MP is created, you can set the commit message which is what is actually used for merges, changelogs etc.
<FourDollars> Mirv: I agree.
<FourDollars> It seems that I don't need to use pbuilder or sbuild to build the package manually. I just need to use the CI train.
<seb128> Mirv, FourDollars, that statement is untrue, there is a small arrow on the mp submition page which gives you details, including a commit message section
<seb128> but yeah, it's not on screen by default
<bzoltan> Mirv: zbenjamin:  I have pushed the qmake-extras to the silo5 ... it is nothing but a version bump
<zbenjamin> bzoltan: ok!
<FourDollars> seb128: It is optional so people always ignore it by default. XD
<seb128> right, that's annoying
<Laney> Not once you get burned by it a few times
<Mirv> seb128: wow, I never noticed that
<Mirv> I've gradually started to use the Extra Options on other pages but not there before this
<Mirv> bzoltan: ok
<FourDollars> 2015-11-18 10:14:12,916 ERROR Needs review: https://code.launchpad.net/~fourdollars/unity-settings-daemon/fix-lowest-brightness/+merge/277326
<FourDollars> 2015-11-18 10:14:12,917 ERROR Publish failed: unity-settings-daemon has merges in bad states
<FourDollars> Mirv: Any idea?
<pete-woods> sil2100: okay, we have a successfully built silo again, and seb128 acked the packaging yesterday
<pete-woods> I obviously can't publish gmenuharness myself, so what's the next stap?
<pete-woods> *step
<Mirv> FourDollars: the MP needs to be top-approved (the Status at the top), you can probably ask pitti to do that
<FourDollars> Mirv: OK.
<xavigarcia> sil2100: Hi there! What would be the statu of silo 000? is it waiting to get reviewed by somebody else?
<sil2100> xavigarcia: hey! Yes, we need an archive admin doing the preNEW review, I poked seb128 yesterday but not sure if he wasn't waiting for the package to get renamed
<sil2100> seb128: did you manage to take a look at the new package in silo 000?
<seb128> xavigarcia, pete-woods, read backlog, that's what pete-woods was talking about
<pete-woods> xavigarcia: FYI I manually merged all the outstanding MRs into the tree for seb128's review
<pete-woods> so he'd get the complete fiew
<pete-woods> view
<pete-woods> and the silo just has an empty MR in it now
<seb128> I had a look yesterday and it was fine to me, just the descriptions could be a bit more descriptive
<pete-woods> yeah, I agree with that
<FourDollars> Mirv: What is the next step for https://requests.ci-train.ubuntu.com/#/ticket/672?
<pete-woods> you could probably generate those descriptions ;)
<sil2100> seb128, pete-woods: remember that you can now always access the merged branch of the train
<sil2100> https://code.launchpad.net/~ci-train-bot/gmenuharness/gmenuharness-ubuntu-xenial-landing-000
<sil2100> (as an example)
<Mirv> FourDollars: it is now published (congrats for your first train publishing!), the next step is simply waiting to see if it migrates from -proposed pocket to -releae pocket, after which the ticket will be marked as Landed. this takes often takes hours at minimum, so there's nothing to do right now. the package is at https://launchpad.net/ubuntu/+source/unity-settings-daemon/15.04.1+16.04.20151118.1-0ubu
<pete-woods> yeah, that's good to know :)
<Mirv> ntu1
<Mirv> FourDollars: https://launchpad.net/ubuntu/+source/unity-settings-daemon/15.04.1+16.04.20151118.1-0ubuntu1 (repaste since IRC cut the line)
<FourDollars> Mirv: Cool. Thx a lot. :)
<Mirv> FourDollars: you're welcome
<rvr> xavigarcia: ping
<xavigarcia> rvr: pong
<rvr> xavigarcia: Hi, yesterday I was testing silo 51
<xavigarcia> rvr: I was now testing what you posted for it
<rvr> xavigarcia: Ah, cool
<xavigarcia> rvr: let me check and will ping you back
<rvr> xavigarcia: Sure
<xavigarcia> rvr: what was the case exactly when you cannot trigger the warning?
<xavigarcia> rvr: after moving volume down or after pressing cancel?
<rvr> xavigarcia: Hmm
<seb128> FourDollars, congrats on the landing, and thanks for handling it ;-)
<rvr> xavigarcia: I pressed "Ok"
<xavigarcia> rvr: ah, in that case you approved the warning... and it does not appear again
<xavigarcia> rvr: maybe the test plan is not clear enough
<rvr> xavigarcia: Yeah, I was confused about what to do with the notification
<rvr> xavigarcia: Is there any way to reset it?
<xavigarcia> rvr: the idea is that when you approve the warning it should not appear again until you unplug and plug the headphones again
<rvr> xavigarcia: Yeah, understood
<xavigarcia> rvr: so... unplug the headphones.... keep playing music, plug the headphones again and the warning should be reseted
<xavigarcia> rvr: If not it would be annoying for the user to be all the time approving the warning once he already did
<rvr> xavigarcia: I thought the notification only appeared once "in a lifetime"
<xavigarcia> rvr: sorry, I had a phone call
<xavigarcia> rvr: yeah, but there was a bug opened asking to reset that then unplugging the headphones
<rvr> xavigarcia: Ack
<pete-woods> seb128: so do we need you to do that prenew thingy then? or is that someone else
<rvr> xavigarcia_lunch: Take a look to the card (when you're back :)
<seb128> pete-woods, I did that yesterday no?
<renatu> Mirv, ping
<Mirv> renatu: pong
<Mirv> renatu: I see your email
<renatu> Mirv, I just sent you a e-mail :D
<renatu> Mirv, nice thanks
<pete-woods> seb128: I have no idea. I don't know how to check what has or hasn't been done on that end. does that mean I just need a properly authorised person to hit "publish" now?
<pete-woods> (https://ci-train.ubuntu.com/job/ubuntu-landing-000-2-publish/build)
<seb128> somebody with upload rights I guess
<pete-woods> seb128: okay, well at least I know you've done the pre-upload now :)
<seb128> right
<pete-woods> just need to badger for the CI train publish
<pete-woods> sil2100: apparently the pre-upload was done by seb already yesterday
<pete-woods> I think we just need to publish now
<rvr> tvoss: Hey. FYI, silo 47's merge proposals need review.
<xavigarcia> rvr: Ok thanks... I'm taking a look
<jibel> tvoss, mardy you can publish silo 57 the status is bileto is wrong
<xavigarcia> rvr: I have one question... what do you mean with "After the volume confirmation dialog has auto-closed"?
<rvr> xavigarcia: The high volume dialog, I wait until it is auto-dismissed
<xavigarcia> rvr: ah, ok... good one.. I've never tried that
<xavigarcia> rvr: In relation with the volume changing while the warning is showing... you can modify the volume, but it will never go beyond the warning level until you press OK
<xavigarcia> rvr: I think that is what we expect
<rvr> xavigarcia: The test case explicitly says that volume shouldn't change while the high volume dialog is displayed
<xavigarcia> rvr: in relation to the label in the volume notification. After discussion with design we decided that it was best to remove it, as it was not specified in the regulations and because we now have the output label
<xavigarcia> rvr: I think I need to update the test plan
<rvr> xavigarcia: Yes, please :)
<xavigarcia> rvr: I will confirm with the spec first, but in relation to the label it was removed intentionally
<mterry> sil2100, robru: I have a silo I want to add a manually uploaded package to.  It's been a little while since I've done this.  I add the package name to the "Source Package Names" field and just upload to the ppa?  for both overlay and xenial?
<xavigarcia> rvr: OK, I will update and will ping you when it's ready
<xavigarcia> rvr: I also need to test the auto-dismissed warning dialog. I don't think that's what we want to happen
<xavigarcia> rvr: Ok, I managed to recreate the issue you mention... looking for a fix. thanks!
<jibel> robru, hey, some silos in bileto have a status 'Requesting autopkgtests for this silo...' can you fix them?
<rvr> xavigarcia: Ack
<tvoss> rvr, I know
<tvoss> rvr, see comment on the silo
<rvr> tvoss: The reason to do QA after reviews is that, even if the developer doesn't expect any change, there could be, and would be wasted time if verification was done or in progress.
<tvoss> rvr,  as you wish, I just set it to qa'able as it works fine
<bzoltan> Mirv: could you help me with the silo number five?
<Mirv> bzoltan: helping
<bzoltan> Mirv:  thank you
<bzoltan> Mirv: ^ WUT?
<bzoltan> Mirv:  queuebot: 3.5.2+16.04.20151118-0ubuntu1
<Mirv> bzoltan: might be because of the binary -> source trick. I'll publish manually.
<bzoltan> Mirv: could be. Thank you
<bfiller> is errors.ubuntu.com working for anyone? I keep getting Aw Snap page in chromium
<jibel> bfiller, works fine here
<sil2100> mterry: hey! Yeah, that's more or less what you should do
<mterry> sil2100, cool
<bfiller> jibel: weird ok
<seb128> pmcgowan, jibel, there was langpack regression in the ota8 candidate pointed this morning on #ubuntu-touch, unsure how much of an issue it is
<seb128> I reported https://bugs.launchpad.net/canonical-devices-system-image/+bug/1517501 about it
<ubot5> Ubuntu bug 1517501 in Canonical System Image "unity8 translations reverted to june version in most recent langpack update" [Undecided,New]
<seb128> basically the unity8 translations got reverted to their june state because somebody changed the domain on launchpad
<pmcgowan> wha??
<sil2100> huh?
<sil2100> I wonder how serious it is
<sil2100> rvr: hey, could you install the recent rc image and check if unity8 translations look okayish?
<seb128> xavigarcia, charles, shrug, seems like the most recent indicator-sound landing regressed notifications under unity7, mouse scrolling over the indicator makes notify-osd grumpy :-/
<seb128> xavigarcia, charles, reported https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/1517502
<ubot5> Ubuntu bug 1517502 in indicator-sound (Ubuntu) "[xenial] invalid notifications under unity7" [High,New]
<rvr> seb128: o_O
<seb128> xavigarcia, charles, that's 2 recent regressions under unity7, you guys need to start testing your changes on desktop as well please
<seb128> rvr, sil2100, pmcgowan, seems we fixed the template at the right time, today langpacks in the overlay fixes the issue
<seb128> the ones that landed an hour ago
<rvr> seb128: Cool
<sil2100> seb128: still, this would mean we'd need to import the new langpacks to OTA-8 and re-spin
<seb128> right
<sil2100> Which is pretty bad
<seb128> well I think that the revert to june is an issue for e.g Chinese
<seb128> they had incomplete translations by then
<seb128> and we lost quite some strings
<rvr> Right
<sil2100> pmcgowan, jibel, rvr: we need to check this, we might need to re-spin or issue an emergency OTA-8+
<seb128> see https://launchpadlibrarian.net/226898897/language-pack-touch-zh-hans_1%3A15.04%2B20151111_1%3A15.04%2B20151118.diff.gz
<seb128> strings like "Device Locked" or "Power"  or "Return to Call" were lost
<seb128> remove/add to favorite, pull to refresh
<seb128> going to be quite a step back on chinese
<xavigarcia> seb128: roger that.... I will take a look
<seb128> xavigarcia, thanks
<xavigarcia> seb128: is this happening in wily?
<seb128> xavigarcia, I guess not, that landing was in xenial only
<seb128> xavigarcia, though I didn't try wily in the overlay ppa if that's what you mean
<xavigarcia> seb128: so to recreate... I should move the mouse over any sound notification?
<seb128> xavigarcia, no, you should mouse scroll over the indicator to change the volume
<seb128> like using a mouse wheel or touchpad edge scrolling/fingers
<xavigarcia> seb128: ah, ok... understood
<pete-woods> seb128: FYI, when I've tried to run changes to packages (e.g. HUD) through the QA process, I was told that QA don't do desktop packages, only phone ones
<seb128> xavigarcia, did you change the format of the notifications?
<pete-woods> so the only testing will be done by the devs themselves
<seb128> pete-woods, right, doesn't mean devs shouldn't test on their unity7 sessions
<xavigarcia> seb128: I've only added a label to show the output
<pete-woods> seb128: sure, just thought that info might be useful
<seb128> pete-woods, it is, thanks
<pete-woods> (like, I think it's probably an issue - that we don't have enough QA resource to do the desktop)
<xavigarcia> seb128: just to double check... you are changing the volume with the mouse wheel?
<seb128> xavigarcia, yes
<xavigarcia> seb128: Ok, I'm never doing that
<seb128> xavigarcia, is there other ways to make indicator-sound send notifications on unity7?
<seb128> middle click for muting seems also to bug
<seb128> though I'm unsure that was sending a notification
<Trevinho> seb128: no, there was no notification on middle-click
<seb128> k, makes sense
<xavigarcia> seb128: the change I've added is just adding a string. That, in fact, I didn't add in first place
<xavigarcia> seb128: that string was added for the warning notification dialog, but now the string is shown all the time
<xavigarcia> seb128: anyway... will keep an eye and will try to get it fixed asap
<Trevinho> thanks
<pmcgowan> seb128, sil2100 yeah I dont know that we can ship that
<seb128> xavigarcia, we are discussing it on #ubuntu-desktop
<pmcgowan> whats it take to fix, one langpack?
<seb128> xavigarcia, <larsu> seb128: got it. It sends a title for the notification now, which throws off notify osd
<seb128> pmcgowan, well, all locales are buggy, but some probably had an ok status in june and it doesn't matter much
<pmcgowan> seb128, how did this happen?
<seb128> pmcgowan, somebody changed the unity8 domain name on launchpad
<seb128> but seems like launchpad has no log of those events
<seb128> so we don't know why/when/why
<seb128> it made the langpack update not have an unity8.po but an unity90something.po
<pmcgowan> seb128, sil2100 I would vote to fix it with a respin
<sil2100> Maybe we could get some logs from LP through the launchpad admins?
<pmcgowan> the teal issue is we didnt detect it
<seb128> I asked on #launchpad earlier but wgrant didn't find any record of a change
<sil2100> Ah, ok, good
<seb128> well "good"
<sil2100> pmcgowan: I'll copy the langpacks over to the snapshot PPA in a moment
<pmcgowan> yep
<sil2100> Well, good that you asked ;)
<seb128> except it happened,  we have no record of it and no way to know it's not going to happena gain
<sil2100> Indeed...
<pmcgowan> seems we could detect that we regressed the packs, are they versioned?
<sil2100> pmcgowan: I wonder if BQ noticed any regressions in the translations
<sil2100> rvr: did you have a chance to check the rc image?
<rvr> sil2100: On it
<sil2100> pmcgowan: they're versioned, yes, but no one checks their contents as it would be crazy, I would suspect us seeing it during testing
<sil2100> Maybe they didn't regress enough to trigger a red flag during QA
<pmcgowan> sil2100, we should have an auto test for it, not quite sure how to define it
<seb128> sil2100, I think main european languages were fine in their june version
<seb128> so likely little different for e.g spanish
<rvr> sil2100: pmcgowan: While testing OTA8, I didn't found any big problem
<xavigarcia> seb128: so, just to be clear... is this something I need to fix or should be fixed in unity7?
<sil2100> We might indeed do a test for this case of a change in the domain name
<rvr> in Spanish
<seb128> xavigarcia, maybe you can join #ubuntu-desktop?
<seb128> xavigarcia, unsure, Lars is looking at the notifications specification
<pmcgowan> sil2100, its very important for chinese to be as well translated as possible
<sil2100> pmcgowan: yeah, indeed, I wonder since I suppose the meizu.zh channel was tested by the China team
<sil2100> jibel: ^
<seb128> sil2100, pmcgowan, looking at the diff things like "Device Locked" or "Power"  or "Return to Call" were lost
<seb128> or "pull to refresh"
<seb128> in the chinese translations
<rvr> I found many untranslated strings for click packages in Chinese
<rvr> But unfortunately I didn't compare with the previous run
<rvr> (from August)
<rvr> For a subset of debian packages, these are the stats:
<rvr> $ wc -l deb*.log
<rvr>    46 deb-es.log
<rvr>    46 deb-fr.log
<rvr>    60 deb-zh_CN.log
<rvr> 60 untranslated strings for Chinese and 46 for Spanish and French
<rvr> For click packages:
<rvr>    20 click-es.log
<rvr>    17 click-fr.log
<rvr>   207 click-zh_CN.log
<sil2100> So, before I copy all langpacks, I would like someone to make triple sure that the current langpacks fit to the contents of OTA-8
<rvr> Which is a similar figure (a bit lower) than in August
<rvr> sil2100: In rc #182, in webbrowser-app.mo I see  PO-Revision-Date: 2015-09-24 06:53+0000
<sil2100> I think the biggest issue is unity8 translations
<sil2100> As that's what regressed
<rvr> 2015-09-24
<rvr> sil2100: Yeah, checking more recent dates in https://translations.launchpad.net/ubuntu-rtm/15.04/+lang/es
<rvr> sil2100: unity8 PO-Revision-Date: 2014-08-26 12:31+0000
<rvr> Bad
<rvr> In launchpad, unity8 was last edited on 2015-11-11
<davmor2> rvr: blame Saviq it won't fix it but you feel so much better ;)
<bzoltan> seb128:  I need a coredev to ack the silo5 ... it is pure string update no code change. Would you please help me?
<seb128> bzoltan, looking
<seb128> bzoltan, ubuntu-sdk-qmake-extras seems to no exist in Ubuntu atm?
<bzoltan> seb128:  it does... it used to come from different source. the qtcreator-plugin-ubuntu used to provide it. No it is a separate project
<seb128> bzoltan, so it's not as trivial as a pure string update
<bzoltan> zbenjamin: or how was it? ^
<bzoltan> seb128: wait a sec... am I an idiot or not?
<zbenjamin> bzoltan: yes we had to split it off the qtcreator-plugin-ubuntu
<bzoltan> seb128: Ohh.. yes, that revision has the shorter control... seb128 is right
<sil2100> rvr: could you upgrade your rc device with the latest overlay-ppa langpack for spanish and check if everything looks okayish? Remember that the rc image has stable-snapshot in the sources.list - you need to change it to the overlay first
<rvr> sil2100: Ok
<sil2100> rvr: thanks :)
<bzoltan> zbenjamin: so we need to land the ubuntu-sdk-qmake-extras to 16.04 asap
<bzoltan> seb128: zbenjamin: hold on.. we do have that package, I have landed it myself - http://packages.ubuntu.com/search?keywords=ubuntu-sdk-qmake-extras
<seb128> bzoltan, https://launchpad.net/ubuntu/+source/ubuntu-sdk-qmake-extras
<bzoltan> seb128:  but too old
<seb128> ah, it's in the NEW queue
<seb128> let me review it
<bzoltan> seb128: Huhh... thanks bigbang we have coredevs who udnerstand these things :D
<rvr> sil2100: seb128: So, at least in Spanish, the language files that are not up-to-date  are dialer-app, indicator-sound, messaging-app, telephony-service, ubuntu-system-settings and unity8
<seb128> bzoltan, that package seems arch neutral, shouldn't be be arch all rather than any?
<sil2100> rvr: with the latest overlay langpacks?
<rvr> sil2100: No, no, with current rc
<sil2100> Ah, ok
<zbenjamin> seb128: it needs to be installed into the qt arch specific directories
<sil2100> Well, the most recent regression that we're about to fix is the unity8 one
<seb128> zbenjamin, ah, ok
<rvr> sil2100: What about the others?
<seb128> zbenjamin, bzoltan, the export DPKG_GENSYMBOLS_CHECK_LEVEL=4 in the rules is not needed but it's not an issue either ... NEW accepting it
<sil2100> rvr: those should be ok, nothing we can do here, the langpacks are auto-generated and we didn't get any news of the domain changing for those
<seb128> bzoltan, I published now as well
<bzoltan> seb128: thanks, i will fix it and land it for the next round
<pete-woods> trainguards: who do I need to bug to click the publish button for the new package (gmenuharness) in silo 000? (seb already pre-new'ed it and acked the packaging)
<sil2100> So if there are regressions there then those are from different reasons, we'll have to investigate separately
<pete-woods> do we need to corner an archive admin or something?
<sil2100> pete-woods: ok, let me press the button then :)
<bzoltan> seb128: ^ wadahell?
<seb128> bzoltan, hum, publish failed because of ^
<sil2100> pete-woods: I can do it as the package is treated by default as an universe package I suppose, it will land in xenial NEW for archive admins and in the overlay
<seb128> bzoltan, looks like pitti already landed it ?! https://launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/1.3.1705+16.04.20151118-0ubuntu1
<bzoltan> seb128:  feels like Mirv has published it manually
<seb128> yeah, unsure what's going on there
<seb128> but it's uploaded
<rvr> sil2100: What do I need to change in sources.list again?
<bzoltan> seb128:  that is the most important! thanks for your help
<seb128> yw
<sil2100> rvr: I think the sources.list has stable-snapshot instead of overlay, right?
<pete-woods> sil2100: awesome, thanks!
<pete-woods> I guess the MIR will happen as a separate task
<rvr> deb http://ppa.launchpad.net/ci-train-ppa-service/stable-phone-overlay/ubuntu
<sil2100> pete-woods: yw!
<sil2100> rvr: hm, ok, could you check if pinning is ok as well?
<rvr> sil2100: Pin: release o=LP-PPA-ci-train-ppa-service-stable-phone-overlay Pin-Priority: 1001
<sil2100> rvr: anyway, strange that the rc images don't have stable-snapshot in it... you sure you using rc, not rc-proposed? And latest?
<rvr> Oh, shit
<rvr> this is rc-proposed
<sil2100> Well, not a big deal, we only had a few landings
<rvr> sil2100: Just re-checked the dates
<sil2100> But still, best to flash rc ;) And there you'd have to change both pin priority and sources.list
<rvr> sil2100: Most are one day off and another is an update for OTA9
<rvr> sil2100: So just unity8 looks fine
<sil2100> \o/
<sil2100> Anyway, I suppose using current langpacks is better than the previous thing...
<sil2100> Copying to snapshot
 * rvr is finally flashing rc 
<rvr> This upgrade takes time
<rvr> sil2100: unity8.mo (es) X-Launchpad-Export-Date: 2015-11-18 10:31+0000
<rvr> sil2100: unity8.mo (zh_CN) PO-Revision-Date: 2015-07-28 03:57+0000 X-Launchpad-Export-Date: 2015-11-18 10:31+0000
<rvr> sil2100: zh_CH revision date matches Launchpad (2015-07-28), so looks good
<pmcgowan> sil2100, rvr  what did we end up changing in the respin then, all the langpacks or just unity8
<sil2100> pmcgowan: all the langpacks, there was nothing landing that could cause a regression in langpacks
<sil2100> pmcgowan: since... generating separate langpacks would be really troublesome
<sil2100> rvr, pmcgowan: am I good to copy the langpacks to the snapshot PPA?
<pmcgowan> sil2100, do we have an image yet?
<pmcgowan> I would copy after verifying the image?
<pmcgowan> or does the image use the snapshot
<sil2100> We can't have an image without copying to the snapshot
<pmcgowan> then yes :)
<sil2100> But rvr checked the langpacks manually on the rc image ;)
<pmcgowan> got it
<sil2100> Ok, copying in progress, once it's done I instantly build an image
<rvr> sil2100: Looks good
<sil2100> rvr, jibel: image building
<sil2100> I jump out now for a walk
<jibel> sil2100, okay, I rechecking the language packs you cpoied to the stable snapshit
<jibel> oops, snapshot*
<jibel> sorry
<kenvandine> jibel, system-settings is held up in proposed because it's waiting for autopkgtests from ubuntu-system-settings-online-accounts, which claims to be "Test in progress" on the excuses page
<kenvandine> jibel, if i click on the Test in progress link, it shows passed tests, not currently running tests
<kenvandine> is the status broken?  or does it only show completed tests?
<jibel> kenvandine, I cannot help, it's entirely pitti's domain now. sorry
<kenvandine> jibel, ah, ok
<kenvandine> i suspect the tests are running but it doesn't show that on the status page, but we'll see :)
<robru> mterry: yep, you're a core dev so you can just dput directly to the silo PPAs. Other people need trainguards/core=devs to do itfor them.
<jibel> rvr, sil2100 here are all the string changes in unity8 between 34 and the image currently building.
<jibel> http://paste.ubuntu.com/13332679/
<cjwatson> the liburcu/ppc64el problems are fixed now, so that should unblock mir/qtmir (modulo whatever library transition problems are involved)
<dobey> kenvandine: are they running on the running page? :)
<dobey> hmm, it's not
<pmcgowan> jibel, did anything change outside of unity8?
<pmcgowan> sil2100, jibel see my email to john mc
<jibel> sil2100, pmcgowan rvr here is the list of strings that were not translated http://paste.ubuntu.com/13332907/ essentially greeter and indicators
<jibel> pmcgowan, no nothing else
<jibel> pmcgowan, chinese, turkish, basque and greek had much more strings missing than other languages.
<pmcgowan> apparently
<pmcgowan> jibel, are you comfortable with a sanity check on the respin and then publish that
<jibel> pmcgowan, let me check what landed in vivid through SRUs
<pmcgowan> jibel, I thought we didnt pick those up now?
<bzoltan> pmcgowan: jibel: the translation stuff of the UITK has landed on the Overlay
<pmcgowan> bzoltan, yep saw that
<pmcgowan> bzoltan, we really just needed it in trunk so translators could do there thing
<jibel> bzoltan, yes, thanks for that
<bzoltan> pmcgowan: small thing, but makes difference.. it was an easy landing
<jibel> sil2100, anything in vivid is not in the snapshot and pulled from the archive directly?
<jibel> pmcgowan, any package not in the ppa is installed from vivid, I don't think sil2100 copies everytghin to the stable-snapshot
<pmcgowan> jibel, he mentioned something yesterday about changing this but I was not clear on it
<pmcgowan> it being controlling what came in from updates
<jibel> pmcgowan, the only risk would have been lxc but the broken version is in proposed so it's fine to sanity check the image the respin and publish
<pmcgowan> this must be the new verbose ci train
<pmcgowan> jibel, great
<jibel> pmcgowan, but I'd need a diff of the manifest to be really sure
<pmcgowan> yep
<jibel> or the delta once it's on system-image
<kenvandine> dobey, where's the running page?
* robru changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? ping cihelp | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: Rolled out major train change, just ironing out some small issues, ping robru if you see anything weird.
<dobey> kenvandine: http://autopkgtest.ubuntu.com/running.html
<kenvandine> dobey, thx
<pmcgowan> jibel, when we build the new image do we still have the option to publish the last one?
<dobey> kenvandine: the "Running" link at the top of the status pages on autopkgtest.u.c :)
<mterry> robru, nice status verbosity changes.  Looks very verbose now, but presumably better to err on that side  :)
<kenvandine> dobey, so clearly something's broken here :/
<dobey> kenvandine: assuming that "in progress" does not also mean "waiting in a queue you can't see"
<mterry> robru, tiny feature request in that regard -- endlines after each status line?
<kenvandine> dobey, perhaps
<sil2100> pmcgowan: yes
<sil2100> pmcgowan: we do
<sil2100> pmcgowan: I'm importing the new image to the rc channel now... but we can publish the previous one no problem
<pmcgowan> ok
<robru> mterry: yeah that's something I need to figure out. I can't put real newlines in the strings because it breaks the IRC ping. but maybe I can s/./.\n/ in the web view or something
<robru> mterry: also I should probably take the arches off 'Successfully built' so that statuses like ^^ are simpler.
<mterry> robru, yeah.  And/or replace "amd64" with "all" or "*" when appropriate; unless you know the packages is arch: all, it makes it seem like it only built for one arch
<robru> mterry: that's a bit harder as the code that reports that doesn't have knowledge of the packaging, only what it sees in the ppa
<mterry> robru, ah fair, then not worth it  :)
<robru> mterry: oh god it takes 18 minutes to set all statuses for all silos.
<robru> I need to parallelize this somehow
<sil2100> pmcgowan: see my OTA-8 proposition I just sent through e-mail
<robru> mterry: how's that: https://requests.ci-train.ubuntu.com/#/ticket/670 ?
<mterry> robru, looks good.  Is it obvious if not all arches are built?  Like one arch has a ftbfs or something?
<robru> mterry: I've just changed it so that if the status is the same on all arches, it hides the arch list, but if the statuses are different on different arches it'll say "Failed to build [i386] Sucessfully built [amd64 etc et]"
<mterry> robru, awesome
<robru> mterry: just like that ^ ;-)
<mterry> :)
<mterry> robru, I'm seeing that error you just emailed about on https://requests.ci-train.ubuntu.com/#/ticket/255
<robru> mterry: looking
<robru> mterry: sigh, there's a lot of silos (sighlos?) affected by this. I'm tempted to just declare bankruptcy on that one check, clear it from all silos...
<robru> mterry: what I really need to do is re-engineer that check so it doesn't cache any data that can get into an inconsistent state.
<mterry> robru, that sounds suspiciously like work
<robru> heh
<robru> mterry: this is just another in a long line of bugs where the train tries to save some state on disk, but then the world changes around it, and the state on disk is inconsistent with the world, and it causes problems.
<robru> mterry: I'm trying really hard to eliminate the concept of "state" that can become "inconsistent". Checking authoritative sources directly, etc
#ubuntu-ci-eng 2015-11-19
<robru> omg I'm so sorry for all the spam today guys I promise this'll settle down son
<robru> soon
<sil2100> jibel, davmor2, rvr: hey! How did the auto-testing of the new rc image go>
<davmor2> sil2100: no idea
<jibel> sil2100, it's okay, I re-ran most of the failures manually and it's good
<sil2100> Ok then, so we're basically good to go
<sil2100> Now the question is, should I publish..?
<robru> sil2100: please publish something, it'll be the first since my rollout this morning, I need to see if it explodes before I can sleep
<sil2100> There's nothing ready for publishing! Sadly
<robru> sil2100: I don't anticipate any problems publishing, the changes to the publish job are minimal. In case of trouble you might need IGNORE_VERSIONDESTINATION, worst case just copy packages manually and the train will still notice & report migration anyway
<robru> Mirv: let me know if the bot pings too much, it may make sense to prevent it pinging if there status contains "currently building" or something
<Mirv> robru: it's ok, I'm doing stuff in the silo so it's just good.
<morphis> Mirv: do you know what is wrong with https://ci-train.ubuntu.com/job/ubuntu-landing-052-1-build/80/console?
<morphis> or sil2100, robru ?
<morphis> its just a rebuild after I've updated the MP and there are no further changes in the :parent branch
<sil2100> robru: the requests page basic filtering (Migrating etc.) doesn't work with the new statuses
<popey> jibel,  New Music app is ready for testing https://requests.ci-train.ubuntu.com/#/ticket/679
<sil2100> morphis: there's a ubuntu-system-settings in the proposed pocket right now that needs to be merged for you to re-build your packages
<robru> sil2100: crap sorry will fix tomorrow, use searches for now
<jibel> popey, okay, must it wait for the new bgplaylist support to land too?
<popey> no
<popey> this doesn't include that
<morphis> sil2100: ah I see
<sil2100> morphis: this error basically says: hey, there's a version of this package in the archive that's missing in trunk
<popey> this is mostly uitk1.3
<morphis> sil2100: when will that happen?
<sil2100> morphis: and it's missing in trunk as the package didn't migrate yet so the changes weren't merged
<robru> morphis: you can use force build to get around this for now but be aware that's just ignoring the issue, will require a rebuild after that other silo mergers
<sil2100> robru: I wouldn't do that now
<sil2100> Since I know that some migrations are blocked right now
<robru> sil2100: right but presumably he wants to test his branch without being blocked by unrelated silos.
<morphis> sil2100, robru: I pushed changes we need to land everything
<sil2100> I see that the autopkgtests are in progress, so it's not blocked by the standard issues
<sil2100> Ok, so maybe you can force-rebuild to get something testable, but you'll need to rebuild once again after this migrates
<sil2100> So as you prefer
<robru> morphis: yeah if you build now and then publish, it will effectively revert the package that's currently in proposed, that's why this check exists, it tries to prevent you from building a weird package. So you can override it if you want to, but just be aware you'll need to rebuild again to incorporate the other changes once the other silo lands. Train will
<robru> notify you when the other one lands and its ready to rebuild
<morphis> robru: thanks, how long will that take?
<robru> morphis: unknown, there's a delay in autopkgtests right now due to some large backlog.
<morphis> hm
<morphis> robru: which would mean we could be blocked for days or hours on landing things?
<robru> morphis: yep. If it's really urgent we can consider a force merge to move things along but that's a desperate measure
<robru> morphis: you can follow along here: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings
<morphis> ah, thanks
<morphis> davmor2: ^^
<davmor2> morphis: wompwompwomp.com
<morphis> :(
<Mirv> robru: let me just say aloud I love the fully automatic status updating
<davmor2> morphis: ^ is that it built
<davmor2> morphis: or is that a problem
<morphis> davmor2: no that one is what is building now and should succeed
<morphis> 1:6.0-0ubuntu9.7 is the version
<pete-woods> ^ needs a packaging ack
<pete-woods> https://ci-train.ubuntu.com/job/ubuntu-landing-022-2-publish/59/artifact/gmenuharness_packaging_changes.diff
<morphis> davmor2: I forced a rebuild of settings-app now too
<morphis> davmor2: so that we have something to test with
<Mirv> pete-woods: could you use export QT_SELECT := qt5 instead of depending on qt5-default?
<Mirv> pete-woods: mostly because Debian does not like the latter and may remove it at some point
<pete-woods> Mirv: sure, do you put that in debian/rules
<pete-woods> ?
<Mirv> pete-woods: example http://anonscm.debian.org/cgit/pkg-kde/qt/qtdeclarative.git/tree/debian/rules?h=ubuntu
<Mirv> pete-woods: yes
<pete-woods> okay, rebuilding
<bzoltan_> Mirv:  I would need a silo to fix this translation issue - https://requests.ci-train.ubuntu.com/#/ticket/680
<Mirv> bzoltan_: oh right we're low on them. ok.
<Mirv> bzoltan_: done
<bzoltan_> Mirv:  thank you
<bzoltan_> Mirv: seb128:Now I hav a problem - https://ci-train.ubuntu.com/job/ubuntu-landing-010-1-build/262/console This landing does not start because the previous is not landed yet...
<robru> Mirv: Haha thanks
<robru> bzoltan_: just force build to get past that
<robru> Oh gad it's 3am. Night
<Mirv> robru: night!
<bzoltan_> robru:  Thanks, and good night
<victorp> sil2100, hi
<victorp> did you get my email?
<jibel> victorp, he's away ATM and should be back after 1300
<jibel> so soon-ish
<victorp> jibel, np - I just saw that you replied. Just wanted to check you had it
<pete-woods> Mirv: hi, I've fixed the qt default thing now ^
<pete-woods> (new diff https://ci-train.ubuntu.com/job/ubuntu-landing-022-2-publish/60/artifact/gmenuharness_packaging_changes.diff)
<sil2100> victorp: Im on lunch now, will check the email once I'm fully back
<sil2100> victorp: do we have a final decision on the release?
<sil2100> Are we good to go?
<Mirv> pete-woods: it claims it unity MP has new commits, and the train is usually right about these things? someone has pushed something since the last build
<Mirv> pete-woods: sorry, wrong silo
<Mirv> pete-woods: just a moment!
<Mirv> pete-woods: publish done, next xenial proposed migration
<pete-woods> Mirv: thanks! you had me worried there for a second
<pete-woods> thought I'd modified unity8 somehow
<Mirv> pete-woods: :)
<victorp> sil2100, check the email ;P
<pmcgowan> sil2100, published?
<mzanetti> cihelp: hey, we're still having issues that we can't access logs from our CI jobs. Can anyone help please?
<mzanetti> for example: https://code.launchpad.net/~mzanetti/unity8/move-screenshots-to-tests/+merge/276798
<mzanetti> https://code.launchpad.net/~mzanetti/unity8/move-screenshots-to-tests/+merge/276798/comments/703590
<mzanetti> only the first 2 links are working, the rest gives a 404
<fginther> mzanetti, hunh, I'm surprised any of them our working.  We've been fighting a problem with build publishing since the upgrade
<mzanetti> fginther, ack, thanks. Just wanted to make sure it's not our instance alone that's broken while you guys think all is fine. If you're working on it, all is fine.
<fginther> mzanetti, in all cases, you should be able to get the results by swapping "https://jenkins.qa.ubuntu.com" to "http://s-jenkins.ubuntu-ci:8080/" until the problem is fixed
<mzanetti> tsdgeos, ^
<tsdgeos> k
<mardy> Mirv: hi! Is there something you can do to unfreeze https://requests.ci-train.ubuntu.com/#/ticket/591 ? I see that there's an autopcktest failure, but that's some dependency error out of my control
<renatu> cihelp, could you create this silo? https://requests.ci-train.ubuntu.com/#/ticket/682, I am getting this message: ''ERROR Assignment failed: Low on silos: Ask a trainguard to assign.''
<josepht> renatu: that's a request for trainguards
<sil2100> renatu: yep, poke trainguards for this kind of thing - on it now
<renatu> josepht, sil2100 , ok thanks
<sil2100> renatu: done
<rvr> mzanetti: Silo 60 approved
<mzanetti> rvr, woot! thanks!
<robru> alex-abreu: digging into this exception, gimme a minue
<alex-abreu> robru, thx
<oSoMoN> trainguards: can we get a silo for https://requests.ci-train.ubuntu.com/#/ticket/683 ?
<robru> oSoMoN: 22:
<robru> oSoMoN: https://ci-train.ubuntu.com/job/prepare-silo/6531/console
<oSoMoN> robru, thanks
<robru> oSoMoN: you're welcome
<robru> alex-abreu: ok I have a fix in trunk, will hit production in ~30 min, try again then.
<alex-abreu> robru, ok thx
<bfiller> sil2100, robru: can you please add nerochiaro (lp name uriboni) to have access to citrain to create silos, etc?
<robru> bfiller: on it
<bfiller> robru: thanks
<robru> bfiller: done. You're welcome
<bfiller> nerochiaro: try logging out and back in, should be all set
<nerochiaro> bfiller: looks like it's working. thanks. any document i should read to understand the process ? i don't want to annoy people with questions
<bfiller> nerochiaro: not sure about that, but I can give you some quick tips. probably best when you want to create a new silo and can walk you through it
<nerochiaro> bfiller: ok, let's do it that way
<bfiller> nerochiaro: it's for the most part self-explanatory, but couple of things you should be aware of
<robru> nerochiaro: https://wiki.ubuntu.com/citrain/LandingProcess don't hesitate to ask questions, I'd rather answer questions than fix mistakes
<robru> nerochiaro: but there are very few mistakes that can't be fixed by a rebuild so don't be afraid to experiment
<nerochiaro> robru: excellent, thanks
<robru> nerochiaro: you're welcome!
<pmcgowan> robru, why don't I see silo-009 on the citrain requests page
<robru> pmcgowan: looks fine to me? https://requests.ci-train.ubuntu.com/#/silo/009 where are you looking?
<pmcgowan> robru, https://requests.ci-train.ubuntu.com/#
<robru> pmcgowan: second page
<robru> pmcgowan: https://requests.ci-train.ubuntu.com/#?limit=50&page=2
<sil2100> pmcgowan: the requests page is paged, you need to click the "... older ..." button at the bottom
<sil2100> Or simply search by silo
<pmcgowan> robru, oh, stupid me
<pmcgowan> had no idea
<robru> Looks like i need to do something about these device tarball requests, they don't go through Jenkins so they don't get marked as landed and cleared from the list
<robru> pmcgowan: it's sorted by request number so if you're looking for a silo number it's easier to search than to browse the list
<pmcgowan> robru, yeah I got used to just using search in page in the browser
<robru> pmcgowan: yeah unfortunately the performance of the page suffers if more than 50 requests are shown so i had to paginate it
<pmcgowan> robru, so how would I search for media-hub requests
<pmcgowan> if i click the search options nothing happens
<robru> pmcgowan: there's a search field in the right hand bar. Type media-hub and "search active silos" you can even bookmark your searches
<robru> Search options?
<pmcgowan> oh I see
<pmcgowan> robru, thanks
<robru> pmcgowan: you're welcome! Also "show silo #" is for directly jumping to a specific silo number if you know the number you want to see
<rvr> mzanetti: ping
<robru> alex-abreu: oh god it's still broken sorry
<mterry> robru, love the status changes (new line and clearer text).  One thing I just noted.  I updated a unity8 branch but haven't built yet, and the status says it is dirty for xenial only but is fine for vivid
<robru> mterry: yeah, that's expected, because the vivid package isn't built from MPs, it's built by copying the MP dir. so the vivid package has no way to know there's new commits because it is handled by a separate class that has no knowledge of commits. rest assured though it's not possible to build just the xenial bit, when you rebuild one you rebuild both.
 * robru is thinking that I should probably hide the package list when all packages have the same status just like I did with the arch list.
<boiko> robru: would you mind triggering a rebuild of dialer-app for ppc64el xenial in silo 25?
<robru> boiko: done
<boiko> robru: thanks!
<robru> boiko: you're welcome!
<robru> alex-abreu: ok I have another fix, more confidence in this one, just waiting for webops to get back from lunch to get it into production
<alex-abreu> robru, ok :) ... same timeline ?
<alex-abreu> robru, what causes the issue ? is it specific to this silo ?
<robru> alex-abreu: this issue would be effecting anybody trying to build a package that doesn't exist in ubuntu archive. I made some changes recently and this regressed. last fix was a gamble, this fix is similar to reverting the change that caused the issue so it should be good.
<alex-abreu> thx
<robru> alex-abreu: cron will always roll out the fix at 17 minutes past the hour, but I need webops anyway for other stuff I'm doing so I'm trying to get them to roll everything out sooner, but the guy's on lunch
<robru> alex-abreu: you're welcome. sorry for the hassle!
<alex-abreu> np
<mzanetti> rvr, pong
<boiko> robru: is there still a "watch-only" build job or will silo 25 pick the new status (packages built) automatically at some point?
<robru> alex-abreu: ok, got it. trying again: https://ci-train.ubuntu.com/job/ubuntu-landing-045-1-build/104/console
<robru> boiko: I just eliminated watch-only because the train is now ALWAYS watching ;-)
<alex-abreu> robru, thx
<robru> alex-abreu: you're welcome
<boiko> robru: ok, does it poll from time to time or the failed to build status there is a bug?
<robru> boiko: it polls every 30 minutes.
<boiko> robru: ok, thanks
<robru> boiko: you're welcome. in fact it's starting a poll now: https://ci-train.ubuntu.com/job/check-publication-migration/27097/console should get to your silo in a few minutes
<robru> it's on my TODO list to speed this up
<robru> yay
<robru> alex-abreu: oops, don't let that status fool you, packages are in PPA and building.
<alex-abreu> robru,  :)
<greyback_> trainguards: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#liburcu <- the amd64 test has been stuck a long time now, can it be kicked?
<robru> greyback_: what's "a long time"? Last i heard there was a big backlog and you just have to wait. I don't have any power over autopkgtests
<greyback_> robru: at least 3 hours since i last looked. Other tests appear to only take 5 mins, hence was curious
<robru> greyback_: i got a mail from pitti yesterday saying there's a big backlog on amd64 due to a big KDE landing. Not sure if that's cleared up yet or not
<greyback_> robru: perhaps that's it then. Sorry for the noise
<robru> greyback_: no worries, from what i understand the infra is pretty strained. I don't think 3 hours is crazy long. I'd start being worried around 12 hours or something.
<greyback_> robru: ok. See you in 9 hours ;)
<robru> Heh
<kenvandine> robru, check this out
<kenvandine> 2015-11-19 21:15:35,091 ERROR Bileto says: 500 INTERNAL SERVER ERROR
<robru> Ugh
<kenvandine> https://requests.ci-train.ubuntu.com/#/ticket/443
<kenvandine> it still says Beginning publication
<kenvandine> but i'm pretty sure it's done publishing
<kenvandine> robru, i was stress testing bileto... 33 packages :)
<kenvandine> robru, gotta love webapps!
<robru> kenvandine: huh, the audit log says release pocket, that implies it migrated, not sure why it would be updating the audit log but falling to set the status
<kenvandine> robru, yeah... can i merge it?
<kenvandine> or do you want to debug?
<robru> kenvandine: you can merge it if you're blocked, looks like a db field length issue indeed, i thought i took all the length limits off already though...
<kenvandine> robru, not blocked... just want it off my plate
<kenvandine> but i don't mind leaving it for you to debug
<kenvandine> just click merge when you're done :)
<robru> kenvandine: k, leave it with me.
<kenvandine> robru, i need to take off for the evening, thanks!
<robru> kenvandine: you're welcome
#ubuntu-ci-eng 2015-11-20
<robru> blam
<popey> robru, whoever runs that bot might want to remove the colon after the url, some irc clients treat it as part of the url, so when you click it, it 404s
<robru> popey: buggy irc client!
<robru> popey: ^^ ARE YOU HAPPY NOW?!?! :-P
<robru> Incredible, translation updates push to trunk, invalidates all the silos. It's beautiful <3
<mardy> trainguards, can we just force https://requests.ci-train.ubuntu.com/#/ticket/591 to land somehow? The failures are intermittent, and apparently related to CI infra
<robru> mardy: that's actually landed and would merge right now but there seems to be a train problem, I'm looking into it
<mardy> robru: cool, thanks! :-)
<Mirv> mardy: yes, it's now really landed.
<Mirv> robru: not really a problem maybe, migrated 36 minutes ago, maybe just not updated yet?
<Mirv> mardy: you can see it's now in release pocket https://launchpad.net/ubuntu/+source/online-accounts-api
<robru> Mirv: no there's a crazy traceback in the migration script: https://ci-train.ubuntu.com/job/check-publication-migration/27122/console
<mardy> Mirv, robru: but trunk is not updated, is it?
<mardy> (the MP doesn't appear to be merged)
<robru> mardy: no the train is broken, I'm working on it.
<mardy> robru: good luck :-)
<Mirv> mardy: yes, it'd be normally right after it migrates, and the ticket would show "Landed"
<Mirv> mardy: we could force it now that there are no proposed migration problems, but I assume robru is wanting to fix it for real so let's wait a bit
<robru> mardy: thanks, this one is weird.
<robru> mardy: yeah are you blocked on this? we can force merge if you're in a hurry but I'd like to fix it proper and see it be fixed before I go to bed
<mardy> robru, Mirv: no hurry, better fix it once and for all, if possible :-)
<jibel> robru, can you remove the 'request autopkgtest' button from bileto until it is functional?
<jibel> it is just confusing and link to the build artifacts are lost
<robru> jibel: can people not be trusted not to click it? :-/
<jibel> robru, no they don't
<jibel> sil2100, is the changes bot running?
<sil2100> Not if the instance went down again... let me check
<sil2100> eh, can't log in as chinstrap is still down, need VPN, one moment
<robru> mardy: Mirv: ok fix in trunk, will hit production in ~20 and then we can try this again
<robru> jibel: seems nobody clicked it since the last time I cleared it out...
<robru> sil2100: Mirv: btw if somebody clicks that 'request autopkgtest' button and then they want to give up on it (stop watching for results) you can do that by: rm -vrf ~/silos/*/*/*_autopkgtest
<sil2100> robru: ACK
<sil2100> jibel: ok, looks like it works
<sil2100> jibel: the job runs every 30 minutes so maybe it had a delay or something
<Mirv> robru: thanks!
<robru> well technically what I said would clear it for *all* silos but there aren't any silos that are using this currently so it's a minor difference.
<Mirv> robru: wasn't the force merge supposed to still be there for trainguards? https://ci-train.ubuntu.com/job/ubuntu-landing-042-3-merge-clean/build?delay=0sec
<robru> Mirv: it's always forced now, because only trainguards can run it, and the non-force was completely redundant
<Mirv> robru: makes sense, then there's another problem with that since it failed, maybe because I just removed one MP from there
<robru> Mirv: (the failure you got is the same one that bit mardy, fix will hit production in 2 minutes)
<Mirv> robru: ah... great
<robru> Mirv: why are you merging 42? one of the packages isn't at dest...
<robru> mardy: https://code.launchpad.net/~online-accounts/online-accounts-api/trunk done
<robru> sorry for the hassle
<robru> Mirv: it'll work now anyway, confirmed ^^
<mardy> robru: my hero! Thanks!! :-)
<Mirv> robru: because unity-lens-music will go to another landing
<Mirv> robru: it was added after it was published
<robru> mardy: you're welcome
<robru> Mirv: weird, ok
<Mirv> robru: mzanetti and me can't find anything that has new commits in https://requests.ci-train.ubuntu.com/#/ticket/621
<Mirv> https://code.launchpad.net/~mzanetti/unity8/ubuntuanimations/+merge/276511 has one commit on the day of the build, but that's also in the sources
<Mirv> mzanetti: maybe someone uncommitted again something and push --overwrite:d?
<robru> Mirv: mzanetti: the new commit is on trunk. you can discover this by clicking 'status' and scrolling down to the part where it checks your silo, it will list the URL that has new commits.
<mzanetti> on trunk... dafuq...
 * mzanetti looks
<Mirv> robru: Status is a link!!! :D sorry...
<robru> Mirv: everything orange is clickable.
<Mirv> yeah, I know, I just had skipped that somehow
<Mirv> robru: ah, many trunks get translation updates all the time
<robru> Mirv: it's a bit  unfortunate in this case as the migration script has one log for all silos, so you have to scroll literally to the bottom to find silo 60
<Mirv> robru: that's alright
<robru> Mirv: yeah this is a bit iffy. I added this check for the case when a conflicting silo finally merges, so you know to rebuild to incorporate the conflict. translations throws a wrench in that though
<robru> Mirv: I suppose I'll have to work out a way so that it only sets the status if the new commits are not translation commits, but that seems a bit hard & slow (so in addition to iterating over every MP in every silo I'd also have to iterate on every commit in every branch in every silo to make sure the new ones are only translations).
<Mirv> that's slow yes
<robru> sigh, I need to file some bugs
<mzanetti> robru, can it be that it complains about the launchpad translation commits?
<robru> mzanetti: yes
<Mirv> mzanetti: that's what we just discussed
<Mirv> mzanetti: I'll publish the silo manually copying, since they're all universe packages
<mzanetti> oh, sorry
<mzanetti> Mirv, I guess we can revert the translation commit, lp should redo it tonight then...
<robru> Mirv: try publish job? I think it should work
<mzanetti> Mirv, whatever you think it's easier
<Mirv> robru: bad state https://ci-train.ubuntu.com/job/ubuntu-landing-060-2-publish/8/console
<robru> ah
<Mirv> mzanetti: ah damn, unity-api is actually in main :(
<Mirv> mzanetti: just means I need that one copied by someone else
<mzanetti> please stop scaring the sh*t out of me :D
<sil2100> Mirv: sorry! I MIRed it recently ;p
<Mirv> sil2100: damn you! :)
<Mirv> mzanetti: 060 is already published to vivid overlay now :) just waiting for a core-dev to copy unity-api to xenial, I copied the other two
<mzanetti> thanks a bunch Mirv
<Mirv> mzanetti: ok seb128 helped us, let's keep the silo until we see that proposed migration happens in xenial. but it's now there too.
<mzanetti> Mirv, and again, tanks a lot :)
<robru> Mirv: migration script starts in a minute, will take 20 minutes to update the status for silo 60 tho
<seb128> jibel, I think that comment saying that indicator-datetime is not translated is probably the uitk template/timestamps strings not being translated
<Trevinho> Mirv: added new silo, but generated changelog is so wrong.... https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-042/+packages :-(
<robru> Trevinho: what's wrong with it? looks actually reasonable to me
<Trevinho> robru: oh, i maybe see the reason... It uses https://code.launchpad.net/~unity-team/unity-lens-music/saucy as base
<Trevinho> robru: it's wrong since he only change should be the icon change
<Trevinho> this is suspicious -Vcs-Bzr: https://code.launchpad.net/~unity-team/unity-lens-music/trunk
<Trevinho> +Vcs-Bzr: https://code.launchpad.net/~unity-team/unity-lens-music/saucy
<robru> Trevinho: yup, pointing your MP at saucy would cause a goofy changelog
<Trevinho> yeah.... it was proposed to the wrong branch ./
<robru> Trevinho: no big deal then, repropose and rebuild
<mzanetti> Mirv, should it have merged the code by now?
<robru> mzanetti: no, it *just* published. it's so new the train hasn't even noticed it's published yet
<mzanetti> heh, ok
<robru> mzanetti: it'll sit in proposed for a bit, the ticket status will show 'Proposed pocket' for a while, then it'll merge some hours later
<mzanetti> right
<xavigarcia> rvr: Hi there
<xavigarcia> rvr: silo 51 is again ready to QA... I've fixed the issues you found on the warning dialog and I've also updated the test plan
<rvr> xavigarcia: Yeah, I saw it, thanks
<xavigarcia> rvr: np
<Mirv> mzanetti: proposed migration
<Mirv> mzanetti: hours at minimum, then check http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8 if it's stuck for real
<Mirv> mzanetti: it's not wanted that stuff gets thrown to xenial and forgotten, therefore we wait for the migration tests
<Trevinho> robru: it's still wrong... :(
<robru> Trevinho: look at thebranches, they're different.
<Trevinho> mh
 * Trevinho should rebase...
<robru> Trevinho: I duno what branch you started with but it doesn't look like the trusty branch
<Trevinho> yeah, it wasn't a my branch... So you're right
<robru> Trevinho: hm they match at commit 148, so 149 is this anomalous commit, not sure where that came from 2 years ago
<robru> Trevinho: also double-check the bzr tags. that's how the train generates the changelog. it looks for the most recent bzr tag on the branch and includes everything after that in the changelog, so find the most recent release commit and tag it with the version number of that release, should stop the train from including anything older than that in the log
<Trevinho> ok
<robru> Mirv: https://requests.ci-train.ubuntu.com/#/silo/060 crap, it won't auto-merge as long as that 'needs rebuild' is in there.
<robru> Mirv: might have to merge it manually... or delete the translation commit ;-)
<Mirv> robru: ah right. well I'll merge it manually once migration is done
<robru> Mirv: sorry about that, as usual corner cases ruin a brilliant plan
<Mirv> robru: :) heh, but eventually that brilliant plan works! like these auto-updating statuses and everything that is now there.
<robru> Mirv: yeah that's slick. it's about to get slicker, too. I'm parallelizing it so a) it's way faster and b) when you click Status you only see the log for the request you clicked on, don't have to search through all silo.
<rvr> pstolowski: ping
<pstolowski> rvr, pong
<rvr> pstolowski: I think silo 60 already landed
<pstolowski> rvr, great, that means i can rebuild the other one
<pstolowski> rvr, nope, not merged yet
<rvr> Oh
<jibel> xavigarcia, about silo 51 when the phone rings it's a bit weird to see the volume notification with label 'headphone' then the notification again with the label 'speaker' when the call ends. Is it really the expected behaviour?
<jibel> rvr, ^ did you see that too last time you tested this silo?
<xavigarcia> jibel: not sure about that... I should ask design.. But it looks a bit weird... yeah
<Mirv> pstolowski: rvr: unity8 is still in xenial-proposed, so no merging
<rvr> jibel: Nope, I do not remember that problem
<jibel> rvr, xavigarcia ok, silo blocked until you have a confirmation
<xavigarcia> jibel: ack
<popey> The twitter scope, is it in the store or only on the image?
<popey> asking for a friend :)
<jibel> xavigarcia, about silo 6 indicator-location when is the indicator supposed to be removed from the panel? currently it is removed when the user turns GPS off, it should be when location is switched off, or like the spec says after 5 min without an access to the location service.
<jibel> ?
<xavigarcia> jibel: Following the specs stated in the bug it should not appear
<xavigarcia> jibel: And GPS is controlled from the settings
<xavigarcia> jibel: that's what I understood
<jibel> xavigarcia, okay, I double check and confirm in a minute
<xavigarcia> jibel: https://docs.google.com/document/edit?hgd=1&id=1810KDpFl2Mxsn1z3wehPU9pkbS6R6o-j1-pmYpkYb7A#
<bzoltan_> jibel: Mirv: the silo10 has the corrected UITK translation  files. No code changes
<Mirv> bzoltan_: looks correct
<Mirv> both .pot + .po:s
<jibel> xavigarcia_lunch, actually both location detection and gps must be switched off to remove the icon from the panel. Given that there is only one switch left in the indicator, switching it off should be enough to remove the icon, isn't it?
<jibel> bzoltan_, thanks, I trust you checked every single string for invalid characters? :)
<xavigarcia_lunch> jibel: mmm, I guess so... and it's not doing it, right?
<jibel> xavigarcia_lunch, nope
<jibel> xavigarcia_lunch, you must disable location detection and gps from system settings
<xavigarcia_lunch> jibel: ok.... will fix it then. Thanks for finding out
<pete-woods> trainguards: hi guys. got a silo for indicator-network that switches out our vendored menu harness for the newly packaged gmenuharness
<pete-woods> needs a packaging ack: https://ci-train.ubuntu.com/job/ubuntu-landing-038-2-publish/18/artifact/indicator-network_content.diff
<pete-woods> thanks to anyone with spare cycles to have a look
<jibel> xavigarcia_lunch, yw, design should also clarified the spec on this specific point.
<xavigarcia_lunch> jibel: yeah
<pete-woods> whoops, better diff (https://ci-train.ubuntu.com/job/ubuntu-landing-038-2-publish/18/artifact/indicator-network_packaging_changes.diff)
<xavigarcia_lunch> jibel: I wil ping them before pushing anything, to confirn
<jibel> xavigarcia_lunch, thanks
<xavigarcia_lunch> jibel: np
<bzoltan_> jibel:  No I did not. I would lie if I would say that I have checked 5594 strings. but I have checked those what were messed up yesterday
<Mirv> pete-woods: how switching libraries would not require QA, or is that the same identical code now separated to own package?
<jibel> bzoltan_, np :) approved
<bzoltan_> jibel:  thanks.. it was a lame bug. I will never trust chromium browser again... vi rules
<jibel> bzoltan_, heh, sorry we missed it too
<jibel> or found too late
<abeato> Mirv, I need to upload http://people.canonical.com/~abeato/qtmultimedia-opensource-src/ to silo 9 :)
<pete-woods> Mirv: the lib is only used in the test suite, the indicator doesn't get affected at all
<pete-woods> it's a library a bit like autopilot
<pete-woods> but for gmenus
<pete-woods> we just want to use the same lib across all the indicators, rather than copying
<Mirv> abeato: ok
<Mirv> pete-woods: ok
<Mirv> ok ok
<abeato> Mirv, ok thanks
<Mirv> abeato: how's the upstreaming faring with Jim + Yoann? you should probably divide the upstreaming work between you two and offload as much as possible to Yoann
<abeato> Mirv, I think Jim already synced with upstream, this upload is for something wrong we noticed, I'll sync back with jhodapp once he is around
<Mirv> abeato: no, there is zero upstreaming work done: https://codereview.qt-project.org/#/q/project:qt/qtmultimedia,n,z so far
<Mirv> abeato: the current qtmultimedia that is shipping in our overlay is diverged from the July upstream commit and has new features that are not in upstream, so the plan is 1. you get it working, 2. you upstream all new features, 3. you drop the current qtmultimedia API you have and replace with what is in upstream.
<abeato> Mirv, ok, didn't really know the status, as is Jim the one handling this
<Mirv> abeato: bug #1514344 is to follow it. ok. I just occasionally ask since we're basically walking on a thin line by shipping something that is actually rejected by upstream, and just hoping no-one starts to use the API in our stable release since it will be dropped.
<ubot5> bug 1514344 in qtmultimedia-opensource-src (Ubuntu RTM) "Upstream remaining bits and port to upstream QDeclarativePlaylist version" [High,In progress] https://launchpad.net/bugs/1514344
<Mirv> abeato: anyway, uploaded to the PPA since we've agreed this is the situation currently
<abeato> Mirv, understood, I agree with the plan too
<anpok_> cihelp: there seems to be a problem with unity-system-compositor-cir -> unity-system-compositor-xenial-amd-ci has problems with pbuilder
<anpok_> http://jenkins.qa.ubuntu.com/job/unity-system-compositor-xenial-amd64-ci/5/console
<pete-woods> Mirv: thanks! :)
<Mirv> pete-woods: yw!
<bzoltan_> jibel: it would be fun to make a simple script to test if the strings are sensible.
<jibel> bzoltan_, sure, if you find a definition of 'sensible string'
<jibel> it can be anything
<bzoltan_> jibel: I will think about it.. I have an idea
<jibel> kenvandine, there are at least 2 problems with the custom ringtones silos: 1. custom sound is removed from the list when user selects another sound, 2. The custom sound is also available in message notifications
<jibel> kenvandine, also I noticed that 'Alarm Clock' is the first ringtone, is it expected?
<jibel> note that this last point has nothing to do with the silo
<kenvandine> it's alphabetical
<jibel> kenvandine, yeah, but is it expect to have alarm clock as a ringtone ?
<kenvandine> also, the design calls for the custom ringtone to be removed
<kenvandine> jibel: i don't know if anyone thought about that, but it's in the directory with all the ringtones
<kenvandine> jibel: good point on the ringtone showing up under messages
<kenvandine> i'll fix that
<jibel> kenvandine, it's a really annoying to remove it. custom background are not removed when the user picks another one
<kenvandine> yeah, we don't have a design for managing them
<kenvandine> the design is quite simplistic
<kenvandine> it'll evolve though
<kenvandine> we'll eventually add a loop selector, so you can select a clip from a song to repeat
<jibel> kenvandine, we could keep one at least and replace it when the user selects a different custom sound
<kenvandine> when we work on that i'll push design to do something about managing custom ringtones
<kenvandine> jibel: we could, but that would require a lot of refactoring of the panel
<kenvandine> not UI
<kenvandine> just implementation
<kenvandine> and the way we maintain the list
<kenvandine> jibel: which we'll need to do when we add the loop stuff
<kenvandine> jibel: i just pushed a fix for the ringtone showing up in the messages lists, rebuilding silo now
<seb128> jibel, kenvandine, I think the alarm clock one is there because we don't have a directory specific for the clock/reminder
<seb128> we only have ringtones and messages
<rvr> Mirv: ping
<jibel> seb128, okay, it's just a bit odd.
<seb128> jibel, agree, we would need to a separate set of sounds for alarm&reminders
<seb128> seems like a valid request for design
<jibel> seb128, I'll file a bug
<seb128> thanks
<pstolowski> rvr, silo 14 rebuilt and looks good, ready for qa
<jibel> pstolowski, thanks, unblocked
<jhodapp> Mirv, zero is definitely not true, most of it is upstreamed
<jhodapp> Mirv, we've backported our qdeclarativeplaylist API to the 5.7 dev API upstream...so now there's just a tiny bit that needs upstreaming that's not part of an API
<tvoss> sil2100, around?
<davmor2> sil2100, jibel, morphis: Finally the bluez5 silos are ready to land sil2100 can you spin up an image once they do please
<abeato> davmor2, morphis \o/
<abeato> morphis, well done :)
<davmor2> sil2100: can you give me a ping once the image builds then please then I need to test across all four devices
<morphis> YEAH!!!!
<jibel> davmor2, great, lets celebrate \o/
<pmcgowan> oh my
<davmor2> pmcgowan: it's only taken a week of debugging and morphis patiently fixing to get it landed \o/
<pmcgowan> well done morphis and davmor2
<morphis> pmcgowan: thanks
<morphis> pmcgowan: but be prepared... the suspend issue you discovered will be still there on arale :)
<pmcgowan> morphis, oh thats not good
<pmcgowan> enjoying my current battery life
<morphis> pmcgowan: we need to land this big thing first
<morphis> but investigation on the suspend issue is ongoing
<Mirv> jhodapp: abeato: I meant that there are no commits in upstream since August. thanks for adapting to the Source -> Items though, that's a big win! but also addItems and moveItem are in API and not in upstream. plus then any bugfixes of course.
<jhodapp> Mirv, yep, I'll be working on the last bits of that today
<jhodapp> Mirv, upstreaming
<morphis> sil2100: when there are any problems merging all three silos please ping me
<jhodapp> sil2100, hey I heard you maintain ubuntu-touch-meta? It has a media-hub dependency on version 3 and silo 9 is going to land version 4, so its dependency needs updating
 * popey joins the queue for sil2100 
<popey> sil2100, is there a plan to have a mid-way fix between OTA-8 and OTA-9?
<popey> or am I dreaming?
<popey> pmcgowan, ^ maybe you know actually
<Mirv> jhodapp: excellent, the silo 009 is a result of long hard work but OTA-9 will basically resolve then ~everything
<Mirv> morphis: davmor2: 2/3 silos published, 043 needs core dev
<pmcgowan> popey, we are considering it yes
<jhodapp> Mirv, yes indeed, and thanks!
<popey> k
<popey> 25/12/2015? :)
<pmcgowan> popey, for special fixes
<pmcgowan> yeah
<popey> oh, not for general landings?
<pmcgowan> no
<pmcgowan> just cherry icks
<pmcgowan> picks
<popey> okay. ahayzen jhodapp ^
<popey> we were wondering about the media stuff
<ahayzen> popey, no we were saying will there be a framework bump for OTA9
<jhodapp> popey, I'm fine with it going out with OTA9
<popey> oh
<ahayzen> popey, or are you asking multiple questions? ;-)
<popey> i misunderstood, fair enough
<popey> maybe, yes, that
<popey> ahem
<ahayzen> otherwise we'll end up with the usual situation of people on OTA8 trying to run a music-app that won't run due to media-hub/mediascanner2 changes in OTA9 etc
<morphis> Mirv: wow
<morphis> Mirv: anyone we can ping to get this done now?
<Mirv> morphis: on #ubuntu-devel, I'll ask
<morphis> Mirv: thanks
<sil2100> jhodapp: on it! Sorry, I had some visitors ;)
<jhodapp> sil2100, awesome thank you!
<jhodapp> sil2100, you can put that into silo 9 with our changes if desired
<dobey> kenvandine: hey, can i bug you for a packaging ack? :)
<davmor2> sil2100: what kinda excuse is that???
<sil2100> davmor2: a good one!
<davmor2> sil2100: who would you normally pick on core dev wise for landing like 43?
<kenvandine> dobey, in a few :)
<sil2100> hmmm
<sil2100> cyphermox, kenvandine: hey guys! I would need someone to publish the bluez silo (silo 43)
<cyphermox> sil2100: ok
<sil2100> jhodapp: hey, I'll prepare the seed change locally and upload once you release the package - reason is that we're about to land the bluez silo which already has ubuntu-touch-meta
<jhodapp> sil2100, let me know when you've pushed the change to ubuntu-touch-meta and I'll make sure that media-hub*3 can be removed without breaking things
<sil2100> So we'll have to re-build
<jhodapp> sil2100, lol good timing :)
<sil2100> jhodapp: yeah ;) Well, I could upload, but that would be pointless as we'll have to rebuild anyway
<jhodapp> sil2100, so is that an issue, because like I said we'll have media-hub 3 and 4 installed then
<sil2100> jhodapp: well, once you land it, I can publish the seed change before the new media-hub gets into an image
<jhodapp> ah perfect, ok
<jhodapp> that's a good plan then
<kenvandine> dobey, link for the packaging ack?
<dobey> kenvandine: https://requests.ci-train.ubuntu.com/#/ticket/668 is the silo
<dobey> the request
<davmor2> cyphermox: \o/ thanks dude
<tvoss> sil2100, hey there :) could you cancel the outstanding builds for powerpc for https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-021/+packages
<tvoss> sil2100, they will fail and I'm tired of waiting
<sil2100> tvoss: sure, ok
<sil2100> tvoss: cancelled ;)
<tvoss> sil2100, thank you
<jhodapp> jibel, background playlists are ready for testing, it should show up in the QA Trello board shortly (silo 9)
<jhodapp> jibel, let me or abeato know if there's any questions
<kenvandine> dobey, good to go, should i publish?
<dobey> kenvandine: yes please. thanks!
<cjwatson> tvoss: I'm sorry about the wait.  Somebody (*glares at suspect*) put all the builders on manual without telling us about it or explaining why.
<tvoss> cjwatson, no worries :)
<tvoss> sil2100, I would appreciate a review here: https://code.launchpad.net/~thomas-voss/location-service/enable-dual-landing/+merge/278143
<sil2100> tvoss: looking after the meeting :)
<morphis> robru, sil2100, Mirv: you saw the discussion around version numbers in #ubuntu-devel?
<xavigarcia> jibel: Hi there, I've already talked to design and we agreed that when switching off the Location switch it will make hide the location icon
<xavigarcia> jibel: silo 6 shoud be again ready with that change
<xavigarcia> jibel: there is a 5 minute delay showing the icon that is not clear yet, they already added a note to the specs stating that
<jdstrand> sil2100, pmcgowan: when did we start shipping 15.10 frameworks on the device? I see the folloing on mako:
<jdstrand> $ ls -1 /usr/share/click/frameworks/*15.10*
<jdstrand> /usr/share/click/frameworks/ubuntu-sdk-15.10-dev1.framework
<jdstrand> /usr/share/click/frameworks/ubuntu-sdk-15.10-html-dev1.framework
<jdstrand> /usr/share/click/frameworks/ubuntu-sdk-15.10-papi-dev1.framework
<jdstrand> /usr/share/click/frameworks/ubuntu-sdk-15.10-qml-dev1.framework
<jdstrand> I find this very confusing. how can a 15.04 stable system have 15.10 frameworks?
<pmcgowan> jdstrand, it shouldnt we should have removed that
<jdstrand> (not to mention, click-apparmor in the overlay doesn't know what to do with them, so if an app targeted it, it would blow up)
<jdstrand> ok, good
<jdstrand> well, for some definition of good
<pmcgowan> sil2100, we were supposed to take thse out when we went to 15.04.1
<jdstrand> pmcgowan: shall I file a bug?
<pmcgowan> jdstrand, yes please
<jdstrand> pmcgowan: https://bugs.launchpad.net/ubuntu-rtm/+source/ubuntu-touch-meta/+bug/1518393
<ubot5> Ubuntu bug 1518393 in ubuntu-touch-meta (Ubuntu RTM) "stable phone overlay has 15.10 frameworks, but it shouldn't" [Undecided,New]
<sil2100> pmcgowan: will remove those as well, yeah...
<robru> morphis: I saw mention of version numbers but I didn't follow what the problem was our what the desired behavior was. Please file a bug against lp:cupstream2distro explaining it in detail
<davmor2> sil2100:  if all the bluez5 stuff landed are you able to spin up a new image please, not sure if you got my earlier request
<pmcgowan> sil2100, they are ok on xenial but not on vivid overlay
<sil2100> davmor2: looks landed indeed, checking if everything is published and I'll kick an image now
<sil2100> pmcgowan: yeah, not sure how those ended up in our vivid seeds, maybe I copied them over by accident
<davmor2> sil2100: blame the Spanish inquisition nobody will expect that ;)d
<sil2100> It's building now :)
<davmor2> sil2100: \o/
<robru> hmmmmm
<robru> kenvandine: do you know what's going on with https://requests.ci-train.ubuntu.com/#/ticket/54 ? seems an old landing, not sure what happened there...
<kenvandine> robru, oh... that wasn't supposed to be merged
<kenvandine> it was an experimental silo
<robru> kenvandine: yeah I don't know why the train is trying to merge it, since it's not landed.
<robru> unless the version numbers match or something...
<kenvandine> robru, can i edit the silo then kick a rebuild?
<kenvandine> it's still useful for us
<robru> kenvandine: yeah
<robru> kenvandine: oh, haha, false alarm. it wasn't trying to merge it, there's just a bug causing the error to *say* merge&clean.
<kenvandine> robru, good
<robru> kenvandine: side effect of sloppy imports. the 'X failed:' prefix for exception messages is set at import time rather than runtime and the merging code gets *imported* in that script so it uses that prefix on exceptions
<robru> kenvandine: you can force build to overcome that ^
<kenvandine> robru, thx
<robru> kenvandine: you're welcome
<fginther> anpok, I'm looking at the unity-system-compositor problem you reported. If I find the fix, I'll rebuild that MP
<anpok> thx!
<fginther> anpok, it looks like this build was triggered from a manual rebuild. Is that correct?
<anpok> yes
<fginther> anpok, thanks for confirming. The build parameters appeared to have been set from when the job was configured to build for wily and it caused problems when building under xenial.  I've retriggered a new build with 'local_archive_pocket' set to xenial.  That should work, but will monitor it to make sure.
<anpok> oh
<anpok> ah.. right the build failure back then was still with a wily setup..
<anpok> thx
<fginther> anpok, you're welcome, sorry that this detail handled more intuitively
<fginther> *isn't* handled more intuitively
<boiko> rvr: hi, I just need to rebuild telepathy-ofono on silo 25 to include the fixes that just got merged from silo 52
<boiko> rvr: as it is only bluetooth device names, shouldn't interfere with the tests already done
<dobey> trainguards: can someone retry a few builds for me?
<dobey> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-015/+build/8324821
<dobey> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-015/+build/8271658
<dobey> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-015/+build/8271661
<dobey> thanks
<robru> dobey: on it
<rvr> boiko: ok
<popey> ToyKeeper, thanks for testing music - seems I made a mistake and gave you the wrong click, have updated the citrain and trello card accordingly!
<popey> (this fixes the issue you identiied)
<popey> *identified
#ubuntu-ci-eng 2015-11-21
<robru> lol, oops
#ubuntu-ci-eng 2015-11-22
<robru> uh
<robru> well that was odd
#ubuntu-ci-eng 2016-11-21
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Needs rebuild due to new commits (zesty/ubuntu-system-settings). Successfully built (vivid/indicator-power, vivid/ubuntu-settings-components, vivid/ubuntu-system-settings, vivid/unity8, xenial/indicator-power, xenial/ubuntu-settings-components, xenial/ubuntu-system-settings, xenial/unity8, zesty/indicator-power, zesty/ubuntu-settings-components, zesty/unity8)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Preparing packages
-queuebot:#ubuntu-ci-eng- alf__, https://bileto.ubuntu.com/#/ticket/2221 Preparing packages
-queuebot:#ubuntu-ci-eng- alf__, https://bileto.ubuntu.com/#/ticket/2221 zesty/repowerd: Failed to tag release
-queuebot:#ubuntu-ci-eng- alf__, https://bileto.ubuntu.com/#/ticket/2221 Preparing packages
-queuebot:#ubuntu-ci-eng- alf__, https://bileto.ubuntu.com/#/ticket/2221 Successfully built
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Pending binary packages (zesty/ubuntu-system-settings). Successfully built (vivid/indicator-power, vivid/ubuntu-settings-components, vivid/ubuntu-system-settings, vivid/unity8, xenial/indicator-power, xenial/ubuntu-settings-components, xenial/ubuntu-system-settings, xenial/unity8, zesty/indicator-power, zesty/ubuntu-settings-components, zesty/unity8)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Failed to build (zesty/unity-api). Needs rebuild due to new commits (zesty/unity8). Successfully built (vivid/unity-api, vivid/unity8, xenial/unity-api, xenial/unity8)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Currently building (vivid/unity8, xenial/unity8, zesty/unity8). Failed to build (zesty/unity-api). Successfully built (vivid/unity-api, xenial/unity-api)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2194 Needs rebuild due to new commits (zesty/ubuntu-system-settings). Successfully built (vivid/ubuntu-system-settings, vivid/ubuntu-themes, xenial/ubuntu-system-settings, xenial/ubuntu-themes, zesty/ubuntu-themes)
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2215 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Failed to build (xenial/ubuntu-app-launch). Needs rebuild due to new commits (zesty/mediaplayer-app, zesty/ubuntu-app-launch, zesty/ubuntu-system-settings). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-keyboard, xenial/indicator-location, xenial/indicator-message
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Failed to build (zesty/unity-api). Pending binary packages (vivid/unity8, xenial/unity8, zesty/unity8). Successfully built (vivid/unity-api, xenial/unity-api)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2194 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Failed to build (zesty/unity-api). Successfully built (vivid/unity-api, vivid/unity8, xenial/unity-api, xenial/unity8, zesty/unity8)
-queuebot:#ubuntu-ci-eng- charles, https://bileto.ubuntu.com/#/ticket/2188 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Pending binary packages (vivid/nuntium). Ready to build (xenial/nuntium, zesty/nuntium). Successfully built (vivid/dialer-app, vivid/gsettings-ubuntu-touch-schemas, vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/gsettings-ubuntu-touch-schemas, xenial/history-service, xenial/messagi
<ChrisTownsend> #ubuntu-qa: Hi!  I wanted to give a heads up that I have yet one more change for the already approved https://bileto.ubuntu.com/#/ticket/2123.  This time, it's a one line change in debian/control to fix a Breaks/Replaces versioning issue.
<ChrisTownsend> I can't fix it in anther landing because this landing is stuck in -proposed due to the issue.
<rvr> ChrisTownsend: :-/
<ChrisTownsend> rvr: Yeah, I know
<ChrisTownsend> rvr: This thing has been a pain
<rvr> ChrisTownsend: I'll take a look after I finish with the current silo
<ChrisTownsend> rvr: Well, it'll be a bit.  I still need to commit the change, rebuild, and then let autopkgtest's run.
<rvr> ChrisTownsend: Ok, let me know when it's ready
<ChrisTownsend> rvr: Ok, thanks!
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2194 Needs rebuild due to new commits (zesty/ubuntu-system-settings). Successfully built (vivid/ubuntu-system-settings, vivid/ubuntu-themes, xenial/ubuntu-system-settings, xenial/ubuntu-themes, zesty/ubuntu-themes)
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Preparing packages
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 QA Signoff:
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Preparing packages
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2215 Publishing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Diff missing (vivid/nuntium, xenial/nuntium, zesty/nuntium). Successfully built (vivid/dialer-app, vivid/gsettings-ubuntu-touch-schemas, vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/gsettings-ubuntu-touch-schemas, xenial/history-service, xenial/messaging-app, xenial/telepathy-ofo
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Destination version missing from changelog (zesty/libertine). Successfully built (xenial/libertine)
<ChrisTownsend> trainguards: Is "Destination version missing from changelog (zesty/libertine)." something to worry about in https://bileto.ubuntu.com/#/ticket/2123 ?
<sil2100> ChrisTownsend: yeah, in this case it does - it means the previously released libertine didn't migrate yet
<sil2100> So it's possibly not merged to trunk
<ChrisTownsend> sil2100: Right, but it's stuck in proposed and has an issue.
<ChrisTownsend> sil2100: Do I need it to be rejected first?
<ChrisTownsend> sil2100: It's unclear to me how we fix an issue when a release is stuck in proposed.
<sil2100> Ah, so you want it to be overriden?
<ChrisTownsend> sil2100: Yes.
<ChrisTownsend> sil2100: Both in overlay and archive.
<sil2100> ChrisTownsend: so you're re-using the same silo then?
<sil2100> If that's the case then I think you can safely ignore this warning
<ChrisTownsend> sil2100: Well, I did that because I needed to fix up the release branch and since it wasn't merged, I just re-used the silo.
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2215 xenial/unity8-desktop-session: Failed to fetch https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2215/+files/unity8-desktop-session_1.0.13+16.04.20161118-0ubuntu1_source.changes
<ChrisTownsend> Good grief, what does that mean????
<ChrisTownsend> Man, bileto is hating on me today...
<ChrisTownsend> sil2100: Are you able to override the issue on https://bileto.ubuntu.com/#/ticket/2123 so I can get autopkgtest's to run?
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Currently building (xenial/ubuntu-system-settings, zesty/ubuntu-system-settings). Failed to build (zesty/ubuntu-app-launch). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-keyboard, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-network, xen
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Preparing packages
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Preparing packages
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2215 Release pocket
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Failed to build (zesty/ubuntu-app-launch). Needs rebuild due to new commits (zesty/ubuntu-system-settings). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-keyboard, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-network, xenial/indicator-pow
<mterry> robru: does this behavior make any sense to you: bug 1642350 ?
<ubot5`> bug 1642350 in Snapcraft "webbrowser-app silently being excluded from stage-packages" [Undecided,New] https://launchpad.net/bugs/1642350
<mterry> robru: I'm guessing it's snapcraft side (the fact that it's silent certainly is a bug), but maybe there's something weird about the script that builds the snap too?
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Failed to build (vivid/camera-app, xenial/camera-app, zesty/camera-app). Pending binary packages (vivid/mediaplayer-app, xenial/mediaplayer-app, zesty/mediaplayer-app). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/dialer-app, vivid/gallery-app, vivid/messaging-app, xenial/address-book-app, xenial/address-book-service, xenial/dialer-app, xenial/gallery-app, xe
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Generating diffs
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2194 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Diff missing (vivid/nuntium, xenial/nuntium, zesty/nuntium). Successfully built (vivid/dialer-app, vivid/gsettings-ubuntu-touch-schemas, vivid/history-service, vivid/messaging-app, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/gsettings-ubuntu-touch-schemas, xenial/history-service, xenial/messaging-app, xenial/telepathy-ofo
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Successfully built
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Failed to build (vivid/camera-app, xenial/camera-app, zesty/camera-app). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/dialer-app, vivid/gallery-app, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-app, xenial/address-book-service, xenial/dialer-app, xenial/gallery-app, xenial/mediaplayer-app, xenial/messaging-app, zesty/address-book-app, zesty
<ChrisTownsend> sil2100: So, any way to override bileto for https://bileto.ubuntu.com/#/ticket/2123 so I can move on and get automated tests to run?  If I set Lander Signoff to Approved, it doesn't accept it.
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Successfully built
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- Wellark charles seb128, https://bileto.ubuntu.com/#/ticket/1649 DONE queue
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2200 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Currently building (vivid/history-service, zesty/history-service). Failed to build (vivid/camera-app, xenial/camera-app, zesty/camera-app). Pending binary packages (xenial/history-service). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/dialer-app, vivid/gallery-app, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-app, xenial/address-book-servic
<sil2100> ChrisTownsend: just finished a meeting, let me take a look
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Pending binary packages (vivid/messaging-app, xenial/messaging-app, zesty/messaging-app). Successfully built (vivid/dialer-app, vivid/gsettings-ubuntu-touch-schemas, vivid/history-service, vivid/nuntium, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/gsettings-ubuntu-touch-schemas, xenial/history-service, xenial/nuntium, xen
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Failed to build (vivid/camera-app, xenial/camera-app, zesty/camera-app). Needs rebuild due to new commits (zesty/history-service). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/dialer-app, vivid/gallery-app, vivid/history-service, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-app, xenial/address-book-service, xenial/dialer-app, xenial/gallery
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2194 Successfully built
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Successfully built
<sil2100> ChrisTownsend: I think we need robru here
<sil2100> robru: hey! Is there any possibility to override the warning from silo https://bileto.ubuntu.com/#/ticket/2123 ?
<sil2100> robru: since we need to overwrite the version that's in -proposed as it's broken
<sil2100> robru: this should be a valid case btw.
<ChrisTownsend> sil2100: Ok, thanks.  Will wait on robru's response:)
<robru> sil2100: ChrisTownsend: why don't you just put the destination version in your changelog? I don't think that message can be overridden, no
<robru> mterry: huh, no idea.
<ChrisTownsend> robru: I guess I don't understand.  Why do I have to specify that?  What would it be looking for?
<robru> ChrisTownsend: this check is preventing you from accidentally reverting a release from a different ticket. Typically it happens when you have the same package on two tickets, if you publish both, the second one will revert the first one.
<robru> ChrisTownsend: so what you need to do is take the debian/changelog from -proposed and include it in your release so that it's sees the same version numbers there and doesn't think you're reverting anything
<ChrisTownsend> robru: Ugh, this is the same release.  So basically you are saying I need to hack up the changelog to work around this.
<ChrisTownsend> robru: But I see the logic of why this is being prevented.
<robru> ChrisTownsend: https://bileto.ubuntu.com/log/2123/status/1511/ it gives the full diff of what it thinks it's missing
<ChrisTownsend> robru: Ok, thnaks
<ChrisTownsend> thanks even
<ChrisTownsend> robru: This is what I think I should do: http://pastebin.ubuntu.com/23512607/
<ChrisTownsend> robru: Do I keep 'zesty' there or revert it to UNRELEASED and let bileto fill it in?
<robru> ChrisTownsend: Hmmmmmmm...
<robru> ChrisTownsend: I'm not sure if that will work
<ChrisTownsend> robru: Ok:)
<robru> ChrisTownsend: you're better off creating a new entry after that entry that explains what you're fixing
<ChrisTownsend> robru: Ok, I wondered if that's what I needed.
<robru> ChrisTownsend: if you leave it as is it might just clobber that version and then give you the same error, I can't remember quite how that code works
<ChrisTownsend> robru: Thanks
<robru> ChrisTownsend: you're welcome
<ChrisTownsend> robru: Oh, one last question, would I put the 1.4.3-0ubuntu1 version and UNRELEASED distro in for the new stanza?
<robru> ChrisTownsend: yeah, it'll clobber the UNRELEASED version with the version number it generates.
<ChrisTownsend> robru: Ok, so safe to ignore the dch warning of a lesser version then, right?
<robru> ChrisTownsend: yeah
<ChrisTownsend> robru: Ok, great, thanks!
<robru> ChrisTownsend: you're welcome
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2195 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Failed to build (zesty/libertine). Successfully built (xenial/libertine)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Failed to build (zesty/libappindicator). Successfully built (zesty/appmenu-qt5, zesty/sni-qt)
<ChrisTownsend> trainguards: Hi, could you retry https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2123/+build/11235505 please?  That was not failing before, but claims it's due to the libcontent-hub-dev dependency.  Maybe it's a transient issue???
<Saviq> mterry, hey, can you publish https://bileto.ubuntu.com/#/ticket/2195 please?
<mterry> looking
<sil2100> ChrisTownsend: done
<ChrisTownsend> sil2100: Thanks
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2195 Publishing packages
<mterry> Saviq: done
<Saviq> mterry, thanks! TrevinhoÂ â
<Trevinho> Saviq: yeah, noticed... thanks mterry ! :-)
<Saviq> robru, uh oh https://bileto.ubuntu.com/log/2195/publish/1/ ?
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Destination version missing from changelog (zesty/libertine). Successfully built (xenial/libertine)
<ChrisTownsend> robru: Still didn't work:(  ^^^^^
<robru> ChrisTownsend: Saviq: sorry in meeting
<ChrisTownsend> robru: Ok
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Needs rebuild due to new commits (zesty/libappindicator). Successfully built (zesty/appmenu-qt5, zesty/sni-qt)
<mterry> Saviq: I've seen that error before -- we need to wait and see what gets published -- and maybe publish the silo again
<Saviq> mterry, we can probably just publish again, still might be interesting to see what's the problem - from the looks of it, it's a launchpad/archive issue (malformed JSON somewhere)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2195 Release pocket (vivid/indicator-datetime, vivid/qmenumodel, vivid/ubuntu-settings-components, vivid/ubuntu-system-settings, vivid/unity8, xenial/indicator-datetime, xenial/qmenumodel, xenial/ubuntu-settings-components, xenial/ubuntu-system-settings, xenial/unity8). Successfully built (zesty/indicator-datetime, zesty/qmenumodel, zesty/ubuntu-settings-components, zesty/ubuntu-system-settings, zes
<Saviq> OTOH it looks like maybe it published everything (15 entries re: copying/requesting copy)
<Saviq> let's see
<robru> Saviq: yeah that's a failure of launchpad to respond to the copy request. harmless to publish again
<robru> but maybe wait for the status to update to see if it missed anything
<Saviq> robru, wonder if we could catch and retry?
<robru> Saviq: yeah file a bug I guess, I'm not sure where would be the best place to do the catch & retry because *all* lp api calls are subject to this and one thing I don't want to do is litter the catch & retry *everywhere* in the code, but not clear to me that there's a sensible central place to do it from.
<mterry> Imma publish again.  Looks like only xenial+vivid got the update
<Saviq> robru, right, makes sense
<robru> ChrisTownsend: looking now. I think the diff is cached or something. your branch looked good to me before...
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2195 Publishing packages
<ChrisTownsend> robru: Ok, thanks
<Saviq> robru, bug #1643672
<ubot5`> bug 1643672 in Bileto "Bileto could be more persistent when doing HTTP calls" [Undecided,New] https://launchpad.net/bugs/1643672
<robru> Saviq: ok thanks
<robru> ChrisTownsend: yeah the diff is cached, I need to escalate to webops to clear that out
<ChrisTownsend> robru: Ack, thanks again
<robru> ChrisTownsend: you're welcome. actually... actually I think there's a way around this.
<robru> (just digging into code)
<ChrisTownsend> Oh?
-queuebot:#ubuntu-ci-eng- charles, https://bileto.ubuntu.com/#/ticket/2188 QA Signoff:
-queuebot:#ubuntu-ci-eng- charles, https://bileto.ubuntu.com/#/ticket/2188 Destination version missing from changelog (zesty/indicator-datetime). Successfully built (xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-power, xenial/indicator-printers, xenial/indicator-session, xenial/indicator-sound, xenial/indicator-transfer, zesty/indicator-application, zesty/indic
<charles> grr
<robru> ChrisTownsend: what you should do is commit the changelog entry for 1.4.3+17.04.20161118.1-0ubuntu1 directly to *trunk* (not in your MP), then rebase your MP on that. that'll fool it into thinking that the destination version was merged to trunk.
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Destination version missing from changelog (zesty/unity8). Failed to build (zesty/unity-api). Successfully built (vivid/unity-api, vivid/unity8, xenial/unity-api, xenial/unity8)
<ChrisTownsend> robru: That sounds evil, but whatever works:)
<robru> ChrisTownsend: yeah we used to have lots of problems with conflicting tickets released in parallel so the protections against that became quite aggressive...
<robru> ChrisTownsend: another option would be deleting the package from -proposed but that would require an archive admin, committing to trunk is something you can do yourself at least
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Destination version missing from changelog (zesty/ubuntu-settings-components, zesty/ubuntu-system-settings, zesty/unity8). Successfully built (vivid/indicator-power, vivid/ubuntu-settings-components, vivid/ubuntu-system-settings, vivid/unity8, xenial/indicator-power, xenial/ubuntu-settings-components, xenial/ubuntu-system-settings, xenial/unity8, zesty/indicator-power)
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Failed to build (vivid/camera-app, xenial/camera-app, zesty/camera-app). Needs rebuild due to new commits (zesty/address-book-app, zesty/history-service). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/dialer-app, vivid/gallery-app, vivid/history-service, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-app, xenial/address-book-service, xenial/di
<ChrisTownsend> robru: I already asked an AA and they told me they weren't going to do it because it's completely supported to supersede the package in proposed.  So I'm going your route:)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2194 Destination version missing from changelog (zesty/ubuntu-system-settings). Successfully built (vivid/ubuntu-system-settings, vivid/ubuntu-themes, xenial/ubuntu-system-settings, xenial/ubuntu-themes, zesty/ubuntu-themes)
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Destination version missing from changelog (zesty/indicator-datetime). Failed to build (zesty/ubuntu-app-launch). Needs rebuild due to new commits (zesty/ubuntu-system-settings). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-keyboard, xenial/indicator-location, xe
-queuebot:#ubuntu-ci-eng- Saviq, https://bileto.ubuntu.com/#/ticket/2197 Destination version missing from changelog (zesty/unity8). Successfully built (vivid/unity8, xenial/unity8)
<robru> ChrisTownsend: yeah this used to work better, I'm not quite sure how it got this way... it's been a long time since i touched the code in question, I'm not sure why nobody had this problem sooner
<robru> I'll file a bug
<ChrisTownsend> robru: I guess I'm lucky:)  Any ways, thanks for your help on this...about to commit and push the rebased branch and will rebuild.
<robru> ChrisTownsend: you're welcome
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2140 Destination version missing from changelog (zesty/ubuntu-system-settings). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/ubuntu-system-settings, xenial/qtmir, xenial/qtmir-gles, xenial/ubuntu-system-settings, zesty/qtmir, zesty/qtmir-gles)
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Preparing packages
<robru> ChrisTownsend: https://bugs.launchpad.net/bileto/+bug/1643676
<ubot5`> Ubuntu bug 1643676 in Bileto "Rebuilding after publication has regressed" [Medium,Triaged]
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2202 Destination version missing from changelog (zesty/unity8). Successfully built (vivid/unity8, xenial/unity8)
<ChrisTownsend> robru: Great, thanks
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Preparing packages
<robru> ChrisTownsend: you're welcome
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2195 Proposed pocket (zesty/indicator-datetime, zesty/qmenumodel, zesty/ubuntu-settings-components, zesty/ubuntu-system-settings, zesty/unity8). Release pocket (vivid/indicator-datetime, vivid/qmenumodel, vivid/ubuntu-settings-components, vivid/ubuntu-system-settings, vivid/unity8, xenial/indicator-datetime, xenial/qmenumodel, xenial/ubuntu-settings-components, xenial/ubuntu-system-settings, xenial/
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Successfully built
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Failed to build (vivid/camera-app, xenial/camera-app, zesty/camera-app). Needs rebuild due to new commits (zesty/address-book-app, zesty/gallery-app, zesty/history-service). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/dialer-app, vivid/gallery-app, vivid/history-service, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-app, xenial/address-book
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2195 Proposed pocket (zesty/qmenumodel, zesty/ubuntu-settings-components, zesty/ubuntu-system-settings, zesty/unity8). Release pocket (vivid/indicator-datetime, vivid/qmenumodel, vivid/ubuntu-settings-components, vivid/ubuntu-system-settings, vivid/unity8, xenial/indicator-datetime, xenial/qmenumodel, xenial/ubuntu-settings-components, xenial/ubuntu-system-settings, xenial/unity8, zesty/indicator-da
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Preparing packages
<robru> kenvandine: can you republish https://bileto.ubuntu.com/#/ticket/2123 with the latest packaging fix?
 * kenvandine looks
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2140 Successfully built
<kenvandine> robru, done
<robru> kenvandine: thanks
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Publishing packages
<robru> ugh
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Publish failed: Destination version missing from changelog
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2202 Successfully built
<robru> kenvandine: will you be around for a bit? I can fix that, will need you to publish again in about 15 mins.
<kenvandine> robru, sure
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Failed to build (zesty/libappindicator). Successfully built (zesty/appmenu-qt5, zesty/sni-qt)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Failed to build (zesty/unity-api). Successfully built (vivid/unity-api, vivid/unity8, xenial/unity-api, xenial/unity8, zesty/unity8)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Successfully built
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2194 Successfully built
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Destination version missing from changelog (zesty/indicator-datetime). Needs rebuild due to new commits (zesty/ubuntu-app-launch, zesty/ubuntu-system-settings). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-keyboard, xenial/indicator-location, xenial/indicator-mes
-queuebot:#ubuntu-ci-eng- Saviq, https://bileto.ubuntu.com/#/ticket/2197 Successfully built
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Preparing packages
<robru> kenvandine: ok please publish again
<robru> mterry: sorry did you figure out that stage-package issue? sounded like a bug in lp to me, bileto doesn't touch stage-packages at all
<mterry> robru: no.  I mean, I *think* the failure would be at least partly in snapcraft.  Since it doesn't even mention a failure to get the package at all...  (Or a log-capturing error on bileto's part maybe...)
<kenvandine> robru, same thing
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Publishing packages
<robru> mterry: no bileto doesn't touch the build log at all, it's entirely in lp
<robru> kenvandine: but but...
<mterry> robru: well fine, but my point is I blame snapcraft  :)
<robru> kenvandine: I think you're looking at a cached page, it's still running here
<kenvandine> hmmm
<kenvandine> it opened a new tab
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2140 Destination version missing from changelog (zesty/ubuntu-system-settings). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/ubuntu-system-settings, xenial/qtmir, xenial/qtmir-gles, xenial/ubuntu-system-settings, zesty/qtmir, zesty/qtmir-gles)
<kenvandine> and i clicked ack and publish...
<robru> kenvandine: says it worked
<kenvandine> great then :)
<robru> kenvandine: ok thanks
<kenvandine> np
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2202 Destination version missing from changelog (zesty/unity8). Successfully built (vivid/unity8, xenial/unity8)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2105 Failed to build (xenial/ubuntu-app-launch). Needs rebuild due to new commits (zesty/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Destination version missing from changelog (zesty/unity8). Failed to build (zesty/unity-api). Successfully built (vivid/unity-api, vivid/unity8, xenial/unity-api, xenial/unity8)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Destination version missing from changelog (zesty/ubuntu-settings-components, zesty/ubuntu-system-settings, zesty/unity8). Successfully built (vivid/indicator-power, vivid/ubuntu-settings-components, vivid/ubuntu-system-settings, vivid/unity8, xenial/indicator-power, xenial/ubuntu-settings-components, xenial/ubuntu-system-settings, xenial/unity8, zesty/indicator-power)
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Preparing packages
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2194 Destination version missing from changelog (zesty/ubuntu-system-settings). Successfully built (vivid/ubuntu-system-settings, vivid/ubuntu-themes, xenial/ubuntu-system-settings, xenial/ubuntu-themes, zesty/ubuntu-themes)
-queuebot:#ubuntu-ci-eng- Saviq, https://bileto.ubuntu.com/#/ticket/2197 Destination version missing from changelog (zesty/unity8). Successfully built (vivid/unity8, xenial/unity8)
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 Needs rebuild due to new commits (zesty/content-hub). Successfully built (vivid/content-hub, xenial/content-hub)
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Proposed pocket (zesty/libertine). Release pocket (xenial/libertine)
<robru> kenvandine: http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#libertine this doesn't look any better than it did before, do you know the situation here?
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 Preparing packages
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 zesty/content-hub: Failed to merge https://code.launchpad.net/~attente/content-hub/content-hub-glib
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Failed to build (vivid/camera-app, xenial/camera-app, zesty/camera-app). Needs rebuild due to new commits (zesty/address-book-app, zesty/history-service). Pending binary packages (vivid/gallery-app, xenial/gallery-app). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/dialer-app, vivid/history-service, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-bo
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 Preparing packages
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 zesty/content-hub: Failed to branch https://code.launchpad.net/~attente/content-hub/content-hub-glib
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 Preparing packages
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 zesty/content-hub: Failed to merge https://code.launchpad.net/~attente/content-hub/content-hub-glib
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 Preparing packages
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 zesty/content-hub: Failed to merge https://code.launchpad.net/~attente/content-hub/content-hub-glib
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 Preparing packages
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Failed to build (vivid/camera-app, xenial/camera-app, zesty/camera-app). Needs rebuild due to new commits (zesty/address-book-app, zesty/history-service). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/dialer-app, vivid/gallery-app, vivid/history-service, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-app, xenial/address-book-service, xenial/di
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Destination version missing from changelog (zesty/indicator-datetime). Failed to build (xenial/ubuntu-app-launch, zesty/ubuntu-app-launch). Needs rebuild due to new commits (zesty/ubuntu-system-settings). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-keyboard, xen
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 Currently building (vivid/content-hub). Failed to build (xenial/content-hub, zesty/content-hub)
 * tsimonq2 looks around for Mirv
<tsimonq2> Ah I see, I see his away message.
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 Failed to build (xenial/content-hub, zesty/content-hub). Successfully built (vivid/content-hub)
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Destination version missing from changelog (zesty/indicator-datetime). Needs rebuild due to new commits (zesty/ubuntu-system-settings). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-keyboard, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-n
#ubuntu-ci-eng 2016-11-22
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Snapping snap packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2195 Proposed pocket (zesty/qmenumodel, zesty/ubuntu-system-settings). Release pocket (vivid/indicator-datetime, vivid/qmenumodel, vivid/ubuntu-settings-components, vivid/ubuntu-system-settings, vivid/unity8, xenial/indicator-datetime, xenial/qmenumodel, xenial/ubuntu-settings-components, xenial/ubuntu-system-settings, xenial/unity8, zesty/indicator-datetime, zesty/ubuntu-settings-components, zesty/
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Destination version missing from changelog (zesty/indicator-datetime). Needs rebuild due to new commits (zesty/ubuntu-system-settings). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-keyboard, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-n
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2195 Proposed pocket (zesty/qmenumodel). Release pocket (vivid/indicator-datetime, vivid/qmenumodel, vivid/ubuntu-settings-components, vivid/ubuntu-system-settings, vivid/unity8, xenial/indicator-datetime, xenial/qmenumodel, xenial/ubuntu-settings-components, xenial/ubuntu-system-settings, xenial/unity8, zesty/indicator-datetime, zesty/ubuntu-settings-components, zesty/ubuntu-system-settings, zesty/
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2195 Release pocket
-queuebot:#ubuntu-ci-eng- charles, https://bileto.ubuntu.com/#/ticket/2188 Needs rebuild due to new commits (zesty/indicator-datetime). Successfully built (xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-power, xenial/indicator-printers, xenial/indicator-session, xenial/indicator-sound, xenial/indicator-transfer, zesty/indicator-application, zesty/indicator-bluet
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Failed to build (zesty/unity-api). Needs rebuild due to new commits (zesty/unity8). Successfully built (vivid/unity-api, vivid/unity8, xenial/unity-api, xenial/unity8)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Needs rebuild due to new commits (zesty/ubuntu-settings-components, zesty/ubuntu-system-settings, zesty/unity8). Successfully built (vivid/indicator-power, vivid/ubuntu-settings-components, vivid/ubuntu-system-settings, vivid/unity8, xenial/indicator-power, xenial/ubuntu-settings-components, xenial/ubuntu-system-settings, xenial/unity8, zesty/indicator-power)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2194 Needs rebuild due to new commits (zesty/ubuntu-system-settings). Successfully built (vivid/ubuntu-system-settings, vivid/ubuntu-themes, xenial/ubuntu-system-settings, xenial/ubuntu-themes, zesty/ubuntu-themes)
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Needs rebuild due to new commits (zesty/indicator-datetime, zesty/ubuntu-system-settings). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-keyboard, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-network, xenial/indicator-power, xenial/indica
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2140 Needs rebuild due to new commits (zesty/ubuntu-system-settings). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/ubuntu-system-settings, xenial/qtmir, xenial/qtmir-gles, xenial/ubuntu-system-settings, zesty/qtmir, zesty/qtmir-gles)
-queuebot:#ubuntu-ci-eng- charles, https://bileto.ubuntu.com/#/ticket/2188 Preparing packages
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2202 Needs rebuild due to new commits (zesty/unity8). Successfully built (vivid/unity8, xenial/unity8)
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 Preparing packages
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 zesty/content-hub: Failed to merge https://code.launchpad.net/~attente/content-hub/content-hub-glib-2
-queuebot:#ubuntu-ci-eng- charles, https://bileto.ubuntu.com/#/ticket/2188 Currently building (zesty/indicator-datetime). Failed to build (zesty/indicator-location). Pending binary packages (xenial/indicator-application, xenial/indicator-location, xenial/indicator-power, xenial/indicator-session, xenial/indicator-sound, xenial/indicator-transfer, zesty/indicator-messages, zesty/indicator-printers, zesty/indicator-session, zesty/indicator-sound, zesty/indicator-transfer
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 Failed to build (xenial/content-hub). Needs rebuild due to new commits (zesty/content-hub). Successfully built (vivid/content-hub)
-queuebot:#ubuntu-ci-eng- charles, https://bileto.ubuntu.com/#/ticket/2188 Failed to build (zesty/indicator-location). Pending binary packages (zesty/indicator-datetime). Successfully built (xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-power, xenial/indicator-printers, xenial/indicator-session, xenial/indicator-sound, xenial/indicator-transfer, zesty/indicator
-queuebot:#ubuntu-ci-eng- charles, https://bileto.ubuntu.com/#/ticket/2188 Failed to build (zesty/indicator-location). Successfully built (xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-power, xenial/indicator-printers, xenial/indicator-session, xenial/indicator-sound, xenial/indicator-transfer, zesty/indicator-application, zesty/indicator-bluetooth, zesty/indic
-queuebot:#ubuntu-ci-eng- charles, https://bileto.ubuntu.com/#/ticket/2188 Preparing packages
-queuebot:#ubuntu-ci-eng- charles, https://bileto.ubuntu.com/#/ticket/2188 Currently building (xenial/indicator-datetime, zesty/indicator-datetime). Failed to build (zesty/indicator-session). Pending binary packages (xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-power, xenial/indicator-printers, xenial/indicator-session, xenial/indicator-transfer, zesty/indicator-application, zesty/indic
-queuebot:#ubuntu-ci-eng- charles, https://bileto.ubuntu.com/#/ticket/2188 Failed to build (zesty/indicator-session). Pending binary packages (xenial/indicator-datetime, zesty/indicator-datetime, zesty/indicator-sound). Successfully built (xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-power, xenial/indicator-printers, xenial/indicator-session, xenial/indicator-sound, xenial/indicator-tra
-queuebot:#ubuntu-ci-eng- charles, https://bileto.ubuntu.com/#/ticket/2188 Failed to build (zesty/indicator-session). Successfully built (xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-power, xenial/indicator-printers, xenial/indicator-session, xenial/indicator-sound, xenial/indicator-transfer, zesty/indicator-application, zesty/indicator-bluetooth, zesty/indica
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Snapping snap packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Failed to build (xenial/ubuntu-app-launch). Needs rebuild due to new commits (zesty/indicator-datetime, zesty/ubuntu-system-settings). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-keyboard, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-ne
<Saviq> sil2100, hey, can you please finalize the hotfix ticket? thanks! https://bileto.ubuntu.com/#/ticket/2197
<sil2100> Saviq: on it, thanks for poking!
-queuebot:#ubuntu-ci-eng- Saviq, https://bileto.ubuntu.com/#/ticket/2197 Merging branches
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2202 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Preparing packages
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2202 Successfully built
<ltinkl> robru, heyo, any idea what happened to https://bileto.ubuntu.com/#/ticket/2132 ? the last 4 items in the audit log aren't definitely from me, something changed them under my hands :S
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2222 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Currently building (vivid/unity8, xenial/unity8, zesty/unity8). Failed to build (zesty/unity-api). Pending binary packages (vivid/unity-api, xenial/unity-api)
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2222 Successfully built
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2223 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Currently building (zesty/unity8). Failed to build (zesty/unity-api). Pending binary packages (xenial/unity8). Successfully built (vivid/unity-api, vivid/unity8, xenial/unity-api)
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2132 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Failed to build (zesty/unity-api). Successfully built (vivid/unity-api, vivid/unity8, xenial/unity-api, xenial/unity8, zesty/unity8)
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2223 Successfully built
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2222 Preparing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2222 Pending binary packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2222 Successfully built
-queuebot:#ubuntu-ci-eng- alf__, https://bileto.ubuntu.com/#/ticket/2221 Preparing packages
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 zesty/ubuntu-system-settings: Failed to merge https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/fix-hide-broken-panels-on-snappy
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Failed to build (vivid/camera-app, xenial/camera-app, zesty/camera-app). Needs rebuild due to new commits (zesty/address-book-app, zesty/history-service). Pending binary packages (vivid/address-book-service, xenial/address-book-service, zesty/address-book-service). Successfully built (vivid/address-book-app, vivid/dialer-app, vivid/gallery-app, vivid/history-service, vivid/mediaplayer-app, v
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 xenial/indicator-bluetooth: Failed to download DSC file https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2129/+files/indicator-bluetooth_0.0.6+16.04.20161115-0ubuntu1.dsc
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Generating diffs
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Failed to build (vivid/camera-app, xenial/camera-app, zesty/camera-app). Needs rebuild due to new commits (zesty/address-book-app, zesty/history-service). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/dialer-app, vivid/gallery-app, vivid/history-service, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-app, xenial/address-book-service, xenial/di
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Currently building (xenial/address-book-service, xenial/indicator-datetime, xenial/ubuntu-system-settings, zesty/indicator-datetime, zesty/ubuntu-system-settings). Failed to build (xenial/ubuntu-app-launch). Pending binary packages (xenial/address-book-app, zesty/address-book-app, zesty/address-book-service). Successfully built (xenial/indicator-application, xenial/indicator-bluetooth, xenia
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Preparing packages
<rvr> dbarth: mardy: ping
<mardy> rvr: hi!
<rvr> mardy: ÐÑÐ¸Ð²ÐµÑ.
<mardy> rvr: :-))
<rvr> mardy: I am testing silo 2205
<rvr> mardy: I have a problem with Ubuntu Store, can't see anything
<rvr> mardy: In scope-registry logs I see an error
<rvr> mardy: "cannot list snaps"
<mardy> rvr: is that at step 11?
<rvr> mardy: Yes
<mardy> marcustomlinson: hi! Have any idea? ^
<marcustomlinson> mardy, rvr: no idea. Was working last week
<marcustomlinson> rvr, mardy" let me give it another try now
<marcustomlinson> rvr: check that you're connected to wifi or something in the actual unity8 session
<rvr> marcustomlinson: I get ping from 8.8.8.8
<rvr> And I can browse
<mardy> rvr: BTW, I see now that there is another silo, already approved, which seems a duplicate: 2200
<mardy> ah, that looks buggy
<rvr> mardy: 2200 is ubuntu-download-manager
<marcustomlinson> rvr: I'll get back to you, building the snap takes long
<mardy> rvr: true, but the description and the landers are wrong
<rvr> marcustomlinson: I know :D
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2200 Ready to build (vivid/ubuntu-system-settings-online-accounts, xenial/ubuntu-system-settings-online-accounts, zesty/ubuntu-system-settings-online-accounts). Successfully built (vivid/ubuntu-download-manager, xenial/ubuntu-download-manager, zesty/ubuntu-download-manager)
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2223 Proposed pocket
<marcustomlinson> rvr: actually, I may have been a little too intricate with that test plan anyway. Could you try this: Go to Settings->Accounts->UbuntuOne
<marcustomlinson> rvr: If you see the UbuntuOne sign in page pop up then mardy's fixes are good. The store is really a different problem
<rvr> I hate the gesture wizard
<rvr> marcustomlinson: Yes, I saw the sign in page
<marcustomlinson> rvr: updated the test plan
<marcustomlinson> rvr: I'll let you know if I see the same store issue out of interest asap
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Successfully built
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
<jgdx> anyone know who can fix a no pubkey err in https://launchpad.net/~jonas-drange/+snap/silo-2194 ?
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2194 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Currently building (zesty/ubuntu-system-settings). Failed to build (xenial/ubuntu-app-launch). Pending binary packages (xenial/ubuntu-system-settings). Ready to build (xenial/history-service, zesty/history-service). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-ke
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Preparing packages
<marcustomlinson> rvr: weird, so I just apt updated, built the latest snap, rebooted and store works in the snap
<marcustomlinson> rvr: anyway, for what actually needs to be tested from that silo, you've seen it
<rvr> marcustomlinson: Yeah
<alf_> robru: Hi! Something weird happened with https://bileto.ubuntu.com/#/ticket/2221.
<alf_> robru: somehow different jobs seem to have been mixed up in the same silo. At least that's what it seems like, not sure what's going on.
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2202 Preparing packages
<alf_> robru: 2221 initially had repowerd, then I added a unity8 branch, but suddenly it also has a unity7 sru and the description changed
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Failed to build (vivid/camera-app, xenial/camera-app, zesty/camera-app). Needs rebuild due to new commits (zesty/address-book-app, zesty/history-service, zesty/mediaplayer-app). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/dialer-app, vivid/gallery-app, vivid/history-service, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-app, xenial/address-
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2202 zesty/unity8: Failed to merge https://code.launchpad.net/~mzanetti/unity8/disable-spread-while-locked
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2205 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Pending binary packages (xenial/messaging-app, zesty/messaging-app). Successfully built (vivid/dialer-app, vivid/gsettings-ubuntu-touch-schemas, vivid/history-service, vivid/messaging-app, vivid/nuntium, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/gsettings-ubuntu-touch-schemas, xenial/history-service, xenial/nuntium, xen
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/2223 Release pocket
-queuebot:#ubuntu-ci-eng- bschaefer, https://bileto.ubuntu.com/#/ticket/2180 QA Signoff: Failed
-queuebot:#ubuntu-ci-eng- Cimi, https://bileto.ubuntu.com/#/ticket/2202 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Snapping snap packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Successfully built
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Pending binary packages (vivid/unity8, xenial/unity8). Successfully built (vivid/indicator-power, vivid/ubuntu-settings-components, vivid/ubuntu-system-settings, xenial/indicator-power, xenial/ubuntu-settings-components, xenial/ubuntu-system-settings, zesty/indicator-power, zesty/ubuntu-settings-components, zesty/ubuntu-system-settings, zesty/unity8)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2194 Pending binary packages (vivid/ubuntu-system-settings, xenial/ubuntu-system-settings). Successfully built (vivid/ubuntu-themes, xenial/ubuntu-themes, zesty/ubuntu-system-settings, zesty/ubuntu-themes)
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Failed to build (xenial/ubuntu-app-launch). Needs rebuild due to new commits (zesty/mediaplayer-app). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/history-service, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-keyboard, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-network, xe
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Dependency wait (zesty/unity-api). Failed to build (zesty/qtmir, zesty/qtmir-gles). Needs rebuild due to new commits (zesty/unity8). Pending binary packages (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-api, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unit
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2132 Successfully built
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2194 Successfully built
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Preparing packages
-queuebot:#ubuntu-ci-eng- ChrisTownsend, https://bileto.ubuntu.com/#/ticket/2123 Release pocket
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Preparing packages
<robru> alf_: look at the audit log: https://bileto.ubuntu.com/#/ticket/2221#audit_log Lukas-kde is editing your ticket for some reason, not bileto's fault
<robru> ltinkl: i don't see anything in the audit log for 2132 that isn't from you, it looks like you got confused and started editing 2221 somehow. Not sure how that would happen
<ltinkl_> robru, I definitely didn't edit anything; if you look at the timestamps, all of those 4 edits happened at the very same time (which is quite impossible)
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Successfully built
<ltinkl_> robru, also happened recently here https://bileto.ubuntu.com/#/ticket/2221; here's an excerpt from the audit log http://paste.ubuntu.com/23517860/
<ltinkl_> robru, there's no way I would be able to edit 4 things at once, especially using those in-line edit boxes ;)
<robru> Hmm
<robru> Ok i think i know what caused this, will fix in a minute
<ltinkl_> robru, those faulty texts come from a different silo I had been looking at maybe
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Currently building (vivid/unity8). Failed to build (zesty/qtmir, zesty/qtmir-gles). Needs rebuild due to new commits (zesty/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-api, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-api
<robru> ltinkl_: alf_: ok I pushed an experimental fix, please do let me know if you see the problem again
<ltinkl_> robru, thx
<robru> ltinkl_: yw
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Failed to build (zesty/qtmir, zesty/qtmir-gles). Needs rebuild due to new commits (zesty/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-api, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-api, xenial/unity8, zest
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Successfully built
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Failed to build (xenial/ubuntu-app-launch). Pending binary packages (xenial/mediaplayer-app, zesty/mediaplayer-app). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/history-service, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-keyboard, xenial/indicator-location, xenial/indicator-messages, xenial/indica
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Failed to build (xenial/ubuntu-app-launch). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/history-service, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-keyboard, xenial/indicator-location, xenial/indicator-messages, xenial/indicator-network, xenial/indicator-power, xenial/indicator-printers, xenial/in
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Preparing packages
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Currently building (vivid/unity8, xenial/unity8). Failed to build (zesty/qtmir, zesty/qtmir-gles). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-api, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-api, zesty/qtubuntu, zesty/qtubuntu-g
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Failed to build (zesty/qtmir, zesty/qtmir-gles). Pending binary packages (xenial/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-api, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-api, zesty/qtubuntu, zesty/qtubu
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Preparing packages
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 zesty/mediaplayer-app: Failed to commit https://code.launchpad.net/~renatofilho/mediaplayer-app/unity8-desktop-mode. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Failed to build (zesty/qtmir, zesty/qtmir-gles). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-api, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-api, xenial/unity8, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-set
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Failed to build (vivid/camera-app, xenial/camera-app, zesty/camera-app). Needs rebuild due to new commits (zesty/address-book-app, zesty/history-service, zesty/mediaplayer-app). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/dialer-app, vivid/gallery-app, vivid/history-service, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-app, xenial/address-
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Preparing packages
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 zesty/mediaplayer-app: Failed to commit https://code.launchpad.net/~renatofilho/mediaplayer-app/unity8-desktop-mode. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Failed to build (vivid/camera-app, xenial/camera-app, zesty/camera-app). Needs rebuild due to new commits (zesty/address-book-app, zesty/history-service, zesty/mediaplayer-app). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/dialer-app, vivid/gallery-app, vivid/history-service, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-app, xenial/address-
#ubuntu-ci-eng 2016-11-23
-queuebot:#ubuntu-ci-eng- michi, https://bileto.ubuntu.com/#/ticket/2225 Preparing packages
-queuebot:#ubuntu-ci-eng- michi, jamesh, vanvugt, https://bileto.ubuntu.com/#/ticket/2225 Destination version missing from changelog
-queuebot:#ubuntu-ci-eng- michi, jamesh, vanvugt, https://bileto.ubuntu.com/#/ticket/2225 Preparing packages
-queuebot:#ubuntu-ci-eng- michi, jamesh, vanvugt, https://bileto.ubuntu.com/#/ticket/2225 Failed to build
-queuebot:#ubuntu-ci-eng- michi, jamesh, vanvugt, https://bileto.ubuntu.com/#/ticket/2225 Preparing packages
-queuebot:#ubuntu-ci-eng- michi, jamesh, vanvugt, https://bileto.ubuntu.com/#/ticket/2225 Failed to build
-queuebot:#ubuntu-ci-eng- michi, jamesh, vanvugt, https://bileto.ubuntu.com/#/ticket/2225 Preparing packages
-queuebot:#ubuntu-ci-eng- michi, jamesh, vanvugt, https://bileto.ubuntu.com/#/ticket/2225 Successfully built
-queuebot:#ubuntu-ci-eng- michi, jamesh, vanvugt, https://bileto.ubuntu.com/#/ticket/2225 Publishing packages
-queuebot:#ubuntu-ci-eng- michi, jamesh, vanvugt, https://bileto.ubuntu.com/#/ticket/2225 Publish failed: Packaging diff requires ACK
-queuebot:#ubuntu-ci-eng- michi, jamesh, vanvugt, https://bileto.ubuntu.com/#/ticket/2225 Publishing packages
-queuebot:#ubuntu-ci-eng- michi, jamesh, vanvugt, https://bileto.ubuntu.com/#/ticket/2225 Publish failed: Packaging diff requires ACK
<michi> trainguards: I canât publish 2225 even though I ticked the ACK box. Anyone know how to fix?
<robru> michi: only core devs can ack
<michi> Ah, thanks.
<robru> michi: it looks like you just have a whitespace change in debian/rules. If you revert that you can publish without ack
<michi> the problem was that I pasted the diff from bileto. And the leading tab got turned into four spaces.
<michi> Which broke the makefile, so I pushed another change with the fix.
<michi> RAOF is helping me out.
<robru> michi: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-2225/2016-11-23_05:08:50/zesty_cmake-extras_packaging_changes.diff looks like you fixed one line but not the other
<Guest88682> robru: Yes, sorry for that :(
-queuebot:#ubuntu-ci-eng- michi, jamesh, vanvugt, https://bileto.ubuntu.com/#/ticket/2225 Successfully built
<robru> Guest88682: doesn't bother me at all... But if you fix the other line and eliminate that diff, it can be published without an ack
<michi> robru: About to buildâ¦ Thanks for your help@
<michi> !
<robru> michi: you're welcome
-queuebot:#ubuntu-ci-eng- michi, jamesh, vanvugt, https://bileto.ubuntu.com/#/ticket/2225 Preparing packages
-queuebot:#ubuntu-ci-eng- michi, jamesh, vanvugt, https://bileto.ubuntu.com/#/ticket/2225 Generating diffs
-queuebot:#ubuntu-ci-eng- michi, jamesh, vanvugt, https://bileto.ubuntu.com/#/ticket/2225 Needs rebuild due to new commits
-queuebot:#ubuntu-ci-eng- michi, jamesh, vanvugt, https://bileto.ubuntu.com/#/ticket/2225 Preparing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2205 Publishing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2205 Proposed pocket (zesty/ubuntu-system-settings-online-accounts). Release pocket (xenial/ubuntu-system-settings-online-accounts)
-queuebot:#ubuntu-ci-eng- michi, jamesh, vanvugt, https://bileto.ubuntu.com/#/ticket/2225 Successfully built
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Failed to build (xenial/ubuntu-app-launch). Needs rebuild due to burned version number (xenial/ubuntu-system-settings-online-accounts, zesty/ubuntu-system-settings-online-accounts). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/history-service, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-keyboard, xe
-queuebot:#ubuntu-ci-eng- michi, jamesh, vanvugt, https://bileto.ubuntu.com/#/ticket/2225 Publishing packages
-queuebot:#ubuntu-ci-eng- michi, jamesh, vanvugt, https://bileto.ubuntu.com/#/ticket/2225 Proposed pocket
-queuebot:#ubuntu-ci-eng- michi, jamesh, vanvugt, https://bileto.ubuntu.com/#/ticket/2225 Release pocket
-queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Preparing packages
-queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Currently building (zesty/unity8). Dependency wait (zesty/lxqt-qtplugin). Diff missing (zesty/libqtxdg, zesty/qtlocation-opensource-src, zesty/qtquickcontrols-opensource-src, zesty/qtsystems-opensource-src, zesty/webbrowser-app). Failed to build (zesty/akonadi, zesty/maliit-framework, zesty/qtcurve, zesty/qtmir, zesty/qtmir-gles). Ready to build (zesty/qtbase-opensource-src-gles, z
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Preparing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2205 Release pocket
-queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Dependency wait (zesty/lxqt-qtplugin). Diff missing (zesty/libqtxdg, zesty/qtlocation-opensource-src, zesty/qtquickcontrols-opensource-src, zesty/qtsystems-opensource-src, zesty/webbrowser-app). Failed to build (zesty/akonadi, zesty/maliit-framework, zesty/qtcurve, zesty/qtmir, zesty/qtmir-gles). Ready to build (zesty/qtbase-opensource-src-gles, zesty/qtdeclarative-opensource-src-g
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Failed to build (xenial/ubuntu-app-launch). Needs rebuild due to burned version number (xenial/ubuntu-system-settings-online-accounts). Needs rebuild due to new commits (zesty/ubuntu-system-settings-online-accounts). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/history-service, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-date
-queuebot:#ubuntu-ci-eng- alf, https://bileto.ubuntu.com/#/ticket/2221 Preparing packages
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Failed to build (zesty/qtmir, zesty/qtmir-gles). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-api, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-api, xenial/unity8, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-set
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Failed to build (vivid/camera-app, xenial/camera-app). Needs rebuild due to new commits (zesty/address-book-app, zesty/camera-app, zesty/history-service, zesty/mediaplayer-app). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/dialer-app, vivid/gallery-app, vivid/history-service, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-app, xenial/address-
-queuebot:#ubuntu-ci-eng- josharenson, https://bileto.ubuntu.com/#/ticket/2031 This ticket must be migrated to zesty+xenial+vivid before it can be built
-queuebot:#ubuntu-ci-eng- josharenson, https://bileto.ubuntu.com/#/ticket/2031 Preparing packages
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Preparing packages
-queuebot:#ubuntu-ci-eng- alf, https://bileto.ubuntu.com/#/ticket/2221 Successfully built
-queuebot:#ubuntu-ci-eng- josharenson, https://bileto.ubuntu.com/#/ticket/2031 Pending binary packages (zesty/unity8). Successfully built (vivid/unity8, xenial/unity8)
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Needs rebuild due to new commits (zesty/address-book-app, zesty/history-service, zesty/mediaplayer-app). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/camera-app, vivid/dialer-app, vivid/gallery-app, vivid/history-service, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-app, xenial/address-book-service, xenial/camera-app, xenial/dialer-app, xen
-queuebot:#ubuntu-ci-eng- josharenson, https://bileto.ubuntu.com/#/ticket/2031 Successfully built
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Currently building (xenial/indicator-datetime, xenial/indicator-sound, xenial/ubuntu-app-launch, xenial/ubuntu-system-settings, xenial/ubuntu-themes, zesty/indicator-sound, zesty/mediascanner2, zesty/ubuntu-system-settings, zesty/ubuntu-themes). Failed to build (xenial/indicator-messages, zesty/indicator-network, zesty/indicator-transfer, zesty/ubuntu-app-launch). Pending binary packages (xe
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Currently building (xenial/ubuntu-app-launch, xenial/ubuntu-system-settings, zesty/ubuntu-system-settings). Failed to build (xenial/indicator-messages, xenial/indicator-sound, zesty/indicator-network, zesty/indicator-transfer, zesty/ubuntu-app-launch). Pending binary packages (xenial/indicator-datetime, xenial/ubuntu-themes, zesty/ubuntu-themes). Successfully built (xenial/address-book-app, 
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Failed to build (xenial/indicator-messages, xenial/indicator-sound, xenial/ubuntu-app-launch, zesty/indicator-network, zesty/indicator-transfer, zesty/ubuntu-app-launch). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/history-service, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-keyboard, xenial/indica
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Preparing packages
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 zesty/mediaplayer-app: Failed to commit https://code.launchpad.net/~renatofilho/mediaplayer-app/unity8-desktop-mode. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Preparing packages
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Currently building (vivid/unity8, xenial/unity8, zesty/unity8). Failed to build (zesty/qtmir, zesty/qtmir-gles). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-api, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-api, zesty/qtubuntu, ze
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Failed to build (zesty/qtmir, zesty/qtmir-gles). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-api, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-api, xenial/unity8, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-set
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Needs rebuild due to new commits (zesty/messaging-app). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/camera-app, vivid/dialer-app, vivid/gallery-app, vivid/history-service, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-app, xenial/address-book-service, xenial/camera-app, xenial/dialer-app, xenial/gallery-app, xenial/history-service, xenial/m
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Preparing packages
-queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Preparing packages
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Preparing packages
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2226 Preparing packages
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 zesty/qtmir: Failed to upload package
-queuebot:#ubuntu-ci-eng- jgdx dfiloni, https://bileto.ubuntu.com/#/ticket/2227 Preparing packages
-queuebot:#ubuntu-ci-eng- jgdx dfiloni, https://bileto.ubuntu.com/#/ticket/2227 zesty/account-polld: Failed to commit https://code.launchpad.net/~d.filoni/account-polld/lp1481202. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Failed to build (zesty/qtmir-gles). Needs rebuild due to new commits (zesty/unity8). PPA/bzr version mismatch (zesty/unity-api). Pending binary packages (xenial/qtmir). Successfully built (xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-api, xenial/unity8, zesty/qtmir, zesty/qtubuntu, zesty/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- jgdx dfiloni, https://bileto.ubuntu.com/#/ticket/2227 Preparing packages
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2226 Failed to build (zesty/ubuntu-download-manager). Successfully built (vivid/ubuntu-download-manager, xenial/ubuntu-download-manager)
-queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Dependency wait (zesty/lxqt-qtplugin). Failed to build (zesty/akonadi, zesty/maliit-framework, zesty/qtcurve, zesty/qtmir, zesty/qtmir-gles). Ready to build (zesty/qtbase-opensource-src-gles, zesty/qtdeclarative-opensource-src-gles, zesty/qtlocation-opensource-src-gles, zesty/qtmultimedia-opensource-src-gles, zesty/qtubuntu-gles, zesty/ubuntu-ui-toolkit-gles). Successfully built (z
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 Preparing packages
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 zesty/content-hub: Failed to merge https://code.launchpad.net/~attente/content-hub/content-hub-glib-2
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Failed to build (zesty/qtmir, zesty/qtmir-gles). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-api, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-api, xenial/unity8, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-set
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Preparing packages
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Failed to build (zesty/qtmir-gles). Needs rebuild due to new commits (zesty/qtmir, zesty/unity8). PPA/bzr version mismatch (zesty/unity-api). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-api, xenial/unity8, zesty/qtubuntu, zesty/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2194 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2127 Needs rebuild due to new commits (zesty/content-hub). Successfully built (vivid/content-hub, xenial/content-hub)
-queuebot:#ubuntu-ci-eng- jgdx dfiloni, https://bileto.ubuntu.com/#/ticket/2227 Successfully built
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Preparing packages
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 Bad merges (zesty/content-hub). Failed to build (xenial/content-hub). Successfully built (vivid/content-hub)
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Currently building (vivid/unity8, xenial/unity8, zesty/unity8). Failed to build (zesty/qtmir, zesty/qtmir-gles). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-api, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-api, zesty/qtubuntu, ze
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Needs rebuild due to new commits (zesty/messaging-app). Pending binary packages (vivid/camera-app, xenial/camera-app, zesty/camera-app). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/dialer-app, vivid/gallery-app, vivid/history-service, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-app, xenial/address-book-service, xenial/dialer-app, xenial/g
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Bad merges (zesty/unity8). Failed to build (zesty/qtmir-gles). Needs rebuild due to new commits (zesty/qtmir). PPA/bzr version mismatch (zesty/unity-api). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-api, xenial/unity8, zesty/qtubuntu, zesty/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2151 Bad merges (zesty/unity8). Dependency wait (vivid/qtmir, vivid/qtmir-gles). Needs rebuild due to new commits (zesty/qtmir, zesty/unity-api). Successfully built (vivid/unity-api, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/unity-api, xenial/unity8, zesty/qtmir-gles)
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Failed to build (zesty/qtmir, zesty/qtmir-gles). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-api, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-api, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-settings-components, zesty/unity
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Needs rebuild due to new commits (zesty/messaging-app). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/camera-app, vivid/dialer-app, vivid/gallery-app, vivid/history-service, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-app, xenial/address-book-service, xenial/camera-app, xenial/dialer-app, xenial/gallery-app, xenial/history-service, xenial/m
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2194 Successfully built (vivid/ubuntu-themes, xenial/ubuntu-themes, zesty/ubuntu-themes). Uploading build (vivid/ubuntu-system-settings, xenial/ubuntu-system-settings, zesty/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 Preparing packages
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2228 Preparing packages
-queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Dependency wait (zesty/lxqt-qtplugin). Failed to build (zesty/akonadi, zesty/maliit-framework, zesty/qtcurve, zesty/qtmir-gles). Needs rebuild due to new commits (zesty/qtmir). Ready to build (zesty/qtbase-opensource-src-gles, zesty/qtdeclarative-opensource-src-gles, zesty/qtlocation-opensource-src-gles, zesty/qtmultimedia-opensource-src-gles, zesty/qtubuntu-gles, zesty/ubuntu-ui-t
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Currently building (vivid/unity8, xenial/unity8, zesty/unity8). Failed to build (zesty/qtmir, zesty/qtmir-gles). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-api, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-api, zesty/qtubuntu, ze
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2194 Successfully built
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 Currently building (vivid/content-hub, xenial/content-hub). Failed to build (zesty/content-hub)
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2200 Successfully built
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2228 Successfully built
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Failed to build (zesty/qtmir-gles). Needs rebuild due to new commits (zesty/qtmir). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-api, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-api, xenial/unity8, zesty/qtubuntu, ze
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Preparing packages
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Needs rebuild due to new commits (zesty/address-book-app, zesty/messaging-app). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/camera-app, vivid/dialer-app, vivid/gallery-app, vivid/history-service, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-app, xenial/address-book-service, xenial/camera-app, xenial/dialer-app, xenial/gallery-app, xenial/h
-queuebot:#ubuntu-ci-eng- attente kenvandine, https://bileto.ubuntu.com/#/ticket/2178 Failed to build (xenial/content-hub, zesty/content-hub). Successfully built (vivid/content-hub)
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Failed to build (zesty/qtmir-gles). Needs rebuild due to new commits (zesty/qtmir, zesty/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-api, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-api, xenial/unity8, zest
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Failed to build (xenial/indicator-messages, xenial/indicator-sound, xenial/ubuntu-app-launch, zesty/indicator-network, zesty/indicator-transfer, zesty/ubuntu-app-launch). Needs rebuild due to new commits (zesty/address-book-app). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/history-service, xenial/indicator-application, xenial/indicator-bluetooth, xenial/i
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Bad merges (zesty/unity8). Failed to build (zesty/qtmir, zesty/qtmir-gles). PPA/bzr version mismatch (zesty/unity-api). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-api, xenial/unity8, zesty/qtubuntu, zesty/qtubuntu-gles)
<alf_> robru: Hi! Is there a way to clean the silo before rebuilding? I want to remove the only MP for a package (and thus that package) in my ticket. Should I just abandon and rebuild?
<robru> alf_: yep, abandon and rebuild the same ticket gives you a fresh PPA
<alf_> robru: great, thanks!
<robru> Yw
-queuebot:#ubuntu-ci-eng- alf__, https://bileto.ubuntu.com/#/ticket/2221 Abandoning ticket
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Preparing packages
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Needs rebuild due to new commits (zesty/messaging-app). Pending binary packages (vivid/address-book-app, xenial/address-book-app, zesty/address-book-app). Successfully built (vivid/address-book-service, vivid/camera-app, vivid/dialer-app, vivid/gallery-app, vivid/history-service, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-service, xenial/camera-app, xenial/dialer-app, xe
-queuebot:#ubuntu-ci-eng- alf__, https://bileto.ubuntu.com/#/ticket/2221 Failed to build (zesty/repowerd). Successfully built (xenial/repowerd)
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2228 Publishing packages
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Needs rebuild due to new commits (zesty/messaging-app). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/camera-app, vivid/dialer-app, vivid/gallery-app, vivid/history-service, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-app, xenial/address-book-service, xenial/camera-app, xenial/dialer-app, xenial/gallery-app, xenial/history-service, xenial/m
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2200 Publishing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2200 Publish failed: Packaging diff requires ACK
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2228 Proposed pocket (zesty/unity8-desktop-session). Release pocket (xenial/unity8-desktop-session)
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2200 Successfully built
-queuebot:#ubuntu-ci-eng- mterry, https://bileto.ubuntu.com/#/ticket/2228 Release pocket
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Needs rebuild due to new commits (zesty/telephony-service). Successfully built (vivid/dialer-app, vivid/gsettings-ubuntu-touch-schemas, vivid/history-service, vivid/messaging-app, vivid/nuntium, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/gsettings-ubuntu-touch-schemas, xenial/history-service, xenial/messaging-app, xenial
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Bad merges (zesty/unity8). Failed to build (zesty/qtmir, zesty/qtmir-gles). PPA/bzr version mismatch (zesty/unity-api). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-api, xenial/unity8, zesty/qtubuntu, zesty/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Preparing packages
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Bad merges (zesty/unity8). PPA/bzr version mismatch (zesty/unity-api). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-api, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Failed to understand "https://code.launchpad.net/~renatofilho/mediaplayer-app/shared-snappy/+merge/311212351". Is it a merge?
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Pending binary packages (vivid/unity8, xenial/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-api, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-api, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ub
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Successfully built
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Failed to build (xenial/indicator-messages, xenial/indicator-sound, xenial/ubuntu-app-launch, zesty/indicator-network, zesty/indicator-transfer, zesty/ubuntu-app-launch). Needs rebuild due to new commits (zesty/mediaplayer-app). Successfully built (xenial/address-book-service, xenial/history-service, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Needs rebuild due to new commits (zesty/mediaplayer-app, zesty/messaging-app). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/camera-app, vivid/dialer-app, vivid/gallery-app, vivid/history-service, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-app, xenial/address-book-service, xenial/camera-app, xenial/dialer-app, xenial/gallery-app, xenial/hi
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Preparing packages
#ubuntu-ci-eng 2016-11-24
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Pending binary packages (vivid/camera-app, vivid/gallery-app, xenial/camera-app, xenial/gallery-app). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/dialer-app, vivid/history-service, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-app, xenial/address-book-service, xenial/dialer-app, xenial/history-service, xenial/mediaplayer-app, xenial/messagi
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Successfully built
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Needs rebuild due to new commits (zesty/history-service, zesty/telephony-service). Successfully built (vivid/dialer-app, vivid/gsettings-ubuntu-touch-schemas, vivid/history-service, vivid/messaging-app, vivid/nuntium, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/gsettings-ubuntu-touch-schemas, xenial/history-service, xenia
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Pending binary packages (zesty/libappindicator). Successfully built (zesty/appmenu-qt5, zesty/sni-qt)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Failed to build (zesty/update-notifier). Successfully built (zesty/appmenu-qt5, zesty/libappindicator, zesty/sni-qt)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Pending binary packages (zesty/update-notifier). Successfully built (zesty/appmenu-qt5, zesty/libappindicator, zesty/sni-qt)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Preparing packages
-queuebot:#ubuntu-ci-eng- michi, https://bileto.ubuntu.com/#/ticket/2230 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Successfully built
-queuebot:#ubuntu-ci-eng- michi, jamesh, duflu, https://bileto.ubuntu.com/#/ticket/2230 Needs rebuild due to new commits (zesty/cmake-extras). Successfully built (xenial/cmake-extras)
-queuebot:#ubuntu-ci-eng- michi, jamesh, duflu, https://bileto.ubuntu.com/#/ticket/2230 Preparing packages
-queuebot:#ubuntu-ci-eng- michi, jamesh, duflu, https://bileto.ubuntu.com/#/ticket/2230 Successfully built
-queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Preparing packages
-queuebot:#ubuntu-ci-eng- jamesh, https://bileto.ubuntu.com/#/ticket/2219 Needs rebuild due to new commits (zesty/storage-provider-webdav). Successfully built (xenial/storage-provider-webdav)
-queuebot:#ubuntu-ci-eng- jamesh, https://bileto.ubuntu.com/#/ticket/2219 Preparing packages
-queuebot:#ubuntu-ci-eng- jamesh, https://bileto.ubuntu.com/#/ticket/2219 Dependency wait (zesty/storage-provider-webdav). Successfully built (xenial/storage-provider-webdav)
-queuebot:#ubuntu-ci-eng- Mirv tsimonq2 mitya57, https://bileto.ubuntu.com/#/ticket/1985 Dependency wait (zesty/lxqt-qtplugin). Failed to build (zesty/akonadi, zesty/maliit-framework, zesty/qtcurve, zesty/qtmir-gles). Ready to build (zesty/qtbase-opensource-src-gles, zesty/qtdeclarative-opensource-src-gles, zesty/qtlocation-opensource-src-gles, zesty/qtmultimedia-opensource-src-gles, zesty/qtubuntu-gles, zesty/ubuntu-ui-toolkit-gles). Successfully built (zesty/ciborium
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2200 Publishing packages
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2200 Proposed pocket (zesty/ubuntu-download-manager). Release pocket (vivid/ubuntu-download-manager, xenial/ubuntu-download-manager)
<greyback> trainguards: could someone please kill this unity8 build: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2160/+build/11219095
<sil2100> greyback: on it
<greyback> it appears stuck, has been like that for days
<greyback> thanks!
<sil2100> Done
<greyback> sil2100: thanks!
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Preparing packages
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Bad merges (zesty/unity8). Failed to build (xenial/unity8). PPA/bzr version mismatch (zesty/unity-api). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-api, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles)
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Preparing packages
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2194 Needs rebuild due to new commits (zesty/ubuntu-system-settings). Successfully built (vivid/ubuntu-system-settings, vivid/ubuntu-themes, xenial/ubuntu-system-settings, xenial/ubuntu-themes, zesty/ubuntu-themes)
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Failed to build (xenial/indicator-messages, xenial/indicator-sound, xenial/ubuntu-app-launch, zesty/indicator-network, zesty/indicator-transfer, zesty/ubuntu-app-launch). Needs rebuild due to new commits (zesty/mediaplayer-app, zesty/ubuntu-system-settings). Successfully built (xenial/address-book-service, xenial/history-service, xenial/indicator-application, xenial/indicator-bluetooth, xeni
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Preparing packages
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Preparing packages
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Successfully built
-queuebot:#ubuntu-ci-eng- mardy dbarth, https://bileto.ubuntu.com/#/ticket/2200 Release pocket
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2194 Preparing packages
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2226 Needs rebuild due to new commits (zesty/ubuntu-download-manager). Successfully built (vivid/ubuntu-download-manager, xenial/ubuntu-download-manager)
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Needs rebuild due to new commits (zesty/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-api, vivid/unity8, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-api, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Currently building (xenial/address-book-service, xenial/history-service, xenial/indicator-application, xenial/indicator-datetime, xenial/indicator-messages, xenial/indicator-network, xenial/indicator-sound, xenial/media-hub, xenial/ubuntu-app-launch, xenial/ubuntu-system-settings, xenial/ubuntu-system-settings-online-accounts, xenial/ubuntu-themes, zesty/address-book-service, zesty/history-s
-queuebot:#ubuntu-ci-eng- alf__, https://bileto.ubuntu.com/#/ticket/2221 Needs rebuild due to new commits (zesty/repowerd). Successfully built (xenial/repowerd)
-queuebot:#ubuntu-ci-eng- alf__, https://bileto.ubuntu.com/#/ticket/2221 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Currently building (xenial/media-hub, xenial/ubuntu-system-settings, xenial/ubuntu-themes, zesty/ubuntu-system-settings, zesty/ubuntu-themes). Failed to build (xenial/ubuntu-app-launch, xenial/url-dispatcher, zesty/indicator-keyboard, zesty/indicator-network, zesty/indicator-sound, zesty/indicator-transfer, zesty/media-hub, zesty/ubuntu-app-launch). Pending binary packages (zesty/address-boo
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Currently building (xenial/ubuntu-system-settings, zesty/ubuntu-system-settings). Failed to build (xenial/ubuntu-app-launch, xenial/url-dispatcher, zesty/indicator-keyboard, zesty/indicator-network, zesty/indicator-sound, zesty/indicator-transfer, zesty/media-hub, zesty/ubuntu-app-launch). Successfully built (xenial/address-book-service, xenial/history-service, xenial/indicator-application, 
-queuebot:#ubuntu-ci-eng- alf__, https://bileto.ubuntu.com/#/ticket/2221 Successfully built
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Bad merges (zesty/unity8). Failed to build (xenial/qtmir, xenial/qtmir-gles, xenial/unity8, zesty/qtmir, zesty/qtmir-gles). Successfully built (xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-api, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2194 Successfully built
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Failed to build (xenial/ubuntu-app-launch, xenial/url-dispatcher, zesty/indicator-keyboard, zesty/indicator-network, zesty/indicator-sound, zesty/indicator-transfer, zesty/media-hub, zesty/ubuntu-app-launch). Successfully built (xenial/address-book-service, xenial/history-service, xenial/indicator-application, xenial/indicator-bluetooth, xenial/indicator-datetime, xenial/indicator-keyboard, 
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Abandoning ticket
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Preparing packages
-queuebot:#ubuntu-ci-eng- xavigarcia, https://bileto.ubuntu.com/#/ticket/2231 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Successfully built
-queuebot:#ubuntu-ci-eng- xavigarcia, https://bileto.ubuntu.com/#/ticket/2231 xenial/keeper: Failed to add changelog message
-queuebot:#ubuntu-ci-eng- xavigarcia, https://bileto.ubuntu.com/#/ticket/2231 Preparing packages
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Failed to build (xenial/qtmir, xenial/qtmir-gles, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/unity8). Successfully built (xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-api, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Preparing packages
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 zesty/unity8: Failed to merge https://code.launchpad.net/~dandrader/unity8/miral
-queuebot:#ubuntu-ci-eng- xavigarcia, https://bileto.ubuntu.com/#/ticket/2231 Successfully built
-queuebot:#ubuntu-ci-eng- xavigarcia, https://bileto.ubuntu.com/#/ticket/2231 Preparing packages
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2194 Needs rebuild due to new commits (zesty/ubuntu-system-settings). Successfully built (vivid/ubuntu-system-settings, vivid/ubuntu-themes, xenial/ubuntu-system-settings, xenial/ubuntu-themes, zesty/ubuntu-themes)
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Failed to build (xenial/ubuntu-app-launch, xenial/url-dispatcher, zesty/indicator-keyboard, zesty/indicator-network, zesty/indicator-sound, zesty/indicator-transfer, zesty/media-hub, zesty/ubuntu-app-launch). Needs rebuild due to new commits (zesty/ubuntu-system-settings). Successfully built (xenial/address-book-service, xenial/history-service, xenial/indicator-application, xenial/indicator-
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Failed to build (xenial/qtmir, xenial/qtmir-gles, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/unity8). Successfully built (xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-api, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Failed to build (zesty/unity-api). Needs rebuild due to new commits (zesty/unity8). Successfully built (vivid/unity-api, vivid/unity8, xenial/unity-api, xenial/unity8)
-queuebot:#ubuntu-ci-eng- xavigarcia, https://bileto.ubuntu.com/#/ticket/2231 Failed to build (zesty/keeper). Pending binary packages (xenial/keeper)
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Preparing packages
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Preparing packages
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 zesty/unity8: Failed to merge https://code.launchpad.net/~dandrader/unity8/miral
-queuebot:#ubuntu-ci-eng- xavigarcia, https://bileto.ubuntu.com/#/ticket/2231 Failed to build (zesty/keeper). Successfully built (xenial/keeper)
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Preparing packages
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Preparing packages
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Successfully built
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Preparing packages
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Currently building (xenial/unity8). Failed to build (xenial/qtmir, xenial/qtmir-gles, zesty/qtmir, zesty/qtmir-gles). Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-api, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Failed to build (xenial/qtmir, xenial/qtmir-gles, zesty/qtmir, zesty/qtmir-gles). Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-api, xenial/unity8, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Ready to build (xenial/indicator-network, zesty/indicator-network). Successfully built (xenial/ubuntu-settings-components, xenial/unity8, zesty/ubuntu-settings-components, zesty/unity8)
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Successfully built
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Currently building (vivid/telephony-service). Failed to build (xenial/telephony-service, zesty/history-service). Pending binary packages (xenial/history-service, zesty/telephony-service). Successfully built (vivid/dialer-app, vivid/gsettings-ubuntu-touch-schemas, vivid/history-service, vivid/messaging-app, vivid/nuntium, vivid/telepathy-ofono, vivid/telepathy-qt, xenial/
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (xenial/telephony-service, zesty/history-service). Successfully built (vivid/dialer-app, vivid/gsettings-ubuntu-touch-schemas, vivid/history-service, vivid/messaging-app, vivid/nuntium, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/gsettings-ubuntu-touch-schemas, xenial/history-service, xenial/messaging-app,
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Pending binary packages (zesty/unity8). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-api, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/unity-api)
<boiko> trainguards: can someone please trigger a rebuild of history-service/i386/zesty and telephony-service/arm64/xenial on silo 1319?
<robru> boiko: on it
<boiko> robru: great! thanks!
<robru> boiko: you're welcome, done
<alf_> jibel: Hi! I approved the repowerd branch.
<renato__> robru, do you know why the silo 2213 fail on autopackage?  It was built fine but the autpackage is complaining about a missing "qtdeclarative5-qtsensors-plugin" on zesty
<renato__> https://bileto.ubuntu.com/#/ticket/2213
<renato__> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-2213-excuses/2016-11-24_17:35:02/2213_zesty_excuses.html
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (xenial/telephony-service). Pending binary packages (zesty/history-service). Successfully built (vivid/dialer-app, vivid/gsettings-ubuntu-touch-schemas, vivid/history-service, vivid/messaging-app, vivid/nuntium, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/gsettings-ubuntu-touch-schemas, xenial/history-serv
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Successfully built
<robru> renato__: looking
<robru> renato__: huh that is really weird
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Abandoning ticket
<robru> renato__: http://packages.ubuntu.com/search?keywords=qtdeclarative5-qtsensors-plugin doesn't exist in zesty as far as I can see, not sure how that managed to build...
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (xenial/telephony-service). Successfully built (vivid/dialer-app, vivid/gsettings-ubuntu-touch-schemas, vivid/history-service, vivid/messaging-app, vivid/nuntium, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/gsettings-ubuntu-touch-schemas, xenial/history-service, xenial/messaging-app, xenial/nuntium, xenial
<robru> renato__: so it built because you listed it only as a runtime dependency, not as a build dependency. britney is just correctly identifying that that package doesn't exist in zesty. I guess you should double-check the name, perhaps it was renamed between xenial and zesty
<renato__> robru, ok thanks, I will check that
<renato__> robru, is there any way to say that package is required only for a specif version of ubuntu?
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2208 Successfully built
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Preparing packages
<robru> renato__: well not directly. You would need to use bileto_pre_release_hook to pre process the file to only include it in certain releases
<robru> renato__: does it not exist under a new name in zesty? If so you'd just do "new_name | old_name" and it'll grab whatever's available for the series
<renato__> found it as: qml-module-qtsensors
<robru> renato__: yeah so just use pipe then
<renato__> robru, thanks
<robru> renato__: you're welcome
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Preparing packages
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 zesty/indicator-network: Failed to branch https://code.launchpad.net/~pete-woods/indicator-network/ethernet-support
<boiko> robru: would you mind to also trigger a rebuild of telephony-service/s390x/xenial on silo 1319?
<robru> boiko: done
<boiko> robru: thanks
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Pending binary packages (vivid/camera-app, xenial/camera-app). Successfully built (vivid/address-book-app, vivid/address-book-service, vivid/dialer-app, vivid/gallery-app, vivid/history-service, vivid/mediaplayer-app, vivid/messaging-app, xenial/address-book-app, xenial/address-book-service, xenial/dialer-app, xenial/gallery-app, xenial/history-service, xenial/mediaplayer-app, xenial/messagi
<robru> boiko: you're welcome
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Preparing packages
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2213 Successfully built
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Successfully built
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Failed to build (zesty/indicator-network). Pending binary packages (xenial/indicator-network). Successfully built (xenial/ubuntu-settings-components, xenial/unity8, zesty/ubuntu-settings-components, zesty/unity8)
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Failed to build (zesty/indicator-network). Successfully built (xenial/indicator-network, xenial/ubuntu-settings-components, xenial/unity8, zesty/ubuntu-settings-components, zesty/unity8)
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Preparing packages
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Pending binary packages (vivid/unity8, xenial/unity8, zesty/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-api, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-api, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Successfully built
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2232 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2232 Successfully built
#ubuntu-ci-eng 2016-11-25
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2232 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2232 Generating diffs
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2232 Preparing packages
-queuebot:#ubuntu-ci-eng- michi, jamesh, duflu, https://bileto.ubuntu.com/#/ticket/2230 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2232 Pending binary packages (zesty/unity-control-center). Successfully built (zesty/indicator-printers)
-queuebot:#ubuntu-ci-eng- michi, jamesh, duflu, https://bileto.ubuntu.com/#/ticket/2230 Pending binary packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2232 Publishing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2232 Publish failed: Bad merges (zesty/indicator-printers). Pending binary packages (zesty/unity-control-center)
-queuebot:#ubuntu-ci-eng- michi, jamesh, duflu, https://bileto.ubuntu.com/#/ticket/2230 Successfully built
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2232 Successfully built
-queuebot:#ubuntu-ci-eng- jamesh, https://bileto.ubuntu.com/#/ticket/2219 Needs rebuild due to new commits (zesty/storage-provider-webdav). Successfully built (xenial/storage-provider-webdav)
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Preparing packages
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 zesty/unity8: Failed to merge https://code.launchpad.net/~dandrader/unity8/refactorWindowResizeArea
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Generating diffs
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Successfully built
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Preparing packages
<Saviq> sil2100, hey, think we should copy the wallpapers to overlay, too? feels weird that rc has it but rc-proposed not
<Saviq> then again, we'd potentially replace people's desktop wallpapers on unity7...
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Failed to build (zesty/indicator-network). Successfully built (xenial/indicator-network, xenial/ubuntu-settings-components, xenial/unity8, zesty/ubuntu-settings-components, zesty/unity8)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Preparing packages
<sil2100> Saviq: ah!
<sil2100> Yeah, sorry, let me do that
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Currently building (vivid/unity8, xenial/unity8, zesty/unity8). Failed to build (zesty/unity-api). Successfully built (vivid/unity-api, xenial/unity-api)
<Saviq> sil2100, no worries, thanks
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Failed to build (zesty/unity-api). Pending binary packages (vivid/unity8). Successfully built (vivid/unity-api, xenial/unity-api, xenial/unity8, zesty/unity8)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Failed to build (zesty/unity-api). Successfully built (vivid/unity-api, vivid/unity8, xenial/unity-api, xenial/unity8, zesty/unity8)
<alf_> jibel: H! Is there anything else blocking https://trello.com/c/qGML6MxM/3826-2221-2221-1-repowerd-alf (I have reviewd and approved the MP).
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Preparing packages
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Failed to build (zesty/indicator-network). Needs rebuild due to new commits (zesty/libqtdbusmock, zesty/unity8). Pending binary packages (xenial/libqtdbusmock, xenial/ubuntu-settings-components). Successfully built (xenial/indicator-network, xenial/unity8, zesty/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- michi, jamesh, duflu, https://bileto.ubuntu.com/#/ticket/2230 QA Signoff: Approved
<michi> \o/
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Failed to build (zesty/indicator-network). Needs rebuild due to new commits (zesty/libqtdbusmock, zesty/unity8). Successfully built (xenial/indicator-network, xenial/libqtdbusmock, xenial/ubuntu-settings-components, xenial/unity8, zesty/ubuntu-settings-components)
-queuebot:#ubuntu-ci-eng- michi, jamesh, duflu, https://bileto.ubuntu.com/#/ticket/2230 Publishing packages
 * michi is ecstatic...
-queuebot:#ubuntu-ci-eng- michi, jamesh, duflu, https://bileto.ubuntu.com/#/ticket/2230 Publish failed: Packaging diff requires ACK
<michi> AARGHâ¦
<alf_> ubuntu-qa: Hi! Is there anything else blocking https://trello.com/c/qGML6MxM/3826-2221-2221-1-repowerd-alf (I have reviewed and approved the MP)?
<davmor2> alf_: probably just that let me have a check for you
<rvr> alf_: Nope
<rvr> alf_: I am unblocking it
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Failed to build (zesty/unity-api). Needs rebuild due to new commits (zesty/unity8). Successfully built (vivid/unity-api, vivid/unity8, xenial/unity-api, xenial/unity8)
<alf_> davmor2: rvr: thanks!
<pete-woods> trainguards: hi guys. could anyone publish (https://bileto.ubuntu.com/#/ticket/2230) ?
<pete-woods> it's kinda critical, as it will fix FTBFS for a load of downstream packages
<pete-woods> (it has a packaging ack on X it seems, because there was a recent Z-only publish)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Preparing packages
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Preparing packages
-queuebot:#ubuntu-ci-eng- michi, jamesh, duflu, https://bileto.ubuntu.com/#/ticket/2230 Successfully built
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Currently building (vivid/unity8, xenial/unity8, zesty/unity8). Failed to build (zesty/unity-api). Successfully built (vivid/unity-api, xenial/unity-api)
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Currently building (xenial/unity8, zesty/unity8). Failed to build (zesty/indicator-network, zesty/libqtdbusmock). Successfully built (xenial/indicator-network, xenial/ubuntu-settings-components, zesty/ubuntu-settings-components). Uploading build (xenial/libqtdbusmock)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Failed to build (zesty/unity-api). Successfully built (vivid/unity-api, xenial/unity-api, zesty/unity8). Uploading build (vivid/unity8, xenial/unity8)
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-api, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-api, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-settings-components, zesty/unity-api). Uploading b
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Currently building (xenial/unity8). Failed to build (zesty/indicator-network, zesty/libqtdbusmock). Pending binary packages (xenial/libqtdbusmock). Successfully built (xenial/indicator-network, xenial/ubuntu-settings-components, zesty/ubuntu-settings-components). Uploading build (zesty/unity8)
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Failed to build (zesty/unity-api). Pending binary packages (vivid/unity8, xenial/unity8, zesty/unity8). Successfully built (vivid/unity-api, xenial/unity-api)
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Pending binary packages (vivid/unity8, xenial/unity8, zesty/unity8). Successfully built (vivid/qtmir, vivid/qtmir-gles, vivid/qtubuntu, vivid/qtubuntu-gles, vivid/ubuntu-settings-components, vivid/unity-api, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-settings-components, xenial/unity-api, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-
<sil2100> pete-woods: on it
<pete-woods> sil2100: thanks!
<sil2100> pete-woods: looks good, publishing
<pete-woods> sil2100: awesome, that's much appreciated!
-queuebot:#ubuntu-ci-eng- michi, jamesh, duflu, https://bileto.ubuntu.com/#/ticket/2230 Publishing packages
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Failed to build (zesty/indicator-network, zesty/libqtdbusmock). Successfully built (xenial/indicator-network, xenial/libqtdbusmock, xenial/ubuntu-settings-components, xenial/unity8, zesty/ubuntu-settings-components, zesty/unity8)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2150 Failed to build (zesty/unity-api). Needs rebuild due to new commits (zesty/unity8). Successfully built (vivid/unity-api, vivid/unity8, xenial/unity-api, xenial/unity8)
-queuebot:#ubuntu-ci-eng- Cimi Saviq, https://bileto.ubuntu.com/#/ticket/2202 Successfully built
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Successfully built
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Failed to build (zesty/libqtdbusmock). Needs rebuild due to new commits (zesty/indicator-network). Successfully built (xenial/indicator-network, xenial/libqtdbusmock, xenial/ubuntu-settings-components, xenial/unity8, zesty/ubuntu-settings-components, zesty/unity8)
-queuebot:#ubuntu-ci-eng- michi, jamesh, duflu, https://bileto.ubuntu.com/#/ticket/2230 Proposed pocket (zesty/cmake-extras). Release pocket (xenial/cmake-extras)
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Preparing packages
-queuebot:#ubuntu-ci-eng- michi, jamesh, duflu, https://bileto.ubuntu.com/#/ticket/2230 Release pocket
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Failed to build (xenial/indicator-network, zesty/indicator-network). Successfully built (xenial/libqtdbusmock, xenial/ubuntu-settings-components, xenial/unity8, zesty/libqtdbusmock, zesty/ubuntu-settings-components, zesty/unity8)
<Saviq> sil2100, can you please recycle the two failures here for us https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-2202-excuses/2016-11-25_16:45:01/2202_xenial_excuses.html thanks!
<sil2100> Saviq: sure
<sil2100> Saviq: done
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Currently building (vivid/telephony-service). Failed to build (xenial/telephony-service). Needs rebuild due to new commits (zesty/telephony-service). Successfully built (vivid/dialer-app, vivid/gsettings-ubuntu-touch-schemas, vivid/history-service, vivid/messaging-app, vivid/nuntium, vivid/telepathy-ofono, vivid/telepathy-qt, xenial/dialer-app, xenial/gsettings-ubuntu-to
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (xenial/telephony-service). Needs rebuild due to new commits (zesty/telephony-service). Successfully built (vivid/dialer-app, vivid/gsettings-ubuntu-touch-schemas, vivid/history-service, vivid/messaging-app, vivid/nuntium, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/gsettings-ubuntu-touch-schemas, xenial/h
<boiko> trainguards: can someone please trigger a rebuild of telephony-service/i386/xenial on silo 1319?
<robru> boiko: on it
<boiko> robru: thanks
<robru> boiko: you're welcome
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Needs rebuild due to new commits (zesty/telephony-service). Successfully built (vivid/dialer-app, vivid/gsettings-ubuntu-touch-schemas, vivid/history-service, vivid/messaging-app, vivid/nuntium, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/gsettings-ubuntu-touch-schemas, xenial/history-service, xenial/messaging-app, xenial
-queuebot:#ubuntu-ci-eng- greyback, https://bileto.ubuntu.com/#/ticket/2160 Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/unity-api, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh boiko rmescandon bfiller, https://bileto.ubuntu.com/#/ticket/1319 Failed to build (xenial/telephony-service). Successfully built (vivid/dialer-app, vivid/gsettings-ubuntu-touch-schemas, vivid/history-service, vivid/messaging-app, vivid/nuntium, vivid/telepathy-ofono, vivid/telepathy-qt, vivid/telephony-service, xenial/dialer-app, xenial/gsettings-ubuntu-touch-schemas, xenial/history-service, xenial/messaging-app, xenial/nuntium, xenial
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Preparing packages
-queuebot:#ubuntu-ci-eng- jamesh, https://bileto.ubuntu.com/#/ticket/2219 Preparing packages
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Preparing packages
-queuebot:#ubuntu-ci-eng- jamesh, https://bileto.ubuntu.com/#/ticket/2219 Dependency wait (zesty/storage-provider-webdav). Successfully built (xenial/storage-provider-webdav)
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2224 Failed to build (zesty/indicator-network). Successfully built (xenial/indicator-network, xenial/libqtdbusmock, xenial/ubuntu-settings-components, xenial/unity8, zesty/libqtdbusmock, zesty/ubuntu-settings-components, zesty/unity8)
#ubuntu-ci-eng 2017-11-20
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3041 Diff missing
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3046 Generating diffs
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3046 Pending binary packages
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3046 Publish failed: Pending binary packages
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3046 Publishing packages
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3046 Proposed pocket
-queuebot:#ubuntu-ci-eng- jamespage coreycb, https://bileto.ubuntu.com/#/ticket/3033 Needs rebuild due to higher version at destination (bionic/python-jsonschema, bionic/python-os-service-types, bionic/python-zunclient). Proposed pocket (bionic/python-daiquiri, bionic/python-os-testr, bionic/python-stestr). Release pocket (bionic/barbican, bionic/cinder, bionic/congress, bionic/designate, bionic/designate-dashboard, bionic/heat, bionic/horizon, bionic/keystone, bionic/
#ubuntu-ci-eng 2017-11-21
-queuebot:#ubuntu-ci-eng- cpaelzerppc, https://bileto.ubuntu.com/#/ticket/3047 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- cpaelzerppc, https://bileto.ubuntu.com/#/ticket/3047 Proposed pocket
-queuebot:#ubuntu-ci-eng- jamespage coreycb, https://bileto.ubuntu.com/#/ticket/3033 Needs rebuild due to higher version at destination (bionic/python-jsonschema, bionic/python-os-service-types, bionic/python-zunclient). Proposed pocket (bionic/python-daiquiri, bionic/python-os-testr). Release pocket (bionic/barbican, bionic/cinder, bionic/congress, bionic/designate, bionic/designate-dashboard, bionic/heat, bionic/horizon, bionic/keystone, bionic/mistral, bionic/murano
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3048 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3040 Proposed pocket (bionic/sysstat, bionic/tgt). Release pocket (bionic/exim4). Successfully built (bionic/amavisd-new, bionic/open-iscsi)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3048 Ready to build
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3040 Needs rebuild due to burned version number (bionic/open-iscsi). Proposed pocket (bionic/amavisd-new, bionic/sysstat, bionic/tgt). Release pocket (bionic/exim4)
-queuebot:#ubuntu-ci-eng- cpaelzerppc, https://bileto.ubuntu.com/#/ticket/3047 Release pocket
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3049 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3040 Needs rebuild due to burned version number (bionic/open-iscsi). Proposed pocket (bionic/tgt). Release pocket (bionic/amavisd-new, bionic/exim4, bionic/sysstat)
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3049 Generating diffs
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3049 Pending binary packages
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3049 Successfully built
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3049 Publishing packages
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3049 Proposed pocket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3040 Needs rebuild due to burned version number (bionic/open-iscsi). Release pocket (bionic/amavisd-new, bionic/exim4, bionic/sysstat, bionic/tgt)
-queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2670 Needs rebuild due to higher version at destination (xenial/ubuntu-system-settings). Successfully built (zesty/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2393 zesty/aethercast: Failed to fetch lp:aethercast
-queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2670 Needs rebuild due to higher version at destination (xenial/ubuntu-system-settings). Needs rebuild due to new commits (zesty/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2393 Failed to build (xenial/aethercast). Needs rebuild due to new commits (zesty/aethercast)
-queuebot:#ubuntu-ci-eng- jamespage coreycb, https://bileto.ubuntu.com/#/ticket/3033 Needs rebuild due to higher version at destination (bionic/python-jsonschema, bionic/python-os-service-types, bionic/python-zunclient). Proposed pocket (bionic/python-os-testr). Release pocket (bionic/barbican, bionic/cinder, bionic/congress, bionic/designate, bionic/designate-dashboard, bionic/heat, bionic/horizon, bionic/keystone, bionic/mistral, bionic/murano, bionic/murano-dashboar
#ubuntu-ci-eng 2017-11-22
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3027 Ready to build (yakkety/libvirt). Updates pocket (xenial/libvirt, zesty/libvirt)
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3030 Proposed pocket (bionic/qtsystems-opensource-src). Release pocket (bionic/qtwebengine-opensource-src)
-queuebot:#ubuntu-ci-eng- jamespage coreycb, https://bileto.ubuntu.com/#/ticket/3033 Needs rebuild due to higher version at destination (bionic/designate, bionic/mistral, bionic/python-jsonschema, bionic/python-os-service-types, bionic/python-zunclient). Proposed pocket (bionic/python-os-testr). Release pocket (bionic/barbican, bionic/cinder, bionic/congress, bionic/designate-dashboard, bionic/heat, bionic/horizon, bionic/keystone, bionic/murano, bionic/murano-dashboar
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3011 Needs rebuild due to burned version number
-queuebot:#ubuntu-ci-eng- jamespage coreycb, https://bileto.ubuntu.com/#/ticket/3033 Needs rebuild due to higher version at destination (bionic/barbican, bionic/designate, bionic/mistral, bionic/python-jsonschema, bionic/python-os-service-types, bionic/python-zunclient). Proposed pocket (bionic/python-os-testr). Release pocket (bionic/cinder, bionic/congress, bionic/designate-dashboard, bionic/heat, bionic/horizon, bionic/keystone, bionic/murano, bionic/murano-dashboar
#ubuntu-ci-eng 2017-11-23
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3050 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3050 Ready to build
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3050 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3050 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3051 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3051 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3051 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3051 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3050 Proposed pocket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3052 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3052 Diff missing
#ubuntu-ci-eng 2017-11-24
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3052 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3052 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3042 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3042 Diff missing
#ubuntu-ci-eng 2017-11-26
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3052 Needs rebuild due to higher version at destination
