[00:29] <robru> ogra_, rsalveti: time to kick an image build I think? cyphermox and I just landed the big mir transition. looking good on our end
[00:30] <rsalveti> robru: cool, let me check if everything is already in
[00:30] <robru> rsalveti, oh, and if you can ensure that python2.7 2.7.6-2ubuntu1 gets in, that would be super ;-)
[00:31] <rsalveti> sure
[00:32] <rsalveti> hm, python is still in proposed
[00:33] <robru> rsalveti, yeah, just noticed that. it's absolutely critical for running AP tests though
[00:33] <rsalveti> Invalidated by dependency
[00:33] <rsalveti> Not considered
[00:33] <rsalveti> Depends: python2.7 libffi (not considered)
[00:34] <rsalveti> autopkgtest for git-annex 5.20131127.1: FAIL (Jenkins: public, private)
[00:34] <rsalveti> for libffi
[00:34] <robru> rsalveti, i'm not familiar with libffi
[00:35] <rsalveti> sync from debian, upload by doko
[02:03] <Saviq> cihelp, ps-nvidia-gt630 fails otto again http://s-jenkins.ubuntu-ci:8080/computer/ps-nvidia-gt630/builds :/
[02:03] <Saviq> again the "could not start container" issue
[04:06] <rsalveti> [04:06] <rsalveti> should have latest mir/unity8/python2.7/etc
[05:13]  * Mirv upgrades
[07:33] <vila> Saviq: yeah, "again". Root cause https://bugs.launchpad.net/otto/+bug/1253198 , workaround https://code.launchpad.net/~vila/otto/stop-running-container/+merge/196594 waiting approval to be landed and deployed
[07:34] <vila> Saviq: the container has been stopped manually in the mean time
[07:42] <jibel> vila, where is the code that install debs? I cannot find it in otto trunk
[07:42] <jibel> is it a custom branch of otto?
[07:45] <vila> jibel: I don't know of any otto custom branch, there are some uncommitted changes on most of the otto nodes but mainly for setting memory sizes
[07:49] <jibel> vila, it's in usr/local/bin/run-autopilot.sh, so not otto
[07:50] <jibel> in the script that calls autopilot
[07:50] <jibel> vila, I don't know where is comes from do you?
[07:52] <vila> jibel: first line of defense is to stop the otto container to unblock other jobs, that's the priority
[07:52] <jibel> vila, that script is broken
[07:52] <jibel> vila, there is a shebang with sh -eu
[07:52] <jibel> vila, but then it call apt with sh  -c
[07:52] <ogra_> hmm, these crashers in the ubnity8 tests on mako dont look good
[07:52] <didrocks> ogra_: yep :/
[07:53] <didrocks> ogra_: new mir, new crashers :p
[07:53] <ogra_> hud wouldnt worry me as much, but NM
[07:53] <didrocks> ogra_: well, better to figure it out first
[07:54] <ogra_> right
[07:54] <vila> jibel: where do you see this script ? It's not on the otto node
[07:54]  * ogra_ has a plumber in the house in 5min ... 
[07:54] <ogra_> not sure i'll make it in time for the call ... but i'll try my best
[07:55] <didrocks> ogra_: no worry
[07:55] <didrocks> ogra_: "swim" well ;)
[07:55] <ogra_> heh that was two weeks ago ...
[07:55] <jibel> vila, /var/lib/lxc/trusty-amd64-20131023-0529/run/delta/usr/local/bin/run-autopilot.sh
[07:55] <ogra_> i plastered a patch on the pipe ... thats what he has to fix properly today
[07:55] <jibel> on ps-radeon-8350
[07:56] <didrocks> ogra_: you used DEP3 headers I hope? ;)
[07:56] <didrocks> ogra_: joke apart, I hope it won't cost you too much
[07:56] <ogra_> lol, nope, a tar patch
[07:56] <didrocks> inline patch! how ugly :p
[07:56] <ogra_> haha
[07:57] <ogra_> i dont care about the costs ... the pipes are 50 years old ... they all need replacement all across the 200m² over 3 floors
[07:57] <vila> jibel: can you review https://code.launchpad.net/~vila/otto/stop-running-container/+merge/196594 ?
[07:57] <ogra_> but i prefer that to happen in summer
[07:58] <ogra_> my house has 4 bathrooms ... lots of pipes :(
[07:58] <vila> jibel: and add https://launchpad.net/~canonical-ci-engineering to https://launchpad.net/~otto-dev ?
[07:58] <didrocks> ogra_: yeah, summer will be better to shutdown the whole water system…
[07:59] <vila> jibel: making that team admin would be more in line with responsibilities too
[08:07] <jibel> vila, when do you want to run this script?
[08:08] <vila> jibel: This script is used as a post-build task in jenkins to catch containers left running. as mentioned in the MP
[08:09] <vila> jibel: and how to do that is described in the script itself
[08:10] <jibel> vila, but if you abort a job it won't be called, isn't it?
[08:10] <vila> jibel: and it has been tested on q-jenkins
[08:10] <vila> jibel: it is called even if the job is aborted
[08:11] <vila> jibel: it's explained in the script: This script is used as 'Post-build action' and as such is invoked after a
[08:11] <vila> 16	+# job is finished, including aborted.
[08:13] <jibel> vila, its annoying that it kills everything, can you restrict to the container that have been started by the test?
[08:14] <jibel> vila, as fginther suggested once, write a flag in the main job for example or limit to the containers following the naming convention used by the tests
[08:17] <jibel> didrocks, or anyone, I'd need https://code.launchpad.net/~pitti/autopilot-gtk/fix-1254996/+merge/196703 in the distro, what's the procedure?
[08:17] <jibel> it is blocking installer tests
[08:18] <didrocks> jibel: just adding to the landing ask, I'm handling it
[08:18] <vila> jibel: further refinements can be done later (as explained in the MP)
[08:19] <vila> jibel: for now, I want to unblock Saviq and other users that face https://bugs.launchpad.net/otto/+bug/1253198
[08:19] <jibel> vila, it is not a refinement, it kills all running container without distinction
[08:20] <vila> jibel: It is indeed not a refinement, it is a workaround as explained in the MP and the script, refinements can come *later*
[08:20] <jibel> vila, for Saviq 's problem, fix the script run-autopilot.sh
[08:20] <jibel> used by medium tests
[08:20] <jibel> this script is like saying "I've a bug on my machine, I don't know what it is, let press the power button"
[08:21] <vila> jibel: exactly
[08:21] <vila> jibel: and that's what I want
[08:21] <jibel> so you'd better fix the runner instead
[08:21] <vila> jibel: no, that workaround is a catch-up so the ci engine keeps running, other bugs will be fixed later
[08:21] <vila> catch-all
[08:23] <vila> jibel: can I have that MP approved or https://launchpad.net/~canonical-ci-engineering added to https://launchpad.net/~otto-dev or should I just deployed my branch  on the otto nodes ?
[08:24] <jibel> vila, I disagree with the approach of killing all running container, please restrict to the containers used by the tests.
[08:25] <vila> jibel: fine, I'll deploy my branch then
[08:26] <vila> jibel: we can continue the discussion later
[08:34] <Saviq> vila, oh cool, nice that the problem is tracked down
[08:36] <jibel> vila, commented on the MP
[08:41] <vila> Saviq: note that the root cause (wrong deps) won't be fixed by ci, someone has to look at them
[08:41] <Saviq> vila, of course
[08:43] <Saviq> vila, another one I've noticed from time to time bug #1256227
[09:28]  * ogra_ will be late to the meeting but i will come ...
[09:29] <didrocks> ogra_: no worry!
[09:49] <sil2100> didrocks: can you ACK the packaging diff? Sortage mostly, as other changes were made by core devs ;p http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/QA/job/cu2d-qa-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_autopilot-gtk_1.4+14.04.20131128.1-0ubuntu1.diff
[09:50] <Saviq> ev, hey, it seems makos are in a bad state this morning :/ https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/
[09:50] <Saviq> bug #1256227
[09:50] <ogra_> Saviq, there are a ton of network manager crashes in the latest image smoketests too
[09:51] <ogra_> (no idea if that could be related)
[09:51] <Saviq> ogra_, yeah, no idea either, don't get it what it complains about
[09:52] <didrocks> sil2100: +1
[09:52] <ogra_> popey, did you already try r37 on mako ?
[09:52] <popey> am testing now ogra_
[09:53] <ogra_> the lockscreen issue on maguro is fixed
[09:53] <popey> never saw that on mako
[09:53] <ogra_> yeah, that was driver specific
[09:55] <ogra_> didrocks, oh, btw, i would like to switch on cron after tonights meeting, would be good if everyone could think about the best times for the cron entry
[09:55] <ogra_> ^^^^ rest of team too ^^^^
[09:55] <didrocks> ogra_: hum, I would vary doing that while asac is sick/not around
[09:55] <didrocks> as he's the one disagreeing
[09:55] <ogra_> i would like to have some feedback data before he returns
[09:55] <didrocks> but otherwise, yeah, we need to check with psivaa and plars in particular so that it matches their schedule
[09:56] <ogra_> we can still switch it off if he objects
[09:56] <didrocks> so that basically most of the tests are ran when they arrive
[09:56] <didrocks> they can work on correcting/relaunching
[09:56] <didrocks> (so have some slack time)
[09:56] <didrocks> and then, we rekick the next one
[09:56] <ogra_> right, well, the tests have 8h to run
[09:56] <didrocks> psivaa: what would work for you? ^
[09:57] <ogra_> so i can set the schedule in a way that one image is just ready when they get up
[09:57] <didrocks> ogra_: I would say, when psivaa starts his day, it would be better that the tests are already running for 3 hours
[09:57] <ogra_> or has run a chunk of automated tests already
[09:57] <ev> Saviq: okay, adding to the queue. Thank you!
[09:57] <didrocks> yeah, exactly
[09:57] <ogra_> yeah
[09:57] <popey> http://popey.com/~alan/phablet/device-2013-11-29-095719.png  anyone ever see that? where a key gets wedged on?
[09:57] <popey> note it wasn't the last key I pressed, it stayed wedged even when pressing other keys
[09:58] <psivaa> didrocks: ogra_ i would like to have all the tests completed when i come in so that i could relaunch if there is any test that needs it
[09:58] <didrocks> psivaa: when are you starting UTC-wise?
[09:58] <ogra_> psivaa, when do you usually start
[09:58] <ogra_> heh, snap
[09:58] <didrocks> :p
[09:58] <psivaa> ogra_: didrocks: it's UTC 9:00
[09:59] <didrocks> so half an hour before the meeting
[09:59] <psivaa> right
[09:59] <ogra_> so i should put the build say 4h before that ? does that suffice ?
[09:59] <didrocks> this makes it 6 to start running the tests
[09:59] <didrocks> so 5 to build the image?
[09:59] <didrocks> 5 + 8 = 1PM UTC
[09:59] <psivaa> ogra_: that sounds good
[10:00] <didrocks> so tests done by 5 UTC
[10:00] <didrocks> which is the other meeting time
[10:00] <didrocks> hum
[10:00] <didrocks> better to get that done one hour before the other meeting
[10:00] <didrocks> so 4
[10:00] <didrocks> we still have 3 hours for psivaa to fix things up in the morning
[10:00] <ogra_> ok, i'll schedule one build at 5am ... lets wait for plars input if such a schedule works for him too ...
[10:01] <didrocks> ogra_: 4 would work better for the afternoon meeting
[10:01] <ogra_> we dont need to be strict on 8h or wanything
[10:01] <didrocks> 4 -> 12 + 1 hour building + 3 hours of tests == 4 PM
[10:01] <didrocks> (so one hour before the evening meeting)
[10:02] <ogra_> that wont give plars much wiggle room
[10:03] <ogra_> i would start the second build ~ 2h earlier 13:00 UTC or so
[10:03] <ev> heads up: Jenkins on s-jenkins just crashed on us
[10:04] <popey> ogra_: 37 is good here
[10:04] <ogra_> but lets wait for his input
[10:04] <ogra_> popey, no OSK for me
[10:04] <didrocks> sil2100: once https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/disable-autopilot-tests/+merge/197152 is merged, can you add  ubuntu-system-settings-online-accounts to your bucket?
[10:04] <popey> fine here
[10:04] <ogra_> popey, yeah, because you use a werid language/locale setting :P
[10:05] <sil2100> didrocks: sure! Keeping that on the radar ;)
[10:05] <popey> ogra_: CONFORM!
[10:05] <psivaa> ogra_: didrocks: unity8 tests on both devices came good with 37. in transit to the dashboard
[10:06] <didrocks> psivaa: great!
[10:07] <ogra_> didrocks, so still no OSK on maguro (no surprise since nothing changed there)
[10:08] <ogra_> waking up the screen needs sometimes two power button presses ... but at least no tapping on screen anymore
[10:08] <ogra_> (still not 100% fixed though)
[10:08] <didrocks> ogra_: ah, interesting, mind pinging greyback?
[10:08] <ogra_> about kbd or screen ?
[10:09] <greyback> no OSK on maguro! First I've heard of it.
[10:09] <ogra_> greyback, on non english locale
[10:11] <ogra_> greyback, bug 1255999
[10:11] <greyback> ogra_: ok thanks. I'll poke tmoenicke too
[10:11] <ogra_> he should be able to test a german setting i guess :)
[10:14] <sil2100> Mirv: https://code.launchpad.net/~sil2100/cupstream2distro-config/extra_for_qa/+merge/197157 could you take a lookie?
[10:14] <ogra_> psivaa, there was a saucy 102 build and i dont see any tests for it ... would be good to have some results within the next week (no hurry)
[10:15] <psivaa> ogra_: ack, will add to the list
[10:15] <Mirv> sil2100: looks good
[10:15] <sil2100> Mirv: thank you!
[10:18] <Mirv> sil2100: one for you too https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/libavutil52/+merge/197159
[10:20] <didrocks> ogra_: sorry, was chatting on something else, so no, on the power button
[10:20] <didrocks> greyback:  ^
[10:20] <ogra_> didrocks, yeah, all sorted
[10:20] <ogra_> (see above)
[10:20] <sil2100> Mirv: oh, ok, not sure why but I'm somehow amused by this change ;p +1
[10:22] <Mirv> sil2100: Friday? ;) I added another commit though, it seems it's installing both at the moment since I already did a really quick test run
[10:22] <sil2100> Mirv: ok, then I re-approve that
[10:23] <sil2100> Mirv: probably ;p
[10:23] <Mirv> thanks!
[10:24] <Mirv> libav9 migration just completed today/yesterday, which was nice to notice
[10:30] <popey> bug 1256265
[10:34] <didrocks> psivaa: so, can you flash latest image
[10:35] <didrocks> (locally)
[10:35] <didrocks> try to get previous glib version
[10:35] <didrocks> and see?
[10:35] <didrocks> (if the crashes still happens)
[10:35] <psivaa> didrocks: ok, i have a maguro and the crashes (network manager) is only happening on mako
[10:35] <didrocks> psivaa: argh, ok
[10:37] <psivaa> didrocks: network-manager somehow depends on libffi6 which is an upgraded package in 37
[10:38] <didrocks> psivaa: do you have access to device in the lab where you can test backing it out? (I'm testing locally)
[10:38] <didrocks> that + retracing will really help I guess
[10:38] <psivaa> didrocks: yes, doing that. i have access to the device
[10:38] <didrocks> great, will confirm you shortly if I have the crash here (phone booting)
[10:38] <didrocks> with r37
[10:38] <psivaa> ack
[10:50] <didrocks> psivaa: ok, so got the crash, reverting glib -> no crash FYI
[10:51] <psivaa> didrocks: ahh ok, thanks. i'll confirm
[10:51] <didrocks> psivaa: hands over a stacktrace once retraced
[10:51] <asac> seb128: ^^
[10:51] <seb128> asac, hey
[10:52] <asac> will you backout given that glib has caused issues on touch and other parts?
[10:52] <asac> :)
[10:52] <seb128> asac, ssssssure
[10:52] <asac> or do you have a lead
[10:52] <asac> cool
[10:52] <asac> leading by example
[10:52] <asac> hehe
[10:52] <asac> sorry... we need to get our proposed testing story sorted
[10:52] <asac> so we have a better safety net...
[10:53] <psivaa> didrocks: doesn't http://q-jenkins.ubuntu-ci:8080/job/trusty-touch-mako-smoke-ubuntu-rssreader-app-autopilot/39/artifact/clientlogs/_usr_sbin_NetworkManager.0.crash/*view*/ have the required trace information?
[10:53] <seb128> psivaa, it doesn't have debug symbols
[10:54] <didrocks> psivaa: do you know how to retrace a crash file?
[10:54] <psivaa> didrocks: i have not done in the past
[10:55] <didrocks> ah, maybe we should pair someone with you
[10:55] <didrocks> Mirv: mind giving a hand to psivaa? ^
[10:55] <didrocks> I think it's important that he learns about it
[10:55] <didrocks> you have the -dbg files directly btw for glib
[11:21] <Mirv> didrocks: sure, in a bit
[11:21] <Mirv> psivaa: you'll need lp:daisy on host
[11:22] <psivaa> Mirv: ok, i'll get it
[11:25] <vila> Saviq: workaround deployed on s-jenkins, you may still encounter failing jobs but they should not block the following ones anymore
[11:25] <Saviq> vila, thanks
[11:25] <sil2100> didrocks: packaging ACK! http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/Misc./job/cu2d-misc-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_phablet-tools_1.0+14.04.20131129-0ubuntu1.diff ? :)
[11:26] <didrocks> sil2100: +1
[11:29] <sil2100> didrocks: thanks!
[11:29] <sil2100> hm
[11:29] <sil2100> Does anyone know why this is happening? http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/658/label=autopilot-nvidia/console
[11:29] <sil2100> I: No test left to run
[12:36] <psivaa> seb128: didrocks: just an update.. still have not collected the crash debug information.. seeing issues like http://pastebin.ubuntu.com/6493858/
[12:38] <didrocks> psivaa: maybe, you can try retracing it directly on the phone?
[12:38] <psivaa> didrocks: let me try that
[12:38] <didrocks> psivaa: you apport-unpack the .crash file
[12:38] <didrocks> and then follow https://wiki.ubuntu.com/Backtrace on the CoreDump you will get
[12:38] <rsalveti> ogra_: do we have a bug for the weird nm bug you said already?
[12:39] <didrocks> (having the debug symbols
[12:39] <ogra_> rsalveti, not sure
[12:39] <psivaa> didrocks: ack, will try that
[12:39] <ogra_> i didnt file one (and dont have my mako on -proposed)
[12:39] <rsalveti> let me flash the latest
[12:39] <ogra_> rsalveti, the dashboard has a ton of crash files though
[12:39] <rsalveti> oh =\
[12:40] <ogra_> http://ci.ubuntu.com/smokeng/trusty/touch/mako/37:20131129:20131129/5168/
[12:40] <ogra_> all tests with 2 or more crashes are likely to have the NM one
[12:41] <seb128> the nm one is a known issue which is being worked
[12:41] <ogra_> oh, cool
[12:42] <rsalveti> seb128: right, but do we have a bug for it?
[12:42] <seb128> rsalveti, not sure, I've a fix in a ppa and I'm waiting for desrt to get online to validate it
[12:42] <rsalveti> alright
[12:42] <seb128> I confirmed the fix, I just want sanity check that I'm not doing something boggy to gobject
[12:47] <Mirv> didrocks: I think the problem psivaa is seeing, based on the output he's getting, is that it's not a problem/crash that would create coredump
[12:47] <didrocks> Mirv: I doubt there is no coredump, I can see one on the dashboard
[12:48] <Mirv> didrocks: ok. it's what apport is telling him though, and I've had some of those with eg. python crashes. but it might be some different kind of problem.
[12:48] <Mirv> didrocks: the method I gave psivaa I've used successfully with unity8 backtracing at lest
[12:48] <Mirv> least
[12:48] <seb128> that report is working
[12:48] <seb128> I got the dump out this morning to look at it
[12:49] <seb128> that's not rocket science, just use apport tools (e.g unpack and gdb it)...
[12:49] <vila> sil2100: literally, I: No test left to run
[12:49] <vila> means that all tests in the spool dir have run and there is no more to run
[12:49] <Mirv> I'll try retracing too
[12:49] <sil2100> vila: but it results in an error, and the autopilot suite has more than 0 tests
[12:49] <vila> sil2100: this comes from run-autopilot.sh
[12:50] <vila> sil2100: that's not why it results in an error IIUC:
[12:50] <sil2100> I actually ran them on my desktop and there all tests ran
[12:50] <seb128> Mirv, don't bother, no need to be several doing it
[12:50] <vila>     if [ ! "$(ls -A $spooldir/)" ]; then
[12:50] <vila>         echo "I: No test left to run"
[12:50] <vila>         sudo shutdown -h +1
[12:50] <vila>     fi
[12:50] <seb128> Mirv, that's dupping work for no good reason
[12:50] <vila> sil2100: that's the way it always finish the job
[12:51] <Mirv> seb128: well, I'm interested in seeing if I get similar error as psivaa, or not. my computer's CPU and network cycles are free :)
[12:51] <Mirv> (almost, at least)
[12:51] <seb128> Mirv, k, your call
[12:51] <Mirv> psivaa got his .crash file from the device, so I'm checking if we get similar results on that downloadable one
[12:51] <Mirv> seb128: we were asked to pair work on this anyhow..
[12:52] <Mirv> psivaa: yeah, on that jenkins one I got retrace, no problems
[12:53] <vila> sil2100: i.e. there may be another previous error leading to *not* producing a test suite to run but I can't see why from that log
[12:54] <vila> sil2100: /var/local/autopilot/autopilot.log: Loading tests from: /usr/lib/python2.7/dist-packages kind of means autopilot has run and failed for an unknown reason (few lines above that 'No test left ro run' line)
[12:54] <sil2100> hmmm
[12:54] <sil2100> vila: thanks for the analysis!
[12:54] <vila> sil2100: my pleasure, learning with you here
[12:55] <vila> sil2100: in fact, I think autopilot has run indeed, yet a few lines before:
[12:55] <vila> /var/local/autopilot/autopilot.log: I: Running autopilot run autopilot -v -f xml -r -rd /var/local/autopilot//videos/ --record-options=--fps=6,--no-wm-check -o /var/local/autopilot//junit//autopilot.xml
[12:58] <vila> sil2100: so, was that job about running autopilot tests themselves ?
[12:59] <vila> sil2100: i.e. 'autopilot run autopilot' ?
[13:14] <psivaa> ogra_: i'm done with image 37.. please feel free to kick 38 :)
[13:16] <ogra_> doing :)
[13:16] <ogra_> [13:38] <popey> \o/
[13:57] <Saviq> ev, hey, can you tell me how to subscribe to packages for errors.u.c? or where to read about e.u.c for that matter?
[14:00] <seb128> ev, define "subscribe"?
[14:00] <seb128> ups
[14:00] <seb128> Saviq, ^^
[14:00] <seb128> Saviq, like getting emails for issues?
[14:01] <seb128> Saviq, by default it lists packages you are subscribe to in launchpad
[14:01] <Saviq> seb128, how do I do that? on https://launchpad.net/ubuntu/+source/unity8 ?
[14:01] <sil2100> Damn, LP acts strange today..
[14:02] <seb128> Saviq, https://launchpad.net/ubuntu/+source/unity8/+subscribe
[14:02] <seb128> click the "I want to receive these notifications by e-mail."
[14:02] <seb128> Saviq, that doesn't give you emails from e.u.c though, but the default view is to list reports for the packages your user is subscribed to
[14:02] <Saviq> seb128, right, I was team-subscribed to that
[14:03] <seb128> Saviq, well, you can customize your url
[14:03] <seb128> Saviq, e.g https://errors.ubuntu.com/?release=Ubuntu%2013.10&user=unity-team&period=day
[14:03] <Saviq> seb128, right, thanks!
[14:03] <didrocks> ok, exercising time
[14:04] <seb128> yw
[14:04] <seb128> Saviq, https://errors.ubuntu.com/?release=Ubuntu%2013.10&user=saviq&period=day
[14:04] <Saviq> seb128, what does it mean when a row is greyed out?
[14:04] <Saviq> retrace failed?
[14:04] <seb128> Saviq, I think it means it hasn't been seen with the current version of the package
[14:04] <Saviq> ah
[14:04] <Saviq> nice one
[14:04] <seb128> so it might be fixed
[14:04] <seb128> crossed is when the bug is closed
[14:05] <seb128> red is when it's closed but the issue is still reported with the current version
[14:05] <seb128> would be nice to have a legend on the page
[14:05] <seb128> ev tried to make it "obvious enough by itself" but it's still confusing
[14:06] <Saviq> seb128, can it be greyed out if it's crossed, too? like https://errors.ubuntu.com/problem/f27a9186b6a83d502641e0fd89381bcd62095395
[14:06] <Saviq> seb128, it's fixed, not greyed out - but not found in current version
[14:06] <Saviq> probably doesn't make sense to be greyed out if crossed
[14:06] <seb128> right, fixed is just crossed
[14:07] <seb128> it would turn red if it was seen in the current version
[14:07] <Saviq> seb128, aanyway, there anywhere I could read so that I don't bother you? :)
[14:07] <seb128> Saviq, try asking to mpt on #ubuntu-devel if there is a document explaining e.u.c or its design
[14:08] <Saviq> seb128, will do, thanks
[14:08] <seb128> yw
[14:22] <psivaa> seb128: didrocks: Mirv has reported the bug for NetworkManager crash, bug #1256299
[14:22] <seb128> psivaa, Mirv: you can close it, the fix has already been uploaded
[14:23] <psivaa> seb128: i'll wait for the fix to land and work before closing it
[14:23] <seb128> ok, your call
[14:23] <seb128> testing for the fix (that's the new glib just uploaded to trusty-proposed) is welcome
[15:39] <didrocks> psivaa: mind testing it from proposed?
[15:41] <psivaa> didrocks: the tests are running on the device. i was planning to test it once the tests are done
[15:41] <psivaa> i mean the tests with r38
[15:41] <didrocks> psivaa: ok ;)
[15:53] <dobey> transitioning stuff to daily-release is hard
[16:30] <Laney> can I get permissions to re-run autopkgtests?
[16:37] <Laney> (what happened to the matrix reloaded?)
[16:38] <cjohnston> Laney: can you file a bug against ubuntu-ci-services-iteself with your request.. im not sure what may have changed with the move, but that way it can be followed up on when people from the US get back
[16:38] <Laney> cjohnston: ok, in the meantime can you re-run glib2.0 please?
[16:38] <cjohnston> Laney: link please?
[16:38] <Laney> http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/21/
[16:40] <cjohnston> Laney: I'm not familiar.. so I see 'matrix reloaded', on that page I see amd64 which is green and i386 which is red and checked...
[16:40] <cjohnston> what about the downstream builds? do I check that?
[16:41] <Laney> I don't know
[16:41] <Laney> there used to be Matrix Reloaded to make the tests re-run
[16:41] <Laney> don't ask me what it did, but I'm guessing it's a plugin which we don't have any more
[16:41] <Laney> jibel: ^- any clue?
[16:42] <cjohnston> Laney: the plugin still seems to exist (for me atleast)
[16:42] <Laney> oh, you /do/ see it, sorry - misread
[16:42] <cjohnston> Laney: I'm just not sure with the plugin, do  I just leave it at the default for what they set
[16:42] <Laney> so tick both of them and press publish or whatever it is
[16:42] <Laney> that should create a new entry to re-run the tests
[16:42] <cjohnston> "Matrix Reload downstream builds: "
[16:42] <cjohnston> any idea on that tick box?
[16:42] <Laney> can't remember
[16:43] <Laney> ISTR only changing the arches
[16:43] <cjohnston> ok, well its building
[16:44] <Laney> neat, thanks
[16:44] <Laney> I filed https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1256372 for you
[16:45] <cjohnston> ty
[16:45] <cjohnston> I'm not sure if policies changed or what the story is, so I'm not comfortable with making changes :-)
[16:46] <Laney> ok, well I described my ideal
[16:48] <cjohnston> ty
[16:49] <cjohnston> cyphermox: ping
[16:49] <cyphermox> pong
[16:50] <cjohnston> cyphermox: can you walk through updating the q-jenkins stack update stuff with me please?
[16:50] <cyphermox> what do you mean?
[16:50] <cjohnston> https://wiki.ubuntu.com/DailyRelease/FAQ#Adding.2BAC8-removing_components_to_a_stack
[16:51] <cyphermox> ok, what do you want to do?
[16:51] <cjohnston> cyphermox: I'm not really sure what I'm doing, so just make sure I don't kill things?
[16:51] <cyphermox> well, that's what I mean what are you trying to do?
[16:52] <cjohnston> applying https://code.launchpad.net/~dobey/cupstream2distro-config/u1creds-inline-packaging/+merge/197230
[16:53] <cyphermox> ah!
[16:53] <cyphermox> so since it's merged, just make sure you have the very latest revision
[16:54] <cyphermox> then you'll want to cd daily-release;  ./cu2d-update-stack -dUS ../stacks/head/webcred.cfg
[16:54] <cjohnston> cyphermox: do I do this locally or on the remote machine?
[16:54] <cyphermox> that will update the jenkins config in jenkins, and not touch
[16:54] <cyphermox> oh wait
[16:54] <cyphermox> cu2d-update-stack -dU
[16:55] <cyphermox> locally
[16:55] <cyphermox> you should have a .cu2d.cred file on your system that has your credentials for jenkins to be able to update the config remotely
[16:55] <cjohnston> hrm.. ok, I'll create oen
[16:55] <cjohnston> one
[16:55] <cyphermox> hmm
[16:55] <cyphermox> ok just a second
[16:59] <cyphermox> cjohnston: so yeah, all you need to do is get lp:cupstream2distro-config, cd daily-release and then run
[16:59] <cyphermox> ./cu2d-update-stack -dU ../stacks/head/webcred.cfg
[17:00] <cyphermox> note that this often requires you to be in the right teams to be able to update what trunk points to and things like that, so I'm not sure how well it's going to run
[17:00] <cjohnston> ack
[17:00] <cjohnston> its runnin, i guess we shall see
[17:01] <cjohnston> read only transport
[17:01] <cyphermox> right
[17:01] <cyphermox> we also need https://code.launchpad.net/~dobey/ubuntuone-credentials/daily-release/+merge/197222 to get merged though
[17:01] <cyphermox> let me see if I can run it
[17:02] <dobey> cyphermox: no we don't
[17:02] <dobey> cyphermox: the purpose of the previous change was so that this can merge
[17:03] <cyphermox> in that case this is not the same process
[17:03] <dobey> eh? jenkins needs config that doesn't include pulling in the external package branch, to be able to run tests in this branch, because they conflict
[17:03] <cyphermox> cjohnston: then you'll likely want fginther or alesage or some other person to fix up CI rather than daily-release
[17:04] <cjohnston> dunno.. this is what didrocks said was needed
[17:04] <cyphermox> I expect there was a misunderstanding
[17:04] <cyphermox> packaging_branch: may be used in more than one place
[17:05] <cyphermox> the cu2d-update-stack stuff is really mostly going to change q-jenkins for the cu2d jobs, not the merge proposal build stuff
[17:05] <cyphermox> anyway, AFAIK
[17:05] <didrocks> cyphermox: I think cjohnston did the upstream merger part
[17:05] <cyphermox> then the proposal should be able to merge fine
[17:06] <cyphermox> I'm not denying that the second part is necessary, just that it's not what's blocking the merge request
[17:06] <cyphermox> didrocks: do you happen to have magic ubuntuone access to be able to update the packaging branch for ubuntuone-credentials?
[17:06] <dobey> cyphermox: what are you suggesting?
[17:07] <cjohnston> I did deploy-cupstream2distro-config
[17:07] <cyphermox> cjohnston: ok
[17:07] <cyphermox> in this case, the merge should be good to land
[17:07] <didrocks> cyphermox: ah, I don't
[17:07] <cyphermox> then we still need to do cu2d-update-stack for the actual daily build
[17:08] <cyphermox> didrocks: actually
[17:08] <cyphermox> I think I might have the right access, going to try
[17:08] <dobey> cyphermox: what are you "going to try" exactly?
[17:08] <dobey> please don't touch any ubuntuone branches
[17:09] <cyphermox> updating the config
[17:10] <cyphermox> ah, that oneś daily-release false too
[17:10] <cyphermox> It's already good
[17:11] <dobey> yes, the change was just to remove the packaging branch, so ps jenkins would pass the tests again
[17:11] <cyphermox> cjohnston: you should jsut be able to kick the merge proposal to try the build again, but I don't know how you do that
[17:12] <dobey> http://s-jenkins.ubuntu-ci:8080/job/ubuntuone-credentials-ci/69/rebuild
[17:12] <dobey> someone just needs to rebuild it, if the live config is updated now
[17:12] <cjohnston> rebuilding
[17:15] <dobey> looks like it failed again with the same issue.
[17:15] <dobey> so i guess the liv config isn't updated
[17:15] <dobey> live even
[17:20] <cyphermox> cjohnston: you'll need to check the config in http://s-jenkins.ubuntu-ci:8080/job/ubuntuone-credentials-trusty-amd64-manual/14/console to see why it still tries to grab debian, I'm not sure if that's covered by packaging_branch but regardless, it's not a process I know about, it's not cu2d.
[17:21] <cjohnston> bzr branch $packaging_branch debian
[17:22] <dobey> maybe jenkins needs a restart to refresh the config or something?
[17:23] <dobey> not sure how that works
[17:23] <cjohnston> that would be very unfortunate
[17:23] <cjohnston> dobey: hrm
[17:23] <cjohnston> if I just did a rebuild, then that would still have the packaging branch
[17:24] <dobey> did the job config not change?
[17:25] <cjohnston> it has a packaging branch field, but it is blank
[17:26] <cjohnston> but on a rebuild, it takes the config of the build you are rebuilding
[17:26] <cjohnston> so I think it needs a new build
[17:26] <dobey> hmm, maybe. i guess trigger a new build of the job?
[17:26] <cjohnston> or the packaging branch to be removed when doing a rebuild
[17:27] <cjohnston> it still requires a packaging branch
[17:27] <dobey> i thought "rebuild" just triggered a new build of the same job
[17:28] <cjohnston> it does, but it carries all the env vars
[17:28] <cjohnston> https://code.launchpad.net/~dobey/cupstream2distro-config/u1creds-inline-packaging/+merge/197230 doesn't seem like the correct fix for the problem dobey
[17:28] <cjohnston> it still expects and external branch for the debian files
[17:30] <cyphermox> it's probably jsut carrying things over
[17:30] <dobey> why is it expecting one?
[17:30] <cyphermox> what if you resubmit the merge proposal?
[17:31] <cjohnston> cyphermox: dobey that wont work...
[17:31] <cjohnston> all that the MP did was take away the default packaging branch
[17:31] <cjohnston> it didn't remove the need for having a packaging branch
[17:32] <dobey> and what specifies that need?
[17:32] <cjohnston> your funny
[17:32] <cyphermox> cjohnston:        ubuntuone-credentials-trusty-amd64-manual: template: False ??
[17:32]  * cjohnston has no idea.. still looking
[17:32] <cyphermox> (just guessing)
[17:33] <cyphermox> I know fginther had a google doc about these things
[17:37] <cyphermox> cjohnston: do you need a link to the document?
[17:37] <cjohnston> cyphermox: the config in jenkins has:
[17:37] <cjohnston> # This project uses a packaging dir that is not compatible with pbuilderjenkins
[17:37] <cjohnston> bzr branch $packaging_branch debian
[17:37] <cjohnston> but I don't know where that comes from
[17:37] <cjohnston> yes please
[17:37] <cyphermox> right, that's because of the separate debian/ branch
[17:38] <cyphermox> cjohnston: from what I can see, you'd just need to remove that job in configurations and possibly also remove the part about trusty-amd64: False to have things use the standard process
[17:38] <cyphermox> https://docs.google.com/a/canonical.com/document/d/1vZf1jxnP0XYrVSoJF3UoTPNhZBYtX9oQufpR8bdaDzQ/edit#heading=h.c8d6w5jt4m60
[17:38] <Laney> cjohnston: Could you retry http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/22/ one more time? There was some kind of bug in the job that made it pull the wrong version of the tests (pinged jibel about it already)
[17:38] <cyphermox> cjohnston: ^ it's not a very clear document though
[17:38]  * cyphermox goes to get lunch
[17:40] <cjohnston> Laney: done
[17:40] <Laney> thanks
[17:41] <Laney> silly infrastructure :-)
[17:42] <dobey> hmm, there is no indication in that document of what "template: False" actually means there
[17:47] <cjohnston> im wondering if you do template false if you are using a seperate packaging branch
[17:50] <cjohnston> dobey: cyphermox I'm at a complete loss
[17:50] <cjohnston> I'd say at this point we will need to wait for Monday
[17:50] <cyphermox> well, tbh I think it's just avoiding to use a template at all, and instead uses the job named whatever the title is there
[17:51] <cyphermox> in this case, ubuntuone-credentials-trusty-amd64-manual
[17:51] <cyphermox> cjohnston: you could just as well remove the config to try and put it back
[17:51] <cyphermox> if things don't work as you expected
[17:51] <dobey> cyphermox: but it's not clear to me if that should be removed exactly
[17:52] <cyphermox> dobey: most jobs don't need any of this configuration, and don't have a configuration: stanza at all
[17:52] <cyphermox> this was only required because you used merge mode for the bzr branches
[17:52] <dobey> cyphermox: right. and ubuntuone-credentials will still be merged by the u1 tarmac
[17:52] <dobey> cyphermox: which is why it's not clear if just removing that job is the right thing to do
[17:52] <cyphermox> tarmac is irrelevant there
[17:53] <cyphermox> anyway, the worst that can happen is that you'd have another message from jenkins on the merge proposal that says the attempt failed
[17:53] <dobey> cyphermox: only under the assumption that this config isn't what's preventing the CI autoland job from merging approved branches in that project
[17:53]  * cjohnston lunches
[17:53] <dobey> cyphermox: and i don't see any clear indication if that is true or not
[17:53] <dobey> anyway i also need to get lunch
[17:54] <dobey> bbiab
[17:54] <cyphermox> any branch approved that hasn't been merged yet would still need to be reviewed by jenkins first anyway
[18:10] <cjohnston> Laney: all better?
[18:13] <Laney> cjohnston: seems decent now, cheers
[18:13] <cjohnston> :-)
[18:22] <psivaa> seb128: btw with libglib2.0 (2.39.1-0ubuntu2) from -proposed the NetworkManager crash is not occurring anymore.
[18:23] <seb128> psivaa, I know, but thanks for confirming ;-)
[18:35] <seb128> ogra_, psivaa, asac: the fixed glib is in trusty proper btw
[18:35] <seb128> it just migrated there
[19:11] <dobey> back
[19:14] <dobey> cyphermox: right. what i want to avoid though, is two separate jenkins trying to merge/commit the same branch into trunk
[19:39] <dobey> i wonder if just changing this to use "autolanding: False" instead, would solve it
[19:52] <cyphermox> nope, that's something else
[19:52] <cyphermox> that will make the merge proposals not merged at all
[20:05] <dobey> how so?
[20:05] <dobey> and does not merged mean no ps jenkins running tests?
[20:21] <dobey> bah. i guess i'll just go all in, instead of trying to stage this migration in a reasonable way
[20:36] <asac> 19:35 < seb128> ogra_, psivaa, asac: the fixed glib is in trusty proper btw
[20:44] <ogra_> ok
[20:44] <ogra_> [20:44] <popey> \o/
[20:55] <asac> oh cool
[21:11] <dobey> cyphermox, cjohnston: https://code.launchpad.net/~dobey/cupstream2distro-config/u1creds-fix/+merge/197264 <- maybe we could get this merged and deployed now then? i've pulled the landing of that project's trunk out of the u1 tarmac setup now.
[21:26] <dobey> cihelp ^^
[21:58] <dobey> well, time for me to head off. guess this won't get merged/deployed today. :-/
[21:58] <dobey> later
[22:03] <ogra_> [22:03] <ogra_> (since a while)
[22:03] <asac> oh :)
[22:03] <asac> ogra_: thanks
[22:04] <ogra_> np :)
[22:05]  * ogra_ goes afk again ... 
[22:13]  * popey flashes
[22:28] <asac> popey: is it any good?
[22:28] <asac> dashboard is still greenish :) at 11 pass