=== fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
=== psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: psivaa | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
[09:27] <ogra_> hmm, unity8 seems crashy in 119
[09:30] <didrocks> popey: coming?
[09:30] <didrocks> yeah, Saviq, mind having a look: http://ci.ubuntu.com/smokeng/trusty/touch/mako/119:20140109:20140107.1/5957/unity8-autopilot/ ?
[09:31] <popey> ya
[09:32] <didrocks> asac: FYI, as told before holidays, I don't want we rerun for flaky tests
[09:32] <didrocks> even if we point to the real links of failure, then, they are looking at the dashboard and "why warning? test rate are great"
[09:33] <asac> didrocks: i dont think thats the right way to think about it
[09:33] <asac> didrocks: we need to know whether something is a flaki test
[09:33] <asac> or not
[09:33] <didrocks> asac: well, that's to upstream to investigate
[09:33] <asac> we dont know without checking if it succeeds
[09:33] <didrocks> not us
[09:33] <asac> we have to make the call
[09:33] <asac> if we have a regression
[09:33] <asac> or not
[09:34] <didrocks> yeah, and we can see that comparing mako and maguro
[09:34] <asac> if we know we have a flaki test, we should check if its still a flaki test
[09:34] <didrocks> you are hiding information
[09:34] <didrocks> and that's why we have few progress
[09:34] <didrocks> so, I disagree with that approach
[09:34] <didrocks> hence reverting to the previous policy
[09:34] <asac> didrocks: its not the reason why we have few progress
[09:34] <didrocks> it's part of the reason
[09:34] <asac> didrocks: you can stop promoting
[09:34] <asac> thats the reason'
[09:34] <didrocks> anyway, in meeting now
[09:34] <Saviq> didrocks, it's 100%, have I missed something?
[09:34] <asac> but people are on it
[09:35] <didrocks> Saviq: look at the crash
[09:35] <ogra_> Saviq, .crash files
[09:35] <Saviq> didrocks, ah
[09:35] <asac> didrocks: what is clearly wrong is to promote because there is a test that we saw somehow failing in a probably similar manner
[09:35] <didrocks> asac: we can stop promoting until we are reliably at 100% then
[09:36] <didrocks> asac: but you have to explain that to the management chain
[09:36] <asac> didrocks: but our rule is that we dont promote images that have regressions
[09:36]  * didrocks sigh
[09:36] <asac> so if a test was flaki
[09:36] <ogra_> Saviq, 4 out of the 5 crashers with 119 are unity8 (not sure they are all the same) http://ci.ubuntu.com/smokeng/trusty/touch/
[09:36] <asac> we can release with that flaki
[09:36] <didrocks> you will take care of that then
[09:36] <didrocks> I won't
[09:36] <didrocks> and you will make the list
[09:36] <didrocks> and push people then
[09:36] <asac> didrocks: we have psivaa an plars giving us the list daily
[09:36] <didrocks> asac: yeah, and people ignores it
[09:37] <didrocks> asac: and I already have a list
[09:37] <didrocks> so it's all confusing
[09:37] <Saviq> ogra_, will have a look, thanks
[09:37] <didrocks> you introduced confusion then
[09:37] <asac> and i am pushing yes. but i increase pressure/priority continuously
[09:37] <asac> didrocks: if you say they ignore i will talk to them
[09:37] <asac> didrocks: you stated in your summary that folks are looking
[09:37] <didrocks> asac: yeah, see how much feedback/progress
[09:38] <asac> didrocks: so for flaki tests i want to give them time. for test that hard fail i will create a massive firedrill
[09:39] <asac> i dont want to do that priority for flaki tests... those should be prioritized with diligently increasing priority.
[09:39] <didrocks> asac: it's been weeks…
[09:39] <asac> we have made progress
[09:39] <didrocks> so you either take care of that yourself
[09:39] <asac> we do it step by step
[09:39] <didrocks> or you follow my rule
[09:40] <didrocks> asac: I'm quite unhappy that you changed the rule and you force it over me
[09:41] <didrocks> while I'm still having to do the push
[09:41] <didrocks> so either I'm control and I continue
[09:41] <didrocks> either you want to force you rules, but in that case, you handle it
[09:41] <didrocks> seems fair to me
[09:45] <didrocks> plars: psivaa: ok, seems no answer, so please, stop rerunning
[09:45] <didrocks> (apart if we have infra issues, of course)
[09:46] <psivaa> didrocks: asac: ack
[09:46] <Saviq> didrocks, ogra_, would it be possible that those .crash files would get uploaded to errors.u.c?
[09:47] <didrocks> Saviq: I guess that's a question for ev ^
[09:49] <didrocks> Saviq: keep us posted on this crash, it can be linked to latest Mir and seems to happen quite often (so potentially blocking promotion)
[09:51] <Saviq> didrocks, the one in unity8 suite doesn't retrace
[09:51] <Saviq> didrocks, checking out the other ones
[09:51] <didrocks> ok
[09:53] <Saviq> didrocks, the one in http://ci.ubuntu.com/smokeng/trusty/touch/mako/119:20140109:20140107.1/5957/default/ is:
[09:53] <Saviq> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
[09:53] <Saviq>   what():  could not activate surface with eglMakeCurrent
[09:53] <ogra_> Saviq, what didrocks said .... ev-country
[09:53] <Saviq> usually happens when screen goes blank - bug #1236525
[09:53] <ubot5> bug 1236525 in unity-mir "unity8 killed/crash then restart can result in mir unable "could not unblank display"" [Medium,Triaged] https://launchpad.net/bugs/1236525
[09:53] <ogra_> yeah
[09:53] <Saviq> or at least it did until now
[09:54] <ogra_> the boost msg definitely rings a bell
[09:54] <didrocks> Saviq: ok, keep us posted if there is no new crash for you (that you can retrace)
[09:54] <didrocks> ogra_: can you dogfood a little bit maguro?
[09:54] <ogra_> didrocks, my maguro is currently hacked quite a bit for swap issue tracking
[09:55] <ogra_> davmor2_ should get up soon
[09:55] <didrocks> ogra_: ok ;)
[09:58] <asac> didrocks: its all good and its your call as long as you always know if a test being red is a NEW regression or not. i am sure you undersatnd my way of thinking, so its a matter of taste on how to use the dashboard to do promotion and escalation decisionms
[09:58] <ev> didrocks, Saviq: this one? https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-unity8-autopilot/111/artifact/clientlogs/_usr_bin_unity8.32011.crash/*view*/
[09:58] <asac> didrocks: when you were gone people couldnt say for sure anymore if we just landed a very awful regression side effect
[09:59] <asac> or if its a flaki test like we saw before ... hence i required the hard empirical data
[09:59] <asac> i find it a bit sad that folks dont prioritize because the dashboard is green, but maybe you are right
[09:59] <ev> if you look at the stacktrace, it's pointing at a corrupt stack. I suspect the retracers won't be able to do any better :)
[09:59] <asac> however on the maguro once i was continuously increasing priority
[09:59] <asac> ones
[10:00] <asac> but since i sent the first mail beginning of this week, i thought it was reasonable to not expect big fixes by yesterday ... i planned to talk to folks again today about their cases
[10:00] <alan_g> psivaa: we're seeing CI failures (e.g. https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/227/consoleFull) that appear to be the test hardware in a "wrong" state (c.f. bug 1239955). Is there anything you can do to reset it?
[10:00] <didrocks> asac: now I'm back, so yeah, I'm tracking all issues. Before promoting, I'm checking again my last (with stack) ;)
[10:00] <ubot5> bug 1239955 in Mir "integration-tests hang/fail in AndroidGPUDisplay.gpu_display_ok_with_gles when the display is asleep: what(): error posting with fb device" [Medium,Triaged] https://launchpad.net/bugs/1239955
[10:00] <didrocks> asac: I understand why you wanted to do that, but I still think that showing issues clearly on the front page is a preferable way of putting social pressure
[10:01] <psivaa> alan_g: let me see
[10:01] <didrocks> asac: yeah, btw, we have a confirmation that what I was answering to Nicholas yesterday is right: 2 flaky maguro failures showed for the first time on mako today
[10:01] <didrocks> asac: so, we really need to clean the maguro as well
[10:02] <asac> didrocks: yeah. well, i thought about it and i really believe we want to somehow do both: a) retry and b) visualize flakit tests in orange
[10:02] <asac> but i dont want to put that organ for flaki test on the CI team
[10:02] <asac> so lets continue as you say
[10:02] <asac> didrocks: i think we should shift from "clean maguro" to "clean emulator" :)
[10:02] <asac> but not today
[10:02] <didrocks> asac: do you think the emulator is so slower that maguro?
[10:03] <asac> didrocks: yes. it will reveal those timing issues even better
[10:03] <didrocks> than*
[10:03] <asac> didrocks: xnox sent around how to do that
[10:03] <didrocks> yeah, making sense
[10:03] <asac> didrocks: at least we can tell people that say they dont have a maguro that they should see if it works on emulator
[10:03] <asac> and if not debug there
[10:03] <Saviq> ev, ok, I'm not really asking about this particular one
[10:03] <didrocks> asac: +100 :)
[10:03] <ev> Saviq: ah, context please :)
[10:03] <asac> xnox: is it super easy to run APs on the emulator locally?
[10:03] <asac> xnox: did your mail include instructions?
[10:04] <Saviq> ev, I just wonder if it would  be possible to upload stuff from the test runs automagically to errors.u.c?
[10:04] <ev> yes - the problem at the moment though is that we don't have armhf retracers. I've asked bdmurray to pick up the work on that (https://rt.admin.canonical.com//Ticket/Display.html?id=58019)
[10:11] <psivaa> alan_g: if you mean to reboot the device, i think the job does that already before running the tests.
[10:11] <psivaa> alan_g: also when you run the job for the second time, it's not guaranteed that the job will pick up the same mako
[10:12] <psivaa> alan_g: in any case, i've rebooted that particular device. so if you'd like to give it a go
[10:13] <alan_g> psivaa: we've seen it several times today - not sure if it was all on the same device. Will give it a go.
[10:17] <psivaa> alan_g: just checked the other failed builds and they are in different devices. so it may not be the hardware that's at fault
[10:18] <alan_g> psivaa: thanks. Do you know of any change? E.g. is there a image today?
[10:18] <psivaa> alan_g: yes todays tests are using trusty-proposed 119
[10:19] <alan_g> psivaa: I'll try that locally. Maybe we have a new failure mode. Thanks for your help.
[10:20] <psivaa> alan_g: yw :)
[10:24] <asac> didrocks: barry mentioned that system-image has debian/ dir outside their trunk? did they even use CI before?
[10:24] <didrocks> asac: no, they never used it
[10:24] <asac> right
[10:30] <asac> wow ... i got flooded with old email today :/
[10:30] <Saviq> didrocks, no new crashes that I could retrace
[10:31] <didrocks> Saviq: ok, great! :)
[10:31] <Saviq> didrocks, two of them were the eglMakeCurrent thing, which actually sounds concerning if powerd-cli holds the display on
[10:33] <didrocks> ok, let's see what results popey and davmor2_ will get on dogfooding :)
[10:35] <popey> didrocks: 119 is good here
[10:38] <didrocks> great ;)
[10:56] <alan_g> psivaa: trying it locally I find that the test fails intermittently unless I first stop unity8 ("sudo -u phablet -i stop unity8"). Does the test initialization do this?
[10:57] <psivaa> alan_g: let me check
[10:58] <psivaa> alan_g: i see this:
[10:58] <psivaa> infinity: Turning on the display
[10:58] <psivaa> infinity: stopping unity8
[10:58] <psivaa> unity8 stop/waiting
[10:59] <alan_g> psivaa: Oh well, it was a nice theory
[11:00] <psivaa> :)
=== davmor2_ is now known as davmor2
[11:36] <Mirv> psivaa/cihelp: "Could not resolve 'archive.ubuntu.com'" on autopilot-nvidia
[11:37] <Mirv> http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/label=autopilot-nvidia/ all of today's
[11:37] <psivaa> Mirv: i'll take a look
[11:38] <Mirv> didrocks: packaging ack http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/Apps/job/cu2d-apps-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_gallery-app_0.0.67+14.04.20140108.2-0ubuntu1.diff
[11:39] <didrocks> Mirv: +1 :)
[11:39] <Mirv> thanks, both :)
[12:05] <psivaa> Mirv: strange. I was able to resolve archive.ubuntu.com from the command line. but i have now rebooted the machine.
[12:05] <psivaa> Mirv: would you like to try it again please
[12:35] <didrocks> davmor2: hey, awaken? ;)
[12:36] <davmor2> didrocks: what's up?
[12:36] <davmor2> didrocks: haptic on 119 is weird
[12:37] <didrocks> davmor2: just to tell that we want to promote 119, so if you can test it throughfully :)
[12:37] <didrocks> davmor2: for haptic, you can ping tvoss :)
[12:37] <davmor2> didrocks: currently fresh installing to get rid of the swap off from yesterday
[12:38] <didrocks> ok ;)
=== cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
[13:06] <cjohnston> Mirv: did you retry whatever failed to reach archive.ubuntu.com?
=== alan_g is now known as alan_g|lunch
[13:20] <asac> cjwatson: would we have enough builders to enable arm64 and ppc64el in daily-build ppa? if not, do we have plans to expand the pool of builders on those archs?
[13:20] <asac> anything i can do?
[13:20] <Mirv> psivaa: cjohnston: hi, trying now
[13:21] <psivaa> Mirv: ack, thanks
[13:21] <cjwatson> asac: infinity would be best to answer that.  For arm64 the answer is probably still no; there simply isn't enough hardware in existence, and we're expanding as fast as our partner/sponsor can manage.  For ppc64el maybe, it's a bit easier to spin up more VMs there
[13:21] <asac> cjwatson: from what i understand we wouldnt use them much as most packages we carea bout are dep-wait, but it would help us reduce time to archive if we had everything that can be build already build before copying things to proposed.
[13:22] <cjwatson> asac: With Qt 5.2 most packages you care about will be fixed, I suspect
[13:22] <cjwatson> asac: Since v8 goes away
[13:22] <asac> hmm. guess that might increase importance of this topic even further
[13:22] <asac> thanks. will talk to infinity
[13:22] <cjwatson> (Plus various random dh-autoreconf conversions and the like, but nothing else major AFAIK)
[13:29] <Mirv> psivaa: this happened after your reboot: http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/1069/label=autopilot-nvidia/console
[13:29] <Mirv> ie 20 minutes ago UTC time
[13:30] <psivaa> cjohnston: would you mind taking on this please ^?
[13:34] <cjohnston> looking
[13:37] <cjohnston> is appears to still be having issues getting to archive.ubuntu.com
[13:38] <cjohnston> beyond that, if psivaa doesn't have any ideas, we will have to wait for fginther
[13:39] <cjohnston> Mirv: ^
[13:39] <psivaa> cjohnston: strangely enough archive.ubuntu.com resolves OK from that machine. so i am at a loss
[13:43] <cjwatson> Looking at performance in the test rebuild, ppc64el might be safe enough to enable now, maybe.  Though of course some of that is just because failures are on average quicker than successes
[13:49] <fginther> morning
[13:49] <fginther> cjohnston, psivaa looking
=== dobey_ is now known as dobey
=== alan_g|lunch is now known as alan_g
[14:19] <davmor2> didrocks: 119 is looking pretty good I don't see any issues that weren't there before which I think popey can confirm on mako too
[14:19] <popey> already did
[14:19] <popey> its groovy
[14:19] <didrocks> excellent
[14:20] <didrocks> let's promote it then :)
[14:20] <didrocks> ogra_: when you read this ^
[14:22]  * ogra_ sees issues ... that darn thing vibrates every time i start an app :P
[14:22] <ogra_> didrocks, will do :)
[14:23] <didrocks> ogra_: open a bug! :)
[14:23] <didrocks> "can you please break haptic feedback?"
[14:23] <ogra_> heh
[14:45] <popey> didrocks: can we please get https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1240505 qtorganiser5-eds fix from renato in landing asks?
[14:45] <ubot5> Ubuntu bug 1240505 in Ubuntu Calendar App "There is no way to delete an event" [Critical,In progress]
[14:47] <didrocks> popey: sure, can you file it? I see that calender-app change is not merge yet though
[14:48] <popey> ok
[14:58] <cyphermox> didrocks: webbrowser looks good to me
[14:59] <cyphermox> Mirv: have you tested webbrowser too?
[14:59] <didrocks> cyphermox: it wasn't on the landing ask, did upstream tell you finally to release it?
[14:59] <didrocks> (so to answer, I think Mirv didn't test it)
[14:59] <cyphermox> no, you never mentioned upstream asking to release it :)
[15:00] <cyphermox> well, anyway, looks fine to me atm, we'll just wait then
[15:03] <popey> didrocks: will add after calendar dev has tested further.
[15:03] <didrocks> popey: ok ;)
[15:04] <didrocks> cyphermox: that's what I told yesterday in the meeting, that upstream may add it :)
[15:04] <cyphermox> I misheard then
[15:05] <didrocks> cyphermox: I think continuing cleaning the prepare job will be of value (in case they are not all good)
[15:08] <cyphermox> I'm going to need more context, my head is full of bluez state right now
[15:08] <didrocks> cyphermox: what we discussed yesterday, some prepare job in cu2d were yellow because of some direct uploads to distro during the holidays
[15:11] <cyphermox> right
[15:12]  * cyphermox takes bamf
[15:14] <didrocks> boumf! ;)
[15:15] <ogra_> do you eat, smoke or sniff it ?
[15:15] <cyphermox> omg, YUCK.
[15:15]  * ogra_ grins
[15:15] <cyphermox> https://launchpad.net/ubuntu/+source/bamf/0.5.1+14.04.20131125-0ubuntu2
[15:15] <cyphermox> no, yuck this ^
[15:15]  * ogra_ only takes aspirine at times 
[15:16] <ogra_> heh, lovely
[15:22] <cyphermox> https://code.launchpad.net/~mathieu-tl/bamf/14.04.20131125-0ubuntu2/+merge/201025
[15:22] <cyphermox> didrocks: ^
[15:23] <didrocks> cyphermox: yeah, seems some people aren't wanting to play nicely! This diff is so easier though! Thanks :)
[15:24] <cyphermox> the old diff had unapplied stuff in it..
[15:25] <didrocks> cyphermox: yeah, I saw that *sigh* :(
[15:28] <cyphermox> brb
[15:33] <kenvandine> cyphermox, didrocks: i had merges for all the direct uploads, most have merged
[15:34] <didrocks> kenvandine: excellent! so if we rerun, we should have no yellow prepare anymore?
[15:34] <kenvandine> https://code.launchpad.net/~ken-vandine/bamf/0.5.1+14.04.20131125-0ubuntu2/+merge/200723
[15:34] <kenvandine> bamf is failing
[15:35] <didrocks> ah, I guess cyphermox had a bamf merge as well
[15:35]  * didrocks reboots
[15:35] <didrocks> brb
[15:37] <kenvandine> didrocks, cyphermox: my branch has a fix to the gcov.m4 file that fixes a FTBFS, but tests still fail
[15:37] <kenvandine> several of the packages needed updates to that
[15:37] <didrocks> kenvandine: the other works, but only bamf doesnt'?
[15:37] <kenvandine> bamf is the only one not merged yet
[15:37] <kenvandine> yeah
[15:38] <kenvandine> well
[15:38] <kenvandine> it fixed the build
[15:38] <kenvandine> but now tests fail :)
[15:38] <didrocks> kenvandine: ah, can you get bregma on board? :)
[15:38] <kenvandine> bregma, ^^
[15:39] <kenvandine> https://code.launchpad.net/~ken-vandine/bamf/0.5.1+14.04.20131125-0ubuntu2/+merge/200723
[15:39] <dobey> didrocks: replied on https://code.launchpad.net/~dobey/cupstream2distro/native-versions/+merge/200736
[15:41] <didrocks> dobey: ok, just be aware that if someone bumps the version in your native project with removing the +, you will end up in a broken situion
[15:42] <dobey> didrocks: yeah, but i can a) needs-fixing on reviews that have that, and b) yell at people that commit it as such anyway :)
[15:44] <didrocks> dobey: I'm happy with this. I would prefer put that into production in my morning if possible, do you mind? (I can push and it should be safe, but not sure if anyone else will get issues meanwhile, who will debug it)
[15:46] <dobey> didrocks: i'd like to get it merged/deployed asap, so i can start using it
[15:46] <ogra_> === image 119 promoted to trusty ===
[15:46] <dobey> didrocks: i know our TZ difference sucks in that regard though
[15:46] <didrocks> ogra_: thanks!
[15:46] <popey> woop woop
[15:46] <didrocks> dobey: yeah, I prefer to be safe than sorry :)
[15:47] <dobey> didrocks: you are not the only one who can deploy it into jenkins are you?
[15:47] <didrocks> dobey: no, but I'm the only one really knowing the code
=== alan_g is now known as alan_g|tea
[15:48] <dobey> didrocks: well, the code isn't that hard to understand. i think we can debug it if there is a problem :)
[15:49] <didrocks> dobey: I still prefer to be safe. I'm happy to compromise on native vs non native and not handling the automatic fallback for native when the version is wrong. I don't want to put production at risk though :)
=== gatox is now known as gatox_lunch
[15:51] <dobey> didrocks: if you've already made up your mind about not merging/deploying it today, why ask if i mind?
[15:51] <didrocks> dobey: just trying to assess if there is a real need of urgency to put production at risk for it
[15:52] <didrocks> like you have some uploads that are critical for today that can't wait
[15:53] <dobey> well, we need to get a release of ubuntu-purchase-service built, and a unity-scope-click that depends on it. wanted to have it done 2 days ago, but i wasn't aware that changes were made to the u-p-s trunk without review at the time, or that these native versions just flat out didn't work. :-/
[15:54] <didrocks> well, it's a choice as well to want to keep native versions, you blocked on it (contrary to than 200+ projects we have)
[15:55] <didrocks> anyway, no need to loose time in that debate again
[15:56] <dobey> didrocks: right, but from our previous chat about it, it seemed as if it would work as expected. i wasn't aware that it didn't (if i'd known 2 months ago it didn't work, i would have made this branch then)
[15:56] <dobey> but there's nothing we can do about that 2 months ago :)
[15:56] <didrocks> not sure to understand your point, you knew that we had requirements like split, we chatted about it 2 months ago :)
[15:57] <dobey> guidelines. yes we chatted about it, and the implication that native was OK, and that it worked
[15:58] <didrocks> not really what I remember from the discussion
[16:00] <fginther> Mirv, autopilot-nvidia should be working now
[16:00] <sergiusens> didrocks, https://code.launchpad.net/~fginther/cupstream2distro-config/add-usensord-and-goget/+merge/200932
[16:01] <dobey> didrocks: anyway, can we merge/deploy it today, or no?
[16:01] <sergiusens> didrocks, daily release is not enabled since it would need someone to review
[16:01] <didrocks> dobey: not today, as told above (and in meetings now until EOD)
[16:01] <didrocks> sergiusens: ok, will have someone reviewing that
[16:03] <fginther> sergiusens, sorry about not merging that through, I'll get that in now
=== greyback is now known as greyback|away
=== cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: doanac | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
=== alan_g|tea is now known as alan_g
[16:06] <sergiusens> fginther, ah, I thought you were waiting for a reviewer; I was just side pinging didrocks to get the daily release stuff setup as well :-)
[16:49] <cyphermox> kenvandine: I don't see your merges for libdbusmenu and libindicator, did you have one for those?
[16:50] <kenvandine> cyphermox, i didn't do those... i don't recall seeing them as yellow
[16:50] <cyphermox> ugh, my connection is being pretty unreliable right now
[16:50] <kenvandine> maybe i missed that stack :)
[16:50] <cyphermox> kenvandine: they seem to be here
[16:50] <kenvandine> cyphermox, of course... the network guy has networking problems :)
[16:50] <cyphermox> alright, starting with those now, if the interwebs will let me :)
[16:50] <cyphermox> kenvandine: hehe
[16:51] <cyphermox> could be because I hack at stuff and change my network config
[16:51] <kenvandine> i only seem to have network problems when i do google hangouts :)
[16:51] <cyphermox> hehe
[16:51] <kenvandine> hangouts hate me... but pretty reliable when i keep video disabled
[16:51] <cyphermox> yeah, just before a hangout all hell breaks loose
[16:51] <cyphermox> yeah
=== gatox_lunch is now known as gatox
[17:03] <didrocks> kenvandine: cyphermox: coming? :p
=== greyback|away is now known as greyback
[17:36] <robru> sergiusens, http://paste.ubuntu.com/6721951/ what should be done with these files from goget-ubuntu-touch?
[17:37] <robru> sergiusens, should I create an -examples package for them? or delete them?
[17:41] <cyphermox> kenvandine: robru: https://code.launchpad.net/~mathieu-tl/libdbusmenu/12.10.3+14.04.20131125-0ubuntu2/+merge/201052
[17:42] <kenvandine> cyphermox, done
[17:42] <cyphermox> ta, yay!
[17:45] <robru> kenvandine, cyphermox https://code.launchpad.net/~robru/goget-ubuntu-touch/packaging/+merge/201050
[17:46] <kenvandine> cyphermox, mind reviewing that for robru?
[17:46] <cyphermox> I am
[17:46] <kenvandine> my head is deep in the hub atm
[17:46] <cyphermox> hey, could we not fix dh_golang to not do that?
[17:46] <kenvandine> thx
[17:46] <cyphermox> robru: ^ :)
[17:46] <robru> cyphermox, no idea, I've never seen dh_golang before
[17:47] <robru> cyphermox, might be possible but it's outside the scope of this merge
[17:47] <cyphermox> yeah
=== alan_g is now known as alan_g|EOD
=== plars changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: plars | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -
[18:35] <sergiusens> robru, can't we exclude them?
[18:35] <sergiusens> robru, I'll talk to the maintainer of dh-golang
[18:36] <sergiusens> cyphermox, ^^
[18:36] <sergiusens> exactly it's the application source; it would need to exclude files if package name == main
[18:41] <cyphermox> what ?
[18:41] <sergiusens> cyphermox, oh, in ref to reading the backlog and you saying: fix it in dh_golang ;-)
[18:42] <cyphermox> sergiusens: well the right thing to do would be for dh_golang to ignore comments...
[18:42] <cyphermox> though I guess comments in debian/control aren't exactly kosher
[18:43] <sergiusens> cyphermox, I thought you were talking about http://paste.ubuntu.com/6721951/
[18:45] <cyphermox> nah
[18:45] <cyphermox> those should jsut get rm'ed in debian/rules
[18:55] <sergiusens> fginther, hey, is the usensord goget branch deployed to jenkins?
[18:57] <fginther> sergiusens, it should be
[18:58] <sergiusens> fginther, right, just noticed it! Thanks
[18:58] <sergiusens> might be builder overload
=== josepht_ is now known as josepht
[19:20] <robru> sergiusens, cyphermox yep i rm'd those in debian/rules already, but i just wanted sergiusens input to give him a chance to say 'no wait, we need to ship those in package x!'
[19:22] <cjwatson> cyphermox: Comments in debian/control are explicitly permitted by other tools and by the policy manual
[19:22] <cjwatson> cyphermox: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-controlsyntax
[19:22] <cyphermox> yes
[19:22] <sergiusens> cjwatson, I'll log a bug against dh-golang for that
[19:23] <sergiusens> robru, and for that as well ;-)
[19:23] <sergiusens> robru, usr/share/gocode is just for package building
[19:25] <cyphermox> cjwatson: I wasn't saying that it's not permitted, just that it's not quite RFC 2822 or whatever, so people could have cut corners to parse the file
[20:34] <sergiusens> robru, cyphermox how soon do we get daily release for usensord?
[20:34] <cyphermox> let's complete that now..
[20:36] <cyphermox> we basically just need to merge my changes (will push in a second) for cupstream2distro-config and set a bootstrap commit in changelog for both
[20:47] <sergiusens> ChickenCutlass, ^
[20:47] <ChickenCutlass> sergiusens: great -- thanks
[20:56] <sergiusens> fginther, are there any trusty instances on jenkins that I could use?
[21:00] <fginther> sergiusens, there are vms
[21:03] <cyphermox> robru: kenvandine: https://code.launchpad.net/~mathieu-tl/usensord/bootstrap/+merge/201101
[21:04] <cyphermox> ^ boostrap commit...
[21:05] <sergiusens> fginther, that's fine; are the rather clean?
[21:05] <sergiusens> fginther, like the saucy ones is clean enough
[21:05] <fginther> sergiusens, they are snapshotted
[21:05] <fginther> sergiusens, same setup as the saucy VMs you use for the click packaging
[21:06] <sergiusens> fginther, great, it's actually for that :-)
[21:14] <kenvandine> cyphermox, done
[21:17] <kenvandine> yay... bamf passed ci
[21:29] <cyphermox> yay
[21:46] <kenvandine> cyphermox, did you see didrocks gave you ofono on the landing plan?
[21:50] <cyphermox> oops, no I had not seen
[21:50] <cyphermox> I'll take care of it tonight
[21:59] <fginther> s-jenkins will brought down in about 30 minutes to fsck a disk
=== plars changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: -