#ubuntu-ci-eng 2014-02-24
<sergiusens> rsalveti, approved
<sergiusens> cjohnston, wiki updated
<rsalveti> sergiusens: great, thanks
<cjohnston> thanks sergiusens
<rsalveti> building tarball, then upload, then new image
<cjohnston> mako-07 is back online
<rsalveti> cjohnston: thanks!
<cjohnston> rsalveti: with your fix, will we be able to continue using phablet-flash (atleast for now) or will we still break with phablet-flash
<rsalveti> cjohnston: should work with mako
<cjohnston> ack
<cjohnston> can someone file a bug against ubuntu-ci-services-itself with the need to switch please?
<cjohnston> I'll test it again tonight, if it doesn't work, I'll look at getting it switched tonight
<cjohnston> rsalveti: are you building a new image?
<rsalveti> cjohnston: soon
<plars> rsalveti, asac: Sorry, I've been away from home most of the weekend. Looking at it now
<plars> ok, this doesn't bode well
<plars> I'm trying it at home and not getting good results - I don't even get past the google boot screen
<plars> rsalveti: is there something other than -b I need to pass to phablet-flash?
<plars> rsalveti: 'phablet-flash ubuntu-system -b --channel trusty-proposed' is what I'm using and I'm getting 205
<plars> rsalveti: I also don't see a wlan0 in ifconfig -a on my local mako, nor in the lab
<rsalveti> plars: right, we fixed the issue already
<rsalveti> plars: latest image should have the fix, and should be around in a few minutes
<plars> rsalveti: ok, so this is a known problem and will be fixed in 206?
<rsalveti> plars: yes
<plars> rsalveti: awesome
<rsalveti> cdimage part is done already
<plars> rsalveti: argh, you have to tell me that at 10pm, now I can't sleep till I see it work :)
<rsalveti> plars: haha, sorry :-)
<rsalveti> also waiting for that here
<plars> heh, no worries. It will be worth it if I see this working
<rsalveti> yeah
<plars> rsalveti: going to try to have flo up and running tomorrow too. I tried it manually with a device in the lab but the device isn't responding now. I suspect it needs some ack on the screen or something
<plars> it had android before, so not sure
<rsalveti> basically the new recover wasn't flashing the boot partition, so it was still booting with the older kernel
<plars> I'll have to wait for rfowler to see what's on the screen tomorrow I guess
<rsalveti> right, could be as well
<plars> rsalveti: ah, ok
<plars> well, would be good to at least see mako booting and start to run tests before I sleep
<rsalveti> yeah
<rsalveti> wonder why it's taking so long for an image to be published in system-image nowadays
<rsalveti> 50 minutes already
<rsalveti> should probably be done anytime soon, but stil
<rsalveti> *still
<plars> yeah
<sergiusens> rsalveti, how about now?
<rsalveti> still waiting
<sergiusens> :-)
<rsalveti> still nothing, jezz
<plars> sergiusens: is there a ppa with ubuntu-device-flash for precise?
<plars> sergiusens: I would assume it becomes part of the regular phablet-tools at some point right? And are the other phablet-tools still applicable if used with ubuntu-device-flash?
<sergiusens> plars, it's in ppa:phablet-team/tools
<sergiusens> independent; tryying to avoid having a regular person that just installs to land a set of unneeded tools
<sergiusens> could be a dep though
<plars> sergiusens: I don't see it available on precise, and I'm trying to run 'ubuntu-device-flash -bootstrap=true -channel=trusty-proposed' on trusty right now which seems to be doing nothing for about 15 min now
<plars> oh, I see... it no longer autodetects the device type?
<plars> still no 206 either :(
<sergiusens> plars, bootstrap is with two '-' and is done from the bootloader (as stated in the help, man page and wiki)
<plars> sergiusens: I was just looking at running it with --help '-bootstrap=false: Bootstrap the system, do this from fastboot' where it only has 1 -, didn't look at the man yet
<sergiusens> hmm, right; the two dashes isn't released yet
<sergiusens> plars, are you doing that from the bootloader
<sergiusens> ?
<plars> sergiusens: so I'm confused - is phablet-flash not expected to work at all and we'll need to do something with ubuntu-device-flash + adb + something else? to get back to where we were before?
<plars> sergiusens: I'm not, it seems to be downloading right now but hasn't gone farther yet
<rsalveti> it seems import-images was commented out from cronjob =\, running it manually now
<sergiusens> plars, I asked you guys to review two months ago
<sergiusens> sent an email a month ago as well
<plars> sergiusens: I didn't see that, I found an email with no responses mentioning it in ubuntu-phone, but that was about it
<sergiusens> plars, phablet-flash is deprecated
<sergiusens> plars, was over irc (the review request)
<sergiusens> plars, anyways, you just need to bootstrap once
<plars> sergiusens: I believe you, I just don't think I ever saw it
<plars> sergiusens: in the past we've always run phablet-flash in bootstrap mode, so I guess we don't want to do that now with this new tool?
<sergiusens> plars, then you just need to ubuntu-device-flash --wipe --channel devel-proposed and that's it
<plars> I see
<sergiusens> plars, bootstrap implies you can have no OS installed; a broken one or android and not need any requirement on the currently installed os
<sergiusens> plars, the only difference is flashing recovery and booting into it
<sergiusens> nothing else differs from that
<plars> sergiusens: the other phablet-tools for -{network|config|click-test-setup|etc} are expected to be compatible with this though, correct?
<sergiusens> plars, correct
<plars> awesome
<sergiusens> plars, those won't change
<rsalveti> plars: do you know why http://ci.ubuntu.com/smokeng/trusty/touch/mako/202:20140222.1:20140115.1/6761/ is still stuck?
<sergiusens> plars, keep in mind though that when we disable adb on default images I'm going to add one more switch to ubundu-device-flash to enable it while flashing
<sergiusens> plars, but we are not there yet; so no worries
<plars> rsalveti: best guess, is because for some reason, the run ended prematurely
<sergiusens> plars, if you are doing this in ci already, can you please add two dashes to the params? should work still
<rsalveti> plars: hm, ok, can we resume it?
<plars> sergiusens: I'm just playing with it locally at this point
<sergiusens> ack
<plars> rsalveti: no
<rsalveti> 202 is the last 4.2.2 image we had, so that's why it would be useful to have the complete run for it
<plars> rsalveti: it's not paused - it's dead and other things tried to run since then, leaving that dashboard entry in a bad state
<rsalveti> got it
<plars> rsalveti: but it was still trying to use phablet-flash too
<plars> rsalveti: we'll need to put some fixes for all this into the ci infrastructure before things are happy again it seems
<rsalveti> right, that's broken for 203, 204 and 205
<rsalveti> but phablet-flash should hopefully be good again with 206
<rsalveti> importing as we speak
<plars> sergiusens: in the meantime, if we could get it in the ppa for precise, that would help a lot
<sergiusens> plars, I thought it was?
<plars> sergiusens: doesn't seem to be, let me double-check
<plars> oh wait
<plars> crap I forgot this stupid box is on  13.04
<plars> *sigh*
<sergiusens> plars, source package is goget-ubuntu-touch
<sergiusens> plars, oh, didn't do 13.04; that's EOL, right?
<plars> so, yes, our system attached to the phones is on 13.04 and needs to be updated
<sergiusens> I could to buy you time though
<plars> sergiusens: thanks
<sergiusens> plars, hmm, I can't bin copy to raring anymore from the ppa :-/
<plars> hmm, ok
<sergiusens> should be able to wget https://launchpad.net/~phablet-team/+archive/tools/+files/ubuntu-device-flash_0.2%2B14.04.20140117-0ubuntu1_amd64.deb
<sergiusens> I see lucid, but no raring
<plars> wow
<sergiusens> plars, let me try using the cli
<plars> even with ubuntu-device-flash locally, it seems to not boot
<plars> I guess 206 is needed no matter what tool we flash with?
<rsalveti> yeah, wait for 206
<plars> yeah
<rsalveti> with -b, yeah
<plars> I was hopeful :)
<sergiusens> plars, yeah, you need 206
<rsalveti> it works only when updating 202->206 with system-settings
<rsalveti> we didn't notice this as unfortunately I had the right kernel before (because of the mwc image)
<rsalveti> but at least the import-images job is actually running now
<sergiusens> plars, can't copy; I get this from launchpad
<sergiusens> raring is obsolete and will not accept new uploads.
<rsalveti> guess stgraber removed that entry from cronjob when adding the new targets
<rsalveti> raring is not supported anymore, right?
<sergiusens> it isn't
<plars> sergiusens: I was able to install from the wget package - good enough for now. I'll see what we can do to get that box updated soon
<sergiusens> rsalveti, but plars tells me some of our boxes are still on
<rsalveti> maguro is still fine
<rsalveti> raring you mean?
<sergiusens> plars, yeah, you won't be getting updates for anything if you stay on raring
<rsalveti> might be confusing stuff
<sergiusens> rsalveti, raring
<rsalveti> right
 * sergiusens plans for an early wakeup and goes to bed
<plars> Yeah, I think I'm losing hope that we'll see 206 tonight
<rsalveti> yeah, compressing them now
<rsalveti> I'd guess at least more 10 minutes
<plars> ok, well it should kick off on it's own... going to come back and check on it in a bit
<rsalveti> alright, finally done
<plars> well, at least locally I can confirm that I have a wlan0 device
<plars> with 206
<rsalveti> awesome
<plars> rsalveti: and I boot to the gui :)
<rsalveti> \o/
<plars> waiting a bit more to see how the ci run goes - want to see it at least get through the install
<rsalveti> yeah
<rsalveti> nothing at https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/ still
<plars> once that happens, it will be some time before we really see results roll in, and I know psivaa will be up soon
<plars> rsalveti: it's still installing
<rsalveti> oh, great
<plars> image is downloaded, just flashing now
<rsalveti> alright, both mako and flo are working just fine
<rsalveti> time to get some sleep
<rsalveti> later
<plars> yeah, other than a failed systemsettle on default, the tests seem to be up and running now
<plars> I'll work on flo in the morning, then on converting it all to run with the new tool
<plars> rfowler: when you get a chance tomorrow, could you poke flo-01 - if it's in too bad a shape, just try to get it as far as the bootloader and I should be able to fix it from there
<tvoss> sil2100, hey there
<didrocks> Mirv: hey, welcome back! mind to come?
<Mirv> didrocks: oh, I'm in a wrong hangout url?
<didrocks> Mirv: should be
* ev_ changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: ev | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but chooose right timezone | Landing instructions: http://goo.gl/8H1Du3 | Known Issues: -
<alan_g> ev_: we're seeing "Cannot add PPA: 'ppa:chris.gagnon/mir-demo-tester'." failures on CI any idea why? e.g. https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/586/console
 * ev looks
<tsdgeos> ev: also if you have time can you look at https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/5472/console ? "Failed to fetch http://ports.ubuntu.com/ubuntu-ports/pool/main/p/pygobject/python-gi_3.11.90-0ubuntu1_armhf.deb  Could not resolve 'ports.ubuntu.com'"
<ev> alan_g: was this working previously? I'm wondering if it's because you only have packages built for trusty
<tvoss> sil2100, around?
<alan_g> ev: These started over the weekend
<sil2100> tvoss: hello, on a meeting still, will poke you in 30 minutes
<tvoss> sil2100, ack
<popey> ogra: G+ on 206 on mako works fine here
<ogra> ok, then it likely is the high resolution that causes this
<ogra> i guess G+ tries to use the desktop version on the flo
<ogra> popey, btw, do you notice that webapps ate slightly to large on flo ?
<ogra> or is that only me
 * popey looks
<ogra> (/me can scroll horizontally on myna of them ... it is like 1cm to wide)
<ogra> *many
<popey> my flo is portrait
<ogra> mine too
<ogra> (teh default image is portrait ... missing the switch option inside unity8)
<popey> yes, getting browser not supported on flo
<ogra> right
<ogra> i get the same on the desktop when using the webapp btw
<psivaa> sil2100: i definitely see unity-system-compositor and pulseaudio on the top all the time
<popey> ogra: any idea what else could cause this app launch issue bug 1284025
<ubot5> bug 1284025 in Ubuntu Music App "Music app 356 on mako image 206 doesn't play music launched from dash 1st time" [Undecided,New] https://launchpad.net/bugs/1284025
<ogra> popey, pulse ?
<popey> ooh, hang on
<popey> i may need to go back further to eliminate music as the culprit itself
<popey> we updaed from 329 to 350 on friday
 * popey reverts to 329
<ogra> bug 1283818
<ubot5> bug 1283818 in android (Ubuntu) "voice call not working properly after the first call" [Critical,Confirmed] https://launchpad.net/bugs/1283818
<ogra> i think this is a pulse issue too
<ogra> (or an issue with the android HAL not providing the right bits)
<popey> interesting
<didrocks> can be linked, yeah
<didrocks> popey: mind testing on image 201, just in case?
<didrocks> or rather 202 even
<popey> yeah
<popey> which ?
<didrocks> which what? ;)
<popey> 201 or 202
<didrocks> ah
<didrocks> 202, the latest before 4.4 :)
<popey> kk
<didrocks> thx!
<popey> i need to pop out to take cat to vet shortly
<didrocks> sure, it's not the biggest issue we have on worth anyway now :)
<popey> :D
<didrocks> world*
 * didrocks is really worried about global system settle
<popey> nope, its music
<popey> revert to 329 works
 * ogra blames Mir 
<didrocks> ahah ;)
<ogra> k
<didrocks> 329? :p
 * didrocks is lost
<ogra> one donw :)
<ogra> didrocks, music-app
<didrocks> in image number
<didrocks> ah
<didrocks> ok, so music-app itself
<didrocks> popey: can you revert music-app in the store?
<didrocks> that would be one less :p
<didrocks> then, upstream can quietly work on a fix
<popey> lets see
<popey> there is a button which allows me to revert to previous
<popey> but dunno how many back it lets me go
<didrocks> revert to previous -> repeat -> revert to previous -> repeat :p
<popey> and i need to go 2 steps back
<didrocks> also, we need to ensure that in their testing story is going to cover this
<popey> well, i dunno if it lets me, and I dont want to revert once and be stuck on 350
<popey> yeah
<didrocks> yeah
<didrocks> mhr3: hey, not sure if you saw but upstart-app-launch doesn't depend anymore on zeitgeist itself but zeitgeist-core, do you think that will have any impact?
 * mhr3 checks
<mhr3> didrocks, nah, it's fine, zeitgeist is just a metapkg
<didrocks> mhr3: but python-zeitgeist
<didrocks> is removed now
<didrocks> from the imag
<didrocks> image*
<didrocks> as well as data-hub
<mhr3> yea, that's fine
<didrocks> http://people.canonical.com/~ogra/touch-image-stats/20140223.changes
<didrocks> mhr3: ^
<ogra> so looking at the topafter.log of the unity8 tests on the dashoard shows that neither pulse nor unity-system-compositor actually consume much resources
<ogra> they both run ... but with 0.5 to 0.8 CPU load only ...
<ogra> not a massive consumption
<didrocks> ogra: do we know why system settle is triggering then?
<didrocks> (as failure)
<ogra> systemsettle expects 97.5 % ... the overall load is at ~95
<ogra> we surely eat more, but not massively
<ogra> i think what we see with unity-system-compositor is the same we saw before ...
<ogra> (we had minor systemsettle issues since nested was involved, remember ? )
<ogra> now it seems pulse added iteslf to the issue which makes it fail every time
<didrocks> ok
<ogra> didrocks, image 199 http://ci.ubuntu.com/smokeng/trusty/touch/mako/199:20140221.1:20140115.1/6736/ubuntu_clock_app/808519/
<ogra> (clock app tests, settle_after failed)
<ogra> this looks pretty much the same
<ogra> just that it doesnt happen randomly but constantly now
<davmor2> Morning all
<ogra> (system-compositor and pulse keep it up in this test)
<didrocks> ogra: yeah, so overall CPU usage is higher still
<didrocks> hey davmor2
<ogra> didrocks, right, but the two processes keeping it up have been there before, seems we just passed a threshold now (so that each of them eats 0.1 more or whatever)
<ogra> aha
<ogra> https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/79/artifact/clientlogs/friends_app/topafter.log/*view*/
<ogra> there i see pulse constantly eating 2.9%
<ogra> towards the end
<ogra> thats definitely more than it should
<ogra> now if there was only a syslog to check ...  :(
<ogra> http://ci.ubuntu.com/smokeng/trusty/touch/mako/206:20140224:20140224/6796/friends_app/ doesnt have one
<didrocks> yeah
<didrocks> psivaa: can you provide us a syslog maybe?
<psivaa> didrocks: just a sec
<ogra> pulse errors should be in there
<didrocks> ogra: I wonder if pulse doesn't act up even more due to the issue on first call
<didrocks> meaning, if the 2 issues are mixed up
<ogra> well, does any test involve making an actual call ?
<ogra> i.e. one wheer audio is really involved
<didrocks> ogra: I don't know if audio is really involved when the mock test for phoning is used
 * ogra doubts it 
<davmor2> didrocks: so tomorrow on I'll be joining the morning all today was a bit of a meh day slept in getting back into a really timezone :)
<asac> do we have any "story" why those phablet-test-run failures happen on some APs, but not all?
<ogra> asac, we are still looking at system-settle
<ogra> most likely a pulse issue though
<asac> ogra: system settle?
<ogra> yeah, the tests all go mad over it
<asac> ogra: those look greenish on most: http://ci.ubuntu.com/smokeng/trusty/touch/mako/201:20140222:20140115.1/6756/ubuntu_clock_app/
<ogra> asac, 201 ... old stuff
<asac> ic
 * asac hits reload
<ogra> you want to start looking from 202 on where android 4.4 took over the world
<psivaa> ogra: didrocks: http://pastebin.ubuntu.com/6986465/ for the syslog
<didrocks> ogra: 203 actually, no?
<psivaa> hope it does not break the browser
<didrocks> psivaa: let's see :)
<ogra> didrocks, err, right
<asac> ogra: still see those phablet-test-run thingies on 202
<asac> http://ci.ubuntu.com/smokeng/trusty/touch/mako/202:20140222.1:20140115.1/6761/mediaplayer_app/
<didrocks> asac: yeah, not the first time there are those kind of issues
<didrocks> asac: paul told me he's rerunning and asking internally why there are those cases
<didrocks> (that was last week)
<didrocks> psivaa: ogra: no enough log spam to be convinced by pulseaudio
<asac> ic. 206 really is system settle infected
<ogra> didrocks, look for rtkit-daemon ... thats part of pulse
<didrocks> asac: yeah
<asac> but seems the phablet-test-run went away
<ogra> though i see a *ton* of NM spam as well
<didrocks> asac: see my email prep I pasted to you :)
<didrocks> ogra: NM is only at startup, though?
<ogra> eb 24 10:59:28 ubuntu-phablet pulseaudio[1972]: [alsa-sink-MultiMedia1 (*)] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write!
<ogra> Feb 24 10:59:28 ubuntu-phablet pulseaudio[1972]: [alsa-sink-MultiMedia1 (*)] alsa-sink.c: Most likely this is a bug in the ALSA driver '(null)'. Please report this issue to the ALSA developers.
<ogra> Feb 24 10:59:28 ubuntu-phablet pulseaudio[1972]: [alsa-sink-MultiMedia1 (*)] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
<didrocks> ogra: yeah, but see, it's only at every boot
<didrocks> then, nothing
<ogra> well but there seems to be something fishy
<didrocks> hard to believe it's what creating a crazy pulseaduio running
<didrocks> yeah, but it's not like spamming every second?
<ogra> i think what creates the crazyness are rather the rtkit bits
<ogra> why would it have to spam every second
<didrocks> yeah
<ogra> it is enough that pulse keeps busy
<didrocks> that one is a better lead
<didrocks> and +1 on NM
<didrocks> it's spamming every second as well
<ogra> hmm
<ogra> lots of apparmor DENIED's too
<ogra> filemanager tries to open /
<didrocks> notes-app and filemanager
<didrocks> so yeah, can be another issue
<didrocks> ah, and there is another one
<didrocks> Feb 24 06:59:14 ubuntu-phablet kernel: [   69.971310] type=1400 audit(1393225154.432:84): apparmor="DENIED" operation="open" parent=2851 profile="com.example.confined-basic_confined-basic_0.1" name="/dev/input/event0" pid=3516 comm="confined-basic" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0
<ogra> heh, yeah, definitely not related to pulse :)
<didrocks> but maybe that's the security tests?
<didrocks> Feb 24 07:04:30 ubuntu-phablet kernel: [  385.889912] type=1400 audit(1393225470.349:187): apparmor="DENIED" operation="open" parent=2851 profile="com.example.confined-basic_confined-basic_0.1" name="/etc/issue" pid=9955 comm="confined-basic" requested_mask="r" denied_mask="r" fsuid=32011 ouid=0
<didrocks> yeah, clearly security ones
<ogra> well, would be nice to know what PID 3516 actually was :P
<ogra> ah, k
<didrocks> so, let's add to the basket notes-app and filemanager making nasty things on the list to get fixed :p
<ogra> right, biut thats not the systemsettle issue
<ogra> (most likely)#
<sergiusens> com.example.confined-basic_confined-basic_0.1 is from no click app
<didrocks> I would be shocked if it was the case :p
<sergiusens> it's most likely a security test
<didrocks> yeah, that's what we came to
<didrocks> soâ¦
<didrocks> let's order
<ogra> Feb 24 06:48:49 ubuntu-phablet rtkit-daemon[2148]: message repeated 4 times: [ Failed to make thread 2245 RT: Operation not permitted]
<ogra> Feb 24 06:48:49 ubuntu-phablet rtkit-daemon[2148]: Failed to make thread 2260 RT: Operation not permitted
<didrocks> pulseaudio -> ftkit-daemon
<didrocks> and network-manager
<didrocks> seems the 2 that we need to look at
<sergiusens> ogra, the problem with filemanager and terminal is that for some reason it's confined now
<didrocks> sil2100: with us?
<sergiusens> they were supposed to be confined
<ev> alan_g and tsdgeos: I've filed tasks in Asana to track your issues.
<ogra> sergiusens, yeah, they are most likely not the cause for our systemsettle issues
 * sergiusens regrets handing keys over
<sil2100> didrocks: yes
<didrocks> sil2100: backloged, agreed with the diagnosis?
<sil2100> didrocks: those make sense, yes, should we poke upstream people regarding those?
<didrocks> sil2100: well, we don't have an official active maintainer for pulse
<didrocks> but yeah, for nm, it's cyphermox :)
<sil2100> Let's wake him up, YEAH! ;)
<sil2100> Just kidding
<didrocks> mup! ;)
<didrocks> do we know if diwic is still around?
<ogra> /mup sms cyphermox "wake up"
<ogra> :)
<didrocks> hehe
<ogra> he is, but in other areas
<asac> ftkit? fischertechnik API :) https://github.com/CodaFi/FTKit
<ogra> doing OEM stuff
<ogra> asac, lol
<ogra> asac, rtkit
<didrocks> I don't find him on IRC
<didrocks> ah
<asac> that makes more sense :)
<ogra> he isnt regulary on freenode anymore i think
<didrocks> he's not anywhere I can find him :/
<tsdgeos> ev: should i have got some kind of asana notification?
<ev> oops, adding you as a follower now
<didrocks> asac: do you kow of any other awesome pulseaudio god?
<sil2100> hm, he should normally be online
<alan_g> ev: thanks. FWIW I've now seen a "pass" this morning (followed by a "fail" - so it didn't just go away) https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/
<asac> didrocks: TheMuso maybe?
<sil2100> He doesn't seem to have holidays as well
<didrocks> asac: he's in AU timezone, not sure that will help us fixing it/debugging it now
<sil2100> didrocks: let's try e-mailing David - maybe he'll see the e-mail and pop up then
<ogra> and i doubt he does much phone/tablet stuff
<didrocks> ogra: yeah
<didrocks> sil2100: mind doing that, with the link to the pastebin?
<sil2100> didrocks: sure
<didrocks> thanks
<ogra> didrocks, rsalveti is also looking into the calls thing with pulse ... he said he'd handle that as high prio on the ML
<ogra> probably it is actually the same and saves our butt automatically :)
<didrocks> yeah, can be linked if there is a bad bandwidth between android <-> ubuntu through hybris
<didrocks> yeah
<didrocks> I hope os
<didrocks> so*
 * ogra too
<didrocks> we still need to look at the nm one
<ogra> well, NM is only reavily logging
<didrocks> then, only, when the system is a little lower, we can watch at actual test failures
<ogra> *heavily
<didrocks> yeah, maybe it impacts a little still though, even if it's not in top ps
<ogra> not sure there is an actual issue apart from it filling the disk
<didrocks> worth having a look I guess
<didrocks> while we are at it :)
<ogra> indeed
<didrocks> ok, at least music-app -> reverted (thanks popey!)
<ogra> yeah
<ogra> one less
<psivaa> didrocks: ogra: http://pastebin.ubuntu.com/6986534/ is the last bit of kern.log during a system settle run
<psivaa> rings any bell?
<ogra> psivaa, yep, just the general powermgmt noise and a bit of NM
<didrocks> yeah
<sil2100> psivaa: looks ok to me
<ogra> do you see anything unusal above that ?
<asac> sergiusens: do we have adding systemsettle as an option to phablet-test-run somewhere on our roadmap?
<psivaa> let me check
<sergiusens> asac, it wasn't requested; but I can; mandatory or optional with skip?
<ogra> sergiusens, optional please
<ogra> it eats a lot of time
<ogra> well, an option to switch it off ... should be on by default i guess
<sergiusens> ok
<asac> sergiusens: kind of with a flag --pre-landing-run
<asac> or something
<asac> :)
<asac> or indeed rather --quick
 * ogra wonders if there is simply a permission issue with the android 4.4 udev rules and pulse 
<sergiusens> ogra, the works once and not again?
<sergiusens> for phone calls that is
<ogra> sergiusens, the "pulse is constantly eating above 1% cpu since the switch"
<ogra> i guess the two are related though
<didrocks> ogra: not really, it was high as well before
<ogra> didrocks, over 1% ?
<psivaa> ogra: http://pastebin.ubuntu.com/6986572/ and the kernel log is roughly a repetition of http://pastebin.ubuntu.com/6986534/ during the systemsettle run
<didrocks> ogra: sometimes, not contantly
<didrocks> as the system settle after
<ogra> didrocks, right, not it is constantly at least 1% and bumping up to 5% during systemsettle
<didrocks> yeah
<ogra> s/not/now/
<ogra> and while ricardo added compltete udev rules for flo and hammerhead, the changes to the exoisting rules for existing devices were minor
<ogra> for mako actually only one for the rotation detection
<ogra>  * 70-mako.rules: changing default permission for msm_rotator, which is now
<ogra>     used by 4.4.2
<ogra> everything else stayed as is
<didrocks> yeah, I already looked at this
<ogra> my maguro doesnt look so bad on 206 btw ...
<ogra> (not that it matters, it still uses the old android indeed)
<didrocks> ahah :)
<didrocks> ogra's looking at his maguro with a tear :)
<ogra> not really
 * ogra would like to replace maguro with hammerhead :P
<didrocks> heh
<didrocks> btw, really likes the music used for the mwc demos
<didrocks> musics*
<Laney> is it the free software song?
<didrocks> I wonder, didn't look
<didrocks> ah
<didrocks> *the*
<didrocks> oh no :)
<didrocks> I told it IS nice ;)
<didrocks> that wouldn't match with rms voice :p
<Laney> :D
 * popey hugs his RMS soundboard app
<popey> http://popey.com/~alan/phablet/device-2014-02-06-171210.png
<popey> sergiusens: see last comment on bug https://bugs.launchpad.net/music-app/+bug/1284025
<ubot5> Ubuntu bug 1284025 in Ubuntu Music App "Music app 356 on mako image 206 doesn't play music launched from dash 1st time" [Medium,Confirmed]
<didrocks> popey: is it you putting on Linux UNplugged "Get it out of here" :)
<didrocks> or "Negative is the freedom dimension
<didrocks> "
<popey> i took those samples from LAS, yes
<didrocks> ahah :)
<didrocks> sergiusens: can you ensure this test case is part of upstream's manual test plan or that there is an integration test then?
<sergiusens> didrocks, the RMS stuff?
<didrocks> ahah, no :) the bug popey raised :)
<sergiusens> didrocks, well it was tested before it landed!
<didrocks> sergiusens: the first launch?
<didrocks> (music doesn't play on first launch, reverting making it work)
<popey> i have a fix in the works
<sergiusens> didrocks, I don't think so
<sergiusens> wrong item
<didrocks> sergiusens: yeah, so we need to get that case added on the integration tests or as part of manual tests running while releasing
<sergiusens> didrocks, ok, but I already have to write test plans for like 20 components; not sure I want to write the apps ones as well
 * sergiusens delegates to balloons 
<didrocks> sergiusens: I don't think you should be the one having to write those, ask upstream to help :)
<didrocks> just if you can track those are part of the release test plan so that we don't regress the same way again
<didrocks> (when they release the fixed version)
<psivaa> didrocks: http://pastebin.ubuntu.com/6986667/ is the content of /var/log/lightdm/unity-system-compositor.log
<psivaa> unity-system-compositor is also on the top most of the time. so curious if this shows anything
<ogra> delegation is the first step into management :)
<didrocks> psivaa: hum, yeah, I don't find anything really worrying in there, the unable to set active session does make sense on the destkop, not sure for touch tohugh
<ogra> psivaa, but unity-system-compositor was there before and usually stays below 1%
<didrocks> psivaa: we need to get some Mir guys on it
<didrocks> psivaa: can you join #ubuntu-mir?
<ogra> while pulse usually stays above 1%
<ogra> and even bumps pretty high in spikes
<psivaa> ogra: we are checking for 97.5 % idle time. so 1% is a lil high?
<ogra> psivaa, yes, and we had random issues with that since unity-system-compositor is uesd
<ogra> the pulse issue is new with andorid 4.4
<psivaa> ogra: ack, i removed pulseaudio and settling still fails. so was wondering
<didrocks> psivaa: removed?
<ogra> bug 1279391
<ubot5> bug 1279391 in Mir "[nested] inclusion of u-s-c as system comp not getting system load zero as quick as before" [Undecided,New] https://launchpad.net/bugs/1279391
<ogra> thats the bug for unity-system-compositor
<psivaa> didrocks: apt-get remove pulseaudio  ( although i dint know how stupid the attempt is :D)
<ogra> open since a while
<ogra> psivaa, heh, that will surely make some things go mad
<didrocks> psivaa: I guess you need to remove rtkit as well
<didrocks> as it's the package containing the crazy process :)
<didrocks> $ dpkg -S /usr/lib/rtkit/rtkit-daemon
<didrocks> rtkit: /usr/lib/rtkit/rtkit-daemon
<didrocks> psivaa: FYI ^
<ogra> chmod -x :P
<didrocks> you, evil guys! :)
<psivaa> ogra: removing pulse dint cause a lot of issues, at least in weather app test
<psivaa> didrocks: rtkit message was seen before as well and i checked with kernel team a couple of weeks ago and they said it was not changed for a long time
<didrocks> psivaa: yeah, but maybe an interaction with 4.4?
<psivaa> didrocks: http://ci.ubuntu.com/smokeng/trusty/touch/mako/172:20140209:20140115.1/6518/dialer_app/754252/ is with image 172 containing the similar message as the syslog for 206.
<psivaa> but this time with android interaction this could cause settling issues
<psivaa> i.e. in relation to rtkit
<didrocks> psivaa: yeah, anyway, we need to get those messages fixed as it's always harder to read with those, wdyt?
<ogra> didrocks, dont bother ... i will at some point kill all kernel logging
<ogra> since it fills the disk
<psivaa> didrocks: agreed. lots of warnings and it's hard to find the message that actually causes the issue
<sil2100> didrocks: so, just in case, diwic is e-mail-reachable, so we can poke him to help us as well
<didrocks> ogra: hem, issue "fixed"? :p
<sil2100> didrocks: he's looking at it as well
<didrocks> sil2100: oh, excellent! :)
<ogra> didrocks, kind of :P
<didrocks> sil2100: thanks man
<ogra> didrocks, point is that we are doing way to excessive logging for end users
<ogra> it eats your disk quickly
<didrocks> ogra: yeah, but we need a way to still get those infos when things go wrong
<didrocks> developer mode? :p
<sil2100> ogra: if anything, we CC'd you as well, so if you have any useful pointers or info that I missed, just give diwic a sign ;)
<ogra> didrocks, or dmesg ...
<ogra> but thats a ring buffer that overwrites itself
<didrocks> yeah
<ogra> i was talking to apw about the excessive logging ... but i didnt get to provide him the needed logs yet
<ogra> he wanted to look into it ... seems that it is mainly powermanagement android drivers that dont respect kernel log settings
<didrocks> ah, yeah, more than possible :)
<didrocks> ogra: sorry for the stupid question, but as we run on our own kernel, we do have a kernel version matching the one from android 4.4? What's the package containing our kernel?
<ogra> linux-image-$arch
<ogra> as usual
<ogra> linux-image-mako for N4
<ogra> or linux-image-$version-mako rather
<ogra> (just search for mako on the -changes ML (or flo, maguro, manta)
<didrocks> ogra: ah ok, and so, we choose a version of the kernel matching the android one for ABI compatibility, right?
<ogra> the kernel source comes from android
<ogra> we just package it
<ogra> (and patch it for i.e. apparmor etc)
<didrocks> ah ok, I thought we got our own ubuntu kernel running
<didrocks> hence my "I was puzzled"
<didrocks> thanks to have shed some lights ogra
<ogra> no the android blobs expect the right kernel
<ogra> so we need to use this one
<didrocks> yeah, I was wondering how magical this was for us to use anothe kernel
<didrocks> but ok, there is no magic :p
<sil2100> I jump out to the vet for a moment (just for the periodical a shot), be back in a jiffy
<dbarth> hi
<dbarth> i had a question this morning: can i have 2 merge props, one being stacked on top of the other, in a silo config?
<dbarth> or do they need to be all MPs targetting bzr trunks?
<ralsina_> sil2100: can I get a reconfigure in silo 14? Added a branch in the spreadsheet
<ralsina_> dbarth: I usually have stacked branches in the silo and it seems to work nicely as long as prereq brnches are set in the proposals
<jdstrand_> didrocks, sergiusens: those are absolutely from the security tests
<didrocks> jdstrand_: excellent, thanks for confirming
<didrocks> dbarth: you need all targetting the same branch (this is a sanity check to ensure that some doesn't get in a raring branch and the rest in a trusty branch)
<didrocks> and yeah, what ralsina_ told
<dbarth> ok, clear, that should work then
<dbarth> btw, the ci train spreadsheet is read-only for me this morning, is that normal?
<didrocks> dbarth: shouldn't, did you try to refresh?
<didrocks> ralsina_: done
<ralsina_> didrocks: awesome, thanks
<didrocks> yw
<dbarth> ok works
<xnox> didrocks: with click apps, commits into trunks are merged by humans, and then click packages are released elsehow?
<xnox> didrocks: or who do i talk to about coreapp click releases?
<psivaa> ogra: didrocks: i also noticed 'top' is taking more than 2.3%
<didrocks> xnox: stgraber defined the procedure, so yeah, commits are done manually in trunk and then, we have a release in another branch
<didrocks> psivaa: oh waow
<psivaa> didrocks: yea, that's pretty persistent
<psivaa> and while me running another top during the test run doubles it :)
<xnox> didrocks: and debian/changelog? do i write useful things there for coreapps?
<xnox> didrocks: or where can i read the "procedure" ?
<didrocks> xnox: not sure if Stephane wrote the procedure anywhere
<didrocks> ask him about it :)
<didrocks> psivaa: indeedâ¦ nice catch!
<didrocks> psivaa: so next stopâ¦ kernel guys?
<psivaa> didrocks: yep, exactly what i was typing :)
<ogra> xnox, popey and sergiusens usually handle the landing of core apps
<didrocks> xnox: you are talking about click itself, right?
<didrocks> not core apps
<xnox> didrocks: no, i'm not talking about lp:click, i'm talking about e.g. lp:ubuntu-*-app
<popey> depends which app
<didrocks> xnox: ah ok, so sergiusens :)
<xnox> popey: but do humans merge things into trunk? or is that "ci-train"/automerger managed stuff?
<ogra> popey, messaging
<popey> ah, not my department then
<didrocks> xnox: there is no ci-train/automerger yet
<ogra> i think messaging-app actually needs to go through bfillers team first
<ogra> for the actual merge
<didrocks> yeah, for those shipped in distro, it's different
<didrocks> (as .debs)
<ogra> the landing is then via sergiusens' scripts
<ogra> didrocks, hmm, isnt is a click ?
 * ogra thought it was
<didrocks> ogra: it is, but it's duplicated as .debs and as click
<popey> ii  messaging-app  0.1+14.04.20 armhf        messaging application for Ubuntu
 * ogra checks 
<ogra> yeah, same here
<didrocks> right
<didrocks> so deb and click
<ogra> right
<didrocks> I don't like having that, because it's not an easy mapping
<ogra> i wonder why we do that
<popey> not a click yet on device, or it would be in /usr/share/click/preinstalled
<ogra> click should be fine
<popey> (which it isnt)
<didrocks> ogra: because until click run on the desktop, bill wants to be able to install them as .deb
<ogra> k
<ogra> up to him i guess
<sergiusens> xnox, what do you want?
<xnox> sergiusens: how are core-click-apps released? e.g. am I fine to merge things into trunk  (those that are ready to go)
<xnox> sergiusens: and then something/somewhere/eventually will generate a new click et.al.
<didrocks> ogra: do you know with session upstart if I can add some env variable with sudo start <env var=foo> <process>?
<sergiusens> xnox, merge to trunk then there's this http://s-jenkins.ubuntu-ci:8080/view/click/ which builds them from trunk
<sil2100> Back
<xnox> sergiusens: excellent. and when do those end up on the image? cause e.g. calculator is out of date.
<xnox> (and 219 is not on p.c.c./~u-a/click_packages)
<sergiusens> xnox, it gets uploaded to the store by balloons or myself
<ogra> didrocks, usc-wrapper
<ogra> (thats a script)
<xnox> sergiusens: oh, the store. ack.
<didrocks> ogra: $ usc-wrapper
<didrocks> -bash: usc-wrapper: command not found
<sergiusens> xnox, yeah; the store; there's no general user id's but if you behave we can work out oauth credentials
<sergiusens> :-)
<xnox> sergiusens: hm... tempting. I'd rather just poke you and balloons to e.g.
<xnox> sergiusens: balloons: please upload new calculator into the store =)
<sergiusens> fginther, btw; are we going to have click testing on those click builds with a mako at least?
<ogra> didrocks, /usr/share/ubuntu-touch-session/usc-wrapper
<ogra> didrocks, though thats not the session ... thats actually system wide
<didrocks> yeah
<ogra> didrocks, for the session i'd take the unity8 upstart job
<didrocks> and just add the env var here?
<ogra> yeah
<sil2100> ralsina_: reconfigure still needed?
<ralsina_> sil2100: no, didrocks did it, thanks
<Laney> sil2100: can you reconfigure silo 010 (line 13) for me please? I added a new branch
<didrocks> ogra: ok, hacked the unity8 upstart job, seems to be the only way
<ogra> there are other ways, but yeah, thats the best
<didrocks> interesting, can't get unity8 to show off though
<didrocks> let's reboot
<xnox> didrocks: did i gather it correct, that messaging-app is, at the moment, under ci-train?
<didrocks> xnox: yeah
<xnox> didrocks: can i be trained as an add-hoc lander then? i'd like to be able to ci-train release, all the things i can commit to.
<didrocks> xnox: check with asac if there are more slots, we are quite full in term of rampining up in term of capacity, but let's see what he thinks if we should have one more session
<rsalveti> morning
<didrocks> xnox: until then, you can use the messaging-app lander to add your request to their landing (they should do that themselves if you add a MP)
<didrocks> hey rsalveti!
<sil2100> Laney: sure
<xnox> didrocks: and how do i find out who the landers are?
<xnox> didrocks: cause it's been 20 days now, which in my head is the timeout to do direct dput into the archive.
<didrocks> xnox: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdC05a2ZQSmgwU2NFYnJQOE9qMDRYa3c&usp=drive_web#gid=1
<didrocks> xnox: well, ping on IRC the lander I guess :)
<didrocks> where is your branch?
<xnox> didrocks: none of the listed people work 24/7 all year around, it's a single point of failure, both timezone wise, and vacation/holiday/sprints/travel wise.
<rsalveti> ogra: hm, a lot of settle_before
<didrocks> xnox: you can use other landers, as it works well for now, they have backup
<ogra> rsalveti, and after
<didrocks> xnox: then, the landers are coordinating themselves
<ogra> rsalveti, pulse seems CPU greedy
<rsalveti> ogra: is pulse the bad guy here?
<rsalveti> interesting
<ogra> rsalveti, and i see some alsa pulse errors in syslog
<xnox> didrocks: right, so which line is for messaging-app there? =)))))
<didrocks> rsalveti: it was already quite high sometimes in the past
<rsalveti> right
<xnox> didrocks: i'm sorry but like i have no idea what team that's under or what e.g. OLS is.
<didrocks> but it's even higher
<ogra> rsalveti, also unity-system-compositor ... but that was bad since we switched to nested
<xnox> didrocks: team apps i guess?
<rsalveti> indeed
<asac> right
<asac> its not our fault if the lander doesnt land your stuff
<asac> :)
<ogra> and didnt degrade
<didrocks> xnox: hum, did you ctrnl + F "messaging-app"?
<Laney> sil2100: what's that failure about?
<didrocks> xnox: in the link I pasted to you
 * didrocks finds
<xnox> didrocks: oh, it opened landers tab for me, due to 2fa auth
<asac> we will ramp up more folks, once the current folks have settled and everything goes smoothly. i believe its a couple weeks until thats the case
<didrocks> messaging-app bfiller Yes https://wiki.ubuntu.com/Process/Merges/Checklists/system-apps https://wiki.ubuntu.com/Process/Merges/TestPlan/messaging-app
<Laney> is the rebuild going to rebuild all of the components?
<didrocks> xnox: argh ;)
<Laney> because I only added one new branch for u-s-s so the others should be fine
<didrocks> Laney: you have an option for only rebuilding one source
<Laney> cool
<didrocks> (check in the build and tell me if it's not obvious)
<Laney> PREPARE_ONLY?
<didrocks> yep :)
<Laney> the name isn't obvious but the description is alright
<xnox> didrocks: i giggle at the requirements in light of my branch =)
<didrocks> Laney: can be renamed, opened to any pointters
<Laney> PACKAGES_TO_BUILD :-)
<didrocks> Laney: it's only the MP
<didrocks> not the sources
<Laney> it says 'enter the source package names'
<didrocks> so needs to be clear in the name we only prepare things ;)
<sil2100> Laney: done ;)
<didrocks> Laney: yeah, but it doesn't changes the "direct upload to ppa"
<didrocks> PACKAGES_TO_BUILD can let you think that direct upload to ppa will be rebuilt, no?
<Laney> it doesn't say anything about that currently either
<Laney> unless you know what 'prepare' means?
<didrocks> Laney: prepare is about preparing source packages from MPs
<didrocks> Laney: just give me a name and a description and I can change that easily :)
<didrocks> (I would rather use _REBUILD than _BUILD though)
<Laney> do you error out if it's used the first time?
<didrocks> yeah
<Laney> ok
<rsalveti> didrocks: ogra: we have some tests using audio as well
<dbarth> sil2100: can i get a last reconfig on silo 005 please?
<ogra> rsalveti, actual audio or fake stuff
<rsalveti> ogra: these alsa messages are expected, also happen with 4.2.2
<ogra> i.e. does something actually play/record
<dbarth> line 1 of the spreadsheet
<ogra> rsalveti, ok
<Laney> Enter source package names separated by spaces. A new build will be submitted to this silo containing all merge proposals attached to this landing request. It is an error to specify a source package name that has no merge proposals listed here. (leave blank for all)
<didrocks> rsalveti: diwic has been pinged FYI and looking as well
<Laney> s/to this landing request/to this landing request for the given packages/
<sil2100> dbarth: sure
<didrocks> Laney: ok, and so PACKAGES_TO_REBUILD as the flag name?
<Laney> if that works for you
<didrocks> sure
<didrocks> I need to change some error message though
<didrocks> as I'm talking about "prepare"
<Laney> in this case I think the packages could have been detected
<Laney> u-s-s had a new MP added and none of the others changed
<seb128> could somebody give me a silo for l28?
<didrocks> Laney: well, explicit is always better than implicit
<didrocks> Laney: happened a lot like "I click rebuild opssss"
<sil2100> dbarth: could you modify the MP list to include only links to merge proposals? ;)
<Laney> I don't know about that
<Laney> you could get more explicit than this :P
<didrocks> Laney: well, if you click "build" without any other parameter after one full build was successful, it will error out as well
<didrocks> what kgunn saw btw
<ogra> rsalveti, in the before logs i see ofono phonesim everywhere
<Laney> okay, it's minor so I don't want to push it :-)
<sil2100> dbarth: I see that there's one merge request that's targetting some other branch, not trunk
<rsalveti> ogra: real audio
<rsalveti> ogra: I was surprised when testing as it started to produce noises :-)
<ogra> rsalveti, looking at image 196 it doesnt seem to show that often
<ogra> haha
<ogra> i never heard noises ... thats why i'm so surprised
<rsalveti> psivaa: ogra: how can I easily reproduce the systemsettle test?
<ogra> rsalveti, top -c -b -d 6 -n 5
<ogra> run that ten times in a loop
<sil2100> dbarth: all the merges should target trunk if they are to be released ;)
<ogra> rsalveti, and take the average idle time out of it
<ogra> hmm
<ogra> not so easy to capture it
<rsalveti> didrocks: where did you ping diwic?
<sil2100> dbarth: you can either re-target it to trunk or take that branch and merge it manually to that target branch
<ogra> rsalveti, per mail
<ogra> rsalveti, sil2100 did with me on CC
<rsalveti> oh, mind including me as well?
<didrocks> rsalveti: sil2100 sent an email
<Laney> sil2100: sorry, forgot to say thanks - thanks ;-)
<ogra> rsalveti, top -c -b -d 6 -n 5 | grep id,
<ogra> that works for me
<rsalveti> alright, let me flash 206 from scratch again
<dbarth> sil2100: ok, hang on
<ogra> http://paste.ubuntu.com/6987137/
<ogra> thats an idling flo
<rsalveti> ogra: hm, not that good
<rsalveti> how many seconds do we wait before getting that data?
<ogra> (and btw i still cant reproduce the runlevel thing with lightdm here ... i trired on all devices)
<rsalveti> sergiusens: would you mind taking a look at the camera issue as well?
<ogra> not sure
<ogra> rsalveti, i think psivaa or plars should know
<didrocks> Laney: done, will be deployed next time we deploy code :) http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/517
<sergiusens> rsalveti, the one photo freeze issue?
 * sergiusens hopes it wasn't mako
<ogra> what else :P
<psivaa> rsalveti: so that's 6 seconds
<sergiusens> ogra, mako is my personal device :)
<sergiusens> ogra, if phone calls worked it would of been fine :-P
<ogra> sergiusens, mine too, thats why i refuse to do any testing on it
<ogra> it only runs promoted images
<ogra> (well, i tested the bootspeed changes manually i have to admit)
<rsalveti> sergiusens: well, I wasn't able to reproduce the phone call issue anymore, but will test more later today
 * sergiusens flash 206 on mako
<rsalveti> sergiusens: maybe check the autopilot failures with flo
<rsalveti> sergiusens: the camera one
<sergiusens> oh right
<sergiusens> rsalveti, flo has the same issues?
<sergiusens> rsalveti, I'll check click camera and autopilot
<rsalveti> sergiusens: not same
<seb128> hum
<ogra> flo works fine
<seb128> is there anyone giving silos today? ;-)
<ogra> i just took ten pics in a row with each camersa
<rsalveti> ogra: autopilot fails from time to time
 * seb128 would like to get one for l28
<ogra> rsalveti, ah, i thought freezes
<seb128> I've another landing I want to do later than relies on that first to go through
 * seb128 would like to get things rolling a bit
<rsalveti> ogra: why do we have phonesim running all the time as well?
<ogra> rsalveti, no idea
<ogra> it should settle down after initializing the sim, no ?
<rsalveti> https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/85/artifact/clientlogs/friends_app/topafter.log/*view*/
<rsalveti> https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/85/artifact/clientlogs/friends_app/topbefore.log/*view*/
<rsalveti> pulse is not even there
<ogra> yeah, not in this one
<rsalveti> but phonesim is going crazy
<ogra> the ones we looked at during the meeting all showed pulse and u-s-c
 * seb128 waves
<ogra> but u-s-c was like that before
<ogra> pulse wasnt
<seb128> is there anyone reading me?
<rsalveti> seb128: yes
<plars> rsalveti: what are you looking for? time between running the test and systemsettle?
 * ogra wonders what that noise between his lines is
<ogra> :P
<seb128> rsalveti, thanks
<seb128> what do one has to do to get a silo here? ;-)
<ogra> seb128, pompoms and miniskirt help ...
<rsalveti> plars: just trying to understand what is causing the systemsettle test to fail
<ogra> and waving your arms
 * seb128 waves
 * seb128 waves
 * seb128 waves
<ogra> lol
<seb128> sorry but I'm getting annoyed
<ogra> didrocks, ^^^
<seb128> I've work to land and there is no way to get any traction
<seb128> I'm close to just dput manually
<ogra> give that frenchie a silo !
<didrocks> ogra: isn't sil2100 giving silos now? :)
<sil2100> Silo? Can I assign?
<seb128> sil2100, yes please, l28
<rsalveti> ogra: wonder if pulse is crashing now with 4.4.2
<seb128> I've waited a few hours before starting nagging
<seb128> but since things didn't seem to move...
<seb128> sil2100, thanks
<rsalveti> ogra: as it's not even around for friends-app
<sil2100> Ok, so if didrocks gave me the blessing, let me assign
<ogra> rsalveti, we checked syslog of one test that exposed it ... pulse wasnt restarting
<rsalveti> crash would make it restart, and consume cpu
<didrocks> sil2100: why wouldn't I give you the blessing?
<rsalveti> ogra: but then why is it not even there for friends-app?
<ogra> rsalveti, good question
<plars> rsalveti: it actually looks like top is the big consumer from the logs, but iirc we somehow filtered that one out for the calculations. Even without it, it looks like there are a few other things eating up enough that the sum would push it over the edge perhaps. Looking at my local mako which I installed 206 on last night, it has pulseaudio holding a steady 2.6% of the cpu and has been idle since it first booted
<ogra> plars, i still dont agree to that claim
<ogra> (top being the big consumer)
<rsalveti> ogra: also, it there a way to just promote 206 for flo? so we can have at least one image in trusty for it
<ogra> top spikes to 36% like it did  before
<ogra> two or three times in a run
<rsalveti> plars: cool, will investigate pulse here
<ogra> but is tame the rest of the time
<ogra> rsalveti, i cant just promote an image ...
<ogra> needs landing team approval
<rsalveti> ogra: the udev files didn't change
<ogra> i can bring it up in the landing meeting
<ogra> rsalveti, yes, i was wondering if we are probably missing a change on mako or some such
<rsalveti> ogra: sure, just because there's no CI for it still, and only in trusty-proposed
<ogra> right
<ogra> it looks fine for me in manual smoketesting
<rsalveti> right, that's why my request :-)
<didrocks> I think that makes sense
<rsalveti> so people can flash at least 206, until we're able to promote a new one for it
<dbarth> sil2100: landing-001 is good to go (publish)
<ogra> they can ... when using the proposed channel
<dbarth> sil2100: but still stuck with 005 for now
<ogra> didrocks, so should i do a singlle promotion just for flo ?
<rsalveti> ogra: right, but it'd just be better (mwc for example), for people to use trusty instead
<ogra> (if you say it makes sense)
<didrocks> sil2100: so, I saw that you assigned a silo, but you know it's because it's desktop-only, right?
<didrocks> ogra: +1
<rsalveti> and wait for a better update, instead of always getting trusty-proposed automatically
<ogra> didrocks, rsalveti, promoting then
<rsalveti> awesome, thanks
<ogra> rsalveti, what about generic
<ogra> could need promotion too i guess
<ogra> same siatuation here
<rsalveti> ogra: yeah, that would need as well indeed
<ogra> let me do that one too then
<rsalveti> is generic finally published there as well?
<ogra> didrocks, ^^^^
<ogra> rsalveti, stepahne added it yesterday
<rsalveti> great
<didrocks> ogra: sure :)
<xnox> rsalveti: is generic -> x86 or armhf?
<rsalveti> xnox: armhf
<xnox> rsalveti: excellent!
<rsalveti> generic_x86 would be x86 :-)
<rsalveti> but still need the androideabi compiler
<xnox> rsalveti: ack, thanks for letting me know.
<sil2100> didrocks: righto, I'm not publishing anyway for now (maybe if it's desktop only, maybe then)
<rsalveti> np :-)
<xnox> rsalveti: yeah, i don't have it for you yet =) will get it done as soon as I can.
<rsalveti> no worries
<ogra> === Image 206 Promoted on flo and generic arches ===
<popey> oooh
<sil2100> Damn, my girlfriends grandparents are here for a visit and they're successfully decreasing my productivity ;p
<ogra> sil2100, give them ubuntu touch devices to play with :P
<xnox> sil2100: by trolling behind your back?! =)
<popey> s/play with/bug hunt/
<ogra> (thats the secret plan)
<ogra> :)
<rsalveti> ogra: you're using 4.2.2 still, right?
<ogra> rsalveti, on mako
<rsalveti> ogra: how much is pulse consuming there in idle?
<rsalveti> it's always ~1.0 here (4.4)
<fginther> sergiusens, It can be done, but it wasn't on our list of projects
<didrocks> rsalveti: yeah, that's what we saw
<fginther> didrocks, is http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/ still be used?
<sergiusens> fginther, but I asked you during the sprint :-)
<ogra> rsalveti, not in toop at all
<didrocks> fginther: as long as not everything is moved to CI train, yeah
 * ogra does a fresh boot
<rsalveti> ogra: right, but just check with ps
<fginther> sergiusens, I misunderstood, this morning you're talking about the core apps, right?
<sergiusens> fginther, talking about http://s-jenkins.ubuntu-ci:8080/view/click/
<ogra> <apw> psivaa-afk-bbl, ogra, ok this is accounted for by a change to what is reported in /proc/stat (which is consumed by top)
<ogra> <ogra> aha
<ogra> <apw> basically when the machine is idle, cpus are turned off complely, in the previous kernel the offline cpus counted as 100% idle, now the do not
<ogra> didrocks, psivaa-afk-bbl plars rsalveti ^^^
<ogra> there we got our issue
<rsalveti> oh
<didrocks> oh
<davmor2> rsalveti: phablet   1885  0.5  0.2  97840  4008 ?        S<l  14:17   0:06 pulseaudio --start --log-target=syslog  n4 with mwc image on which is 4.4.2 based I believe
<didrocks> ogra: turned off completely, not downscaled though? (so why do we have random values?)
<ogra> davmor2, mwc is 4.4
<fginther> sergiusens, ah, I just misunderstood then. Yes, that click testing is in plan.
<sergiusens> great
<plars> ogra: so is that causing top to report values we can't necessarily trust for all processes then?
<ogra> didrocks, because 100% is defined differently now
<ogra> plars, well, the consumption should still be fine
<ogra> plars, the idle value wont
<sil2100> uh
<didrocks> ogra: ah, so basically, we can have just one core up, and that will be our global rate
<ogra> rsalveti, phablet   1446  1.0  0.2  99628  3896 ?        S<l  15:37   0:02 pulseaudio --start --log-target=syslog
<dbarth> sil2100: and i have an extra reques with silo-013 being stuck (it didn't build the cordova-cli package)
<ogra> lokskk fine to me
<dbarth> sil2100: but getting silo-001 landed is still my priority right now
<ogra> didrocks, well, idle isnt 4*100/100 anymore but the average idle time of the running CPUs
<ogra> only measured while they were online
<didrocks> ogra: yeah, I was telling the same thing :)
<didrocks> ok, so basically we do have "no issue"
<plars> I see
<ogra> didrocks, we do
<didrocks> hum, why?
<ogra> our test is crap
<didrocks> yeah
<didrocks> but I meant no issue on the image
<ogra> it should use /proc/stat ...
<rsalveti> lol
<didrocks> yeah
<rsalveti> crap
<ogra> (not top which eats resources itself)
<ogra> and it would need to take the new setup into account
<ogra> no idea how to every get that reliable though
<didrocks> so
<ogra> *ever
<apw> ogra, ok we have confirmed between my antient image and colin's updated one that the stats behave different
<ogra> apw, yeah, you guys rock
<ogra> thanks so much !!!
<rsalveti> yeah, thanks :-)
<rsalveti> was already typing gdb -p `pidof pulseaudio`
<didrocks> sil2100: plars: psivaa-afk-bbl: as the image is behaving as we expect, can you look at every AP test results and note here those which fails + look at them?
<ogra> there were like ten people burning half a day on it already
<didrocks> plars: also, it seems phablet-test-run didn't start on things like dialer-app, any idea why?
<didrocks> asac: another occurence btw ^
<ogra> didrocks, so lets have upstream fix the systemsettle test ...
<ogra> asac, Â°
<ogra> asac, !
<didrocks> ogra: but some tests didn't run and we need to know what tests failed
<didrocks> liek weather-app for instance :)
<ogra> didrocks, right, i would like to get the dirt off the dashboard though
<rsalveti> yeah
<ogra> we should disable systemsettle for now
<didrocks> ogra: let's try to work on both in parallel
<ogra> so it doesnt taint results on next run
<plars> didrocks: it looks like the unlocker failed before dialer_app
<rsalveti> sil2100: didrocks: ogra: mind also replying back to diwic? (and including me as well)
<didrocks> plars: anyway to have it reported differently?
<ogra> rsalveti, yeah, will do ... he isnt around today anyway
<ogra> not super urgent
<didrocks> rsalveti: I'm not in that email, sil2100 didn't include me :/
<didrocks> thanks ogra
<ogra> only cool people were included :)
<ogra> like sil2100 and me :)
<didrocks> tsss :p
 * asac tries to figure whats up
<rsalveti> hahah
<didrocks> plars: not sure what that "daily" test is as well
<ogra> asac, systemsettle doesnt (cant) work anymore
<ogra> asac, the stats changed ... idle isnt idle anymore
<didrocks> unity8 has 5 failures though
<plars> didrocks: yeah, something confused the dashboard with that one. Not sure yet - there's a *LOT* to look at this morning
<asac> ogra: dont get it. what is idle?
<didrocks> plars: ok, please us posted please :)
<asac> if its not idle
<plars> will do
<rsalveti> asac: before it was idle with 4 cpus, now it's idle with only 1
<ogra> asac, before all CPUs were on, so idle was 100%*4 ...
<davmor2> ogra: try installing saidar
<rsalveti> so the rate changed, yeah
<ogra> asac, now with the new kernel cores get shot down
<sil2100> ;p
<ogra> asac, so there isnt a reliable 100% value anymore
<sil2100> It was David who included ogra in the e-mail!
<asac> ogra: kernel cores get shot down? when?
<ogra> asac, you just get idle values from the other cores while they are running
<rsalveti> asac: kernel itself is doing that
<ogra> asac, all the time they are not in use
<ogra> the kernel shuts them down dynamically
<sil2100> Damn, finally some peace
<rsalveti> let me manually run the unity8 tests
<davmor2> ogra, rsalveti, didrocks: http://paste.ubuntu.com/6987322/
<ogra> davmor2, another tool wont help the issue
<ogra> the kernel interface wont report reliable 100% anymore
<ogra> userspace tools only hook into that interface
<rsalveti> still don't get why phonesim is consuming that much cpu
<ogra> yeah
<rsalveti> let me run the dialer-app tests
<davmor2> ogra: ah sorry I just read the comment on top and switched off after that :)
<asac> sounds like an odd story
<ogra> rsalveti, note that for some tests there is a reboot ... you might see it not settled after rebooting in the ones where it is in top-before
<rsalveti> ogra: oh, ok
<ogra> asac, sounds perfectly valuable for the issue we see
<asac> where is the systemsettle test?
<asac> i mean the code :)
<ogra> somewhere buried in UTAH ?
<davmor2> ogra: did the new content handlers land? could it be that they are keeping the system from 100% idle?
<ogra> you should know, you wrote it
<asac> https://code.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch
<asac> ogra: it was taken and integrated somewhere
<ogra> davmor2, then we would see them
<asac> found it
<asac> :L)
<ogra> :)
<plars> balloons: when you get a sec, could you help look at some of the ap failures and see if anything jumps out at you? I'm going to kick off one in just a moment where the unlocker just failed it seems, but some of these are just one or two ap test failures
<ogra> asac, it should use /proc/stat directly anyway to not taint the results with top stuff
<ogra> the prob is though that we cant rely on the idle value anymore ... no matter which interface we use
<rsalveti> right
<ogra> so we should measure the other way round i think
<ogra> load above ... instead of idle above ...
<rsalveti> hm, got a dialer-app crash as well
<ogra> a .crash file you mean ?
<rsalveti> bfiller: ^ is this known?
<rsalveti> ogra: yes
<ogra> we have that since months
<ogra> known
<rsalveti> alright then
<ogra> the tests should pass though
<rsalveti> oh, and the annoying mir freeze
<bfiller> rsalveti: yup, mir bug
<rsalveti> kgunn: we need to land the mir freeze fix in the archive as well asap
<rsalveti> bfiller: got it
<ogra> keep it :P
<rsalveti> oh, unity8 crashed now
<ogra> we dont want it
<didrocks> rsalveti: yeah, some tests failed, I wonder if a crash or hang is the cause
<rsalveti> that's why, freeze is just apport taking all the cpu
<kgunn> rsalveti: dialer app crash is a bug in unity-mir that we are trying to land a fix for
<ogra> sigh
<ogra> apport
<rsalveti> kgunn: not that one, it hangs from time to time when using it
<rsalveti> let me get a trace for this guy
<asac> so i dont get why we get 95% idle if the idle value isnt right anymore... sounds too close to be wrong. i can understand that the idle is a bit lower if we end up having just one core on though. is that what you try to say?
<ogra> asac, no, before all cores were constantly on
<ogra> asac, so idle was 4*100% / 4
<ogra> asac, now it is 1 * 100% ... plus the random idle values of cores when they are up
<ogra> you cant divide cleanly by four anymore
<ogra> you would have to take the time they were online into account
<rsalveti> yeah
<rsalveti> another reason why top is not the right tool
<ogra> well, we should just not measure idle but consumption
<ogra> and not use top as it is a userspace process that consumes resources itself
<rsalveti> ogra: oh!
<ogra> (though even reading from /proc/stat will eat resources for the reading)
<asac> you mean we should use absolute cycles consumed rather than a percentage
<rsalveti> ogra: one reason pulse is waking up a lot more now
<asac> consumption in percent probably woul dhave the same issue
<rsalveti> ogra: it gets all the cpu on/off uevents
<rsalveti> which is happening all the time now
<asac> so what we could do is force off cpus during systemsettle
<ogra> asac, no, the total of system, user and nice and set an upper threshold
<ogra> rsalveti, awwww
<ogra> asac, i.e. measure the actual consumption
<ogra> instead of watching idle
<rsalveti> right, idle is relative now
<asac> i still believe it would have similar issues
<asac> %Cpu(s): 2.6 us, 3.1 sy, 0.0 ni, 94.2 id, 0.2 wa, 0.0 hi, 0.0 si, 0.0 st
<asac> that sums up to 100
<rsalveti> ogra: http://paste.ubuntu.com/6987394/
<ogra> oh man
<ogra> whatever we do, we need to kill the logging in any case !
<ogra> (or is that debug mode)
<rsalveti> ogra: the log is not there by default, I just added (debug mode)
<rsalveti> just showing that pulse is getting every single cpu event
<ogra> asac, yes, thats a snapshot
<ogra> asac, we take 10*5 snaphots over a ceratin amount of time
<rsalveti> ogra: and the battery ones as well
<ogra> asac, that wont sum up to 100 anymore as cores come and go
<asac> ogra: show me a sample where it doesnt sum up
<asac> in the log
<ogra> asac, dunno, its just logical, i dont need logs for that
<asac> heh
<asac> i dont think its logical.
<asac> i can see how the percent values are having a variety
<ogra> your 100% vary as the resources underneath vary
<asac> based on how many cores are on and off
<asac> but its still right
<plars> as I understand it, an offline cpu is no longer considered idle (due to the fact that it's simply off, rather than doing nothing)
<asac> sure
<asac> but doesnt mean the idle is wrong :)
<ogra> plars, right
<ogra> the sum is
<asac> it just gets magnified by factor 4
<ogra> no
<asac> in case of 1 cpu only
<ogra> you cant mgnify by 4 if the 4 isnt a constant
<plars> so yes, logically it makes no sense - an offline cpu is about as idle as you get. But for accounting purposes, it's not factored in
<ogra> right
<asac> ogra: well, its getting magnified between 1 and 4
<asac> and we dont know what it is exactly
<ogra> asac, yes, and the 100% between now and in 1min are completely different to the 100% beween in 5 min and 6min
<ogra> the 100% dont change, the factor does though
<asac> i undefrstand it, but still the usage will have the same issue :)
<ogra> which will give you an unreliable value
<asac> which is the only thing i am questioning
<asac> i am not questioning that we get awful variance due to CPUs on and off right now
<ogra> the usage of processes in sum will stay reliable
<ogra> you have to rip out the CPU values here
<rsalveti> ogra: something is waking up pulse all the time http://paste.ubuntu.com/6987416/, but it might just be because we're getting way more events now
<ogra> and sum the processes
<rsalveti> will check
<ogra> rsalveti, can we perhaps switch off threading ?
<ogra> so it sticks to the first core
<ogra> i bet there is a config option
<rsalveti> not sure if that is the issue, let me take a look first
<apw> asac, it does mean idle is wrong, the idle stats for non-online cpus do not accumulate now as they did before
<rsalveti> ogra: another issue I saw yesterday, is that it's taking way more time now to generate the system-images
<rsalveti> ogra: maybe more channels caused that
<rsalveti> ogra: ~1:20h
<apw> what we need to do is count the idle as "100% busy - what_we_used" for each cpu
 * didrocks goes for a run
<ogra> rsalveti, woah ...
<apw> which will be 100% idle for offline cpus
<ogra> rsalveti, i noticed it was longer ... but not that much
<didrocks> apw: right, we need an absolute value
<rsalveti> ogra: yeah, so it's taking ~2h to get a new image published now :-(
<apw> didrocks, i'll try and find a way to get the numbers you need
<ogra> rsalveti, crap
<didrocks> apw: thanks :) keep doanac` in touch I guess (for the UTAH side)
<ogra> rsalveti, well, goldfish will be gone soon
<asac> apw: right.
<rsalveti> ogra: yeah
<ogra> thats one down
<asac> that was my plan
<rsalveti> asac: oh, as you created this test I guess I can just blame you then :P
<asac> blame?
<asac> :)
<rsalveti> hahah :-)
<rsalveti> ogra: yeah, the current jack-detection logic is consuming quite a lot of cpu =\
<rsalveti> ogra: it walks over all properties when it gets an uevent
<rsalveti> looking for the SWITCH_STATE property
<rsalveti> there's a call there to make udev just return events from the switch subsystem, but commented out
<ogra> hmm, the jack detection is diwics work
 * ogra remembers the patch 
 * sil2100 remembers doing jack-detection for the old transformer
<sil2100> Damn that was a hack
<ogra> yep
<sil2100> ;)
<ogra> even the one that landed in pulse was one ... just less evil ... i remember diwic raving about it
<rsalveti> yeah
<asac> ogra: do you have a cat /proc/stat while the cpus are on and while off?
<sergiusens> didrocks, row 1 col 1 in train says thum
<ralsina_> dear CI train people (didrocks, sil2100, Mirv), can I get silo 14 landed?
<plars> balloons: specifically on rssreader, I'm thinking maybe the name change affected the AP tests too? They don't seem to run at all
<balloons> plars, I can't remember what we did with that :-) However, the test suite is shorts_app now
<plars> balloons: ok, sounds like we'll need to change the name on our side then
<ogra> asac, http://paste.ubuntu.com/6987526/
<ogra> seems they are always listed
<sil2100> ralsina_: did you set it to 'Tested: yes'? :)
<ralsina_> sil2100: oops, doing it.... done
<sil2100> ogra: do you know if we're still holding the line of package publication?
<ogra> sil2100, dunno
<asac> ogra: sure htat they are off while you cat them?
<ogra> did we actually block at all ? everyone was so shocked by the test rresults, i dont remember discussion that
* ev changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but chooose right timezone | Landing instructions: http://goo.gl/8H1Du3 | Known Issues: -
<asac> ogra: can you cat twice with 4.4 and wait like 10 secs in between?
<ogra> asac, the device is idling since 1h with screen off
<ogra> i would expect them to be offline, yes
<sil2100> ogra: I remember Didier mentioning in the morning on IRC that 'we're holding off releases'
<sil2100> Let me re-confirm
<ogra> asac, note that flo might behave different though ... thats mako vs flo
<ogra> popey, do you have a recent install on mako ? and could you pastebin /proc/cpuinfo and /proc/stat ?
<ogra> popey, of an idling device that is
<plars> balloons, didrocks: So here's the current lits I have of failures (after rerunning dialer_app). I haven't tried rerunning some of the others, but I think psivaa-afk-bbl has, and I'd like to sync up with him about what he observed. Also, rssreader needs a name change on our side, which I'll take care of in just a bit, hopefully in time for 207
<balloons> plars, fginther had done some work on this with my original bug: https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1279643
<ubot5> Ubuntu bug 1279643 in Ubuntu CI Services "Ubuntu rssreader app build jobs need to reflect name change to shorts app" [Undecided,New]
<popey> ogra: image 206 on mako, yes
<plars> balloons: ack
<balloons> I'm confused why all this happened I guess :-)
<balloons> I guess only the builder was changed, not the runner on your end
<fginther> balloons, I wasn't aware that the suite name was used anywhere else in the ci infrastructure
<popey> ogra: http://paste.ubuntu.com/6987544/
<ogra> asac, ^^
<ogra> asac, so the stats keep the cores around even when offline it seems
<balloons> no worries fginther.. we know now ;-)
<sergiusens> fginther, changing the suite name is problematic; reason why I started adding an x-test thing so you can phablet-test-run the package and forget about what the module name was (and in the future, also not depend on autopilot at all if needed)
<fginther> balloons, and so do I
<ogra> popey, thanks !!
<fginther> sergiusens, nice
<asac> ogra: so forcing online/offline cpu is like this: http://paste.ubuntu.com/6987573/
<asac> e.g. it disappears
<ogra> yep
<asac> on my intel machine
<ogra> not sure it works on android kernels, but yeah, thats how it usually works
<ogra> ask the kernel team :)
<asac> apw: how does the android kernel behave in this respect?
<asac> see a few lines above
<ogra> asac, the thing is that you might interfere with some android userspace tool that handles this inside the container
<dbarth> sil2100: did you see my request earlier about publishing silo-001? it's blocking us a bit for the appshowdown release
<ogra> i.e. you might confuse it
<asac> maybe path of least resistance is really to turn off all cpus but one for systemsettle
<asac> that surely would make things easy to calibrate :)
<ogra> definitelly
<ogra> i just fear that we might confuse android
<ogra> as long as we dont, that might be the way
<ogra> asac, prob is that issues llike what rsalveti is seeing with pulse above will be completely hidden
<sil2100> dbarth: hi! Yes, I saw that, but I don't know if we're clear to publish things now or not - want to clarify this with didrocks first
<sil2100> asac: maybe you know - should we hold of landings for now or can I publish new packages?
<dbarth> ok traffic jam, nw
<asac> sil2100: would prefer to wait for didrocks
<asac> sil2100: that preference might change depending on the specific landing case
<asac> e.g. if its a firedrill landing etc. let me know
<mhr3> sil2100, silo for 29 pls
<mhr3> sil2100, do i prefer pinging everytime i need a silo, or is just adding the line enough?
<mhr3> do you*?
<sil2100> mhr3: I usually notice it, I didn't assign it due to the firedrill happening right now
<mhr3> sil2100, it's been there for the past two hours though
<mhr3> so ping it is :)
<sil2100> mhr3: yes ;p I'll assign it once I have clearence if it's ok to assign one ;)
<apw> asac, they are still there, but we don't actually care
<apw> didrocks, asac, doanac`, ogra: this script seems to get the "right" version of idle on either kernel: http://people.canonical.com/~apw/misc/idle
 * apw can see why you care how busy the enabled cpus are, ie why they made this change (which mainline has now as well), as it lets you know if you really need to bring one back
<sergiusens> sil2100, can I get a silo for l32?
<sil2100> One moment
<asac> apw: cool. with this we somewhat loose ability to log the processes and what they consume (to investigate in logs whats going on in case we are not idle enough anymore).
<apw> asac, well if you fail that check you can run the previous dump, as you know it is over
<sil2100> What the... I see some spreadsheet problems, something new it seems
<apw> and i'd say from what i am seeing that your idle has gone to hell
<asac> hmm
<ralsina_> sil2100: gentle reminder to land silo 14 unless landings are blocked?
<ogra> asac, i think we should be good running top once after apw's test
<ogra> to just get the hanging top consumer
<sil2100> ralsina_: I remember about that - just still missing clarification if we can land
<sil2100> Waiting for didrocks
<ralsina_> sil2100: ah, ok
<sil2100> But I'll resume silo assignments for 'safe' components
<ralsina_> sil2100: no rush, to be honest :-)
<asac> apw: could i just use a top with delay 5 instead of sleep to capture the process business?
<ogra> it wont be as fine grained but we will at least get hanging procs
<ogra> asac, that will bring top back into the equation
<ogra> i would try to keep them distinct to get more accurate numbers
<sil2100> robru, cyphermox: just so that you guys know - the spreadsheet seems to be awfully slow today, so assigning a silo can take some serious seconds to complete
<cyphermox> aye
<sil2100> mhr3, sergiusens: silos assigned for you guys
<mhr3> sil2100thx
<apw> asac, if you run anything in there you won't see if it is idle
<asac> apw: any way we can do something similar like top that captures details on the pid's while we sleep?
<asac> e.g. manually?
<ogra> asac, any process you run there will taint the result
<apw> ogra, who do i talk to to get this flashy thing to work, it is completly impossible to know what it is doing
<apw> even worse than the previous versio
<ogra> apw, did you read what was suggested in the other channel ?
<ogra> apw, boot into bootloader mode and just run it again
<asac> ogra: right, hence ii think something like capture the process stats before and after the two cat's
<ogra> asac, i would do it after the test fails actually
<ogra> and onyl then
<ogra> if it settles file you dont need the info
<ogra> if it doesnt, chances are good that the process still is in your top run right after the test
<ogra> s/file/fine/
<didrocks> sil2100: what's up?
<sil2100> didrocks: hello! Can I land stuff to distro? As the system settle issue is 'somewhat' cleared, I guess the smoketesting results look pretty ok, right?
<didrocks> sil2100: as told, until we have a list of everything that failed (we now have the system settle things out), we only publish desktop-things only
<didrocks> sil2100: do we have the list of what's failing still?
<didrocks> I saw paul mentionned this, if you can with him build up that list for the meeting
<didrocks> so that we know where we stand
<sil2100> didrocks: sure, I just browsed through it myself before and saw 2 failures - terminal app and clock
<sil2100> didrocks: but I'll make sure with Paul
<sil2100> plars: ping :)
<plars> sil2100: on a call right now, but what's up?
<sil2100> plars: do you have a list of real-test-failures for the latest image by any chance?
<sil2100> (excluding the system settle ones)
<plars> sil2100: somewhat - some of these have not yet been double-checked to see if they are flaky or consistently failing, but here's the list so far: http://paste.ubuntu.com/6987534/
<didrocks> sil2100: how did you build the list, I see a lot of unity8 ones
<rsalveti> ogra: plars: phonesim takes a while to settle down because NM tries to create a data connection with it
<ogra> yeah
<rsalveti> and it takes a few seconds for NM to give up
<rsalveti> http://paste.ubuntu.com/6987869/
<rsalveti> wonder if we really need to export the data call interface with phonesim
<AlbertA> cihelp: how do I retrigger this jenkins build? http://s-jenkins.ubuntu-ci:8080/job/unity-mir-ci/258/rebuild
<AlbertA> cihelp: I have vpn access and I can see that url, but I don't see a way of re-trigger the build after following the link
<fginther> AlbertA, you need someone to provide you jenkins access, which we're trying to get away from now
<fginther> AlbertA, generally, updating the MP will automatically trigger a rebuild. Is there a specific reason why this needs to be rebuild?
<fginther> AlbertA, looking at the logs, this build failed because the testing didn't cleanup, has this been fixed? Or will a rebuild just have the same problem?
<rsalveti> ogra: sergiusens: any idea why maliit-server is getting an input channel from pulse?
<ogra> output i could understand
<rsalveti> playback stream
<sergiusens> rsalveti, audible feedback?
<ogra> for the click sounds
<sergiusens> bfiller, ^^
<rsalveti> yeah, not input
<ogra> ah
<ogra> yeah
<ogra> thats fine i think
<ogra> you want to shorcut that to not get latency
<rsalveti> http://paste.ubuntu.com/6987898/
<rsalveti> right, because I know someone is also waking pulse quite frequently
<rsalveti> from alsa
<ogra> (which we have anyway ... i often lose clicks when typing fast)
<rsalveti> ogra: was it maliit-server the one you removed 2 seconds of sleep?
<didrocks> kgunn: bfiller do you mind coming to your landing meeting?
 * sergiusens smells another revert
<didrocks> I guess we'll need you :)
<kgunn> didrocks: normally i would...but i'm in another meeting, i can't atm
<didrocks> kgunn: an hour meeting?
<didrocks> or 30 minutes?
<kgunn> will end in 30
<didrocks> kgunn: ok, can I catch up with you then?
<ogra> rsalveti, yes, because the missing unity8 commit we added them for is long merged
<rsalveti> yeah, just trying to understand if we could have any other unexpected side effect
<rsalveti> didrocks: not much from my side, still investigating pulse
<rsalveti> should have something later today
<didrocks> rsalveti: ok, no worry, you are already aware :) FYI, I'm going to propose pairing people to help fixing all the failing tests we have
<rsalveti> didrocks: great, thanks so much
<didrocks> rsalveti: and slow down/stop touch landings which are not set to get things fixed
<rsalveti> and sorry for the noise, at least I'm happy we got some results today
<sergiusens> rsalveti, can you monkey press publish here? https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=24
 * sergiusens likes calling it monkey press
<didrocks> rsalveti: no worry, we knew it was going to be painful :)
<rsalveti> yeah
<rsalveti> :-)
<rsalveti> sergiusens: DONE
<sergiusens> rsalveti, I notice I forgot to add your name change
<sergiusens> rsalveti, I'll get another train in place
<didrocks> cyphermox: joining?
<popey> balloons: any idea what's going on here https://bugs.launchpad.net/autopilot/+bug/1283868
<ubot5> Ubuntu bug 1283868 in Autopilot "music-app rev 356 fails AP test on image 205 on mako" [Undecided,New]
<balloons> UnicodeEncodeError fun
<ogra> rsalveti, cyphermox just pointed out that phonesim shouldnt be installed at all
<ogra> rsalveti, and in fact it isnt
<robru> popey, balloons: sounds like somebody wrote a test in python2 but ran it under python3. needs some porting
<ogra> rsalveti, http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20140224/trusty-preinstalled-touch-armhf.manifest
<ogra> rsalveti, seems one of your tests pulled it in, just uninstall
<ogra> cyphermox, thanks !
<cyphermox> phonesim is nice for testing but then I'd be really scared if it was running normally, since you couldn't know for sure which modem is being used for what, and I'm not just talking about NM
<ogra> yeah
<cyphermox> i.e. I don't want tests running and having any chance to do something with the real SIM, which is why I remove it
<ogra> and it is in fact not preinstalled
<cyphermox> but the other way around is posisble
<ogra> i know ricardo did a dialer-app test run before
<didrocks> ogra: cyphermox: we nede to have after the dialer-app are run, unininstall it
<didrocks> need*
<ogra> that has most likely pulled it in
<cyphermox> yes
<didrocks> otherwise, depending on when dialer-app tests are run
<cyphermox> dialer-app tests indeed pull it in IIRC
<didrocks> all the other tests are "polluted"
<cyphermox> or you know, something else
<ogra> right, or run dialer-app last at least
<didrocks> remember the issue we had at some point?
<cyphermox> shouldn't have to mess with the ordering of tests though
<didrocks> ogra: yeah, I think most of tests should have a teardown()
<didrocks> cyphermox: +1
<didrocks> asac: doanac`: agreed? anyway we can get that? ^
<ogra> cyphermox, no, but its a workaround worst case
<doanac`> didrocks: sorry - what are you asking of me?
<cyphermox> ogra: no, the right way to fix this is to fix the cleanup for the test that pulls it in
<ogra> cyphermox, i know what the right way is ... but if people are to busy right now to fix it, reordering until they can fix tomorrow would help for today ;)
<didrocks> doanac`: basically, is is possible to remove -autopilot (and all automatically installed packages) from one tests at the end before we go to the next suite?
<doanac`> didrocks: it goes a little against how the code works now. we install the deps up-front, and then run the tests. we could do it, but its a little work
<asac> didrocks: you say autopilot should provide setup/teardown infrastructure in the framework?
<didrocks> doanac`: up-front, meaning for every tests?
<asac> sounds reasonable thing to do. not sure if thomi agrees
<doanac`> didrocks: up front, after provisioning and before we start running tests
<asac> (sorry, on call, so might not know what this is about exactly - take my input with proper care)
<didrocks> doanac`: is it new, it wasn't the case before
<didrocks> doanac`: I remember at some point (like 3 month ago) we had a bug where we got ofono-simd installed
<didrocks> and then, all tests were failing
<didrocks> but ofono-simd was installed only when we reach teh dialer-app AP test
<doanac`> didrocks: semi-new. we've done it this way since the start for click-packages. we recnetly started doing it this way for .deb autopilot tests also
<didrocks> ah ok, so yeah, it changed
<didrocks> doanac`: hum, we have an issue, it seems ofono-simd shouldn't be used while we are testing other stuff
<didrocks> as mocks replace real functionalities that may be used somewhere else
<doanac`> didrocks: okay, so we need to apt-get install, test, apt-get remove for each test now?
<didrocks> doanac`: yeah, for each testsuite
<doanac`> didrocks: ack. i'll file a bug. it might take a few days for me/plars to sort that out.
<didrocks> doanac`: sure, system settle idling is way more important :)
<plars> apw: so if I understand this correctly, it's giving percent cpu usage (user+nice+system+iowait) *100/numcpus after sleeping for 10 sec, correct?
<doanac`> didrocks: https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1284226
<ubot5> Ubuntu bug 1284226 in Ubuntu CI Services "touch daily image test: need to install and remove deps for each testsuite" [High,Confirmed]
<didrocks> doanac`: thanks :)
<rsalveti> ogra: phonesim is installed when testing dialer-app
<rsalveti> ogra: plars: can we remove a package after testing that app?
<rsalveti> plars: also, is the package installed before running that test only or when setting up the image itself
<ogra> rsalveti, to late ... doanac` is already on it ;)
<rsalveti> like, don't know if it first install all the tests and so on or if this only happens when starting a test
<ogra> (see backlog)
<rsalveti> oh, sorry, got a split, backlog is not part of my default screen
<ogra> ah
<ogra> bug 1284226
<ubot5> bug 1284226 in Ubuntu CI Services "touch daily image test: need to install and remove deps for each testsuite" [High,Confirmed] https://launchpad.net/bugs/1284226
<rsalveti> didrocks: it's just that this also affects system-settle
<rsalveti> didrocks: because at every reboot NM will try to create a data connection a few times (5 I guess)
<rsalveti> causing other cpus to go up and down, and then also causing pulse to consume more
<rsalveti> (which I'm currently investigating
<rsalveti> )
<ogra> rsalveti, right, we discussed that at the landing meeting
<ogra> (which brought up that phonesim should never be installed)
<rsalveti> right, cool
<didrocks> rsalveti: oh, we didn't see it in the "top"
<didrocks> but saw a lot of logs spew
<didrocks> ok, so yeah, that can as well mean we'll need that at the same time
<didrocks> (and a cherry on top)
<ogra> didrocks, phonesim was in all top-before logs that happened after the dialer test
<ogra> (but it was like that since ages already ....)
<didrocks> yeah, but not nm?
<plars> yes, I believe it would be installed at setup time, not right before the dialer test
<plars> this isn't a new thing though
<rsalveti> right
<rsalveti> it's not, but it's also delaying the settle-down job
<ogra> didrocks, just because we never lookec at NM debug output
<didrocks> popey: hey, so, all AP tests run for you?
<didrocks> for music-app
<sil2100> hmmm
<popey> yes
<didrocks> (that would be good input for robru and balloons)
<popey> Ran 12 tests in 436.767s
<popey> OK
<didrocks> ok
<didrocks> I guess a lot of issues we see are similar to sil2100's ones
<didrocks> ok, time to go this time, see you tomorrow guys, and good luck!
<ogra> oh. lovely, beta freeze
<rsalveti> ogra: argh
<ogra> only until thu.
<rsalveti> right, pulse is part of every image haha
<rsalveti> ogra: so, pulse is behaving properly with the default image here
<rsalveti> after I install phonesim and reboot, there's always someone waking it up every 2 seconds
<ogra> 206 ?
<rsalveti> ogra: yes
<ogra> phew
<ogra> k, so it is just phonesim
<ogra> which will be fixed soon to be removed
<rsalveti> well, need to find why we have someone waking pulse (via alsa)
<rsalveti> wonder if it could be a race with maliit-server, rebooting and will see
<ogra> i guess some phonesim mock thingie does that
<ogra> i wouldnt bother if it only shows with phonesim
<ogra> (though it will indeed taint the settle test of dialer-app)
<rsalveti> there's a package called phonesim-autostart
<rsalveti> maybe the test could start it itself?
<ogra> does that get installed ?
<rsalveti> ogra: yes
<ogra> ask pitti
<ogra> phonesim is his baby
<apw> plars, / (HZ * numcpus)
<plars> apw: ah, right
<rsalveti> ogra: compare, normal image: http://paste.ubuntu.com/6990307/
<plars> apw: but what comes out at the end is the idle % at the point it's measured, correct? (corrected for cpu scaling and quantity)
<rsalveti> ogra: after installing phonesim: http://paste.ubuntu.com/6990345/
<rsalveti> see the amount of times alsa is waking up pulse
<ogra> yeah, crazy
<apw> plars, yes
<apw> basically we work on the premise that there are HZ*numcpus worth of ticks, the ticks which arn't useful ticks are idle ticks, and this works whether the cpu is updating or not
<cyphermox> robru: ogra: rsalveti: the issues look very much like something that would get broken by a change from android 4.3 to 4.4... camera image is majorly messed up ;)
<ogra> works fine on flo though
<cyphermox> mako
<rsalveti> cyphermox: what is the issue?
<ogra> just take your flo with you for taking photos when going out with your mako
<ogra> easy fix :P
<cyphermox> the image in camera_app for what you're looking at is doing like an old TV -- like horizontal sync is broke
<cyphermox> I don't have a flo
<ogra> you need to get one
<cyphermox> ;)
<rsalveti> that's weird, always works fine here, but it might indeed behave differently
<rsalveti> the camera hal sucks so bad
<sergiusens> rsalveti, looking at that later today
<rsalveti> thanks
<ralsina_> ogra: can I get silo 14 reconfigured? Since landings are on hold I am using it for testing branches for MWC as they come.
<ogra> ralsina_, i cant configure silos, sorry ...
<ralsina_> ogra: ack, no problem
<ogra> ralsina_, cyphermox or robru
<sergiusens> doanac`, can you rebless this? https://code.launchpad.net/~xnox/phablet-tools/py2-3/+merge/205608
<ralsina_> ogra: I actually meant robru! Not my best day with names :-)
<ogra> lol
<ogra> yeah, easy to mix up :P
* fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: fginther | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but chooose right timezone | Landing instructions: http://goo.gl/8H1Du3 | Known Issues: -
<doanac`> sergiusens: done
<sergiusens> doanac`, I'm going to get a landing slot for this and yours, mind giving it a go with ci workflow when the silo is built just in case?
<doanac`> sergiusens: no problem. i'm headed to lunch now, but just ping when you are ready for me to give it a spin
<sergiusens> great
<sergiusens> robru, hey, can I get a silo for l31?
<balloons> ping fginther
<fginther> balloons, pong
<robru> sergiusens, is that desktop-only?
<balloons> fginther, it seems the filemanager click builder isn't building; http://s-jenkins.ubuntu-ci:8080/job/filemanager-app-click/90/console
<sergiusens> robru, yup
<robru> ralsina_, I can reconfigure, are the MPs up to date in the spreadsheet?
<robru> sergiusens, ok
<sergiusens> robru, as in what it installs is for the desktop to interact with the devices :-)
<ralsina_> robru: yes they are
<robru> ralsina_, ok just a sec
<fginther> balloons, looks like it needs to be update. I'll get started on that.
<balloons> fginther, yea, I was going to say the same.. looks like it needs to be cmake :-)
<robru> sergiusens, ok you got silo 3
<sergiusens> thanks
<robru> ralsina_, ok it's reconfigured
<ralsina_> robru: awesome, thanks!
<boiko> robru: heym I have this change on line 24 of the spreadsheet, it is tested already, but it needs the calendar-app click package to be updated in the image, should I mark it as Testing pass?
<ralsina_> robru: something happened, I added two branches and they are gone now. I'll readd them :-(
<balloons> fginther, just looking through the rest; not sure if rssreader builder has an issue or not; have a look http://s-jenkins.ubuntu-ci:8080/job/rssreader-app-click/106/console
<ralsina_> robru: ugh, I don't know what happened, re-added them and now it has to be reconfigured again
<robru> boiko, you can mark it testing pass, but under the comments please write "don't release this until calendar-app click package is updated"
<robru> boiko, oh and maybe mention what version number is required so we can check whether it's safe to release then
<boiko> robru: and what is the process to get the calendar-app updated?
<robru> boiko, not sure, I guess it needs to get uploaded to the click store. i don't deal with that
<robru> ralsina_, ok one sec
<fginther> balloons, I can fix that one too
<sergiusens> doanac`, when you get back; can you update your mr as xnox has a couple of updates on his?
<robru> ralsina_, ok so just to confirm, these are the merges you want? http://paste.ubuntu.com/6990558/
<doanac`> sergiusens: ack
<ralsina_> robru: correct
<sergiusens> doanac`, I wish launchpad noticed changes in its prereqs :-)
<robru> ralsina_, ok, done.
<boiko> robru: ok, thanks
<robru> boiko, you're welcome
<ralsina_> robru: thanks again!
<fginther> balloons, http://s-jenkins.ubuntu-ci:8080/view/click/job/rssreader-app-click/107/
<robru> ralsina_, no worries
<fginther> balloons, http://s-jenkins.ubuntu-ci:8080/job/filemanager-app-click/91/
<cyphermox> robru: found anything meaningful in the tests?
<robru> cyphermox, haven't been able to find anything meaningful... they just seem flaky. I run them and I get different failures than were originally reported, and on second run I get yet different failures. still looking for any kind of pattern
<cyphermox> ah
<cyphermox> so far I get the same failures reproducibly
<doanac`> sergiusens: i just merged my branch with the latest for xnox, tested and pushed. it should be in good shape
<sergiusens> doanac`, great; let me rebuild the silo then; thanks
<robru> cyphermox, which tests?
<asac> plars: do you know if we abandoned N10 testing? cant find them in the "all targets" dashboard anymore
<cyphermox> camera_app and gallery_app so far
<plars> asac: iirc that and n7 were abandoned a long time ago as the focus got placed on phones, with the later intent of bringing back n7 and n10 with the new 4.4 based images (with the newer devices of course)
<asac> plars: ok cool. didnt know we turned those jobs off... thought they were still running, just not looked at
<asac> but thats fine
<asac> plars: how is enabling flo going?
<plars> asac: I'm hoping to have flo up and running today or tomorrow, on n10 I hear it needs a newer device though, is that so? or is there only one variety of n10?
<asac> newer?
<asac> plars: never heard that we need a newer N10
<asac> rsalveti: any idea?
 * rsalveti reading
<ogra> there is only one N10 model
<plars> asac: there are two n7's, someone said that the n10 we support with the newer image is not the original n10 that came out
<ogra> no worries
<plars> ah good
<plars> ok, so that's a relief
<rsalveti> yeah, there's only one model
<rsalveti> we're safe
<rsalveti> just need to add them back
<rsalveti> the problem with n10 is that 4.2.2 was half backed for it
<rsalveti> (the original android image)
<asac> plars: ^^
<asac> just add them back and we are good to go
<asac> rsalveti: half baked? you mean by google?>
 * ogra doubts that ...we surely will have awful test results :P
<plars> rsalveti: right, but we expect the new 4.4.2 ones to be better right?
<ogra> flo has all my sympathies though
<asac> ogra: syure, but thats fine. we dont have seen better results so it wont block promotion
<cyphermox> robru: hrm... actually for gallery-app the results are pretty abysmal
<cyphermox> just dbus errors for all of them
<rsalveti> plars: asac: yes, by google, that's why 4.4.2 is so much better with it
<rsalveti> and so is our newer image
<ogra> ++
<ogra> if the sidestage wouldnt be so odd, the N10 would be a wonderful device
<ogra> with the new image
<rsalveti> yeah
<rsalveti> argh, ports is really slow for me today
<ogra> (though i'm not as impressed with the display as i thought)
<ogra> flo is a true beauty wrt display
<boiko> robru: so, I talked to the calendar guys, latest revision is already in the click store, so we are fine to release the qtorganizer5-eds change
<robru> boiko, ok, but does that change fix any of the current regressions?
<boiko> robru: ah you mean if we need to release that for MWC? good question, maybe bfiller knows for sure
<robru> boiko, no, I mean does this release of qtorganizer5-eds have any impact on fixing any of this mess? http://ci.ubuntu.com/smokeng/trusty/touch/mako/206:20140224:20140224/6796/
<bfiller> robru: no this is unrelated to that new mess
<boiko> robru: oh, probably not, wow, things are not looking good there
<robru> boiko, no they aren't ;-)
<robru> boiko, bfiller so I recommend holding off on the qtorganiser5-eds release until this is more under control
<bfiller> boiko: is the lastest calendar app part of the preinstalled image?
<boiko> bfiller: well, it is on the store, and according to sergiusens if it is there, it will be updated on the image
<bfiller> boiko: ah ok
<sergiusens> if it's in the store it will show up
<bfiller> boiko: then just go ahead and mark testing as pass on the train after it's been tested
<robru> boiko, but next image build isn't for another ~7 hours
<boiko> robru: that's fine
<robru> boiko, wait, what's the nature of the dependency here? does calendar-app require the new qtorganizer? or does qtorganizer require the new calendar-app?
<boiko> robru: so, I think the old calendar-app does not work with the current qtorganizer-eds, but the current one does
<boiko> robru: this new qtorganizer-eds fixes some stuff related to recurrent events
<robru> boiko, ok so what I'm afraid of is in ~7 hours, we'll get a new image build, and it'll have the new calendar app, but it probably won't have the new qtorganizer, is that a bad state to be in?
<boiko> robru: don't think so
<boiko> robru: recurrent events was not supported/working properly before, so no regressions here
<robru> boiko, ok thanks
<balloons> fginther, ty for both click fixes
<bfiller> rsalveti: cyphermox found an issue with camera-app that seems related to new Android
<rsalveti> bfiller: which one? :-)
<bfiller> rsalveti: explaing why some AP tests failing. if you tap the preview for the focus ring it hangs the app
<bfiller> rsalveti: sometimes have to tap it a few times
<bfiller> sometimes happens right away
<rsalveti> right, might be the same hang it is happening when taking pictures
<bfiller> rsalveti: can you take a look at it?
<rsalveti> bfiller: sure, sergiusens is already planning on taking a look at that today, but we're working on it
<sergiusens> bfiller, on my plate
<bfiller> rsalveti: cool, thanks
<bfiller> cyphermox saw this in log might be of help http://paste.ubuntu.com/6990774/
<bfiller> sergiusens: https://bugs.launchpad.net/ubuntu/+source/camera-app/+bug/1284290
<ubot5> Ubuntu bug 1284290 in camera-app (Ubuntu) "mako camera-app screen garbles and app crashes" [Undecided,New]
<sergiusens> thanks
<davmor2> hey ogra with the first 4.4 release does that mean that maguro bites the dust </queen_another_one_bites_the_dust>
<rsalveti> davmor2: it's still working with latest image
<rsalveti> userspace is compatible with both 4.2 and 4.4
<rsalveti> we're just not updating the android image for it anymore
<davmor2> rsalveti: stop with the maguro cpr already ;)
<ogra> davmor2, maguro will be gone from testing tomorrow (or wed.)
<davmor2> ogra: kill it, kill it with fire!!!!!
<ogra> davmor2, thats plars job
<ogra> he's got the flamthrower
<davmor2> plars: ^ KILL IT, KILL IT WITH FIRE!!!!!!!!!!!!!
<ogra> *flame
<plars> it's being done, but I should point out the reason CI is still trying to test it is because we seem to still be building images for it
<plars> http://system-image.ubuntu.com/trusty-proposed/maguro/
<plars> ogra: who needs to kill that?
<davmor2> plars: it isn't quite dead yet
<rsalveti> yeah, the goal was to kill it once we get the x86 emulator
<balloons> ping fginther
<ogra> plars, it can go from the dashboard
<ogra> in favour of flo
<rsalveti> guess it's up to asac to decide that
<ogra> we seriously dont want to block image promotion on it
<plars> we haven't done that for a while now
<ogra> so it should go ...
<asac> true. you can move it to the "all targets" section until we have finished the transition
<ogra> right
<asac> (maguro that is)
<ogra> keep the data around ... keep the tests runnign until emulator
<plars> asac: but we still want to try to run it?
<plars> asac: it doesn't seem to work in the latest image
<ogra> plars, getting some low end info is surely good
<ogra> oh ?
<ogra> i'm on 206 just fine here
<ogra> OTA though
<fginther> balloons, pong
<plars> ogra: I didn't look at it much because I thought it was expected to fail - actually I thought it was expected not to even build
<plars> ah, the device is not present
<plars> I can see what's up with that
<ogra> plars, we just left the 4.2 files for it on cdimage
<plars> ok, I'll add it back to the runs then, I was just working on removing that
<balloons> fginther, I'm wondering if you can have a look at how reminders-app is being built for the ppa (debian packaging mind you). I don't see qtdeclarative5-evernote0.1 being built and it's needed
<ogra> and userspace is compatible to both versions
<asac> plars: it is expected to boot and work still... dont put too much time into it, but the golden way would be to have it running until we have transition finished and emulator is up
<plars> asac: that's the plan
<fginther> balloons, what branch (or where) does qtdeclarative5-evernote0.1 come from?
<balloons> fginther, I'm feeling a little behind on it, but they did work to merge the plugin into lp:reminders-app, and you can see it now in debian/control
<fginther> balloons, I see that the i386 upload is blocked dueo to a newer account-plugin-evernote already being in the ppa. This appears to be blocking all uploads from the i386 build which includes qtdeclarative5-evernote0.1
<fginther> balloons, https://launchpadlibrarian.net/166772018/upload_5616694_log.txt
<balloons> fginther, oO so if I bump the version and commit it should set everything free?
<fginther> balloons, it should, but you'll need to bump it higher then 3-0~10~ubuntu13.10.1
<balloons> weird version.. ok
<balloons> ty for your help fginther
<fginther> balloons, you're welcome, let me know how it goes
<balloons> fginther, is there a way to reject what's sitting in the ppa now?
<balloons> in other words, no way to kick out that build
<fginther> balloons, it can be removed, but launchpad may keep the records around for week(s)
<fginther> balloons, I can give it the boot
<balloons> it's going to be a pain to mangle the versioning that much I think, so worth a try
<cjwatson> You can't ever reuse the same version, but I believe if you delete it it should let you upload an older version after a short while
<cjwatson> (I think)
<balloons> fginther, is account-plugin-evernote also a high version? 3-0~9~ubuntu14.04.1 it seems?
<fginther> balloons, yes, that's the trusty version, the saucy version is 3-0~10~ubuntu13.10.1
<balloons> fginther, can you kick that out also?
<fginther> balloons, I've deleted them
<balloons> thanks.. seems like just the beginning of untangling this mess.. :-)
<fginther> balloons, do you have the power to retry the build?
<balloons> fginther, I don't believe I do.. If I do I don't know it
<fginther> balloons, I'll give it a friendly kick then
<robru> boiko, actually i've decided to publish silo 2 because it looks like it reduces some failures in the image. please merge & clean once it reaches distro
<boiko> robru: ok, nice, thanks
<fginther> balloons, the rebuild work, the update trusty binary packages are in the ppa. saucy rebuild is in progress
<balloons> fginther, wonderful, let me see if the dependency issue is sorted now at least
<balloons> fginther, worked splendidly
<fginther> balloons, nice
<plars> maguro is running fine now: http://ci.ubuntu.com/smokeng/trusty/touch/maguro/206:20140224:20140115.1/6811/
<sergiusens> balloons, are you good with the update to calendar?
<balloons> sergiusens, updates to calendar? the trunk version landing in store or ?
<sergiusens> balloons, yeah that
<balloons> sergiusens, rsalveti think we can land this? https://code.launchpad.net/~sergiusens/phablet-tools/buddy-x/+merge/206587
<sergiusens> balloons, yes we can
<balloons> sergiusens, yea, I've no reason not to be.. the EDS fix in the silo atm will solve the known bugs
<balloons> btw sergiusens congrats on upload rights for lots of fun things
<sergiusens> thanks, delayed that for too long :-)
<balloons> sergiusens, I linked the bug to your MP as well
<sergiusens> awesome
<boiko> robru: in silo landing-002 the "Merge and clean" cell is showing as #N/A
<robru> uh
<robru> boiko, shows for me: http://162.213.34.102/job/landing-002-3-merge-clean/build?delay=0sec
<boiko> robru: but the link is still correct it seems though
<boiko> robru: reloading the document did the trick, not sure why the image was not showing up
<robru> it's been glitchy lately i guess
<sergiusens> balloons, just pushed a small improvement to that MR, can you take a look; would need a happrove as well
<sergiusens> rsalveti, mind doing that review? https://code.launchpad.net/~sergiusens/phablet-tools/buddy-x/+merge/206587
<sergiusens> robru, gotta love muting the music tests
* fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but chooose right timezone | Landing instructions: http://goo.gl/8H1Du3 | Known Issues: -
<sergiusens> fginther, hey, I'm having an issue with https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/5497/ ;  and the otto counterpart; these tests pass locally on my device
<sergiusens> the issue is, not sure what is failing there
<fginther> sergiusens, I can take a quick look now
<sergiusens> thanks
<fginther> sergiusens, I don't know... The same 5 TestHud failures are on both the otto and mako tests. The Mako has extra failures due to unity8 crashing
<fginther> sergiusens, I took a closer look at the packages installed for the otto tests and there are no differences between this test and one from a few builds ago that didn't show these failures
<sergiusens> darn
<fginther> sergiusens, the last unity8 MP to merge from from 2 days ago, was your MP older than that?
<sergiusens> yes
<dobey> fginther: if you could get a chance to take a look at https://code.launchpad.net/~dobey/tarmac/merge-specific/+merge/208037 that would be great. it adds the feature of passing a specific MP to merge.
<sergiusens> fginther, my mp is 2 weeks old probably
<sergiusens> fginther, I took it over from bfiller
<fginther> sergiusens, by any chance did you merge to trunk before testing?
<sergiusens> fginther, no; I was going to but then thought that this was done in jenkins anyways, right?
<fginther> sergiusens, right it's done by jenkins, might explain why jenkins show the failures but you don't see them
<sergiusens> ah you mean locally; well I tested using the output.zip from jenkins
<fginther> oh
<sergiusens> fginther, ^
<sergiusens> so it is quite the same
<sergiusens> and read what otto did for setup and replicated
<fginther> sergiusens, I triggered a rebuild to get some more info
<sergiusens> fginther, with more debug info?
<fginther> dobey, I'll add it to the list of tasks, I'll try to get to it in a a day or two
<fginther> sergiusens, no just another data point, same test run
<fginther> sergiusens, I need to drop off, I might be able to take a look later, otherwise it will be tomorrow.
<sergiusens> ok
<dobey> fginther: cool, thanks
#ubuntu-ci-eng 2014-02-25
<sergiusens> robru, hey, can you reconfigure l31-silo-003 for me? added an MR
<robru> sergiusens, sure
<sergiusens> robru, or do I not need to do that?
<sergiusens> the MR targets the same project
<robru> sergiusens, if you added an MP then I need to reconfig it, for now. we're working on a way to give you more autonomy here
<sergiusens> ok, thanks
<robru> sergiusens, ok done, please build.
<sergiusens> thanks
<sergiusens> doanac`, seems https://code.launchpad.net/~doanac/phablet-tools/autopilot-args/+merge/207315 still needs rebasing
<sergiusens> doanac`, http://162.213.34.102/job/landing-003-1-build/35/console
<sergiusens> fginther, failed again
 * cyphermox logs off
<asac> doanac`: plars: do you know why 206 is still in "running" state?
<asac> as are 202 and 201
<asac> here: http://ci.ubuntu.com/smokeng/trusty/touch/
<asac> ok dropping out ... cu tomorrow
<plars> asac: known bug being worked on: https://bugs.launchpad.net/qa-dashboard/+bug/1284298
<ubot5> Ubuntu bug 1284298 in Ubuntu CI Services "Need a way to timeout 'running' smoke jobs" [Undecided,New]
<bzoltan1> robru: ping
<bzoltan1> robru: I see an entry in the CI train for UITK. Was not it so, that I am the releasing dude for the UITK?
<bzoltan1> robru: That MR -> https://code.launchpad.net/~renatofilho/ubuntu-ui-toolkit/limit-alarms-fetch/+merge/207629 is not approved by the SDK team
<bzoltan1> renato: ping
<bzoltan1> Is anybody here from the CI?
<bzoltan> hello didrocks
<didrocks> hey bzoltan
<bzoltan> didrocks: In the Self service CI (CI train) I watched the line nro 38 with some surprise. Does robru know that the UITK releasing belong to me and my team? He was about to release an MR what was not even approved yet.
<didrocks> bzoltan: I don't know why he set himself as a lander. I told we are not lander for anything though
<didrocks> bzoltan: so, I'll talk again about this with him
<didrocks> bzoltan: the MP has landed bt
<bzoltan> didrocks: thank you
<didrocks> btw
<bzoltan> didrocks: I am preparing a new MR bundle for today ...
<didrocks> bzoltan: ok, just be aware (see emails) that we are not releasing anything that's not to fix all the issues we have on the image first
<bzoltan> didrocks: clear and +1 that
<mhr3> sil2100, y 29 no publish yet?
<didrocks> mhr3: we don't publish anything that impact touch
<didrocks> see the phone ML
<mhr3> hmm
* psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: psivaa | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but chooose right timezone | Landing instructions: http://goo.gl/8H1Du3 | Known Issues: -
<Laney> ralsina_: what was your rebuild in the updates silo about?
<Laney> also, can we retry builds in the landing PPAs?
<didrocks> Laney: you can request the ci team to do that if you don't want to rebuild the MP itself
<didrocks> Laney: some other people like pitti, rsalveti have access to it
<didrocks> you can have if you don't mind the spam :)
<Laney> https://launchpad.net/~ci-train-ppa-service/+archive/landing-010/+build/5633952
<Laney> you can give me it you want ;-)
<Laney> procmail is a beautiful thing
<didrocks> Laney: one sec, giving to you. please, if you need to dput to a ppa direclty some stuff, target the right one! :)
<Laney> hah
<didrocks> Laney: you have power!
<sil2100> Power \o/
<Laney> thanks didrocks!
<didrocks> yw ;)
<Laney> I guess the spreadsheet won't notice if the retry succeeds though
<Laney> 'watch only'?
<didrocks> exactly :)
<sil2100> didrocks: hmm, there's no morning meeting today?
<Mirv> omg my trusty is so borken today
 * sil2100 didn't get an e-mail
<didrocks> sil2100: hum, there is
<didrocks> I did receive it
<didrocks> https://plus.google.com/hangouts/_/calendar/Y2Fub25pY2FsLmNvbV91cTRvNmQyMWJvNmJ0bm1mcW9xZWtsNTdnOEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t.us2orfbhb8ssqjui2u15tajj3s
<sil2100> grrrr
<sil2100> didrocks: thanks
<popey> 20 seconds!
<popey> (ish)
<seb128> Mirv, what's the issue with trusty?
<didrocks> Mirv: can you come to the meeting or you are really really broken?
<Mirv> comig
<Mirv> sil2100: the lightdm thing is the same I saw at the sprint. but I have really no idea what has happened otherwise. I upgraded and did this stuff less than hour ago...
<Mirv> it's possible removing lightdm messed up /etc/group or something like that
<seb128> Mirv, what's the issue with lightdm?
<Mirv> seb128: the issue I've been seeing is a cosmetic one, some background parts like the machine name's turn to grey when pressing enter, ie the UI looks wrong. I got that fixed once by reinstalling lightdm including resetting its configuration.
<seb128> that doesn't make sense
<Mirv> seb128: the rest of my problems are probably related to lightdm removal scripts or such breaking up other things, plus the fact that installing lxde/gdm etc is not completely smooth either
<seb128> reinstalling a package makes no difference
<Mirv> seb128: it was a combination of things I don't remember all of which, but I thought to try again to find out what's the reason behind the UI ugliness
<psivaa> Mirv: https://jenkins.qa.ubuntu.com/job/trusty-touch-mako-smoke-daily/87/artifact/clientlogs/ubuntu_weather_app/
<psivaa> has the crash file
<Mirv> psivaa: thanks, got it
<tvoss> sil2100, ping
<sil2100> tvoss: pong!
<tvoss> sil2100, I guess we are meeting in an hour from now on?
<sil2100> tvoss: yep
<tvoss> sil2100, ack and thx :)
<sil2100> ;)
<didrocks> Mirv: is the qmlscene crash good enough to work on it?
<didrocks> Mirv: do not hesitate to involve the SDK team as well on that one :)
<Mirv> didrocks: it was not, for some reason, but I edited it manually to get backtrace which should be soon ready on the device
<didrocks> hgreat ;)
<Mirv> didrocks: the .crash was missing "Package:" line
<didrocks> ah ok
<didrocks> seems apport tried to report it without sucess
<didrocks> success*
<didrocks> (probably due to sdk in proposed)
<Mirv> and because I didn't start 'screen' on the device, I'm now stuck with LXDE and lxdm-binary consuming 100% CPU until the retrace is finished :P
<didrocks> ahah :)
<sil2100> didrocks: so, we're waiting for rsalveti to appear regarding the unity8 crashes - Saviq tried mapping the crash to a specific library, but it doesn't seem to be possible
<sil2100> didrocks: that memory range doesn't seem to be mapped to any library
<Saviq> didrocks, yeah, I can't get any symbol out of those :|
<Saviq> /we should build non-stripped system.imgs
<didrocks> Saviq: yeah, I was about to say that
<didrocks> Saviq: just build for one device
<didrocks> that will be quicker
<didrocks> (in case you are using the package)
<Saviq> didrocks, you'll have to give me more data on that
<didrocks> ok, one sec, downloading the source
<didrocks> I'll tell you what I did for this :)
<Saviq> didrocks, appreciated
<didrocks> Saviq: ok, so: debian/android-targets
<Saviq> didrocks, which pkg?
<didrocks> remove all lines you don't want :)
<didrocks> apt-get source android
<Saviq> right!
<Saviq> of course ;D
<didrocks> then in debian/rules
<didrocks> remove everything in the override_dh_install: after the dh_install call
<sil2100> That's hacky ;)
<didrocks> (the 2 tar commands)
<didrocks> rm debian/ubuntu-emulator*
<didrocks> as well
<didrocks> (even if that's not strictly needed)
<didrocks> so then build
<davmor2> Morning all
<didrocks> it will take only 15 minutes on my machines instead of 15 minutes*number of devices
<didrocks> wb davmor2!
<didrocks> Saviq: finally, just dpkg-deb -x android<yourdevice>.deb foo
<didrocks> you will have the img in foo/usrâ¦
<didrocks> sil2100: well, yeah, we should add more hacks to only build successfully for some sources :)
<didrocks> Saviq: you will need a 32 bits chroot, I was never have able to build it on x64 here
<Saviq> didrocks, oh ok good to know
<Saviq> didrocks, anything special I need to tell sbuild to not strip the binaries?
<didrocks> Saviq: the usual NOSTRIP (that you can hardcode in debian/rules while you are it to ensure ;))
<didrocks> and then, just something like sbuild -d trusty -c trusty-proposed+multiverse-i386 --arch i386 android_<version>-0ubuntu1.dsc -A should do it
<Saviq> didrocks, ok, going for it!
<didrocks> good luck, do not hesitate if you have any questoin
<didrocks> question*
<Saviq> didrocks, thinks we should consider building debug-enabled system.img as part of our image builds or do you think we could get -dbgsym packages out of it?
<didrocks> Saviq: I thinkg we should just create some -dbg and have system.img without being stripped part of that package
<didrocks> (I don't think we can automate that as -dbgsym)
<Saviq> didrocks, mhm, /me files bug
<sil2100> Yeaaa
<didrocks> but I'm maybe just on crack, I'm sure Ricardo is way more knowledgeable than I on that crazy package :) (I can understand the debian/rules though, so it's a start :p)
<didrocks> basically it's creating in your sbuild an armhf source
<didrocks> (so you have a chroot in chroot)
<Mirv> qmlscene bug #1284581 seems inside the (now obsolete) V8 engine of Qt
<ubot5> bug 1284581 in Ubuntu "qmlscene crashed with SIGSEGV in FindInlineFunctionGenerator()" [Undecided,New] https://launchpad.net/bugs/1284581
<didrocks> Mirv: I'm about to send an email with latest state, would you mind answering that?
<Mirv> didrocks: ok
<Mirv> I wonder if that's something Android 4.4 related
<Saviq> didrocks, bug #1284583
<ubot5> bug 1284583 in android (Ubuntu) "Should provide debug-enabled system.img" [Undecided,New] https://launchpad.net/bugs/1284583
<didrocks> Saviq: thanks, I'll discuss that once the firefighting is off with Ricardo
<ogra> hmm
<ogra> that will put quite some build time penalty on us
<Saviq> ogra, how often do we build that though?
<ogra> once or twice a month ... but if you are waiting for it to roll a test image it is annoying to wait 1h more :)
<ogra> how often do you actually need dbg symbols inside android ?
<ogra> twice a release for one specific arch ?
<Mirv> lightdm back, compiz still broken
<Mirv> seb128: oh, sorry, I managed to forget what triggered my tinkering with lightdm - after today's dist-upgrade + reboot, I was for some reason not able to type anything in lightdm
<Saviq> ogra, in lieu of that package, clear information on how to get it would be nice
<xnox> Saviq: one can trivially locally build android with debug symbols, but we can't ship a debug img easily as it's too big and unflashable.
<Mirv> mouse worked. now after this adventure also typing works, plus the funny UI issues are gone
<Saviq> xnox, unflashable? crap
<xnox> Saviq: thus one uses gdbserver, with debug symbols on the host and debug things over adb.
<ogra> Saviq, yeah, i would even vote to have a PPA with debug builds ...
<sil2100> Mirv: you can work-around that by clicking on one of the indicators and then clicking away
<xnox> Saviq: but since that relies on relative paths, one does a local android build with /detached/ symbols.
<ogra> xnox, the system.img should be fine
<Mirv> sil2100: aha... :D
<xnox> Saviq: flashes the images to devices and then does adb remote debugging with gdbserver.
<seb128> Mirv, oh, right, that's a quite frequently reported issue :/ you can use indicators to workaround the typing bug, that gives the focus back to the entry
<ogra> as it doesnt rely on y specific flash size
<sil2100> Mirv: you can then type normally - I have it like every second boot
<didrocks> Mirv: email sent
<ogra> (it lives inside the ubuntu rootfs)
<xnox> Saviq: i think rsalveti / sergiusens can guide you how to do it.
<Mirv> didrocks: ok
<ralsina_> Laney: barry asked for one
<xnox> Saviq: it's been a while since i last had to do it.
<Saviq> xnox, yeah, rsalveti is being waited on ;)
<xnox> =))))
<Laney> ralsina_: ah, well you can give a package name to just try that particular one (system-image in this case) to not use resources unnecessarily
<Laney> anyway, his stuff doesn't build :(
<didrocks> bzoltan: on https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/ubuntu-ui-toolkit-RC_2502/+merge/208064, the commit message is used to commit to trunk
<didrocks> bzoltan: and in the changelog
<didrocks> a better description will be needed I guess :)
<t1mp> bzoltan: that MR itself won't be merged right?
<bzoltan> t1mp: didrocks:  that is just a testing MR, not meant to land
<bzoltan> t1mp: didrocks: what I proposed to land is in the CI sheet
<didrocks> bzoltan: ah ok :)
<t1mp> bzoltan: ok, clear. that's what I thought :)
<bzoltan> t1mp: didrocks: I want to be sure that there are no conflicts between the MRs
<t1mp> bzoltan: ++
<didrocks> bzoltan: sure sure, you just frightened me :)
<bzoltan> didrocks: Sorry for that :)
<didrocks> heh, no worry :)
<bregma> didrocks, shall we move the OIF packages under ci-train or should I just move them to regular Debian-sync releases?
<didrocks> bregma: I would say citrain
<bregma> of course you would, I didn;t expect any other answer :)
<didrocks> why did you ask then? :p
<didrocks>  bregma: btw, I fixed my unity issues
<didrocks> was due to the decor plugin still loaded
<didrocks> however
<didrocks> now, I have no more Ctrl + Alt + T working :/
<sil2100> bregma: oh! I see unity7 landing is ready to be assigned a silo
<bregma> sil2100, yeah, I just did than, need a silo if you please
<seb128> bregma, sil2100: wait
<sil2100> seb128: too late, silo assigned ;/
<bregma> seb128, is there a fix from xnox about to appear?
<sil2100> seb128: we can reconfigure in a moment
 * sil2100 was trigger-happy
<seb128> bregma, https://code.launchpad.net/~xnox/unity/no-debug-symbols/+merge/208093 from this morning
<seb128> sil2100, no worry, I just want debug symbols to be fixed with that landing
<sil2100> bregma: can you add that to the MP list if needed ^ ?
<didrocks> seb128: do we know what changed? the default CFLAGS doesn't have -g now?
<bregma> sil2100, added, does the silo need a reconfigure?
<sil2100> Yes, reconfiguring
<seb128> didrocks, I don't know, https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1284047/comments/1
<ubot5> Ubuntu bug 1284047 in unity (Ubuntu) "Build stripped binaries, lead to missing debug symbols" [High,Confirmed]
<didrocks> seb128: yeah, I just read your command, but seems changing changed on the default CFLAGS anyway
<didrocks> I guess there are quite some impacts on various packages
<bregma> didrocks, I've run into that same problem in other packages, it seems there was a change to debhelper at some point
<didrocks> bregma: interesting, ok
<bregma> it explicitly says to not set CFLAGS, so the packaging was broken before and just happened to work
<seb128> bregma, didrocks: http://irclogs.ubuntu.com/2014/02/24/%23ubuntu-devel.html#t10:56
<seb128> "debhelper changed to BuildType=None, that might affect cmake based projects..."
<seb128> not sure that's the issue there though
<seb128> didrocks, bregma: the default flags seems to be fine, it's the hackery in debian/rules which is buggy (otherwise dropping those lines wouldn't be enough to fix it)
<didrocks> seb128: ah, thanks :)
<didrocks> yeah, at the time, it was the only way to remove -Wall though
<bregma> I had the problem with an autotools project that set CFLAGS in the debian/rules file, it started losing hardening and debug flags after the build toolchain was upgraded after the last Debian release
<bregma> fact is, Unity doesn;t need those fancy build flags any more, so good riddance
<seb128> k
<didrocks> yep :)
<Saviq> didrocks, hey, so I got:
<Saviq> ubuntu-android-ramdisk+mako.img
<Saviq> ubuntu-preinstalled-boot-armhf+mako.img
<Saviq> ubuntu-preinstalled-recovery-armel+mako.img
<Saviq> ubuntu-preinstalled-system-armel+mako.img
<Saviq> ubuntu-ramdisk+mako.img
<Saviq> ubuntu-ramdisk-recovery+mako.img
<Saviq> I assume -system- is what I want to flash, anything else?
<didrocks> Saviq: yeah, I don't think you segfaulted on the recovery :p
<didrocks> and the ramdisk are included in the preinstalled ones
<Saviq> didrocks, and the corresponding ubuntu-*tar.xz as rootfs?
<didrocks> Saviq: no, the system img is what you need alone
<Saviq> didrocks, can I flash the system.img alone?
<ogra> no
<didrocks> ogra: there will be a mismatch?
<ogra> it lives inside the ubuntu system.img file
<ogra> flashing it wont gain you anything
<didrocks> oh right
<didrocks> you need to rebuild the image with it
<didrocks> argh
<ogra> you need to boot into recovery, loop mount /userdata/system.img and then put the android system.img file into /var/lib/lxc/android in there
<Saviq> ogra, ok, trying
<didrocks> ogra: if you do that once booted, do you expect to see bad things happening with libhybris?
<ogra> (in recovery mode it is actually /data/system.img iirc)
<ogra> didrocks, nope, as long as the hybris version is still the same
<ogra> same goes for the kernel
<didrocks> ok :)
<ogra> (the modules live inside the android system.img)
<didrocks> ok
 * Saviq is worried there's no symbols
<Saviq> same size :/
<sil2100> ;/
<Saviq> no booting grr
<didrocks> ogra: are you sure not flashing the system partition is correct? We don't use anything from it, right?
<didrocks> ogra: because https://wiki.ubuntu.com/Touch/Building doesn't match
<ogra> thats for the old flipped model
<ogra> not for system-image
<didrocks> ogra: should probably be updated :) do we have one for system-image with similar instruction?
<ogra> i dont think so
<Saviq> didrocks, didn't boot :|, /me wonders if 207 would help
<didrocks> Saviq: I don't think it would especially help, if you are already on 207â¦
<didrocks> ooppss
<didrocks> on 206
<didrocks> I meant
<Saviq> didrocks, but anyway, the file should be bigger, shouldn't it :|
<didrocks> yeah, it should
<didrocks> the aosp build system is complex, not sure they respect our flagsâ¦
<Saviq> didrocks, yeah, I'm waiting for Ricardo
<Saviq> he'll do it in 5s
<didrocks> yep, sounds better :)
<ogra> smells like you missed some build option when rolling the android package
<Saviq> added to debian/rules:
<Saviq> export DEB_BUILD_OPTIONS=nostrip noopt debug
<Saviq> and commented out all emulator-related things
* cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but chooose right timezone | Landing instructions: http://goo.gl/8H1Du3 | Known Issues: -
<alan_g> cjohnston: Our (Mir) CI has started failing all MPs. Can you tell if something changed? https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/
<didrocks> ogra: we don't use trusty-preinstalled-touch-armel+mako.zip    anymore, right?
<didrocks> in system-image
<ogra> nope
<cjohnston> looking
<ogra> but some ports do ...
<ogra> (which is why i didnt remove it yet from the build)
<didrocks> yeah
<cjohnston> alan_g|lunch: I don't see anything that changed. I'm wondering if a release of something else maybe effected it
<cjohnston> alan_g|lunch: I'll ask fginther to look when he comes around
<rsalveti> morning
<rsalveti> didrocks: Saviq: still checking emails, do you have a crash file available and how to reproduce the crash easily?
<rsalveti> didrocks: ogra: awesome, dashboard for 207 looks way better
<rsalveti> the pulse fix I did yesterday still didn't land
<ogra> well, kind of
<rsalveti> that will reduce cpu usage as well
<rsalveti> ogra: well, system-settle is better (not sure if fixed :-)
<ogra> rsalveti, we seem to have set CONFIG_RT_GROUP_SCHED in our kernel ... seems that prevents rtkit-daemon from functioning
<didrocks> rsalveti: I don't have the crash file handy, Saviq has one
<ogra> system-settle was re-written
<didrocks> rsalveti: yeah, you are hit by beta freeze
<rsalveti> ogra: is that preventing or are we missing some other options?
<didrocks> rsalveti: otherwise, not a lot of progress overall (see my email entitled "summaring up issues on current touchâ¦")
<ogra> rsalveti, seems it is preventing on purpose if i read the docs right
<rsalveti> yeah, we'll get more fixes til end of my day
<rsalveti> :-)
<rsalveti> ogra: oh, ok
<ogra> rsalveti, waiting for stgraber to show up, he should know if we need that option at all
<ogra> i assume having pulse in rt mode will give us some boost in audio stuff :)
 * ogra would love if the kbd even made click sounds when you type fast)
<rsalveti> hahah
<ogra> it kind of looses it if you get to a certain typing speed
<ogra> rsalveti, oh, and hammerhead ucm files uploaded ;)
<rsalveti> ogra: \o/
<ogra> not final but at least people have sound
<rsalveti> that's awesome anyway
<ogra> and comes fully from the community ... thats what i like most about it
<ogra> :)
<rsalveti> yeah
<Saviq> rsalveti, yes I've a .crash (plenty of them, actually)
<Saviq>  rsalveti, way to repro: phablet-test-run -p unity8-autopilot -n unity8
<Saviq> rsalveti, but if possible and you have some time, I'd like to learn how to tackle this next time
<rsalveti> Saviq: basically https://wiki.ubuntu.com/Touch/Core/UbuntuDebugAndroid
<rsalveti> Saviq: but first you'd need a local build of your android
<rsalveti> then you can get the libs with debug symbols (we should probably be exporting that somehow via android-dbg
<rsalveti> I'll try to get to that later this week)
<rsalveti> repo init -u https://code-review.phablet.ubuntu.com/p/aosp/platform/manifest.git -b phablet-4.4.2_r1
<rsalveti> repo sync
<rsalveti> source build/envsetup.sh
<rsalveti> lunch aosp_mako-userdebug
<rsalveti> that should get you the 4.4 based images
<Saviq> rsalveti, bug #1284583 btw :)
<ubot5> bug 1284583 in android (Ubuntu) "Should provide debug-enabled system.img" [Undecided,New] https://launchpad.net/bugs/1284583
<rsalveti> Saviq: thanks
<Saviq> rsalveti, but yeah, problem is... http://pastebin.ubuntu.com/6993715/
<rsalveti> right, smells like android
<Saviq> rsalveti, also, you can't get the map if you only got a .crash file
<rsalveti> interesting that I coudn't get any crash when running the autopilot test this weekend
<Saviq> rsalveti, it doesn't always happen
<rsalveti> oh, I thought you had procmaps in there
<Saviq> rsalveti, ah you're right
<Saviq> in the .crash directly
<Saviq> rsalveti, once in every 20-30 runs
<rsalveti> got it
<rsalveti> Saviq: can I get your crash file as well
<rsalveti> ?
<Saviq> rsalveti, of course
 * Saviq preprocesses
<Saviq> rsalveti, and how do I get a symbolized local build? we actually tried to build a complete system.img with nostrip, but that didn't work (same .img file size, and didn't boot anyway)
<rsalveti> Saviq: yeah, need to change the build rules internally
<rsalveti> that's what I'm planning to do to fix your bug
<Saviq> rsalveti, so yeah, problem with the maps part is that, according to what I was able to find, no library is actually mapped at the address where it crashed :/
<rsalveti> oh, hm
<rsalveti> could this be mir related?
<rsalveti> I know we had tls issues with mir as they are heavily using tls with c++11 now
<Saviq> rsalveti, one thing I know is the crash happens after libcrypto causes SIGILL
<Saviq> if that has any bearing
<rsalveti> hm, that always happens
<rsalveti> when it's testing for supported features
<Saviq> rsalveti, yeah I know, just saying
<rsalveti> yeah, I got annoyed by that once already
<Saviq> rsalveti, http://people.canonical.com/~msawicz/_usr_bin_unity8.32011.crash
<Saviq> rsalveti, so yeah, as you can see maps doesn't mention anything :|
<Saviq> rsalveti, that's why /me wanted a fully symbolic system.img, if at all possible :|
 * sil2100 jumps out to the vet again, quickie
<Saviq> sil2100, lol
<fginther> alan_g, looking at the mir failures. the only difference I see so far is that there is a new libc version in the builds that are failing tests
<alan_g> fginther: alf_ wonders if it could be related to https://bugs.launchpad.net/mir/+bug/1284653
<ubot5> Ubuntu bug 1284653 in valgrind (Ubuntu) "valgrind packages ouf of sync with current glibc version (2.19)" [Undecided,New]
<fginther> alan_g, hmmm, libc went from libc6_2.18-0ubuntu7_amd64.deb to libc6_2.19-0ubuntu2_amd64.deb
<fginther> alan_g, ok, based on this bug, it looks the issue has been identified. Can you work with the foundations team to get a new valgrind built?
<alan_g> kgunn: ^^
<kgunn> alan_g: fginther ...yep, trying to get someone to reply :)
<fginther> kgunn, thanks!
<Saviq> rsalveti, so... I'll be your PITA today, can you point me anywhere which would tell me how to actually nostrip system.img?
<rsalveti> Saviq: no worries, getting dedicated to your issue now
<rsalveti> didrocks: diwic found why pulse is always consuming ~2% of the cpu, and he found the fix as well
<rsalveti> didrocks: should hopefully land in the archive later today
<rsalveti> better battery life as well :-)
<didrocks> rsalveti: excellent, let's hope we can convince the release team to accept it despite the beta freeze :)
<rsalveti> yeah
 * didrocks really goes for a run before it's raining
<ogra> just wait, will save you the shower afterwards
<ogra> (take some shower gel with you though)
<thostr_> sil2100: can i get a silo for line 30?
<rsalveti> Saviq: I think this is all you need to have a not-stripped image: http://paste.ubuntu.com/6994774/ (at build/)
<rsalveti> Saviq: checking still
<Saviq> rsalveti, /me builds
<rsalveti> argh, still stripping
<rsalveti> Saviq: you also need the vendor files which I forgot: bzr branch lp:~rocket-scientists/aal+/aosp-vendor-4.4.2 vendor
<rsalveti> let me do a clean build as well
<sil2100> thostr_: let me see
<Saviq> rsalveti, and where do I put the vendor files?
<rsalveti> Saviq: builddir/vendor
<rsalveti> builddir is your build dir root directory
<Saviq> rsalveti, I'm actually in `apt-get source android`
<rsalveti> Saviq: oh, if you rebuild that it'll work fine, as it copies the files from the android-src-vendor package
<rsalveti> Saviq: worked, not stripping anymore
<Saviq> rsalveti, so just the TARGET_STRIP_MODULE=?
<rsalveti> just apply as a package patch http://paste.ubuntu.com/6994804/
<sergiusens> doanac`, hey, did you get my message last night about the ap args MR? still needs to rebase with xnox's changes
<xnox> sergiusens: hm? anything needed from me?
<sergiusens> xnox, not really; just push doanac` to merge to get your stuff in
<Saviq> rsalveti, ok, and then I put the resulting system.img into loop-mounted system.img at /var/lib/lxc... and that should be it, right?
<pmcgowan> fginther, is anyone from CI team assigned to qt5.2 related issues?
<fginther> pmcgowan, not specifically that I'm aware of. ev, doanac`, plars, psivaa ^
<pmcgowan> fginther, if not I would like someone to be, to help tracking during the landing
<psivaa> fginther: pmcgowan: could be Mirv
<psivaa> Mirv: apologies if you're not :)
<pmcgowan> psivaa, well we need someone from the CI team to help Mirv
<doanac`> sergiusens: forgot about the MP. i'll get it updated this morning.
<fginther> pmcgowan, I'll follow up with ev
<pmcgowan> fginther, thanks
<doanac`> sergiusens: branch is updated now. thanks
<sergiusens> great doanac`
<rsalveti> Saviq: yes
 * rsalveti back from lunch
<rsalveti> Saviq: were you able to build the image?
<rsalveti> Saviq: getting forbidden at your crash file
<Saviq> rsalveti, yeah, just built, needed 40 mins, doesn't want to use ccache somehow
<Saviq> rsalveti, grr, try again
<rsalveti> thanks, downloading now
<Saviq> rsalveti, stoopid people.c.c and its umask
* doanac` changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: doanac | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but chooose right timezone | Landing instructions: http://goo.gl/8H1Du3 | Known Issues: -
<Saviq> rsalveti, so yeah, not booting :/
<Saviq> got a 0123456789ABCDEF        device
<rsalveti> Saviq: anything in logcat?
<Saviq> rsalveti, "android isn't running" when tried to get into lxc-console
<Saviq> lxc-start: failed to run pre-start hooks for container 'android'.
<rsalveti> right
<rsalveti> can you check if logcat tells you something?
<rsalveti> let me try to boot my image
<Saviq> rsalveti, how do I logcat without android running?
<Saviq> /bin/bash: line 0: exec: logcat: not found
<ogra> /system/bin/logcat
<Saviq> [  321.857652] EXT3-fs (loop1): error: can't find ext3 filesystem on dev loop1.
<Saviq> [  321.939844] EXT2-fs (loop1): error: can't find an ext2 filesystem on dev loop1.
<Saviq> [  322.009766] EXT4-fs (loop1): VFS: Can't find ext4 filesystem
<Saviq> [  322.069677] adjust_soc: ibat_ua = -92200, vbat_uv = 4234436, soc = 100, batt_temp=331
<Saviq> [  322.079810] FAT-fs (loop1): bogus number of reserved sectors
<Saviq> [  322.079902] FAT-fs (loop1): Can't find a valid FAT filesystem
<Saviq> ogra, no such file
<Saviq> seems the generated system.img isn't mountable
<ogra> oh, ah
<ogra> wait a sec
<ogra> bzr branch lp:project-rootstock-ng
<ogra> Saviq, take a look at the "convert_android_img()" function
<ogra> you want to do this first
<rsalveti> oh, right
<rsalveti> you need simg2img first
<ogra> android-tools-fsutils
<ogra> install that
<sil2100> o_O
<ogra> system-image converts the img file
<Saviq> it grew to 840M...
<Saviq> but yeah, that's mountable
<rsalveti> lol, yeah
<rsalveti> you probably want resizefs as well
<Saviq> ok, that's better
<didrocks> ogra: no, I still need a shower :) using some gel on the bicycle on the way back will be my next goal I guess :)
<sergiusens> doanac`, so now that it's built can you check https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=21 against with your ci stuff?
<ogra> optimization ftw :)
<didrocks> heh
<didrocks> ogra: well, not too much, yesterday I almost got a car/bike unattending meeting
<didrocks> (and I was the bike)
<ogra> ouch
<didrocks> yeah, one way road, by bike are two ways
<didrocks> when cars arrive on that road, they tend to only look at one directionâ¦ not both
<Saviq> yay! we have a boot!
<didrocks> there is a huge line drawn to say look at the bikes on the other side, but they don'tâ¦ So I'm careful most of the time
<didrocks> but this car was just racingâ¦
<didrocks> Saviq: so booting a 840M android image? :p
<doanac`> sergiusens: ack.
<Saviq> didrocks, no, 250M
<didrocks> ah ;)
<didrocks> still 5 times more
<Saviq> didrocks, no
<Saviq> didrocks, just twice
<Saviq> didrocks, it's 107M currently
<didrocks> ah, uncompressed, I was talking about the .zip size
<Saviq> the stock one, that is
<didrocks> yep
<Saviq> yikes reports.qa is slow these days :/
<rsalveti> yeah
<didrocks> ogra: what does simg2img practically speaking? (no manpage, no --help)
<ogra> sparse image to image
<sergiusens> Saviq, it is, use the internal one through the vpn
<seb128> didrocks, sil2100: l42 has the indicator-datetime fixes-only landing ready
<ogra> sparse is a special format android uses ... theoretically it should be growable
<rsalveti> Saviq: yeah, crashed in the heap, so might not be android related after all
<rsalveti> Saviq: wonder if it could be tls related
<didrocks> ogra: ah, and so, we convert to ext4?
<sil2100> seb128: sure
<ogra> didrocks, right, so we can mount it
<Saviq> rsalveti, got a fresh .crash, let's see if I get anything...
<didrocks> ogra: got it!
<Saviq> rsalveti, no dice ;(
<didrocks> Saviq: I guess you have as well the qt dbgsym?
<Saviq> didrocks, it doesn't even get to qt
<seb128> sil2100, thanks
<didrocks> Saviq: sometime, for some unknown reasons, I saw some smashed stacktrace
<didrocks> somtimes*
<didrocks> with only 2 frames
<didrocks> installed the qt debug symbols
<sil2100> grrr
<didrocks> and then, the stacktrace is readable and has more frames
<Saviq> ok /me does again
<rsalveti> Saviq: still heap?
<didrocks> I have NO idea how this is possible if you ask me :)
<rsalveti> Saviq: how could you easily reproduce that again? running autopilot?
<rsalveti> Saviq: joining meeting as well?
<Saviq> rsalveti, yeah, and yeah
<didrocks> rsalveti: yeah, it's triggering it
<rsalveti> great, testing with a fresh image now
<Saviq> rsalveti, yeah, heap, and still no symbols
<rsalveti> yeah, hate those crashes
<rsalveti> we had similar issues with tls and gcc 4.7 x gcc .48
<rsalveti> 4.8
<rsalveti> ports is so slow for me :-(
<sil2100> Then we're still in the blind ;/
<rsalveti> not necessarily
<ogra> rsalveti, us.ports.u.c isnt better ?
<rsalveti> ogra: not much, probably because of ricmm
<rsalveti> haha
<ogra> ah, right
<ogra> he trades the bytes for toilet paper
<asac> printfs :/
<rsalveti> I believe this might be tls related
<rsalveti> or could be a side effect of forcing stuff to gcc 4.7 / 4.8
<asac> are there other ways we can extract some info? valgrind, lttng etc.?
<rsalveti> valgring should help, but the problem is that it only happens when running autopilot
<ogra> pliers
<asac> rsalveti: why is autopilot conflicting with the valgrind idea?
<rsalveti> asac: not conflicting, but autopilot is running a bunch of tests, not only one that we can also run separately and get the crash
<asac> right, but maybe valgrind always complains about stuff that later will cause this problem
<rsalveti> could be
<asac> so we might see it without reproducig it
<rsalveti> autopilot is still running here
<asac> rsalveti: what did we do to force stuff to 4.7?
<ogra> add a build dep
<rsalveti> asac: platform-api is using 4.7, because it's the same compiler used by the android package
<rsalveti> together with that we're also building other packages with 4.7,like location-service
<rsalveti> but we know we had heap issues when mixing both things together
<didrocks> especially if you use C++11 features
<rsalveti> like stuff built with 4.8 using platform-api that was built with 4.7
<rsalveti> and we know that mir is now using tons of c++11 stuff
<didrocks> (we have already been hit by that with 4.6 vs 4.7)
<didrocks> gcc upstream fixed the ABI breakage, but not sure something else didn't slip in again
<rsalveti> well, but that was fixed with 4.8
<rsalveti> that's why it's so annoying
<didrocks> so you think they rebreak the ABI the other way around?
<didrocks> to be compatible with 4.6?
<asac> so looking at latest image run, it seems the systemsettle dragon did fly away? or did we adjust the threshold?
<rsalveti> abi was fixed with 4.8, that's why we have issues when mixing stuff built with 4.7
<didrocks> ok
 * didrocks remembers a nice nux vs unity7 explosion at the time
<asac> you cant mix C++ stuff from differnet gcc versions
<didrocks> asac: you should be able to as per upstream says
<asac> maybe we still have 4.6 mixed in?
<asac> :)
<rsalveti> no, hope not
<rsalveti> lol
<asac> seems systemsettle is indeed again at > 99
<tvoss> rsalveti, so Mir is bringing in 4.8 to the platform api, correct?
<rsalveti> tvoss: yes
<rsalveti> is unity8 using platform-api as well?
<rsalveti> maybe indirectly
<tvoss> Saviq, is unity8 using the mir-server implementation of platform-api?
<Saviq> tvoss, it's using the ubuntumirserver QPA, so I'd say yes
<tvoss> Saviq, rsalveti and at that point we have got a 4.7 x 4.8 mixture iirc
<rsalveti> Ran 46 tests in 962.789s
<tvoss> iiuc even
<rsalveti> OK
<rsalveti> Restoring shell
<rsalveti> Saviq: ^
<rsalveti> let me try again
<ogra> asac, yeah, we just hardcoded that :P
<Saviq> rsalveti, yeah, *sometimes* it works
<Saviq> rsalveti, I mean it crashes maybe 5% of the time
<asac> ogra: who gets the ida to hardcode a value that is not 100%? :)
<tvoss> Saviq, rsalveti if it's a race, valgrind might help
<asac> ogra: its 99.4 ... what a crazy idea :)
<asac> or is there any insider meaning on 99.4?
<ogra> asac, carefule people that know that you will look ;)
<asac> :)
<asac> lol
<rsalveti> lol
 * Saviq is down to 15M free on rootfs...
 * ogra is silly today ... that what reading cgroup docs all day does to you
<asac> err
<Saviq> no, actually 8.1M
<rsalveti> you could resize from recovery
<ogra> Saviq, du -hcs /var/log/*
<ogra> ;)
<rsalveti> ricmm got the statically-linked recovery binary
<ogra> rm -rf /var/log/*
<rsalveti> rm -rf /
<rsalveti> DONE
<rsalveti> :P
<Saviq> ogra, that's not rootfs ;)
<ogra> :)
<sil2100> Crap, meeting!
<ogra> Saviq, oh, the android system ?
<Saviq> ogra, no, ubuntu
<Saviq> ogra, /var* is rw-mounted, isn't it?
<Saviq> aaaaanyway
<ogra> it is
<asac> plars: how long do we wait for the top now?
<Saviq> no dice
<Saviq> #0  0x39c0d8f8 in ?? ()
<Saviq> No symbol table info available.
<Saviq> #1  0x39c2d7e8 in ?? ()
<Saviq> No symbol table info available.
<sil2100> hm hm
<rsalveti> Saviq: can you try the following patch: http://paste.ubuntu.com/6995323/
<plars> asac: I changed systemsettle yesterday so that we no longer use top to find the idle%, we use /proc/stat instead. Top is still used (same timings as before) to get data that can be used to see what was eating cpu though
<rsalveti> under builddir/bionic
<rsalveti> I can upload the image as well
<Saviq> rsalveti, will do, building
<asac> plars: sure, saw your commit... wonder if we also changed parameters for top_wait etc.
<plars> asac: no, but there's a new parameter for the sleep between the /proc/stat snapshots. Default is 10 seconds (and it runs at each iteration as it would have when we use top) but it's configurable.  So basically it's sampling cpu usage for 10 seconds each iteration
<Saviq> rsalveti, that's probably the time for you to tell me how to *not* build the package every time, as it takes 40 mins...
<rsalveti> Saviq: first thing, are you only building for mako?
<Saviq> rsalveti, yes
<rsalveti> then yeah, only using ccache to be faster
<Saviq> rsalveti, having followed didrocks' pointers on that
<rsalveti> or just rebuilding without building the entire package
<Saviq> rsalveti, well, yeah, I'm gonna go that way, dpkg-buildpackage -nc FTW
<rsalveti> using lunch then make
<rsalveti> :-)
 * Saviq wonders why ccache in sbuild didn't cut it
<rsalveti> argh, also got a crash when changing tls, but also in the heap
<Saviq> libcaca? like wth does android use libcaca for!?
<didrocks> rsalveti: yeah, I just have some hackish way to change debian/rules to just build for one device :)
<rsalveti> let me try to disable android tls for arm, just like we do for x86 now
<rsalveti> if we still get a crash, then it's not hybris
<Saviq> rsalveti, I like it how you build a chroot in those debian/rules ;d
<rsalveti> haha, yeah
<rsalveti> xnox created most of that logic
<ogra> we have some really weird package hacks in touch :)
<ogra> if you want to see the worst, take a look at initramfs-tools-ubuntu-touch's build :)
<xnox> rsalveti: i claim no ownership, it's all copied off other dodgy corners of our archive =))))
<ogra> fakeroot and fakechroot stacked chroots building an initrd for arm on x86
<balloons> sil2100, I have a potential fix for the terminal issue
<rsalveti> xnox: :-)
<xnox> Saviq: you can limit that package to only build flavour you are after to cut down the time....
<sil2100> balloons: !
<Saviq> xnox, I did
<xnox> Saviq: oh, i see =) sorry.
<sil2100> balloons: you were able to reproduce it? What was the problem?
<xnox> we may still build things we don't use =/
<Saviq> xnox, but I built in a ~clean sbuild every time, so it still took quite some time
<Saviq> xnox, for some reason it doesn't use ccache
<xnox> Saviq: there is little to cache.... and it tends to eat up more that cache provides.
<xnox> Saviq: it takes ~35 minutes to build everything on my machine.
<Saviq> xnox, everything?
<xnox> Saviq: yes, i build in RAM.
<Saviq> xnox, as in all the targets?
<Saviq> xnox, yes, /me too
<xnox> yes.
<balloons> I haven't reproduced, but I suspect the issue is with the app catching the touch event.
<Saviq> xnox, quad-core i7 with HT
<xnox> 32GB ram + parallel 12.
<Saviq> ok well
<Saviq> still shouldn't be that much
<Saviq> took 40 mins last time :/
<xnox> Saviq: crank up DEB_BUILD_OPTIONS=parallel=x, to floor(RAM in GB/2)
<xnox> Saviq: well, at the time it was 4 products, not sure how many it builds these days.
<balloons> what we can do is clean up the test to assert a bit better about where the failure actually occurs to narrow this down
<Saviq> xnox, 5 these days
<balloons> and if the touch event isn't being captured, we can decide if it's an issue with the platform, or if we need to work around the timing issue
<Saviq> xnox, and I usually use -j9
<balloons> I'll tweak it a bit, and try it out.. phone is flashing new image now
<xnox> Saviq: i find overcommitting to perform better, monitor the load if it's less than number of cores, you are stalling.
<balloons> sil2100, sorry see my responses mixed above ^^ :-)
<Saviq> huh... 80% idle at -j12... pfft!
<sil2100> balloons: makes sense ;) We would at least know if it's really the case once it actually happens
<sil2100> balloons: since so far from the logs all seemed ok
 * Saviq wonders if byobu doesn't slow it down at that point...
<balloons> sil2100, right, I was talking with bfiller_afk about the dialer app tests which had a similar thing.. the tests don't fail well, that is to say it's ambiguous as to what failed.
<Saviq> xnox, hmm hmm, does it actually build in parallel for you?
<Saviq> xnox, make[1]: warning: jobserver unavailable: using -j1.  Add `+' to parent make rule.
<rsalveti> Saviq: in case you want to disable android tls http://paste.ubuntu.com/6995480/
<rsalveti> that will force it to use pthread_set/getspecific instead
<xnox> Saviq: it used to.... can you paste full build log to paste.ubuntu.com for me to check?
<rsalveti> last time I built the package I built all in parallel
<rsalveti> it uses make now
<Saviq> xnox, grr, just cleared the old logs...
<Saviq> xnox, will get it to you asap
<xnox> Saviq: well, whenver you build it again =)
<rsalveti> while true; phablet-test-run -p unity8-autopilot -n unity8; done;
 * rsalveti waits for the crash
<xnox> =)))))))))))))
<xnox> should have added "; alert" at the end.
<xnox> rsalveti: to get the bubble notification.
<rsalveti> lol, indeed
<rsalveti> got that alias as well
<xnox> it's default on all ubuntus i believe =)
<rsalveti> oh, awesome
<rsalveti> Saviq: got the same crash with android tls disabled :-(
<rsalveti> so good and bad news
<Saviq> I=0; while true; do I=$(( $I +1 )); echo -n "$I: "; if phablet-test-run -n unity8 &> /dev/null; then echo OK; else echo BAD; fi; done
<Saviq> and on device:
<Saviq> while true; do echo -n .; if ls /var/crash/*.crash &> /dev/null; then ps aux | grep apport | grep -v grep &> /dev/null && continue; echo; STAMP=$(date +%s); mkdir $STAMP; mv /var/crash/*crash $STAMP; ls $STAMP; fi; sleep 2; done
<Saviq> rsalveti, and syntax error near: phablet-test-run :P
<rsalveti> Saviq: yeah :P
<Saviq> rsalveti, right, so any idea about next steps?
<rsalveti> got another crash, checking
<Saviq> xnox, http://paste.ubuntu.com/6995550/ partial, but should maybe be enough for you to see
<rsalveti> yeah, heap again
<xnox> Saviq: you don't set parallel option at all.....
<xnox> Saviq: hence a serial -j1 build is enforced.
<Saviq> xnox, sbuild -j9 usually did that for me?
<xnox> Saviq: no, that doesn't work for a few releases now.
<Saviq> xnox, oh!
<xnox> Saviq: in ~/.sbuildrc, update $build_environment
<xnox> Saviq: e.g. $build_environment = { 'DEB_BUILD_OPTIONS' => 'parallel=12'};
<Saviq> xnox, you must be kidding me ;P
<rsalveti> xnox: is there any way to also produce a 4.8 based gcc-arm-linux-androideabi?
<xnox> Saviq: ditto in ~/.bash_aliases i have: export DEB_BUILD_OPTIONS='parallel=12'
<Saviq> xnox, in _aliases?
<xnox> rsalveti: sure, i can build a 4.8 based one. I was thinking that maybe platform-api is enforced to 4.7, because of all of android built using 4.7.
<rsalveti> xnox: exactly
<rsalveti> xnox: but wanted to give android a try with 4.8
<xnox> Saviq: yeah, it's sourced by default in ~/.bashrc, and it means that I can replace ~/.bashrc with a stock one from /etc/skel easily =)
<Saviq> xnox, yup
<xnox> rsalveti: ack. I'm working on updating all cross-compilers, i'll ping you ones i have the ones you are after.
<rsalveti> Saviq: is the autopilot test using the system-compositor as well?
<rsalveti> xnox: awesome
<xnox> rsalveti: x86-android fails to compile binaries for me, investigating, spinning up a 4.8 for arm-android should be quicker.
<rsalveti> yeah
<Saviq> rsalveti, nope
<xnox> (2 down, 5 to go....)
<rsalveti> Saviq: but are we disabling it before running the tests?
<rsalveti> or better, should we?
<Saviq> rsalveti, it shouldn't matter, it just displays fullscreen unity8 these days, doesn't it?
<rsalveti> Saviq: right, but wonder if we could have issues with the framebuffer somehow as we'd have 2 servers running at the same time
<Saviq> rsalveti, could be, I wasn't really involved in the u-s-c enabling, didn't know it even happened
<rsalveti> right
<Saviq> ok now it's definitely byobu slowing it down ^_^
<Saviq> /my terminal stopped responding :D
<rsalveti> Saviq: I'd also give it a try without u-s-c
<rsalveti> meanwhile I'm rebuilding plat-api
<ogra> as long as unity8 is stopped via upstart u-s-c should be fine
<rsalveti> ogra: but I don't think unity8 autopilot tests are actually using u-s-c
<rsalveti> it starts/stops unity8 a bunch of times
<ogra> why would that matter ?
<rsalveti> and probably starting it by hand, not using u-s-c mir socket
<ogra> AP only generates user input, no ?
<ogra> yeah, that would be evil
<ogra> thats why i said via upstart is fine
<Saviq> rsalveti, ogra, yeah, we're doing it via upstart
<ogra> then you got the socket and all
<rsalveti> alright, then it should be using u-s-c
<Saviq> now that's better
<Saviq> xnox, I think -jfoo still works, but I added an export of DEB_BUILD_OPTIONS to debian/rules temporarily, and that overrode it
<rsalveti> zzzz, 15kb/s from ports
<Saviq> rsalveti, apt-cacher-ng ftw, let me know if you need me to try anything
<rsalveti> Saviq: just going to rebuild platform-api and location-service to use 4.8 instead
<Saviq> rsalveti, mhm
<asac> rsalveti: dont you use the US mirror?
<asac> thought we had that set up for you americans
<rsalveti> yeah, but that's also slow for me today
<rsalveti> probably because of venezuela
<rsalveti> lol
<rsalveti> the main cable still goes via venezuela
<Saviq> and ricmm isn't here to blame 'im
<rsalveti> exactly, already pinged him twice
<asac> robru-is-dying: is dying better than deathly?
<rsalveti> he's probably fighting the government
<robru-is-dying> asac, 'robru-is-deathly-ill' didn't fit, but i wasn't aware of the limit until i tried.
<asac> robru-is-dying: isnt deathly the active (e.g. you are killing)? :)
<asac> ah ok
 * robru-is-dying seriously though is going to lie down for a bit
<asac> robru-is-dying: get better
<asac> robru-is-dying: who can sasign silos etc. in case a good fix comes up?
<asac> cyphermox: ?
<asac> cyphermox: will you be around for a bit?
<Saviq> find [...] -o -name DEADJOE ?Â¿???
<cyphermox> asac: just about to go out to get lunch
<asac> cyphermox: but will be back, right?
<cyphermox> I'll be back in an hour or so
<cyphermox> yes
<asac> cool. dont let us down :)
<asac> enjoy!
<asac> cyphermox: you are last man standing with full powers
<asac> :)
<cyphermox> until dinner, and then back again until very late
<asac> but we only land regression fixes, so should be fine
<cyphermox> sure
<cyphermox> bbl
<ogra> aww, crap
<fginther> sergiusens, are you still fighting that unity8 MP? I was able to reproduce the failures on my maguro
<ogra> igh sigh sigh
<asac> fginther: maguro?
<fginther> asac, it's what I have
<ogra> so there was this accidential removal of click-update-manager (to upgrade apps) ... in image 194
<sergiusens> fginther, haven't touched it yet
<ogra> we seeded it back ... but havent promoted an image since
<ogra> :(
<ogra> people cant upgrade their apps since a week
<sergiusens> fginther, but mzaneti explained that regardless, it would fail on otto
<asac> ogra: thats awful
<ogra> asac, yes
<asac> ogra: how did that happen exactly? is that thing not seeded directly?
<sergiusens> fginther, I wonder if I propsed an empty MR if I'll still get these failures
<fginther> sergiusens, I'll build trunk and see
<ogra> asac, it is, i was pinged by the click lens guys to drop it since they assumed a feature would have landed in system-settings to take over that task
<doanac`> sergiusens: i've been testing the updated phablet-tools branch. I think it looks good
<sergiusens> fginther, oh btw; if you tested at home, make sure /home/phablet/autopilot did not exist as it would take precedence
<ogra> asac, it was added back two days later when we discovered that this feature didnt exist
<sergiusens> doanac`, great; did you get clicks sort tested there as well (just in case)
<ogra> asac, but we didnt promote anything since 194 ... which was the image that dropped it ... 202 has it back
<fginther> sergiusens, what's the background on these tests not working on otto, is this a case where the tests need to be disabled on desktop?
<ogra> asac, there is a thread about it on the ML from last week
<sergiusens> doanac`, I did add prerequesites of what needs to work
<sergiusens> fginther, a missing implementation in unity itself and the lack of a uri handler
<doanac`> sergiusens: "clicks sort"?
 * sergiusens rereads what he wrote
<sergiusens> doanac`, clicks sort of :-
<sergiusens> :-)
<sergiusens> ah
<doanac`> sergiusens: yeah. i tested some click packages. here's the apps i just finished testing: dropping_letters_app unity8 mediaplayer_app ubuntuuitoolkit gallery_app notes_app webbrowser_app
<ogra> asac, it is in the "Landing team 20.02.14" thread
<doanac`> sergiusens: actually - might have a problem: http://q-jenkins.ubuntu-ci:8080/job/andy-autopilot-trustytouch-daily_release/label=test_execution_service-mako/22/artifact/clientlogs/unity8/test_results.xml/*view*/
<plars> Can someone with a flo give the webbrowser ap tests a try? This is twice (out of 2 tries) that I'm seeing it get stuck during those tests
<plars> both times, on the webbrowser_app.tests.test_tabs.TestTabs.test_tabs_model test
<doanac`> sergiusens: that almost looks like some python2/3 type stuff
* plars changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: plars | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Landing instructions: http://goo.gl/8H1Du3 | Known Issues: -
<sergiusens> doanac`, it is
<sergiusens> xnox, look at http://q-jenkins.ubuntu-ci:8080/job/andy-autopilot-trustytouch-daily_release/label=test_execution_service-mako/22/artifact/clientlogs/unity8/test_results.xml/*view*/
<sergiusens> very easy to fix in unity8 fwiw but maybe you want to keep using py2 for it for now
<plars> balloons: you don't happen to have a flo do you?
<balloons> plars, no I do not. manta and mako
<rsalveti> Saviq: I just hate so much that it takes so much time to build c++
<rsalveti> still rebuilding the packages that were using 4.7
<rsalveti> ricmm: why do we have a circular dependency between platform-api and location-service?
<plars> balloons: who's a good contact for webbrowser that might have a flo then, do you know? bfiller_afk?
<ricmm> rsalveti: kind of, platform-api provides the hardware-api which is used by location-service
<ricmm> in turn platform-api provides the application-api, which uses the location-service
<balloons> I'm not sure if om26er has one, but he's pinged now
<ricmm> but the dependency is only circular when both things change at once, it is always avoidable with sequential MRs
<ricmm> as it should be, anyways
<asac> balloons: we shipped you an N7 afaik
<asac> balloons: let me see
<rsalveti> ricmm: right, I'm just rebuilding both things with 4.8
<asac> awesome... seems it didnt happen.
<asac> let me get on it
<balloons> asac, oO, news to me..
<rsalveti> ricmm: so, you were not here, but basically we got an issue with unity8
<asac> balloons: you got one allocated like 2-3 weeks ago
<rsalveti> ricmm: thought it was tls, removed tls, still there
<plars> asac: I'm just looking for someone who can help see what's going on with this webbrowser ap test on flo. I have flo up and running images in CI but it keeps getting stuck here
<rsalveti> ricmm: crashing inside the heap
<balloons> asac, gotcha, I'll expect it in the mail then. It would be useful to have, thank you
<rsalveti> ricmm: weird crash, doesn't happen all the time
<plars> I can't see any reason for it, but it's looking pretty consistent and not happening on other devices
<rsalveti> ricmm: so we're now thinking what could be causing that crash, and one suggestion was the gcc 4.7 x 4.8 issue we had
<ricmm> I'd like to reproduce it
<rsalveti> ricmm: flash 207 on mako
<ricmm> you always chose the one without battery
 * ricmm charges mako
<rsalveti> ricmm: then run the unity8 autopilot test for a few times
<rsalveti> wait for the crash
<asac> balloons: feel through the crack it seems. if you dont hae it by end of week, please ping
<ricmm> rsalveti: ok
* doanac` changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: doanac | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Landing instructions: http://goo.gl/8H1Du3 | Known Issues: -
<rsalveti> ricmm: able to reproduce it already? :P
<ricmm> rsalveti: really?
<ricmm> you know I'm still downloading
<rsalveti> lol
<rsalveti> indeed
<rsalveti> will ping you again in ~8h then
<ricmm> ok
 * ricmm hangs up the 14.4k
<rsalveti> haha
<rsalveti> ricmm: any other idea about what might be causing this weird behavior?
<ricmm> not really
<ricmm> do you have a good trace handy?
<rsalveti> ricmm: no trace, crash in heap
<ricmm> but where were the threads
<ricmm> who accessed the heap
<ricmm> etc
<rsalveti> ricmm: just the crash file
<ricmm> :(
<rsalveti> rebuilt stuff with 4.8 and now location service is consuming all the cpu
<ricmm> rsalveti: cute
<ricmm> rsalveti: download gonna take like 20 min, so gonna walk the dog
<tvoss> rsalveti, location service is built with gcc 4.7
<rsalveti> ricmm: Saviq: rebuilt stuff with 4.8 (location-service, libdbus-cpp, platform-api, libhybris), and still got the crash
<rsalveti> reverting system-compositor now
<Saviq> rsalveti, :/
<rsalveti> to revert system-compositor: http://people.canonical.com/~rsalveti/ubuntu-touch-session_0.103rsalveti1_all.deb
<cyphermox> robru-is-dying: you asleep yet? ignore if true.
<cyphermox> just making sure we don't lose a team player ;)
<rsalveti> Saviq: can you also give it a try without system-compositor?
<Saviq> rsalveti, sure, lemme
<rsalveti> we can at least get a better stack trace I guess
<Saviq> (maybe)
<ricmm> rsalveti: flashing done :D
<rsalveti> Saviq: ok, got a crash without system-compositor but in mir now
 * rsalveti getting dbg symbols
<ricmm> rsalveti: did you rebuild these things stripped?
* doanac` changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Landing instructions: http://goo.gl/8H1Du3 | Known Issues: -
<rsalveti> ricmm: yes, doing normal package build
<Saviq> rsalveti, /me too
<ricmm> do some nostrip bros
<rsalveti> didn't rebuild mir
<ricmm> rsalveti: so just running the test suite is enough?
<rsalveti> ricmm: autopilot
<ricmm> yea unity8-autopilot
<rsalveti> doesn't fail all the time
<Saviq> huh interesting, apport-cli showed me more symbols than apport-retrace -g...
<rsalveti> argh, core is truncated
<rsalveti> Saviq: got a good st?
<Saviq> rsalveti, ah, fuck no, this was ThreadStacktrace
<Saviq> rsalveti, same two fooked frames
<rsalveti> Saviq: also in heap?
<Saviq> rsalveti, yes
<rsalveti> Saviq: same here
<rsalveti> need to script it in a way that we can control the process with gdb or similar
<Saviq> rsalveti, I did have that
<Saviq> rsalveti, stop unity8
<rsalveti> so we can dig the threads
<Saviq> rsalveti, while true; do gdb -ex run -ex continue unity8; done
<ricmm> does this even happen outside of autopilot?
<Saviq> ricmm, yes
<Saviq> rsalveti, from outside you need to pkill unity8 if it didn't crash and continue/quit gdb so that it clears the socket
<rsalveti> alright, so the problem is starting unity8 I guess
<Saviq> rsalveti, unfortunately adding more -ex to gdb resulted in it going over the segv
<robru-is-dying> cyphermox, i'm in and out of consciousness. if you need something right now i can help, otherwise i'll be back later
<Saviq> so the continue / quit had to be manual
<rsalveti> right, ok
<ricmm> well but at least that means it crashes every now and then
<ricmm> on a normal start
<Saviq> ricmm, yes indeed
<ricmm> you dont need to interact with it for a while for it to crash
<Saviq> ricmm, no, not at all
<Saviq> ricmm, once you can interact, it won't crash any more
<Saviq> it crashes very early
<ricmm> Saviq: how often can you make it crash?
<ricmm> I must have started it 30 timesn ow and nothing
<Saviq> ricmm, maybe more often than that
<Saviq> ricmm, but not by much
<Saviq> ricmm, I got it maybe once in 20 runs
<ricmm> we should have a rule
<ricmm> if its once in 20 runs, its not a bug
<ricmm> Saviq: the crash is before the first frame? before or after the SIGILL, etc
<ricmm> just to speed this kill/restart up
<Saviq> ricmm, after the SIGILL
<ricmm> how long do I need to wait after it to make sure it wont happen
<Saviq> ricmm, seconds, once you can interact with the launcher / greeter, it's not gonna happen
<ricmm> k
<Saviq> ricmm, :
<Saviq> while true; do gdb -ex run -ex continue unity8; done
<ricmm> yea im doing that
<Saviq> ok
<ricmm> but to be fair I can interact with the launcher before the sigill
<Saviq> ricmm, not for real you can't
<Saviq> ricmm, once it settles
<Saviq> like when it doesn't take it a second to follow your finger
<ricmm> oh ok
<ricmm> rsalveti: any luck?
<rsalveti> ricmm: still no
<ricmm> I really cant make it crash
<ricmm> getting tired of trying
<rsalveti> keep trying
<rsalveti> you'll get it at some point
<ricmm> did you get it with non-test unity8 already?
<rsalveti> nops
<Saviq> :/
<ricmm> got it to crash
<ricmm> indeed in the heap
<rsalveti> ricmm: anything useful in any other thread?
<ricmm> im looking through them
<ricmm> god I hate these boost bts
<rsalveti> sergiusens: so, we need the new qtmultimedia in for 5.2, what else do you needed to change at that package?
<rsalveti> besides just making it compatible with 5.2?
<sergiusens> rsalveti, not much I think
<sergiusens> are we pushing for 5.2 now?
<sergiusens> rsalveti, just got back
<ChickenCutlass> sergiusens: yes
<sergiusens> dogs tried to bite me when biking to destination :-P
<sergiusens> ChickenCutlass, rsalveti want me to do that now?
<rsalveti> sergiusens: hahah
<rsalveti> sergiusens: please
<sergiusens> sure thing; I'll push to a ppa I control and then ask Mirv to sync
<sergiusens> so we are landing everything?
<rsalveti> we want it because we're doing a call for testing
 * sergiusens rootstocks with qt 5.2
<rsalveti> this is a hard one to reproduce
<ricmm> took me like 40 times
<rsalveti> ricmm: any news?
<ricmm> now I have a horrible backtrace that means nothing to me
<ricmm> I dont see any reference to areas near that heap area
<ricmm> rsalveti: http://paste.ubuntu.com/6996845/
<ricmm> memory around the offending heap area too
<rsalveti> right
<rsalveti> ricmm: with flo: http://paste.ubuntu.com/6996904/
<ricmm> always at mapping + 0x38F8
<ricmm> the mapping is 384 kbytes large
<ricmm> too large :D
<ricmm> time for some watchpoints and hope that it crashes again
<xnox> sergiusens: that is fixed in lp:~xnox/unity8/py32ap
<xnox> sergiusens: also staged for the upload.....
<xnox> sergiusens: ptr will start running python3 compatible tests, but we have circular depends between unity8, ubuntu-ui-toolkit and phablet-test-run.
<xnox> sergiusens: which is: lp:~xnox/unity8/py32ap     lp:~xnox/ubuntu-ui-toolkit/py32ap     lp:~xnox/phablet-tools/py2-3
<sergiusens> xnox, we should of added it to the same silo; but sadly that is blocked
<sergiusens> fear we are in a deadlock
<xnox> sergiusens: depending on how testing is executed, you will get bogus results.
<xnox> sergiusens: i know a very nice silo, called trusty-proposed.
<xnox> sergiusens: also, the other two should be in silos as well, and since they are ppas, just add them in your test environment and test all three together.
<sergiusens> xnox, well I don't make the rules; if doanac` is ok with it; it's fine
<xnox> sergiusens: or don't do silly things, like testing unity8 with a click setup.
<sergiusens> lol
<sergiusens> that too
<xnox> sergiusens: you shouldn't use phablet-click-test-setup to run unity8 tests. you should wipe /home/phablet/autopilot.
<sergiusens> xnox, agreed
<xnox> sergiusens: i mean, it will work, once unity8 update lands, but until then, you should have a clear state and only do: phablet-test-run -p unity8-autopilot -v unity8
<xnox> without click-setup left around on your pythonpath.
<sergiusens> xnox, that really depends on how the ci stuff is setup
<sergiusens> xnox, and I'm not against you ;-)
<sergiusens> xnox, but I was recently reprimanded so I have my tail hidden :-)
<xnox> haha =)
<xnox> sergiusens: sounds silly ;-)
<xnox> sergiusens: if CI is not clearing /home/phablet/autopilot when executing unity8 or ubuntu-ui-toolkit tests, then it's testing wrong test-cases....
<xnox> fginther: is /home/phablet/autopilot cleared (or otherwise is empty) before using .deb based tests? e.g. unity8-autopilot?
<fginther> xnox, yes, it starts with a freshly flashed image and then just installs the debs from the MP
<sergiusens> fginther, even on the image tests?
<xnox> fginther: cool, thanks.
<fginther> sergiusens, smoke image testing doesn't install debs.
<fginther> sergiusens, it does use the click setup thingy I think
<sergiusens> fginther, not even for unity8?
<xnox> hm, i think i lost URL to the current silo status page.
<fginther> sergiusens, I'll need to double check, this has changed recently
<xnox> anyone has URL to spreadsheets, describing silo states?
<fginther> plars, are any  .debs installed during touch smoke tests?
<plars> fginther: yes
<fginther> plars, any for unity8?
<plars> fginther: don't think so
<plars> fginther: wait
<plars> fginther: yes there is
<plars> fginther: python-gi
<sergiusens> plars, what about the autopilot modules?
<plars> fginther: I remember that one now - when everything shifted over to getting the tests from branches where possible, that was still required
<sergiusens> xnox, this? https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=24
<plars> fginther: no, iirc those get pulled in with phablet-click-test-setup and we run from those
<fginther> plars, ok, that was my next question
<xnox> sergiusens: yes, thanks.
<fginther> plars, I don't see anything in the code to specifically pull in unity8-autopilot
<plars> fginther: I take that back, unity8-autopilot is installed
<fginther> hah
<sergiusens> plars, when you run the unity8 tests; is /home/phablet/autopilot removed?
<plars> no
 * doanac` just got back from walk, reading backscroll
<fginther> sergiusens, looks like I was wrong
<xnox> sergiusens: funny how many fixes i have pending in various landings.
<doanac`> plars, sergiusens: i just got a full daily-image run with this latest phablet-tools: http://q-jenkins:8080/job/andy-smoke-daily-test/2/#showFailuresLink
<doanac`> looks like unity8 was the main issue, but there might be some other failures.
<plars> we can't clear /home/phablet/autopilot - isn't that where all the click-test-setup bits go?
<plars> doanac`: that doesn't look too good
<sergiusens> I would think the click tests are ran while the image is read only
<xnox> plars: sure, but it's also your PWD, thus if you install and expect to test: /usr/lib/python2.7/dist-packages/unity8/tests/, you are infact testing /home/phablet/autopilot/unity8/tests (as that is pulled in to provide unity8 emulators)
<sergiusens> and then you switch to readwrite and do whatever is required with read write
<xnox> (in read only images)
<doanac`> looks like music_app is now failing cause it needs mock: http://q-jenkins:8080/job/andy-smoke-daily-test/2/testReport/junit/unittest.loader.ModuleImportFailure.music_app/tests/test_music/ ?
<plars> xnox: but I thought phablet-click-test-setup ensured that we get the same bzr revno that matches the package installed
<xnox> plars: correct. unity8 is not a click package.
<doanac`> sounds like phablet-click-test-setup shouldn't install it as such?
<plars> xnox: it checks the version of unity8
<plars> see fetch_test_base in phablet-click-test-setup
<xnox> plars: look at the phablet-click-test-setup code, it looks at clicks and pulls their matching sources, and pulls matching version unity8 / ubuntu-ui-toolkit by version number.
<plars> xnox: exactly
<xnox> if after executed that, the device is not cleared, and unity8-autopilot.deb is installed (or has been previously been installed, to be under test), it will be ignored.
<xnox> we've asked here, to see if that is the case (that a fresh read-only image is used) when tests of unity8-autopilot are initiated.
<xnox> unity8-autopilot.deb that is.
<sergiusens> plars, it only works when you never switch to read write
<plars> what's the problem you are trying to sort out? I'm missing the context
<plars> what only works when you never switch to read/write?
<plars> aiui, we are stuck on read/write until no extra packages need to be installed
<xnox> plars: of there is no problem, we just don't know how to navigate jenkins to find out the info we lack. Where is all types of unity8 test results?
<xnox> (as in raw console log, not empty test_results.xml)
<plars> ah
<sergiusens> plars, exactly; the stuff installed with phablet-click-test-setup is only to get the emulators and such required by the readonly tests; but if used wth debs; hast the potential to break
<sergiusens> xnox, I guess we can just force to run ui toolit and unity8 in py2 mode with an ugly hack
<xnox> sergiusens: maybe phablet-test-run shouldn't pull in unity8/uuit, if they appear to be already available.
<sergiusens> xnox, they have it because they are in read write
<xnox> sergiusens: and/or otherwise execute them form a different path.
<sergiusens> xnox, but general developers don't go to read write
<sergiusens> xnox, and the emulators they provide are required for all tests
<xnox> sergiusens: let me play around here a little bit.
<xnox> sergiusens: how come the log you showed me, gives errors? clearly that is not using a clean environment.
<sergiusens> xnox, that's doanac` 's log, not mine
<doanac`> what do we mean "not clean"? the fact that its using unity8 from /home/phablet/autopilot/unity8?
<xnox> doanac`: the fact that /home/phablet/autopilot is present, when executing unity8 test-cases, yes.
<doanac`> xnox: its how we've been running this since day1.
<xnox> doanac`: which is uncovered, due to not me uploading the whole lot, as quickly as possible, to minimise discruption all in one go.
<xnox> doanac`: you didn't do: phablet-test-run -p unity8-autopilot -n unity8 ?
<doanac`> xnox, no. we run phablet-click-test-setup, and then phablet-test-run unity8
<doanac`> python-gi gets installed before we run also
<xnox> doanac`: without going read-write?
<sergiusens> doanac`, oh, without installing unity8-autopilot?
<doanac`> correct - we don't install unity8-autopilot
<sergiusens> doanac`, that's awesome if so
<plars> doanac`: it does seem to be installed on at least this device I'm looking at
<sergiusens> doanac`, so you have pure readonly testing
<plars> I'm not sure why though
<xnox> doanac`: that will continue to work, after unity8/py32 branch lands. Otherwise, there is temporary dependency.
<plars> it's not specified in the pkgs for unity8
<doanac`> sergiusens: no. we have a read-write image, just not installing unity8-autopilot
<xnox> sergiusens: unity8 is in a silo, as far as I can tell, can we reconfigure them together?
<doanac`> xnox, sergiusens: so to level set what I did to cause the failure:
<plars> ok, I misspoke, I was looking on one of the devices in the lab that may not have been the last one running the tests after all
<sergiusens> xnox, we can; if unity8 is unlocked
<plars> I don't see where we *should* be installing unity8-autopilot
<doanac`> i took our latest phablet-test-run and tried to make it work with today's image
<xnox> plars: that's all good.
<sergiusens> doanac`, it's that the new test setup splits out py3 and py2
<doanac`> sergiusens: yes.
<doanac`> plus my 2 MPs
<sergiusens> doanac`, so unity8 is running as py3 because it's emulators land there; but it's not py3 ready
<xnox> doanac`: and the merge proposal to get the rest of it py3 ready, is in-flight....
<doanac`> sergiusens: that's fine by me. i thought you wanted me to run the tests just to get an idea if any thing crazy had broke
<sergiusens> doanac`, and that's great
<sergiusens> xnox, which silo is unity8 in?
<doanac`> so i think everything is okay and working as expected, right?
<xnox> sergiusens: now, i'm not sure. help me read: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=0 line 33, tab pending.
<sergiusens> doanac`, sort of; can't land this withtout landing the unity8 changes
<xnox> sergiusens: let me send an email, about branch configurations.
<sergiusens> xnox, it's row 33, but it's unsiloed
<xnox> sergiusens: yeap, gotcha.
#ubuntu-ci-eng 2014-02-26
<xnox> sergiusens: Saviq: bzoltan: didrocks: you've got mail, requesting a silo reconfiguration =) (and to steal branch from Saviq & bzoltan for sergiusens to land) I hope we can agree to do that =)
<ricmm> Saviq: its a lot easier to crash after a while
<rsalveti> ricmm: no deal?
<sil2100> hm, my thunderbird went nanners
<sil2100> Can anyone paste me the hangout link? ;)
<sil2100> Ah, nevermind now!
<mardy> didrocks: hi! Is it possible to have several branches for the same project in a silo? Will they get automagically merged?
<seb128> mardy, yes, they get merged in the order you list them in the request
<mardy> seb128: cool, thanks
<seb128> yw
<dbarth> hi, what's the weather like for the CI train this morning? ie do you think landings may resume today?
<didrocks> dbarth: not now, we still have the dashboard failing
<dbarth> ok, nw; will land in a ppa for now
<psivaa> didrocks: ogra: systemsettle failure on default set is because it was using an identical script but from a different location, which was not changed.
<didrocks> psivaa: ahah
<didrocks> :)
<psivaa> i'll propose a fix with symlinking to the original one
<ogra> === Image 209 Building ===
<didrocks> yeah, seems better than duplication :)
<didrocks> thanks psivaa
<didrocks> and let's see if we can this in time for 209
<ogra> funny :)
<psivaa> yw :)
<ogra> the system-image part takes significantly longer, you have plenty of time :)
<sil2100> hmmm
<sil2100> I might have some clue on what makes the terminal test fail, just need to figure out what is causing this
<Saviq> huh? stable == saucy still?
<didrocks> Saviq: yeah, it's been a long debate, not sure we should focus our strength on that today :)
<Saviq> didrocks, nah, I just went for ubuntu-device-flash and was surprised it chose image 104 for me :)
 * ogra thinks we should drop these channels altogether ... 
<ogra> default and proposed is all we should have
<didrocks> Saviq: I think we can bring that back on the table once the transition to 4.4 is done
<didrocks> ogra: +1
<Saviq> yeah, ETOOMANYCHANNELS
<ogra> stable was theoretically thought for developers to get a stable base for their apps ...
<ogra> but we are moving way to fast for that imho
<didrocks> indeed
<ogra> oooh
<ogra> didrocks, the new logo is beautiful
 * ogra sees itfor the first time
<didrocks> ogra: heh, thanks ;)
<ogra> dancing friends :)
<didrocks> thanks to my wife to have detour it (even with the svg, to downscale it and not having weird outer circle "moving"â¦ wasn't that straightforward)
<didrocks> heh :)
<seb128> what logo?
<xnox> seb128: the new recovery, has a spinning ubuntu cof upon bootstrap flash.
<ogra> seb128, new recovery mode
<seb128> oh ok
<ogra> the dead android with rotating guts is gone
<didrocks> that was really annoying me \o/
<ogra> ++
<xnox> didrocks: can we get rid of the choppy progress bar?
<ogra> thats harder than replacing the logo
<ogra> (needs actual code changes)
<xnox> didrocks: or like slow it down? i'm not resurrected robocop to register that it's working properly, instead of looking choppingly fast.
<didrocks> xnox: slowing it down is easy, the issue is that we can get a progress bar with the number of steps, but some steps are taking seconds, other minutes :p
<ogra> wow
<ogra> my device just rebooted in the middle of a unity8 test run
<ogra> hmm
<ogra> WARNING: in file "/usr/lib/python2.7/dist-packages/unity8/shell/tests/__init__.py", line 148 in setUp
<ogra> This function is deprecated. Please use 'the Touch class to instantiate a device object' instead.
<ogra> i thought it is python3 now
<ogra> hmm, the camera fake thingie in unty8 doesnt fit on the screen on flo
<davmor2> Morning all
<xnox> ogra: nah, my branch to switch it to python3 is on hold.
<ogra> ah, k
<xnox> ogra: and it doesn't fix / change classes.
<xnox> ogra: something about unity8 crashing, and that being priority to fix.
<ogra> yep, i know, i was in the meeting this morning :)
<didrocks> sometimes GAS will turn me crazy
<sil2100> It's probably poison GAS
<sil2100> What's up?
<didrocks> oh, I found the fix
<didrocks> but using "name" and 'name' is different if you pass that to a function
<didrocks> it's because of their internal caching creating bugs
<sil2100> ;/
<Laney> gas the gnu assembler?
<didrocks> google apps scripts
<ogra> umm
<ogra> sh: 1: gcc: not found
<ogra> dpkg-architecture: warning: couldn't determine gcc system type, falling back to default (native compilation)
<ogra> why does the unity8 test use gcc
<didrocks> ogra: it's autopilot
<ogra> ah
<didrocks> and this is the case for a long time
<didrocks> that we have that error
<ogra> never noticed it
<ogra> (but i also rarely watched the terminal while the tests were running, it probably just scrolled offscreen)
<didrocks> sil2100: Mirv: robru-is-dying: cyphermox: ok, so now, when you add more lines to the spreadsheet, it should apply the formatting for you (phew)
<didrocks> ogra: yeah, it's at the beginning of a test or testsuite
<Mirv> nice..
<ogra> right
<ogra> Ran 46 tests in 1373.092s
<ogra> FAILED (failures=1)
<ogra> Restoring shell
<ogra> unity8 start/running, process 13586
<ogra> not that bad
<didrocks> yeah, same than in the dashboard
<didrocks> because of the crash
<sil2100> \o/
<ogra> ERROR: unity8.indicators.tests.test_indicators.IndicatorTestCase.test_indicator_exists(Bluetooth)
<ogra> and thats expected ... since flo has no working BT yet
<didrocks> sil2100: Mirv: tell me if you find any bug, I had to rewrite some formulas for that
<ogra> hmm
<ogra> so http://ci.ubuntu.com/smokeng/trusty/touch/flo/208:20140226:20140224/6826/unity8/ looks quite different from ym test
<ogra> *my
<didrocks> ogra: again those StateNotFoundError: State not found for class 'DefaultIndicatorWidget' and filters {'objectName': 'indicator-bluetooth-widget'}.
<didrocks> another one is the crash
<ogra> didrocks, well, there is no BT indicator on flo
<ogra> i had the crash (which actually caused a reboot) the run after the crash was fine apart from the BT test
<didrocks> ogra: ok, so only the crashes
<didrocks> the 3 others
<didrocks> (no process found with pidâ¦)
<ogra> i only had one
<ogra> see above
<didrocks> yeah, it's random, so you can get lucky
<didrocks> talking about the dashboard, seems there were 3
<ogra> right
 * ogra re-runs
<ogra> didrocks, oh, i totally forgot to mention in the meeting ... when we re-added click-update-manager (which had been dropped in 194) inn image 202, we didnt promote 202 which means users cant upgrade their apps at all atm
<didrocks> ogra: yeah, one of the issue is that we don't have full test results on 202 nor dogfooding
<ogra> i was wondering (sice we're stuck atm anyway) if we should put some effort into gettin 202 late promoted
<didrocks> so, if the CI team can maybe rerun 202 in parallel?
<didrocks> that makes sense
<didrocks> psivaa: will that take you a long time to get 202 running all tests? ^
<ogra> might clash with 209 now though :/
<didrocks> yeah
<didrocks> let's wait for his feedback
<ogra> === Image 209 DONE ===
<psivaa> didrocks: i get the setup going, it wont take long but for the tests to complete it will take around 4+ hrs.
<psivaa> i could run 202 on a different device though
<psivaa> but we wont have the results on the dashboard
<ogra> that might be good
<didrocks> psivaa: if some tests are failing or need rerunâ¦
<psivaa> didrocks: that's fine. they will be isolated
<didrocks> psivaa: you will still be able to just run the testsuite failing?
<didrocks> ok :)
<didrocks> so yeah, if you have time, please :)
<didrocks> then, if the results are good, we can ask our lovely dogfooders
<psivaa> didrocks: ack, will kick one
<didrocks> thx!
<bregma> hey didrocks, how do I get a project to start using ci-train... just add a MP and it will automatically climb aboard, or is there some manual adjusyment the Landing Team has to make?
<didrocks> bregma: is that a new project or something that was under daily release before?
<bregma> in this case, it's the unity8-desktop-session project, so, new
<bregma> I also need to get geis and libgrip releases out, but I'm pretty sure they need manual reconfiguration
<didrocks> ah ok, so a MP is enough to get it (just ensure we can bzr bd)
<didrocks> can you please add it as well to https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdC05a2ZQSmgwU2NFYnJQOE9qMDRYa3c#gid=1?
<didrocks> that helps tracking
<bregma> I don't believe I have edit access, let me try
<didrocks> you should have
<didrocks> bregma: btw, you probably want to take bamf (and some of the scopes?)
<didrocks> as a Lander
<didrocks> I see they still don't have any landers
<bregma> the scopes should all be mhr3
<didrocks> mhr3: taking them? ^
<didrocks> thostr_: ^
<bregma> OK, I have edit, adding and updating
<didrocks> I only see the mediascanner one
<didrocks> bregma: thanks!
<didrocks> bregma: it will by default collect from rev 0 for the changelog though, if you released one version, ensure it's tagged with the packaging version then
<bregma> didrocks, up to now I used standard debrelease techniques, it should be tagged
<didrocks> excellent, we should be fine then :)
<thostr_> bregma: well, the old scopes is unity7 only that's why I though you'd take those
<bregma> didrocks, how about geis, it has pending changes that haven't landed in distro for some time and I have no new MPs at the moment, so it will need a trunk flush, correct?
<didrocks> bregma: yeah, just propose an empty MP to flush those
<didrocks> Mirv: mind unwiring from daily release and update the items without CI Train "yes" on https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdC05a2ZQSmgwU2NFYnJQOE9qMDRYa3c#gid=1, please?
<thostr_> didrocks: do we need to explicitly move all old scopes to ci, or can we rather do that once we have changes?
<thostr_> didrocks: ... which I don't expect any time soon
<didrocks> thostr_: we can do that once you have change, just be aware that we'll disable everything shortly though
<thostr_> didrocks: sure
<didrocks> thostr_: however, once you have change, it will take more time to migrate
<didrocks> so be aware of that and don't ask the impossible later on :)
<thostr_> didrocks: yes, understood
 * bregma always expects the impossible from didrocks
<didrocks> tssss ;)
<psivaa> om26er: hey do you think bug 1276747 could also be a reason why turning the screen on failing in http://pastebin.ubuntu.com/6999455/
<ubot5> bug 1276747 in autopilot (Ubuntu) "after starting a new app cannot get proxy object for unity8" [High,Confirmed] https://launchpad.net/bugs/1276747
<psivaa> didrocks: http://q-jenkins.ubuntu-ci:8080/job/psivaa-trusty-touch-mako-smoke-daily/3/console is flashing with 202
<didrocks> psivaa: excellent, thanks!
<mhr3> didrocks, what, what, what?
<mhr3> what am i supposed to take?
<om26er> psivaa, no, this log seems to show it could not find proxy for unity8, could be unity8 crashed
<didrocks> mhr3: backlog just before my hilight :)
<psivaa> om26er: unity8 did not crash on those instances
<mhr3> didrocks, ok, a sec, in meeting
<om26er> psivaa, let me try to reproduce that, not sure if 'com.canonical.Shell.BottomBarVisibilityCommunicator' exists these days
<psivaa> om26er: thanks. http://pastebin.ubuntu.com/6999481/ contains some more information indicating unity8 is running
<om26er> psivaa, where can i find the unlock screen script ?
<psivaa> om26er: and this does not occur all the time: http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/view/head:/utils/target/unlock_screen.py
<om26er> that code looks familiar
<psivaa> om26er: if it helps, this behaviour started only this week and during the weekend we had autopilot, unity and android updates.
<om26er> psivaa, i am trying on the very latest image, seems to work for me multiple times. did anyone reproduce the issue locally as well ?
<psivaa> om26er: i dont think anyone tried this. and it happens about 1 in 5 times i'd say
<Mirv> didrocks: ok, so both updating daily release config for ci train 'yes' if not already plus adding possible entries in configs that are not in the sheet
<om26er> psivaa, i have a question is the script running as root in CI ?
<didrocks> Mirv: thanks!
<psivaa> om26er: i think so, let me confirm
<om26er> psivaa, also i want a complete log, seems i have been able to reproduce the issue here
<psivaa> om26er: it is being run as root
<didrocks> psivaa: hum, default system settle for 209 didn't use your change?
<psivaa> om26er: https://jenkins.qa.ubuntu.com/view/Trusty/view/Smoke%20Testing/job/trusty-touch-mako-smoke-daily/90/ has the necessary logs
<psivaa> om26er: 'adb-shell /home/phablet/bin/unlock_screen.sh' is when it starts for all the app tests
<psivaa> didrocks: the MP needs approval and merge. dint want to push it straight
<didrocks> psivaa: ah ok
<ogra> hmm
<ogra> so i can enable BT on the android side of the flo
<ogra> and apparently it even comes up ... but the indicator doesnt seem to notice
<didrocks> apw: hey, do you think it will be possible to have the same "core up" behavior than in 4.2? (so cores not shutting down)
<didrocks> just to run one full test suite with that
<didrocks> and see if the flakyness that are revealed is due to that
 * ogra files bug 1285146 for cyphermox 
<ubot5> bug 1285146 in bluetooth-touch (Ubuntu) "Bluetooth on flo can be easily enabled but the indicator does not recognize it" [High,New] https://launchpad.net/bugs/1285146
<mhr3> didrocks, noone's touching the old scopes, so let's deal with it if/when they need to be touched
<didrocks> mhr3: ok, just note my remark on the introduced delay then once you want to land it
<Mirv> didrocks: ok sync done. all packages having in CI Train already set were disabled correctly, but I was wary of setting any disabled-in-daily-release-config to be automatically CI Train 'yes'. instead, for you to review: http://pastebin.ubuntu.com/6999661/
<mhr3> didrocks, if there's just a simple fix needed or something trivial can't it use no-train?
<didrocks> mhr3: no, we are not going to support the old infra anymore
<mhr3> didrocks, there's still manual uploads ;)
<didrocks> mhr3: well, we don't do that for our projects :p
<mhr3> didrocks, clearly i need to become ubuntu developer so i can screw with you ;)
<didrocks> mhr3: better to keep one process only
<didrocks> mhr3: don't worry, a lot of people are using their time to accomplish this :p
<mhr3> didrocks, aaah, so i wouldn't be the only one? that sucks
<didrocks> Mirv: ok, I flipped the switch for those having a landers
<didrocks> Mirv: but it seems you basically missed the ## Stack oif.cfg ##
<didrocks> Mirv: and account-plugins
<didrocks> click-apparmor
<didrocks> and another click
<Mirv> didrocks: hmm?
<didrocks> Mirv: basically, everything that has a lander is up to ci train
<sil2100> bregma: so, unity7 is tested, right?
<Mirv> didrocks: oif is covered as being enabled in daily release config, so covered by pastebin's first line. the rest, I'm probably missing some pass you were wanting? I worked through the daily-release configs and compared those to the spreadsheet, but I didn't go through the spreadsheet by itself as such
<sil2100> bregma: do any of those changes there could affect touch?
<didrocks> Mirv: yeah, so when there is a lander, we need to disable them from daily-release
<didrocks> Mirv: as well as upstream-merger, and then, set the "In CI Train" to yes
<Mirv> didrocks: ok, so if lander name is there, it means need to disable, ok
<didrocks> yep :)
<Mirv> didrocks: that's the pass I'm missing
<sil2100> Exactly ;)
<didrocks> Mirv: sorry, it seems they are just 6 of them :)
<didrocks> fginther: please, when you add projects or change cu2d-config, please reflect the change in the spreadsheet as well: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdC05a2ZQSmgwU2NFYnJQOE9qMDRYa3c#gid=1
<didrocks> fginther: and don't enable upstream-merger :)
<Mirv> didrocks: so actually just oif needs disabling in config, I think. click-* were not in daily release, and I now moved accounts-plugins also under the title I created "Other CI Train packages not formerly in daily release system". https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/sync_citrain_disable_oif/+merge/208361
<didrocks> Mirv: hum, you need to disable upstream merger as well for them, they were not in it?
<om26er> psivaa, i have come to a situation where the unlock script prints that unity8 has been restarted but it is actually not, probably due to a bug somewhere on unity side or our config
<didrocks> Mirv: hum, you only changed the daily-release tag, there is more than that, remember at Bluefinn?
<bregma> sil2100, yes, tested and FFe acked, all changes are only in Unity7 (the removed config option was never used anywhere) so no Touch effects
<didrocks> Mirv: let me find you a commit
<Mirv> didrocks: in stacks/head, I find no trace of apparmor/click-apparmor/click in projects:
<didrocks> Mirv: you need to add:
<om26er> at that time the screen is indeed turned on *but* starting unity with 'initctl start unity8' does not actually show it on my screen
<didrocks> +     daily_release: False
<didrocks> +     autolanding_template: False
<didrocks> +     use_stack_ppa: False
<didrocks> Mirv: to every project that you are disabling ^
<Mirv> didrocks: right.. adding
<didrocks> (so probably account-plugin, click-* as well)
<om26er> plars, do you manage the unlock screen script ?
<sil2100> didrocks: ^ can I publish unity7 then? :) I'll double check the FFe bits before that
<didrocks> om26er: it happens quite often since the android 4.4 switch FYI
<didrocks> sil2100: yeah :)
<om26er> plars, how important is it to restart unity8 after every test suite ?
<Mirv> didrocks: pushed to the branch for oif, still not finding accounts-plugins, click-* in the daily release config with grep
<sil2100> didrocks: ok, Laney ACKed the FFe's, so it's indeed all green
<didrocks> Mirv: oh nothing? interesting
<sil2100> bregma: btw.! Wow! I see you guys come from the future ;D "Unity7 bugfixes 2024.02.24" ;)
<didrocks> Mirv: I would still add the 3 lines for "dead" projects
<didrocks> Mirv: just in case :p
<bregma> geez, one typo and they never let you forget
<ogra> sil2100, bregma, oh horror !!!!!
 * ogra really doesnt want to see us using unity7 in 2024 still
<sil2100> bregma: ;)
<om26er> didrocks, plars psivaa we can probably add tests for the unlock script itself
<didrocks> people mixing numbers
<didrocks> I never do that!
<ogra> except in lotteries
<didrocks> om26er: yeah, but first, let's get it fixed :)
<ogra> :)
<didrocks> ogra: ahah
<apw> didrocks, the change was not to whether they were up, it was how they are reported in the idle stats; right?
<didrocks> Mirv: and hum stacks/head/webcred.cfg:    account-plugins:
<Mirv> didrocks: aha, why was I grepping accountS-plugins
<Mirv> just a moment
<didrocks> apw: not sure, no power management change as you know of?
<didrocks> it's only on the reporting side?
<om26er> Saviq, hey! unity8 does not start and if i start it from the terminal i see this: http://paste.ubuntu.com/6999748/
<om26er> does that mean anything ?
<apw> didrocks, i don't have that information without waiting for this stupid thing to charge, but the issue with the test suites was about reporting _only_
<ogra> om26er, did you use upstart to start it ?
<Mirv> didrocks: ok now the merge request page is updated
<didrocks> apw: yeah, but we have other "weird" new races and so on since the switch itself, so I was wondering if they changed something around CPU or scheduling (and if we can proove that theory)
<sil2100> didrocks: packaging ACK needed: http://162.213.34.102/job/landing-012-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity_7.1.2+14.04.20140225-0ubuntu1.diff <- new dep in main, seems ok
<om26er> ogra, with initctl it gave: http://paste.ubuntu.com/6999760/
<apw> didrocks, i didn't see a heap of nasty looking change, but presumably we tested these kernels before switching
<ogra> om26er, as phablet user ? and is lightdm running (and thus unity-system-compositor)
<sil2100> Great, I just broke my unity7, geh ;)
<om26er> ogra, yes as phablet user, i ssh'd in
<didrocks> apw: ok, false hope then :)
<om26er> ogra, lightdm have 2 instances and unity-system-compositor have 1
<ogra> ok, thats fine then
<ogra> (something seems to hog /tmp/mir_socket or so)
<didrocks> sil2100: +1
<didrocks> Mirv: hum, seems you missed my remarkâ¦
<didrocks> 14:27:56 didrocks | Mirv: I would still add the 3 lines for "dead" projects
<didrocks> 14:27:59 didrocks | Mirv: just in case :p
<om26er> ogra, rm -r /tmp/mir_socket ?
<ogra> om26er, no, thats privided by unity-system-compositor ... you would rip the carpet out underneath it
<ogra> om26er, rather check if there is another unity8 stuck or so
<ogra> it hooks into that socket
<Mirv> didrocks: sorry, there are 8 different cases. so add where for which dead projects? I somehow skipped that as being that "yes keep those mentions in the daily-release config proposal that I copied from spreadsheet"
<Mirv> didrocks: this syncing is complex :)
<om26er> ogra, seems our unlocker tries to remove mir_socket http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/view/head:/utils/target/unlock_screen.py
<om26er> line 29
<didrocks> Mirv: yeah ;) basically the idea is "disable daily release and upstream merger for the dead projects"
<didrocks> Mirv: so adding the same 3 lines in the configuration
<didrocks> for them
<ogra> om26er, hmm, that feels rather wrong, ask mterry once he comes online ... he designed the nested Mir mode we use today
<Mirv> didrocks: ah, adding the three "disabling lines"! great.
<ogra> didrocks, ^^^^ that could cause a lot of unity8 test issues actually
<didrocks> yep
<didrocks> ogra: yeah, that's probably the cause of so many phablet-test-run which don't start
<didrocks> psivaa-lunch: right? ^
<ogra> i'm not sure if /tmp/mir_socket gets dynamically re-created
<ogra> but i doubt it
<Mirv> didrocks: pushed and LP is updated
<ogra> and unity8 kind of wants to connect to it
<jdstrand> didrocks, Mirv: I don't know what this oif stuff is, but apparmor, apparmor-easyprof-ubuntu and click has me as a lander but getting them into the citrain fold is still in progress (I started it but got pulled away)
<ogra> jdstrand, you can always dput to a landing PPA
<ogra> which i guess is at least hafl a CI train ...
<ogra> *half
<jdstrand> true, I'll keep that in mind
<didrocks> jdstrand: yeah, but we can disabling them from daily-release and automerging :)
<jdstrand> I'll get it done-- I just haven't had landings to request yet (things got delayed there)
<psivaa-lunch> didrocks: ogra: om26er: 'rm -f /tmp/mir_socket' is there for long time and 'rm: cannot remove '/tmp/mir_socket': Operation not permitted' has also been reported before
<jdstrand> didrocks: I'm not sure I understand
<psivaa-lunch> without much harm
<ogra> psivaa-lunch, yeah, it shouldnt be removed ever with nested mode
<didrocks> jdstrand: if you don't, basically don't worry, we just unplug from the old system :)
<ogra> but i guess if you run it as phablet user you wont have the permissions
<ogra> phablet@ubuntu-phablet:~$ rm /tmp/mir_socket
<ogra> rm: cannot remove '/tmp/mir_socket': Operation not permitted
<ogra> yeah
<jdstrand> didrocks: ok, thanks
<ogra> om26er, so you iare safe as long as you dont run it as root
<psivaa-lunch> ogra: ack
 * om26er back in a few minutes, doctor appointment
<bzoltan> something is horrible wrong with my ISP ... I got 0.06MBs upstream
<plars> om26er|doc: I had nothing to do with that script, iirc you were the original author of it. :)  I really still think there needs to be some way to call into unity itself where it knows how to do all of that without having to use autopilot externally
<plars> om26er|doc: unlock has been occasionally failing to unlock the screen lately though
<plars> for the last week or so it seems, before that it was pretty reliable
<didrocks> plars: yeah, seems it's since the 4.4 switch
<bregma> didrocks, any suggestion what component unity8-desktop-session should go under in the CiTrain spreadsheet? (unity8.cfg makes some sense, but I don't know what these .cfg things are)
<rsalveti> didrocks: I got quite a few ascii errors when running tests with flo as well
<rsalveti> not with mako though, not sure what causes it
<didrocks> bregma: I would say "misc", but you can add to the end, it doesn't make sense anymore as we don't have stack configs
<didrocks> rsalveti: ascii errors, like invalid locales?
<rsalveti> yeah, usual locale error with python
<didrocks> interesting, I guess no langpack difference and we do have utf8 there as well. Apart if we go to some error path and the output isn't correct binary/ascii convertion
<rsalveti> but nice that it's part of the dashboard now :-)
<rsalveti> right
<didrocks> rsalveti: we really see various timeouts
<didrocks> so, if the power management changed in the 4.4 kernelâ¦ maybe it just reveals some flakyness
<didrocks> (that we have in our code)
<apw> didrocks, ok ... the old kernel on a very old image i happen to have here ... shows that we run with a single cpu normally also
<didrocks> apw: oh, really?
<apw> as i said it was just a statistics reporting change
 * didrocks doesn't understand "shows that we run with a single
<didrocks> cpu normally also"
<didrocks> seems it's not reporting change
<apw> define reporting change ?
<apw> the online cpulist from the kernel is '0' on my phone by defualt, ie a single cpu online called 0
<rsalveti> yeah, I got the impression that we're no using 4 cpus
<rsalveti> and before we were using 2 the most
<rsalveti> *we're now
<apw> hard to tell without having some what to make the thing busy i guess
<didrocks> rsalveti: at least, that would explain most of the flakyness we are seeing I guess
<apw> didrocks, i hate to think we write code which isn't smp aware
<apw> its all in go right
<rsalveti> didrocks: yeah
<rsalveti> we can now run many more threads in parallel :-)
<apw> rsalveti, what do you base it only using 2 on ?
<fginther> didrocks, ack
<rsalveti> apw: when debugging pulse I was only getting cpu1 on/off
<rsalveti> with 4.4.2 I was getting cpu 1,2 and 3 on/off events
<apw> rsalveti, ok i've got an old installed here, and with a cpu loop i can get all cpus online no problem, so it is possible to use them all
<rsalveti> but we can check by flashing the older image
<ogra> we should really try to run with 0 CPUs
<ogra> saves so much battery
<rsalveti> right
<apw> my older image deffo can use all 4, and indeed is getting nice and warm doing exactly that
<plars> oh nice - flo seems to be getting past the webbrowser tests in 208 and 209
<plars> http://ci.ubuntu.com/smokeng/trusty/touch/?show_all=1
<rsalveti> maybe the governor is behaving differently now somehow
<ogra> rsalveti, is it still using the same governor ?
<ogra> (we still force ondemand on the ubuntu side)
* retoaded changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: retoaded | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Landing instructions: http://goo.gl/8H1Du3 | Known Issues: -
<om26er> plars, the issue on hand right now is that sometimes unity8 does not start even initctl tells us it did
<elopio> asac: can you please comment on what we are missing for https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1275012 to happen?
<ubot5> Ubuntu bug 1275012 in Ubuntu CI Services "Add a job to run all the image tests with qt5.2" [Undecided,New]
<plars> om26er: well that could keep us from unlocking it I suppose :)
<om26er> plars, yep ;)
<didrocks> elopio: hey, have you seen my answer on the nostate error?
<elopio> didrocks: not yet. On the bug you mean?
<elopio> didrocks: oh, got it. I just marked as incomplete the one in the dialer, because I ran it 5 times on my phone and the dash is now green.
<elopio> I've been trying to run the ones in weather app, but something is funny here. I'm reflashing to try again.
<didrocks> elopio: see my answers and mostly, look at the dashboard :)
<didrocks> elopio: it's our first input source
<didrocks> and as you can see, things are really flaky (look at different results in different images)
<didrocks> so we'll need your expertise I guess in how those tests are misbehaving
<asac> elopio: who from CI team have you been working with on this until now?
<elopio> asac: nobody.
<elopio> didrocks: yes, I'm trying to reproduce the errors here. I just started with the one that strangely fixed itself :)
<elopio> about the clock, I've made a branch that should improve the alarm tests a little: https://code.launchpad.net/~elopio/ubuntu-clock-app/page_object-alarm_tests/+merge/207988
<asac> elopio: so i was told this was agreed work with the CI team. not really great to hear today that this wasn't done now.
<elopio> I'll ask nik about landing it.
<didrocks> elopio: oh nice! balloons, sergiusens ^
<elopio> asac: maybe somebody agreed on it, but didn't update the status of the bug.
<asac> doanac`: what do you think about https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1275012?
<ubot5> Ubuntu bug 1275012 in Ubuntu CI Services "Add a job to run all the image tests with qt5.2" [Undecided,New]
<asac> ev: ^^
<popey> Mirv:                         text: "Author: Mike Sheldon <elleo@gnu.org>\n\nReleased
<popey> under the GPL, version 3.0 or later.";
<popey> it's those \n's that are doing the boxes
<asac> elopio: in the future, please dont committ to engineering team that you will make stuff happen that you can't happen alone without aligning engineering work done by other teams. this commitment from QA caused people to believe all is going fine and well, and the CI team is deep in the hot phase of an important customer project right now
<asac> anyway, lets see
<Mirv> popey: file a bug against ubuntu-ui-toolkit first, maybe they can retarget if it's nothing they can affect
<Mirv> popey: I was able to see it now by installing TouchWriter
<popey> ok
<didrocks> Mirv: did you push your changes? I missed your ping probably
<asac> elopio: is this just duplicating the autopilot job or what does this entail?
<elopio> asac: as far as I can remember, I never commited to this task. That's why I didn't assign it to myself.
<elopio> but well, I suppose I didn't make it clear, I'm sorry.
<asac> elopio: right. be careful. thanks.
<asac> elopio: so the "in the meanimte" comment ... is that still valid?
<elopio> asac: duplicating the job, they also want a view like the dashboard to get a nice view of the errors.
<asac> elopio: thats not going to happen i am sure
<asac> but guess its not critical
<asac> as long as the data is there someone can write a perl script or something
<thostr_> sil2100: can I get a silo for line 30?
<elopio> and I think we need clear direction of when we can run this job, because I heard somebody saying that it might starve the other jobs that need hardware.
<Mirv> didrocks: I was thinking you'd approve https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/sync_citrain_disable_oif/+merge/208361
<elopio> asac: yes, we can use the autopilot job whenever they are not trying to make a release.
<didrocks> Mirv: approved! remember you need to redeploy on q-jenkins
<asac> elopio: sonuds like that could be mitigated through manual coordination for a few days
<Mirv> didrocks: yes, redeployed already. thanks!
<asac> elopio: so http://q-jenkins:8080/job/autopilot-release-gatekeeper/42/ seems to already show what tests failed
<elopio> asac: ok, we can do that. Who should we coordinate with in order to start this job? didrocks? Or we just run it whenever we want?
<asac> elopio: guess thats good enough from dashboard point of view
<asac> elopio: my understanding is that this autopilot job is something that the qa tools team (thomi/veebers) is using internally, so thjink its coordinating between qt task force and autopilot tools team
<asac> and didrocks has no stake in this
<asac> didrocks: correct? are we using this job for anything in CI Train?
<didrocks> Mirv: thanks to you :)
<elopio> I'm just wondering. If this job consumes all the phones we have, and they are trying to release a new image, both jobs will take twice the time.
<asac> elopio: yeah, i dont think thats the case. its probably consuming at most one phone at the same time
<asac> anyway, we have to wait for doanac`/ev to comment
<didrocks> asac: I don't, indeed
<asac> good
<didrocks> elopio: feel free, the pool is static
<asac> plars: there?
<elopio> ok, then. Thanks for the clarifications asac. Sorry for the troubles.
<plars> asac: yes
<asac> plars: is there a need to coordinate running http://q-jenkins:8080/job/autopilot-release-gatekeeper/42/ and image testin?
<asac> plars: or do they use separate phones for testing and dont step on each others toe?
<asac> (i assume its all fine, just double checking)
<didrocks> elopio: it's another incentive to get the base image good again, to know what impacts really Qt 5.2 has :)
<plars> asac: I'm not familiar with that job, let me look
<asac> elopio: dont worry. if you can help fixing those flaky tests StateNotFound things it would be an amazing contribution to the qt landing effort :)
<asac> elopio: my understanding was that you guys understood the bad coding pattern used in those tests... if not check with thomi, i believe he knows exactly what needs to be done
<elopio> I'm trying to fix ugly tests one project at a time. There are too many.
<elopio> asac: it's pretty obvious. There are many many steps in some of the tests, with only one assertion.
<plars> asac: looks like it runs on a specific device, a mako
<Saviq> om26er, rm /run/user/32011/mir_socket
<om26er> Saviq, removing that every time is fine ?
<Saviq> om26er, as long as unity8 isn't running
<Saviq> om26er, or well, it might be slightly different now with system compositor, check initctl get-env --global UNITY_MIR_SOCKET
<Saviq> om26er, as that one â might be held by unity-system-compositor
<plars> asac: that device seems to also be part of the daily smoke runs, and is in the middle of a job right now. It won't interfere with that if someone starts a new one on it, but it will be stuck in the queue until the other job finishes
<om26er> Saviq, it directs to /tmp/mir_socket
<Saviq> om26er, so yeah, that's the one unity8 tries to create and fails, if it's there
<plars> asac: if you'd like, I can take this device out of the pool that runs daily smoke tests, but we're close to the end of the current run, so it would be better not to cancel it unless it's really urgent
<om26er> Saviq, whats the solution, should we clear it when we stop unity and expect for it to be recreated when unity8 is started again ?
<Saviq> om26er, it happens already, but it's left hanging when unity8 crashes badly
<Saviq> om26er, so... we might be nasty and remove it in unity8's pre-start
<Saviq> om26er, but I'm not entirely sure that's a good thing to do
<Saviq> om26er, mir folk really didn't want that
<asac> plars: if we have a way to allocate a separate device for the autopilot/qt job
<asac> that would be good
<asac> plars: but not sure what the capacity of phones in the lab is
<asac> plars: its not urgent for sure.
<plars> asac: yeah, I'll take care of it as soon as this current job finishes on that device
<asac> plars: just want to ensure that the AP/qt job does not interfere with the image testing
<plars> asac: it won't interfere for sure, but it could get delayed if, for instance, someone tried to start it right now
<asac> right. at best there are no delays on image testing because of AP/qt job
<asac> plars: does that increase risk that we run out of devices for image testing?
<plars> asac: no, we have 3 other mako devices in that pool
<asac> plars: so we will have 1 hot/spare still for image testing? and in worst case we could easily bring back the AP device, right?
<plars> asac: exactly, we are doing pretty good on makos
<asac> sound good
<plars> asac: and on flo we have 3 for smoke, we only have 2 mantas and rick is working on getting those hooked up. So hopefully that one should be rolling soon too
<psivaa> didrocks: http://q-jenkins.ubuntu-ci:8080/job/psivaa-trusty-touch-mako-smoke-daily/3/#showFailuresLink has some failures with 202. dint look each of them though
 * didrocks needs to go for a run
<didrocks> psivaa: do you have time to look at them? ^
<didrocks> or plars ^
<didrocks> maybe :)
<plars> psivaa: what job is that?
<didrocks> hum
<psivaa> plars: that was a job with image 202
<didrocks> all failures seems to be unable to unlock the scren
<plars> psivaa: I guess you were trying new/old packages with it by hand?
<didrocks> plars: no, only image 202
<didrocks> but most of the tests failed
<plars> ah, ok
<didrocks> because can't unlock the screen
<psivaa> didrocks: yea, sorry so that means the actual app tests have been skipped. let me run them again
<ChrisTownsend> retoaded: Hi.  I updated the branch for https://code.launchpad.net/~townsend/nux/fix-animation-crash/+merge/208218, but I've yet to see a result from CI and I also don't see any evidence a CI job is running.  IS this because it's in the globally approved state or is there something messed up with Nux CI?
<dbarth_> hey again, do you guys mind if i continue stacking merge proposals into an already allocated silo? (silo-005)
<dbarth_> i know it's not helping much fix the image, but this way we can continue our tests and copy the silo ppa binaries into the SDK PPA once tests pass
<dbarth_> (this, to be ready on time for the app showdown kickoff)
<retoaded> ChrisTownsend, checking
<ChrisTownsend> retoaded: Thanks
<doanac`> asac: the autopilot-release-gatekeeper job should be able to test qt5.2 properly using the code as our daily-image testing. However, it wouldn't show up in the qa-dashboard. If that is really required, i think we need to bring in ev and priortize this effort. its something plars or myself could do.
<plars> doanac`: I may have misunderstood, but I didn't think that's what he was asking for
<asac> doanac`: i looked at the jenkins job. that seems good enough
<plars> doanac`: I think he was just trying to make sure the job wouldn't stomp on daily smoke testing if they both happened at the same time
<doanac`> plars: oh - that should be fine. our new pooling should handle things correctly. I mis-read the bug, they want dashboard-like runs. not results
<sil2100> thostr_: hi! Is that a touch landing?
<sil2100> thostr_: since it says 'mostly desktop' ;)
<thostr_> sil2100: mostly, but not all
<thostr_> sil2100: it's converged, so applicable to everything in the end
<sil2100> didrocks: ^ can I assign a silo for those? It's line 30, it's all indicators
 * sil2100 is normally a bit worried about those
<Laney> sil2100: (tedg:) we were discussing fixing the OnlyShowIn lines in those yesterday, so i'm not sure they are ready
<sil2100> Laney: ok, I'll switch it to 'Ready: No' - once there is a final decision, just switch that back to Yes and we'll see about assigning a silo ;)
<seb128> sil2100, thostr_, Laney: changes to upstart jobs could impact on the phone I think
<Laney> I think they break !Unity users as is
<seb128> Laney, tedg: do we have a summary of what issues we try to address with those changes?
<seb128> I don't understand the problem/why we change
<Laney> didn't try to understand that part, just pushing back on the OnlyShowIn thing
<tedg> We're fixing a couple things, but mostly it's for consistency.  For instance indicator-application is basically broken in XFCE.
<tedg> Some indicators didn't have respawn stanzas or limits.
<tedg> etc., etc., with that set everyone behaves the same.
<psivaa> didrocks: so with 202 the screen unlocking still fails with a number of tests. probably some conflicting packages to what's already in 202 causing this.
<tedg> I need to adjust the conf file slightly for the XFCE folks.  I wasn't hurrying because of no-silos.  Can do now.
<psivaa> didrocks: because the archive has moved on and during each test we download app, test AP packages from the archive and they might clash with the versions in 202
<retoaded> ChrisTownsend yes, the mp is already in an Approved state so will not trigger a  run.
<ChrisTownsend> retoaded: Ok, thanks for confirming.
<retoaded> np
<ChrisTownsend> retoaded: Do you know if setting it back to Needs Review->Approved will trigger a CI job now that Nux is part of the CI train and automerging is disabled?
<ogra> cyphermox, https://launchpad.net/bugs/1285146
<ubot5> Ubuntu bug 1285146 in bluetooth-touch (Ubuntu) "Bluetooth on flo can be easily enabled but the indicator does not recognize it" [High,New]
<doanac`> didrocks: FYI - bug 1284226 has been released. we are now doing setup/teardown for each test. this should hopefully help the ofono-simd issue
<cyphermox> ogra: thx
<ubot5> bug 1284226 in Ubuntu CI Services "touch daily image test: need to install and remove deps for each testsuite" [High,Fix released] https://launchpad.net/bugs/1284226
<retoaded> ChrisTownsend, yes it should.
<ogra> cyphermox, if you need any other logs or info, just let me know
<ChrisTownsend> retoaded: Ok, thanks.  I'll give it a try.
<retoaded> ack
<tedg> Laney, sil2100, seb128, Updated with the change requested by the Xubuntu folks.
<Laney> tedg: I think you also need to fix the OnlyShowIn conditions in the xdg files (remove it?) for non-upstart folks
<Laney> Or OnlyShowIn=GNOME;Unity;XFCE;\nAutostartCondition=GNOME3 unless-session gnome or something
<tedg> Laney, I don't think so.  For instance if you installed Kubuntu, you wouldn't want it to launch the indicator services.
<tedg> I don't think that GNOME wants indicator services, eh?
<Laney> fallback sure does
<tedg> Fallback?
<Laney> panel
<tedg> MATE?
<Laney> no
<seb128> tedg, "Ubuntu classic" if you prefer :p gnome-panel + indicators + compiz (or other wm if you prefer)
<tedg> seb128, Laney, what does that set as its desktop session?
<dbarth_> sil2100 or an EU guy, can i get a reconfig on silo-005?
<dbarth_> we won't land but will use that for final tests and upload to public ppa
<dbarth_> sil2100: that was silo-001 sorry
<Laney> tedg: XDG_CURRENT_DESKTOP=GNOME; I think what I listed up there ought to work
<tedg> Laney, Won't that screw Gnome Shell then?
<seb128> tedg, GNOME atm I think, but they are talking about changing to Unity
<tedg> Ha, I'm in the future already :-)
<Laney> why?
<Laney> See the AutostartCondition
<ogra> bug 1285234
<ubot5> bug 1285234 in lightdm (Ubuntu) "lightdm on touch leaves a unity-system-compositor process around" [Undecided,New] https://launchpad.net/bugs/1285234
<tedg> Laney, Doesn't that just check the desktop session to see if it's "gnome" ?
<Laney> what more do you want to do?
<tedg> I think you need to distinguish between not-gnome and gnome.
<tedg> Or I guess, was-gnome
<Laney> 'gnome' means gnome-shell
<tedg> Yes, which is why the gnome-fallback shouldn't say that it's gnome.  It's not.
<Laney> I'm not sure what you're talking about, I'm afraid
<sil2100> dbarth_: looking
<Laney> XDG_CURRENT_DESKTOP is what OnlyShowIn looks at and DESKTOP_SESSION is what the unless-session is considering
<Laney> It's basically exactly what we're doing for gnome-screensaver already
<sil2100> dbarth_: ok, so silo 001, right?
<tedg> Uhg, okay.  I think that's kinda a hack.  But if it makes fallback work I don't care.
<Laney> It's all worse than dbus activation. :)
<tedg> DBus activation is a hack, it's hard to rank them though.
<sil2100> dbarth_: ok, reconfiguring 001 and setting to Testing to No
<didrocks> doanac`: excellent! so next run? :)
<didrocks> sil2100: ask them to rerun the tests on the phone as well (unity8 in particular)
<didrocks> sil2100: if so, ok
<didrocks> psivaa: argh, so only click apps failed?
<didrocks> asac: ogra: so, we can't have results on 202 either :/
<ogra> didrocks, sad :(
<bregma> sil2100, I can has silos for line 44 and line 45 pretty please?
<dbarth_> sil2100: thank you
<asac> didrocks: 202? i see results
<asac> also its in the past
<ogra> asac, ignore the dashboard
<didrocks> asac: the results were partials
<ogra> this 202 test was running on a device that isnt attached to it
<psivaa> didrocks: not only them but also the the apps whose tests download some deps from the archive
<ogra> asac, we were hoping we can get a gree 202 to fix the click upgrader issue
<didrocks> psivaa: I doubt we had imcompatible changes here
<ogra> *green
<didrocks> asac: we wanted full results because latest image we promoted doesn't have the click upgrade UI
<asac> didrocks: is there a way at all to get those results still?
<didrocks> asac: that's what I was asking psivaa for, but seems not
<ogra> asac, the original tests fell over heavily
<ogra> so we wanted it re-tested ... but that was not a dashboard capable setup
<ogra> and it seems it didnt work nyway
<ogra> *anyway
<ogra> because the click apps and autopilot are out of sync now
<asac> psivaa: plars: can we get a rerun of 202?
<psivaa> didrocks: http://q-jenkins.ubuntu-ci:8080/job/psivaa-trusty-touch-mako-smoke-daily/4/testReport/junit/%28root%29/camera_app/setup/ is one example
<ogra> asac, it wont help
<plars> asac: I think psivaa was already having one in progress
<ogra> asac, we would have to roll back the archive ....
<didrocks> psivaa: why can't it fetch python-gi?
<psivaa> asac: the version that image 202 looks for is not in the archive.
<psivaa> didrocks: ^
<didrocks> psivaa: ah, you don't apt-get update before installing
<psivaa> i guess we could probably force fix like apt-get update and stuff.. but that will take time
<sil2100> bregma: looking
<didrocks> doanac`: can you look at that? it's a valid case ^
<didrocks> even if we still have the initial flaw, the autopilot are potentially not matching the version we have on the device
<ogra> right
<tedg> Laney, Updated
<Laney> tedg: cheers, LGTM
<Laney> I only checked the diff for bluetooth, assuming the rest are the same
<Laney> no, wait, the second one hasn't been updated
<sil2100> bregma: 44 assigned
<psivaa> didrocks: i could run apt-get update and rerun the tests to see if there is any improvement but i think then the results wont exactly be that of 202
<ogra> heh, on 209 the flo results are actually better than mako
<ogra> (one crash less)
<bregma> sil2100, that's the priority one, thanks
<sil2100> bregma: 45 assigned as well o/
<bregma> ta
<doanac`> didrocks: catching backscroll. so we want to call: apt-get update; apt-get install <pkg> instead of just calling apt-get install <pkg>, correct?
<didrocks> doanac`: exactly
<ogra> but only for re-running tests
<didrocks> psivaa: well, will still be better than no results, I don't think as long as we don't dist-upgrade that we'll have different apps
<didrocks> yeah
<doanac`> didrocks: sure. that's a simple change
<plars> didrocks: asac: I thought we said before that we never want to do apt-get update during a test run, because we could pull in newer versions of things than what we want from the archive
<plars> doanac`: ^
<ogra> plars, right ... but this one test is a special case
<plars> so we are talking about a one-off here, not in general
<ogra> since it cant find a version at all for this old image if you dont run apt-get update
<ogra> yeah, please dont apt-get update on normal tests :)
<doanac`> ah - so we *only* do apt-get update for a "re-run"
<ogra> yes
<doanac`> ogra: k, thanks for the clarification. sorry i misunderstood at first
<ogra> since for that the version in the archive can have moved forward ... so the Packages file is out of sync with the actual archive and you will get 404s
<plars> doanac`: psivaa: I think for this one, it would be easier to just go onto the device, apt-get update, upgrade/install those specific packages, and restart the test without reinstallation
<psivaa> ogra: doanac`: we could leave that out and may be add as a manual step not as part of the test
<psivaa> plars: yea
<ogra> right. or a switch or whatever
<elopio> didrocks: now this makes more sense: http://ci.ubuntu.com/smokeng/trusty/touch/mako/209:20140226.1:20140224/6842/ubuntu_clock_app/819490/
<elopio> we are starting with no alarms, so we can't delete any of them.
<elopio> ultimately, that's because of bug https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1275060 I'll try to fix it today.
<ubot5> Ubuntu bug 1275060 in Ubuntu UI Toolkit "QQuickListView fails to click an element if part of the list is out of view" [Undecided,Confirmed]
<ogra> the best would actually be if we could do a snapshot of the archive when we build an image and always have the test point at that
<ogra> but thats quite some effort
<sil2100> balloons: ping
<sil2100> balloons: did you see my comment on the terminal-app flaky test bug?
<didrocks> elopio: ah ok, so clock-app understood :)
<didrocks> elopio: just all the others to understand now :p
<didrocks> elopio: good luck, do not hesitate to answer on the phone ML
<didrocks> asac: doanac`: hum, however, setup and teardown are counted as tests on the dashboard, is that expected?
<elopio> :) everything - 1 to go
<didrocks> asac: doanac`: for instance, if we can't run any application test, we have 80% of tests passing: http://ci.ubuntu.com/smokeng/trusty/touch/mako/209:20140226.1:20140224/6842/ubuntu_filemanager_app/
<doanac`> didrocks: yeah. i needed to report them now, as they could fail and we'd need to know
<didrocks> doanac`: ok, but the count is puzzling then ;)
<balloons> sil2100, no, I can look
<didrocks> like 80% "not that bad", oh no test were run :p
<sil2100> didrocks: be right there
<doanac`> didrocks: yeah. that's a good point.
<sil2100> Had a prank call to the door just now
<sil2100> balloons: your theory with input events might be right according to that ;)
<doanac`> didrocks: not sure the best way to fix that. i'll open a bug and discuss with team
<didrocks> doanac`: thanks!
 * balloons reads
<balloons> sil2100, where did you find the logs you looked at? And yes I think your questions are quite valid
<sil2100> balloons: in the smoketesting test results, the ubuntu-terminal-app application logs are attached to the AP result
<balloons> ahh, ok
<ogra> rsalveti, did you knwo that 4.4 changed the oomkiller ?
<ogra> who knows, probably the breakage is related
<rsalveti> shouldn't
<ogra> didrocks seems ot have more info, seems to have been mentioned in some android podcast today
<rsalveti> interesting
<rsalveti> well, not for every kernel
<psivaa> didrocks: so running the tests after apt-get update resolves the package mismatches but the screen unlocking still fails
<rsalveti> on another call now, but we're still debugging the crash
<rsalveti> it happens with SF as well, so easier to debug
<ogra> rsalveti, yeah
<psivaa> didrocks: ogra: i see that happened after unity 8 test runs on 202 but dont see any packages being installed just before untiy8 tests
<ogra> weird
<ogra> rsalveti, did you get anywhere with the non working calls on second call ?
<ogra> or is that on hold for unity ?
<rsalveti> ogra: fully focued on unity8, but will get to that later today for sure
<ogra> ok
<psivaa> and i checked unity8_7.84+14.04.20140221.orig.tar.gz was the version when we originally ran unity8 and that is the same version that the test uses now as well
<ogra> (just was asked in the meeting)
<rsalveti> always the feeling we're getting closer to know what is wrong
<doanac`> psivaa, plars, didrocks: as per the misleading pass-rate calculations: https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1285266
<ubot5> Ubuntu bug 1285266 in Ubuntu CI Services "dashboard pass-rates can be misleading" [Medium,New]
<sil2100> rsalveti: we're keeping our fingers crossed o/
<rsalveti> yeah :-)
<didrocks> doanac`: thanks
<didrocks> rsalveti: ok, so, what I mentionned during the meeting is that in the android 4.4 kitkat developer podcast (from google), they mentionned they have made adjustement to their oom killer
<didrocks> rsalveti: (yeah, I'm listening to it while exercising)
<didrocks> rsalveti: so, they told they are way more aggressive in killing cached applications
<rsalveti> interesting
<didrocks> not sure how our apps are seen on the android side as there is no onstage/cached applications notion
<didrocks> that would map with other failures we see
<didrocks> (no crash though)
<didrocks> like some applications don't have any pid and the tests failed
<didrocks> or .service don't respond
<didrocks> asac: FYI as well ^
<rsalveti> no pid and no crash?
<rsalveti> but I'd guess dmesg to say something
<rsalveti> *expect
 * didrocks tries to refind one test
<didrocks> rsalveti: hum, actually, maybe the dashboard was slow to update the artefacts, but I found one crash on that one
<didrocks> let me look at other
<didrocks> (I was looking at http://ci.ubuntu.com/smokeng/trusty/touch/mako/209:20140226.1:20140224/6842/gallery_app/818684/)
<rsalveti> yeah, I'd expect at least one crash
<didrocks> no dmesg though in artefacts :/
<didrocks> to see if oomkiller entered into action
<didrocks> yeah, nothing without crash in 229 or 228
<didrocks> 209* 208*
<ogra> 2009 2008 ?
<ogra> :P
<didrocks> ogra: you start trolling me again! :)
<ogra> lol
<didrocks> ogra: do you have a window dedicated to g+ btw? :)
<didrocks> or even a monitor/device
<ogra> well i read G+ before going downstairs after the meeting :)
<didrocks> ahah :)
<ogra> since google accounts dont really work for hangouts anymore i cant really keep a dedicated window for it anymore ... i used to do that though
<didrocks> rsalveti: btw, finally found an official (written) source: https://source.android.com/devices/low-ram.html:
<didrocks> "Tuned memory use of low-RAM devices: tighter out-of-memory (OOM) adjustment levels, smaller graphics caches, etc.
<didrocks> "
<didrocks> ogra: use 2 profiles on your browser
<didrocks> and:
<didrocks> "Kill processes (even ordinarily unkillable ones such as the current IME) that get too large in idle maintenance."
<ogra> hmm, never tried that
<ogra> didrocks, you should point ricmm and tvoss at that
<didrocks> I think they are pinged now :)
<ogra> might actually have impact on our app lifecycle
<ogra> yeah :)
<didrocks> ricmm: tvoss: backlog the last 30 lines. Basically, oomkiller changed in 4.4, so that can explain all the flakyness we start to see ^
<rsalveti> yeah, so it's not on the kernel side
<didrocks> it's another process we are not using?
<rsalveti> they just changed the threshold
<ogra> well, probably also the defaults in kernel
<ogra> we should at least take a look
<rsalveti> not so sure, as it's not needed
<rsalveti> grouper kernel for example is the same old
<rsalveti> one
<ogra> i doubt it would affect testing
<rsalveti> emulator as well, nothing changed
<tvoss> rsalveti, yup, the default thresholds are adjusted
<ogra> if it affects anything it is long running apps
<tvoss> ogra, well, that depends on us to mark long-running correctly
<didrocks> Donât allow large services to put themselves back into A Services (so they canât cause the launcher to be killed).
<ogra> tvoss, well, if we dont change it but the kernel default does it doesnt depend on us :)
<didrocks> not sure if we try to do that (or if it's another way of marking, only on dalvik side)
<tvoss> didrocks, nothing about dalvik here. can you check in logcat if you see anything suspicious?
<tvoss> ogra, ^
<om26er> retoaded, hey! can we disable apport 'report a problem' in otto ? it comes up during our tests and causes failures
<ogra> tvoss, http://paste.ubuntu.com/7001147/
<ogra> (thats a flo (new N7)
<ogra> nothing that strikes me
<ogra> cyphermox, yay ... i got a BT indicator after the echo
<tvoss> ogra, I see an egl context creation issue
<tvoss> ogra, E/libEGL  ( 1762): eglMakeCurrent:775 error 3009 (EGL_BAD_MATCH)
<plars> bfiller: any ideas on why https://jenkins.qa.ubuntu.com/job/trusty-touch-flo-smoke-daily/4/consoleFull seemed to fail out early? This was on flo
<ogra> tvoss, hmm
<tvoss> ogra, which process is 1762
<ogra> tvoss, dunno, i rebooted already
<bfiller> plars: which issue is this one?
<bfiller> plars: hard to tell what's wrong in that massive log :)
<plars> bfiller: I'm trying to get complete results on flo, and there were a few tests that didn't run to completion
<plars> bfiller: ah, sorry about that - search for "testing messaging" and it should get you to the right section
<plars> bfiller: messaging app
<balloons> popey, davmor2, do you notice that apps tend to end white-screened after closing on the latest images?
<bfiller> plars: ok
<davmor2> balloons: ah so maybe not just a qt5.2.1 issue then
<balloons> davmor2, yes, perhaps something else if you've noticed it
<popey> balloons: davmor2 yes
<balloons> davmor2, popey any bug, if not I guess I'll file
<davmor2> balloons: it seems to happen on qt.5.2.1 on  209  notably on ap tests
<balloons> I'm going to assume qmlscene
<popey> no, i thought it was an AP "feature"
<balloons> haha
<davmor2> popey: I'll set thomi on you
<bfiller> plars: do they fail if you run them manually on the device?
<ogra> tvoss, so next boot ... http://paste.ubuntu.com/7001213/ ... pid 1734 is unity8 ... probably something for either Saviq, ricmm or the Mir team to look at
<plars> bfiller: no idea, I don't have a flo, and my mako is tied up at the moment trying to reproduce the unlock screen errors
<davmor2> popey: and you know he is from the mordor side of New Zealand
<ogra> oooh intresting ...
<ogra> pid 1759 is actually maliit-server
<balloons> ok, so I'll check and see what it looks like
<ogra> why does that talk directly to the driver ?
<davmor2> balloons, popey: is one of you writing a bug for that one?
<tvoss> ogra, it talks to libEGL
<ogra> why ?
<balloons> davmor2, I am.. However, it doesn't seem like the app is still running
<ogra> shouldnt it all go through the shell ?
<balloons> looking at the process list
<popey> yeah, the app is finished
<balloons> that makes sense, but ...
<popey> it just leaves white behind
<balloons> right.. why the white?
<tvoss> ogra, nope, apps use egl
<tvoss> ogra, it's not a driver in the classical sense
<ogra> ah, k
<bfiller> plars: I can ask osomon tomorrow to try it on flo, he's the only one on our team who has one
<tvoss> ricmm, Saviq I see an an eglMakeCurrent failing in Unity8
* fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: fginther | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Landing instructions: http://goo.gl/8H1Du3 | Known Issues: -
<seb128> cyphermox, hey
<davmor2> balloons: it looks to me like the window that opens first and then you have the second or 2 wait for the app to open on it
<plars> bfiller: thanks!
<balloons> davmor2, popey do you only see this with autopilot?
<davmor2> balloons: pass I've only been running ap tests
<davmor2> let me try an app noramlly
<popey> ditto
<davmor2> balloons: okay so taking a quick look at the browser, if I swipe the app out of the way then close via the dash I get no issues, however if I open the hud and hit quit I briefly get a black screen in place.  So I wonder if it is the way that ap is closing the app?
<balloons> davmor2, I assume yes. The app launch for ap changed very recently
<balloons> I assume this is fallout, but not limited to ap
<balloons> davmor2, popey https://bugs.launchpad.net/autopilot/+bug/1285305
<ubot5> Ubuntu bug 1285305 in qtdeclarative-opensource-src (Ubuntu) "Apps leave whitescreen behind upon exiting" [Undecided,New]
<davmor2> confirmededed
<ogra> dededed ?
<popey> â food
<om26er> fginther, hello :)
<om26er> fginther, did you get a chance to look into 'report a problem' issue in otto ?
<fginther> om26er, can you give me some more context? I'm not sure what you are referring to
<bfiller> om26er: hey, any idea what would cause this failure? do we need an eventually somewhere? http://paste.ubuntu.com/6993735/
<cyphermox> seb128: hey?
<om26er> fginther, sorry about that, in some of the cases our tests fail because the apport 'report a problem' window comes on screen, so autopilot have a way to check the before-after of the system and it sees a new window being started and not closed
<om26er> fginther, https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/3116/testReport/junit/ubuntu_system_settings.tests.test_datetime/TimeDateTestCase/test_searching_tz_not_found_with_mouse_/
<bfiller> om26er: it's timing out just trying to switch tabs, seems pretty fundamental (gallery-app)
<fginther> om26er, I remember now. I have not had a chance to investigate yet. how often do you see this problem?
<om26er> bfiller, i am trying to figure out, is there a way to reproduce the issue ?
<om26er> fginther, almost everytime for ubuntu-system-settings tests
<bfiller> om26er: I haven't been able to reproduce yet, but very reproducible on smoketests
<om26er> bfiller, looks like tab switching went bad indeed
<om26er> fginther, wouldn't 'sudo service apport stop' do it for us ?
<om26er> bfiller, let me try to reproduce it on my phone
<fginther> om26er, that should work, I just need to make sure that doesn't impact actual crash collection. I'll give this a test today
<retoaded> om26er, fginther: sorry, I forgot to respond to the issue but I was looking into it. only one of the nodes that are specifically marked as otto nodes had apport installed/running.
<fginther> retoaded, interesting... It's still possible that when the otto lxc container loads it re-enables apport. I'm not very familiar with how services are treated
<fginther> retoaded, thanks for checking
<retoaded> np
<bfiller> om26er: weird when running the test manually it first switches to the Photos tab, then to the Albums tab
<om26er> bfiller, thats how its supposed to work with autopilot, the tabs are switched one after the other
<bfiller> om26er: oh
<bfiller> om26er: thought it would swtich directly to the requested tab
<om26er> bfiller, i am running the test, its working fine for me. going to run the suite in a loop
<cgoldberg> robru, cyphermox, Hi.. I've got a landing for Autopilot, just added to spreadsheet (line 48) .. can i get a silo allocated today for that?
<cyphermox> cgoldberg: IIRC only if it fixed current known regressions
<cyphermox> *fixes
<thomi> cyphermox: we have a FFE, and it contains bug fixes - is that enough, or...?
<cyphermox> it's slightly unclear to me, is this the fix for the state not found thing?
<thomi> cyphermox: no
<cyphermox> thomi: as I recall, didrocks mentioned we were mostly looking at fixing the things that are currently broken in the image
<cyphermox> I can allocate, but we won't publish it
<thomi> cyphermox: thanks. Hopefully by the time we're done with the testing the image will be fixed.
<cyphermox> hmm
<cgoldberg> cyphermox, cool.. that would help
<cyphermox> checking, perhaps it's even "don't allocate" from the message I had yesterday
<cyphermox> the problem is, if you have that assigned and then you want to land the fix for the state thing, then we won't be able to
<cyphermox> robru: what do you think?
<thomi> cyphermox: why not? Can't we just add additional MPs to the silo and re-spin?
<thomi> err, re-allocate.. or whatever it is you guys do :)
<ogra> cyphermox, https://code.launchpad.net/~ogra/ubuntu/trusty/bluetooth-touch/add-flo/+merge/208461 for you
<asac> cyphermox: thomi: think adding new MPs for components is fine. just remember that there is risk that as part of getting image fixed we might to invalidate silos as we have to shovel a cherry pick in or land something that makes you need to retest everything.
<thomi> asac: sure, thanks.
<asac> thomi: anyway, please get the state not found thing sorted. seems that elopio didnt know what to do to fix things
<cyphermox> that's what I meant
<ogra> cyphermox, note that this MP also fixes a test failure on flo (BT indicator in unity8) so it should be fine to land it at any time
<thomi> asac: elopio just told me that it's fixed already
<asac> thomi: or has a different order of fixing bad tests than the ones that show problems
<asac> oh
<thomi> asac: elopio is the guy you want to talk to about that :)
<asac> thomi: where is it :)
<cyphermox> ogra: actually, no
<asac> thomi: i talked today and the above is what i last heard
<ogra> cyphermox, why no ?
<asac> elopio: there :)?
<ogra> cyphermox, works fine here
<asac> elopio: gimme MPs that have the fixes
<cyphermox> ogra: we discussed dropping any device-specific jobs, there is a better way to do this that should work on all devices just the same
<ogra> cyphermox, the chipset is the same as on mako and uses the same way of initialization
<elopio> thomi: asac, I said that I'm not able to reproduce the StateNotFound errors that we got on image 206, and more recent images don't show StateNotFound errors.
<cyphermox> yes
<elopio> so whatever was causing it, seems to be fixed now.
<cyphermox> ogra: but you shouldn't have to poke hci_smd_set yourself either
<ogra> cyphermox, and we try to get to green images again
 * asac checks
<cyphermox> ogra: gosh, I hadn't thought of this
<cyphermox> ogra: give me a minute
<ogra> if you want to rework the whole way of starting thats fine
<elopio> asac: the errors we are getting now make more sense, and I'm slowly working on them. First, the clock needs to create an alarm before deleting it.
<ogra> my MP is good as an interim fix to get one failure down
<asac> elopio: here is what didrocks sent around a bit earlier: "Work is going on. Leo wasn't able to reproduce it, some back and force on the mail comments shed some lights (with a whole list of tests that failed on #206, #207 and #208."
<cyphermox> ogra: then don't bother sending an MP and just push it if that's what you'd prefer...
<asac> elopio: ok you rock. sorry for making unqualified commments.
<ogra> cyphermox, well, its your baby, i'd like you to nod it off :)
<ogra> and its in CI, isnt it ?
<cyphermox> ogra: I don't remember
<ogra> heh, k
<cyphermox> heh, whatever
<ogra> root@ubuntu-phablet:/# grep hcismd_set /var/lib/lxc/android/rootfs/* 2>/dev/null
<ogra> root@ubuntu-phablet:/#
<ogra> cyphermox, ^^^
<ogra> i fear there is nothing on the android side touching that
<ogra> guessing there is some UI tool that does the echoing
<cyphermox> ogra: there should have been
<cyphermox> but I guess for that particular device bludroid does it now
<ogra> well, not in the init.*.rc files
<cyphermox> >.<
<cyphermox> I can read
<cyphermox> approved
<ogra> well, i wonder if bludroid does it for all 4.4 devices now ...
<cyphermox> I don't really want to mess with this right now
<ogra> then we would have that issue on all of the,
<ogra> ok, i'll just uplaod then
<cyphermox> yeah
<cyphermox> apparently it's hard for android to decide how they want to do stuff
<ogra> :)
<seb128> cyphermox, hey!
<cyphermox> ogra: the end result will have to be that we make the bluetooth.status job or whatever seems to be the "standard" on 4.4 do the /sys/module poking and just start the *.bt.sh job and then that one
<seb128> cyphermox, can I haz slots?!
<seb128> ;-)
<cyphermox> ogra: but I guess that will be for laterz
<seb128> cyphermox, l46&47
<ogra> cyphermox, yeah
<cyphermox> seb128: shouldn't this stuff be blocked by beta?
<seb128> cyphermox, there is no such thing as proposed block
<seb128> cyphermox, we stopped blocking upload, we just block britney/transitions to trusty
<cyphermox> yes, I know
<cyphermox> just saying
<ogra> bt-touch uploaded
<ogra> one failure down on flo :)
<ogra> only 3164323 left
<ogra> :P
<rsalveti> ogra: at least we just found out that the unity8 crash is not only happening with unity8
<rsalveti> it seems to be qt related somehow
<rsalveti> the crash we got with unity8, gallery-app and weather-app (qmlscene) are all the same
<ogra> rsalveti, well, did you see my discussion with tvoss above
<ogra> there seem to be EGL issues too
<cyphermox> ogra: cool
<rsalveti> ogra: which issues?
<ogra> rsalveti, http://paste.ubuntu.com/7001213/ EGL_BAD_MATCH ...
<rsalveti> we always had one error
<ogra> rsalveti, pid 1734 is unity8 ... 1759 is maliit--server
<ogra> ah, k
<rsalveti> but don't know which one :-)
<ogra> heh
<rsalveti> ogra: check your mako
<rsalveti> ogra: should happen for every app you load
 * ogra notices that he cant fing his mako 
<ogra> argh !
<ogra> damned ... that slippery thing always slides down where i put it ... and then vanishes between some papers or so
<ogra> grrr
<rsalveti> hahah
<Saviq> tvoss, there *was* a bug I believe
<tvoss> Saviq, hmmm ... worth investigating?
<ralsina_> robru: can I get a reconfigure for silo 14? I added a new branch https://code.launchpad.net/~dobey/unity-scope-click/post-method/+merge/208210
<ralsina_>  to the spreadsheet
<robru> ralsina_, sure
<Saviq> tvoss, isn't it the one when your screen was off?
<robru> ralsina_, please just space-separate the URLs though
<ralsina_> robru: ok
<tvoss> Saviq, hmmm, good point
<tvoss> Saviq, what about the egl swap interval thingy?
<ralsina_> robru: fixed
<tvoss> Saviq, also: you might want to spin a build of u8 with address sanitizer enabled
<Saviq> tvoss, https://bugs.launchpad.net/unity8/+bug/1261466
<ubot5> Ubuntu bug 1236525 in unity-mir "duplicate for #1261466 unity8 killed/crash then restart can result in mir unable "could not unblank display"" [Medium,Triaged]
<tvoss> Saviq, haven't come to it, yet
<robru> ralsina_, ok, please build
<Saviq> tvoss, what about the swap interval thingy?
<tvoss> Saviq, there is an error reported here: http://paste.ubuntu.com/7001147/
<ralsina_> robru: started, thanks
<robru> ralsina_, you're welcome
<tvoss> Saviq, line 427ff
<Saviq> ETOOMANYLINES
<Saviq> tvoss, not sure what to do about that, is that happening at the same time the eglMakeCurrent, or?
<tvoss> Saviq, might well be ...  hang on, got a theory
<rsalveti> ogra: the unicode error http://paste.ubuntu.com/7001623/
<rsalveti> this is when running tests with flo
<ogra> rsalveti, yeap, seen that
<ogra> (and i have seen that before too ... like months ago ... and i know someone fixed it ... but cant remember when or who)
<ogra> (or where even)
<rsalveti> right
<rsalveti> was happening a few weeks ago
<ogra> yep
<cgoldberg> cyphermox, line 16, windowmocker.. is that landing today?
<bfiller> om26er: any luck reproducing?
<om26er> bfiller, not in a reproducible fashion, I ran the whole suite and one one of the tests failed with a similar error message from dbus
<asac> cyphermox: can you easily see how many silos are currently loaded?
<asac> kgunn: how many silos do you have in theory ready for landing?
<om26er> bfiller, let me inspect the test code, I might find something there
<cyphermox> asac yes
<cyphermox> http://calypso.cyphermox.net/~mtrudel/silos/
<cyphermox> I made myself a graph
<cyphermox> it updates every hour
<asac> cyphermox: ok, i think i am interested in loaded and green :)
<asac> hehe
<asac> always more and more
<cyphermox> bah
<bfiller> om26er: ok thanks, yes I see the same failure in another gallery-app test from the nightly build: http://ci.ubuntu.com/smokeng/trusty/touch/mako/209:20140226.1:20140224/6842/gallery_app/818684/
<om26er> bfiller, I saw the failure in test_add_photo as well
<cyphermox> cgoldberg: I guess it could land today
<kgunn> asac: actually i have a question about that...
<kgunn> i have 1 unity-mir silo
<kgunn> but...
<kgunn> i really would like a silo in preparation for landing to begin...i'd like to have one for mir ?
<kgunn> is it possible?
<asac> kgunn: so we need fast path silos
<asac> we have 17 allocated already.
<asac> dont think we can really hand out more new ones :( ... otherwise we cant land the fixes for the regressions quickly once they came in
<asac> come in
<kgunn> ack
<asac> kgunn: we probably could hand out one more ...
<asac> i would really like to see this unity8 heap crash fixed somehow. from what i understand its 40% chance of being mir and 30% chance of being android 4.4 and the rest something else
<kgunn> it'd be great if i got a silo
<kgunn> i'm following phablet as well...seems like
<asac> cyphermox: did anyone request a silo today?
<kgunn> there's lots of suspiscions around TLS and hybris
<asac> kgunn: so problem is that if a patch with mir comes out that fixes this, we would have to invalidate all your work if we want to land that cherry pickish
<ogra> there is a long discussion about this going on atm on the internal channel (for whatever reason)
<kgunn> ack, happy to be invalidated if its mir's fault
<asac> kgunn: let me wait on what cypher says about my question above.
<asac> need to be somewhat fair
<kgunn> yep...thanks for trying at least
<asac> bfiller: how many silos do you have loaded?
<cyphermox> asac: yes, cgoldberg and seb128
<asac> cyphermox: which landing topic?
<cyphermox> 46, 47, 48
<asac> isnt cgoldberg autopilot?
<cyphermox> you didn't specify
<asac> me didnt specify?
<bfiller> asac: you mean how many outstanding requests do we have in the train?
<bfiller> asac: I think 4 or 5
<cyphermox> yes, autopilot, unity-control-center and dbustest-runner
<asac> bfiller: how many silos do you have loaded and validated
<asac> or in progress
<asac> cyphermox: ok, but those got a silo it seems? i was interested if we rejected requests for new silos
<bfiller> asac: none loaded and validated, many waiting for silos
<asac> bfiller: think you are close to gallery or dialer fix?
<asac> those are the ones you investigate right?
<bfiller> asac: om26er helping with gallery, just sent an email about that. I don't know how to proceed on that one
<bfiller> looks like Chris gagnon just pushed a fix for some dialer-app flakiness
<bfiller> asac: we can release that
<om26er> bfiller, btw there is also a gallery-app.crash file as well so the app might have crashed
<om26er> http://ci.ubuntu.com/smokeng/trusty/touch/mako/209:20140226.1:20140224/6842/gallery_app/
<asac> bfiller: ok cool. you could piggyback your other landings in that landing
<asac> :)
<asac> as an idea
<asac> e.g. make one big silo request that also includes that fix... but please be extra careful about regressions in those other apps
<asac> bfiller: what do you think?
<bfiller> asac: yeah, was thinking that. but we have a bunch of other changes queued. might be better to just do the AP test fix first
<bfiller> asac: just so we don't introduce any other weirdness
<asac> dbarth_: i see you have two silos... are you still working on 005?
<asac> bfiller: yeah, was just thinking how i can jusfity get your other stuff moving. but guess i would get harangued for such a move anyway
<asac> bfiller: so for sure, if there is a dialer fix, land that asap
<dbarth_> asac: 001 could land and free that slot; testing is finished
<bfiller> asac: ok
<asac> dbarth_: we cant really land
<dbarth_> i know
<asac> dbarth_: but want to ensure that others can continue preparing
<asac> dbarth_: whats 001 about?
<dbarth_> but if you want to recycle a ppa, can you take 005, but not 001 please
<dbarth_> 001 i will use to do pkg copies to the sdk
<asac> dbarth_: will surely not recycle a ppa that is validated. dont worry
<asac> dbarth_: just wonder if 005 is still being worked on
<dbarth_> ok
<asac> if you are active on that one i dont want to take that away
<asac> dbarth_: can you explain to me more about 001?
<asac> dbarth_: is that a landing in the centre of the stack?
<asac> or rather a leave component?
<asac> guess its not fully leave
<om26er> bfiller, yes, the time stamps of the .crash file and our ci dashboard match exactly at the same time. the app crashed at 12:42:11 and just 1 second before autopilot raised that error
<bfiller> om26er: interesting
<asac> robru-sick: 006 is in proposed?
<bfiller> asac, robru: line 50 of the sheet has fix for dialer-app tests
<asac> cyphermox: ^^
<bfiller> at least some
<asac> bfiller: good
<asac> thanks!
<asac> cyphermox: can you check if 006 is alreayd in release pcket?
<asac> robru-sick: cyphermox:  bregma: isnt 008 ready for landing?
<asac> seems desktop only
<asac> same for 009
<asac> robru-sick: can we recyclke your cordova cli ppa?
<robru-sick> asac, oh, yeah
<bregma> 0002 and 008 are definitely ready for landing, both exclusively desktop only
<robru-sick> bregma, ok, desktop only we can do
<asac> robru-sick: cyphermox: ^ ... not sure if there is a directive to not land these, if not, lets do it and make room for kgunn and bfiller
<robru-sick> asac, only touch is frozen as far as i know
<asac> bregma: do you have more in the pipe to land right after?
<bfiller> om26er: I downloaded the crash file and installed apport-retrace on the device
<bfiller> om26er: getting this error when I try to run it: apport-retrace -s _usr_bin_gallery-app.32011.crash
<bfiller> ERROR: report file does not contain one of the required fields: CoreDump DistroRelease Package ExecutablePath
<bfiller> om26er: how do I get the backtrace from the crash file?
<robru-sick> bfiller, what's the status of that MP in line 3? will you ever land that? if not, please delete the row
<om26er> bfiller, we can probably try to report that bug to launchpad and it may retrace it for us
<sergiusens> robru-sick, it will land, but needs unity8
<sergiusens> it's in blockade mode now; right?
<bfiller> robru-sick: I think it's still valid
<robru-sick> bfiller, oh ok, i thought it was abandoned. didn't realize you still wanted to land it eventually. thanks
<bfiller> robru-sick: yeah, just didn't want to land it at the time to not interfere with other MR's and possibly break something
<bfiller> sergiusens: you ever use apport-retrace with a crash file from smoketests?
<sergiusens> robru-sick, we need to reconfigure it with unity8 though
<sergiusens> bfiller, nope
<robru-sick> sergiusens, no worries
<bfiller> om26er: would you mind doing that? we need the trace to figure out what's going on
<sergiusens> bfiller, there's an email from ev titled "Manually retracing crashes on Touch images" on the phone list though
<om26er> bfiller, trying to do that but seeing problem here as well
<asac> robru-sick: did you see bfillers silo request?
<asac> oh i see you chattin gwith him
<robru-sick> asac, on it
<sergiusens> bfiller, it might be an incomplete crash
<asac> robru-sick: seems he submitted a regresison fix
<asac> e.g. flaky
<robru-sick> bfiller, ok you got silo 13 for dialer-app
<bfiller> robru-sick: thanks
<robru-sick> bfiller, you're welcome
<asac> robru-sick: the other question was whether 006 is already in release pocket and could be merged back
<asac> seems not
<asac> or maybe the status in that sheet is off
<asac> robru-sick: actualy, is that in for a day already? (e.g. 006)
<robru-sick> asac, yes, that got in yesterday.
<asac> robru-sick: so we can recycle 006?
<robru-sick> asac, yes, but bzoltan will be upset about it.
<asac> e.g. you have to hit merge and clean? please triple check. the commit message in MP looks different
<asac> bzoltan: show up
<asac> robru-sick: but there is no way back anyway
<asac> feels odd
<asac> let me find someone from sdk team
<robru-sick> asac, agreed, it's weird to have a published silo go unmerged for so long
<robru-sick> asac, i guess i should just merge it, and if sdk team finds some problem with the code, we can rush through whatever fixes they feel appropriate.
<asac> give me a sec
<robru-sick> ok
<asac> robru-sick: ok go ahead and hit the button. next time dont do that without sdk folks unless its a firedrill thingy
<asac> kaleo gave an ack
<asac> robru-sick: ok cool
<asac> robru-sick: so 006 is free then afterwards
<asac> also we have two silos freed by bregma
<asac> lets give kgunn and bfiller each one
<robru-sick> asac, ok sorry, thought it was a firedrill situation ;-)
<asac> bfiller: do you wnt to change your landing request to just include all that you want to land
<asac> bfiller: if you merge them you can have everything in one silo
<asac> bfiller: (except the dialer-app which has its own silo)
<bfiller> asac: sure, so combine all requests into one? (except dialer-app)?
<asac> bfiller: i would think in this way you can at least continue staging changes for those apps there
<asac> and hav ea place to basically maintain a temp branch for all
<asac> bfiller: risk is tha tif one app is infected and you notice dduring testing you have to ask to drop that
<asac> and rebuild everything
<asac> bfiller: oh wait
<asac> bfiller: at best dont put an app in that is currently named as flaky
<asac> i would like to see if we can land green apps tomorrow
<asac> even if the image isnt good yet
<om26er> bfiller, you need apport-retrace -sR
<robru-sick> bfiller, kgunn just ping me when your requests are ready to be assigned.
<kgunn> cool thanks guys
<asac> robru-sick: lets keep one of the freed silos for bregma/desktop landings ... e.g. jus thandout one for bfiller and one for kgunn after those three are freed
<kgunn> robru-sick: sorry you're sick...
<robru-sick> kgunn, thanks
<asac> robru-sick: 002 008 and 006 (after the merging)
<bfiller> asac, robru-sick : ack, let me review what I have in the pipeline and rearrange into one
<bfiller> om26er: thanks, trying
<asac> kgunn: bfiller: so 006 will be avail really soon. 002 and 008 will only happen after stuff is through proposed
<asac> you guys decide who goes first :)
 * ogra waits for asac to hand out boxing gloves
<asac> think bfiller could potentially land green apps tomorrow potentially
<asac> so maybe maybe he might be the one that could benefit the most from being ready today
<asac> (but no promisses)
<kgunn> bfiller: you can rock n roll first if you wnat
<seb128> asac, there is a flag to ignore the "going through proposed" step if you want, I'm using it for desktop stuff atm, beta freeze keeps stuff even if they are ready, no reason to not merge back
<asac> seb128: i think our touch stuff goes in by bot
<asac> not?
<ogra> it does
<seb128> "in by bot"?
<ogra> just not the stuff that overlaps with desktop/flavours
<seb128> right
<asac> seb128:  we have an auto approve bot
<asac> so i think lets not use this option
<seb128> well, you can clean the silo even if stuff are still in proposed, that's on box to click on
<seb128> no we don't
<asac> yeah good to know
<asac> oh right its bregma :)
<seb128> we have to click a "clean and merge back" button
<asac> so yeah lets use that for those landings
<seb128> right
<seb128> no reason the unity8 session needs to lock a silo
<seb128> just merge back
<bregma> it's having trouble merging back, seems to want to push to the wrong place
<asac> robru-sick: ^^ thast valid for 002 and 008 i guess.
<robru-sick> asac, ok, on it
<asac> bregma: hmm
<seb128> bregma, where?
<seb128> hum, weird
<bregma> 2014-02-26 21:47:45,715 INFO Trying to push to https://code.launchpad.net/~bregma/unity8-desktop-session/trunk
 * bregma is resigned to forever have problems
<bregma> the merge is not lost, so I'll go ahead and clean the silo, I;m done with it
<seb128> bregma, trunk is owned by you, whoever set that project up didn't do the checking it seems, the jenkins bot needs commit access to the trunk
<bregma> the merge can get clean up later
<robru-sick> bregma, well, the problem there is that you personally own lp:unity8-desktop-session, so citrain doesn't have permission to push there
<bregma> doesn;t make sense why that would be, but I'll figure it out
<seb128> bregma, https://code.launchpad.net/~bregma/unity8-desktop-session/trunk
<seb128> that's owned by you
<seb128> lp:unity8-desktop-session
<robru-sick> bregma, well when you created the project, you would have set up the trunk branch as a branch that you owned, instead of a team-owned branch
<bregma> I understand that's how it looks, but I'm fairly sure I didn;t do that, I must have messed it up some other way
<bfiller> om26er: getting corrupted stack trace, nothing useful from it
<bregma> doesn;t matter, I can recover
<om26er> darn!
<om26er> bfiller, maybe try the crash file from the other failure ?
<robru-sick> bregma, please take this branch specifically: https://code.launchpad.net/~ps-jenkins/unity8-desktop-session/latestsnapshot-recup and push it to something like lp:~unity8-team/unity8-desktop-session/trunk and then reconfigure the lp project trunk to point at that
<bfiller> om26er: I tried both
<om26er> :/
<om26er> bfiller, thats basically a dead end
<bfiller> om26er: wondering if this might be the same crash that dialer experiences due to unity-mir bug
<om26er> bfiller, no, thats probably a different crash, with different symptoms
<bfiller> om26er: this the bug I'm talking about https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1240400
<ubot5> Ubuntu bug 1240400 in unity-mir "dialer-app crashed with SIGSEGV in __GI___pthread_mutex_lock()" [Critical,In progress]
<bfiller> om26er: basically we need to be able to reproduce the crash on a device to see what's going on I think
<bfiller> om26er: going to try and reflash with 209 image and try again with that latest crash file
<om26er> bfiller, dialer-app handles that crash through an exception, it happens on the end of the test normally but yess we need to see on the phone what really happens
<bfiller> om26er: can you get it gallery to crash when you run in a loop or run the entire suite on the device?
<om26er> bfiller, it failed once, so not exactly reproducible but it did happen, i'll run it again
<bfiller> om26er: run "ulimit -c unlimited" first from a shell before you start the tests
<bfiller> that way a core file will be gerneated if crash
<bfiller> sergiusens: what's the new command to reflash with the 4.42 based image?>
<bfiller> can't keep track of it all
 * bfiller getting old
<ChickenCutlass> bfiller: just use devel-propsed
<bfiller> ChickenCutlass: phablet-flash?
<ChickenCutlass> bfiller: ubuntu-device-flash -channel=devel-propsed
<bfiller> ChickenCutlass: as I said, thanks
<asac> bregma: i guess you should merge manually and then move the trunk to a better team
<asac> not exactly sure what rules to obey for the merging though, but maybe seb128 knows
<seb128> seems like bregma figured it out, the silo is being cleaned (didrocks included enough checkboxes/override in the system to let us unblock)
<robru-sick> asac, no need to merge manually, merged branch exists at https://code.launchpad.net/~ps-jenkins/unity8-desktop-session/latestsnapshot-recup already
<bfiller> robru-sick: silo 13 tested, ready to be released
<om26er> bfiller, I have been able to reproduce the crash with albums tests here. what happens is that its able to switch to the albums tab but that tab is shown empty, i.e. no buttons on the toolbar and neither is there any 'dummy' album shown
<om26er> and after a few seconds ofcourse the app has to go
<bfiller> om26er: cool, did it generate a core file?
<om26er> bfiller, i see a core on /home/phablet
<bfiller> om26er: try running "gdb /usr/bin/gallery-app core"
<bfiller> om26er: then "bt" once in gdb
<om26er> bfiller, says corrupt stack
<bfiller> (:
<asac> robru-sick: oh nice
<bfiller> om26er: can you tell me how to reproduce the crash?
<asac> nice feature
<om26er> bfiller, run this multiple times. autopilot run gallery_app.tests.test_album_view
<bfiller> om26er: let me try
<om26er> bfiller, i reported a crash report from the file https://bugs.launchpad.net/ubuntu/+source/gallery-app/+bug/1285387
<ubot5> Error: ubuntu bug 1285387 not found
<om26er> but its pretty much going to be useless as well
<robru-sick> bfiller, thanks
<sergiusens> bfiller, might want 't a a bt' for a bigger picture view
<bfiller> sergiusens: I've tried that
<sergiusens> are looking at the crash on start?
<sergiusens> bfiller, cause rsalveti was thinking that they all have the same root cause
<bfiller> sergiusens: no, just a very hard to reproduce autopilot failure on gallery tests
<sergiusens> ah, ok
<bfiller> sergiusens: don't think it's on startup though
<bfiller> sergiusens: http://ci.ubuntu.com/smokeng/trusty/touch/mako/206:20140224:20140224/6796/gallery_app/
<rsalveti> sergiusens: bfiller: it's the same one
<rsalveti>   #0 0x3810d8f8 in ?? ()
<rsalveti> that's the same offset we get with the qmlcrash and unity8
<bfiller> rsalveti: really?
<rsalveti> yes
<rsalveti> v8 code
<rsalveti> qt v8
<bfiller> rsalveti: you're looking at the .crash file?
<rsalveti> bfiller: stack trace
<rsalveti> bfiller: happens when you start gallery-app
<rsalveti> same for qmlscene and unity8
<bfiller> rsalveti: how do you reproduce?
<bfiller> I can't make it happen
<rsalveti> bfiller: open/close it until you get it
<rsalveti> yeah, it's painful
<rsalveti> and not going to help you either
<rsalveti> we're debugging this crash like 2 days already
<rsalveti> doesn't happen with qt5.2 though
<bfiller> I guess that's good
<bfiller> move on then
<bfiller> rsalveti: is the dialer-app crash the same too?
<rsalveti> bfiller: check the stacktrace
<bfiller> rsalveti: k
<rsalveti> if it ends with d8f8, then yes
<ChickenCutlass> rsalveti: if this crash does not happen with 5.2
<ChickenCutlass> why are we wasting time
 * ChickenCutlass is confused
<bfiller> ChickenCutlass: +1
<bfiller> move one
<bfiller> on
<bfiller> robru-sick: per asac earlier, I've combined a few asks into line 36. so that is ready for a silo
<robru-sick> bfiller, alright
<kgunn> fginther: surely you're eod....
<kgunn> but whoever is taking up vanguard
<kgunn> i've been hawking this for a while
<kgunn> https://code.launchpad.net/~afrantzis/mir/update-valgrind-armhf-suppressions/+merge/208421
<kgunn> and jenkins seems to be ignoring
<kgunn> i suppose i can manual merge...but
<kgunn> stepping away, bbiab
<robru-sick> bfiller, ok you got silo 2, please build.
<bfiller> robru-sick: ack
<bfiller> robru-sick: argh, merge failure
<bfiller> robru-sick: will try and resolve later, dinner now
#ubuntu-ci-eng 2014-02-27
<sergiusens> robru-sick, hey, are you the only one doing slots? Given that you are sick
<fginther> kgunn, looks like it merged on it's own, and yes I should be eod
* fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Landing instructions: http://goo.gl/8H1Du3 | Known Issues: -
<sergiusens> robru-sick, can I cancel sot 3 (as it's blocked) and get a slot for L47?
<robru-sick> sergiusens, sure
<sergiusens> robru-sick, one more for l48 as well; which is desktop as well
<robru-sick> sergiusens, can they be in the same silo? we're a little short right now
<sergiusens> robru-sick, I guess; even if not related
<sergiusens> but also not exclusive
<robru-sick> sergiusens, yeah, would be easier for us.
<sergiusens> want me to bundle?
<robru-sick> sergiusens, yes please
<sergiusens> robru-sick, done
<robru-sick> sergiusens, thanks. just waiting for silo 3 to finish purging
<sergiusens> robru-sick, going to retry that one once unity8 can land again, should I leave that comment?
<robru-sick> sergiusens, sorry what?
<sergiusens> robru-sick, what used to be in silo 3 is going to get retried as soon as stuff can land freely again
<robru-sick> sergiusens, oh right, yeah you can change the comment to be more meaningful. thanks.
<robru-sick> sergiusens, ok, you got silo 3, please build.
<sergiusens> thanks
<robru-sick> you're welcome
<sergiusens> robru-sick, btw, do you have perms to mark https://code.launchpad.net/~ps-jenkins/goget-ubuntu-touch/trusty-proposed as abandoned or mature?
<sergiusens> oh wait
<sergiusens> that's train
<sergiusens> no former daily release
<sergiusens> nvm
<robru-sick> sergiusens, yeah, and I don't have permissions on that account ;-)
<bfiller_afk> robru-sick: I need to drop one of the MR's from silo 2 request, what's the best way to do that?
<bfiller_afk> robru-sick: I've taken it out of line 36 already
<robru-sick> bfiller_afk, sorry, i can do that now
<robru-sick> bfiller_afk, rebuilding for you since you're afk
<asac> bfiller_afk: yeah dropping is a reconfigure with a complete rebuild as robru-sick did
<asac> or is doing
<bzoltan> asac: ping
<bzoltan> asac: I have dropped a mail to you and to a bunch of people... not a big drama, but I would like to understand what I do wrong.
<bzoltan> robru-sick:  hello there... what was with the linenumber 35 landing ask? I marked it "No" and I commented there why I do not like it ... why it was processed?
<bzoltan> asac: at the same time I have an MP with 13 branches
<sil2100> brb, need to jump out for a moment
<bzoltan> didrocks: ping
<didrocks> bzoltan: pong
<bzoltan> didrocks: I put you to the To: in my mail... I am confused and so worried a bit
<bzoltan> didrocks: no big drama, but I wish to understand what just happened
<didrocks> bzoltan: there is nothing new, I'm not sure why you are raising the same thing again
<didrocks> apparently, you already pinged asac at the time
<didrocks> he and I sent an email to robert about it
<bzoltan> didrocks: because an MR landed without our approval
<didrocks> and he excused and understood what happens
<didrocks> bzoltan: right, what you raised 3 days ago?
<didrocks> bzoltan: but it was already landed
<bzoltan> didrocks: yes... and the MR is merged now.
<didrocks> bzoltan: yeah, it was already pushed
<didrocks> as I told you
<bzoltan> didrocks: without testing?
<didrocks> (or if you read the phone ML emails)
<didrocks> apparently he did the sdk testing
<didrocks> so yeah, appart from emergency, this shouldn't happen, as told 3 days ago
<didrocks> but it was already too late
<didrocks> already in proposed
<didrocks> as my 3 last emails on the phone ML is telling
<bzoltan> didrocks: How did it land? The tests were not marked as "done" on the Silo sheet
<didrocks> the only thing that changed is that it reached the release pocket (because of beta freeze)
<didrocks> bzoltan: right, again, same thing than 3 days ago
<didrocks> not sure why you reraise the same issue as it's the one that happened 3 days ago
<bzoltan> didrocks: I still do not get it... how and why an MR lands what is not tested?
<didrocks> grumble
<didrocks> do you read the phone ML?
<didrocks> or not?
<didrocks> seems not :/
<bzoltan> didrocks: I do
<didrocks> well, so as told there
<didrocks> 3 days ago, robert did land a renato's fix for alarm clock
<didrocks> you raised it then
<didrocks> asac and I poke him to get more details
<didrocks> and he apologized to not have followed the process
<didrocks> but the thing was already published
<didrocks> and stuck in proposed
<didrocks> (as told in my emails)
<didrocks> the only thing which changed since yesterday is that it reached the release pocket
<bzoltan> didrocks: I still do not understand why robru-sick lands anything from renato and what do we do to avoid it in the future?
<didrocks> bzoltan: human error, he thought that was proposed by a sdk team member
<didrocks> and he tested it before landing
<bzoltan> didrocks: Human error to land an MP without tests?
<didrocks> bzoltan: seems so
<bzoltan> didrocks: the Silo sheet said that "testing done" - No
<didrocks> bzoltan: yeah, and I raised it
<didrocks> he didn't flip the switch
<didrocks> which is an issue
<bzoltan> didrocks: Human error to create a silo for for an MP not requested by the lander?
<didrocks> bzoltan: any lander can land other components in case of emergency and the primary lander isn't there
<bzoltan> didrocks: human error not to check if the MR is approved?
<didrocks> but they are taking the risk and accept responsability
<didrocks> bzoltan: yeah
<bzoltan> didrocks: this is 3 human errors with one case.
<didrocks> and?
<didrocks> what's your point?
<bzoltan> didrocks: what do we do to avoid it in the future... you made a very strict and riggid (and so good)  CI process. What good it is if people can just do shortcuts whenever they need so?
<didrocks> bzoltan: we need then to educate people
<didrocks> so that it doesn't reproduce
<didrocks> rather than arguing on the same issue than happened 3 days ago
<didrocks> nice you have time for that, I don't though
<bzoltan> didrocks: I am not arguing
<didrocks> I've already take actions
<didrocks> as told
<didrocks> 3 days ago
<didrocks> the landing didn't create regressions, hopefully
<didrocks> (or we would have revert)
<didrocks> and fixed an issue
<bzoltan> didrocks: it did for us
<didrocks> bzoltan: which regression, do you have a bug? do we need to revert?
<bzoltan> didrocks: I pull zsombi|afk in to explain
<didrocks> just point me to a bug report
<didrocks> and tell me if I need to revert
<didrocks> but then, you have to fix the alarm quickly
<didrocks> and only the alarm
<didrocks> or I'll have to revert sdk even more
<didrocks> as your latest landing created that regression
<bzoltan> didrocks: what regression was created by what?
<zsombi> didrocks: I don't get this...
<didrocks> bzoltan: https://bugs.launchpad.net/ubuntu/+source/qtorganizer5-eds/+bug/1282129
<ubot5> Ubuntu bug 1282129 in Ubuntu Clock App "Clock and calendar tests fail with static void QOrganizerEDSEngine::itemsAsyncListed(ECalComponent*, time_t, time_t, FetchRequestData*) " [Undecided,New]
<didrocks> bzoltan: that's what they tried to fix apparently
<zsombi> didrocks: yes, but it WASN'T a regression!
<didrocks> zsombi: it was, we didn't get the crash before and we got it then
<zsombi> didrocks: they wanted to increase the performance as alarms fetching was slow
<didrocks> seems that some tests started to fail because of that
<didrocks> zsombi: so, what regression did it create to you?
<zsombi> didrocks and you haven't seen the crash before? that code in SDK wasn't changed for ages, so how was it a regression?
<didrocks> zsombi: no, we haven't seen the crash before in the daily testing at least
<zsombi> didrocks: with the fix you cannot fetch alarms that are created to a due date > 7 days
<didrocks> zsombi: hum, but you did approve yesterday the MP?
<didrocks> so you approved (even if it was after it landed) a regression?
<bzoltan> didrocks: my previous MP was tested against the calendar_app and it gave green light.
<zsombi> didrocks: but for the Clock app this is NOT a regression, because there you cannot create > 7 days alarm anyway
<didrocks> zsombi: what on the image is creating a 7 days alarm and have tests?
<zsombi> didrocks I approved so the fix can go to MWC if needed, and we are already working on the fix
<didrocks> ok, so sounds you know how to fix it
<didrocks> and no urgency to revert that one
<didrocks> as nothing on the image is using the > 7 days, right?
<zsombi> didrocks yes, I know... believe me approving the MR was a compromise I had to take... I was completely against it, but we had to do this... so no App should be affected, maybe test cases are.
<didrocks> you have tests that are failing?
<zsombi> didrocks: what bothers me was that the MR wasn't top-approved, and was still taken.
<didrocks> zsombi: this is what I discussed with bzoltan 3 days ago
<didrocks> happy that the SDK team can talk about the same issue for 3 days
<didrocks> but meanwhile, there is an image that I need to go back to green, so I don't have the luxury
<didrocks> and speaking of which, the Qt crash raised 4 weeks ago to your team
<zsombi> didrocks: we do not have any tests failing, atm
<didrocks> and dimissed by "we are going to switch to 5.2" is now hitting us badly
<didrocks> zsombi: you should probably then test that
<zsombi> and how can we speek for 3 days on teh same topic if the whole stuff got landed today?
<didrocks> zsombi: it was already in 3 days ago
<didrocks> read the phone ML
<zsombi> didrocks: yes, I'm adding more tests to alarms now as we speek
<didrocks> great
<didrocks> from 25.02.14:
<didrocks> 10. The alarm creating issues on clock apps (Robert).
<didrocks> -> Half of the fix is in the release pocket, the other half (the sdk part) is stuck in proposed due to beta-freeze. Robert is looking if that can goes to the release pocket.
<zsombi> didrocks: I did... and I found the first occurrence about this MP yesterday, on the 25.02.14 landing mail...
<didrocks> zsombi: it was posted 2 days ago
<didrocks> as the fix landed 3 days ago
<zsombi> today is 27th, so only 2 days are gone since then :)
<didrocks> (well 2.5)
<didrocks> zsombi: right, but this is a recap email
<didrocks> and bzoltan started to speak about it at the 25 in the morning
<didrocks> when it was already landed
<zsombi> didrocks: and still went in...
<didrocks> zsombi: it WAS in
<bzoltan> didrocks: I have flagged out the problem with that MP before 25.02 and before that mail...
<zsombi> and you say that landing caused image not to be green?
<didrocks> bzoltan: ?
<didrocks> 2014-02-25 08:44:47     bzoltan didrocks: In the Self service CI (CI train) I watched the line nro 38 with some surprise. Does robru know that the UITK
<didrocks>  releasing belong to me and my team? He was about to release an MR what was not even approved yet.
<didrocks> bzoltan: ?
<didrocks> I hope you don't infer I'm changing the dates on my logs?
<didrocks> oh, let's take public logs even
<bzoltan> didrocks: the sheet did not say that it was landed ... the mail did not say it was landed.
<didrocks> if you don't trust me
<didrocks> bzoltan: it said it was migating to destination
<didrocks> so in the proposed pocket
<bzoltan> didrocks: I do trust you... I wish to understand where from I should have known that it was landed?
 * didrocks looses time for prooving bzoltan that he spoke on the 25
<didrocks> no no
<didrocks> seems you don't agree
<didrocks> so, let's get public logs
<zsombi> didrocks: m,an, I branched the trunk yesterday, and the FIX wasn't there... how come it landed on 25th then?
<didrocks> zsombi: you should learn how ubuntu is workingâ¦
<bzoltan> didrocks: dude, I remember I talked to you... I just wonder why my words were ignored.
<didrocks> bzoltan: they were not
<didrocks> man
<didrocks> bzoltan: http://irclogs.ubuntu.com/2014/02/25/%23ubuntu-ci-eng.html#t07:44
<didrocks> so do you still say "09:31:37  bzoltan | didrocks: I have flagged out the problem with that MP before 25.02 and before that mail..."?
<didrocks> or do you infer I cheated on the public logs as well?
<didrocks> I don't have access to irclogs.ubuntu.com if you ask me
<bzoltan> didrocks: I still do not get how something can land when the Silo tests are not done. My only problem is that I see the CI Train sheet and I see the IRC ... and it seems that an MR just landed on a shortcut without giving me any visibility
<didrocks> bzoltan: you don't answer the questionâ¦
<didrocks> when did you flag it BEFORE the 25?
<bzoltan> didrocks: I meant that line what you just linked
<dbarth_> asac: (about your questions yesterday evening): 001 is CSS files and removing some private APIs for HTML5 apps; very self-contained if you want to land/purge the silo
<didrocks> bzoltan: ok, so, it was the 25
<didrocks> not before the 25
<sil2100> Back
<didrocks> so now, let's get back in time
<didrocks> and rehash again
<didrocks> as it seems you don't know what a pocket is and don't read the phone mailing list
<didrocks> in the european night, between the 24 and 25
<didrocks> robert did land that MP
<didrocks> without flipping the testing done to yes
<didrocks> then, it was in the proposed pocket
<bzoltan> didrocks: I read the mails and yes I have no idea what the pocket is... I take that an MP is not landed before the Silo sheet has green cell on the testing line.
<didrocks> "migrating to destination"
<didrocks> in the spreadsheet
<didrocks> once it's in proposed, it's in ubuntu
<didrocks> it's too late
<didrocks> the package was blocked in proposed due to beta freeze
<didrocks> (not just for a couple of hours, but a day)
<didrocks> then, you raised it to me
<didrocks> asac and I sent an email to robert
<didrocks> and he apologized and thought renato was on the sdk team
<didrocks> testing was done by him and nicholas
<didrocks> I reported that the component was blocked in proposed in my 25.02.14 email
<didrocks> then, it was unblocked from proposed and so migrated to the release pocket
<didrocks> and lands into an image
<didrocks> what I reported on the 26.02.14 email
<didrocks> so again, nothing was pushed/changed since you raised it
<seb128> s!
<didrocks> as I'm explaining it to you for the past 35 minutesâ¦
<bzoltan> didrocks: I admit I did not pay attention to "migrating to destination" because I thought that if an MP line has no testing plan and not asked by the lander and the tests are not flipped inthe Silo  ... then it does not land.
<didrocks> bzoltan: not if you force the publication
<didrocks> bzoltan: people has to push "publish"
<didrocks> then, if they do not follow rulesâ¦
<didrocks> so that was part of that email we sent as well
<didrocks> all clear now?
<bzoltan> didrocks: from the mail I understood that the SDK part is "stucked" due to the freez ... and I was happy to see that, because the MP was bogus anyway
<didrocks> bzoltan: stuck in proposed
<didrocks> but it means, already in distro
<bzoltan> didrocks: I do not know what is "proposed" sorry for that
<didrocks> bzoltan: yeah, you should learn after working on ubuntu for months now how the distro is working
<bzoltan> didrocks: That is true... I should
<bzoltan> didrocks: sorry, by watching the sheet and reading the mails I was under the impression that this MR is not landed yet.
<didrocks> bzoltan: they had "migrating to destination" is when things are moving to distro
<bzoltan> didrocks: I do admit that I am not fully at home with the distro lingo
<didrocks> that's what I didn't use the pocket name in that "migration" sentence
<didrocks> so the sheet was telling it was already published (just didn't hit the final destination)
<bzoltan> didrocks: "migrating to destination" I ignored because I could not imagine something landing on the distro without tests and without the lander
<didrocks> bzoltan: well, as told, other people can land your work, that's why you have a wiki page
<didrocks> but that should be in coordination with the primary landers
<didrocks> and the landing team shouldn't take that decision apart from extreme cases
<didrocks> and testing was done
<didrocks> the switch wasn't flipped
<didrocks> (4th timeâ¦)
<bzoltan> didrocks: I am not that stupid :)
<bzoltan> didrocks: sorry if you think I waste your time...
<didrocks> why are you repeating the same sentence over and over then?
<didrocks> bzoltan: well, you can help getting us back to green now
<didrocks> bzoltan: remember that qmlscene crash that was dismissed because rare 4 weeks ago (crash in v8 engine)?
<bzoltan> didrocks: what can I do for you?
<didrocks> seems (as you probably saw on the phone mailing list), that it's all over the place now
<bzoltan> didrocks: yes
<didrocks> I'm afraid of adding on top of the android 4.4 migration the Qt 5.2 ones
<didrocks> so I guess we should really invest in a wokaround at least
<didrocks> workaround*
<didrocks> so any help to get that one down will be really a tremendous gain
 * didrocks adds this example on his "I told you to not ignore it, it will strike us back" bag :)
<didrocks> (bzoltan: last word on the sdk landing, I archived it in case you are looking for it as everything landed, it's in the archive tab, same spreadsheet)
<bzoltan> didrocks: OK, I will see what can I do with that qmlscene... thanks for explaining the whole story of the mess ...
<didrocks> bzoltan: no worry, just trust me for next time that I don't try to do anything on your back. If I told you I dealt with it, it's really that I dealt with it :)
<bzoltan> didrocks:  you I do trust ...
<didrocks> and if you see a landing you didn't expect, just poke me, not sure we need to "escalate" or whatever before gathering further infos
<didrocks> bzoltan: to come back on this qmlscene crash (in the V8 engine), I only see the multithreading/scheduler changing in android 4.4 getting us into that situation way moreâ¦
* psivaa-afk changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: psivaa | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Landing instructions: http://goo.gl/8H1Du3 | Known Issues: -
<didrocks> popey: where are you? we miss you! :)
<popey> sil2100: yeah, invite me if you have a hangout pls
<sil2100> popey: hi! psivaa will just send me the test-executing script from the dashboard for now
<popey> sil2100: ok
<tvoss> sil2100, hey there :)
<Mirv> didrocks: oh, one thing I forgot - the idea was to do direct syncs from Debian for the majority of Qt modules - this clashes with the PPA preparation idea..
<seb128> sil2100, is l22 not getting a silo due to the freeze? (indicator-datetime bugfixes, for issues that impacts mostly the desktop though)
<Mirv> didrocks: the list is at https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AjuCdq68GSyVdFI4QzNQdWpfME5aMEV2VXo0cUpOMkE#gid=19
<Mirv> didrocks: the alternative is not to do so but use ubuntu1 for everything like I've done in the current PPA already
<Laney> you can sync to PPAs
<Mirv> Laney: \o/
<seb128> Mirv, please don't do that, what Laney said
<Laney> lp:ubuntu-archive-tools copy-package
<didrocks> Mirv: yeah, if it's ready already from debian side, please do that :)
<Mirv> excellent
<didrocks> Mirv: is it already in?
<Mirv> thank you, thank you
<Mirv> didrocks: yes, I checked today that everything we need was put to Debian experimental during my vacation
<didrocks> excellent
<didrocks> so yeah, start the sync :)
<didrocks> tell me if you need any help with copy-package
<Laney> is the no landing rule still on?
<didrocks> Laney: for stuff in touch? yep
<didrocks> Laney: see the ML ;)
<Laney> it's too hard to keep track
<Mirv> yeah, so I upload qtbase and then four syncs, one upload, sync, two uploads, 10 syncs.. something around that
<Laney> because the status updates are just in random emails
<didrocks> Laney: random emails?
<Laney> can you put it in a /topic somewhere?
<didrocks> Laney: all my emails start with it?
<Laney> "Landing team xx.yy.zz" is pretty random to me
<seb128> didrocks, is l22 blocked by your freeze?
<didrocks> Laney: date of the day
<didrocks> seb128: desktop bug reports, I would say no
<seb128> good
<seb128> thanks
 * seb128 waits for sil2100 to be around
<didrocks> Laney: read at least the first 3 lines, I've been careful to state it as the beginning of each email
<didrocks> "Not a lot to add compared to this morning status email, we still hold the line on touch landings which are not targeting fixing the current image issues. "
<didrocks> " Some desktop only update are still flowing in through CI Train, however, we are still blocked by not being able to get one image promotable."
<Laney> 'we are still blocked' is the key there?
<sil2100> seb128: I can assign it ;)
<seb128> didrocks, I think his point is that having to catch emails is not as convenient as a dashboard/topic
<seb128> sil2100, thanks
<sil2100> seb128: when I saw it I was thinking 'uhh, ok, desktop only but still - indicators'
<didrocks> Laney: yeah
<didrocks> seb128: well, we need a web ui for the landing
<didrocks> stating that
<didrocks> but we need to have the CI work on it
<Laney> /topic in here or touch would be ok for me
<seb128> right
<didrocks> I don't have /topic rights here I think
<Laney> here isn't locked
<Laney> touch is, don't know why
<Laney> not any more!
* didrocks changed the topic of #ubuntu-ci-eng to: "Ubuntu CI Engineering Team | Vanguard: psivaa | CITrain support - US: robru,
<didrocks> hum
<sil2100> !
<Laney> haha
<sil2100> Ooooo
<sil2100> Didier broke the topic!
<sil2100> RUN FOR YOUR LIVES
* didrocks changed the topic of #ubuntu-ci-eng to: "Ubuntu CI Engineering Team | Vanguard: psivaa | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Landing instructions: http://goo.gl/8H1Du3. Landing frozen for Touch until we get one promotable image | Known Issues: -"
<sil2100> Oh, it's back again
<sil2100> Nevermind
<seb128> no fun :p
<sil2100> ;)
<davmor2> didrocks: so it looks like unity8 is locking up randomly, also shutting down bluetooth from the indicator kills the phone reboot into unity8 which I though was a qt5.2.1 issue but it seems not.  There is a bug assinged to qt5.2.1 for the bluetooth issue and the random lock ups is being worked on already I think
<davmor2> didrocks: other than that 210 seems okay
<davmor2> didrocks: I'm assuming that the unity8 random locks ups won't help the autopilot tests either so if you get some that fail on ci but pass on rerun/local that might be a cause
<didrocks> davmor2: do you have a bug for the random locks up (which happens even with qt 5.2.1), and who is working on it?
<didrocks> om26er: psivaa: any news on the screen unlock? :)
<davmor2> didrocks: no this isn't on qt5.2.1 this is on standard, I didn't see the lock up on qt5.2.1.  But I'm assuming it would effect 5.2.1 I just didn't hit it.  Let me dig into it I'm sure I have heard talk of it though
<psivaa> didrocks: just saw om26er :)
<davmor2> didrocks: https://bugs.launchpad.net/bugs/1277206 this is the bluetooth bug
<ubot5> Ubuntu bug 1277206 in unity8 (Ubuntu) "QT5.2: Disabling bluetooth crashes unity8" [Undecided,Confirmed]
<ogra> davmor2, does it only crach the UI or the phone as a whole ?
<davmor2> ogra: it only seems to relaunch unity8
<ogra> phew, fine then :)
<davmor2> ogra, didrocks: it looks like it only happens on a first run after a fresh flash too
<davmor2> I couldn't reproduce after re-enabling bluetooth
<ogra> hmm, interesting
<davmor2> I'm going to reflash it so I have a clean slate and see what info I can get about it
<didrocks> davmor2: ok, so maybe your lock up is linked to the crash we have :)
<didrocks> phew
 * didrocks was afraid of another issue
<davmor2> didrocks: could be
<ogra> well, might be intersting to see if an extra reboot in the test runs would fix it
<ogra> probably something in the session isnt completely set up on first boot that causes this
<ogra> i assume we immediately start testing without any additional reboot
<davmor2> didrocks: so on initial start up there is a crash for _usr_lib_arm_linux_gnueabihf_upstart-app-launch_desktop-hook.32011.crash  I'm guessing that isn't the start you want.  However I've cleared that off as I want a nice clean slate for the bluetooth killer
<davmor2> didrocks: I'm assuming it might be the start guide
<didrocks> davmor2: can you retrace that one?
<davmor2> didrocks: no I killed it but I can reflash in a minute and do it then
<didrocks> davmor2: that would be awesome!
<psivaa> ogra: on flo the screen unlocking for ubuntu-system_settings had failed on my rerun as well. so kicked it again.
<ogra> thanks
<psivaa> the frequency of screen unlock issues appears to be more on flo
 * sil2100 fights his phone
<didrocks> psivaa: so, the plan is om26er to add more debug infos and running it? (or give the utah script so that he can reproduce?)
<psivaa> didrocks: still waiting to hear from om26er. just received an email from him saying starting late today
<didrocks> ok
<ogra> psivaa, flo is faster and more responsive than mako
<ogra> i actually assume that many of these issues we see are because android 4.4 is also significantly more responsive than 4.2 was
<ogra> so timing critical things that didnt race before might now ...
<psivaa> ogra: yea that would make sense.
<ogra> so indirectly didrocks is right in blaming android 4.4 ... but after all it only exposes breakage in our tests that didnt show up due to slowness before
<didrocks> ogra: yeah, see why we shouldn't never give up on races :)
<ogra> it would help if we could ask unity8 if the screen is actually unlocked and get a proper response for this
<didrocks> right
<davmor2> didrocks: is there a wiki page/documentation on how to get a good traceback my google-fu seems to be off this morning
<ogra> "Debugging" on the ubuntu wiki ?
<didrocks> davmor2: https://wiki.ubuntu.com/DebuggingProgramCrash
<ogra> iirc thats the top level page
<ogra> yeah
<davmor2> didrocks: cheers
<didrocks> davmor2: for using gdb itself, maybe pair with sil2100?
<didrocks> that will be way faster :)
<didrocks> sil2100: mind helping davmor2 to retrace a crash?
<sil2100> What's up?
 * sil2100 reads up
<davmor2> sil2100: I get this on a fresh flash _usr_lib_arm-linux-gnueabihf_upstart-app-launch_desktop-hook.32011.crash
<ogra> isnt that just a script ?
<davmor2> didrocks: looks like the bluetooth issue might be a race issue.  I'm assuming to do with what needs to be displayed and removing the indicator from the top bar.
<ogra> you should be able to read it with an editor
<didrocks> ok ;)
<didrocks> psivaa: do you think ogra should try the unlock screen script? I don't have flo, tried unlocking 10 times the screen for mako without success
<didrocks> in case:
<didrocks> http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/files/head:/utils/target/
<didrocks> download unlock_*
<didrocks> chmod +x both
<didrocks> and run the .sh as root
<psivaa> didrocks: I think the freq is high in flo. so it would help
* cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Landing instructions: http://goo.gl/8H1Du3. Landing frozen for Touch until we get one promotable image | Known Issues: -
<rsalveti> morning
<ogra> hey hey
<rsalveti> ogra: so in the end the crash has nothing to do with 4.4.2
<rsalveti> good and bad news
<ogra> well, it seems to expose some races due to 4.4 being more snappy i think
<rsalveti> good is that this is not happening with qt 5.2, bad is that we got another crash there
<rsalveti> ogra: yeah, I believe so
 * ogra curses his maguro 
<ogra> it endlessly reboots ...
<rsalveti> was able to get the crash with manta quite frequently as well, with 4.2.2
<ogra> with the popping sound during the boot process
<rsalveti> might be because manta is really fast anyway
<ogra> yeah
<ogra> ARGH !!!!
<ogra> MAGURO !!!!
 * ogra gives up after watching the device doing its 10th reboot in a row ... and re-flashes losing 2h of work 
<ogra> damned
<ogra> i cant even get it into recovery now
<ogra> just reboots as soon as it loads the kernel it seems
<rsalveti> yeah, might be that old sound related kernel crash when booting
<asac> Mirv: didrocks: hangout crashed
<asac> lets continue after the meeting
<didrocks> asac: which meeting?
<asac> 5.2 ... dont worry :)
<asac> there is a daily standup now
<didrocks> should I get there as it's linked to the hot topic?
<asac> didrocks: dont think you can do much there
<asac> didrocks: unless you have time to fix bugs
<didrocks> asac: ok, so the decision won't be taken into that meeting?
<didrocks> about what we are doing?
<asac> didrocks: the decision was already be done
<asac> didrocks: its about tracking and driving the bugs down
<didrocks> asac: yeah, but about the current image state and when we throw it in
<asac> didrocks: do you want to propose to throw it in today?
<asac> if so you should join
<didrocks> asac: not today, but maybe tomorrow, once the base qt + first rebuild of some components are done
<didrocks> if we go that road
<asac> didrocks: yeah, then join tomorrow
<didrocks> ok
<didrocks> let's do that
<asac> today i want to see what people think about breaking apps :P
<asac> but i might even take that offline
<didrocks> ok
<asac> didrocks: if you say we should flush the toilet tomorrow i will try to talk to rick today
<didrocks> asac: yeah, tomorrow (or monday depending on how we are in the build progress) at the latest I guess
<didrocks> asac: in that case, I'm going for a run now :)
<asac> didrocks: yeah do that.
<om26er> psivaa, didrocks hey
<om26er> I am up now, might need to wash my face
<sil2100> Phew
<sil2100> An I might have my device working again
<psivaa> om26er: this is about any updates on screen_unlock failures. saw that today as well about 4 times in mako and 6 times on flo in about 20 times each
<om26er> psivaa, yes so the issue was with unity8 not starting due to some reasons, I reported a bug for that
<psivaa> om26er: do you have that bug handy?
<om26er> psivaa, bug 1285215
<ubot5> bug 1285215 in mir (Ubuntu) "Unity fails to start sometimes in CI resulting in screen unlock failure [what(): bind: Address already in use]" [Medium,Triaged] https://launchpad.net/bugs/1285215
<sergiusens> sil2100, hey, can you rerun l23?
<sil2100> sergiusens: sure
<sil2100> hm, actually you can re-run it yourself, right? ;)
<sil2100> Or maybe you want me to reconfigure?
<sergiusens> sil2100, reconfigure
<sergiusens> :-)
<sil2100> sergiusens: done!
<sergiusens> sil2100, ppa still has the packages, is that expected?
 * sergiusens keeps forgetting
<bfiller> asac, sil2100: silo 2 ready to be released (line 18 on sheet). tested and ready to go
<asac> bfiller: tested == all green?
<asac> bfiller: is this a regrssion fix or the ones we discussed yesterday?
<bfiller> asac: the tests all pass on my device
<bfiller> asac: these are other ones that were pending, not regression fixes
<davmor2> didrocks: I've come to the conclusion that apport hates me and this crash hates me more, Apparently the word Core doesn't exist in the crash file so apport does nothing with it grrrrr  I have forwarded a copy to sil2100 as requested I'll let him bang his head against it while I carry on for a bit :)
<asac> bfiller: ok. give us some time. we are talking about the qmlscene crash and how to best handle things until 5.2 is landing
<bfiller> asac: ok
<asac> if i could send mails that would help :)
<om26er> cjohnston, hey! do you review cupstream2distro-config changes ?
<om26er> I have this one https://code.launchpad.net/~om26er/cupstream2distro-config/uss_disable_otto/+merge/208619
<cjohnston> fginther: please ^
<fginther> om26er, cjohnston approved
<om26er> fginther, cool, francis is there :)
<fginther> om26er, will deploy when it merges
<sil2100> davmor2, didrocks: there's not much to retrace there ;)
<davmor2> sil2100: fsckin thing
<ogra> didrocks, om26er, so one thing that strikes me ... did you ever notice that after a fresh boot the greeter sometimes needs multiple attempts to actually unlock ? it only slides by a few pixels and snaps back, i wonder if the unlock script simply experiences the sam here
<ogra> *same
<didrocks> ogra: yeah, I got that bug, but since saucy
<ogra> right
<didrocks> so maybe this is what happens
<ogra> but probably it got worse now
<om26er> ogra, didrocks I have seen the problem happen on my phone, Unity8 never started to begin with
<ogra> i wonder what would happen if we let the whell script simply repeat the unlock attempt ... say 3 times instead of one
<om26er> ogra, it already tries twice
 * ogra doesnt have issues with unity starting on his devices ... weird
<ogra> it can take long on first boot after a fresh flash, but it usually comes up after a while
<ogra> (because of the apparmor-click registration)
<didrocks> ogra: did you get anything on your flo?
<ogra> like what ?
<didrocks> ah, you didn't see my pings
<didrocks> or I didn't see your answers :)
<didrocks> one sec
<ogra> didrocks, oh, sorry, i was in the garden for 1h ... had to chop two trees
 * ogra is still dizzy ... so much sport 
<didrocks> ogra: ahah, interesting "break" :)
<ogra> yeah, the allowed time to chop them ends on sat ... so i have to do it today and tomorrow
<didrocks> waow, so strict rules :)
<ogra> (bird nesting time etc)
<didrocks> ah found it:
<ogra> yeah
<didrocks> didrocks | http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/files/head:/utils/target/
<didrocks> didrocks | download unlock_*
<didrocks> didrocks | chmod +x both
<didrocks> didrocks | and run the .sh as root
<didrocks> this is to test unlock
<ogra> yeah
<ogra> i got that open
<didrocks> ok ;)
<didrocks> I couldn't get it after 10 runs on mako
<ogra> but that need AP installed, no ?
<didrocks> but it's already installed on the image!
<didrocks> remember :)
<ogra> didrocks, properly unlocked
<didrocks> ogra: I think do that in loop if possible
<ogra> and repeatable
<didrocks> if you can't reproduce either that won't be fun :/
<ogra> for i in $(seq 1 10); do ./unlock_screen.sh; done
 * ogra twiddles thumbs 
<didrocks> ogra: shouldn't you relock it in between? :p
<ogra> didrocks, it restarts unity
<ogra> so it comes up locked every time
<didrocks> and shutting down the screen?
<ogra> didrocks, hmm
<ogra> you mean via powerd ?
<didrocks> yep
<didrocks> just trying to think what happens in the CI system when we start it
<didrocks> I guess the screen is off
<ogra> i guess it just booted and the screen is still on
<ogra> but yeah, i can try
<didrocks> ogra: it booted, but then, we have system settle
<ogra> the ten runs seem to work fine though
<didrocks> so it's waiting a lot
<ogra> it was off when since 2h i ran the first (single) iteration
<ogra> that worked fine
<didrocks> ok, if you can try hammer with screen off in between
<didrocks> "just in case" :p
<didrocks> (not sure where the Tm is on this layout)
<ogra> hmm
<ogra> powerd-cli display off doesnt seem to exist
<ogra> despite the help talking about it
<ogra> oh
<ogra> "powerd-cli display on" actually switches it off
<ogra> ah, only after i ctrl-c out of the blocking
<didrocks> oh? :/
 * ogra has a meeting now ... i'll let it sit and time out during the meeting 
<didrocks> yeah ;)
<ogra> and also try after a fresh boot
<didrocks> it's another plan
<didrocks> sil2100: any luck on the terminal?
<Saviq> didrocks, yes
<sil2100> didrocks: not really ;< I even re-prepared my phone to make sure I'm using the right versions and nothing, not even one failure... I tried using the scripts from smoketesting for running the tests and the result (along with the unlock_* bits even) is the same. But I have a slightly re-written version of the test now which I think might give us some additional clues
<didrocks> sil2100: did you try to bring eliopo to this? He's awesome at finding those kind of issues
<didrocks> sil2100: like, don't block for 3 days on it
<didrocks> sil2100: or just get published your information with more debugs
<ogra> didrocks, so it doesnt really matter if the initial unlock after a boot doesnt work, since we restart unity afresh
<didrocks> ok
<ogra> and there the unlock seems to be just fine
 * ogra just rean the same sequence with adb reboot added between the unlocks ... no issues 
<ogra> and also leaving it sitting doesnt change it
<sil2100> didrocks: our all data is on the bug, but we'll also include eliopo in the loop
<sil2100> *into
 * sil2100 didn't know we had such a convinient person ;)
* doanac` changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: doanac | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Landing instructions: http://goo.gl/8H1Du3. Landing frozen for Touch until we get one promotable image | Known Issues: -
* doanac` changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: doanac | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Landing instructions: http://goo.gl/8H1Du3. Landing frozen for Touch until we get one promotable image | Known Issues: -
<didrocks> ogra: ok :(
<ogra> so now i left it for 10min ... still fine
<ogra> (and i'm now actually running "adb shell ./unlock_screen.sh" to be as close to the UTAH setup as i can here)
<ogra> hmm
<ogra> what i notice is that the touchscreen is dead after running the unlock
<ogra> i cant actually tap on anything or interact with the UI
<ogra> (though i guess thats because all input is redirected to AP)
<seb128> sil2100, can I get a slot for l25 (indicator-keyboard fixes, desktop only)
<sil2100> seb128: sure, doing
<seb128> sil2100, thanks
<sil2100> seb128: assigned
<sil2100> np :)
<seb128> thanks
<sil2100> balloons: commented on your MP
<balloons> sil2100, I responded :-) We have a couple ways of dealing with OSK. And yes, I had to stop myself from changing the test around completely, heh. Just need to get it to work, then we can tweak it
<sil2100> balloons: disabling OSK would be awesome ;) Can we do that somehow in AP itself?
<sil2100> Like, for instance, just for this test?
<balloons> sil2100, yes, if we disabled it, I would push only for this test
<balloons> and yes we can
<bfiller> sil2100: the osk is disabled in all the address-book-app tests I believe
<sil2100> \o/
<bfiller> (which I don't think it should be, but it is)
<bfiller> so you can find an example there
<bfiller> just have to stop maliit-server
<balloons> sil2100, likely if we simply tap in the top 1/6 of the screen we'll never hit the osk
<sil2100> balloons: right, that's actually what I was experimenting with locally - the problem is that I though of that being a bit hacky
<balloons> we actually have an open bug for the core apps to remove all the osk disabling as we can; it's not ideal to do that
<sil2100> didrocks: meeting!
<cjwatson> pmcgowan: would you or somebody on your team be available to attend https://blueprints.launchpad.net/ubuntu/+spec/core-1403-qt5-versioning as a UDS session?
<pmcgowan> cjwatson, yes, in fact I could attend
<cjwatson> cool
<balloons> sil2100, yes, I'll try tapping the top of the screen for now
<sil2100> balloons: thanks! I commented on the bug the way I did it ;)
<sil2100> balloons: but it was hacky - I'm sure you'll find a better way
<balloons> sil2100, I actually pushed the new version.. it uses globalrect property of the page
<balloons> I tweaked the assert as well. It should fail better now
<sil2100> balloons: globalRect, hah! With this it looks much better ;) My AP knowledge got a bit old it seems
<sil2100> Let me do a quick spin of your latest branch and let's get it landed!
<kgunn> didrocks: ...we suddenly have ci faililng....
<kgunn> https://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/1066/console
<kgunn> but we noticed nothing changed on our dev branch
<didrocks> kgunn: I guess this is a question for doanac` (the CI team)
<didrocks> ah
<kgunn> alan_g: do you happen to know when the last passing CI was on an MP up for review ?
 * alan_g goes to look...
 * doanac` looks
<didrocks> kgunn: diffing the installed package would help to know what changed
<didrocks> doanac`: you do have that on your artefacts?
<alan_g> kgunn: 	Failing since 27-Feb-2014 16:16:06 was working at 11:44:53
<doanac`> looks like a legitimate issue in log.h
<balloons> sil2100, I put the device under load and it seems to hold up fine.. I'm happy with it
<sil2100> Yep, me too - approving
<robru-sick> didrocks, sil2100: anything you guys want me to hit publish on?
 * sil2100 cannot top approve
<balloons> sil2100, no worries, I did it
<didrocks> robru-sick: I think there is nothing to publish until tomorrow midday (apart desktop-only feature)
<kgunn> doanac`: can you share what changed there ? per  Failing since 27-Feb-2014 16:16:06 was working at 11:44:53
<kgunn> i have to step away for a bit
<robru-sick> didrocks, oh ok. I thought you said we would publish some and then build images, didn't catch that you were talking about tomorrow
<doanac`> kgunn: i'll take a look
<didrocks> robru-sick: once we get an image with only the crash
<didrocks> robru-sick: my email will try to clarify that out :)
<robru-sick> didrocks, ok, thanks
<didrocks> robru-sick: you can assign silos though (but testing should only start tomorrow)
<didrocks> kgunn: oh, before you leave
<didrocks> kgunn: the screen unlock issue seems to be a Mir issue
<didrocks> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1285215
<ubot5> Ubuntu bug 1285215 in mir (Ubuntu) "Unity fails to start sometimes in CI resulting in screen unlock failure [what(): bind: Address already in use]" [Medium,Triaged]
<didrocks> (I'll mention it in the landing email)
<sil2100> didrocks: so, the terminal workaround fix is ouuun \o/ With the modifications done, we should have it in soon
<didrocks> sweeeeeet
<sil2100> Lets now just hope that it really works around that strange path causing the failure
<doanac`> kgunn: looks like libglm has been updated from 0.9.4.6-2 to 0.9.5.1-1 and there's a new compile error as a result
<doanac`> look for: /mir/partial-armhf-chroot/usr/include/glm/detail/type_vec3.inl:86:33 in https://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/1065/consoleFull
<elopio> ping cihelp, can somebody give me permissions to rebuild the autopilot release job in http://q-jenkins:8080 ?
<cjohnston> elopio: please use the vanguard
<elopio> ah, sorry, I always do it wrong
<elopio> ping doanac` ^
<doanac`> elopio: looking
<asac> cjohnston: yeah, was my wrong guidance :)
<asac> (on ci help)
<asac> hope that didnt highlight :)
<cjohnston> :-)
<elopio> actually, on my last three pings the vanguard was c-i-h-e-l-p. This time, I just assumed it would be it too.
<elopio> from now on, I'll just start pinging the wrong word just to annoy cjohnston :)
<doanac`> elopio: i'm checking to make sure i can grant this for you.
<elopio> thanks doanac`
* plars changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: plars | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Landing instructions: http://goo.gl/8H1Du3. Landing frozen for Touch until we get one promotable image | Known Issues: -
<didrocks> cyphermox: robru-sick: sil2100: FYI, commented on line #17. I think it's the kind of landing we are going to wait post Qt 5.2
<didrocks> Saviq: FYI ^
<jdstrand> I popped into the meeting earlier today, but I couldn't stay for long. I just wanted to point out an unfortunate consequence of the blocked landings recently
<robru-sick> jdstrand, oh?
<Saviq> didrocks, you mean the switch to py3?
<jdstrand> right before all this, the click update manager was dropped so that we could use system settings
<Saviq> didrocks, let xnox know
<didrocks> xnox: ^
<jdstrand> but the system settings functionality wasn't there
<jdstrand> so the change was reverted
<jdstrand> that's all fine
<jdstrand> the problem is, the click update manager change made it to a promoted image, but the reversion never did
<xnox> didrocks: hm?
<didrocks> xnox: I would appreciate, as we have to land Qt 5.2 now, that we decouple the python3 switch for AP once we can repromote an image
<didrocks> sorry for the delay, but sounds the safest for now
<xnox> didrocks: re:python3 planning, in the light of the new planning. The proper way to decouple switch to python3 is to block landing phablet-tools update.
<didrocks> (we are resuming some degraded mode for landing, see my email I just posted on ubuntu phone)
<xnox> didrocks: but keep python3 unity8 and ubuntu-ui-toolkit.
<didrocks> xnox: hum, nothing will activate it, you mean?
<xnox> didrocks: this way, all tests will be executed with python2.
<jdstrand> it isn't a *major* issue. perhaps we can just chalk it up to bad timing, but for dogfooders we haven't gotten app updates in a while. I'm not sure how to fix the process, but it would be nice if that revert had made it in to a prompted image before the churn happened
<didrocks> xnox: sounds legit to me
<xnox> didrocks: but myself and barry will be unblocked testing all clicks and apps under python3, locally, with changed phablet-tools.
<didrocks> xnox: there is no landing slot/demand for phablet-tools yet, right?
<jdstrand> anyhoo, I don't need any attention, I just wanted to bring up the point
<xnox> didrocks: the branch you want to deconfigure is the phablet-tools py32 from me, and one that depends on it.
<xnox> didrocks: or just kick phablet-tools out of it's landing slot / silo.
<didrocks> jdstrand: yeah, we know about it, we even tried to resurect image #202
<didrocks> jdstrand: we have some mitigation plan, look at the phone ML
<xnox> didrocks: sergiousens is not online thought to confirm.
<xnox> didrocks: it's tainted anyway, since it has my py32ap branch and another one which depends on it.
<didrocks> jdstrand: the plan was that the revert was before android 4.4
<didrocks> jdstrand: but the CI infra had issues (see my email on Monday)
<didrocks> xnox: line 16?
<xnox> didrocks: blacklist: https://code.launchpad.net/~xnox/phablet-tools/py2-3/+merge/205608.
<xnox> didrocks: let me check the spreadsheet.
<didrocks> xnox: hum
<didrocks> https://code.launchpad.net/~doanac/phablet-tools/ptr-support-subunit
<didrocks> contains your change
<xnox> didrocks: yeah, line 16 kick-out, there are branches that depend on mine, and shouldn't land.
<xnox> didrocks: they need rebase / restructuring, if they want to land without my changes.
<didrocks> xnox: ok, just added a comment for now, I'll let you and sergio talk
<didrocks> removed the comment on the other one
<xnox> didrocks: but do keep line 17 as is.
<didrocks> yep :)
<xnox> didrocks: and ditto ubuntu-ui-toolkit, which i believe was ready to land as well. the py32ap branch.
<didrocks> xnox: yeah, as long as your change isn't active, I'm good :)
<xnox> didrocks: are we out of landing slots, or is ubuntu-ui-toolkit not planned yet?
<didrocks> xnox: we will start resume landing tomorrow
<didrocks> once the remaining issues (apart from the crash and unlock screen) are fixed on the image
<xnox> bzoltan: ping, about reviewing https://code.launchpad.net/~xnox/ubuntu-ui-toolkit/py32ap/+merge/207757 did you get a chance to look into it?
<didrocks> so tomorrow, they should have a slot
<xnox> didrocks: ack.
<xnox> bzoltan: hoping for https://code.launchpad.net/~xnox/ubuntu-ui-toolkit/py32ap/+merge/207757 to land with a next ubuntu-ui-toolkit landing.
<seb128> didrocks, so, if indicator-datetime has 2 bugfixes pending, 1 for desktop and 1 for touch, can I land both, or should I let touch fixes out?
<didrocks> seb128: today -> out. Tomorrow after next image -> in
<bzoltan> xnox:  what is the "need fixing" from Barry Warsaw ?
<seb128> didrocks, ok, let me do 2 landings then, thanks
<didrocks> yw ;)
<bzoltan> didrocks: did I read right? We have a chance to land our MRs tomorrow? That would be fantastic.
<didrocks> bzoltan: yeah
<didrocks> bzoltan: we'll need to be extra careful though
<bzoltan> didrocks: of course
<didrocks> bzoltan: see the "Special landing mode process" email
<bzoltan> didrocks:  it is open in front of me
<didrocks> :)
<xnox> bzoltan: see comment below it, i've addressed the issue he raised.
<bzoltan> xnox: OK
<didrocks> ogra: pffff, only one sharing
<didrocks> you missed one! :)
<ogra> oh ?
<ogra> still reading marks interview
<didrocks> You can't multi-task :)
<om26er> fginther, can you tell whats wrong here https://jenkins.qa.ubuntu.com/job/ubuntu-system-settings-ci/664/ seems all the child jobs passed but still its not succeeding
<ogra> there
<ogra> :P
<didrocks> ogra: ah, finally! :)
 * didrocks hugs ogra
 * ogra hugs didrocks 
<fginther> om26er, the job is trying to pull test results from the generic-mediumtests-trusty job that was removed. I'll do a fix
<om26er> fginther, thanks
<fginther> om26er, I'm updating the job, but it will have to wait for the current one to finish running
<om26er> fginther, sure
<balloons> terminal fix is in the store, one down, 2 to go :-)
<sil2100> Wooshaaa
<fginther> om26er, updated, I've retriggered the last two jobs that failed
<sil2100> balloons: awesome, thanks :)!
<om26er> fginther, we can also re-enable otto for it once the upstart override is added
<fginther> om26er, right, I'm still testing that
<bzoltan> xnox: I am running the standard tests on your MR, Kaleo is fine with it, i am fine with it... once my teste give green I will add to the MP in the CI sheet
<xnox> bzoltan: thanks.
<robru-sick> seb128, your desktop=only landing got silo 13, please build
<seb128> robru-sick, thanks
<fginther> om26er, http://s-jenkins.ubuntu-ci:8080/job/autopilot-testrunner-otto-trusty-debug-fjg/60. Tests passed and it still hit the system-image-dbus crash
<fginther> om26er, if the tests look good, I'll work on re-enabling the job
<om26er> fginther, great so the apport window finally didn't ruin the party
<om26er> fginther, looks good to me now
<fginther> om26er, thanks for the fix
<om26er> ;)
<asac> kgunn: is this pre-start you talk about in the test or in MIR itself?
<kgunn> no, in the test...team doesn't agree that mir should be deleting sockets as they might belong (in theory) to another mir instance..
<kgunn> Saviq: ^
<asac> multiple mir instances?
<kgunn> right
<asac> kgunn: curious what the case for having multiple mir instances is... is that for multi-user support?
<kgunn> i'm not done hashing it out w the team, surely there's a way to take care of the case (e.g. determine its stale)
<asac> balloons: anything we can do to help getting your weather and clock fixes done and/or in?
<asac> rsalveti: voice call and camera are on track you believe? are both on you or is one of the ricardo's ricmm?
<rsalveti> asac: working on them right now :-)
<rsalveti> yup
<asac> kgunn: so yeah, i guess lets get pre-start fix into test if you can't find a better way and just ensure we dont forget to drop that bandaid once the real fix arrives
<kgunn> we won't we gotta bug
<asac> ok will wait for update then
<asac> oh thought you said we wont land the pre-start fix :)
<asac> (but you said we wont forget)
<asac> cool
<asac> cyphermox: robru-sick: will you be around later for help kgunn and friends?
<robru-sick> asac, yep, i'm lying in bed but have my laptop and can respond to pings
<robru-sick> asac, for at least 6 more hours
<asac> robru-sick: do you know whats up with the spreadsheet? looks buggy to me
<robru-sick> asac, yeah, just noticed that. I guess just leave it. worst case, I can fiddle the backend directly
<asac> robru-sick: does that look familiar to what we had before (e.g. google bustage?)
<balloons> asac, working with the upstream devs for clock and weather, so ...
<robru-sick> asac, yeah, it's just google spreadsheet limitations, seems it doesn't scale very well.
<asac> robru-sick: but saw something like this and it auto recovered?
<robru-sick> asac, yeah, i saw this before... i dunno if it "auto recovered", but it went away while i was sleeping so probably didrocks fixed it. but it's ok, I can do things manually in the backend to override this brokenness
<asac> robru-sick: good. still would love to see the pending requests etc.
<robru-sick> asac, yeah, people can add requests still, just the status column will only say #ERROR
<robru-sick> asac, oh, actually it looks fine already ;-)
<asac> yay
<asac> perfect
<robru-sick> asac, yeah, just some hiccups from google, i guess they are trying to sabotage us ;-)
<asac> of course they do... always :)
<Saviq> kgunn, duflu himself wrote
<Saviq> kgunn, that they can check if the socket responds, and delete if it's dead
<kgunn> Saviq: mterry and i converged to that very point just now :)
<Saviq> kgunn, k, I can add the removal in unity8's pre-start in the mean time
<kgunn> Saviq: ta
<Saviq> kgunn, fwiw I already had a MP up since November ;) https://code.launchpad.net/~saviq/unity8/drop-stale-socket/+merge/196917
<kgunn> hold out :)
<kgunn> ta
<robru-sick> seb128, i published silo 8 for you since it's desktop only
<seb128> robru-sick, thanks, I would have done it earlier but ppc had some backlog and delayed builds
<robru-sick> seb128, no worries
<veebers> plars: hey, would you know anything about the maguros being offline on "Ashes"?
<plars> veebers: they shouldn't be, let me check. Where are you seeing this?
<veebers> plars: when we're trying torun this job: http://q-jenkins:8080/job/autopilot-release-gatekeeper/
<veebers> specifically maguro-07
<plars> veebers: oh, that's something different, I didn't think it was tied to any maguro
<plars> veebers: ok, it's online now
<veebers> plars: awesome, thanks
* plars changed the topic of #ubuntu-ci-eng to:  Ubuntu CI Engineering Team | Vanguard: cihelp | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Landing instructions: http://goo.gl/8H1Du3. Landing frozen for Touch until we get one promotable image | Known Issues: -
<plars> rsalveti: asac: manta is starting to show up on http://ci.ubuntu.com/smokeng/trusty/touch/ now
<rsalveti> plars: awesome!
<asac> plars: nice!
<asac> almost full house :P
<asac> house full of emulators would be great :)
#ubuntu-ci-eng 2014-02-28
<asac> kgunn: already asked for landing the pre-start thingy?
<Mirv> hi. unfortunately powerpc among else is slowing down things. hopefully after qtdeclarative it'll become smoother, but I expect that a person in US timezone able to land the non-qt packages would be beneficial
<Mirv> didrocks: ^ I already spend last evening occasionally pushing things further, but it would have helped also with Qt if someone during my night could have pushed the buttons
<Mirv> also, it seems armhf builds in Debian are not all done, so I need to upload qttools ubuntu version for its symbols again, after qtdeclarative rebuild finishes
<didrocks> Mirv: if you can add at your end of day some infos, I guess we can have someone doing that
<Mirv> didrocks: yeah, will do
<didrocks> Mirv: ack on qttools
<Mirv> didrocks: in other news, http://pad.ubuntu.com/qt52-dependencies should be now ready - ie it includes (bolded) all the packages that need something else done than re-building trunk or current archive version
<Mirv> I guess for non-CITrain packages a manual upload would be done, and for CI Train packages a merge request
<didrocks> Mirv: can we have a trial without any rebuild on our packages, just the Qt part?
<didrocks> Mirv: like, running all AP tests
<didrocks> (do you think that will be ready soon?)
<didrocks> (on armhf)
<didrocks> I guess that will give some data on management who wants to do how Qt handled minor release, even with this ABI break
<Mirv> didrocks: yes, the combination of the silo and the beta2 PPA should give something to test where the Qt of the silo is used instead. I think after qttools and qtmultimedia are ready quite many tests should use the newer builds
<Mirv> qtwebkit won't be ready by my EOD, but hopefully I get far enough (qt3d, qtsensors, qtlocation) that I can push a build of it
<didrocks> Mirv: ok, keep us posted :)
<didrocks> (nice to have that bar on the pastebin)
<Mirv> didrocks: do you by the way know any way to get the builder output all changed symbols, since it tends to stop after the first symbols file? that's why I've now the second rebuild of qtdeclarative for powerpc symbols
<didrocks> Mirv: you can lower the warning so that it doesn't trigger any error
<didrocks> but that's about it
<Mirv> right
<didrocks> (and it will then need another rebuild)
<Mirv> qtdeclarative finished on powerpc \o/
<Mirv> that's actually the first time ever, since V8 wasn't available for powerpc before 5.2
<didrocks> yeah ;)
* didrocks changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Landing instructions: http://goo.gl/8H1Du3. Landing in degraded mode (see http://goo.gl/J1EqPW) | Known Issues: -
<didrocks> sil2100: hey, how are you?
<sil2100> didrocks: hey! Upgrading my system ;)
<sil2100> How about you?
<didrocks> sil2100: I'm good, thanks (even if it's rainy here)
<didrocks> sil2100: can you prepare an order of safe landings for the meeting that you and Mirv will be able to proceed today? As you are going to test them as well, try maybe to match them in logical chunks?
<sil2100> Ok, on it then
<didrocks> thanks!
<sil2100> Damn, my phone is acting strange
<didrocks> \o/ look at line 23
<sil2100> Wooooo
<sil2100> Didn't know we had that feature!
<didrocks> well, we didn't have it 5 minutes ago :p
<didrocks> ok, let me get that triggered every 5 minutes
<sil2100> You did-*rock* ;)
<didrocks> heh ;)
<didrocks> (there are a lot of checks to ensure we don't overwrite if a job is in progress or rollback or whatever)
<didrocks> and it's checking every silos
<sil2100> Let's just not trigger the spreadsheet breakage again!
<didrocks> heh, I guess it won't make that many changes
<didrocks> grrr, delivery of a 20 kgs pack between 8am and 7pm
<didrocks> and of course, they choose the meeting time
<ogra> === Image 212 Building ===
<sil2100> ;)
<Mirv> I might be able to eat some very random "lunch" now while the phone is flashing
<didrocks> ok, automated migration check done
<didrocks> and deployed
<davmor2> didrocks: okay so looking at 211 it is pretty much on par with 210, I'll carry on testing it but I've not had any crashes yet
<didrocks> davmor2: great! keep us posted :)
<sil2100> bzoltan1: hmm.. one of your merges doesn't seem to exist anymore
<sil2100> bzoltan1: in the list of 13 landings
<sil2100> bzoltan1: https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/tabbar-apfix-unit/+merge/208368 <- the branch is there but no merge request, can you clarify this?
<davmor2> didrocks: well other than the camera app :)  which we know and blame rsalveti for whole heartedly right ;)
<bzoltan1> sil2100: that must be renato's one
<didrocks> davmor2: sure sure ;)
<bzoltan1> sil2100:  ohh that one... sure, a sec
<didrocks> sil2100: ah, ensure renato one (if still listed) is removed btw, it's already listed
<didrocks> landed*
<sil2100> bzoltan1: ah, ok ;)
<sil2100> didrocks: I mean: ah, ok
<didrocks> ;)
<sil2100> bzoltan1: could you also check for renato one? ;)
<didrocks> psivaa: ok, so gallery_app is the v8 crash
<didrocks> psivaa: so, what I have done to quickly check
<didrocks> wget <crashfile>
<didrocks> apport-unpack <crashfile> foo
<didrocks> gdb gallery-app foo/CoreDump
<didrocks> then I'm seeing: #0  0x50b0d8f8 in ?? ()
<didrocks> (on the phone of course)
<psivaa> didrocks: ohh on the phone.
<sil2100> phew
<psivaa> didrocks: thanks for the steps.
<didrocks> psivaa: yeah, I tried on the desktop, but symbols don't match
<didrocks> yw! :)
<didrocks> no need to install any dbgsym, nothing :p
<bzoltan1> sil2100:  that MR was replaced by an other one
<didrocks> just work on /tmp
<bzoltan1> sil2100: renato's legendary MR has landed on the trunk already and so it is not in my MP
<sil2100> bzoltan1: could you remove/replace what's needed in the list? I'll assign a silo then ;)
<bzoltan1> sil2100:  done
<Mirv> sil2100: err, unity-scope-scopes isn't installed by default on the image?
<Mirv> so what exactly needs testing I'm wondering
<didrocks> Mirv: if it's not installed (it's for the new scope API), just get it in
<didrocks> Mirv: the real testing will come when we activate them
<Mirv> thanks, just double checking because of the toll this context switch is having on my brain :)
<didrocks> heh ;)
<didrocks> I'm pretty sure it's not activated anyway
<didrocks> (it's on the mwc image)
<sil2100> I just love my ISP
<Mirv> I kind of love my ISP but I'm currently pondering if I love it so much I'd get a two year fixed contract - the contract terms are usually so that even if in reality it would start to suck, there's no real chance to abort the contract
<Mirv> I'd just get 100/10 instead of 24/10 and for slightly less price
<Mirv> but I generally hate all "bind yourself to us for N years" deals
<sil2100> Yeah, I'm also bound to a 2 year contract here
<Mirv> sil2100: so based on your experience it'd be an valuable option to be able to switch :)
<sil2100> didrocks: packaging ACK needed! Looks ok, although the description seems to be doubled ;/ python 2 and 3 ones have the same desc... not sure if we should block on that? http://162.213.34.102/job/landing-009-2-publish/lastSuccessfulBuild/artifact/packaging_changes_window-mocker_1.4+14.04.20140220.1-0ubuntu1.diff
<ogra> === Image 212 DONE ===
<ogra> (yay, and my desktop build notification tool works)
<popey> didrocks: did you want me to dogfood 212?
<didrocks> sil2100: +1, I think the package name helps knowing what it is
<didrocks> popey: weather-app only + everything related to sound
<didrocks> popey: if you can rerun the weather-app AP test btw, just in case :)
<ogra> definitely dogfood it
<ogra> make sure calls work again
<popey> k
<ogra> thats the importand change in this image
<didrocks> so, after that one, only:
<ogra> *important
<didrocks> - the qt crash
<didrocks> - camera app
<didrocks> - clock apps
<didrocks> should be the remaining issues
<davmor2> popey: On the click updater I saw the new image for the calculator however once it had installed I still see the old one, also the calculator doesn't seem to open once updated even after a reboot so I'm wondering if something got broken there
<davmor2> didrocks: ^ other than that issue and the camera app locking up all seems good here on mako :)
<didrocks> davmor2: excellent, and so, no crash at all?
<davmor2> didrocks: not so far
<didrocks> great
<davmor2> popey: the new weather opens fine I don't know if that was the fix for the qt5.2.1 issue we saw or what :)
<sil2100> didrocks: packaging change! http://162.213.34.102/job/landing-014-2-publish/6/artifact/packaging_changes_unity-scope-click_0.1+14.04.20140226.1-0ubuntu1.diff <- added dependency, it's used so it should be ok
<didrocks> sil2100: yeah, +1
<Mirv> mh, that cordova thing is a bit hard, but I guess I can downgrade and see if it looks identical with that
<Mirv> I've a "non-styled" app after instead of just running on device I installed it. plus the instructions on the google docs don't exactly match what I have in the SDK
<Mirv> ah hmm, I guess I should use the SDK PPA even though archive version is only a week old
<Mirv> maybe that helps with the desktop side of things and wrapping up what's going to get installed
<didrocks> sil2100: seems ubuntu-ui-extras had a silo but nobody checked the lander for him
<didrocks> so I assigned bill as he requests to flush trunk
<sil2100> didrocks: indeed, right, thanks!
<didrocks> yw
<Mirv> eh, now the docs instructions for testing HTML5 apps are even more wrong
<didrocks> hum, no dbarth
<didrocks> Mirv: maybe just put a comment and move to the next one then?
<didrocks> (put your comment on red background)
<sil2100> ;/
<Mirv> sil2100: can you check if l12 is proper now? I just added my stuff to the comments
<Mirv> moving to unity-mir next
<popey> didrocks: 212 seems okay for clock/camera/audio/dialer (not fully dogfooded)
<didrocks> popey: great, tell us if you see any crash impacting you
<didrocks> thanks :)
<didrocks> so, maybe we'll be able to promote an image once the camera+clock fix are in
<popey> didrocks: will do, i have a couple of meetings but will dogfood properly in a bit
<popey> and will update the sheet and ping you when done
<didrocks> popey: I count on your breakage expertise! :)
<didrocks> (take care of the phone glass though, not that kind of breakage :p)
 * didrocks runs
<sil2100> ;)
<didrocks> no answer on the troll, even not a disdain "ahahah", so disappointing!
<Mirv> sil2100: more precisely, do I need to switch some testing "unsuccessful" switch or is comment enough?
<popey> :Ã¾
<sil2100> Mirv: comment and you can even switch the Tested field to No if needed ;)
<Mirv> that's what I was wondering about. yep, I'll switch it so it's more clear it's not been (successfully) tested (by us)
<sil2100> AH HA
<sil2100> Good one
<sil2100> I'm testing now address-book-app and wanted to check the testing guidelines to see if I'm doing it right
<sil2100> I click the links and HA! Empty!
 * Mirv updated unity-mir and has a black screen after reboot. is this bad? :)
<sil2100> NOTREGRESSION
<sil2100> ;D
<sil2100> Just kidding
<sil2100> Really?
<Mirv> yeah. unity8 and maliit-server crashed, apport running.
<Mirv> I'll need to do some reiterations downgrade/upgrade I guess first
<davmor2> Mirv: is it a fresh flash or just added the unity8 stuff?
<Mirv> davmor2: fresh flash + landing-011 (unity-mir) (and well also html5 update)
<Mirv> hmm, another reboot and no crash
<Mirv> have we had random unity8 crashes lately on the images?
<popey> didrocks: terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
<Mirv> maybe I pretend what happened didn't really happen and run unity8 tests and do a couple more reboots after that
<popey> expecting that?
<didrocks> popey: not really
<didrocks> you do have a crash file?
<popey> not a recent one
<popey> didrocks: getting a few crashes
<popey> I'm being a bit brutal with it
<didrocks> ok, can you try to clean /var/crash and retry?
<didrocks> to see if it's reproducible
<popey> ya
<popey> had one unity crash and a bunch of app crashes / oddities
<Mirv> popey: so you too got unity8 crash on stock image (or whatever you're testing?)
<Mirv> I'm retracing one unity8 crash file now on desktop (if it works) while running unity8 tests
<popey> Mirv: this is stock 212
<Mirv> I'm using 211 - landing-011
<popey> bah, can't reproduce it now
<popey> did exactly the same thing
<didrocks> Mirv: don't retrace, just try to look at the address first
<didrocks> if it's d8f8
<Mirv> didrocks: how to look at the address?
<Mirv> -> hangout, but AP should be soon ready and I did manual testing too already. if AP ok I'll do a couple of reboots more, and it should be ~ready
<didrocks> Mirv: excellent! so it's what I pasted for psivaa this morning
<didrocks> one sec, looking
<didrocks> didrocks | psivaa: ok, so gallery_app is the v8 crash
<didrocks> didrocks | psivaa: so, what I have done to quickly check
<didrocks> didrocks | wget <crashfile>
<didrocks> didrocks | apport-unpack <crashfile> foo
<didrocks> didrocks | gdb gallery-app foo/CoreDump
<didrocks> didrocks | then I'm seeing: #0  0x50b0d8f8 in ?? ()
<didrocks> didrocks | (on the phone of course)
<didrocks> Mirv: ^
<Mirv> retrace is ready, though, will look tha to
<asac> Mirv: so can we for the sake of testing back out the binary packag rename until we are ready?
<asac> makes no sense to shoot ourselves in the foot
<asac> imo
<asac> Mirv: its very very important that we can test stuff without the apps getting rebuild
<asac> all the apps that have no private headers and dont use qreal
<asac> in API
<Mirv> asac: it'd restart the building once again, but I guess it could be doable. but not without approval from slangasek who in the first place asked Debian to do the rename and Debian accepted it to help us
<asac> Mirv: you are the man who preps stuff in the ppa
<asac> you dont need slangasek approval for our testing
<asac> really
<asac> thats crazy. b
<asac> we are not saying that we wont do the package rename for the landing. just for testing etc.
<Mirv> asac: well it seems going back and forth with different solutions
<asac> its not going back and forth. its just operationally we cant rename it right now
<Mirv> asac: then for landing it would be another 1-2 weeks of rebuilds, if now the rename would temporarily removed
<asac> we can do the rename before we do the push to archive
<asac> Mirv: ok, what you can do is include a compatibilty package for the testing
<asac> so we just need to drop that
<Mirv> so I think it needs discussion before I remove the PPA
<asac> and no rebuild after
<didrocks> can we screw apt?
<didrocks> and tell to --force-depends
<didrocks> or something like that
<asac> we can just shiup empty package named like old and depend on the new package
<Mirv> didrocks: I think for testing purposes that would be possible and a more sensible path
<asac> while we test
<asac> whatever
<asac> find a solution
<Mirv> some dummy libqt5core5 package could work too
<asac> without infrsatructure work
<didrocks> I would prefer the dummy libqt5core5 package approach
<Mirv> but now back to -> hangout
<asac> please do the dummy one for the ifnal testing
<asac> thanks. please upload that asap so we can do the testing we need
<Mirv> didrocks: http://pastebin.ubuntu.com/7010279/ ?
<didrocks> Mirv: should be arch:all
<didrocks> section oldlibs
<didrocks> (if we want to keep it)
<didrocks> otherwise +1
<Mirv> yeah this multi-tasking is quite hard
<sil2100> Time for some lunch
<didrocks> popey: if I install manually a click package, it should appear in installed, right?
<popey> i tend to....
<popey> adb push foo.click /tmp
<didrocks> yeah
<didrocks> then pkcon install-local <click_package>?
<popey> adb shell then sudo -u phablet -i, then pkcon install-local /tmp/foo.click
<popey> then search for it
<didrocks> ah
<didrocks> I'm dumb
<didrocks> I was root
<popey> ya, everyone does that
<didrocks> ahah :)
<didrocks> hum
<didrocks> ok, black scren
<didrocks> screen
<popey> which app?
<didrocks> I think it's because I need some permissions or whatever :p
<didrocks> popey: a dummy test app, just generated for default qtcreator
<popey> ah
<didrocks> (weird we don't ship the correct manifest)
<popey> I'd look in /home/phablet/.cache/upstart
<popey> or dmesg -T | grep DEN
<didrocks> libust[7388/7392]: Error: Error opening shm /lttng-ust-wait-5-32011 (in get_wait_shm() at lttng-ust-comm.c:881)
<didrocks> no other error
<didrocks> ok, it works from qtcreator
<didrocks> popey: do you still have a device with Qt 5.2?
<popey> didrocks: no
<didrocks> do you have the instructions somewhere so that I can upgrade?
<popey> ya
<popey> https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2
<popey> == Updating on device ==
<popey> obviously make it rw and reboot first
<didrocks> oh! :)
<didrocks> popey: ok, I'm dist-upgrading, seems that's all needed then, thanks ;)
<Mirv> asac: I did a test build locally and now before switching hangouts uploading to PPA
<Mirv> mhr3: line 14 ready for clean and merge
<Mirv> didrocks: the EOD status is actually fully documented at http://pad.ubuntu.com/qt52-dependencies in case it'd be wanted that we go forward with recompilations, which I guess we won't be doing. but just in case, that doc has all the information landing team should need with Qt 5.2
<asac> Mirv: thanks! ... remember to drop the transitional package for the final upload i guess - unless we want to go through the motion of talking to steve again
<didrocks> Mirv: thanks a lot :)
<Mirv> sil2100: so unity-mir and the scopes published
<rsalveti> morning
 * rsalveti reading backlog
<popey> didrocks: what controls rotation in apps? I mean, which system component says "ok, we're 90 degrees from normal now, rotate!" ?
<didrocks> popey: I would say qtubuntu-sensors, but TBH, I'm not 100% sure
<popey> looks plausible
<tvoss_> popey, right now, it's qtubuntu-sensors
<tvoss_> popey, but that's soemthing that will change over time
<popey> ok, i need to file a bug for qt5.2
<popey> oh, no I don't i mean for image 212
<popey> i didnt say 5.2, ignore that
<didrocks> you did say it
<didrocks> I read it!
 * popey edits the logs
<didrocks> heh :)
<didrocks> and my memory as well?
 * ogra didnt see 5.2 anywhere 
<ogra> :P
<popey> *** Problem in qtubuntu-sensors
<popey> This is not an official Ubuntu package. Please remove any third party package and try again.
<popey> dammit
<ogra> but why is popey working with qt212
<popey> oh, i have way too many devices
<popey> didrocks: bug 1286150
<ubot5> bug 1286150 in qtubuntu-sensors (Ubuntu) "Rotating detection is very sensitive mako #212" [Undecided,New] https://launchpad.net/bugs/1286150
<popey> just nudging or tapping the phone causes it to try to rotate
<didrocks> popey: hum, I don't see anything in qtubuntu-sensors that could have caused it
<popey> could be android/hybris?
<didrocks> rsalveti: any idea? ^
<popey> it could well have arrived earlier than 212
<rsalveti> I can check
<didrocks> popey: let me flag 202 just in case
<didrocks> popey: can you try 206 meanwhile?
<didrocks> just to know if it's pre/post-android 4.4
<popey> didrocks: does that need a 4.4 downgrade?
<didrocks> popey: not for 206
<popey> ok
<didrocks> ugly recovery logo on 202 :p
<didrocks> popey: I don't see real difference between 202 and 212
<didrocks> on the titling
<popey> bang the side of the phone
<ogra> it was always very sensitive for me
<didrocks> it's as sensitive
<didrocks> as it was
<didrocks> to me
<didrocks> I can try 209
<didrocks> to compare
<ogra> (also i dont bang my phone))
<popey> to simulate
<popey> i mean, i notice it flip when i put it down on the desk, even on an incline
<rsalveti> yeah, they were also sensitive here as well
<ogra> i had that since ages
<popey> hmm
<popey> okay
<popey> ignore me :D
<ogra> pretty annoying if you put it down while reading a text
<ogra> just to have your hands free
<popey> text
<popey> right
<popey> â»
<didrocks> ogra: I'm trying 196
<didrocks> (and you delay my break! ;))
<ogra> i didnt claim it was broken !
<ogra> blame popey
<didrocks> argh
<didrocks> popey: ^
<popey> http://blamepopey.com/
<didrocks> sorry "all the same" :)
<ogra> ++
<didrocks> popey: you lack blinking tags :)
<popey> I apologise most sincerely from the bottom of my heart. Can you ever forgive me?
<didrocks> popey: thanks, I just wanted you to feel guilty :)
<popey> good luck with that
<didrocks> roh
<Mirv> didrocks: so ubuntu2 of qtbase compiling in the PPA. transitional package to be dropped for final release, and at the moment (after the meeting discussions) it does not seem anyone is actually going to investigate mixing of packages / ABI breakage right now. but the transitional package is now there for time being. I can remove it with ubuntu3 upload on Monday or something.
<didrocks> Mirv: ok, so let's seeâ¦ keep it until next week, yeah :)
<seb128> do you guys know when l10 is planned to land?
<seb128> the fixes for the concurrent checks of upgrades
<Mirv> didrocks: sil2100: secondly, it would be "go ahead" about continuing now as listed at http://pad.ubuntu.com/qt52-dependencies for example by starting by giving CI Train the multimedia-touch link, then dee-qt/libqtdbus* etc in order. it's up to the landing team I guess to organize whether I'll do it alone or not.
<seb128> we start having a stack of ubuntu-system-settings changes in the queue, one blocking toolkit changes
<Mirv> the qtwebkit finished building, Qt is essentially done now in landing-006
<didrocks> seb128: do you know what is "We want manual testing first"
<didrocks> about?
<seb128> didrocks, no, I want to know if anyone is actively working on making that happen
<didrocks> Mirv: we are tha landing team :)
<seb128> e.g ralsina_
<seb128> ;-)
<Mirv> didrocks: yes, so up to us/you to decide eg. in the evening meeting :)
<Mirv> I'm EOD now, but the plan should be ~clear
<Mirv> in the pad
<didrocks> Mirv: right, depends on how much we need to land for the rest, I guess, but yeah, it's clear ;)
<Mirv> yep
<didrocks> seb128: yeah, we need him I guess to know on that one
<ralsina_> seb128: yes? (/me reads backlog)
<seb128> ralsina_, hey
<seb128> ralsina_, I'm wondering when the fixes for the concurrent upgrade checks is going to land (l10), we have a mp for settings there and it's blocking any other setting work to get a slot
<ralsina_> I am not really the right person to land system settings, my team only did a plugin for it. The "we want manual testing" was laney
 * sil2100 prepares for testing unity8
<didrocks> Laney: ? ^
<sil2100> The u-d-m and ubuntu-system-settings one is a bit fishey
<seb128> ralsina_, u-s-s is only a small part of that landing ask
<ralsina_> right
<sil2100> So I wait with that one still
<didrocks> sil2100: what is fishy?
<ralsina_> both barry and mandel have tested the other parts a lot
<seb128> ok
<seb128> I'm going to test that ppa on my n4 which is on 209
<seb128> let's see how that goes
<didrocks> seb128: if you +1 on that one, I'm happy that you publish it
<didrocks> (with your testing)
<seb128> didrocks, thanks
<didrocks> popey: ok, same sensitivity here
<didrocks> with 198
<didrocks> sil2100: going for a run, once unity8 is tested, can you get (if you have packaging changes) other core-devs +1?
<bfiller> asac: line 26 on sheet are build only changes for qt5.2. no functionality added/changed
<didrocks> sil2100: so that we can start another image soon
<bfiller> didrocks: any chance we could get a silo for line 20 today?
<didrocks> bfiller: sounds legit, assigning now
<bfiller> didrocks: thanks
<sil2100> didrocks: sure
<sil2100> didrocks: the upgrade part was fishy, I was getting some strange error when wanting to upgrade my image
<sil2100> Not sure if it's caused by these changes (since I just reverted), but I guess unity8 is more important
<didrocks> seb128: FYI ^
<didrocks> sil2100: yeah
<didrocks> bfiller: done
<boiko> didrocks: bfiller: thanks, I'll build that
<bfiller> boiko: just did :)
<boiko> bfiller: ah ok, thanks then
<bfiller> didrocks: and line 26 should be harmless, just some includes added so the packages would be correclty on both qt5.0 and 5.2
<bfiller> build correctly that is
<didrocks> bfiller: check with asac first though, seeing his comment
<asac> dont worry
<bfiller> asac: any objections there?
<asac> didrocks: so given we gave up on the idea to do empirical data gathering we can just land qt5.2 changes
<didrocks> bfiller: and telephony-service is already in line 20
<bfiller> didrocks: ah right, I should have added it there (:
<asac> bfiller: whats the exact question? had a reconnect :)
<bfiller> asac: your comment in line 26
<asac> if its about qt5.2 changes, we tried to not land those so we could test our binary compatibilty story
<didrocks> bfiller: so, separate them, maybe? if you want the other part to land?
<asac> but seems the damage is already done, so we have to figure how to do that different
<bfiller> asac: this is just a build fix so it will compile under both, no compatibility issue at all
<asac> bfiller: right. however, build fixes might have implicit runtime behaviour changes as well... but anyway, we gave up on the idea that we can use the pretransition state to check the binary compatibility story
<bfiller> asac: so it's ok then to land?
<asac> yep. removed the comment
<asac> thx
<bfiller> cheers
<didrocks> bfiller: so, you separate telepathy-service from it? so that we can land
<bfiller> didrocks: sure, one sec
 * didrocks is waiting on bfiller to take his first break 9h after he started his day
<bfiller> lol
<didrocks> blame popey from my previous failed attempt!
<didrocks> bfiller: silo 002 for you
<didrocks> bfiller: if you need anything sil2100 is around (but validating unity8 for now)
<bfiller> didrocks: thanks, I moved the telephony-service to it's own line for after line 20 biulds
<didrocks> bfiller: yeah, sounds good ;) thanks.
 * didrocks goes really for a run now
<rsalveti> kgunn: are you preparing mir 1.6?
<kgunn> rsalveti: i am
<kgunn> getting all the mp's sorted...
<kgunn> filling out the spreadsheet in moments
<kgunn> is it ok ?
<rsalveti> kgunn: great
<kgunn> rsalveti: i'll probably suck in a few u-s-c & u-m MP's with it
<rsalveti> sure, just to know because I'll try the x86 emulator image with your latest stuff, and nested should be working now
<rsalveti> if the issue with unity-mir conflicting symbols with mir is already fixed in there
<rsalveti> yeah, that's fine
<rsalveti> wonder if might have another silo blocking you
<kgunn> rsalveti: yeah...i need to pull that in as well
<kgunn> https://code.launchpad.net/~gerboland/unity-mir/namespace-to-prevent-collision/+merge/208645
<rsalveti> awesome
<kgunn> gerry just warned me
<sil2100> bfiller: what's up?
<bfiller> sil2100: good for now
<rsalveti> didrocks: can I get a silo for line 31?
<sil2100> didrocks: lemme see
<ogra> popey, could you try something on a 4.4l based mako ?
<seb128> ralsina_, didrocks, sil2100, Laney: upgrade went without issue here (using the ppa-010, auto download on wifi, 209->212)
<ogra> popey,  adb shell "dmesg | grep ACL"
<seb128> I'm waiting for Laney to be back to check with him, but I would say +1 for landing that slot
<ogra> popey, does that return any systemd-udevd messages for audio devices ?
<rsalveti> I think it returns a bunch of messages for a bunch of devices
<rsalveti> not sure why yet
<ogra> rsalveti, right
<popey> ogra: [   21.517747] Bluetooth: opening HCI-SMD channel :APPS_RIVA_BT_ACL
<ogra> rsalveti, i see it on flo, but not on my mako with image 196 (4.2)
<ogra> popey, thats all ?
<popey> yes
<ogra> great
<ogra> rsalveti, so mako doesnt have it
<ogra> even on 4.4
<ogra> seems to be flo specific
<rsalveti> all multimedia related
 * ogra checks manta
<cyphermox> ogra: popey: what's this? for bluetooth?
<ogra> cyphermox, no idea, i was looking for alsa stuff :)
<ogra> for bug 1286184
<ubot5> bug 1286184 in linux-flo (Ubuntu) "udev ACLs for sound devices can not be set" [Undecided,New] https://launchpad.net/bugs/1286184
<rsalveti> ogra: maybe because of the default permissions for them?
<rsalveti> crw-rw---- 1 system video 81, 1 Feb 28 15:33 /dev/v4l-subdev0
<Laney> seb128: Yeah indeed
<Laney> are we allowed to do it?
<cyphermox> ogra: oh okay
<rsalveti> ogra: might might have it 664 or similar
<ogra> hmm, perhaps
<ogra> i'll check them
<ogra> but udevd runs as root
<seb128> Laney, didrocks said that if we did manual testing and it worked fine he would be fine with us publishing
<ogra> it should be able to set the acls
<Laney> seb128: ok cool, let me do that then
<seb128> didrocks, confirming that we can land l10?
<ogra> grrr
<ogra> my manta is dead
<Laney> sil2100 thinks it is 'fishy'
<seb128> Laney, wait for didrocks to confirm
<Laney> for what reason?
<seb128> read backlog ;-)
<Laney> I didn't see any clear explanation
<seb128> sil2100, ^
<seb128> I think he just hit issues, but he didn't give specific
<seb128> so it could be anything
<ogra> great
<Laney> yes quite
<ogra> manta doesnt have it either
<Laney> it's not very helpful
<rsalveti> Operation not supported
<rsalveti> yeah, should be kernel related
<rsalveti> missing config or such
<ogra> right
<sil2100> seb128, Laney: I'll double check that one, had some problems with system upgrade (had an error message), but didn't confirm if it didn't happen for me with the pacakges reverted
<sil2100> As I'm dealing with unity8 now
<seb128> sil2100, when do you think you can check?
<Laney> what error and when did you do it?
<kgunn> sil2100: ready for a mir silo whenever you get the chance
<sil2100> seb128: in a few moments, unity8 tests just finishing their run
<seb128> k
<seb128> thanks
<Laney> please file a bug or tell someone next time
<rsalveti> ogra: it seems we're missing CONFIG_TMPFS_POSIX_ACL
<ogra> rsalveti, fun, apw checked the config when we talked about it and told me it was on
<ogra> (i didnt check myself though=
<ogra> )
<rsalveti> config/config.common.ubuntu:# CONFIG_TMPFS_POSIX_ACL is not set
<ogra> yeah
<rsalveti> I know config/enforce forces that
<rsalveti> but not sure if it's indeed working
<rsalveti> do we have /proc/config?
<ogra> nope
<ogra> not on flo at least
<rsalveti> sadpanda
<ogra> we should probably have it since we dont ship a config in boot
<rsalveti> /boot/config should have it
<rsalveti> ogra: yeah
<ogra> if we would use the packages :)
<rsalveti> sure, I mean, just for us to check
<apw> rsalveti, in which tree
<rsalveti> apw: flo
<apw> i checked it in the one ogra was suggesting it was off in, mako
<apw> well there you go
<rsalveti> 2899 # CONFIG_TMPFS_POSIX_ACL is not set
<rsalveti> yeah, disabled
<ogra> rsalveti, added a note to the bug
<rsalveti> apw: can you enable that for us?
<ogra> apw, bug 1286184 has all info
<ubot5> bug 1286184 in linux-flo (Ubuntu) "udev ACLs for sound devices can not be set" [Undecided,New] https://launchpad.net/bugs/1286184
<ogra> please enable /proc/config.gz too
<rsalveti> yeah
<apw> you want the config built into the kernel, on devices the size of a peanut ?
<ogra> (noted there as well, tell me if you need a separate bug)
<ogra> apw, yes
<apw> why?
<apw> whats wrong with the one on disk
<ogra> apw, to find out about options i have to pull the kernel source otherwise
<rsalveti> we don't have the one on the disk
<ogra> apw, there is none on disk
<apw> well only cause you remove it to save space
<ogra> apw, we nebvber install the kernel package in the rootfs
<apw> it is in the package
<sil2100> Publishing unity8 - packaging changes made by coredev (xnox), so auto-+1'ed
<sil2100> ;)
<rsalveti> sil2100: which silo?
<ogra> apw, the zImage and modules only get pulled into the android boot.im at android package build time
<apw> it still makes more sense to copy that file into the flash than it does to fill memory, actual ram with it
<ogra> from the kernel .deb
<rsalveti> right
<ogra> android has it on by default
<ogra> i dont think it does any harm
 * ogra also wouldnt call 2G a peanut :) 
<sil2100> rsalveti: assigned 003
<sil2100> rsalveti: ah, you mean the unity8?
<rsalveti> sil2100: oh, sorry, yeah, unity8
<sil2100> Silo 008
<rsalveti> cool
<apw> ogra, if that is what you want ... i will note my objection h
<apw> here, as the filesystem is the sensible place for it
<ogra> apw,  we want to rip out all device specific bits from the fs
<apw> there is a device specific tarball for this kind of thing right?
<ogra> yes, of the android container
<sil2100> seb128, Laney: ok, so I reverted the packages and I still see the problem, I see an error of the likes of "FileNotFoundError: [Errno 2] No such file or directory: '/android/cache/recovery'" in the updates panel of system settings
<sil2100> Maybe it's caused by my infameous dual-boot?
<rsalveti> we could try to make it available at /system/boot/
<rsalveti> that would make everyone happy I guess
<ogra> sil2100, err
<apw> ogra, to me getting every user of the phone to waste memory cause you haven't got the git repo is also strange
<seb128> sil2100, seems like something on your install is busted
<ogra> sil2100, pretty please never use diual boot during *any* testing
<ogra> sil2100, it cant do OTA
<rsalveti> ogra: apw: let me change the packaging then to drop that at /system/boot or similar
<rsalveti> the modules are already part of the android system image anyway
<ogra> sil2100, the recovery img gets abused for the dual boot, you cant even download the files
<ogra> its a hack, dont use it
<Laney> I think we can disregard those results :-)
<ogra> rsalveti, hmm, k
<sil2100> Indeed!
<Laney> however...
<Laney> there should be a way to turn off the updates in that case
<sil2100> Well, I think we need someone else to double-check the test results
<sil2100> Laney: well, dual-boot is not official, so I don't think that's needed
<Laney> Lots of people have tested it
<ogra> Laney, yes, i added a whishlist bg for it ... seb128 told me there would be no developer time to fix it though
 * sil2100 likes the dual-boot
<ogra> sil2100, its a hack
<Laney> ogra: Free software man
<ogra> please never use it when testing anything official
<Laney> Just because we won't work on it doesn't mean it shouldn't be there
<ogra> Laney, indeed :)
<ogra> Laney, its just that chances are low to get it fixed
<sil2100> This way I can safely use my mako as my main phone - whenever something doesn't work on UT then I can switch to android and have it working again ;)
<ogra> sil2100, again, please dont use it for any official testing
<ogra> you can do whatever you want for personal use :)
<ogra> but there are plenty of hacks in the install process of the dual boot that can easily taint your results
<ogra> (we refuse to support it for a reason ... )
<Laney> it was trumpeted at the time though
<sil2100> geh
<seb128> sil2100, so it's ok to land it?
<sil2100> Thing keep bumming me out this week it seems
<sil2100> seb128: I would still like someone to try upgrading his system with the packages from the silo
<seb128> sil2100, I did that an hour ago
<seb128> <seb128> ralsina_, didrocks, sil2100, Laney: upgrade went without issue here (using the ppa-010, auto download on wifi, 209->212)
<seb128> I installed the ppa content on 209
<seb128> rebooted
<Laney> Many people have tried it
<seb128> then upgraded to 212
<Laney> me, barry, mandel
<sil2100> Oh! Missed that ping :) THanks!
<sil2100> Let me publish it then, the rest looks fine
<seb128> ok to land then? ;-)
<ogra> ++
<Laney> I'm doing it
<seb128> we can do the publishing
<Laney> already have the page open :P
<seb128> sil2100, ^
<seb128> Laney, thanks
<seb128> \o/
 * Laney slaps 2fa
<mandel> awesome! seb128, sil2100, Laney thx!
<ogra> :)
<Laney> http://162.213.34.102/job/landing-010-2-publish/16/console
<seb128> Laney, SUCCESS
<seb128> \o/
<Laney> yeah friday uploads!
<seb128> haha
<sil2100> All these Friday uploads are planned uploads!
<didrocks> rsalveti: what's this line 31? the pulseaudio fix wasn't enough? (just trying to gather info for the email ;))
<didrocks> rsalveti: or is it for the camera fix?
<rsalveti> didrocks: bug 1284731
<ubot5> bug 1284731 in linux-manta (Ubuntu) "Please turn off CONFIG_RT_GROUP_SCHED in all our kernels" [Critical,Fix committed] https://launchpad.net/bugs/1284731
<rsalveti> didrocks: no, not camera yet
<rsalveti> didrocks: not critical for pulse, but a good fix
<rsalveti> so it can requests rt priority from rtkit
<rsalveti> when doing voice calls
<didrocks> rsalveti: oh yeah, indeed a good one :)
<rsalveti> didrocks: camera is in progress
<didrocks> rsalveti: thanks for the infos ;)
<rsalveti> np
<didrocks> sil2100: ogra: let's kick an image as soon as unity8 is in the release pocket
<didrocks> (now that you can track it live on the spreadsheet :p)
<didrocks> plars: hey, mind checking that all flaky tests are due to the crash on image 212 for the meeting?
<ogra> didrocks, btw, i would like to land this one https://code.launchpad.net/~mterry/session-manager-touch/exec-usc/+merge/208636 (one liner, tested omn all devices, fixes an issue on shutdown) with a direct upload
<didrocks> plars: and that the crash is the known one
<ogra> (not urgent, but i dont want to forget about it over the weekend)
<plars> didrocks: I'm trying to get flo/manta looking a bit better, but I guess you are talking about mako?
<didrocks> ogra: sure, please do, but let's not delay this image on it
<didrocks> plars: please focus on mako first
<didrocks> plars: for now, forget manta :)
<didrocks> plars: do you need a recipe to validate the .crash files?
<didrocks> (I pasted one to psivaa)
<plars> didrocks: no, I didn't
<ogra> didrocks, yeah, doesnt matter if it gets into this image or the next one
<didrocks> plars: ok, seems we have 5 crashes to validate :)
<didrocks> plars: you think you will have that for the meeting?
<ogra> didrocks, btw, i wrote some desktop tools to monitor images recently ... (one that rings an alarm if a build is done, another one wheer you can type in the image number and get the right changelog automatically) i'll push them to the pahblet-team ppa once i'm done, should be helpful for all image producers
<didrocks> ogra: ahah, excellent!
<ogra> (just some zenity with shell scripts)
<didrocks> urgh zenity :p
<ogra> yeah, will re-do in QML later :)
<didrocks> ahah
<plars> didrocks: I'll check them out
<plars> didrocks: you are talking about the app crashes, not things like qmlscene right?
<didrocks> plars: all crashers
<didrocks> plars: it's 1 min per crash to see :)
<rsalveti> ogra: cool, get us an irc bot as well :-)
<ogra> rsalveti, working on that :)
<rsalveti> I can pay in beers
<ogra> haha
<rsalveti> awesome
<didrocks> unity8 in!
<didrocks> let's kick an image
<didrocks> hum, rmadison disagree :)
<didrocks> my script is still relying on lp :p
<seb128> wouut
<seb128> Laney, upload on friday, and it's even to make into an image on friday :p
<Laney> heh
<Laney> didrocks: can you wait for ubuntu-download-manager and system-image?
<seb128> how come u-s-s moved first?
<didrocks> Laney: I would prefer not, any reason?
<seb128> oh, the others ones have autopkgtests
<didrocks> Laney: if we keep delaying on more and more componentsâ¦
<Laney> so that the fixes are in ...
<seb128> didrocks, we got the u-s-s update without the other 2 from the same silo
<didrocks> argh
<didrocks> ok then :(
<seb128> that's an untested mix
<seb128> u-s-s went through but britney/autopkgtest are delaying the other ones
<xnox> how are things looking? will ubuntu-ui-toolkit land today, or is it posponed till monday?
<Laney> the tests all passed afaics
<seb128> right
<seb128> next publisher run
<ogra> didrocks, it in, do you want to trigger the build or want me to do it ?
<ogra> *it is
<didrocks> ogra: even ubuntu-download-manager and system-image?
<ogra> ah, only looked for unity8
<didrocks> ogra: yeah, see ^ :(
<didrocks> we have to wait now
<ogra> yeah
<seb128> it's not going to be long, the tests are done, next publisher run
<seb128> likely less than 10min
<didrocks> balloons: joining?
<seb128> didrocks, ogra, Laney: system-image is in, looks like the download-manager is going to need another run
<ogra> the source doesnt seem to have moved yet
<ogra> ogra@anubis:~/Devel/branches/ubuntu-touch-session-0.104$ rmadison system-image|grep proposed
<ogra>  system-image | 2.1-0ubuntu4   | trusty-proposed/universe | source
<seb128> ogra, right, I was looking at the output page
* retoaded changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: retoaded | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Landing instructions: http://goo.gl/8H1Du3. Landing in degraded mode (see http://goo.gl/J1EqPW) | Known Issues: -
<Laney> it will
<Laney> have faith
 * ogra does ... just not in the timing
<ogra> (except for rmadison)
<robru-sick> rsalveti, i'm probably less busy than cyphermox if you need any help landing/testing
<rsalveti> cool, thanks
<ogra> robru-sick, still sick ?
<robru-sick> ogra, yeah, it's quite bad, my throat is very scratchy & swollen. i'm lying in bed with laptop
<ogra> oh man
<ogra> hope you get better soon
<ogra> thats going on a week already, isnt it ?
<robru-sick> ogra, thanks. it's been two weeks now, i just wasn't complaining about it before.
<ogra> oww
<robru-sick> ogra, yeah, i got it right as I was moving. something about being in and out all day really weakened my immune system
<Laney> udm is going over now
<Laney> ogra: do you know wait-for-package on nusakan?
<ogra> didrocks, want me to trigger the image ? i plan to work late today anyway
<ogra> Laney, sure
<ogra> i love it
<didrocks> ogra: if you can, that would be awesome!
<ogra> didrocks, fine then
<Laney> you could use it in this case :-)
<ogra> Laney, well, if i wouldnt hop between office and living room, yeah
<Laney> screen?
<didrocks> thanks ogra ;)
<seb128> Laney, can you clean the silo? ;-)
 * seb128 wants to put another u-s-s in
<Laney> once rmadison has udm
<ogra> Laney, ah, that modern stuff
<seb128> the gdoc says they are in destination
<seb128> is that not true.
<seb128> ?
<Laney> it should be, just not visible via rmadison yet
<seb128> didrocks, where do you get the "packages are in destination" status from? not rmadison?
<Laney> well, lp says it's gone over
<didrocks> seb128: no, launchpad
<seb128> k
<Laney> probably gets it from the state there
<Laney> I guess that's enough tbh
 * Laney cleans
<seb128> Laney, you are being overzealous :p
<Laney> http://162.213.34.102/job/landing-010-3-merge-clean/11/console
<seb128> thanks
<robru-sick> bregma, ping me when line 33 is ready and I can assign you a silo.
<ogra> === Image 213 Building ===
<bregma> robru-sick, I will, but it will probably be an hour or so while I test a last-minute FTBFS fix for ppc64le (said build is killing my local machine)
<Laney> bregma: you should use a beefy cloud instance to build :-)
<robru-sick> bregma, no worries, i'm around
<xnox> ..
<xnox> bzoltan pinged me to merge and resolve 3 branches that have conflicts between them.
<xnox> I've now done so, in https://code.launchpad.net/~xnox/ubuntu-ui-toolkit/py32ap+listview-scroll_to_bottom+qmlapicheckverbose/+merge/208859
<xnox> not sure what needed to happen next to get the three branches bundled correctly.
<xnox> ..
<bzoltan> xnox: I have replaced the MR with the non conflicting one, but the "build" does not pick it up ... maybe somebody from the landing team could help us.
<bzoltan> robru-sick: ^^
<bzoltan> cyphermox: ping
<cyphermox> pong
<bzoltan> cyphermox:  we have a situation with xnox ^^^
<bzoltan> cyphermox: in silo 13
<cyphermox> so yu want me to reconfigure and make it just xnox's branch?
<ogra> cyphermox, can i get a silo for line 34 (and possibly some hand holding, i had a bootcamp but zero practical experiance)
<cyphermox> ogra: sure, give me a minute I'm in lunch time, having a meeting with my game development team ;)
<ogra> cyphermox, no hurry ...
<robru-sick> ogra, i can do it
<ogra> robru-sick, great
<robru-sick> ogra, ok, you got silo 8. so you can click 'build' on the 'landing-008' tab of the spreadsheet
<ogra> thanks !
<robru-sick> ogra, you're welcome
<robru-sick> bzoltan, did you get your reconfigure for silo 13? I can do it if not
<ogra> bah, i get access denied on jenkins
<ogra> "No permission for 'Job/Build' "
<robru-sick> ogra, darn. you'll have to ask didier for permissions there. i can do it for today though
<ogra> thanks again
<robru-sick> no worries
<robru-sick> seb128, you got silo 10, please build
<seb128> robru-sick, thanks
<robru-sick> you're welcome!
<cyphermox> bzoltan: ping?
<cyphermox> bzoltan: I'm still waiting for the confirmation that reconfiguring with just that one commit is indeed what you wanted me to do
<robru-sick> ralsina_, please merge & clean silo 14
<robru-sick> cgoldberg, please merge & clean silo 9
<cgoldberg> robru-sick, will do now.. thanks
<robru-sick> cgoldberg, thank you!
<bzoltan> cyphermox: sorry I ost the connection
<bzoltan> cyphermox: I woud need the new MR instead of the old from xnox
<bzoltan> cyphermox:  but of course together with the other 12
<cyphermox> bzoltan: could you update the spreadsheet to the correct list of MRs ?
<bzoltan> cyphermox: in the pending page I have updated
<cyphermox> ah, cool then :)
<cyphermox> hrm, I see some conflicts still but I'll resolve them now
<cyphermox> I think https://code.launchpad.net/~kalikiana/ubuntu-ui-toolkit/qmlapicheckverbose/+merge/187243 also shouldn't bethere sicne it would be included in xnox's branch
<cyphermox> same for https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/listview-scroll_to_bottom/+merge/202129
<bzoltan> cyphermox: OK... so I remove these two
<cyphermox> only if you agree with my assessment ;)
<bzoltan> cyphermox: xnox said that he merged to his MR
<cyphermox> yes
<bzoltan> xnox: do you confirm?
<ralsina_> robru-sick: done
<cyphermox> ok it's running
<cyphermox> bzoltan, I can see the merges in his commits so it's good
<robru-sick> ralsina_, thanks
<bzoltan> cyphermox:   Fantastic. Thanks a lot for your help!
 * bzoltan opens a beer and drinks it for the CI team :D
<bzoltan> it is 8pm for /me
<bzoltan> errrr 9pm
<cyphermox> bzoltan: it's ready to rebuild
<ogra> you are exaggerating !
<ogra> 7:52
<ogra> :P
 * cyphermox picks up a beer
<cyphermox> hey, it's almost 2pm now here ;)
<ogra> beer time :)
 * cyphermox grabs lunch at the same time
<cyphermox> too bad I don't actually have beer here
<ogra> take a whisky then :)
<ogra> will do as well
<bzoltan> xnox: ping
<ogra> === Image 213 DONE ===
<bzoltan> cyphermox: those conflicts was just the top ... I puled off that MR from xnox. Let's first land the original 12 MR and then handle the one from xnox on a clean trunk
<cyphermox> alright
<bzoltan> cyphermox: would you please reconfigure the silo again
<cyphermox> sure
<bzoltan> cyphermox: thanks
<cyphermox> as I mentioned befoe though you need to rebuild everything before it works, and I think you need to pass a parameter since you've had builds prior
<bzoltan> cyphermox: sorry, what should I do?
<cyphermox> bzoltan: ignore me, should be fine ;)
<bzoltan> cyphermox: it looks better now
<t1mp> bzoltan: you should open a second beer and watch the stuff land :)
<bregma> hey robru-sick line 33 is ready and eager for a silo now
<robru-sick> bregma, on it
<bregma> oooh, I see a present for me in landing-008, too, goody goody goody
<robru-sick> bregma, you got silo 9, please build
 * bregma goes clicky clicky clicky
<tvoss_> bregma, rofl
<rsalveti> robru-sick: can I get a silo for line 36?
<rsalveti> cyphermox: ^ maybe you as well, if you're around
<robru-sick> rsalveti, on it
<rsalveti> robru-sick: awesome, thanks
<robru-sick> rsalveti, oh, i don't see an MP in the F column?
<xnox> bzoltan1: cyphermox: i've merged the three branches together. i believe i was clear that that mega+ branch replaces the other three branches...
<xnox> i'm away from keyboard now. long past EOD.
<xnox> i thought, the three branches are removed, that mega one added and reconfigure =/ but i'm not silo/lander trained at all.
<bfiller> robru-sick: silo-004 ready for release when you have a moment
<robru-sick> rsalveti, can't do anything without an MP. are we not upstream of ofono?
<rsalveti> robru-sick: package upload
<robru-sick> bfiller, i notice your silo includes a fix for qt 5.2 build failures. will those fixes break if they land before qt 5.2?
<bfiller> robru-sick: no they won't break
<bfiller> robru-sick: tested agasint latest build
<robru-sick> bfiller, ok
<bzoltan1> xnox:  do not bother ... the MP is busted anyway :( I need kalikiana to help with it
<xnox> bzoltan1: meh. ok.
<robru-sick> rsalveti, if you want to release lp:ofono trunk, you need to submit a null merge against trunk. citrain works exclusively on MPs. no MP, no silo
<robru-sick> rsalveti, is this the first release of lp:ofono?
<rsalveti> robru-sick: right, we don't have a branch for it set-up at this point, so that's why I want to do just a package upload
<rsalveti> I was always uploading to the archive by hand
<rsalveti> so now I just want to go in a silo first
<rsalveti> that's why we don't have a MR/branch for it now
<robru-sick> rsalveti, i literally can't assign a silo unless there's an MP. so you need to make a null merge for me to build in a silo.
<rsalveti> robru-sick: well, it is possible, I just have one like that (see 31)
<rsalveti> 24 is another similar one
<robru-sick> rsalveti, go figure, never seen that before. Ok, you got silo 11. but this approach doesn't make sense, you can use any PPA for this purpose. citrain only makes sense when you're building & merging MPs. by doing a manual upload of a single package to a PPA, you literally get none of the benefits of CItrain process
<rsalveti> robru-sick: well, it's better still to just go with ci train, as we can coordinate the testing and so on
<rsalveti> and automatically get the packages published as well
<rsalveti> once we hit promote
<rsalveti> and we also know we get a clean ppa
<robru-sick> rsalveti, yeah, but if you have an MP, you get automatic release tagging, automatic uploads... now you have to prepare the upload manually anyway, only difference is you upload to one PPA instead of another.
<rsalveti> that provides all the right builders and so on
<rsalveti> robru-sick: yup, but that's what I wanted :-)
<rsalveti> robru-sick: thanks!
<robru-sick> ok
<bfiller> robru-sick: silo-002 ready for release too, doesn't break qt5.0 either
<robru-sick> bfiller, just want to confirm that you're really dropping this voicemail stuff? http://162.213.34.102/job/landing-004-2-publish/lastSuccessfulBuild/artifact/packaging_changes_dialer-app_0.1+14.04.20140228-0ubuntu1.diff
<robru-sick> bfiller, oh i see from the changelog it got merged. no worries
<bfiller> robru-sick: yup, should be good
<robru-sick> bfiller, ok, published silo 4, looking at 2
<robru-sick> bfiller, ok, both published, looking good
<bfiller> robru-sick: thanks
<robru-sick> bfiller, you're welcome!
<boiko> robru-sick: do you by chance know what is going on on line 20 of the spreadsheet? is that an error or just an intermediate state?
<robru-sick> boiko, intermediate state. it's telling you that your stuff is just in -proposed, not released yet. it'll turn green when it's ready to hit 'merge & clean'
<boiko> robru-sick: nice! thanks!
<robru-sick> boiko, you're welcome
<bfiller> fginther: any chance you can get CI setup for lp:sync-monitor. It's a new project we need to get integrated into touch
<fginther> bfiller, it's already setup, been there for a week or more
<fginther> bfiller, is it not working?
<bfiller> fginther: oh really, cool. renato ^^^
<robru-sick> bfiller, hey what's going on on line 29? does that need a silo? i thought that was one of the ones i just published...
<bfiller> robru-sick: looking
<bfiller> robru-sick: you published line 26, line 29 are more qt5.2 fixes
<robru-sick> bfiller, oh, silo 4 is on line 20, and silo 2 is on line 26, so it looks like this one does need a silo.
<robru-sick> bfiller, ok, assigning
<bfiller> robru-sick: thanks, the sheet is confusing
<robru-sick> bfiller, yeah, there's a lot going on since the embargo ended ;-)
<robru-sick> bfiller, oh, i need you to merge & clean silo 4 before I can assign line 29. also please merge silo 2 while you're at it ;-)
<bzoltan1> robru-sick: would you please reconfigure the silo13? I ripped off one MR what can not get together with an other one
<bfiller> robru-sick: done
<robru-sick> bzoltan1, ok
<robru-sick> bfiller, thanks
<bzoltan1> robru-sick: thanks
<robru-sick> bzoltan1, ok, silo 13 reconned, please rebuild
<bzoltan1> robru-sick: sweet, thanks ...
<rsalveti> ogra: no more acl errors
<robru-sick> bzoltan1, you're welcome
<rsalveti> \o/
<ogra> yay !!!
<ogra> rsalveti, i'm not even sure they caused any issues :)
<rsalveti> probably not
<rsalveti> but anyway :-)
<ogra> but they filled dmesg
<ogra> :)
<ogra> i'm more interested if RT will gain us anything
<rsalveti> yeah
<robru-sick> bfiller, ok, you got silo 2, please build!
<robru-sick> bregma, published silo 9, please merge & clean when it hits distro.
<robru-sick> bfiller, do you need a silo for line 37 yet? it's not marked as ready but looks ready
<bfiller> robru-sick: I'm waiting on one other MR that I wanted to add to it
<bfiller> robru-sick: will keep you posted
<robru-sick> bfiller, ok great
<robru-sick> bfiller, ok you got silo 4 ;-)
<bfiller> robru-sick: nice, I just added the other mr
<bfiller> you're quick :)
<bfiller> robru: silo-004 (line 36) ready to land
<bfiller> robru: line 37 needs a silo
<robru> bfiller, on it, thanks
<robru> bfiller, ok, 4 published, and you got silo 14.
<bfiller> robru: great, thanks
<robru> bfiller, you're welcome
#ubuntu-ci-eng 2014-03-01
<bzoltan> hello folks... would anybody be here to reconfigure the silo13? Set an other strange conflict ...
<bzoltan> robotfuel: cyphermox, rsalveti ^
<ogra_> bzoltan, heh, good luck with getting any landings on the weekend
<bzoltan> ogra_: I am not after landing ... but to get a bloody non conflicting build in the Silo
<bzoltan> ogra_:  :) that is the fun part ... all MRs were tested, gave green and merged without conflict locally
<ogra_> well, there are simply no propoer plans for driving the silos on weekends yet
<ogra_> (i brought that up last week, but there is no solution atm)
<bzoltan> ogra_: I do not hav high expectations :)
<bzoltan> ogra_: btw, would you reconfigure it? If that is what it needs...
<asac> cyphermox: want to help a citrain?
<asac> emergency landing?
<asac> cyphermox: dont worry
<asac> we wait till monday (in case you read this)
<bzoltan> whoever reconfigured my silo :) thank you a lot ...
<bzoltan> does anybody know what that means http://162.213.34.102/job/landing-013-3-merge-clean/13/console
<rsalveti> === Building image 215 ===
<bzoltan> rsalveti:  do you know what that error is about?  ^^
<sil2100> mandel: hi!
<sil2100> mandel: regarding that broken u-d-m - does the branch attached to the bug fix the problem?
<sil2100> asac: I'll try to do an emergency landing ASAP
<sil2100> popey: ^
<popey> sil2100: no idea.
<popey> sil2100: i can test if someone can build me a deb or whatever?
<sil2100> popey: I'll test it as well, I'm building it in a silo now
<sil2100> popey: would appreciate your help
<sil2100> Major fuckup from my side
<popey> sil2100: No problem at all. Lets focus on getting it fixed and tested and not dwell on who broke it.
<popey> sil2100: my device is on 212 right now, should I update to 214 and then await a ppa?
<sil2100> I guess 214 might be a good idea, as it's broken
<popey> kk
<popey> doing now
<cjwatson> woo, finally all tests passing on my libclick branch
<cjwatson> might not be too far away now ...
<popey> sil2100: just ping me when you need something, I'm afk but I get pinged from highlights
<sil2100> popey: ppa:ci-train-ppa-service/landing-004 <- PPA link!
<sil2100> It's built
<popey> sil2100: ok
<popey> sil2100:  you planning on doing ap tests?
<sil2100> popey: dogfooding for sure, not sure if we have AP tests for this?
<popey> no idea
<popey> root@ubuntu-phablet:/# apt-cache policy ubuntu-download-manager
<popey> ubuntu-download-manager: Installed: 0.3+14.04.20140224-0ubuntu1 Candidate: 0.3+14.04.20140301-0ubuntu1
<popey> sil2100: testing installing a new click package and using update manager, both work with that ppa installed
 * popey tests a bit more
 * sil2100 reboots after an upgrade
<sil2100> popey: can you try the update tests from https://wiki.ubuntu.com/Process/Merges/TestPlan/ubuntu-download-manager as well?
<popey> sil2100: ok
<sil2100> popey: thanks!
<sil2100> So far so good on my device as well
<popey> sil2100: hm, i cant do 3g test, no 3g data on this sim
<sil2100> popey: then WiFi should be enough, I'll do 3G data test otherwise
<popey> thanks
<sil2100> hmmmm
<sil2100> Crap, 3G downloading doesn't seem to work ;/
<sil2100> Let me revert and see if it worked in the past
<popey> you sure you have data available on your sim? not run out of allowance?
<sil2100> Webbrowser works fine
<popey> ok
<sil2100> And I'm pinging stuff fine
<popey> worth checking â»
<sil2100> But the script for downloading just doesn't work ;/ While it works on WiFi
<sil2100> I'll retry the test
<sil2100> geh
<popey> wassup?
<sil2100> So, it seems that strangely now switching from 3G to WiFi (and the other way around) breaks the downloading - at least it seems so
<popey> sounds like that problem I reported in browser
<sil2100> I would say this: I'll fill in a bug but land this anyway
<sil2100> ralsina_: ping
<popey> sil2100: i have re-triggered bug 1277589
<ubot5> bug 1277589 in Ubuntu system image "Better protection against concurrent access" [Critical,Fix released] https://launchpad.net/bugs/1277589
<popey> (while testing your u-d-m update"
<sil2100> Crap
<sil2100> So, it's reintroducing a regression, yes?
<popey> however
<popey> no
<popey> i downgraded u-d-m and it still happens
<sil2100> Ah, but you downgraded to which version?
<popey> i just think that bug isn't fixed - separately from your u-d-m issue
<sil2100> The archive has a broken one
<popey> "This bug was fixed in the package ubuntu-system-settings - 0.1+14.04.20140218.1-0ubuntu1
<popey> "
<sil2100> popey: to which you downgraded?
<popey> no, hang on...
<popey> I update to your new u-d-m
<popey> triggered the above bug, thought "uh-oh" so I downgraded u-d-m back to the one in #212
<sil2100> Oh
<popey> to make sure that didnt re-introduce it
<popey> and I can trigger the above bug again on #212 stock
<sil2100> And it's there, right? 212 seems to have the 'right' version
<sil2100> Ok
<sil2100> phew.
<popey> yes, 212 has the right version, but its still broken
<popey> sorry, shouldn't have mentioned it â»
<popey> it's clouding the conversation â»
<popey> just going to do one more test of your u-d-m upgrading from 212 to 215
<sil2100> :)
<sil2100> \o/
<sil2100> If it goes good then let's release
<sil2100> \o\
<popey> k
 * sil2100 keeps his fingers crossed
<popey> sil2100: ok, i upgraded over wifi and it worked fine with your u-d-m, and I did the other tests for installing click packages too
<sil2100> popey: awesome, thanks for the help man ;)
<sil2100> Let's get this published
<popey> np
<popey> thanks for jumping in to fix
<popey> sil2100: its a shame 215 was so recently triggered, will this be in the 3am image?
<sil2100> popey: I guess so
<sil2100> popey: I don't have the power of triggering image builds, so we'll have to wait for the next tick
<popey> sil2100: rsalveti can
<sil2100> popey: you can try poking him if he's around ;) But first wait until it hits the archive properly!
<sil2100> Sicne it's probably still in -proposed
<popey> well right now 215 is still being qa'ed
<popey> http://ci.ubuntu.com/smokeng/trusty/touch/
<popey> so would be preferable to leave it some time. and as it's saturday, might be prudent to just wait for the 3am kick, or piggyback on another image that someone else may kick for whatever reason
<ogra_> want an image build once it is in ?
<popey> unconvinced it's worth it, what do you think ogra_?
<ogra_> who built 215 ?
<popey> ricardo
<popey> 2.5 hours ago
<ogra_> ah, yeah, i see it in the backlog
<ogra_> yeah, then testing will still take 3-4h for it
<ogra_> which means if i built then 216 will clash with 217 testing
<ogra_> so lets juts leave it to cron (3am UTC)
<ogra_> else we will only get messy test results in the end
<popey> +1
<popey> sil2100: want to reply to that mail on the list letting everyone know?
<sil2100> popey: to which mail?
<sil2100> popey: I already sent out an info that we did that landing and the next image should be ok
<sil2100> To the ML
<popey> cool
 * ogra_ sent a followup about the images
<popey> i hadn't seen it, sorry
 * ogra_ goes back to watch snooker :)
 * popey goes back to portal 2
<popey> *on* *linux* :D
<sil2100> :D
<sil2100> Ok, I see u-d-m is ready for migration, so I go now
<sil2100> See you on Monday! (hopefully)
<ogra_> rsalveti, wow, ofono is seriously broken (at least on e.crash from the scripts per test ... some have two)
#ubuntu-ci-eng 2014-03-02
<rsalveti> ogra_: seriously?
<rsalveti> yeah, quite a few crashes, weird
<rsalveti> wonder if it's only broken with phonesim
<asac> rsalveti: online :)?
<asac> guess same idea
<asac> hehe
<asac> rsalveti: is the other sim still on the table?
<rsalveti> actually, just 2 crashes it seems, maybe related with some python 2 specific code still
<rsalveti> as it's not really ofono
<rsalveti>  dbus.exceptions.DBusException: org.ofono.Error.Failed: Operation failed
<rsalveti>  dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name org.ofono was not provided by any .service files
<asac> rsalveti: stop working :)
<asac> not productive
 * asac goes off
<bzoltan> ogra_:  do you know what the hack causes this -> http://162.213.34.102/job/landing-013-3-merge-clean/ ?
<rsalveti> 2014-03-02 11:34:58,300 DEBUG Copying configuration from /srv/juju/vol-0000011d/var/lib/jenkins/silos/landing-013/config to /var/lib/jenkins/status/landing-013
<rsalveti> 2014-03-02 11:34:58,300 ERROR Last step didn't finish successfully. You need to either ignore that the previous step didn't finished successfully or ensuring that prepare, build and checked passed.
<rsalveti> maybe you need to build it again?
<rsalveti> no, same error
<rsalveti> not sure why then
<bzoltan> rsalveti: thanks for checking it out ... I have no idea what the error means
<Laney> bzoltan: err, it means that the silo hasn't been published, right?
<Laney> https://launchpad.net/ubuntu/+source/ubuntu-ui-toolkit
<bzoltan> Laney: yes
<Laney> so you need to do that before you can do the last step
<bzoltan> Laney:  So I can not merge to the trunk before it gets published?
<rsalveti> bzoltan: no, first published, then you merge
<bzoltan> rsalveti: OK, thanks
<bzoltan> rsalveti: what does it take to get that MP published?
<rsalveti> bzoltan: well, you need to publish your silo, once the packages are in the distro, you hit merge & clean, which will get your MR merged
<bzoltan> rsalveti:  I can not publish the silo as far as I know... or can I?
<ogra_> wow, that email client works already pretty well
<bzoltan> rsalveti: I am a low life lander of the SDK :)
<ogra_> oops, wrong channel :P
<Laney> bzoltan: you need a core-dev or lander to publish it
<Laney> s/lander/landing team person/
<bzoltan> Laney: I know .. that is why I am here :)
<bzoltan> Laney: I know my chances are low today :)
<Laney> I could do it, don't know if I'm allowed to though
<Laney> might be best to wait
<bzoltan> Laney: you know better the rules than me :)
<rsalveti> bzoltan: which silo, 13?
<bzoltan> rsalveti: yes
<rsalveti> bzoltan: did you test and validate the changes already?
<bzoltan> rsalveti: yes
<rsalveti> bzoltan: publishing
<bzoltan> rsalveti: thank you!
<bzoltan> rsalveti: it is cool that my boys will have clean trunk tomorrow morning
<rsalveti> :-)
<Laney> I was scared by the degraded mode thing
<Laney> but good that someone else wasn't :P
<ogra_> heh
<ogra_>  7666 phablet   20   0  355452  88588  44532 R 103.6  4.8   2:42.59 ubuntu-email-client
<ogra_> 103%
* cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CITrain support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Landing instructions: http://goo.gl/8H1Du3. Landing in degraded mode (see http://goo.gl/J1EqPW) | Known Issues: -
#ubuntu-ci-eng 2015-02-23
<imgbot> === IMAGE 109 building (started: 20150223-02:05) ===
<imgbot> === IMAGE RTM 242 building (started: 20150223-03:05) ===
<imgbot> === IMAGE 109 DONE (finished: 20150223-03:25) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/109.changes ===
<imgbot> === IMAGE RTM 242 DONE (finished: 20150223-04:15) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/242.changes ===
<sil2100> Saviq: https://code.launchpad.net/~unity-team/unity8/rtm-20150213/+merge/249680 <- can this get top-approved?
<ogra_> grmpf ...
<Mirv> Saviq: https://code.launchpad.net/~unity-team/unity8/rtm-20150213/+merge/249680 is unapproved
<sil2100> cihelp: we're missing tests from recent ubuntu-rtm run of 242 in krillin
<sil2100> cihelp: http://rtm-dashboard.ci.ubuntu.com/smokeng/utopic/touch_stable/krillin/242:20150223:20150216-fe747ac/346/ - did some machine go offline?
<psivaa_> sil2100: let me take a look
* Laney changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: -
<psivaa_> sil2100: The phones could not get to 'http://derived.archive.canonical.com/' during a couple of runs. Looks like a temp network glitch. I've kicked the failed ones off for now. will check on that in a bit
<sil2100> psivaa_: thanks!
<sil2100> jibel: ^
<sil2100> john-mcaleely: hey! Give us a sign whenever you get any reports of criticals from the client ;)
<john-mcaleely> sil2100, ack
<ev> psivaa_: is this in an apt-get update? Could we do the apt-get update || apt-get update || apt-get update trick?
<psivaa_> ev: yep, possibly. looking into it
<ev> thanks!
<mzanetti> trainguards: I'd need a reconfig of silo 0. added an ubuntu-ui-toolkit branch
<sil2100> mzanetti: on it
<mzanetti> sil2100: thank you :)
<mzanetti> sil2100: can you translate that for me? https://ci-train.ubuntu.com/job/ubuntu-landing-000-1-build/339/console
<sil2100> mzanetti: it seems someone made a direct upload to the archive of UITK
<mzanetti> hmm... ok
<sil2100> Let me check
<mzanetti> that means I could just drop that branch again
<mzanetti> does it?
<sil2100> hmmm
<sil2100> mzanetti: it's a bit strange that you try to build a merge that's targetting the staging branch
<sil2100> This can also cause some additional problems, as now there's more version mismatches
<mzanetti> ah... right
<Mirv> uitk staging shouldn't be used as landing target, correct
<sil2100> mzanetti: since trunk https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk has all the versions, and staging is missing many many commits it seems
<Mirv> trunk's changelogs are only occasionally merged to staging
 * mzanetti confused
<mzanetti> sil2100: anyways, seems I need to cherry-pick that commit to a branch against trunk and then add it to the silo
<mzanetti> will do
<mzanetti> thanks
<jibel> pete-woods, I failed silo 7, and switching from French to English messages are still in French. If I take a new photo when the device is in English then the message for the recorded video is translated to English but the message for new photos is still in French.
<jibel> -and
<pete-woods> jibel: as I probably didn't  mention. this requires changes to the apps also, they currently are not doing the correct thing. we will also need to update photos and and music app
<pete-woods> but those apps are click packaed, and I don't know how to put them in the silo
<pete-woods> jibel: I can provide an updated .click for the music app to test against, if that would help?
<rvr> dbarth__: Silo 4 + silo 8 failed. "Unable to dispatch url 'intent://" ...
<rvr> dbarth__: https://pastebin.canonical.com/126099/
<jibel> pete-woods, can you provide an update for the music-app, if it works I'll pass the silo
<mzanetti> trainguards: a silo for unity8, row 65 please.
<sil2100> mzanetti: on it!
<mzanetti> thanks :)
<sil2100> bfiller: hey! Could we get this approved somehow? https://code.launchpad.net/~boiko/history-service/rtm-remove_obsolete_tools/+merge/247179
<mzanetti> sil2100: I just approved the branch in silo rtm/20. sorry for that :/
<sil2100> mzanetti: thanks :)
<dbarth__> rvr: checking
<Mirv> sil2100: hmm, was rtm 005 still on the ones to be landed, now I forgot already? I've run my AP test suite with that, but I'm wondering whether I'll ask ric to have the actual upstream bug test on it or whether it will be forgotten?
<pete-woods> jibel: https://www.dropbox.com/s/1jonik2nlo0yebr/com.ubuntu.camera_3.0.0.519-foo_armhf.click?dl=0
<pete-woods> an updated camera app
<pete-woods> jibel: you need to run it at least once, so that the infographics db gets updated
<jibel> pete-woods, OK, thanks. I'm trying it now.
<pete-woods> but after that you should see the picture count on the greeter update after only updating the language. i.e. won't have to start the app
<pete-woods> I've just tried it on my device, so reasonably confident it works :)
<jibel> pete-woods, it's all good. I tried with en, fr and es. Are there bugs for the click packages?
<pete-woods> jibel: I've just linked them all under that central bug
<pete-woods> maybe should split?
<pete-woods> I've linked my camera app branch to the bug
<jibel> pete-woods, that's fine but I just see a task for the music-app, there should be a task for the camera app too.
<pete-woods> jibel: added :)
<jibel> pete-woods, ah perfect, that's why it didn't want me to add one :)
<om26er> alex_abreu, Hi!
<alex_abreu> om26er, hi :)
<om26er> alex_abreu, re: silo13, one of the packges in the ppa is already obsolete as a later version was uploaded to ubuntu-rtm. Can you see if the silo is in its expected form ?
<om26er> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-013/+packages
<alex_abreu> om26er, echking
<alex_abreu> om26er, I think it needs a reconfigure ... sorry, one of the package in the ppa is not there anymore in the MR lists for the silo :/ (the html5 one)
<alex_abreu> om26er, the only bit that should land is the webapps-qml one
<om26er> alex_abreu, hmm, well that means the silo is good to go for testing since installing the silo wont pull the html5 package
<alex_abreu> om26er, so it is then :)
<Mirv> jibel: the bug of unity-webapps-qml in rtm-010 still has no target or tags, the trello comment says "OK, but ask Pat to add a milestone." -> me not 100% sure whether to publish
<jibel> Mirv, wait for Pat to confirm that it is wanted in RTM then publish
<Mirv> ok
<Mirv> jibel: where is om26er? he moved rtm-013 to under testing 20mins ago, but I've just checked that silo is unusable because of both rtm-010 landing and ubuntu-html5-theme outdated. I added a note to the spreadsheet and trello.
<jibel> Mirv, I don't know, he is not on any IRC channel
<Mirv> so it seemed, so those notes will need to be enough
<jibel> Mirv, I moved the card back to need qa sign off
<jibel> and blocked
<Mirv> jibel: thanks
<Mirv> dbarth__: alex_abreu: ^ see above for rtm-013 discussion. since rtm-010 is landing unity-webapps-qml would need a rebuild after 010 has landed, and ubuntu-html5-theme is already outdated in the 013 PPA due to some earlier landing
<alex_abreu> Mirv, yeah, silo 13 should not contain html5 bit, it should be reconfigured, ... and rebuilt yes
<alex_abreu> Mirv, could you reconfigure it? ... I'll wait for silo 10 to land before building
<Mirv> alex_abreu: reconfig + ubuntu-html5-theme removal done, and ok, thanks!
<alex_abreu> Mirv, thx !
<Mirv> jibel: since sil2100 is away, I'll ask you whether you mentioned rtm-005 (qtdeclarative) being still planned to land or not? I've done regression testing and wondering whether to ping ricardo to do the actual bug fix testing so that we could at some point mark it as being upstream tested.
<jibel> Mirv, we'll defer this silo
<sil2100> Mirv: I'm here, but deep in code (when not preparing lunch)
<sil2100> Mirv: as jibel said, on the meeting it was set as skipped
<Mirv> jibel: sil2100: ok, thanks, I was a bit already under that impression based on earlier discussion.
<Mirv> sil2100: just go back, then :)
<dbarth__> Mirv: want me to rebuild silo 010?
<Mirv> pmcgowan: morning. rtm fix for bug #1409051 is QA sign-off:d but with a note "OK, but ask Pat to add a milestone.", and the bug still lacks the milestone (or a mention that do not land)
<ubot5> bug 1409051 in unity-webapps-qml "When using a webapp-properties file for an unamed webapp the user script does not get injected" [High,In progress] https://launchpad.net/bugs/1409051
<Mirv> dbarth__: no, don't touch! :) 013 was the to-be-rebuilt after 010 lands.
<Mirv> dbarth__: and alex said he'll handle it
<pmcgowan> Mirv, ok will do in a min
<dbarth__> Mirv: ah sure, sorry; ok 13 and alex_abreu doing it
<bfiller> sil2100: approved the MR for silo 16
<pmcgowan> Mirv, done
<Mirv> thanks
<Mirv> ogra_: can you ack oxide 1.0.0 -> 1.3.0 dep change? https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-010-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity-webapps-qml_0.1+15.04.20150213~rtm-0ubuntu1.diff
<sil2100> bfiller: thanks!
<sil2100> Let me publish
<sil2100> mandel: hey! How's work on rtm silo 000 going?
<ogra_> Mirv, ack
<Mirv> thanks
<mandel> sil2100, blocked due to the fact that the fix makes other, already present bugs, more obvious :-/
<mandel> sil2100, so  I have to fix 2 more bugs, if it is needed, release it and I'll required another one
<sil2100> mandel: ok
<sil2100> mandel: thanks for the info
<mandel> sil2100, sorry if it was not early enough
* plars changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping plars | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: -
<sil2100> cihelp: hey! I noticed that we're missing around 300 tests for krillin vivid rests on the smoketesting dashboard: http://rtm-dashboard.ci.ubuntu.com/smokeng/vivid/touch/krillin/120:20150223:20150210-95b6a9f/347/
<sil2100> plars: can you take a look what happened? ^ :)
<plars> sil2100: will do, give me a moment - dealing with several fires at the moment
<sil2100> Sure, not a top-priority
<balloons> popey, I'm looking at things myself for the moment since plars is quite busy it seems :-)
<balloons> happy monday plars. I'm looking for some help on the terminal core app jobs. I was hoping you could check the job parms for me. It seems some of the jobs are pulling from lp:ubuntu-terminal-app while others pull from lp:ubuntu-terminal-app/reboot.
<elopio> sil2100: do you know if there's something in the dashboard autopilot tests that still needs py2?
<plars> balloons: give me a moment
 * davmor2 hugs popey
<popey> sil2100: can you provide me links to all dashboards where I can see AP status? I have seen various links to numerous dashboards, but I don't know which ones you guys look at, which ones QA gate on.
<plars> sil2100: it looks like one of them failed to unlock during the ubuntu-system-settings tests, and the other timed out - let me retry those two sets completely
<plars> balloons: so istr that we were asked a while back to enabled testing on the reboot branch, but also leave the testing on the original branch
<plars> ah, it looks like maybe fginther was already looking at this from the backscroll
<balloons> plars, yes I believe that is correct.. Now the "reboot" branch is trunk so everything can/should simply point to it
<plars> balloons: ok, unless he's done it already I'll push a branch to remove the reboot one then
<sil2100> popey: so, for per-image-based test-results the most important links are here: https://wiki.ubuntu.com/LandingTeam/Smoketesting
<sil2100> popey: normally I would say to look at krillin ubuntu-rtm, but I suppose with the focus switch to vivid we would also like to have it working for krillin vivid
<sil2100> plars: thanks!
<sil2100> elopio: sadly, I have no information on that
<popey> thanks sil2100
<jgdx> cihelp: is there a sim card in makos that we run AP tests on?
<plars> jgdx: no
<jgdx> plars, thanks.
<fginther> plars, I've manually disabled the ubuntu-terminal-app-reboot jobs until you're able to make that MP
<plars> fginther: thanks, one sec
<robru> kenvandine: around for a packaging ack? https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-017-2-publish/22/artifact/
<jibel> bfiller, ^ camera is OK to land
<sil2100> \o/
<jibel> bfiller, the camera crashes sometimes (it starts but takes a moment while apport is generating the crash file) but it's already a problem with build 3.0.0.484. So not blocking on it and trying to find the root cause.
<bfiller> jibel: ok thanks, is there a bug for the crash?
<jibel> bfiller, I can file a bug "the camera crashes randomly" but not really useful until we find rough steps to reproduce.
<jibel> bfiller, I gave the crash file to Kaleo if he can get anything useful out of it
<bfiller> jibel: thanks
<bfiller> jibel: so I will push a new click package into the store then for camera
<jibel> bfiller, OK. ui-extras0.2 must be seeded for the editor, and the editor translated.
<robru> brb
<rvr> Kaleo: ping
<bfiller> jibel: I'll take care of that
<rvr> bfiller: Kaleo: Silo 17 needs a pot update for camera app, as it contains a new string, "Edit"
<bfiller> rvr: Kaleo you can push the updated pot file to trunk
<Kaleo> rvr: on it
<rvr> Nice
<rvr> dbarth__: alex_abreu: With Google Maps installed, intent works ok
 * ogra_ watches Kaleo stirring the pot
<Kaleo> bfiller, rvr: pot file updated in trunk
<rvr> Perfect
<Kaleo> (push is taking its sweet time)
<alex_abreu> rvr, awesome
<rvr> alex_abreu: Does silo 4 need additional testing?
<alex_abreu> rvr, mmmh which one is silo 4?
<rvr> alex_abreu: url-dispatcher
<rvr> alex_abreu: I was told to test 8+4 in the same batch
<rvr> tedg: ^
* plars changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: -
<alex_abreu> rvr, mmh isn't it a dup of silo 8?
<alex_abreu> rvr, yeah it is ...
<rvr> Meh
<alex_abreu> rvr, so my guess is that we should remove silo 4 (L13)
<rvr> alex_abreu: Ok, I'll approve silo 8
<rvr> Hmm.. actually, I'm going to recheck
<alex_abreu> rvr,  :)
<alex_abreu> ok
<dbarth__> rvr: \o/
<rvr> dbarth__: alex_abreu: Approved
<bfiller> kenvandine: can you ack the packaging changes in rtm 17 please?
<kenvandine> bfiller, i'll look
<kenvandine> bfiller, ubuntu-ui-extras is removing quite a few depends
<tedg> alex_abreu, Saw some pings while I was at lunch, all good?
<alex_abreu> tedg, yup ... all good
<kenvandine> bfiller, was the libaccounts and libnotify build depends just for the old share component?
<bfiller> kenvandine: yes I think so
<kenvandine> -         libqt5sql5-sqlite,
<kenvandine> -         libqt5webkit5-qmlwebkitplugin,
<kenvandine> bfiller, i guess that is from the browser component switching to oxide?
<kenvandine> at least the webkit dep
<bfiller> kenvandine: right, though not sure why we ever depended on webkit for the share stuff
<kenvandine> it wouldn't have been for the share stuff
<kenvandine> i assume this is just cleaning up cruft
<bfiller> kenvandine: but clearly don't need it anymore for the editor component
<bfiller> kenvandine: yup, old cruft
<kenvandine> there are other depends for libqt5sql5-sqlite, so at least it won't be removed from the image because of this
<kenvandine> ok... +1 from me
<kenvandine> robru, +1 on packaging changes in rtm 17
<robru> kenvandine: thanks!
<bfiller> kenvandine: thank you
<kenvandine> np
<kenvandine> rsalveti, you still have that bt agent_rework branch in silo 18
<rsalveti> kenvandine: hm, lemme look at that
<kenvandine> rsalveti, it isn't built atm...
<kenvandine> i think it was just hard to find someone that could test it
<rsalveti> kenvandine: yeah, let me give this another shot now
<rsalveti> kenvandine: ping you back in ~3h
<kenvandine> rsalveti, thx!
<bfiller> popey: new camera-app uploaded to store, please review when you can
<bfiller> rsalveti: we are (finally) read for seed change to rtm to add qtdeclarative5-ubuntu-ui-extras0.2
<rsalveti> bfiller: RTM, right?
<bfiller> rsalveti: yeah, already in vivid
<rsalveti> bfiller: sure, let me take care of that
<bfiller> rsalveti: thanks
<kenvandine> rsalveti, definitely ping me, i have another conflicting silo building as well, but if you can verify that silo 18 passes, i'll land that one first
<rsalveti> kenvandine: sure
<popey> bfiller: done.
<bfiller> popey: thanks
<popey> np
<bfiller> robru: I need to add telepathy-ofono to silo rtm 11, but it just needs to be a no-change rebuild. what's the best way to do that?
<bfiller> it has to be rebuilt against telepathy-qt5 which is in silo 11
<robru> bfiller: branch lp:telepathy-ofono somewhere you own, then propose it for merging back into itself. it'll make an empty merge, you can add that to the spreadsheet and i can reconfigure it.
<bfiller> robru: https://code.launchpad.net/~bfiller/telepathy-ofono/no-change-rebuild/+merge/250674 added to spreadsheet
<robru> bfiller: ah thanks. which row?
<bfiller> robru: 44
<fginther> kenvandine, I see the ubuntu-system-settings tests are passing again. Do you know if there was a specific problem that was causing the app startup failures?
<robru> bfiller: ok, reconfigged, if you hit build it should do the right thing
<bfiller> robru: cool
<kenvandine> fginther, yeah, kind of
<kenvandine> fginther, we had a test that was blowing up because we think it caused a conflict with other stuff using the session bus
<kenvandine> once it blew up, everything after it blew up too
<kenvandine> we removed the offending conflict, which got everything passing again
<kenvandine> fginther, however, jgdx is still working on figuring out a proper fix so we can add the test back
<kenvandine> it was introduced by a change in uitk, that was making it require a session bus to look for a setting
<fginther> kenvandine, well, glad you at least found the problem
<kenvandine> which then caused our's to fail to get the session bus, something along those lines :)
<fginther> kenvandine, and thanks for the update
<robru> rsalveti: hm, no qa for powerd? ;-)
<rsalveti> robru: nops, enabling debug by default (upstart), so we can debug another issue
<kenvandine> fginther, it was pretty frustrating to chase down, but it's nice to see green again :)
<rsalveti> to be reverted before the next milestone
<robru> rsalveti: ah ok, no worries
<fginther> kenvandine, understandable. I'm trying to document this a little so that we have some better approaches to handling problems like these in the future. Not sure anything useful will come of it, but we may be at least be able to offer better advice
<kenvandine> fginther, indeed, problems like this one end up consuming so much time just trying to understand it
<robru> awesome.
<kenvandine> rsalveti, i went ahead and published 25, i'll kick a rebuild of 18 after it merges
<kenvandine> rsalveti, it won't affect your testing of 18 though
<kenvandine> it was AP only
<rsalveti> kenvandine: oh, great, was just testing it
<kenvandine> rsalveti, sorry, wasn't sure ;)
<kenvandine> but it won't affect you, if you mark it as passed
<rsalveti> kenvandine: no worries :-)
<kenvandine> i'll publish it after it rebuilds
<rsalveti> crap, thunderstorm, might get offline
<robru> whoa, only 1 free silo. crazy
<rsalveti> yay, crash in system settings
<rsalveti> some bt devices are almost impossible to connect with mako
#ubuntu-ci-eng 2015-02-24
<kenvandine> rsalveti, so is that a no on silo 18?
<kenvandine> rsalveti, my silo 25 landing is a bit stuck, held in proposed
<rsalveti> kenvandine: yeah, when testing silo 18
<rsalveti> kenvandine: taking longer than expected, can't easily connect with a few bt devices I have
<rsalveti> have to check individually if that could have caused a regression or not
<imgbot> === IMAGE 110 building (started: 20150224-02:05) ===
<kenvandine> rsalveti, ok, thx
<kenvandine> GRRR
<kenvandine> Setting up python3-distupgrade (1:15.04.8) ...
<kenvandine>   File "/usr/lib/python3/dist-packages/DistUpgrade/DistUpgradeViewKDE.py", line 37
<kenvandine>     from PyQt5.QtGui import QTextOption, QPixmap, QIcon,
<kenvandine> SyntaxError: trailing comma not allowed without surrounding parentheses
<kenvandine> settings held up in proposed because whatever package that provides that keeps getting uploaded with silly python syntax errors
<imgbot> === IMAGE RTM 243 building (started: 20150224-03:05) ===
<imgbot> === IMAGE 110 DONE (finished: 20150224-03:30) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/110.changes ===
<imgbot> === IMAGE RTM 243 DONE (finished: 20150224-04:15) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/243.changes ===
 * Mirv kicked some autopkgtests ^
<didrocks> cihelp: hey! I'm looking back since the CI move in december) to the new infra for ubuntu make tests and ps-trusty-desktop-i386-1 is down (disconnected in s-jenkins), any chance to get it back up?
<didrocks> the job that reverts the vms are connecting to naartjie, but since the move to the new vpn, I wonder how to connect to itâ¦ (ssh naartjie doesn't work anymore, I guess it's a domain issue)
<didrocks> ok, seems that I could restart it myself adding .ubuntu-ci, thanks nevertheless
<ev> ah, was just looking
<ev> making a note to have a nagios alert for that
<didrocks> ev: oh, that would be awesome, for $random reason, they were failing to restart jenkins-slave like once a week
<didrocks> ev: btw, as I can restart the machines, do you mind if I create a newer snapshot? The current one is really old and dist-upgrade takes 40 minutes
<ev> go for it
<didrocks> thanks, I was wondering if disk space would be impacted
<ev> 411G free
<didrocks> should be enough :p
<didrocks> thanks!
<ev> didrocks: can you tell me a little bit more about exactly what was failing and for how long, and how this impacts you? You got in there a bit quicker than I could dig :)
<ev> and I need to write this up in a way that points at the bigger problem
<didrocks> ev: oh sure, basically since the new config in december, I was wanting for the vms to be up again to have my daily tests of ubuntu make running against trusty (trunk and trusty packages). This wasn't a big issue as I tend to run them manually myself as well and my connexion is quite good.
<didrocks> ev: those machines are updating to latest trusty, running tests, and then reverting to the snapshot + rebooting
<didrocks> ev: I know they are temporary solutions until you have a better way to tests things which needs a GPU + hw acceleration
<didrocks> basically, the issue was the with the old vpn setup, I was able to ssh to naartjie directly (as the added domain with .ubuntu-ci)
<didrocks> to restart the vm myself
<didrocks> so, now, I just need to add the domain myself
<Mirv> cihelp: sil2100: in SDK team we noticed mako UITK results regressing after 20150212, but since krillin didn't regress it does not look to be landing specific (and certainly not UITK landing), so does anyone know how mako broke on those Thu/Fri landings?
<Mirv> or if it was landing specific, then it would have been mako only landing. but I was thinking maybe something in mako testing changed.
<Mirv> cihelp another topic, SDK team had last successful merge to uitk staging on Friday, but after that we're getting constantly ~40 failures, and again we're puzzled and have no idea how is that. see for example https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/82-dragging-mode/+merge/246128 but also in any "no-op" branch MP.
<Mirv> sorry for spamming with multiple things, but just queue them up :)
<Mirv> the "no-op" branch would be eg https://code.launchpad.net/~timo-jyrinki/ubuntu-ui-toolkit/clean_up_build_dependencies_cruft/+merge/249461
<Mirv> earlier failures in that branch was a different thing that got fixed, but then I didn't retry until it was too late..
<oSoMoN> trainguards: Iâll need a binary copy of oxide-qt from https://launchpad.net/~phablet-team/+archive/ubuntu/ppa/+packages to silo 3 (version 1.5.3-0ubuntu2 removes the build dep that was in universe)
<Mirv> oSoMoN: ok, note that you unfortunately would need to file FFe as well as per latest mailing list discussions, not having the blanket FFe (+ Oxide is on desktop anyway)
<Mirv> since FF was last Thu
<oSoMoN> Mirv, right, will do that. no need for the FFe for the copy to happen though, right? it will only block actual landing, right?
<Mirv> oSoMoN: exactly
<oSoMoN> good
<oSoMoN> trainguards:Â can I have a silo assigned for line 49, please?
<Mirv> oSoMoN: on those, finished a meeting
<Mirv> mvo: not top-approved https://code.launchpad.net/~click-hackers/click/devel/+merge/250584
<Mirv> mvo: if you don't use such a process, then just top-approve yourself
<mvo> Mirv: thanks, I will top-approve myself, there is a bit of a reviewer shortage for click currently
<psivaa_> Mirv: let me look at your pings
<Mirv> psivaa_: thanks :) no hurry, but both seem real problems SDK team itself does not have power upon
<Mirv> mako being broken in general or MP:s having problems after Friday
<Mirv> sil2100: focus is on vivid alright, we're out of silos! :)
<psivaa_> Mirv: http://ci.ubuntu.com/smokeng/vivid/touch/mako/101:20150216:20150210/12311/ubuntuuitoolkit/ suggests uitk has been failing earlier than Thurs/ Fri on smoke
<Mirv> psivaa_: ok. how did then eg https://code.launchpad.net/~seb128/ubuntu-ui-toolkit/gettext-application-name/+merge/249665 land on Friday?
<Mirv> psivaa_: or https://code.launchpad.net/~aacid/ubuntu-ui-toolkit/nonsquareicons/+merge/250110 - all of those seem to have first failure then some "without results" PS Jenkins bot continuous-intregration approve?
<psivaa_> Mirv: that's worrying
<psivaa_> Mirv: not sure who/ how that was possible
<psivaa_> Mirv:  I dont think we could do anything about the failures, but i'll certainly raise it to the team to see how that was 'Approved' by PS-jenkins-bot
<Mirv> bzoltan_: ^ some news at least. it'd look like the last week's landings got in "by mistake", sort of, via erronous mystery Approve from CI, and now they are back to failing because tests fail on mako
<Mirv> psivaa_: so, it's possible that from our side the core problem is that mako is broken, and not because of UITK but something else, since 20150212
<Mirv> psivaa_: notably the tests don't fail on krillin, and there was no change on krillin on that date when mako started failing
<ricmm> Mirv: hey, still missing line 51
<Mirv> psivaa_: thanks for investigating, now in general we have the problem "mako is broken" but not really sure who could point out in which way
<ricmm> it was two silo requests, think I could get that one going too?
<ricmm> if you dont mind
<Mirv> ricmm: yeah, sorry, we've all 31 silos in use, I'm just about to free one
<ricmm> oh, ok
<ricmm> didnt see, sorry
<psivaa_> Mirv: yea, there are a couple of things..
<psivaa_> Mirv: 1. in mako there is a qmlscene crash
<psivaa_> Mirv: 2. the tests are device specific too
<Mirv> lool: is row 7 "Fix platform-api dep to allow multiarch install for cross-builds" ok to free up, it has not been touched for 1 month 2 weeks and we are out of silos?
<sil2100> Mirv: I'll be cleaning up some silos now as well
<Mirv> psivaa_: can you give me a link to the qmlscene crash, so I can make sure there's a bug filed to whatever is causing it?
<Mirv> sil2100: thanks
<psivaa_> Mirv: https://jenkins.qa.ubuntu.com/job/vivid-touch-mako-smoke-daily/325/artifact/clientlogs/ubuntuuitoolkit/_usr_lib_arm-linux-gnueabihf_qt5_bin_qmlscene.32011.crash/*view*/
<psivaa_> Mirv: as per how to land those MP's that have the failures, i'd ask in the team if that was done by one of us and if that was done for a specific reason
<psivaa_> hmm, let me rephrase, i've combined two of my sentences there
<psivaa_> Mirv: as per how to land those MP's that have failures, i dont think we could do it in the auto-* mode (because of the failures)
<psivaa_> and as to how the MP's were allowed to land with the failures, i'd ask within the team
<Mirv> psivaa_: yes, the last week's landings shouldn't have landed, kind of, even though it's not that team that broke the mako. if it was not CI changing anything on mako, then it would have been either http://people.canonical.com/~ogra/touch-image-stats/20150213.changes or http://people.canonical.com/~ogra/touch-image-stats/20150213.1.changes that broke mako
<sil2100> lool: hey! Regarding silo 22 in vivid - there has been no movement since a month, is it ok to clear it ouot?
<Mirv> sil2100: I just asked lool like 10 minutes ago ^ :)
<lool> erf
<lool> sorry folks
<lool> I completely forgot about this silo
<lool> it's a completely risk free change (no code change), but I didn't follow the full process of testing the actual binaries, so couldn't push the publish button
<Mirv> lool: so do you want to update and work on it now? (the package itself is superseded currently)
<psivaa_> Mirv: right, something that uitk tests depend on might be causing the failures
<psivaa_> Mirv: it could be that UITK that did not 'break' mako, but it was UITK tests that were failing and in that situation UITK mps should not have been allowed to land.
<Mirv> psivaa_: yes so indeed there were no UITK changes when those mako failures appeared in UITK tests in the dashboard, and now new MP:s can't go in because something broke mako UITK tests (but not krillin) from outside of SDK. and now "just" the culprit should be found.
<psivaa_> Mirv: yep, the culprit should be found (and should have been found before force landing the MP's :))
 * Mirv is sorry he has 5 vivid silos, all for good reasons though :(
<sil2100> Mirv: ;)
<Mirv> or 6, but I'm freeing up that qtpim now that it's most probably vivid+1
<sil2100> Who would have thought that we might start being low on silos again even with 30 silos ;)
<Laney> Building more roads always leads to more cars
<Mirv> I wonder what would be the equivalent of public transport, or biking
<Mirv> I think this analogy doesn't carry to the end :)
<sil2100> Laney: actually, we built more silos which resulted in more rails and more trains driving those..!
<jgdx> I'm seeing this interesting error [1] when running phablet-test-run. All tests fail.. [1] http://pastebin.ubuntu.com/10387874/
<sil2100> mzanetti: ping
<mzanetti> sil2100: hey
<sil2100> mzanetti: so, I'm looking at the unity8 silo that's ready for vivid now
<sil2100> mzanetti: https://code.launchpad.net/~mzanetti/unity8/reveal-launcher-with-mouse-hover/+merge/248913 <- I need to double check, is that a new feature?
 * sil2100 hates the FFe in this regard
<sil2100> *FF's
<mzanetti> sil2100: well... the launcher can't be revealed by mouse... from a phone point of view it might be a new feature... from a desktop point of view it fixes the launcher...
<mzanetti> do I need to pull it out again?
<mzanetti> it's been in the silo since last week already :/
<sil2100> grrr
<sil2100> Not sure, we don't have the blanket FFe so I don't know if this won't break feature freeze
<sil2100> Let's leave it there, let me get some info
<sil2100> If anything we can just fill in a single FFe
<sil2100> It's really a bit silly to have an FFe for things like Unity8 for the desktop...
<mzanetti> yeah well... that's what it is... so if I need to pull it out again I can do so... I thought I'd give it a shot as it's a small branch and it is a fix for the desktop mode...
<Mirv> psivaa_: the qmlscene crash seems once again "something happened before this crash, hence connection rejected" which have had earlier and would need I think the upstart logs for apps from the point when it happened. bug #1425034
<ubot5> bug 1425034 in qtdeclarative-opensource-src (Ubuntu) "qmlscene crashed with SIGABRT in qt_message_fatal()" [Medium,New] https://launchpad.net/bugs/1425034
<michi> cihelp: Could someone please take a look at these failures: http://s-jenkins.ubuntu-ci:8080/job/unity-scopes-api-ci/
<michi> They are definitely not caused by problems in our code.
<cprov> michi: I am on it
<michi> cprov: Thank you!
<cprov> michi: it looks like the cloud workers are not behaving correctly, I will have to dig more to find what is wrong. Once it is sorted do I have to do anything else than retry the job ?
<cprov> michi: also, is it blocking you to do anything urgent ?
<michi> cprov: No, not really. If you could re-start the three failed jobs, that woud be great.
<michi> No, not blocking us for anything mission critical.
<cprov> michi: okay, will do, thanks for the info.
<michi> But I do wonder why the system doesnât detect that kind of failure by itself.
<michi> There is clearly some problem in the infrastructure that is unrelated to the branches we are trying to land.
<michi> But no-one seems to notice unless we shout.
<michi> How hard would it be to detect this kind of failure with robot that alerts you when something isnât working?
<Mirv> mvo: click seems to have some problems with autopkgtests http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#click
<mvo> Mirv: yeah, I just noticed that, I will do a new 0.4.38.1
<mvo> Mirv: thanks!
<mvo> Mirv: or should I do a 0.4.38 and override the existing one?
<mvo> Mirv: nevermind, I updated devel and will prepare a new release
<cprov> michi: the cloud workers and their jobs could benefit of better monitoring, then we could possibly detect some of those weird and unknown malfunctioning issues. We are working on it.
<michi> cprov: Well, it would be really nice if the system would realized when things arenât working. We have a long history of suffering from this kind of issue, going back at least 12 months. My conservative estimate is that around 50% of all our CI failures were caused by infrastructure problems.
<michi> Basically, what Iâm saying is that âCI breaks all the timeâ. Iâm sorry for being so harsh.
<Mirv> mvo: it's in -proposed so you need to bump something anyway. btw I was slightly worried about that ignore option being a new feature..
<Mirv> mvo: which would need FFe if it is
<mvo> Mirv: uh, indeed, for some reason I thought of it as a bugfix but you are right of course
<cprov> michi: well, I fully understand your complaints and it will get fixed, because we are working to mitigate the impacts on you.
<mvo> Mirv: I will ensure I get a FFe
<michi> cprov: I do appreciate the efforts, and I realize that Iâm most likely ranting at the wrong person.
<michi> But, please, if you can, pass this feedback up the chain: CI has been a long-standing problem for us, causing us many, many hours of wasted time.
<cprov> michi: I sure will.
<michi> We have no choice: we have to squeeze through the CI gate, like it or not. But that puts CI at roughly the level of importance of a compiler. If itâs broken, we are hosed.
<Mirv> mvo: thanks!
<cprov> michi: it's supposed to be like this and we should support a reliable CI infrastructure to you guys, it's on our job description ;-) With your help and feedback we will get things sorted.
<brendand> mzanetti, what's the trouble with unity8 tests?
<mzanetti> brendand: troubles?
<brendand> mzanetti, jibel said there were some dashboard failures you needed help figuring out
<mzanetti> oh... that's news to me...
<mzanetti> need to look
<jibel> mzanetti, not dashboard failures, it's related to tsdgeos reply on the ML, saying that him and you have different results for AP test of unity8 on the same devices and same code
<jibel> if we gate on automated tests, we have to understand where these failures come from
<mzanetti> jibel: well... so far this has been my experience with autopilot tests all the time
<mzanetti> they fail randomly sometimes
<mzanetti> but yeah... I have one failing test here on a device of mine which doesn't happen for tsdgeos nor in jenkins
<mzanetti> not sure yet why
<brendand> mzanetti, i'm here to help if you need anything
<cprov> michi: just double-checking, http://s-jenkins.ubuntu-ci:8080/job/unity-scopes-api-vivid-armhf-ci/121/consoleFull seems to be a legitimate test failure, correct ?
<brendand> mzanetti, is test_can_unlock_passphrase_screen the one you sometimes see fail?
<mzanetti> brendand: the one I had yesterday/today is unity8.shell.tests.test_emulators.DashAppsEmulatorTestCase.test_get_applications_should_return_correct_applications
<brendand> mzanetti, do you have a paste or link of the error?
<mzanetti> brendand: http://paste.ubuntu.com/10389462/
<brendand> mzanetti, do you observe that the device is doing when that test is reached?
<brendand> s/that/what/
<mzanetti> brendand: sorry. IRC notifications broken atm here.
<mzanetti> brendand: so I see that it tries to move the scope, but not far enough, so it snaps back
<mzanetti> so I'd know how to fix it I guess, but the question remains why it's only failing here
<mzanetti> (running on mako btw)
<brendand> indeed strange
<seb128> is the weather channel scope working for others on bq/rtm?
<ogra_> seb128, works from "today"
<seb128> not here, but I'm unsure how to debug :-/
<ogra_> does location work ?
<ogra_> might not be getting location data
<seb128> shrug
<Mirv> I have an excellent example if someone ever asks me to commit something to Qt upstream for him/her, "just one line"... https://codereview.qt-project.org/#/c/63026 - 1.5 years and counting to get that "just one line" in :)
<Mirv> bug filed against Qt 5.1.1 originally, and we've been carrying the patch since :)
<Mirv> I think now since there's even newer way of reading environment variable, it's going to satisfy everyone
 * Mirv added a FAQ to the contributing page, that should do it
<oSoMoN> trainguards: can silo 25 be published, please?
<sil2100> oSoMoN: looking o/
<mvo> so it looks like something has removed the "x" bit from the click debian/packagekit-check during a jenkins rebuild :/
<ogra_> sil2100, who will approve the FFe's for touch ?
<ogra_> i assume we dont really want to give that to the release team but  rather have the product team device
<ogra_> s/device/decide/
<ogra_> *tsk*
<ogra_> pmcgowan, ^^^
<sil2100> ogra_: normally I would say slangasek would be our man, but he still didn't comment on the blanket FFe I filled in ;p!
<ogra_> heh
<sil2100> Since he's aware of touch business and is an archive admin
<didrocks> sil2100: just a note, you need release team member, not archive admin :)
<ogra_> right, still, i think the product team should be involved in approvals
<pmcgowan> ogra_, I think we can ask for exceptions but not approve them
<ogra_> pmcgowan, well, the developer would ask for the exception ... but i think the product team has a way better overview of how intrusive a feature addition is than the release team has
<sil2100> didrocks: right ;) In any way, slangasek is the man ;p
<pmcgowan> ogra_, agreed
<sil2100> ogra_: right, but FF and FFe's are processes tightly controlled by the release team
<sil2100> ogra_: if the product team would be the one controlling that for touch, we probably wouldn't have FF at this time at all
<ogra_> sil2100, sure ... but the product team is responsible for the final product ... they should be gating FFe's
<sil2100> Since FF makes sense for the selected cycle, not for ubuntu-rtm or product release
<ogra_> well, vivid is a product release
<ogra_> and tedg sounds like he plans to file a lot of FFe's
<sil2100> Yeah, and I hope he has all of them discussed with his manager
<ogra_> i think they should be going in front of the product team first ... before they get handed to the release team
<sil2100> And the managers know best what is the current focus and what should be worked on
<sil2100> Currently all managers know that we're focusing solely on stability
<tedg> ogra_, For things like indicators, for instance, there are multiple products involved. One archive.
 * ogra_ doesnt trust managers :P
<pmcgowan> ouch
<ogra_> at least if they decide for their own team if $shiny_feature_they_promised_6_months_ago should still go in
<tedg> I think that the release team is in a good position to understand the impact of a change.
<ogra_> the release team has no clue what impact a change has to the customer or the planned product
<ogra_> only the product team gas
<ogra_> *has
<tedg> If there is different impact for different targets, the release team should be given info on that, not usurped.
<ogra_> the release team will decide from a distro POV
<ogra_> not from a product POV
<tedg> Is the disto not a product?
<tedg> You're saying they decide from the product of Ubuntu Desktop, not the product of XYZ Phone.
<ogra_> i'm not agaiinst FFe's (though it should really really be a rare exception, the release schedule is well known since months) ... but the phone is quite different from a product POV
<ogra_> which makes me think the product team should be the initial gatekeepter ... before it goes to release team
<sil2100> Well, there are different things here
<sil2100> There's vivid and there's RTM
<ogra_> tedg, right, thats what i mean
<tedg> More hoops is never a better solution :-)
<ogra_> more hoops for a super rare thing is fine
<sil2100> The release team has and might have some knowledge on the vivid product, even for touch, but RTM works different and has different timetables and needs
<tedg> FFe's aren't super rare. If nothing else, look at all the crap that landed in RTM after it was "feature froze"
<ogra_> right, we need to stop that
<ogra_> an FFe is an exception ... not the rule ...
<tedg> sil2100, Sure, so individual products can branch and control that for customer deliveries. We shouldn't impose those on the main archive.
<ogra_> if we are bound to the main archive with a product we have to
<ogra_> vivid RTM will essentially be vivid
<ogra_> which means vivid needs to be at product quality
<tedg> Sure, but there's a process so people don't rush to meet the deadline but make sure it's done. And FFe's get harder and the time goes on. I'd expect one this week to be easy to get, next harder, etc.
<tedg> ogra_, I'm confused at how you're using "product" â Ubuntu Desktop is a product to me.
<ogra_> ubuntu desktop si a different kind of product
<tedg> Do you consider it a lower quality product?
<ogra_> no, i consider it a different quality product ... it needs to fullfil completely different goals
<ogra_> desktop is a general purpose product ... if it works on 90% of the HW and 90% of the weird manually set up corner cases this is fine ... such a thing isnt possible in a phone release where people can not fix stuff following howtos etc
<tedg> But we expect to do system image based desktops here Real Soon Nowâ¢, right? Seems like system image is the difference you're making to me.
<ogra_> where did i say system image anywhere
<tedg> Certainly there is more HW variety, but we do have contracts that specify a list HW that should work.
<ogra_> i'm talking about use cases
<ogra_> i'm not even tallking about HW
<tedg> I'm confused then. I don't understand the distinction you're making.
<ogra_> i'm talking about your mom .. who might buy a phone and wont be able to follow a howto to hack the fix in she needs
<ogra_> while this is possible in the desktop case
<tedg> Well, my lawyer couldn't follow a howto in either case to fix a problem.
<ogra_> they are massively different products with massively different purpose and we need to treat them like that
<tedg> He'd probably just go buy a Windows machine if he felt he needed to do that.
<ogra_> right ... or an android phone
<ogra_> the point is that he has the opportunity to follow a hosto in the desktop case if he wants
<ogra_> he doesnt have that ability on the phone
<ogra_> *howto
<tedg> I think his ability to follow a howto on both of them is exactly the same. Or, at least, we should assume that they are.
<ogra_> especially in the case of a non rootable, fully locked down phone ...
<ogra_> how ?
<ogra_> you have no root, you have no access to the system
<pmcgowan> bfiller, tested silo 11 and it works great
<ogra_> you might not even be able to re-flash ... now dont tell me there is no difference to a desktop
<tedg> I think you respect my lawyer's technical ability more than I do. :-)
<bfiller> pmcgowan: nice
<pmcgowan> bfiller, I dont have access to the ci sheet
<bfiller> pmcgowan: I'll mark it ready for QA
<pmcgowan> bfiller, tested on mako with 195
<bfiller> pmcgowan: is that an rtm image?
<pmcgowan> yes
<ogra_> tedg, i dont care about your lawyer ... he could just ask you for help ... point is that not even you will be able too help him with a broken phone if it is locked down
<pmcgowan> bfiller, my krillin not set up for easy test right now
<ogra_> one is a consumer pproduct, the other is a general purpose product ... two different things
<tedg> ogra_, And I think we should make that same assumption for the desktop, else we're failing the general market.
<tedg> Desktops are consumer products today.
<tedg> And, they'll be more so tomorrow.
<ogra_> sure, and there sill be a different quality standard applied if you buy a dekstop with preinstalled ubuntu
<ogra_> vs what you download from cdimage
<ogra_> and install yourself
<ogra_> and thats the use case the release team cares about ...
<ogra_> not the preinstalled one
<tedg> And the OEM team takes that and prepares a golden image for a particular device.
<ogra_> see
<ogra_> so you agree the iso on cdimage is different from a properly shaped product ...
<ogra_> the point for the phone this release is that vivid *is* our properly shaped product
<ogra_> there wont be any time left to do special RTM stuff before it goes out to the manufacturer
<tedg> Then the release team needs to buy into that.
<tedg> Having two different processes won't work.
<pmcgowan> bfiller, is there somewhere to add a description of the specific test to do on that silo?
<ogra_> (there will surely be later ... but thats after we gave out the golden master)
<ogra_> tedg, the release tea doesnt know the product team reqs.
<ogra_> and shouldnt care
 * ogra_ wishes we would have stopped allowing FFe's long ago ... it used to be a very rare exception ... til uunity7 came around and teams simply ignored that an exception should be an exception
<tedg> I fail to see how the release team could successfully navigate changes going into the archive without knowing the requirements they were being measured on.
<ogra_> they are measuring based on distro reqs. not based on product reqs for a certain product for a certain vendor on a certain HW
<ogra_> and not under the aspect that you cant change the installed system ...
<tedg> Are you concerned about that being because of confidentiality or because they don't care? I don't understand why you believe those should be separate.
<ogra_> tedg, i dont say they should be separate ... what i'm suggesting is that a dev files an exception that the product team reviews ... if they approve they file an FFe that gets handed to the release team
<ogra_> so you get the review from a product POV before it goes to the distro review
<tedg> So you think that every package that goes into a product the product team should get veto over the release team?
<ogra_> for this particular usecase at this particular time, yes
<ogra_> i.e. for the case where distro = RTM
<ogra_> which we hopefully only have once
<tedg> I guess I'm a bit confused on that. You're saying that you believe in other cases the version given to a customer will be based on a release with customizations?
<ogra_> tedg, my point is that we have less than 6 weeks and that there wont be time for RTM fiddling in advance (we can only do that later)
<ogra_> tedg, so the vivid release for the phone needs to be treated like RTM
<tedg> Landing random features constantly?
<ogra_> once we have merged vivid into RTM thats indeed all different
<tedg> I'm not sure what "treated like RTM" means.
<ogra_> landing features only after review and selection
<ogra_> like we do now
<ogra_> (in RTM(
<tedg> Hmm, perhaps you have a different view than me. But I haven't seen that. All I've seen is random chaos WRT RTM.
<ogra_> the set of to-land features gets reviewed once a week by a team from landing team and product teams
<ogra_> for rtm
<ogra_> and only approved stuff lands
<sil2100> Right, for ubuntu-rtm there's usually a strict list of fixes we land with priority, all of which are reviewed by the product team and the landing team
<ogra_> as long as vivid = RTM (i.e. the next 6-8 weeks) we need to do the same in vivid imho
<ogra_> else we have no chance of delivering a product in the given timeframe
<tedg> Perhaps that meeting needs to send out minutes.
<ogra_> i thik olli_ keeps the summaries somewhere in a google site document
<tedg> So they're encrypted and hidden.
<sil2100> tedg: all the accepted fixes/changes have bugs that are marked with milestones
<ogra_> tedg, well, obviously they did their work well enbough that you didnt notice it in your RTM work
<sil2100> And the engineering managers are aware of the most critical ones of those and escalate them to developers
<ogra_> :)
<olli_> tedg, ... relax
<sil2100> ogra_: it's not in any spreadsheet right now btw. ;) There's one spreadsheet pmcgowan has, but it only overviews the 'most important ones' - launchpad bug milestones are enough to know what is worthwile to work on
<olli_> ogra_, I am not involved in that part of the product atm, pmcgowan is
<ogra_> ok
<sil2100> Just looking at the milestones and the priority of their bugs is enough
<ogra_> ok
<ogra_> oops
<olli_> no moa spreadsheets, as promised
<ogra_> that second ok i didnt type !
<sil2100> davmor2, jibel: how's testing going so far?
<sil2100> Tell me, how bad is it?
<jibel> sil2100, only 15% done and 80% pass rate. We just received a custom tarball that we'll install manually to proceed with the real target
<tedg> sil2100, Honestly half the bugs on a milestone get moved, it's not clear looking at a milestone what is actually expected to land.
<sil2100> tedg: those milestones rather stay as they are - if a bug is assigned to the canonical-devices-system-image project and has a milestone set, then it means it has been marked as 'good to land' for RTM
<jibel> sil2100, there are some bad bugs, like no second SIM (fix in progress) no keyboard on 1st boot, problems with indicators and notifications, the launcher, the clock, ...
<sil2100> jibel: the no keyboard on first boot bug is that something like what we saw in ubuntu-rtm? i.e. one of the things that sometimes don't work on first boot?
<sil2100> jibel: or is that reproducible everytime (i.e. at every reflash eva)?
<jibel> sil2100, yes. I reflashed and it didn't happen
<ogra_> tedg, together with the summary that sil2100 sends out every day you should get a proper picture
<sil2100> I usually include the milestone links in my e-mails ;)
<ogra_> right
<tedg> My issue there is there is that many times I work on my part of a bug there, "it's critical and milestoned", only to find out that no one else is actually working on their part.
<tedg> So, it seems a better process is "wait for someone to ask, then ask if it's milestoned"
<sil2100> jibel, ogra_, davmor2, robru, popey, rvr, john-mcaleely: I will have to skip today's evening landing meeting
<popey> ok
<sil2100> I skipped practice last week and would like to attend today
<ogra_> sil2100, as usual
<popey> np, there is a pub nearby with my name on it
<davmor2> sil2100: man you need to get your priorities sorted ;)  enjoy your training :)
<sil2100> davmor2: sorry, I'm still working it out later after I'm back, so it's not that I'm skipping work ;)
<sil2100> Let's say I'm aligning with the US-tz people this way
<davmor2> sil2100: haha, I didn't say you were working :)
<davmor2> weren't even
<john-mcaleely> so davmor2 can't tell when sil is working or not?
<davmor2> john-mcaleely: well I know he'll work hard today martial arts training :)
<bfiller> rsalveti: were you able to get that rtm seed updated yesterday with ui-extras added?
<rsalveti> bfiller: yes - http://people.canonical.com/~ogra/touch-image-stats/rtm/243.changes
<rsalveti> sil2100: don't we require QA sign off for vivid now?
<rsalveti> no vivid cards at https://trello.com/b/AE3swczu/qa-testing-requests-for-questions-ping-eu-jibel-us-jfunk-nz-thomi-or-ubuntu-qa-on-ubuntu-ci-eng
<rsalveti> mine was archived
<sil2100> rsalveti: not yet, we'll start doing QA sign-off on Monday
<rsalveti> sil2100: alright
<kdub> cihelp: could I get added to the landing sheet? (currently I'm only in view-only mode)
<Ursinha> trainguards: ^
<sil2100> kdub: sure
<sil2100> kdub: just out of curiosity - which components will you be landing usually?
<kdub> mir
<sil2100> kdub: on it
<sil2100> kdub: let me check if you're in the train permissions as well
<kdub> sil2100, thanks
<sil2100> kdub: should be all ok
<sil2100> o/
<robru> kdub: ok you got silo 7, just be aware of your conflicts with silo 0 (I know 0 is for testing; you may need to rebuild 0 after 7 publishes)
<kdub> robru, thanks
<robru> kdub: let me know if you need any help running the train. you should have permission to start the build.
<robru> kdub: you're welcome
<kdub> robru, and that silo is for vivid, right?
<robru> kdub: yep
<kdub> thanks again robru
<robru> kdub: you're welcome
<robru> kdub: you can limit the dashboard to your own name to see just the stuff you care about: http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=kdub
<robru> kdub: or http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=qtmir if you want to see conflicts as well
<kdub> robru, ah, handy
<rsalveti> robru: https://ci-train.ubuntu.com/job/ubuntu-landing-018-1-build/101/
<robru> rsalveti: yeah, not sure what just happened there. try again?
<rsalveti> robru: already did
<robru> crap
<robru> rsalveti: something's wrong with sso...
<robru> rsalveti: ok well, this is beyod my ability to fix, off to #webops!
<rsalveti> robru: alright :-)
<robru> rsalveti: ok wow, sorry about that! fixed, and re-ran your job: https://ci-train.ubuntu.com/job/ubuntu-landing-018-1-build/104/console
<rsalveti> robru: what was it?
<robru> rsalveti: earlier today I discovered SSO was misconfigured, I fixed it incompletely at first, and then in my attempt to make a more permanent fix I managed to corrupt the global jenkins config rendering it incapable of running any jobs.
<robru> rsalveti: including the job I would have used to fix it, hence why I had to escalate to webops there.
<rsalveti> oh, got it
<rsalveti> cool
<robru> brb, late lunch
#ubuntu-ci-eng 2015-02-25
<imgbot> === IMAGE 111 building (started: 20150225-02:05) ===
<imgbot> === IMAGE RTM 244 building (started: 20150225-03:05) ===
<imgbot> === IMAGE 111 DONE (finished: 20150225-03:25) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/111.changes ===
<imgbot> === IMAGE RTM 244 DONE (finished: 20150225-04:15) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/244.changes ===
<sil2100> jibel: hey, will you be doing those ota tests for the latest rc image as per what alex requested yesterday?
<davmor2> sil2100: we already test ota in the regression suite what would we need to ota again for, or is this something else?
<davmor2> sil2100: we also test ota in the sanity suite too
<john-mcaleely> I think AK just wanted to confirm that, so we're probably ok
<sil2100> ok then
<sil2100> Let me find a quiet place here and launch my laptop
<sil2100> Double-confirming - we want image number 19 from RC to the stable channel, right?
<sil2100> (for krillin)
<sil2100> john-mcaleely: ^
<sil2100> Ok, anyway promoting
<john-mcaleely> sil2100, yup
<john-mcaleely> phew ;-)
<sil2100> hm, it's taking its sweet time
<sil2100> ogra_: copy-image takes an awefully long time, is that normal?
<sil2100> ogra_: usually it's almost instant
<ogra_> heh, usually it takes a long time ... interesting that it was quick for you the last times
<ogra_> it re-packs the rootfs tarball for each toplevel arch once
<sil2100> Yeah, it was done in a few seconds normally
<ogra_> so the first armhf and the first x86 run are both slow
<ogra_> subsequent armhf runs are fast since only the index files get updated
<sil2100> Ok then, I'll leave it running in screen since I need to move now, I'm probably sure krillin should be copied in a few moments
<sil2100> john-mcaleely: ^ I won't be around to announce once it's done, but it'll be done ;)
<ogra_> can take ten mins
 * sil2100 moves
<john-mcaleely> sil2100, great!
 * john-mcaleely runs u-d-f query in a loop :_)
<john-mcaleely> looks like it's done sil2100 :-)
<davmor2> sil2100: why do you want your laptop in space?
<sil2100> davmor2: how come in space? ;)
<davmor2> sil2100: you wanted to find somewhere quiet to launch your laptop :)
<davmor2> sil2100: most people just turn them on, you apparently launch them :D
<nerochiaro> sil2100: not sure if you are the right person to ask to, but do you know how does CI decide what packages to install before running AP tests ? specifically python packages
<greyback> Any reason why silos do not have debug packages generated? It would help me right now
<Mirv> greyback: the answer a couple of weeks ago was that we should have a "new, better system" in a couple of weeks. I'm not sure what the status is :)
<cjwatson> greyback: There are some problems with doing them across the board (which will hopefully be lifted soon, it's just that there's been quite an impressive dependency chain within Launchpad to get there including a complete librarian data migration), but I can retrieve them for you for a single silo as long as it was built reasonably recently
<Mirv> oh, there is it, the status
<cjwatson> https://bugs.launchpad.net/ubuntu-lt/+bug/1420185
<ubot5> Launchpad bug 1420185 in Ubuntu Landing Team "A way to provide ddebs to landing PPA:s?" [Wishlist,New]
<Mirv> sounds complex, but nice
<cjwatson> I think it's still reasonably only "weeks" since I said that :)
<greyback> cjwatson: ok am glad they're on the way at least. I'd very much appreciate mir debug packages from silo0
<cjwatson> greyback: OK, give me a few minutes to track them down.
<cjwatson> greyback: Just mir, not the other packages?
<greyback> cjwatson: well if you're copying... :)
<cjwatson> greyback: This is fairly time-consuming per-package, so would prefer to know what you actually need
<cjwatson> greyback: Argh, I think they may have been GCed already, sorry
<greyback> cjwatson: ah ok, no worries
<greyback> sbuild won't take too long
<greyback> thanks anyway
<cjwatson> We can reasonably reliably get them as long as the build was less than two or maybe three days ago.
<cjwatson> But the builders don't keep them around forever, and the ghastly hack that is ddebs.ubuntu.com doesn't keep them for PPAs either ...
<bzoltan_> Mirv:  may I ask for an RTM silo to land the UITK branch?
<Mirv> bzoltan_: looking
<Mirv> bzoltan_: I can assign a silo, if you're sure the fix is still wanted in before vivid switch?
<Mirv> bzoltan_: you've got the Bond silo. btw https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/textHandlerCleanUpRTM/+merge/247388 links to four bugs, of which only one has canonical system image target
<bzoltan_> Mirv:  I expect it to land by tomorrow or latest on Friday. Depends onthe load of QA
<Mirv> bzoltan_: so just to make sure you didn't miss, you got the ^ 007 rtm silo
<nerochiaro> does anyone know in which way CI decides what packages to install before running AP tests ? I have a problem with some packages being not isntalled despite being specified in debia/control and in manifest.json
<nerochiaro> fginther: Mirv: cjwatson: sil2100: ^^^ ? (or maybe point me to the right person I can ask to. thanks)
<sil2100> nerochiaro: hey!
<sil2100> nerochiaro: sorry, I was AFK
<nerochiaro> sil2100: hi
<nerochiaro> sil2100: np
<nerochiaro> i had forgotten too for a while :)
<sil2100> nerochiaro: you mean for a click package, right?
<nerochiaro> sil2100: yes, for camera app
<nerochiaro> sil2100: specifically looking at this issue: http://rtm-dashboard.ci.ubuntu.com/smokeng/utopic/touch_stable/krillin/243:20150224:20150216-fe747ac/349/camera_app/154770/
<sil2100> nerochiaro: not sure about CI, since you would have to ask them to get more detailed info, but I think phablet-test-click-setup is only fetching selected bzr branch of the click package and install ubuntu-ui-toolkit and unity8 AP tests
<sil2100> nerochiaro: plars would know more about smoketesting though
<nerochiaro> sil2100: ok thanks, let's see if he can help them
<nerochiaro> then
<plars> nerochiaro: just waking up, what's going on?
<cjwatson> nerochiaro: I'm afraid I have no idea about the CI bits
<nerochiaro> plars: was just wondering how can i make sure to tell AP to install the packages that my tests need
<plars> nerochiaro: if this is about camera, I know veebers was looking at it yesterday... ah ok
<nerochiaro> plars: different issue
<plars> nerochiaro: which test, and which dependencies does it need?
<nerochiaro> http://rtm-dashboard.ci.ubuntu.com/smokeng/utopic/touch_stable/krillin/243:20150224:20150216-fe747ac/349/camera_app/154770/
<nerochiaro> plars: it does need python3-wand
<nerochiaro> plars: it is the test linked above
<plars> nerochiaro: I'll stick it on our vanguard queue, if nobody else gets to it then I'll be able to do it in just a bit, does that work for you?
<nerochiaro> plars: just to be sure i understand: it is something you guys need to do, it is not something we can specify somewhere in the package manifest, right ?
<nerochiaro> plars: because in the package.json we have this, and i was wondering what it is for then:
<nerochiaro>     "x-test": {
<nerochiaro>         "autopilot": {
<nerochiaro>             "autopilot_module": "@AUTOPILOT_DIR@",
<nerochiaro>             "depends": [
<nerochiaro>                 "python3-wand",
<nerochiaro>                 "python3-mediainfodll"
<nerochiaro>             ]
<nerochiaro>         }
<nerochiaro>     }
<plars> nerochiaro: I forget, is camera a click or a debian test?
<nerochiaro> plars: camera builds both click and debian, but i think we run tests as click
<plars> nerochiaro: if it's pulling in a deb for the test, it *should* get any dependencies with it. However clicks don't use that
<plars> yeah, clicks are so disrespectful, they don't even bother to see stuff like that :)
<plars> nerochiaro: so is python3-mediainfodll needed also?
<nerochiaro> plars: yes please, both of them
<nerochiaro> plars: and the vanguard queue i guess will work if it is done in a reasonable amount of time
<nerochiaro> plars: thank you
<plars> nerochiaro: within the next couple of hours most likely
<nerochiaro> plars: most excellent. thank you
<plars> nerochiaro: for it to be in there, and land in the test code, etc
<plars> fully "done"
<nerochiaro> plars: it will do nicely. and a quick question before i let you go get your morning coffee ;) , are these tests re-run only when there is a new image, or we can ask them to be re-run with a certain merge request code  to see if it really fixes issues ?
<plars> nerochiaro: they should already be run for MP landings, are they not?
<nerochiaro> plars: what i see CI posting in the MR comments is basically only for vivid, not for RTM, unless I am missing something
<plars> nerochiaro: ah, not sure on that, but I'll check. Certainly it will be run for every new image though
<nerochiaro> plars: ok, thanks. if there is any way to access RTM tests results for merge requests, please let me know.
<plars> nerochiaro: don't things normally land in vivid though, and then migrate to rtm? What do you land in rtm directly?
<nerochiaro> plars: maybe i am not very clear on the process, but RTM is still on utopic
<plars> nerochiaro: looks like someone asked for it last night too, the deps already had a mp for it and should be there soon
<nerochiaro> plars: great
* plars changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping plars | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: -
<rsalveti> kenvandine: it seems we got a better fix for the bluetooth mr, will validate https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-018 later today again
<rsalveti> if indeed a good fix, then it would be nice to have it for rtm as well
<kenvandine> rsalveti, cool
<seb128> rsalveti, kenvandine, I acked the trunk mp and testing it with my car (which didn't work) and with keyboard and audio transmitter (which still work)
<seb128> tested even
<rsalveti> cool
<seb128> rsalveti, kenvandine, there are a bunch of bluetooth fixes in trunk, but rtm is basically over from what I understood from pmcgowan, e.g we just want to focus on rebasing on vivid now?
<kenvandine> seb128, yeah
<rsalveti> seb128: well, not yet over :-)
<kenvandine> well... soon :)
<rsalveti> once vivid is stable and we get a plan to move to it
<kenvandine> we might land some fixes soonish before rebasing
<rsalveti> "stable"
<seb128> rsalveti, well, basically I asked if we can get bugs added to the approved rtm list and that was the reply
<rsalveti> right, but we will be landing critical issues
<seb128> is that considered one?
<rsalveti> the idea was just to avoid landing issues that are not critical/high enough
<rsalveti> seb128: that might help pairing with quite a few cars out there
<rsalveti> and we have a bug from bq for it, so possibly
<seb128> indeed, mine for example :-)
<pmcgowan> that one might warrant a backport
<seb128> do we want to backport ssp pairing as well?
<seb128> that's used by e.g some keyboards
<rsalveti> seb128: keyboard pairing is not yet supported in RTM
<rsalveti> iirc
<pmcgowan> sil2100, did we promote the last rtm image?
<seb128> rsalveti, k
<seb128> rsalveti, where is the list of what is supported or not?
<sil2100> pmcgowan: yes :)
<rsalveti> seb128: would need to check the debdiff for that :-), but I think input is not yet supported because that only landed in vivid
<sil2100> pmcgowan: only the krillin one so far, but I'll have time to promote the rest in a minute
<seb128> rsalveti, oh, that's what you mean. Yeah, I added the ssp/keyboard pairing to vivid, I was just wondering if we should backport that as well
<rsalveti> seb128: afaik for the input to be useful it'd also require a new mir
<rsalveti> the current mir in RTM is unable to add new input devices dynamically
<seb128> rsalveti, ah ok, let's forget about it then
<rsalveti> yeah
<robru> sil2100: meeting?
<davmor2> sil2100, jibel, ogra_: landing meeting or is it cancelled?
<ogra_> i'm in the release plannin meeting atm
<ogra_> wont make LT today
<davmor2> we cancelled landing team
<Mirv> evening hi
<robru> Mirv: hola
<robru> oSoMoN: how's it going? you really ready for a publish? ;-)
<oSoMoN> robru, if you mean silo 25, I hit "build" again by accidentâ¦
<oSoMoN> I meant to rebuild silo 8, mixed up the two
<robru> oSoMoN: hmmm. so is 25 ready to publish? the dashboard says so...
<oSoMoN> robru, it is, and itâs actually already in -proposed, awaiting for the beta1 freeze lift to migrate to release
<robru> oSoMoN: oh, k. hm
<oSoMoN> which is why building it again was completely uselessâ¦
<robru> oSoMoN: yeah if it was already published, I just gotta fix the status or it won't automerge once it lands...
<oSoMoN> ah, sorry about that
<robru> oSoMoN: no worries.
<robru> oSoMoN: ok I think I fixed it, within 5 min or so we should see 'Migration: blah blah' message.
<Mirv> it's 24, not 25, which is in -proposed
<Mirv> oh, and I'm not really here
<Mirv> 20150224, that is
<oSoMoN> yeah, Iâm not really here either
 * oSoMoN disappears
* plars changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: -
<robru> Mirv: thanks for the heads up, fixed
<john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20150225-b67e0b6.changes
<john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20150225-b67e0b6.tar.xz
<john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-testresults-20150225-b67e0b6.ods
<john-mcaleely> new device tarball, for the logs and the morning :-)
<john-mcaleely> (also in the citrain spreadsheet, currently line 57)
#ubuntu-ci-eng 2015-02-26
<veebers> trainguards, silly question, if I update the MP that is preposed for the silo, do I need to reconfigure or just re-build the silo ppa?
<robru> veebers: rebuild if it's the same mp. Reconfigure if there's a new mp, including of its superceding a previous mp.
<veebers> robru: ah cool thanks, the MP was updated due to new code in trunk so I'll rebuild the silo.
<robru> veebers: sounds good
<veebers> oops
<veebers> ticked the right box this time :-)
<Mirv> (and morning too)
<Mirv> eh
<Mirv> ah, device tarball
<sil2100> Mirv: ;)
<mandel> sil2100, is launchpad down for you?
<mandel> sil2100, my manners, good morning!
<mandel> rearrange those please :)
<sil2100> mandel: morning! ;)
<sil2100> mandel: huh, indeed it is
<Mirv> launchpad down :(
<sil2100> I asked on launchpad-ops if anything
<Mirv> modern human is so impatient. "it's been down for 2 mins already!"
<sil2100> Ah, update
<Mirv> "but... but... I've important stuff building and I need to keep hitting refresh!"
<sil2100> 2 minutes?!?!?! OUTRAGE
<mandel> Mirv, yes, I don't consider it important, yet manager do
<mandel> Mirv, I just suffer their impatience :P
<mandel> also, compiling cpp takes longer than getting lp back hehe
<sil2100> LP is an important factor for almost everyone, so good that it's back up agaon
 * Mirv is satisfied with what the refreshing shows
<sil2100> oSoMoN: hey! Were you able to fill in an FFe for the oxide landing?
<oSoMoN> sil2100, IÂ did (bug #1425599), but chrisccoulson said that we don't use this process for oxide (or firefox & chromium), because all releases get the latest updates anyway
<ubot5> bug 1425599 in oxide-qt (Ubuntu) "[FFE] oxide 1.5" [Undecided,New] https://launchpad.net/bugs/1425599
<oSoMoN> so the FFe process is fairly redundant - if it's rejected, the latest release still lands anyway
<sil2100> hmm
<sil2100> Is that something that has been agreed with the release team?
<ogra_> hmpf
<ogra_> i just woke up my krillin for the first time today ...
<ogra_> the clock shows 5:04
<ogra_> and i cant convince it to show the right time it seems
<oSoMoN> sil2100, pretty sure it has, chrisccoulson can you comment on this?
<ogra_> hmm, suspend/resume fixed it for the lockscreen, but the clock indicator is gone
<chrisccoulson> sil2100, oSoMoN - yeah, I'm quite sure it has too, considering we are regularly pushing the same updates out to stable releases. And having an evergreen webengine was one of the reasons we created Oxide
<chrisccoulson> ISTR going through this every cycle :)
<ogra_> chrisccoulson, and you havent set up macros for it in your IRC client yet ?
<chrisccoulson> heh
<mandel> sil2100, is there a way to create 2 silos, one for rtm with udm and its dependencies, and a second silo for vivid with the same branch of udm and its dependencies
<mandel> sil2100, the issue is that its dependencies have a branch for rtm, yet I keep udm as updated as possible (trunk) in rtm
<sil2100> davmor2, jibel, john-mcaleely: so, following up on my earlier question, do we know if the U1 deletion bug has a fix ready/released?
<davmor2> sil2100: not yet
<jibel> sil2100, bug fixed in devel but not in rtm
<jibel> bug 1413655
<john-mcaleely> sil2100, I do not know
<ubot5> bug 1413655 in Canonical System Image "Updates panel does not prompt for login when U1 account is invalid/deleted" [Critical,In progress] https://launchpad.net/bugs/1413655
<sil2100> Thanks
<sil2100> dobey: hey!
<sil2100> dobey: we would need LP: #1413655 fixed for ubuntu-rtm as well, do you have some work done on getting this bug backported to 14.09?
<ubot5> Launchpad bug 1413655 in Canonical System Image "Updates panel does not prompt for login when U1 account is invalid/deleted" [Critical,In progress] https://launchpad.net/bugs/1413655
<mandel> sil2100, Mirv is this normal -> https://ci-train.ubuntu.com/job/ubuntu-landing-014-1-build/163/console
<mandel> sil2100, Mirv ignore me, ppc symbol issues
<sil2100> mandel: it looks like all architectures failed to build
<sil2100> mandel: because of symbol issues
<mandel> sil2100, yet, it just fails on ppc and the symbols files are not separated per arch
<mandel> sil2100, if it failed due to the symbols in should be in all the archs.. right?
<sil2100> mandel: it looks like it failed on all archs
<sil2100> ;)
<sil2100> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-014/+sourcepub/4804160/+listing-archive-extra
<mandel> sil2100, indeed, I'm stupid, I just updated the symbols
<mandel> sil2100, I forgot a push
<mandel> spanish lesson: soy gilipollas
<dbarth> sil2100: o/ hey can i get a silo for that quick fix?
<dbarth> i hear there is a window open to land that one in rtm
<dbarth> or any trainguards available
<sil2100> Sure
<davmor2> dbarth: ^ and sil2100 is already on it apparently
<sil2100> dbarth: we've been actually discussing this one
<sil2100> We even wanted to land it ASAP ;)
<dbarth> thanks guys
<dbarth> excellent
<Saviq> sil2100, thanks
<Saviq> trainguards, reconfigure on vivid silo 19 please, have added qtmir
<sil2100> Saviq: on it
<Mirv> sil 'Lightning' 2100
<Saviq> ;)
<sil2100> ;p Only sometimes though ;)
<om26er> renatu, Hi!
<renatu> om26er, hi
<om26er> renatu, it was regarding sync-monitor, it failed to sync for me on the first try
<om26er> renatu, http://paste.ubuntu.com/10428002/
<om26er> but now its working
<renatu> om26er, strange it should not try to sync if there is no network
<renatu> looks like it try to sync with device offline
<om26er> renatu, device was always connected
<renatu> om26er, the error says: Network is unreachable
<om26er> renatu, we can blame my internet then :)
<renatu> om26er, maybe in that time when you tried to sync the device was connected to wifi but without internet access
 * sil2100 goes off to lunch
<john-mcaleely> sil2100, I understand I have a +1 on the device tarball. is now good to push it?
<dobey> sil2100: yes i'll have a branch today
<Saviq> can you guys access the spreadsheet?
<Saviq> gdocs say it's too popular
<Mirv> Saviq: same here
<Mirv> it was "trying to reach" and after reaching it said that
<Saviq> yup
<Saviq> DoS :/
<Mirv> s/reaching/refreshing/ :)
<Saviq> Mirv, seems to be back
<Mirv> confirming
<john-mcaleely> sil2100, ping
<sil2100> john-mcaleely: pong
<john-mcaleely> sil2100, can I push the tarball, davmor2 is +1 on it?
<sil2100> john-mcaleely: sorry, was on lunch - where would you push the tarball to?
<john-mcaleely> normal RTM
<davmor2> john-mcaleely: 1 second
<sil2100> Sure :)
<sil2100> Oh
<sil2100> davmor2: ?
 * john-mcaleely waits one second
<john-mcaleely> ...
<john-mcaleely> done!
<sil2100> ;D
<davmor2> sil2100: nearly tested silo10 for the u1 account fix
<davmor2> john-mcaleely: ^
<john-mcaleely> we can land them as two builds? good to get them separate in rtm
<john-mcaleely> and device tarballs are quick builds
<sil2100> davmor2: we won't have time for that this round anyway, since we didn't prepare the derived series yet
<john-mcaleely> sil2100, ?
<sil2100> I would say let's land the tarball now
<john-mcaleely> yeah
<sil2100> And if anything, have a new image built later with the u1 fix
<sil2100> john-mcaleely: push it ;)
<john-mcaleely> sil2100, pushed!
<sil2100> \o/
<cjwatson> sil2100: if you're going to need a derived series please give us maximal warning this time
<cjwatson> don't want another last-thing-on-Friday panic
<sil2100> cjwatson: sure, for now we're trying to figure out how to copy only a device tarball from one channel to another ;)
<seb128> rsalveti, do you plan to land the agent rework silo? the comment from Mirv on the status is a bit confusing
<rsalveti> seb128: yup, in my list for testing & landing today
<rsalveti> takes a while to validate with all the bt devices, but will get it done today
<seb128> rsalveti, I tested & approved the mp yesterday :-)
<rsalveti> seb128: sure, but I want to test with my other devices as well because I had quite a few issues with that previous version of that mr
<seb128> rsalveti, do you plan to do the backport to rtm as well?
<rsalveti> seb128: which car did you use to test?
<rsalveti> seb128: that's the idea, yeah
<seb128> rsalveti, a peugeot one
<rsalveti> seb128: which model?
<seb128> 207
<rsalveti> mine is a peugeot as well, but 208
<rsalveti> cool, different one
<seb128> 207 business pack
<rsalveti> great
<seb128> I also tested ssp pairing on a k480 keyboard
<seb128> and an audio receiver
<seb128> so should be fine
<seb128> the previous version of the mp was making the per-device agent buggy
<seb128> that one should work for scenarios with adaptor agents and per device ones
<rsalveti> yeah, cool
<Mirv> sil2100: robru: ^ silo 020 qml cache for vivid, when/if FFe approved. or rsalveti too, whoever stays the longest :)
<sil2100> ;)
<sil2100> \o/
<sil2100> mandel: ping
<oSoMoN> trainguards: can you assist with silo 25 ? not really sure what happened
<robru> oSoMoN: looking
<robru> oSoMoN: yeah merge conflict against trunk, not sure, train has code to handle that, not sure what's wrong with it now. anyway I manually merged it and pushed
<popey> sil2100: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc&usp=drive_web#gid=0
<popey> is that the right sheet?
<popey> sil2100: did you say I just email you and you enter it, or I enter it? Because this looks like a computed sheet
<oSoMoN> thanks robru
<robru> oSoMoN: you're welcome
<sil2100> popey: you can e-mail me all the info :)
<rsalveti> sil2100: robru: can't create silo for line 64
<sil2100> One day we can go through adding a line together
<rsalveti> getting fata error in the spreadsheet and jenkins also failing
<sil2100> uh
<sil2100> The spreadsheet was acting strangely some hours ago indeed
<sil2100> rsalveti: let me try
<robru> rsalveti: log? line 64 was blank for me until I just reloaded the page just now
<popey> sil2100: correct answer! :D
<sil2100> huh
<rsalveti> robru: not blank here
<sil2100> robru, rsalveti: getting the same thing here
<sil2100> I mean, it's not blank, but a fatal error
<sil2100> Let me refresh the spreadsheet completelt
<robru> sil2100: fatal error where? in jenkins? or in the spreadhseet?
<sil2100> robru: on the spreadsheet
<robru> sil2100: rsalveti: worked fine for me, assigned silo 17
<sil2100> rsalveti: maybe it was broken since we had the spreadsheet open for too long?
<sil2100> robru probably loaded it just recently
<robru> rsalveti: yeah when in doubt, reload the spreadsheet.
<sil2100> popey: ;)
<oSoMoN> trainguards: can I have a silo for line 65, please?
<rsalveti> sil2100: robru: I opened it again in another browser
<rsalveti> and still had the same issue
<sil2100> huh
<rsalveti> well, it seems it'sfine now
<sil2100> Well, spreadsheet
<sil2100> So, looking at the failure summary from Google I get, there was some fatal error happening in syncstatus
<sil2100> But it might just have simply fixed itself magically, as always
<greyback> trainguards: can I get a silo for line 62 please
<robru> sil2100: you want to assign or should I?
<sil2100> robru: please do ;)
<robru> k
<robru> sil2100: oh I'm getting the fatal error now
<robru> greyback: bfiller: spreadsheet is imploding will assign when I can
<greyback> robru: thanks :)
<Mirv> good riddance...
<Mirv> for the imploding spreadsheet :)
<robru> greyback: ok rtm 12
<greyback> robru: cheers
<bfiller> robru: thanks, noticing that
<robru> greyback: you're welcome
<robru> oSoMoN: silo 21
<robru> bfiller: silo 25
<robru> sil2100: seems I have to prepare manually by copy & pasting from the spreadsheet. yey
<oSoMoN> robru, cheers
<robru> oSoMoN: you're welcome
<robru> Saviq: https://ci-train.ubuntu.com/view/1.%20Build/job/ubuntu-landing-019-1-build/119/console eh, qtmir-gles isn't in the silo...
<robru> or in the ppa, I mean
<robru> also wtf, that's supposed to timeout...
<Saviq> robru, huh, that job was supposed to *build* qtmir-gles... but obviously I forgot to reconf
<Saviq> robru, but found a bug for you then ;)
<robru> Saviq: you have an MP prepared already?
<robru> bfiller: 6, 26, 28
<bfiller> robru: thanks
<robru> bfiller: you're welcome
<robru> bfiller: WATCH_ONLY in silo 26 means "don't merge my merges, only look at PPA", but there's nothing in your PPA yet. FORCE_REBUILD also wasn't necessary, just run that job with no options.
<bfiller> robru: I must have pressed that by accident
<robru> bfiller: no worries, I'm just watching over builds ;-)
<bfiller> robru: I usually click "force rebuild" and "ignore missing twins" by habit. I guess I don't usually need these?
<robru> bfiller: force rebuild is only needed if you're rebuilding an already-built MP (due to new commits). also ignore_missing_twins is only to do with -gles packages so pretty much only used by kgunn & friends.
<bfiller> robru: ok
<robru> bfiller: I mean they don't *hurt* per se, but yeah, not often necessary.
<greyback_> trainguards: could I have a hand for a second, I'm proposing something for qtmir for RTM, but the build appears to be taking qtmir trunk and applying my patch, not the qtmir-rtm branch. How do I specify the RTM branch to the train?
<greyback_> trainguards: unping, my bad
<robru> greyback_: train goes by MPs, if the train is grabbing trunk it's because your MP points at trunk.
<greyback_> robru: yeah I realized I pointed it to the wrong branch, and needed to reconfigure
<greyback_> should be ok now
<rsalveti> sil2100: for silo rtm 12, we actually want to land that asap
<rsalveti> sil2100: the battery related fixes are fine for RTM
<rsalveti> and this is one of them
<robru> greyback_: no worries, I'm here to help if you need me
<greyback_> robru: thanks
<robru> greyback_: you're welcome
<sil2100> rsalveti: ok, then in my opinion the bug priority should be changed
<sil2100> rsalveti: since the battery fixes are critical prio IMO
<rsalveti> yeah
<robru> rsalveti: you did a WATCH_ONLY in silo 17 but there's no package there... I think you should cancel that build and rebuild without WATCH_ONLY
<rsalveti> robru: ops, wasn't supposed to be watch-only
<rsalveti> robru: done, thanks
<robru> rsalveti: you're welcome
<balloons> wgrant, ping
<veebers> trainguards the commit message for a landing is pulled from the commit message from the proposed MP right?
<rsalveti> veebers: yes
<robru> veebers: yes, unless it is specified in debian/changelog, then that is preserved
<veebers> and that's grabbed at the silo build time?
<robru> veebers: yes
<veebers> right, so I need to rebuild if I want that changed
<robru> veebers: yes
<veebers> cool thanks robru, rsalveti
<robru> veebers: you're welcome
<kdub> trainguards, with line 53/silo 7, what do I do about that source package? I've completed the testing, but that qtmir-gles source package has to land along with the other changes
<robru> veebers: also note, the train doesn't handle bulleted lists well. if you're going to set the commit message on an MP, try to write just one sentence on one-ish lines. if you need a bulleted list you have to write your debian/changelog yourself
<robru> veebers: (train can make a bulleted list, but each bullet represents one MP, so you'd have to have a bunch of MPs each with one sentence commit messages)
<veebers> robru: ah ok, gotcha. How will it handle the current one?
<robru> veebers: which one?
<robru> kdub: I don't understand the problem. silo says packages built?
<veebers> robru: sorry, any idea how the train will handle the current commit message?
<robru> veebers: what MP though? I don't know what silo you're talking about :-)
<veebers> robru: lol sorry I thought the fact you mentioned the bulleted lists you were looking at it, sorry about that
<robru> kdub: something goofy going on there, spreadsheet says source package but the train config clearly has an MP listed in the dashbaord
<robru> veebers: nah just some code I poked at recently.
<kdub> robru, right, something seems off, but I'm not quite sure how source packages work
<kdub> in the ci train
<veebers> robru: heh, right so fyi it's this one, and I want to remove one of the bullet points, so I'll update, rebuild and re-run the test run (https://code.launchpad.net/~autopilot/autopilot/trunk/+merge/250402)
<robru> kdub: well ostensible you manually upload those to teh PPA yourself. however in this case there's clearly an MP in the silo and the package is in the PPA as a result of that. it should be fine to just click publish. I have no idea why the spreadsheet shows different info. in cases of discrepancies, the dashboard is authoritative.
<robru> veebers: well, this is what your last build resulted in: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-009/+sourcepub/4803556/+listing-archive-extra so consider that...
<robru> veebers: you might want to make your own debian/changelog entry.
<robru> brb
<kdub> robru, so I think what happened was, the mp was in the mp-to-land column at the time the silo was set up, and then I wanted qtmir-gles as a source package, so i moved it to that column
<robru> kdub: why do you want a source package? what's wrong with the MP?
<robru> kdub: at any rate, if you need it to be a source package, it means you need to reconfigure the silo. but all that's going to accomplish is that it won't merge the MP that you built from, I don't understand why that would be desireable.
<kdub> camako, any insight? I'm not quite sure why it should be a source package myself
<robru> kdub: MPs are the primary use case for the train, I think you should change it back unless you have a good reason.
<camako> robru, this is for the qtmir twin (qtmir-gles)
<robru> camako: right, but you guys have an MP for that. what's wrong with it?
<camako> robru, the right thing to do would be to add it to the MP list
<kdub> okay, so I'll add the MP to the list
<robru> camako: agreed
<camako> robru, nothing... we weren't sure
<camako> yep
<robru> camako: kdub: yeah source packages are typically only used for things that we don't have lp branches for and thus have nothing to make an MP against.
<camako> robru, yeah the intention was that we'd add the MP later and reconfig ourselves (i.e. don't ask the trainguards) .. But some info got crossed...
<wgrant> balloons: Hi
<robru> camako: oh I see, yeah that makes sense, to start as a source package and then switch it to the MP, since you need to know the silo # before you can make the MP.
<robru> camako: kdub: but yeah, once you have the MP you're golden ;-)
<camako> robru, exactly
<veebers> robru: heh, thnks for the heads up, that isn't a very good change log, I'll make my own
<balloons> wgrant, hey, I was just implementing what you proposed on https://bugs.launchpad.net/launchpad/+bug/810229
<ubot5> Launchpad bug 810229 in Launchpad itself "no way to be both official-reviewer on a project and not recieve email (without using an external mailing list service)" [Low,Triaged]
<balloons> thanks for the thorough investigation. I hope I got it all correct, testing it out now
<kdub> okay, thanks for the help robru / camako
<veebers> robru: is there any magic I need to do other than just a dch -i  . . . commit and mp?
<robru> veebers: yeah sorry about that, train is optimized for small isolated branches authored by one or two people. the changelog it generates in the case of "many authors, one giant MP" is pretty puke-y
<veebers> robru: cure, makes sense
<veebers> s/cure/sure/
<robru> veebers: nope, no magic. train will detect that debian/changelog is modified and won't modify it further. just review it after you dch to make sure you got the desired result.
<wgrant> balloons: Ah, great. Let me know if it doesn't go as planned.
<robru> kdub: your'e welcome
<veebers> robru: ack, thanks
<robru> veebers: you're welcome
<robru> veebers: oh, the only magic bit I guess is that your series should be UNRELEASED, not vivid.
<veebers> robru: hmm, I fear that the version number might cause me grief, let me check
<robru> veebers: hm, yeah, I don't understand that part of the code very well. I think if your first line of the changelog says 'vivid' then the train will think that's an old release and generate a new, empty changelog entry (literally a bullet point with no text). but if you say UNRELEASED it should mangle the version number and generally do the right thing.
<dobey> i seem to recall having "vivid" as the release when i did custom debian/changelog for a landing, and it working fine :-/
<robru> veebers: last build generated version number 1.5.0+15.04.20150226-0ubuntu1 so a rebuild should result in 1.5.0+15.04.20150226.1-0ubuntu1 and work fine. you shouldn't need to know that though, basically if the first line of your changelog says "autopilot (1.5.0) UNRELEASED; urgency=medium" then the train should convert that to "autopilot
<robru> (1.5.0+15.04.20150226.1-0ubuntu1) vivid; urgency=medium" by itself
<veebers> robru: awesome, thanks again (I should have store the count of beers I owe you in something bigger than a unit32 as it's going to overflow soon)
<robru> dobey: yeah but I think if you say 'vivid' then you also have to pick your own version number. if you want the auto-version-number magic you need to say UNRELEASED. I can't remember exactly the details, I'd have to dig up the code
<robru> veebers: lol, you're welcome
<veebers> robru: so, one more question the debian/changelog in lp:autopilot has UNRELEASED from _ages_ ago as we've been using the train to land from lp:autopilot -> lp:autopilot/1.5 so it's happened automagically for us until now. Is it save to change that UNRLEASED to something else so dch -i gives me a new entry?
<robru> veebers: you mean http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/debian/changelog ?
<veebers> robru: that's the one
<robru> veebers: oh, don't use that one, since it's missing a ton of stuff. grab the one from the 1.5 branch and include that in the MP.
<veebers> the changelog and release has been happening in http://bazaar.launchpad.net/~autopilot/autopilot/1.5/view/head:/debian/changelog
<veebers> robru: ack, I'll merge that one back into lp:autopilot then go from there
<robru> veebers: ok sounds good
<dobey> hrmm
<dobey> i thought we had autopilot runs enabled for lp:pay-ui
<dobey> but i don't see an autopilot job run for my MP :-/
<dobey> which is odd, because it did run on my MP from last week :-/
<veebers> robru: if you have a moment could you sanity check this please? Then once that's merged to trunk I'll rebuild the silo: https://code.launchpad.net/~veebers/autopilot/add-changelog-for-release/+merge/251178
<dobey> cihelp: why would the ap tests jobs not be run on https://code.launchpad.net/~dobey/pay-ui/mir-app-test/+merge/251163 when they should be enabled?
<robru> veebers: seems fine generally. Assuming that you just took lp:autopilot/1.5:/debian/changelog and dumped it without modifications on top of lp:autopilot:/debian/changelog it should be correct.
<veebers> robru: right, just merged that back into trunk. Sorry I meant the version line, that's what you suggested right (1.5.0) . . . .
<robru> veebers: oh right, yeah that's fine
<veebers> sweet, cheers
<robru> veebers: it should be. ping me when the rebuild is done, I'm curious how that turns out. I might need to hotfix some code if it screws up
<veebers> robru: lol, aight, will do :-)
<fginther> dobey, there are two jobs that failed. Unfortunately the ap tests aren't able to run unless all the required sub jobs pass first
<dobey> fginther: oh ok. can you trigger a rebuild then? the failure is due to a test failing, which is completely unrelated to anything i changed in the branch (i only changed autopilot tests, and this is a unit test failure)
<dobey> not quite sure why it failed. seems maybe a timing issue during that run perhaps :-/
<fginther> dobey, rebuilding now
<dobey> thanks fginther
<oSoMoN> kenvandine, hey, would you have a moment to review and ack the packaging changes in https://code.launchpad.net/~osomon/webbrowser-app/use-grabToImage/+merge/250223 ?
<oSoMoN> trainguards: Iâm trying to get hold of a core-dev to ack the packaging changes in silo 21, and it will be ready for publication
<robru> oSoMoN: k, mterry or kenvandine are my go-to guys for that...
<robru> oSoMoN: not sure who else is around
<oSoMoN> already ask the latter, letâs poke the former
<oSoMoN> darn, heâs not around it seems
<robru> oSoMoN: yeah I don't see him
<camako> robru, can you please publish Mir 0.12 (silo 7)?
<robru> oSoMoN: https://launchpad.net/~ubuntu-core-dev there's lots of options though, see any names you recognize? ;-)
<oSoMoN> ogra_, would you have a minute to review and ack the packaging changes in https://code.launchpad.net/~osomon/webbrowser-app/use-grabToImage/+merge/250223 ?
<oSoMoN> robru, a bunch of them, yes :) trying a few options now
<robru> camako: one sec
<camako> Thanks robru
<robru> camako: you're welcome!
<camako> robru, @Packaging changes need manual ACKing, do I need to do get a core dev to do this or is it done already?
<robru> camako: normally yes, however that was a trivial diff, so I just waived it through for you
<camako> robru, okay thanks... That's what I thought.
<robru> camako: you're welcome
<oSoMoN> robru, Iâm off to bed, hopefully kenvandine sees my request and acks the changes and you can do the publication dance while Iâm asleep, otherwise Iâll follow up on it first thing tomorrow morning. cheers
<robru> oSoMoN: k, goodnight
#ubuntu-ci-eng 2015-02-27
<kenvandine> robru, +1 on the webbrowser-app packaging
<robru> kenvandine: cool, thanks!
<kenvandine> robru, np
<robru> veebers: congrats, changelog looks sane
<veebers> robru: heh yeah, I checked that before. Looks fine, thanks for your help on that.
<robru> veebers: you're welcome
<veebers> Although I had to propose a different a different MP as a bzr plugin I had does the right thing for merges, but launchpad does use that plugin :-P
<veebers> had to manually resolve it and use that
<robru> veebers: what plugin? curious
<veebers> robru: BZR_DISABLE_PLUGINS=builddeb bzr merge
<veebers> oops, sorry thats how to disable it at any rate :-P
<veebers> I meant to just say builddeb
<robru> veebers: hm, weird, I have builddeb and never had trouble merging
<veebers> robru: I must have done something slightly weird in what I wanted to do with the change log (i.e. merge backwards etc.)
<veebers> robru: I see manual ACKing there, do I need to hit someone up for that?
<robru> veebers: ah ok. yeah I'm pretty vanilla with my merges.
<robru> veebers: nah, that was a false positive. literally just whitespace in the diff. I waived it through
<veebers> robru: ah awesome, you're a king amongst men
<robru> veebers: why thank you, kind sir
<Mirv> sad, no FFe :(
<Mirv> yet
<rsalveti> :-(
<Mirv> rsalveti: shouldn't you be sleeping? :)
<rsalveti> yeah, but our software was supposed to be working :-)
<rsalveti> Mirv: why do we need a FFe if it was available for Qt 5.3?
<rsalveti> this was just a regression on Qt 5.4
<Mirv> rsalveti: well, compared to the state at the beginning of feature freeze, it's a new feature, but you're correct. if you want to take the blame I can just publish it :) it'd be nicer if there was a short ack from release team.
<rsalveti> Mirv: yup, should be easy to get some sort of ack
<rsalveti> Mirv: have the bug in hands?
<Mirv> rsalveti: https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1418060
<ubot5> Launchpad bug 1418060 in qtdeclarative-opensource-src (Ubuntu) "[FFe] QML compilation cache patch needs adaptation for Qt 5.4" [Critical,In progress]
<Mirv> there was an "almost ack" already, and I added the requested patch headers 50min later, then I think the team was swamped with beta1. pinged on IRC too yesterday.
<rsalveti> Mirv: yeah, probably
<rsalveti> Mirv: cool, looks like we might have a +1 today then
<Mirv> yeah, there shouldn't be any problem
<ogra_> grmbl ... so this is the second day where my clock adds up on krillin/rtm
<ogra_> *acts
<Mirv> ogra_: just acts up, not adds up 4 months? ;)
<ogra_> heh, that was the arale
<Mirv> right
<ogra_> and i blame that in that case the completely draIned battery was at fault
<sil2100> Mirv: let's publish silo 20 \o/
<sil2100> popey: hey, did you send me that e-mail with landing details? Since I don't seem to see it
<popey> no, not ready yet
<Mirv> sil2100: \o/
<popey> sil2100: com.ubuntu.terminal_0.7.58_armhf.click uploaded to the store.
<oSoMoN> trainguards:Â can I haz a silo for line 70, please?
<Mirv> oSoMoN: sure
<Mirv> oSoMoN: and nice fixing again, less private header users \o/
<Mirv> even though for 5.5 I'll do throwaway rebuilds anyway for more packages, but it makes it easier to keep the landing PPA in a working state when there are less packages
<Mirv> that's actually the most important usefulness from getting rid of private header usage - a more working landing PPA
<Mirv> well, for me the most important :D
<Mirv> but also for being able to test the future Qt version around the clock
<sil2100> popey: thanks :)
<oSoMoN> Mirv, yeah, Iâm glad I finally managed to get rid of private headers altogether
<sil2100> mandel: hey! I would like to ask a question about rtm silo 9
<mandel> sil2100, shoot!
<sil2100> mandel: is that one of the bugfix that need to get fixed to get 0 released?
<mandel> sil2100, yes, a security one
<mandel> sil2100, linked in the mr
<sil2100> ACK
<mandel> sil2100, https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1330770
<ubot5> Launchpad bug 1330770 in ubuntu-system-settings (Ubuntu) "click packages rely upon tls for integrity and authenticity" [Critical,In progress]
<mandel> sil2100, are you tying to block me? ;)
<sil2100> mandel: no no ;)
<ogra_> mandel, he will give you his bank account data in a minute though
<sil2100> mandel: I wanted to ask as pmcgowan targetted your silo as 'good to be cleared and dropped', but I actually thought that it might be related to the issues you mentioned in silo 0
<mandel> sil2100, is was set to be cleared and drop?? wtf? when? why? no no, don't do that!
<sil2100> mandel: yeah, no worries
<mandel> ogra_, I don't earn that much! I just have one car ;)
<ogra_> lol
<sil2100> We simply clear out silos from ubuntu-rtm that won't land, as the focus is vivid right now
<sil2100> But your silos are good ;)
<ogra_> mandel, you should join the landing team, the bribes easily earn you a second one :)
<mandel> ogra_, I'm in
<mandel> sil2100, ok, thx
<mandel> ogra_, what do I have to do? just reject?
<mandel> ogra_, I can do that in lots of languages: no, no, no, no, no (that is spanish, french, italian, portugues and catalan)
<mandel> and nein!
<ogra_> lol
 * sil2100 off to prepare lunch
<brendand> sil2100, is a new vivid image planned soon?
<brendand> sil2100, like in the next couple of hours?
<brendand> sil2100, we're waiting for an address book autopilot update
<sil2100> brendand: we didn't plan building anything now
<sil2100> Is it urgent? We can kick one if you need
<Mirv> \o/
<oSoMoN> trainguards: can silo 9 be published, please?
<Mirv> oSoMoN: sure
<john-mcaleely> sil2100, ping
<john-mcaleely> sil2100, (also in email, if you get this when I'm offline again)
<sil2100> john-mcaleely: thanks!
<rvr> rsalveti: Hi. Can you take a look to the cards of silo 1 and 19? Want to clarify their statuses.
<brendand> sil2100, how long would one take - it would be good if it doesn't do any harm
<brendand> sil2100, would be awesome if it could be in the next 90 minutes (i forget how long builds take)
<Mirv> brendand: sil2100: I wouldn't mind a new vivid image either now that qml cache is in :)
<sil2100> o/
<sil2100> Ok, let me kick a new vivid image
<sil2100> ogra_, rsalveti: any objections?
<ogra_> not at all
<sil2100> ogra_: to build a vivid image, I just need to execute the for-project ubuntu-touch etc. command without modifying DIST, right?
<ogra_> yep ... crontab -l helps :)
<ogra_> i usually copy paste from there ... safest bet :)
<sil2100> Yea, using that, but vivid is not explicitly mentioned there, so I didn't want to guess ;)
<imgbot> === IMAGE 114 building (started: 20150227-13:00) ===
<imgbot> === IMAGE 114 DONE (finished: 20150227-14:20) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/114.changes ===
<Mirv> brendand: ^
<brendand> cool
<kgunn> trainguards hey, just requested another silo, but i may need a little help...cause i'm not real savvy on the whole "additional pkg sync" stuff
<kgunn> basically....for that new silo i requested on line 66, i need the same pkgs that are silo 0 for libevdev & qtsystems-opensource-src
<Mirv> kgunn: you'll just want to upload them manually or ask us to binary copy, in which case it'd be fine as is
<sil2100> The silo sync can be used too
<kgunn> Mirv: yeah, if you binary copy from silo0 that'd be best...libevdev is a no change from archive, but the qtsystems-opensource-src has some mods
<sil2100> But if you feel safer you can just request a copy-package instead ;)
<Mirv> kgunn: why libevdev is there then if it's in archives too?
<Mirv> ah, target distro missing, adding
<kgunn> right
 * kgunn feels safer in hands of sil2100 and Mirv than his own
<Mirv> kgunn: yes, so libevdev seems to match what's in archives, so I wonder if it's needed at all?
<kgunn> Mirv: yeah...for some reason it was...maybe cause of the qtsystems-source-src building on it?
<kgunn> so we wouldnt break?
<kgunn> as it happened along the way one time i think
<Mirv> kgunn: I don't see a sensible explanation, which makes me fear I'm missing something.. unless at the time is was not yet in vivid archives
<Mirv> would mzanetti know?
<Mirv> removing two '"' characters from MP field..
<mzanetti> ?
<Mirv> mzanetti: why is same-as-archive-version libevdev in mwc silo?
<mzanetti> Saviq said we need that in order to make ci-train device-upgrade 0 work
<mzanetti> which still doesn't
<mzanetti> Mirv, kgunn ^
<Mirv> the plot thickens.. Saviq? ^
<Mirv> I can copy that, but it's the exact same version number and all that is already in the archives, so..
<mzanetti> Mirv, yeah well... ci-train upgrade-device fails because it would require to pull in new packages
<Saviq> Mirv, evdev isn't on the images
<Saviq> Mirv, so "citrain device-upgrade" would fail silently
<Saviq> because that's a new dep in silo 0
<Mirv> ohhh... so the theory was citrain would be ok if the package would be in the PPA..
<Mirv> interesting
<Saviq> not the theory, that's the truth ;)
 * Saviq was just going sync:ubuntu,vivid for evdec
<Saviq> -c
<Saviq> +v
<Mirv> well mzanetti just said it still doesn't work :)
<Mirv> but if that's one piece of the puzzle, then yes it makes sense, thanks!
<mzanetti> not exactly sure if it's that reason though
<Saviq> hum?
<mzanetti> didn't investigate too much tbh
<Saviq> Mirv, lemme check, I'll try here
<Mirv> well right at the moment 000 has outdated mir + unity-system-compositor
<Mirv> "the grey line of death" https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-000/+packages
<mzanetti> I think the outdated mir is on purpos
<mzanetti> e
<mzanetti> anpok wanted to downgrade it somehow today morning
<Mirv> anyhow kgunn ^ 009, and it already has libevdev and qtsystems copied over, so feel free to just build the MP:s
<Mirv> yup 0.12 made it into archives already
<Mirv> so then it shouldn't matter
<Saviq> mzanetti, well, mir 0.12 is migrating to vivid now, so we might need to drop it later, or rebuild in any case
<Mirv> oh right it's stuck in proposed
<Saviq> mzanetti, FYI, you can always reproduce what citrain is doing manually, by:
<Saviq> host> phablet-config writable-image -r 1596 --ppa ppa:ci-train-ppa-service/ubuntu/landing-000
<Saviq> device> sudo apt-get -o Dir::Etc::SourceList=/dev/null update
<rvr> rsalveti: ping
<Saviq> device> sudo apt-get dist-upgrade
<Saviq> mzanetti, and AFAICT that looks just fine
<mzanetti> Saviq, I don't think the ci-train too does a dist-upgrade, does it?
<mzanetti> tool
<Saviq> mzanetti, it does, but *after* the update with -o ...null
<rsalveti> rvr: pong
<Saviq> mzanetti, which means it temporarily disables the default archive
<mzanetti> ah
<rvr> rsalveti: Silo 1 and 9 need feedback
<Saviq> mzanetti, and goes on with just /etc/apt/sources.list.d
<mzanetti> right
<rvr> rsalveti: s/9/19/
<sil2100> rvr: what feedback do you need?
<rvr> Silo 1: Bugs 1421750 and 1417756 are not approved to land in week 9/13.
<ubot5> Error: Launchpad bug 1421750 could not be found
<ubot5> bug 1417756 in gst-plugins-bad1.0 (Ubuntu RTM) "mp4 videos recorded with GoPro camera do not play back on krillin" [Undecided,New] https://launchpad.net/bugs/1417756
<rvr> Silo 19: Silo description is Â«Adding additional meta data when decoding video files in gstreamerÂ», which is different than the bug reported in the PPA changelog.
<sil2100> rvr: I think those are factory fixes
<pmcgowan> sil2100, rvr they are for factory
<sil2100> rvr: at least that's what I understood from some recent discussions
<pmcgowan> also please look at ww13-ota milestone now
<sil2100> rvr: so you have a green light on signing them off
<rvr> pmcgowan: Ack, thanks
<pmcgowan> sil2100, yes
<rsalveti> yeah, basically ^
<sil2100> pmcgowan: thanks for confirming :)
<rvr> rsalveti: And what about silo 19?
<rvr> rsalveti: Changelog points to garbage signal on screen during playing specific mp4 video file https://bugs.launchpad.net/barajas/+bug/1421148
<ubot5> Error: launchpad bug 1421148 not found
<sil2100> bfiller: I'm looking at silo 001 now
<sil2100> bfiller: looks good in overall and probably is fine, but I'm a bit worried the release team might think that LP: #1401735 is a 'feature' instead of a bugfix
<ubot5> Launchpad bug 1401735 in ubuntu-keyboard "[Chinese][pinyin]no need to type full pinyin characters " [Medium,In progress] https://launchpad.net/bugs/1401735
<sil2100> bfiller: has this been escalated by the design team to be a bug in the current behavior?
<bfiller> sil2100: not a feature
<bfiller> sil2100: it's a performance improvement
<sil2100> I guess so too, publishing
<Saviq> Mirv, is the mir stuck in proposed issue being worked?
<sil2100> My ISP is really pissing me off
<sil2100> Whenever I have connection trouble it's usually during hangouts
<dbarth> trainguards, could i a get reconfig on silo rtm-010 (that's to verify that other u1 fix)
<sil2100> dbarth: sure
<sil2100> dbarth: done :)
<dbarth> sil2100: ty
<rsalveti> jhodapp: sil2100: robru: something happened that the media-hub silo we had for RTM disappeared
 * rsalveti looks for the log
<rsalveti> -queuebot/#ubuntu-ci-eng- [05:52:48] Silos: ubuntu-rtm/landing-002 (jhodapp, tvoss) Empty (media-hub, qtubuntu-media, qtvideo-node)
<sil2100> rsalveti: it might have been freed as part of our clean-up :)
<rsalveti> ^^
<sil2100> rsalveti: pmcgowan requested to clean up silos that aren't critical and are not crucial to land for ubuntu-rtm
<rsalveti> sil2100: nooooooooooooo
<rsalveti> sil2100: we were testing that
<rsalveti> omg
<rsalveti> don't do that
<sil2100> rsalveti: oh noes!
<sil2100> rsalveti: you remember the silo number it had? :)
<rsalveti> sil2100: rtm 2
<sil2100> Ok, I have all the backups so it'll be really fast
<sil2100> FUCK
<dbarth> hmm, apparently not
<rsalveti> sil2100: found the list of mrs
<rsalveti> will update and create the silo
<sil2100> rsalveti: sorry, such internet problems that it's creazy
<sil2100> *crazy
<sil2100> rsalveti: I'm doing CI Train ss backups every 30 minutes, so I can just recover any silo you want at any time
<sil2100> Just I need to be able to access the freaking spreadsheet to do that
<rsalveti> sil2100: so worries, got the list here :-)
<sil2100> F*cking ISP
 * cking always OSD messages when somebody curses like that ;-)
<sil2100> rsalveti: again sorry for clearing it up ;)
<sil2100> I might have misinterpreted no-movement falsely as well
<sil2100> brb, modem restart
<sil2100> popey: prepared
<sil2100> :)
<sil2100> pmcgowan: hey! Could you maybe change the priority of https://bugs.launchpad.net/ubuntu-rtm/+source/qtmir/+bug/1423787 to critical? It's a power-drain-related bug
<ubot5> Launchpad bug 1423787 in qtmir (Ubuntu RTM) "music-app blocks system suspend even when not playing any song" [High,In progress]
<Mirv> kgunn: sil2100: so no I don't think anyone has looked at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mir that Saviq was asking, seems packaging error
<pmcgowan> sil2100, sure but its on the ota milestone
<pmcgowan> sil2100, ww13-ota is the trigger for landing
<Mirv> kgunn: sil2100: and might complicate sil 009/000 usage as mir trunk is not uptodate
<kgunn> kdub: camako ^^ see Mirv
<Mirv> s/sil/silo/
<sil2100> pmcgowan: ah, ok, good to know
<sil2100> Mirv: ouch
 * sil2100 looks
<Mirv> I'm not really available to help but also robru should be here soonish
<Mirv> sil2100: for silo usage I'd consider force mergin 0.12 to trunk and handling solving that after it with separate fix upload
<Mirv> ie merge silo 007
<sil2100> Mirv, kgunn, Saviq: yeah, it seems like the ABI/API changed, package name has been bumped but the dep hasn't been renamed in the -dev package
<camako> kgunn, Mirv, mir packaging issue fixed. Currently building...  will be ready in a couple of hours.
<sil2100> camako: \o/
<camako> also, we found a way to detect such issues in CI going forward
<Mirv> camako: great
<Mirv> it might have made sense to clean&merge the 007 first though, since it was already published, even if stuck in proposed
<Mirv> proposed == published always anyway, it won't disappear
<Mirv> it's probablypossibly still possible, sil2100?
<Mirv> and then a new silo+MP for the fix
<Mirv> or of course however you wish
<sil2100> Mirv: yes, that can be done, but it's not required as the same silo can be re-used to publish a new fixed package as well
<sil2100> A thing of preferences I suppose
<Mirv> sil2100: oh, I was just looking at the message ^ and thought the changelog wouldn't support should rebuilding and republishing
<Mirv> but if that's supported then no reason to clean in between
<sil2100> Mirv: since the package never got out of -proposed, it can be forced to ignore the missing changelog entry (as it's probably the entry for what's in proposed) and just act as if it never existed
<sil2100> Mirv: as proposed is not the target archive
<sil2100> Mirv: and once the same silo is re-used, all the missing changelog info will be included anyway
<sil2100> camako, kdub, kgunn: hey, you guys need help with that silo?
<ogra_> sil2100, i got a sprint review meeting atm, is there anything for me in LT ?
<sil2100> ogra_: no, I think we're cool ;)
<sil2100> o/
<popey> sil2100: I'll be skipping the meeting as I have to take my daughter to ballet
<ogra_> great
<sil2100> Sure, I guess we're more or less good
<ogra_> popey, make her take a video of your dancing then !
<popey>  :)
<camako> sil2100, I guess at some point we'll need you guys to re-publish, but for now we are good
<Mirv> sil2100: oh, cool
<sil2100> camako: since I saw the silo doesn't build, you'd need to use a force flag I guess?
<camako> sil2100, oh I see gotcha
<camako> kdub ^
<sil2100> pmcgowan: hey, can we land a new reminders-app to the store?
<sil2100> pmcgowan: I think that's fine, considering it benefits both RTM and vivid
<pmcgowan> sil2100, yes
<pmcgowan> bfiller, seems silo11 has an issue
<bfiller> pmcgowan: what's the issue?
<kdub> camako, thanks for restarting build
<pmcgowan> bfiller, merge filed
<pmcgowan> failed
<bfiller> pmcgowan: hmnn, robru not sure what's the problem with rtm 11
<robru> bfiller: checking
<sil2100> robru: ah, it seems like the bug you mentioned in the morning?
<robru> sil2100: yep, I'll fix it
<robru> sil2100: oh actually no, telephony-qt5 really isn't published...
<sil2100> Wait, what? Why?
<sil2100> I remember I published it and ACKed the changes
<om26er> Mirv, Hi!
<om26er> Mirv, whats the status of silo13 rtm wasn't that supposed to be cleaned or something ?
<brendand> sil2100, i lost the links for the changelogs
<brendand> sil2100, can you furnish me
<robru> sil2100: ah, I see what happened. packagelist generated was invalid, missing the destination version, because telepathy-qt5.project was missing it. fixed it by a WATCH_ONLY build and then re-published, telepathy-qt5 should migrate shortly
<robru> bfiller: ok should be fixed now, telepathy-qt5 will migrate shortly and then the silo should merge
<robru> sil2100: meanwhile unity8 has that problem I mentioned in my email previously
<bfiller> robru: thanks! pmcgowan ^^^^
<robru> bfiller: you're welcome
<robru> brendand: which links you looking for? a specific silo?
<brendand> robru, no the image to image changelogs
<brendand> robru, i think they were under ogra's page on p.c.c
<robru> brendand: sil has some as well: http://people.canonical.com/~lzemczak/landing-team/
<brendand> robru, ah but they aren't there for the promoted images
<robru> brendand: no I'm not aware of any promoted-to-promoted diffs. they just diff between each built image
<robru> brb
<sil2100> brendand: we only do those for -proposed images
<sil2100> brendand: but binding proposed -> promoted is rather easy, I think jibel even had a script handy for that
<rsalveti> robru: going to trigger a new image
<robru> rsalveti: coolio
<ogra_> oh, then i need t write a mail
<ogra_> *to
<ogra_> (lockscreen checking in adb will be in that one)
<rsalveti> oh, did that land?
<rsalveti> great
<ogra_> ah, you missed the standup
<rsalveti> yeah, great
<rsalveti> just saw it
<ogra_> i decided to land it anyway so it is in ... the push/pull fix is still pending
<rsalveti> ogra_: np
<ogra_> i think i found a better way for the dbus bits ... but then my meeting marathon started :)
<imgbot> === IMAGE 115 building (started: 20150227-18:45) ===
<rsalveti> ogra_: :-)
<rvr> rsalveti: So, to approve silo 19, I need a clarification about its description. Â«Adding additional meta data when decoding video files in gstreamerÂ» doesn't match the bug (Â«garbage signal on screen during playing specific mp4 video fileÂ»).
<rvr> rsalveti: Video playback is fixed
<tedg> trainguards, can I get a vivid silo for line 72 please?
<robru> tedg: your wish is my command! silo 2
<tedg> robru, Thanks!
<robru> tedg: you're welcome!
<bfiller> robru: is this error legit? not sure if I need to do something ^^^
<robru> bfiller: checking
<robru> bfiller: it is legit, there's a version in distro that isn't in the trunk changelog: https://launchpad.net/ubuntu/+source/qtorganizer5-eds/0.1.1+15.04.20141121.1-0ubuntu2 luckily it's just a no-change rebuild, so you can choose FORCE_REBUILD to steamroll over that (but normally you need to check this; if there's a non-trivial upload in distro, FORCE_REBUILD
<robru> will technically revert it)
<bfiller> renatu: ^^^ will you take a look at that?
<bfiller> robru: should we just update trunk so it matches the version number?
<robru> bfiller: yes that's the best thing to do
<robru> bfiller: i mean, sync the changelog
<robru> bfiller: don't just copy the version number
<bfiller> robru: got it, thanks
<robru> bfiller: basically like 'apt-get source qtorganizer5-eds' and then copy the debian/changelog from that, and just push it to lp:qtorganizer5-eds trunk
<bfiller> robru: ok
<robru> bfiller: you're welcome!
<renatu> bfiller, ok I will do that, but how this happen?
<renatu> robru, ^^
<robru> renatu: it's caused by somebody doing a manual distro upload, eg, not using the train
<robru> renatu: which happens from time to time
<renatu> robru, ok let me fix that
<renatu> thanks
<robru> renatu: you're welcome
<rsalveti> rvr: in order to fix the issue we need to give the decoder more data about the video
<rvr> rsalveti: Ok
<rsalveti> rvr: so it know how to properly decode the video (and avoid it getting corrupted)
<rsalveti> rvr: thanks for validating it
<robru> kdub: so what's the deal with this mir landing? is it just bugfixes? I'm concerned because we're in feature freeze and this is versioned as though it's a new release.
<robru> rsalveti: will you publish rtm 19? I was about to but then saw your name on it
<kdub> robru,  it is a bug fix for a phone lockup that broke api
<robru> kdub: so there's no new features at all?
<kdub> robru, nope
<robru> kdub: ok cool
<imgbot> === IMAGE 115 DONE (finished: 20150227-20:10) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/115.changes ===
<robru> kdub: and you're ready to publish? ;-)
<kdub> robru, doing a quick sanity check on my n4 with the rebuild, gimme just a few minutes more...
<robru> kdub: oh ok. the spreadsheet indicates it's ready to go. just ping me when you're really ready
<kdub> robru, right, it got held up in vivid-proposed because of a packaging issue with a dev package that has now been fixed
<kdub> i guess in the future if that happens, i should toggle back to not tested in the spreadsheet
<robru> kdub: yes please
<kdub> robru, okay, really ready :)
<robru> kdub: great, thanks
<robru> kdub: ok, looks good.
<kdub> robru, thanks
<robru> kdub: you're welcome
<rsalveti> robru: will publish it
<robru> rsalveti: the meaning of your message really hinges on that colon being there ;-)
<rsalveti> robru: :-)
<rsalveti> DONE
<robru> rsalveti: sweet
#ubuntu-ci-eng 2015-02-28
<imgbot> === IMAGE 116 building (started: 20150228-02:05) ===
<imgbot> === IMAGE 116 DONE (finished: 20150228-03:30) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/116.changes ===
<Mirv> kdub: camako: robru: mir is still stuck in proposed
<robru> Mirv: ugh. Valid candidate my ass!
<robru> Mirv: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt i dont even
<Mirv> robru: yeah that update_output looks like "the world will fail if trying to update mir"
<robru> Mirv: and yet it passed silo verification...
<robru> Mirv: lol, abiword to zenity. ZENITY. HOW DO YOU BREAK ZENITY.
<Mirv> :D
<robru> Mirv: but seriously I don't have a clue how to fix that
<Mirv> yeah, I'm trying to update manually and see if it makes any sense, as soon as apt update would succeed
<Mirv> so, someone has capped my bandwidth to archive.ubuntu.com to like 512kbit/s. hello 90's!
<Mirv> oh, actually, in 1999 I had 100/10..
<Mirv> hello 80's!
<Mirv> in 80's I had ZX Spectrum and loaded from cassette at around 1500 bit/s, or sometimes the crazy hackers made it to 2600 bit/s turbo if you had really high quality cassette
<Mirv> kdub: camako: so far we've only understood that update_output claims Mir would break everything, while in practice everything seems and upgrades fine (I've now installed all binary packages from source mir, from -proposed, on my laptop). we might need a wizard like cjwatson to check it eventually.
<cjwatson> Mirv: you probably have a remaining dependency on a removed binary.  zenity breaking suggests that's probably in the vicinity of gtk.
<cjwatson> Mirv: new libmirclient8 still Depends: mir-client-platform-mesa | mir-client-platform-android, both of which have been removed in favour of *2.  Furthermore, new libmirserver30 Depends: mir-platform-graphics-mesa | mir-platform-graphics-android, both of which have been removed in favour of *2.
<cjwatson> kdub,camako: ^- mir bug
<cjwatson> Mirv: when you're simulating the install for this kind of thing, check closely to make sure that it's possible to remove all the binary packages that the source package in question no longer builds.  proposed-migration pretends that they no longer exist when doing its calculations
<infinity> Mirv: The simplest way to test that sometimes is just to hop in a chroot and "apt-get install (new packages) (broken package) remove1- remove2-"
<infinity> Mirv: ie: tell apt "no, you can't install the ones we're removing" and see what happens.
<infinity> In this case, "apt-get install libmirclient8 mir-client-platform-mesa- mir-client-platform-android-" was more than enough to show the issue.
<cjwatson> Mirv: Oh, also, ubuntu-touch depends on mir-graphics-drivers-android.
<cjwatson> Somebody should update the seeds, but the automatic update script probably won't work in this situation where the new thing is stuck in -proposed, so it's probably best to edit the metapackage directly.
<cjwatson> Fortunately that's not rocket science.
<infinity> cjwatson: It would be awfully nice if the try/pass/fail output gave a "would remove: bin1 bin2" line under the list of source package it's attempting an upgrade on, though.  Would be much easier to plug "apt-get install (list of fail) remove1- remove2-" into a console.
<cjwatson> Yeah, I guess ...
<cjwatson> patches welcome :)
<infinity> cjwatson: I mean, I assume uploaders know what packages they're removing, but when I'm debugging someone else's fail, I need to look at diffs. :P
<infinity> cjwatson: Who maintains britney upstream these days?  I feel like little formatting improvements like that should probably just go to Debian if I'm bothering to do them.
<cjwatson> Niels Thykier mostly, I think
<cjwatson> debian-release anyway
<cjwatson> but: the NBS removal thing is a bit of an Ubuntuism to start with IIRC
<infinity> cjwatson: My other consistent complaint (again, coming from doing "apt-get install (fail list)" is the unnecessary commas in the list, leading to the inevitable "echo list | sed 's/,//g' | xargs" which is silly.
<cjwatson> I don't remember whether something like that would apply on either side
<cjwatson> you'll have to see how closely it ties into the partial unstable handling
<infinity> Though, with the complete illegality of commas as input to apt, maybe I can just make Michael accept them in the package list. :P
<cjwatson> see also dpkg-checkbuilddeps
<infinity> Yup.
<infinity> checkbuilddeps has the excuse that it's control format, though.
<infinity> And "foo (1.0) bar" is confusing without the commas.
 * infinity takes what's left of his flu back to bed.
<Mirv> cjwatson: infinity: thanks for all the advice. so indeed I didn't notice this "these packages are still in the archive but should be removed, and something depends on those"
<Mirv> mir-platform-graphics-mesa/android has been replaced with *1, while mir-client-platform-mesa/android is at *2
<Mirv> rsalveti: ^ if you're around, feel free to publish now that it does not seem anything scary, after it has built and some sanity testing. https://launchpadlibrarian.net/198975118/mir_0.12.0%2B15.04.20150227-0ubuntu1_0.12.0%2B15.04.20150228-0ubuntu1.diff.gz
 * rsalveti waves
<charles> rsalveti, want to approve the MP? :)
<rsalveti> charles: yup, testing, reviewing and landing :-)
<rsalveti> if all goes well
<rsalveti> charles: can land the other one we got there as well
<rsalveti> for indicator-datetime
<rsalveti> mir finally landed :-)
<robru> Sweet jeebus!
#ubuntu-ci-eng 2015-03-01
<charles> looks like a hiccup in the ppc64el build, will retry
<charles> yup, INFO ppc64el: Successfully built
<imgbot> === IMAGE 117 building (started: 20150301-02:05) ===
<Mirv> cool (mir landed)
<robru> ls
<robru> lol
<imgbot> === IMAGE 117 DONE (finished: 20150301-08:30) ===
<imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/117.changes ===
#ubuntu-ci-eng 2016-02-29
<Mirv> jibel_: want to have a meeting or not?
<jibel_> Mirv, do we need one?
<Mirv> jibel: not from my side, but me and Dave are here if you have something on mind
<jibel> Mirv, nothing from me
<davmor2> jibel: no worries
<alf__> trainguards: Hi! Question: Can the CI train handle projects that useg LP git branches instead of bzr?
<robru> alf__: no
<alf__> robru: Thanks. Are there plans to add such a feature?
<robru> alf__: yes
<alf__> robru: Any ETA (just a very rough approximation will do, a few weeks/month, a year)?
<robru> alf__: 6 months i guess? I'm working on a major fundamental re architecture that will (among other things) modularize the bzr code so that git code can even be written. Then git is the next thing after that
<alf__> robru: thanks
<robru> alf__: you're welcome
<jgdx> trainguards: what's the dependency wait in silo 6? It complains the dep qml-module-qtsysteminfo (>= 5.0) can't be satisfied, but it's in my xenial.
<Mirv> jgdx: the qtsystems has a "~" in the version number after "5.0", "~" means in debian versioning speak "lower than" (since the module has not been released by upstream but is a git snapshot. TL; DR; make it (>= 5.0~)
<jgdx> Mirv, oh, ok. Thanks
<jhodapp> Mirv, how should we handle this silo situation...silo 53 has the back port of the QtMultimedia audio_role changes that are only for vivid+overlay landing. I need to land a qtubuntu-media change for both vivid and xenial +overlay. I can't build my change in a separate silo without the QtMultimedia back port, but I can't place my qtubuntu-media change into silo 53 because I need to dual land.
<Mirv> jhodapp: let's make 053 dual landing, even though qtmultimedia xenial doesn't need changes
<jhodapp> Mirv, ok that's what I thought as well, good to get that confirmed
<Mirv> jhodapp: it's now dual landing, I'll take care of xenial qtmm no change rebuilds
<Mirv> any MP:s should build normally there now
<jhodapp> Mirv, awesome thank you
<Mirv> jhodapp: note that you ran Build job but there are no MP:s in there so it did not do anything
<jhodapp> Mirv, oh hmm, my page must have been stale then
<jhodapp> it showed an MP
<jhodapp> Mirv, ok updated, thanks
<bregma> trainguards, I'm seeing the automated signoff fail for my silo, but the failure is unrelated to my package in any way, what's the procedure to resolve this?
<Mirv> bregma: get someone with upload rights to the packages in question (main -> core-dev) to click the retest buttons on the excuses page for the failing tets
<Mirv> and/or investigate why it's failing and file a bug of flaky test
<veebers> Hi robru, a couple of questions. I have an autopilot release I would like to do that would also sync the release between V & X, will it cause any issues if I merge the changelog diff into release trunk to get it to build (or is it possible to force it to ignore that and build anyway)
<robru> veebers: I'm pretty sure committing the changelog directly to trunk is what I told you to do last time we spoke? what changed/
<veebers> robru: ah no you're right sorry, I had it in my mind what we discussed last time wouldn't work, but only part of what we discussed wouldn't work. Sorry :-P
<robru> veebers: no worries
#ubuntu-ci-eng 2016-03-01
<bzoltan_> davmor2: jibel: the silo50 is good for checking again.
<pstolowski> jibel, good morning! i think you changed https://bugs.launchpad.net/ubuntu/+source/unity-scopes-shell/+bug/1419829 status by mistake, this problem hasn't been fixed yet
<ubot5> Launchpad bug 1419829 in unity-scopes-shell (Ubuntu) "[Scope] location settings are enabled by default" [High,In progress]
<jibel> pstolowski, oh right, it's a typo, sorry.
<jibel> reverted
<pstolowski> jibel, np, thanks
<jamesh> davmor2: re. the problems you found in silo 75, would it be possible to get access to one of the files where cover art no longer displays?
<davmor2> jamesh: sure
<davmor2> jamesh: issues scp-ing to server let me chase up on that
<michi> davmor2: If you still have the dbus.log file, that would be interesting to see too.
<davmor2> michi: I can grab that too for you, couldn't check syslog as it doesn't exist owned by wrong group I need to check in with jibel on how you re-enable it then I can run an update and check on it
<michi> Syslog wonât show us anything interesting.
<michi> All we need is ~phablet/.cache/upstart/dbus.log
<michi> Plus the actual media file.
<popey> jibel: I created a ticket for clock - new design and bug fixes - ready for testing https://requests.ci-train.ubuntu.com/#/ticket/1063
<jibel> popey, thanks
<jibel> set to ready
<jgdx> bfiller, there's a couple of important things missing from the backend, but the most important thing is the routing part. VPN are all or nothing in this regard.
<awe_> robru, around?
<dobey> doh
<robru> awe_: hi
<awe_> robru, I had some questions about the silo comments...  it seems if you wait too long to enter a comment on a ticket, it gets cleared.
<awe_> so I tried composing in an editor and cut & paste
<awe_> which leaves my comments horribly formatted
<awe_> https://requests.ci-train.ubuntu.com/#/ticket/954
<awe_> just wondering if this was on your radar, or I should file a bug
<robru> awe_: ugh, really? I fixed that once, sounds like it regressed
<awe_> robru, what'd you fix?  the formatting, or the disappearing comments?
<robru> awe_: not sure what you mean about formatting, you mean the way it line breaks after every period? That's because the automated statuses can't have line breaks, so the comments put line breaks to improve readability
<robru> The disappearing
<awe_> robru, ok.  The auto-formatting makes my comments look awful.  C'est la vie I guess, although maybe being able to edit comments would be helpful.
<awe_> anyways, not a big deal, but wanted to pick your brain about it
<robru> awe_: comments are immutable on purpose, they're meant to be an audit trail rather than something you write an essay in.
<awe_> sure... but there's no place else to record test results
<awe_> and once way back when, we used to record device/channel/image #
<awe_> s/record/require/
<awe_> so I at least try to include that much info
<robru> awe_: right, you're supposed to write that in the comments now, it just doesn't enforce the format like the spreadsheet did
<awe_> anyone else notice that the wiki has been super unstable lately?
<dobey> yes
<robru> awe_: I'll take a look at the disappearing today, that shouldn't be hard to fix
<awe_> thanks robru
<dobey> eh, i don't bother with the device/channel/image any more
<robru> awe_: i often have problems SSO'ing to the wiki
<awe_> yea, that... and lots of internal server errors lately
<robru> Haven't seen that personally
<robru> michi_: jamesh: yeah you're going to need ~ci-train-bot added to https://launchpad.net/~mediascanner-team/+members if you want the train to be able to push your merges to trunk.
<robru> awe_: ok, the fix for the comment clearing is now in production, please let me know if you see any other issues.
<dobey> hmm
<dobey> i don't understand
<dobey> what would have caused such failures as https://requests.ci-train.ubuntu.com/#/ticket/780 is showing now for the autopkgtests?
<dobey> (not having links to logs there, is quite frustrating)
<robru> dobey: what links are missing? The excuses page says unsatisfiable depends. I guess something landed in -proposed which breaks you, this isn't the first silo i saw like this
<dobey> robru: why would it also break in vivid though?
<dobey> hmm
<robru> Oh i only looked at xenial...
<dobey> vivid has much of the same errors, though it does have fewer total :-/
<dobey> i think something crazy is going on
<dobey> but i don't know where the logs are, so i can't see
<robru> dobey: you want what, the britney logs?
<dobey> the autopkgtest logs
<dobey> or whatever logs would show what is going on here, since i guess it's happening before the test jobs actually run
<robru> dobey: there are no autopkgtest logs because those errors are not from autopkgtest
<robru> dobey: enjoy: https://requests.ci-train.ubuntu.com/static/britney/last-run.txt
<dobey> I: [Tue Mar  1 21:02:34 2016] - Requesting autopkgtests for ['qtpurchasing-opensource-src/5.6.0~git20151023.2f454143-0ubuntu4~15.04.1'], exclusions: {'pay-service', 'ubuntu-system-settings', 'trust-store', 'ubuntu-push'}
<dobey> the britney log doesn't seem to have anything useful for this problem :-/
<dobey> yeah, i don't see "libgo7" mentioned anywhere in there
<dobey> ToyKeeper: hi. i just added another comment on the trello card for IAP. if you could read that and test again, you should hopefully not get the cancel of a purchase acting like it was successful, as a result of an incompleted purchase, as was happening
<ToyKeeper> dobey: Thanks!
<dobey> ToyKeeper: i'm about to head off for a while, but please ping if there's anything urgent :)
<ToyKeeper> Well, so far I managed to lock up the UI...  but it recovered in less than a minute.  :)
 * ToyKeeper reflashes to start fresh and try the actual test plan
<dobey> :)
<ToyKeeper> I'll be out for a bit later...  today is voting day and I'm not sure how long that will take.
<robru> great, only 7 more hours until somebody with the authority to fix this wakes up ^
#ubuntu-ci-eng 2016-03-02
<dobey> robru: michi should be around now or soon i think
<michi> dobey: Iâm around, but I have no admin rights for mediascanner2
<robru> Yeah
<michi> Waiting for James.
<robru> Or sil
<michi> sil will be off until tomorrow, from memory?
<michi> I think heâs moving apartment or something.
<robru> Well, James then
<michi> Yeah. Itâs not the end of the world.
<dobey> oh yeah, sorry, i thought you were an admin
<michi> Is this a recent change to the train?
<robru> michi: no it's a recent change to mediascanner
<michi> Weird.
<michi> So, the bot used to be a team member then and somehow thatâs disappeared?
<robru> michi: looks like a new team was created to own the branch and nobody put the train in it
<michi> Ah.
<michi> Yes, I think that happened recently.
<michi> I wasnât a team member, and James added me.
<michi> Not sure whether he change the team itself back then.
<michi> Anyway, James should be around in 30 minutes or so.
<robru> michi: huh, the team is from 2013, dunno why the train isn't in there
<michi> Weird. It wasnât me, I promise :)
<dobey> robru: it wasn't owning any branches until december i guess
<robru> michi: anyway, the train always relied on team membership for permission to merge to trunk... I guess your trunk was owned by a different team until recently, or you never released mediascanner in the train before
<dobey> or something like that perhaps. not sure why things were changed
<dobey> anyway, back to trying to relax and not feel horrible
<michi> dobey: what are you feeling horrible?
<jamesh> robru: hi.  I've added ci-train-bot to mediascanner-team.  There hasn't been any changes to branch ownership since the last merges though
<jamesh> robru: I'm guessing the bot had access through ~hollywood-team before, which I used to be able to view but can't anymore.
<robru> jamesh: yeah I'm not sure what to say, the train hasn't changed, it can't ever possibly merge branches without being in the team, that's lp's security, nothing to do with train code. Either it used to be in the team and was incorrectly removed, or team ownership changed to a new team that didn't have the bot
<jamesh> I'm guessing some other team has changed, but I have no idea which
<robru> jamesh: I'm not familiar with Hollywood team but i also don't have permission to view it
<jamesh> robru: "hollywood" was the code name for the old media scanner code base back in Ubuntu TV days
<jamesh> It's a bit difficult to tell what has changed without being able to see that private team though
<robru> jamesh: yeah i dunno. Anyway it should merge shortly, thanks for adding the bot
<jamesh> so presumably ci-train-bot was a member of hollywood-team via the same path I used to be.
<jamesh> looking at google's cache of the ~mediascanner-team Launchpad page, it used to have 98 members but now has 46, so something definitely changed
<dobey> michi: just been feeling horrible most of the day, probably largely in part due to allergies
<michi> Sorry to hear that :(
<michi> Pollen?
<dobey> yeah
<dobey> spring is here it seems
<dobey> anyway, am back off, hopefully to get more sleep tonight than i was able to attain last night
<ToyKeeper> dobey: Whenever you return...  is it supposed to permanently forget about consumable purchases each time the app starts?
<ToyKeeper> I know I'd be pretty annoyed if I bought a hundred consumables, used three, then found it empty later that day.
<ToyKeeper> Everything else seems fine though.
<Saviq> Mirv, morning, any idea what's all this about https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-064/excuses.html ?
<Mirv> hmm
<Saviq> it's like that all over the place https://requests.ci-train.ubuntu.com/#/ticket/1021
<Mirv> wow
<Mirv> better call saul... no, I mean pitti
<Saviq> touchÃ©
<Mirv> I can't see a reason for those unsatisfiable depends, the only usual reason for such would be main <-> universe deps
<Saviq> and/or a proposed transition, right? but that's vivid Â¿?
<Mirv> yeah it's vivid nothing extraordinary tends to happen there ever
<Mirv> but also on xenial https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-076/excuses.html
 * Saviq â #ubuntu-devle
<Mirv> ack
<popey> jibel: rvr could you please hold off testing clock - design have come back to us with a change they'd like. So I'll have to get that landed and rebuilt first. Sorry about this, it was unexpected!
<rvr> popey: Sure!
<jgdx> trainguards: what's up with this automated signoff thing in silo 6? I can't find anything about it here [1] and it's been a day without any progress. [1] https://wiki.ubuntu.com/citrain/LandingProcess
<popey> rvr: jibel ok, clock url updated in trello and citrain. Ready for testing :)
<rvr> popey: Ack!
<Mirv> jgdx: there was a regression in the infra earlier today, now sorted out if you saw dependency errors
<Mirv> jgdx: some tests probably rerunning, not sure of those unity8 ones though if there's another problem
<Mirv> jgdx: seems to be running still, or somehow on hold http://autopkgtest.ubuntu.com/running.shtml#pkg-unity8
<Mirv> jgdx: I'll ping pitti about it seems a bit abnormal
<jgdx> Mirv, thank you. Let me know if there's something I should do now, before or next time.
<Mirv> actually not pinging yet, they seem to progress at least now, and at least the 006 ones
<dobey> ToyKeeper: the app has to store that; our server doesn't keep track of how many potions/coins/whatever you've used in the app
<dobey> jibel: hi. so ToyKeeper tested the IAP silo again last night, and she says it's fine, but she noticed an issue in the app we're using to test with, which i think is probably due to confinement and our not modifying the qthangman example code but only packaging into a click to do initial testing with. can we unblock the card on trello and go ahead and land it now?
<dobey> omg
<dobey> CarolineYu: please fix your network connection
<pstolowski> trainguards hey, got "The following packages have unmet dependencies:
<pstolowski>  sbuild-build-depends-core-dummy : Depends: build-essential but it is not going to be installed" in silo 54, known?
<Mirv> pstolowski: unmet dependencies was there earlier in the day but was ought to be resolved by pitti and it seemed so
<Mirv> pstolowski: oh right that's not britney excuses but a build failure
<Mirv> pstolowski: and your problem is arch specific. I'm rerunning those failed archs to see if it persists
<Saviq> jibel, what's the price range for bumping a silo in "Need QA Sign-off" list?
<pstolowski> Mirv, k, thanks
<jibel> Saviq, which silo?
<Saviq> jibel, 76
<Saviq> jibel, it's small in itself, but either this or 50 would have to wait for one another
<jibel> Saviq, ah okay, I don't know how much you gave to rvr but he moved it to the top of the queue
<Saviq> ;D
 * rvr is waiting for his Raspberry Pi 3... he's cheap!
<dobey> jibel: hi, did you see my request earler re: silo 41?
<dobey> the constant reconnection spam from CarolineYu's irc client certainly isn't helping see things, i'm sure
<jibel> dobey, I didn't
<dobey> jibel: so, ToyKeeper was able to test it again last night, and it's all working for her, but she left it as blocked as there is an issue in the qthangman app itself. i added a comment on the card explaining the situation there. as all the stuff in the silo is passed though, i'd like to get it unblocked and into the passed column and landed
<dobey> jibel: and since she's asleep now, i thought it best to ask you
<jibel> dobey, yeah, I just read the back scroll, sounds good to me
<dobey> jibel: great. should i move it on the board?
<dobey> jibel: oh, i don't have permissions to remove the blocked label, or move the card to passed
<dobey> but i'll go ahead and hit publish for the silo
<dobey> hmm, i guess i will have to get someone to ack the packaging
<dobey> kenvandine: around? :)
<dobey> kenvandine, cjwatson, infinity, seb128, Laney, slangasek: could one of you do a publish with package ack on https://requests.ci-train.ubuntu.com/#/ticket/780 please? :)
<dobey> mterry: ^^ or if you're around, maybe you could? :)
<mterry> dobey, I'm here, yeah.  Let me look
<dobey> mterry: awesome, thanks
<mterry> dobey, kicked
<dobey> mterry: thanks much!
<michi> davmor2: ping
<veebers> robru: ping, I have a question about a failure in my silo (can't see logs the failure)
<robru> veebers: which one?
<veebers> robru: https://requests.ci-train.ubuntu.com/#/ticket/1061
<robru> veebers: so I'm seeing a unity8 regression in xenial. what's your question?
<robru> veebers: looks transient, probably worth retrying if you can find somebody with permissions for that
<veebers> robru:Which unity8 regression? I'm seeing the message: "Automated Signoff  Failed". I did the testing etc. and now want to release
<robru> veebers: right, so when you see "Automated signoff failed", you look a couple lines down at "Automated signoff artifacts" and there's links to "excuses" pages there that explain the automated failure.
<veebers> robru: oh right, I missed that :-\ Sorry
<robru> "automated test results", excuse me
<veebers> robru: what's the process for trying again? Toggling the Lander Signoff dropdown?
<robru> veebers: so yeah what happened was the train automatically ran a bunch of autopkgtests with your new autopilot and it found a problem, ut I looked at the log and it looks like an infra problem, so just find somebody with upload rights on unity8 (eg, your favorite core dev) and they can click retry on that
<veebers> robru: oh right, cheers. I don't think I have a favorite code dev, they're all equally awesome ;-)
<robru> veebers: heh, yeah
#ubuntu-ci-eng 2016-03-03
<Mirv> ubuntu-qa: please prioritize ticket 1021 (unity8) because it's needed to land first before we can put silo 50 (UITK + Unity 8) into the queue
<Mirv> ubuntu-qa: or you can actually choose - 050 was already tested earlier, so maybe it makes sense to retest it first (will be in queue soon) and pass it and then on to 1021
 * Mirv gets coffee
<Mirv> hmm, with the autopkgtests queue being over 1000 per architecture, there might be plenty of time to review 1021 first
<jibel> Mirv, 1021 is next in the queue
<Mirv> jibel: thanks
<Mirv> jibel: davmor2: FYI 1068 also in queue fixes the GPS issue I had, yay for debugging \o/
<morphis> sil2100: how far are we with your android packages?
<sil2100> morphis: let me check
<sil2100> morphis: oh! It's approved
<sil2100> Let me publish
<morphis> sil2100: great
<nik90> rvr, hey, how's clock-app testing going? Any blockers?
<rvr> nik90: No blocker so far, I'm finishing with the test plan and then I am checking the changes
<davmor2> sil2100: jibel: was the meeting cancelled and I didn't get the notification?
<rvr> nik90: popey: clock-app-roved
<popey> \o/
<popey> thanks rvr
 * popey uploads to the store
<nik90> rvr, thnx
<dbarth_> hey there, i don't know if there is a way to unblock or speed up some autopkg tests on xenial
<dbarth_> i have silo 36 blocked on xenial tests https://requests.ci-train.ubuntu.com/#/ticket/923 and that further blocks building and landing silo 77
<dbarth_> both having bug fixes for ota-10
<dbarth_> knowing that tests pass on vivid at least, is there a way to bypass some of that and be on time?
<dbarth_> rvr: can you advise on whether i need rebuild this silo that you just approved https://requests.ci-train.ubuntu.com/#/ticket/893 ?
<dbarth_> i admit being a bit lost with the exact status at this stage
<rvr> dbarth_: You should ask robru or sil2100 for details
<rvr> dbarth_: But it says it needs rebuild
<robru> dbarth_: yes, as it says, calendar app has new commits that have not been built.
 * sil2100 has serious connectivity issues in his new home
<robru> dbarth_: regarding your other question about autopkgtests, just ask qa to be added to the queue.
<dbarth_> robru: ok, i'm rebuilding
<dbarth_> and rvr ^^can you had the silo (36) to the queue meanwhile please?
<dbarth_> add
<rvr> dbarth_: Ok
<dbarth_> great, thank you; if that one can land, then 77 has the nicer fixes (and UI polish) that i'd like to line up asap
<dbarth_> knowing that 36 fixes the oxide dep. chain on ppc64 and al architectures, which will let 77 go without raising all of the test alarms again
<abeato> sil2100, hey, I have a new device tarball in http://people.canonical.com/~abeato/avila/ubuntu/ for frieza, would it be possible to generate a new rc image (should be rc#4, bq-aquaris-pd)
<rvr> Mirv: ping
<kenvandine> dobey, uh oh... silo 41 had mostly landed and now it needs a rebuild :/
<kenvandine> i need to get that settings branch merged so i can build silo 69
<dobey> kenvandine: eh?
<kenvandine> dobey, it claims new trust-store commits
<dobey> kenvandine: it lies
<kenvandine> hmmm
<kenvandine> the trust-store branches show that they were merged
<dobey> ugh, why was the system-settings branch not merged
<kenvandine> robru, ^^
<robru> looking
<kenvandine> that's the one i need merged
<kenvandine> robru, thx
<kenvandine> also interesting that it doesn't show as landed
<dobey> hmm
<dobey> the ubuntu-push one isn't merged yet either
<robru> 2016-03-03 19:33:10,506 INFO Disputed revision-id: ci-train-bot@canonical.com-20160303184919-t8cxc67bld0btm9o
<robru> 2016-03-03 19:33:10,509 ERROR New commits: https://code.launchpad.net/~phablet-team/trust-store/trunk
<robru> kenvandine: dobey: looks like a different silo landed an hour ago
<kenvandine> robru, but itt mergeed the trust-store branches all merged in this landing
<dobey> what different silo?
<robru> I dunno, it's just seeing a new commit on trunk it doesn't recognize
<dobey> https://code.launchpad.net/~phablet-team/trust-store/trunk
<kenvandine> robru, shouldn't it have complained before merging the trust-store branches into trunk?
<dobey> only new things on trunk are what it put there
<kenvandine> maybe the train had a hicup
<robru> hmmm
<robru> not sure
<robru> kenvandine: try force-merging the silo? it does appear it's all merged, just confused.
<kenvandine> robru, this landing merged 3 branches into trust-store trunk
<kenvandine> ok
<dobey> Committing to: /var/lib/jenkins/silos/ubuntu/landing-041/xenial/ubuntu-system-settings/ubuntu-system-settings/
<dobey> bzr: ERROR: No changes to commit. Please 'bzr add' the files you want to commit, or use --unchanged to force an empty commit.
<dobey> wtf?
<robru> dobey: it merged already, so there's nothing left to merge again. that's fine
<kenvandine> oh man... robru ^^
<kenvandine> robru, no it didn't
<kenvandine> https://code.launchpad.net/~dobey/ubuntu-system-settings/iap-trust-store/+merge/280356
<dobey> wtf
<robru> kenvandine: somebody removed the train bot from some critical team recently and it broke a bunch of bot powers. just add ci-train-bot to whatever team owns lp:ubuntu-push, run it agian, and it'll be fine
<kenvandine> robru, will it merged that settings branch?
<kenvandine> it looked like it ignored it before it blew up
<dobey> kenvandine: i guess it blew up and didn't get to pushing system-settings
<robru> kenvandine: everything looks totally fine to me. just needs permission to push to the trunk.
<kenvandine> ugh
<kenvandine> Chipaca, ^^
<kenvandine> we need Chipaca to add the bot
<dobey> oh fml
<robru> Chipaca: probably a good idea if you aren't the only admin of ~ubuntu-push-hackers, please add ~ci-train-bot to the team
<dobey> somehow my team membership got dropped there too
<robru> dobey: you, like the bot, probably only had indirect membership through some other team. I haven't been able to pinpoint the issue but somebody did a pretty major team reshuffle recently and the bot lost permissions to a few branches at least
<dobey> hmm, i guess this might be a result of the "team cleanup" that beuno did in february or january
<robru> sounds like it
<dobey> robru: yeah, beuno did some stuff with the ~ubuntuone* teams
<robru> kenvandine: anyway if you're in a hurry, and you happen to have team membership, you can push to the trunks yourself by branching the relevant branches from https://code.launchpad.net/~ci-train-bot
<kenvandine> cool, i'll do that for settings
<kenvandine> i can't do that for push
<robru> k
<dobey> yeah i can't either since my membership also got dropped :(
<Mirv> rvr: pong
<rvr> Mirv: Can you tell me how did you test this? https://code.launchpad.net/~thomas-voss/location-service/do-not-rely-on-obsolete-satellite-based-positioning-state/+merge/287790
<Mirv> rvr: ok, let me write it up there
<Mirv> rvr: done
<Mirv> rvr: so the start situation is as described, which apparently might be the case for many users including me. so if you have it On, change it to Off with a text editor and reboot and verify you have non-accurate GPS (not real GPS signal)
<Mirv> rvr: the setting in question was removed from UI or something, and what the silo does is that it does not disable real GPS even if the setting would be Off, ie it starts ignoring it since there is (some) other logic in place and the setting is not needed anymore
<rvr> Mirv: Ahh, I see. Thanks.
<Mirv> you may have other means to verify accurate/non-accurate location, but I used that example client application. after it was working it was very obvious also otherwise since I had actually moving dot in eg uNav when walking
 * rvr reflashes to check original state of /var/lib/ubuntu-location-service/config.ini
<Mirv> rvr: if it's On by default, then you'd need to simulate this which apparently may be the case for old OTA users who have upgraded
<Mirv> and I mean Engine::SatelliteBasedPositioningState=SatelliteBasedPositioningState::off is what I had there
<dobey> robru: uhm, where is the ci-train-bot for ubuntu-push in landing-041?
<dobey> i can't seem to find it
<rvr> Mirv: There is no file there
<robru> dobey: you mean the branch?
<dobey> robru: yeah
<rvr> Mirv: /etc/init/ubuntu-location-service.conf
<rvr> Hmm
<robru> dobey: https://code.launchpad.net/~ci-train-bot/ubuntu-push/ubuntu-push-ubuntu-xenial-landing-041
<robru> dobey: shows up if you select 'any status' as the status is no longer active
<dobey> robru: why is the status set to abandoned?!
<robru> i dunno man jeez
<robru> dobey: maybe there was a previous silo that was abandoned? I guess it doesn't set the status back to 'development' when it pushes new commits to it
<dobey> i don't think it was abandoned
<dobey> it's just been sitting there for 2.5 months
<robru> dobey: well, somehow, at some point, somebody called Merge.abandon_phase(), and not necessarily on the same request. it could be the previous request was also in the same PPA but was abandoned.
<dobey> robru: i don't recall ever abandoning the request and making a new one
<dobey> *shrug*
<dobey> kenvandine, robru: can we run the merge again on https://requests.ci-train.ubuntu.com/#/ticket/780 ? i found someone to push the ubuntu-push changes up, so it should be ok now i think?
<robru> dobey: kenvandine: on it
<kenvandine> cool
<robru> ugh it still needs the permission
<robru> dobey: if you get *all* the branches merged yourself we can just abandon the silo
<dobey> oh, it still wants to push there anyway, i guess
<robru> or I guess if we drop push from the request then it'll merge the other ones ok
<dobey> well i guess kenvandine pushed the u-s-s branch, and the push branch is pushed now
<dobey> so i guess they're all merged
<robru> dobey: i'll drop push from the silo then it should work
<dobey> so whichever you think is best, feel free to do, i guess :)
<robru> dobey: well it'll look better if it says 'Landed' rather than 'Abandoned' given that it is actually landed.
<dobey> indeed
<dobey> huzzah
<robru> yaaaay
<robru> ok I'm off for luncj
<dobey> the bot getting removed from lots of teams is freaking annoying :)
<robru> yeah whoever did that needs a smack
<dobey> +100
<dobey> e. honda smack
#ubuntu-ci-eng 2016-03-04
<veebers> robru: yet another dumb question, do I personally click publish for my silo or do I need someone with specific permissions to do so?
<robru> veebers: you'll have to ask the train that (by clicking publish)
<robru> veebers: (you can publish if there's no packaging changes; if there is packaging changes then you need to find somebody with upload rights)
<veebers> robru: ah cool, thanks :-)
<robru> veebers: you're welcome
<robru> veebers: I'm off to the gym in 15, let me know if you need anything else, otherwise I'll be back in 2hrs
<veebers> robru: ack, enjoy the gym :-) As far as I'm aware things are publishing well
<robru> thanks
<robru> veebers: ^ ah that's a success, yes. there was a message in the log that worried me but it was harmless
<veebers> Is there anyone around that has upload rights for qtmir that might be able to click the retry button for the autopkgtests? (http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#autopilot)
<Mirv> rvr: it was /var/lib/ubuntu-location-service/config.ini...
<abeato> sil2100, hey, would it be possible to generate a new rc/bq-aquaris-pd.en image for frieza? I have uploaded the device tarball in http://people.canonical.com/~abeato/avila/ubuntu/
<sil2100> abeato: sure
<abeato> sil2100, also, it would we good to temporarily move the place to search for images to rc-proposed to that location until john is back
<abeato> sil2100, thanks lot
<sil2100> abeato: hello btw.! Yeah, we can do that
<sil2100> Ok, let me do both
<abeato> :)
<sil2100> ;)
<abeato> sil2100, and morning ;)
<sil2100> abeato: the images should be imported, both for rc and rc-proposed
<abeato> sil2100, awesome, thanks
<ogra_> sil2100, seems you are still missing a cdimage "manta"
<sil2100> ogra_: yep, working on that now
<sil2100> :)
<ogra_> so painful ... would be good if we had a central place where such stuff is defined
<sil2100> Yeah, for me with not much experience in this path it's just a matter of trial-and-error
<sil2100> Who knows where the next hiccup will be ;)
<ogra_> cjwatson once started that with /etc/default-arches though ... but then the phones came ... with all their hackery and non-std subarch names
<sil2100> cjwatson: hey! What's the general process of updating /srv/cdimage.ubuntu.com on nusakan?
<sil2100> cjwatson: I have a fix commit that I would like to pull in
<ogra_> sil2100, https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup
<sil2100> ogra_: thanks
<sil2100> cjwatson: ...forget my question ;)
<cjwatson> yep, I think that has everything
<rvr> Mirv: We finally figured out. The file is not created until location service is disabled-enabled.
<Mirv> rvr: ok! but you stated something about /etc/ instead of /var/lib/ too?
<rvr> Mirv: I tried to find the file somewhere else
<Mirv> ok
<Mirv> popey: any idea who needs to do what in order for the QA approved (on Wednesday) Telegram to get to the store?
<jibel> rvr, ^ just to confirm, you verified that telegram works on stable too?
<rvr> Mirv: jibel: But there were additional fixes coming
<rvr> jibel: Jin told us they would create a new request to include the latest fixes they added
<rvr> mzanetti: Do you know what hapenned? ^
<mzanetti> rvr, I'm confused myself
<mzanetti> rvr, well, I know that the other day, when you found the bug, I spend an hour in the evening to fix it...
<popey> Mirv: yes
<popey> Mirv: but karni implied (on telegram) that this version wasn't for the store?
<mzanetti> rvr, I thought we agreed to not have that issue as a blocker and I wanted to fix it for the next release. but not sure if jin is on that same page right now...
<popey> Mirv: usually he (or whoever) provides a text description of the update changelog and a click and I usually upload it to the store
<mzanetti> rvr, note that jin is the official maintainer, I'm just a drive-by contributor
<rvr> mzanetti: Between you and me, yes, that was the agreement
<popey> Mirv: but I may have misunderstood what karni said
<mzanetti> rvr, I did tell to karni and jin in a telegram group that we agreed on that, and also wrote that in a mail to them, but I have the impression he skipped that information
<rvr> Here is the new request https://requests.ci-train.ubuntu.com/#/ticket/1076
<rvr> But it didn't pop up in trello
<popey> Mirv: https://drive.google.com/drive/folders/0BxI5I3bE-llaTHpyaFctV0VVVUE is where he usually shares it with me, but I don't care how I get it. Maybe ask victorp ?
<mzanetti> rvr, oh, I see that this new ticket also has stickers support in it
<rvr> jibel: popey: Mirv: mzanetti: So there is a new version pending to be validated
<mzanetti> rvr, so in that case, this is just "the next version" already (I pressed the turbo button on implementing abunch of features in telegram)
<popey> :)
<rvr> I validated the previous version in stable
<rvr> That one is ready
<rvr> So as you want to proceed
<popey> so basically I just need a changelog and a click and a +1 from QA
<mzanetti> is popey uploading the app?
<popey> I will if asked :)
<rvr> popey: https://requests.ci-train.ubuntu.com/#/ticket/1044
<popey> I usually do
<rvr> popey: +1'd there
<rvr> popey: That is com.ubuntu.telegram_2.0.8.0_armhf.click
<popey> got it
<popey> mzanetti: http://paste.ubuntu.com/15279934/ is that changelog accurate for 2.0.8?
<rvr> jibel: Do you know why this request didn't create a new card in trello? https://requests.ci-train.ubuntu.com/#/ticket/1076
<jin_> davmor2: ping
<davmor2> jin_: pong
<pete-woods> trainguards: hi guys, could someone kick the failed powerpc build in this silo? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-075/+packages
<jin_> davmor2: Hello, this is Jin,
<pete-woods> it's the usual crash in doxygen
<jin_> since we have a new release request of Telegram,
<jin_> davmor2: would you kindly to help us to give a test on that :)
<jin_> davmor2: https://requests.ci-train.ubuntu.com/#/ticket/1076
<jin_> davmor2: I already told Victor yesterday,
<davmor2> jin_: there was a discussion about that very thing with rvr about 3 minutes ago so I think he has it in hand already
<jin_> davmor2: just want to know if you could add this request into your RFT queue, that will be better
<jin_> davmor2: oh is it?  really thanks!
<jin_> I will check the Trello dashboard and monitor the status of this ticket,
<davmor2> rvr: ^ can you confirm
<rvr> jin_: Yes, I discovered that no new card was created for that request
<rvr> jin_: I am adding it manually
<jin_> davmor2: thanks for this connection
<jin_> rvr: oh my bad, how to new a card for that?
<jin_> rvr: (you mean in the Trello dashboard, right?)
<rvr> jin_: Yes, new requests should automatically create new cards in Trello, but in this case, it didn't
<jin_> rvr: okay, if meet the same problem next time, I will add the card into your Trello manually!
<rvr> jin_: Don't worry, just ping us
<jin_> rvr: sure!
<rvr> jin_: By the way, popey is uploading the previous version to the store
<popey> previous being 2.0.8, right?
<jin_> popey: Hey man, yes, 2.0.8.0
<rvr> popey: The one that I approved, yes :)
<jin_> it is correct
<popey> ok, just making sure :)
<cjwatson> pete-woods: done
<popey> jin_: http://paste.ubuntu.com/15279934/ that's the correct changes in 2.0.8?
<jin_> rvr: many thanks!!!  and... the 2.0.8.1 we made is for the issue fixed you mentioned (about the avatar rotate forever)
<jin_> popey: yes, confirmed
<popey> ok thanks
<jin_> popey: it is correct
<jin_> popey: so... do I need to raise a letter to you later as well..?
<jin_> popey: since you already knew we have this update ...
<jin_> XD
<popey> jin_: no :)
<jin_> popey: thanks man
<popey> jin_: rvr asked me before you joined the channel
<pete-woods> cjwatson: thanks!
<jin_> popey: btw, we have a new version 2.0.8.1 for bug solving as well, but anyway, just wait for QA result so that we can react,
<jin_> rvr, popey: you guys awesome! really thanks.
<jin_> this release is important to our Telegram user since it solved the reconnection issue
<rvr> Yes, yes, yes
<jin_> popey: thanks for uploading, if you done, could you please send me a letter so that I can do the tracking as well?
<popey> jin_: will do
<jin_> rvr: if any issues please feel free to tell me, so that I can schedule the release and will let you know the status
<jin_> popey: nice! thanks man
<rvr> jin_: Sure!
<jin_> rvr: thanks mate
<Mirv> popey: ok, thanks, I only noticed the QA passing of certain version
<Mirv> popey: and now karni is gone
<Mirv> popey: ah thanks, reading the further discussion
<popey> \o/
<jin_> Mirv: Hello guy :)
<jin_> Mirv: karni hand over Telegram to me already,
<jin_> if you got any problems, please tell me,
<Mirv> jin_: no problems, just eagerly waiting for the new version to arrive on store :)
<Mirv> jin_: thanks for taking over!
<jin_> Mirv: or contact me by: Jin.Hsieh@canonical.com is fine to me
<jin_> Mirv: Sure! Thank you!
<rvr> Mirv: Executing "client -bus" as phablet returns "The name com.ubuntu.location.Service was not provided by any .service files" and crashes
<Mirv> rvr: it was client --bus system
<rvr> Mirv: Thanks, that works.
<rvr> Mirv: To confirm, this is the ini content that I set:
<rvr> Engine::State=Engine::Status::on
<rvr> Engine::SatelliteBasedPositioningState=SatelliteBasedPositioningState::off
<Mirv> rvr: correct, http://pastebin.ubuntu.com/15266476/
<Mirv> that's what I had on my daily phone
<rvr> Mirv: You told me yesterday "verify you have non-accurate GPS" but this is set to off Engine::WifiAndCellIdReportingState=WifiAndCellIdReportingState::off
<Mirv> rvr: it works for me even though it's set to off, no idea why
<Mirv> rvr: I mean, even though that particular file states so, it's enabled in settings
<rvr> Mirv: Ah, took a little bit, but here it is On position updated: Update(Position(lat: Coordinate(27.8742 deg), lon: Coordinate(-15.4323 deg), alt: Coordinate(nan m), hor.acc.: 241 m, ver.acc.: nan m), 1457097342658310115)
<Mirv> rvr: yep. without the silo you tend to have only those single lines. with the silo if you're near window etc you should start getting coordinates that fluctuate a bit and velocity lines
<rvr> Mirv: Great, now installing silo packages to check
<Mirv> that is, On velocity_changed Update(0 m s^-1, 1457097795358032480) type of thigns
<Mirv> davmor2: do you think if 076 is currently blocked you could take another look at the fixed 050 in case it could land first? it was already QA:d aside from the remaining problem that was now fixed.
<Mirv> davmor2: the excuses pages https://requests.ci-train.ubuntu.com/#/silo/050 are now fully green except for one amd64 autopkgtest that a rerun for is seemingly hanged (but essentially the same test already ran with the silo on two other lines)
<Mirv> seb128: if you're available for binNEW review, UITK is adding new (not existed before) library and dev package at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-050/+sourcepub/6167973/+listing-archive-extra (normal package) + https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-050/+sourcepub/6167974/+listing-archive-extra (gles twin package)
<Mirv> the libubuntutoolkit5/-dev, libubuntutoolkit5-gles/-dev
<seb128> Mirv, I'm in middle of something else and need to go for some errands in a bit, but I can have a look once I'm back if nobody beats me to it
<Mirv> seb128: ok, I will ask again on Monday if needed
<seb128> yeah, should be done by then
<rvr> Mirv: At last. I got velocity info with the silo.
<Mirv> rvr: :)
<rvr> The phone got hot, for a while it refused to reboot.
<Mirv> davmor2: ok 050 got back to the QA queue too now as autopkgtests finally got enough retries
<davmor2> Mirv: :)
<rvr> tvoss: Mirv: Silo 49 approved
<Mirv> rvr: tvoss: \o/ I'm happy others sharing my fate will get a fix
<robru> rvr: qa status must be set to "ready" before the trello card gets created
<morphis> sil2100: the automated signoff on https://requests.ci-train.ubuntu.com/#/ticket/954 fails but that is simply not our fault
<morphis> one of libreoffice unit tests is failing
<morphis> sil2100: what are we doing with those things?
<morphis> davmor2: ^^
<morphis> davmor2, awe_: that is where bluez currently is hanging and why it doesn't appear on the QA board
<morphis> davmor2, awe_, sil2100: see https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-039/excuses.html
<davmor2> morphis: thanks I think it can be over ruled but sil2100 would be the one to fill you in on that.
<morphis> davmor2: good, then lets wait for sil2100
<rvr> robru: What's the context?
<awe_> libreoffice?
<awe_> sigh
<rvr> robru: Ah, that's the case for telegram
<robru> Yeah
<sil2100> morphis: hmmm
<sil2100> morphis: interesting though, it didn't fail in xenial in any of the other cases
<sil2100> morphis: should I try retrying?
<dobey> hmm
<rvr> mardy: Silo 13 is approved
<oSoMoN> trainguards: can someone please publish silo 55 for me, there are packaging changes that have been approved already (https://code.launchpad.net/~osomon/webbrowser-app/xdg_download_dir/+merge/286887)
<robru> oSoMoN: sorry, no special publish powers here, you need somebody with real upload rights
<oSoMoN> robru, a core dev?
<oSoMoN> kenvandine, can you help me with the publication of silo 55 ?
<kenvandine> oSoMoN, of course
<oSoMoN> thanks!
<robru> oSoMoN: yes, or anybody with PPU
<oSoMoN> kenvandine, the packaging diff is at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-1050/2016-03-03_19:08:32/xenial/webbrowser-app/packaging_changes.diff
<kenvandine> looks fine
<kenvandine> oSoMoN, done
<oSoMoN> kenvandine, thanks a bunch!
<boiko> trainguards: can someone please trigger a rebuild of telephony-service for amd64 in silo 80?
<robru> boiko: on it
<robru> boiko: ok done
<boiko> robru: thanks
<robru> boiko: yw
#ubuntu-ci-eng 2016-03-05
<boiko> robru: if you are still there, would you mind trigger a rebuild of telephony-service vivid armhf on silo 80?
<robru> boiko: one sec
<robru> boiko: OK done, I'm off for at least an hour, may be back later if you need me
<boiko> robru: thanks a lot!
<nik90> Elleo, Hi,
<nik90> Elleo, did you find time to look through the MP and the navigation structure proposal?
<Elleo> nik90: not yet, going to try and get to it this weekend
#ubuntu-ci-eng 2017-02-27
<abeato> Mirv, hi, I need help to land https://bileto.ubuntu.com/#/ticket/2472
<Mirv> abeato: still? ok, looking. was there something like someone should review the GStreamer update or such? if not, then'd be just reviewing the packaging changes indeed.
<Mirv> abeato: on Friday I was nearing EOD and saw some discussion between you and Lan_ey
<abeato> Mirv, that would go just for gstreamer-zesty, the rest can land
<Mirv> abeato: ok, so partial publish? full xenial and zesty minus gst-plugins-bad?
<abeato> Mirv, yes, that would be great
<abeato> Mirv, feel free to just remove gstramer-zesty if you want
-queuebot:#ubuntu-ci-eng- abeato, https://bileto.ubuntu.com/#/ticket/2472 Proposed pocket (zesty/lxc-android-config, zesty/media-hub, zesty/qtvideo-node). Successfully built (xenial/gst-plugins-bad1.0, xenial/lxc-android-config, xenial/media-hub, xenial/qtubuntu-media, xenial/qtvideo-node, zesty/gst-plugins-bad1.0, zesty/qtubuntu-media)
-queuebot:#ubuntu-ci-eng- justinmcp, https://bileto.ubuntu.com/#/ticket/2165 QA Signoff:
-queuebot:#ubuntu-ci-eng- justinmcp, https://bileto.ubuntu.com/#/ticket/2165 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- jhodapp, https://bileto.ubuntu.com/#/ticket/2189 QA Signoff:
-queuebot:#ubuntu-ci-eng- jhodapp, https://bileto.ubuntu.com/#/ticket/2189 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- abeato, https://bileto.ubuntu.com/#/ticket/2472 Proposed pocket (zesty/lxc-android-config, zesty/media-hub, zesty/qtubuntu-media, zesty/qtvideo-node). Release pocket (xenial/gst-plugins-bad1.0, xenial/lxc-android-config, xenial/media-hub, xenial/qtubuntu-media, xenial/qtvideo-node). Successfully built (zesty/gst-plugins-bad1.0)
<Mirv> abeato: ok ticket now reflects the status correctly. I'd keep the ticket there still, normal "Publish" can be run if the gst-plugins-bad1.0 is fine for zesty and it's wanted in
<abeato> Mirv, thank, so now all the stuff for xenial will eventually land, correct?
<Mirv> abeato: xenial is there in overlay already like it says, "Release pocket" means. zesty stuff is in zesty-proposed except for the unpublished gst one.
<abeato> Mirv, great, but when the MPs will be merged?
-queuebot:#ubuntu-ci-eng- abeato, https://bileto.ubuntu.com/#/ticket/2472 QA Signoff:
-queuebot:#ubuntu-ci-eng- abeato, https://bileto.ubuntu.com/#/ticket/2472 Needs rebuild due to burned version number (zesty/gst-plugins-bad1.0). Proposed pocket (zesty/lxc-android-config, zesty/media-hub, zesty/qtubuntu-media, zesty/qtvideo-node). Release pocket (xenial/gst-plugins-bad1.0, xenial/lxc-android-config, xenial/media-hub, xenial/qtubuntu-media, xenial/qtvideo-node)
<Mirv> abeato: ah, if you require that, then indeed it's best to remove gst. but let's first wait for the rest to migrate to release pocket.
<abeato> Mirv, yep, I would prefere that
<abeato> Mirv, anyway it looks like Laney has alredy approved the zesty version and uploaded: https://code.launchpad.net/~alfonsosanchezbeato/ubuntu/+source/gst-plugins-bad1.0/+git/gst-plugins-bad1.0/+merge/317315
<abeato> Mirv, so now it is better to remove gst-plugins-bad zesty from the silo
<Laney> meow?
<Laney> ah yeah, sorry, I sort of forgot it was in a silo and anyway I changed it v slightly from that version
<Laney> should be ok to just delete from there
<abeato> great
<Mirv> ok, thamks!
-queuebot:#ubuntu-ci-eng- abeato, https://bileto.ubuntu.com/#/ticket/2472 Needs rebuild due to higher version at destination (zesty/gst-plugins-bad1.0). Release pocket (xenial/gst-plugins-bad1.0, xenial/lxc-android-config, xenial/media-hub, xenial/qtubuntu-media, xenial/qtvideo-node, zesty/lxc-android-config, zesty/media-hub, zesty/qtubuntu-media, zesty/qtvideo-node)
-queuebot:#ubuntu-ci-eng- abeato, https://bileto.ubuntu.com/#/ticket/2472 Merging branches
-queuebot:#ubuntu-ci-eng- jhodapp, https://bileto.ubuntu.com/#/ticket/2189 Needs rebuild due to higher version at destination (xenial/media-hub). Needs rebuild due to new commits (zesty/media-hub)
-queuebot:#ubuntu-ci-eng- justinmcp, https://bileto.ubuntu.com/#/ticket/2165 Needs rebuild due to higher version at destination (xenial/media-hub). Needs rebuild due to new commits (zesty/media-hub)
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2514 Needs rebuild due to new commits (zesty/unity-api). Successfully built (xenial/unity-api, xenial/unity8, zesty/unity8)
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Pending binary packages (xenial/ubuntu-printing-app). Successfully built (xenial/content-hub, xenial/qtubuntu-print, xenial/ubuntu-ui-extras, zesty/content-hub, zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Successfully built (xenial/content-hub, xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/ubuntu-ui-extras, zesty/content-hub, zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- jgdx ahayzen, https://bileto.ubuntu.com/#/ticket/2515 Abandoning ticket
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/indicator-keyboard, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-system-settings, xenial/ubuntu-touch-session, xenial/unity8, zesty/indicator-keyboard, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-keyboard, zesty/ubuntu-sys
<greyback> trainguards: hey is it because FF that ubuntu-app-launch & friends has not landed in zesty? (seems it landed in X+O, and the branches actually merged, making qtmir unbuildable on zesty right now)
<xnox> not to do with freeze
<xnox> not blocked
<greyback> I didn't see any complaints in excuses
<greyback> so was out of ideas
<xnox> greyback, correct and freeze blocks are in excuses if there are any
<xnox> greyback, you should look at output of attempting to migrate them at
<xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<greyback> aha
<xnox> look for Trying easy from autohinter: content-hub/0.3+17.04.20170211-0ubuntu1 indicator-transfer/0.2+17.04.20170215-0ubuntu1 qtmir/0.5.1+17.04.20170221-0ubuntu1 ubuntu-app-launch/0.10+17.04.20170215.1-0ubuntu1 ubuntu-push/0.68+17.04.20170211-0ubuntu1 ubuntu-system-settings/0.4+17.04.20170211-0ubuntu1 unity-scope-click/0.1.1+17.04.20170213.1-0ubuntu1 unity8/8.15+17.04.20170221-0ubuntu1
<xnox> start: 63+0: a-20:a-7:a-7:i-10:p-5:s-14
<xnox> orig: 63+0: a-20:a-7:a-7:i-10:p-5:s-14
<xnox> easy: 288+0: a-100:a-44:a-46:i-49:p-35:s-14
<xnox> and a bunch of stuff not being installable.
<xnox> it seems like there is an abi migration for something
<xnox> qtmir? ubuntu-system-settings? or some such
<greyback> afaik ubuntu-app-launch bumped api/abi
<greyback> is all I know. Will poke ted when he arrives online
<Laney> indeed
<Laney> it has a versioned -dev package
<Laney> i think the uploader should handle this transition
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Successfully built (xenial/content-hub, xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/ubuntu-ui-extras, zesty/content-hub, zesty/ubuntu-ui-extras)
<Laney> http://people.canonical.com/~ubuntu-archive/transitions/html/libubuntu-app-launch4.html <- xnox kenvandine tedg_ FYI
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Successfully built
<kenvandine> Laney, tedg_: i'm on it, i think i'll need to do a manual zesty upload for keeper to work around their need to auto-land in the staging branch first
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/indicator-keyboard, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-system-settings, xenial/ubuntu-touch-session, xenial/unity8, zesty/indicator-keyboard, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-keyboard, zesty/ubuntu-sys
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2517 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- kenvandine ted charles, https://bileto.ubuntu.com/#/ticket/2516 Preparing packages
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2504 Preparing packages
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2504 zesty/webbrowser-app: Failed to download DSC file https://launchpad.net/ubuntu/+archive/primary/+files/webbrowser-app_0.23+17.04.20170125.1-0ubuntu1.dsc
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2517 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine ted charles, https://bileto.ubuntu.com/#/ticket/2516 Currently building (xenial/indicator-datetime, zesty/indicator-datetime). Failed to build (xenial/url-dispatcher, zesty/url-dispatcher)
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Pending binary packages (xenial/content-hub). Successfully built (xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/ubuntu-ui-extras, zesty/ubuntu-ui-extras). Uploading build (zesty/content-hub)
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2504 Failed to build (xenial/webbrowser-app). Pending binary packages (zesty/webbrowser-app)
<Laney> kenvandine: righto, just be aware that you probably need to fix the *build* deps too
<Laney> i.e. check the output debs to make sure they depend on 4 instead of 3
-queuebot:#ubuntu-ci-eng- kenvandine ted charles, https://bileto.ubuntu.com/#/ticket/2516 Failed to build (xenial/url-dispatcher, zesty/url-dispatcher). Pending binary packages (zesty/indicator-datetime). Successfully built (xenial/indicator-datetime)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2517 Pending binary packages
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print). Needs rebuild due to new commits (zesty/ubuntu-printing-app). Successfully built (xenial/content-hub, xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/ubuntu-ui-extras, zesty/content-hub, zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Preparing packages
<dobey> kenvandine: ick. can we avoid that perhaps?
<dobey> hmm, there is some weird issue with the keeper tests in jenkins it seems, on xenial
<dobey> manual uploads are a pain in the neck
-queuebot:#ubuntu-ci-eng- kenvandine ted charles, https://bileto.ubuntu.com/#/ticket/2516 Failed to build (xenial/url-dispatcher, zesty/url-dispatcher). Successfully built (xenial/indicator-datetime, zesty/indicator-datetime)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2517 Successfully built
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Pending binary packages (xenial/ubuntu-printing-app). Successfully built (xenial/content-hub, xenial/qtubuntu-print, xenial/ubuntu-ui-extras, zesty/content-hub, zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2504 Failed to build (xenial/webbrowser-app). Successfully built (zesty/webbrowser-app)
<dobey> kenvandine: i thought you already did indicator-datetime and url-dispatcher, too?
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Successfully built (xenial/content-hub, xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/ubuntu-ui-extras, zesty/content-hub, zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- abeato, https://bileto.ubuntu.com/#/ticket/2518 Preparing packages
-queuebot:#ubuntu-ci-eng- abeato, https://bileto.ubuntu.com/#/ticket/2518 Pending binary packages
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Pending binary packages (xenial/ubuntu-printing-app). Successfully built (xenial/content-hub, xenial/qtubuntu-print, xenial/ubuntu-ui-extras, zesty/content-hub, zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- abeato, https://bileto.ubuntu.com/#/ticket/2518 Successfully built
-queuebot:#ubuntu-ci-eng- kenvandine ted charles, https://bileto.ubuntu.com/#/ticket/2516 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Successfully built (xenial/content-hub, xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/ubuntu-ui-extras, zesty/content-hub, zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- kenvandine ted charles, https://bileto.ubuntu.com/#/ticket/2516 Failed to build (xenial/url-dispatcher, zesty/url-dispatcher). Pending binary packages (xenial/keeper, zesty/keeper). Successfully built (xenial/indicator-datetime, zesty/indicator-datetime)
-queuebot:#ubuntu-ci-eng- kenvandine ted charles, https://bileto.ubuntu.com/#/ticket/2516 Destination version missing from changelog (zesty/keeper). Failed to build (xenial/url-dispatcher, zesty/url-dispatcher). Successfully built (xenial/indicator-datetime, xenial/keeper, zesty/indicator-datetime)
-queuebot:#ubuntu-ci-eng- kenvandine ted charles, https://bileto.ubuntu.com/#/ticket/2516 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine ted charles, https://bileto.ubuntu.com/#/ticket/2516 Destination version missing from changelog (zesty/keeper). Pending binary packages (zesty/url-dispatcher). Successfully built (xenial/indicator-datetime, xenial/keeper, zesty/indicator-datetime). Uploading build (xenial/url-dispatcher)
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Currently building (xenial/ubuntu-app-launch). Failed to build (zesty/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- kenvandine ted charles, https://bileto.ubuntu.com/#/ticket/2516 Destination version missing from changelog (zesty/keeper). Needs rebuild due to new commits (zesty/url-dispatcher). Successfully built (xenial/indicator-datetime, xenial/keeper, xenial/url-dispatcher, zesty/indicator-datetime)
<dobey> kenvandine, Laney, tedg_: ^^ am getting this fixed and hopefully at last to qa today, to fix the ual migration issues.
-queuebot:#ubuntu-ci-eng- kenvandine ted charles dobey, https://bileto.ubuntu.com/#/ticket/2516 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg mterry, https://bileto.ubuntu.com/#/ticket/2129 Failed to build (zesty/ubuntu-app-launch). Successfully built (xenial/ubuntu-app-launch)
<kenvandine> dobey, any idea why bileto thinks it's still preparing packages?
<dobey> kenvandine: it's a little slow sometimes
<kenvandine> for some definition of a little :)
<dobey> kenvandine: looks like there were a couple build failures. could you retry them please?
<dobey> kenvandine: well, it only updates every 20 min or so i think
<kenvandine> seems like it's been longer than that
<kenvandine> retrying them
<dobey> well i don't know what the exact timestamps are, so hard to say :)
<dobey> yay, those built ok this time; and now all the MPs are approved
<dobey> so once binaries are published and bileto notices, we should be able to send it through to qa
<dobey> grrrrr
-queuebot:#ubuntu-ci-eng- kenvandine ted charles dobey, https://bileto.ubuntu.com/#/ticket/2516 Destination version missing from changelog (zesty/keeper). Pending binary packages (xenial/keeper). Successfully built (xenial/indicator-datetime, xenial/url-dispatcher, zesty/indicator-datetime, zesty/url-dispatcher)
<dobey> bileto lies
<dobey> oooooh
<dobey> because it's missing from trunk
<dobey> ok, hopefully things will autocorrect now
-queuebot:#ubuntu-ci-eng- kenvandine ted charles dobey, https://bileto.ubuntu.com/#/ticket/2516 Needs rebuild due to new commits (zesty/keeper). Successfully built (xenial/indicator-datetime, xenial/keeper, xenial/url-dispatcher, zesty/indicator-datetime, zesty/url-dispatcher)
<dobey> doh
<dobey> rebuilding keeper then
-queuebot:#ubuntu-ci-eng- kenvandine ted charles dobey, https://bileto.ubuntu.com/#/ticket/2516 Preparing packages
<dobey> kenvandine: can you retry https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2516/+build/12063989 please?
<dobey> trainguards: ^^ or can someone else retry this build please? :)
-queuebot:#ubuntu-ci-eng- kenvandine ted charles dobey, https://bileto.ubuntu.com/#/ticket/2516 Failed to build (xenial/keeper). Pending binary packages (zesty/keeper). Successfully built (xenial/indicator-datetime, xenial/url-dispatcher, zesty/indicator-datetime, zesty/url-dispatcher)
<dobey> anyone? mcfly?
<kenvandine> dobey, on it
<dobey> yay thanks
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2483 Needs rebuild due to new commits (zesty/cmake-extras). Successfully built (xenial/cmake-extras)
-queuebot:#ubuntu-ci-eng- kenvandine ted charles dobey, https://bileto.ubuntu.com/#/ticket/2516 Successfully built
<dobey> YAY
<dobey> kenvandine: ugh, looks like unity8 autopkgtests failed setup in zesty :(
<kenvandine> sigh
<dobey> but seems they are running ok in xenial
<kenvandine> they passed last week after the UAL landing
<dobey> sure
<dobey> and nothing here should affect it
<dobey> kenvandine: maybe there's something else in zesty-proposed now, that would cause the ppa autopkgtests to fail, not having allproposed enabled or whatever?
<kenvandine> must be
<dobey> ah yeah of course
<dobey> unity8 is still stuck in proposed
<kenvandine> yes
<kenvandine> but unity8 passed in the silo before and even in proposed
<dobey> yes
<dobey> but that was with the other silo
<kenvandine> i think the silo should be building with proposed
<dobey> this time it's trying to use the old unity8
<dobey> not the one in proposed
<dobey> Broken unity8-tests:amd64 Depends on unity8:amd64 < none | 8.15+17.04.20170216.1-0ubuntu1 @un uH > (= 8.15+17.04.20170216.1-0ubuntu1)
<kenvandine> indeed
<kenvandine> you are right
<dobey> can you retry them with the "all proposed" flag?
<kenvandine> do you know how to do that?
<dobey> i do not
<dobey> i think mterry does
<dobey> mterry: ^^ how to rerun autopkgtests with "all proposed" exactly?
<mterry> dobey: take the normal re-run url, but add &all-proposed=1 to it
<mterry> kenvandine: ^
<dobey> kenvandine: there you go :)
<kenvandine> cool
<kenvandine> dobey, done
<dobey> whoot
<dobey> looks like it is installing now at least
<dobey> hopefully the actual tests won't be flaky this time
<dobey> yay and tests are running
<kenvandine> woot
<dobey> now just have to wait 2.5 hours or whatever for them to finish
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2483 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2483 Successfully built
#ubuntu-ci-eng 2017-02-28
<dobey> kenvandine: well, looks like it passed now. if QA hits it in the morning, perhaps you can publish by the time you start working :)
<kenvandine> dobey, awesome
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2508 Publishing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2508 Proposed pocket
<vigo> dobey, ^
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2517 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- jgdx ahayzen, https://bileto.ubuntu.com/#/ticket/2381 Failed to understand "https://code.launchpad.net/~jonas-drange/ubuntu-ui-extras/force-serial-test-run/+merge/318223". Is it a merge?
<jgdx> trainguards, hey, wonder if you could clear ubuntu-settings-components from silo 2381?
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2381 Preparing packages
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2381 Currently building (xenial/ubuntu-system-settings). Failed to build (zesty/ubuntu-system-settings). Successfully built (xenial/ubuntu-settings-components, xenial/ubuntu-ui-extras, zesty/ubuntu-settings-components, zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2508 Release pocket
<Mirv> jgdx: ok
<Mirv> jgdx: done now, takes some time before bileto's status notices it
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2381 Failed to build (zesty/ubuntu-system-settings). Successfully built (xenial/ubuntu-settings-components, xenial/ubuntu-system-settings, xenial/ubuntu-ui-extras, zesty/ubuntu-settings-components, zesty/ubuntu-ui-extras)
<jgdx> Mirv, thank you
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Preparing packages
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2381 Failed to build (zesty/ubuntu-system-settings). Successfully built (xenial/ubuntu-system-settings, xenial/ubuntu-ui-extras, zesty/ubuntu-ui-extras)
<vigo> tedg_, ping
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Successfully built
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2519 Preparing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2519 Generating diffs
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2519 Failed to build (xenial/qtdeclarative-opensource-src). Ready to build (xenial/qtdeclarative-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 zesty/unity-api: Failed to commit https://code.launchpad.net/~nick-dedekind/unity-api/workspaces. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Pending binary packages (xenial/ubuntu-printing-app). Successfully built (xenial/content-hub, xenial/qtubuntu-print, xenial/ubuntu-ui-extras, zesty/content-hub, zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/unity8). Needs rebuild due to higher version at destination (xenial/unity-api). Needs rebuild due to new commits (zesty/miral, zesty/qtmir, zesty/unity-api, zesty/unity8). Successfully built (xenial/miral, xenial/qtmir, xenial/qtmir-gles, zesty/qtmir-gles)
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Successfully built (xenial/content-hub, xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/ubuntu-ui-extras, zesty/content-hub, zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 zesty/unity-api: Failed to commit https://code.launchpad.net/~nick-dedekind/unity-api/workspaces. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
<dobey> vigo: what's up?
<vigo> dobey, no worries, just pinged you when I approved the silo this morning :)
<dobey> vigo: the big orange ubuntu button in unity8 opens app drawer now.
<vigo> dobey, oh you're looking to the current one
<vigo> dobey, ack :)
<dobey> and looking at the test plan for url-dispatcher i'm not sure it makes any sense
<vigo> dobey, I agree
<dobey> also unity7 doesn't use url-dispatcher
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Pending binary packages (xenial/ubuntu-printing-app). Successfully built (xenial/content-hub, xenial/qtubuntu-print, xenial/ubuntu-ui-extras, zesty/content-hub, zesty/ubuntu-ui-extras)
<vigo> dobey, ok, I'll write it down in trell and approve then
<vigo> everyhting else is fine
<dobey> vigo: it seems like it means to search the wikipedia scope under unity8
<vigo> dobey, that's working
<vigo> and you can link with browser as it is one of the few apps working
<vigo> at least for me :)
<dobey> yeah as long as it's the browser from .deb
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/indicator-keyboard, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-system-settings, xenial/ubuntu-touch-session, xenial/unity8, zesty/indicator-keyboard, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-keyboard, zesty/ubuntu-sys
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/unity8). Needs rebuild due to higher version at destination (xenial/unity-api). Needs rebuild due to new commits (zesty/miral, zesty/qtmir, zesty/unity-api, zesty/unity8). Successfully built (xenial/miral, xenial/qtmir, xenial/qtmir-gles, zesty/qtmir-gles)
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Successfully built (xenial/content-hub, xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/ubuntu-ui-extras, zesty/content-hub, zesty/ubuntu-ui-extras)
<kenvandine> vigo, you marked 2516 as approved in trello but not bileto, could you please approve that?
<dobey> kenvandine: hi. can you ack/publish 2517 too please?
<kenvandine> dobey, sure
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2517 Publishing packages
<vigo> kenvandine, right away
<kenvandine> vigo, thanks!
-queuebot:#ubuntu-ci-eng- kenvandine ted charles dobey, https://bileto.ubuntu.com/#/ticket/2516 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- kenvandine ted charles dobey, https://bileto.ubuntu.com/#/ticket/2516 Publishing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Preparing packages
<dobey> thanks kenvandine
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2517 Proposed pocket (zesty/indicator-printers). Release pocket (xenial/indicator-printers)
-queuebot:#ubuntu-ci-eng- kenvandine ted charles dobey, https://bileto.ubuntu.com/#/ticket/2516 Proposed pocket (zesty/indicator-datetime, zesty/keeper, zesty/url-dispatcher). Release pocket (xenial/indicator-datetime, xenial/keeper, xenial/url-dispatcher)
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2504 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2517 Release pocket
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Needs rebuild due to new commits (zesty/content-hub). Successfully built (xenial/content-hub, xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/ubuntu-ui-extras, zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2519 Failed to build (xenial/qtdeclarative-opensource-src). Ready to build (xenial/qtdeclarative-opensource-src-gles)
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2504 Failed to build (zesty/webbrowser-app). Pending binary packages (xenial/webbrowser-app)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Pending binary packages (xenial/unity8). Successfully built (xenial/indicator-keyboard, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-system-settings, xenial/ubuntu-touch-session, zesty/indicator-keyboard, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-keyboard, zesty/ubuntu-system-settings, zesty/ubu
<oSoMoN> trainguards: can you please re-run https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2504/+build/12067454 ? (flaky test)
<xnox> building
<oSoMoN> thanks!
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2483 Needs rebuild due to new commits (zesty/cmake-extras). Successfully built (xenial/cmake-extras)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Successfully built
-queuebot:#ubuntu-ci-eng- oSoMoN, https://bileto.ubuntu.com/#/ticket/2504 Successfully built
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print). Needs rebuild due to new commits (zesty/content-hub, zesty/ubuntu-printing-app). Successfully built (xenial/content-hub, xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/ubuntu-ui-extras, zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Needs rebuild due to new commits (zesty/indicator-keyboard). Successfully built (xenial/indicator-keyboard, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-system-settings, xenial/ubuntu-touch-session, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-keyboard, zesty/ubuntu-system-settings, 
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 zesty/ubuntu-printing-app: Failed to branch https://code.launchpad.net/~ahayzen/ubuntu-printing-app/add-ubuntu-printing-app
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print). Needs rebuild due to new commits (zesty/content-hub, zesty/ubuntu-printing-app). Successfully built (xenial/content-hub, xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/ubuntu-ui-extras, zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2520 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Pending binary packages (xenial/indicator-keyboard, zesty/indicator-keyboard). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-system-settings, xenial/ubuntu-touch-session, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-keyboard, zesty/ubuntu-system-settings, zesty/ubu
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2483 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2520 Needs rebuild due to new commits
<dobey> kenvandine: hmm, any idea why the ual and new silo stuff hasn't migrated yet? they all seem to be "valid candidate"
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2483 Successfully built
<kenvandine> dobey, looking
<kenvandine> http://people.canonical.com/~ubuntu-archive/transitions/html/libubuntu-app-launch4.html
<kenvandine> dobey, ^^ libertine-scope
<kenvandine> hmmm
<kenvandine> i didn't remember seeing that yesterday
 * kenvandine prepares a branch
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 zesty/unity-api: Failed to commit https://code.launchpad.net/~nick-dedekind/unity-api/workspaces. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
<kenvandine> dobey, i guess libertine-scope isn't complete abandonware... but it doesn't look like it's been buildable for a while
<kenvandine> getting a fix
<dobey> ok
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
<dobey> hmm, i wonder why libertine scope uses ual at all. i thought it was just talking to liberetine directly
<dobey> we should probably work on getting it and click scope both removed from the archive at this point i think, since app drawer takes care of that now
<dobey> ChrisTownsend, bregma: ^^ is that an accurate view of where libertine-scope stands today?
<ChrisTownsend> dobey: Are you asking about whether libertine scope uses ual or are you asking if we should remove it from the archive because of app drawer?
<ChrisTownsend> Or both maybe?:)
<dobey> ChrisTownsend: well, the archive thinks it uses ual, so i don't think you need to answer that. so mostly if we should remove it from the archive
<ChrisTownsend> dobey: Well, I say until the App Drawer has the ability to discern between different containers, then I would vote that it should stay in the archive.  Otherwise, folks using Libertine w/ multiple containers with the same app installed will not know which app they want to launch.  I realize that is kind of a corner case, but we get questions quite a bit about the App Drawer and X apps.
<dobey> has there been any discussion at all with design about how best to do that?
<ChrisTownsend> dobey: Not that I'm aware of.  I keep bringing it up to management too.
<ChrisTownsend> dobey: But it's possible it has been discussed, it just hasn't trickled back to me:)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2521 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2521 zesty/libertine-scope: Failed to branch https://code.launchpad.net/~larryprice/libertine-scope/updated-cmake-extras
<kenvandine> larryprice, ^^
<kenvandine> bileto failed to branch your branch
<larryprice> kenvandine, o no
<kenvandine> weird
<larryprice> kenvandine, says parent does not exist... i may have made a mistake in the ancestry of that branch. we can try again
<kenvandine> ok, i guess start a new branch
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/unity8). Needs rebuild due to new commits (zesty/miral, zesty/qtmir, zesty/unity8). Pending binary packages (xenial/unity-api, zesty/unity-api). Successfully built (xenial/miral, xenial/qtmir, xenial/qtmir-gles, zesty/qtmir-gles)
<dobey> oof
<dobey> kenvandine: erm, just a hiccup in launchpad maybe?
<larryprice> running that command gives me the same result locally
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2521 Preparing packages
<dobey> yup
<dobey> it's building now
<kenvandine> indeed...
<dobey> oh i guess trello is in us-east-1 too
<dobey> whee
<kenvandine> oh that'll help...
<kenvandine> grrr
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/unity8). Needs rebuild due to new commits (zesty/miral, zesty/qtmir, zesty/unity8). Successfully built (xenial/miral, xenial/qtmir, xenial/qtmir-gles, xenial/unity-api, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2521 Pending binary packages
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2521 Successfully built
<kenvandine> rvr, libertine-scope in silo 2521 has no reverse depends, can we ack the rebuild for the UAL transition to unblock zesty promotion?
<kenvandine> rvr, i'd rather not wait for trello to come back online and it doesn't affect any products
<dobey> kenvandine: and all the QA people are already gone, being almost 22:00 in EU
<kenvandine> dobey, that too... rvr seems to often be around though :)
<dobey> or slightly early or later, depending (i guess i have to say UK separately from EU now)
<dobey> i have a silo that i would like to get published asap too, since it's a build tool and QA really doesn't need to do anything for it
<dobey> kenvandine: publish and ask for forgiveness later? :)
<dobey> kenvandine: please? this blockage is getting annoying :)
<dobey> hmm, or maybe i should just manually funge a couple things to make my life a little easier
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2464 Updates pocket
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2467 Updates pocket
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2488 Updates pocket
#ubuntu-ci-eng 2017-03-01
<kenvandine> great... since trello was down when silo 2521 passed autopkgtests, it never got a card added
<kenvandine> sigh
<dobey> kenvandine: so publish it :)
<kenvandine> dobey, i don't think it'll let me
<kenvandine> if it isn't qa approved
<dobey> kenvandine: do 2483 while you're at it :)
<dobey> kenvandine: yeah it don't care about QA signoff i don't think
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2521 QA Signoff: Approved
<vigo> oSoMoN, ping
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/indicator-keyboard, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-system-settings, xenial/ubuntu-touch-session, xenial/unity8, zesty/indicator-keyboard, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-keyboard, zesty/ubuntu-sys
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2520 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2520 PPA/bzr version mismatch
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2520 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 zesty/qtmir: Failed to merge https://code.launchpad.net/~nick-dedekind/qtmir/screens-api
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2520 PPA/bzr version mismatch
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2521 Publishing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/unity8). Needs rebuild due to new commits (zesty/miral, zesty/qtmir, zesty/unity8). Successfully built (xenial/miral, xenial/qtmir, xenial/qtmir-gles, xenial/unity-api, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2521 Proposed pocket (zesty/libertine-scope). Release pocket (xenial/libertine-scope)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2520 Abandoning ticket
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 zesty/unity8: debdiff failed: see log for details
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 zesty/unity8: Failed to branch https://code.launchpad.net/~mzanetti/unity8/fix-blurry-bfb
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/unity8). Needs rebuild due to new commits (zesty/qtmir, zesty/unity8). PPA/bzr version mismatch (zesty/miral). Successfully built (xenial/miral, xenial/qtmir, xenial/qtmir-gles, xenial/unity-api, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/indicator-keyboard, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-system-settings, xenial/ubuntu-touch-session, xenial/unity8, zesty/indicator-keyboard, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-keyboard, zesty/ubuntu-sys
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 zesty/qtmir: Failed to merge https://code.launchpad.net/~nick-dedekind/qtmir/screens-api
<dobey> jibel, rvr: hi, can we get a qa pass for https://bileto.ubuntu.com/#/ticket/2483 please? it didn't end up on trello because of the outage yesterday
<rvr> dobey: Let me see
<jibel> dobey, done
<jibel> rvr, ^
<rvr> Ok
<dobey> thanks
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2483 QA Signoff: Approved
<dobey> kenvandine, mterry, sil2100: can one of you ack/publish //bileto.ubuntu.com/#/ticket/2483 please? :)
<mterry> sure
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2483 Publishing packages
<dobey> mterry: thanks
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2520 Uploading build
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Currently building (xenial/indicator-keyboard, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-system-settings, xenial/unity8, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu-gles, zesty/ubuntu-keyboard, zesty/ubuntu-system-settings). Failed to build (zesty/unity8). Pending binary packages (xenial/ubuntu-touch-session, zesty/qtubuntu, zesty/ubuntu-touch-s
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2522 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/unity8). Needs rebuild due to new commits (zesty/qtmir, zesty/unity8). Pending binary packages (xenial/miral, zesty/miral). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/unity-api, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2520 Pending binary packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2483 Proposed pocket (zesty/cmake-extras). Release pocket (xenial/cmake-extras)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Currently building (zesty/ubuntu-keyboard, zesty/unity8). Failed to build (xenial/qtmir, xenial/ubuntu-system-settings, xenial/unity8, zesty/qtmir, zesty/qtubuntu-gles, zesty/ubuntu-system-settings). Pending binary packages (xenial/indicator-keyboard, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-touch-session, zesty/indicator-keyboard, zesty/qtmir
<Saviq> trainguards, any idea what's going on with builders? there's a slew of build failures in https://bileto.ubuntu.com/#/ticket/2481 that look like so: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2481/+build/12071278
<Saviq> no error message, no build log, nothing... Â¿?
<sil2100> hmm
<dobey> Saviq: https://launchpad.net/builders
<dobey> seems mostly fine though
<sil2100> Interesting, it doesn't even say what builder it was on
<dobey> yeah, those failures are things broke before it got that far
<Saviq> right, so "what's going on with LP" rather than builders...
<sil2100> Saviq: I would poke cjwatson or wgrant
<sil2100> Saviq: and then simply re-run
<sil2100> I'd like them to maybe take a look at it first
<Saviq> yeah, won't rerun before
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Failed to build (xenial/qtmir, xenial/ubuntu-system-settings, xenial/unity8, zesty/qtmir, zesty/qtubuntu-gles, zesty/ubuntu-system-settings). Pending binary packages (xenial/indicator-keyboard, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-touch-session, zesty/indicator-keyboard, zesty/qtmir-gles, zesty/qtubuntu, zesty/ubuntu-keyboard, zesty/ubuntu
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Failed to build (xenial/qtmir, xenial/ubuntu-system-settings, xenial/unity8, zesty/qtmir, zesty/qtubuntu-gles, zesty/ubuntu-system-settings). Pending binary packages (xenial/indicator-keyboard, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-touch-session, zesty/indicator-keyboard, zesty/qtmir-gles, zesty/qtubuntu, zesty/ubuntu-keyboard, zesty/ubuntu
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Failed to build (xenial/qtmir, xenial/ubuntu-system-settings, xenial/unity8, zesty/qtmir, zesty/qtubuntu-gles, zesty/ubuntu-system-settings). Needs rebuild due to new commits (zesty/unity8). Pending binary packages (xenial/indicator-keyboard, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-touch-session, zesty/indicator-keyboard, zesty/qtmir-gles, ze
<cjwatson> Saviq: we've had various network-level problems today.  for now, try retrying
<Saviq> aha
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/ubuntu-printing-app). Failed to build (xenial/content-hub, xenial/ubuntu-printing-app, zesty/content-hub, zesty/qtubuntu-print). Pending binary packages (xenial/ubuntu-ui-extras, zesty/ubuntu-ui-extras). Uploading build (xenial/qtubuntu-print)
<Saviq> sil2100, are we doing overlay for zesty any time soon?
<sil2100> Saviq: didn't get any request for it, but I guess it would make sense
<Saviq> sil2100, I think you'll get requests one people realize things stopped migrating ;)
<sil2100> Saviq: I'll start poking around for it formally then
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Failed to build (xenial/content-hub, xenial/ubuntu-printing-app, zesty/content-hub, zesty/qtubuntu-print, zesty/ubuntu-printing-app). Pending binary packages (xenial/qtubuntu-print, xenial/ubuntu-ui-extras, zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2522 Pending binary packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Currently building (xenial/unity8, zesty/unity8). Failed to build (xenial/ubuntu-system-settings, zesty/qtubuntu-gles, zesty/ubuntu-system-settings). Pending binary packages (xenial/indicator-keyboard, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-touch-session, zesty/indicator-keyboard, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, 
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2483 Release pocket
<dobey> Saviq: things stopped migrating because of ual api/abi break i thought
<dobey> not because archive is frozen
<dobey> i mean, my cmake-extras silo just landed and i didn't have to go bug release team for it
<dobey> i think we're still pretty ok for a couple more weeks there
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
<dobey> kenvandine: hrmm, is something else blocking ual migration now? libertine-scope is "valid candidate" but stuff still seems to be stuck in proposed
<Saviq> dobey, yeah sure, not saying we're blocked already (why aren't we?)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 zesty/qtmir: Failed to merge https://code.launchpad.net/~nick-dedekind/qtmir/screens-api
<dobey> hmm
<dobey> Saviq: well ui freeze isn't until next week
<Saviq> FF is since three weeks, were we not blocked by that before?
<dobey> no, FF doesn't result in the archive being frozen
<dobey> actually i don't think the archive gets frozen until final freeze, and then release team have to approve things
<dobey> but yeah, not supposed to be landing new features right now :)
<dobey> but eh
<jibel> Saviq, after FF you're supposed to focus on stabilization and bug fixes but the archive is not frozen until final freeze and each week of a beta milestone
<Saviq> ah ok FF != FF
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Pending binary packages
<kenvandine> dobey, i don't know why
<dobey> meh
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/unity8). Needs rebuild due to new commits (zesty/qtmir, zesty/unity8). Pending binary packages (xenial/miral, zesty/miral). Successfully built (xenial/qtmir, xenial/qtmir-gles, xenial/unity-api, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Needs rebuild due to new commits (zesty/unity8). Pending binary packages (xenial/indicator-keyboard, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-system-settings, xenial/ubuntu-touch-session, xenial/unity8, zesty/indicator-keyboard, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-keyboard, zesty/ubunt
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Preparing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2522 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2522 Pending binary packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Currently building (xenial/unity8). Failed to build (zesty/unity8). Pending binary packages (xenial/indicator-keyboard, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-system-settings, xenial/ubuntu-touch-session, zesty/indicator-keyboard, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-keyboard, zesty/u
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir, xenial/qtmir-gles, xenial/unity8, zesty/qtmir, zesty/qtmir-gles). Needs rebuild due to new commits (zesty/unity8). Pending binary packages (xenial/miral, zesty/miral). Successfully built (xenial/unity-api, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Failed to build (xenial/content-hub, xenial/ubuntu-ui-extras, zesty/qtubuntu-print, zesty/ubuntu-printing-app). Pending binary packages (xenial/qtubuntu-print, xenial/ubuntu-printing-app, zesty/ubuntu-ui-extras). Uploading build (zesty/content-hub)
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Failed to build (xenial/content-hub, xenial/ubuntu-ui-extras, zesty/qtubuntu-print, zesty/ubuntu-printing-app). Pending binary packages (xenial/qtubuntu-print, xenial/ubuntu-printing-app, zesty/content-hub, zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
<dobey> kenvandine: any luck figuring it out?
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Pending binary packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir, xenial/qtmir-gles, xenial/unity8, zesty/qtmir, zesty/qtmir-gles). Needs rebuild due to new commits (zesty/unity8). Pending binary packages (xenial/miral, xenial/unity-api, zesty/miral, zesty/unity-api)
<dobey> slangasek: hey, can i bug you for a minute to try and figure out why some "valid candidate" packages aren't migrating from zesty-proposed?
<slangasek> dobey: sure, package names?
<dobey> slangasek: libertine-scope indicator-datetime keeper url-dispatcher content-hub indicator-transfer qtmir ubuntu-app-launch ubuntu-push ubuntu-system-settings unity-scope-click unity8
<slangasek> dobey: if you look on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt, you'll see 'Trying easy from autohinter: content-hub [...]'; the lines after that show the list of packages that would be made uninstallable by letting those packages in
<slangasek> dobey: from there that hopefully gives you some idea of what packages are missing a rebuild or such
<dobey> hmmm
<slangasek> dobey: tracking through some of the deps, python3-autopilot looks to be at the base of a lot of it.  Any versioned breaks: going around?
<dobey> yeah it looks like autopilot i guess
<dobey> slangasek: looks like it's becuase of the version gir1.2-ubuntu-app-launch package, having the version changed because of api/abi break
<slangasek> ok
<dobey> slangasek: thanks!
<dobey> kenvandine: ^^ https://code.launchpad.net/~dobey/autopilot/ual-break/+merge/318667
<dobey> mterry: ^^ care to review? looks like you're a member of the autopilot hackers team :)
<mterry> hah only technically, I don't wanna claim to know that code
<dobey> mterry: well, technically i own the team, so... rather not approve my own branch though ;)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2523 Preparing packages
<dobey> kenvandine: building it in a silo now
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2523 Failed to build
<dobey> crap and it uses api that was removed
<dobey> doh, everything is always more complex than it should be
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2523 Failed to build (xenial/autopilot). Needs rebuild due to new commits (zesty/autopilot)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2523 Preparing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2522 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/2520 Successfully built
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2523 Failed to build (xenial/autopilot). Needs rebuild due to new commits (zesty/autopilot)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2523 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir, xenial/qtmir-gles, xenial/unity8, zesty/qtmir, zesty/qtmir-gles). Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/miral, xenial/unity-api, zesty/miral, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Failed to build (xenial/content-hub, xenial/ubuntu-ui-extras, zesty/qtubuntu-print, zesty/ubuntu-printing-app). Successfully built (xenial/qtubuntu-print, xenial/ubuntu-printing-app, zesty/content-hub, zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Successfully built
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2523 Failed to build (xenial/autopilot). Needs rebuild due to new commits (zesty/autopilot)
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 zesty/content-hub: Failed to download DSC file https://launchpad.net/ubuntu/+archive/primary/+files/content-hub_0.3+17.04.20170211-0ubuntu1.dsc
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2523 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Failed to build (zesty/content-hub). Successfully built (xenial/content-hub, xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/ubuntu-ui-extras, zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2523 Failed to build (xenial/autopilot). Needs rebuild due to new commits (zesty/autopilot)
#ubuntu-ci-eng 2017-03-02
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Preparing packages
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Pending binary packages (xenial/content-hub, zesty/content-hub). Successfully built (xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/ubuntu-ui-extras, zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- robru, https://bileto.ubuntu.com/#/ticket/2486 Abandoning ticket
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Successfully built (xenial/content-hub, xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/ubuntu-ui-extras, zesty/content-hub, zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 zesty/unity8: Failed to merge https://code.launchpad.net/~mzanetti/unity8/screens-workspaces-switcher
-queuebot:#ubuntu-ci-eng- Elleo, https://bileto.ubuntu.com/#/ticket/2433 Bad merges (zesty/ubuntu-keyboard). Successfully built (xenial/ubuntu-keyboard)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir, xenial/qtmir-gles, xenial/unity8, zesty/qtmir, zesty/qtmir-gles). Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/miral, xenial/unity-api, zesty/miral, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2519 Ready to build (xenial/qtdeclarative-opensource-src-gles). Successfully built (xenial/qtdeclarative-opensource-src)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2519 Currently building (xenial/qtdeclarative-opensource-src-gles, xenial/qtmir, xenial/qtubuntu, xenial/ubuntu-ui-toolkit, xenial/unity8). Failed to build (xenial/webbrowser-app). Ready to build (xenial/qtmir-gles, xenial/qtubuntu-gles, xenial/ubuntu-ui-toolkit-gles). Successfully built (xenial/qtdeclarative-opensource-src)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2519 Currently building (xenial/ubuntu-ui-toolkit, xenial/unity8). Diff missing (xenial/qtdeclarative-opensource-src-gles, xenial/qtmir, xenial/qtubuntu). Failed to build (xenial/webbrowser-app). Ready to build (xenial/qtmir-gles, xenial/qtubuntu-gles, xenial/ubuntu-ui-toolkit-gles). Successfully built (xenial/qtdeclarative-opensource-src)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2519 Diff missing (xenial/qtdeclarative-opensource-src-gles, xenial/qtmir, xenial/qtubuntu, xenial/unity8). Failed to build (xenial/webbrowser-app). Ready to build (xenial/qtmir-gles, xenial/qtubuntu-gles, xenial/ubuntu-ui-toolkit-gles). Successfully built (xenial/qtdeclarative-opensource-src). Uploading build (xenial/ubuntu-ui-toolkit)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir, xenial/qtmir-gles, xenial/unity8, zesty/qtmir, zesty/qtmir-gles). Needs rebuild due to new commits (zesty/miral, zesty/unity8). Successfully built (xenial/miral, xenial/unity-api, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2519 Diff missing (xenial/qtdeclarative-opensource-src-gles, xenial/qtmir, xenial/qtubuntu, xenial/ubuntu-ui-toolkit, xenial/unity8). Failed to build (xenial/webbrowser-app). Ready to build (xenial/qtmir-gles, xenial/qtubuntu-gles, xenial/ubuntu-ui-toolkit-gles). Successfully built (xenial/qtdeclarative-opensource-src)
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2513 Preparing packages
-queuebot:#ubuntu-ci-eng- pete-woods, https://bileto.ubuntu.com/#/ticket/2513 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2519 Diff missing (xenial/qtdeclarative-opensource-src-gles, xenial/qtmir, xenial/qtubuntu, xenial/ubuntu-ui-toolkit, xenial/unity8, xenial/webbrowser-app). Ready to build (xenial/qtmir-gles, xenial/qtubuntu-gles, xenial/ubuntu-ui-toolkit-gles). Successfully built (xenial/qtdeclarative-opensource-src)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2524 Preparing packages
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2524 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2524 Generating diffs
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2519 Generating diffs
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2519 Successfully built
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2524 Ready to build (xenial/qtmir-gles, xenial/qtubuntu-gles, xenial/ubuntu-ui-toolkit-gles). Successfully built (xenial/qtmir, xenial/qtubuntu, xenial/ubuntu-ui-toolkit, xenial/unity8, xenial/webbrowser-app)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir, xenial/qtmir-gles, xenial/unity8, zesty/qtmir, zesty/qtmir-gles). Needs rebuild due to new commits (zesty/miral, zesty/unity8). Pending binary packages (xenial/unity-api). Successfully built (xenial/miral, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir, xenial/qtmir-gles, xenial/unity8, zesty/qtmir, zesty/qtmir-gles). Needs rebuild due to new commits (zesty/miral, zesty/unity8). Successfully built (xenial/miral, xenial/unity-api, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Needs rebuild due to new commits (zesty/unity8). Pending binary packages (xenial/unity8). Successfully built (xenial/indicator-keyboard, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-system-settings, xenial/ubuntu-touch-session, zesty/indicator-keyboard, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2381 Failed to build (zesty/ubuntu-system-settings). Needs rebuild due to new commits (zesty/ubuntu-ui-extras). Successfully built (xenial/ubuntu-system-settings, xenial/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/indicator-keyboard, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-system-settings, xenial/ubuntu-touch-session, xenial/unity8, zesty/indicator-keyboard, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-keyboard, zesty/ubuntu-sys
-queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2482 Preparing packages
-queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2482 Currently building (zesty/content-hub). Failed to build (xenial/content-hub)
-queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2482 Failed to build
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2529 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2381 Preparing packages
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2381 Currently building (xenial/ubuntu-system-settings, zesty/ubuntu-system-settings). Failed to build (xenial/ubuntu-ui-extras). Pending binary packages (zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 zesty/unity8: Failed to merge https://code.launchpad.net/~mzanetti/unity8/screens-workspaces-switcher
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2529 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2529 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2529 Successfully built
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2381 Currently building (xenial/ubuntu-system-settings, zesty/ubuntu-system-settings). Failed to build (xenial/ubuntu-ui-extras). Successfully built (zesty/ubuntu-ui-extras)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2381 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir, xenial/qtmir-gles, xenial/unity8, zesty/qtmir, zesty/qtmir-gles). Needs rebuild due to new commits (zesty/miral, zesty/unity8). Successfully built (xenial/miral, xenial/unity-api, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2381 Failed to build (xenial/ubuntu-system-settings, xenial/ubuntu-ui-extras). Successfully built (zesty/ubuntu-system-settings, zesty/ubuntu-ui-extras)
<jgdx> trainguards: seems arm64 builds are segfaulting on qml tests again :s
<robru> jgdx: is that that kernel issue?
<kenvandine> jgdx, oh no...
<kenvandine> robru, yes it is
<kenvandine> we need wgrant
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir-gles, xenial/unity-api, xenial/unity8, zesty/qtmir). Needs rebuild due to new commits (zesty/miral, zesty/unity8). Successfully built (xenial/miral, zesty/qtmir-gles, zesty/unity-api). Uploading build (xenial/qtmir)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir-gles, xenial/unity-api, xenial/unity8, zesty/qtmir). Needs rebuild due to new commits (zesty/miral, zesty/unity8). Successfully built (xenial/miral, xenial/qtmir, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2523 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2523 zesty/autopilot: Failed to commit https://code.launchpad.net/~autopilot/autopilot/trunk. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2523 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2523 Pending binary packages (zesty/autopilot). Successfully built (xenial/autopilot)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2523 Successfully built
-queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Preparing packages
-queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Failed to build (xenial/telephony-service, zesty/telepathy-ofono, zesty/telephony-service). Pending binary packages (zesty/history-service). Successfully built (xenial/empathy, xenial/history-service, xenial/telepathy-mission-control-5, xenial/telepathy-ofono, zesty/empathy, zesty/telepathy-mission-control-5)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2531 Preparing packages
-queuebot:#ubuntu-ci-eng- sbalda, https://bileto.ubuntu.com/#/ticket/2530 Abandoning ticket
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Failed to build (xenial/telephony-service, zesty/telepathy-ofono, zesty/telephony-service). Successfully built (xenial/empathy, xenial/history-service, xenial/telepathy-mission-control-5, xenial/telepathy-ofono, zesty/empathy, zesty/history-service, zesty/telepathy-mission-control-5)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2531 Currently building (xenial/ubuntu-app-launch). Failed to build (zesty/ubuntu-app-launch)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir-gles, xenial/unity-api, xenial/unity8, zesty/qtmir, zesty/unity8). Needs rebuild due to new commits (zesty/miral). Successfully built (xenial/miral, xenial/qtmir, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Preparing packages
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir-gles, xenial/unity-api, xenial/unity8, zesty/qtmir). Needs rebuild due to new commits (zesty/miral, zesty/unity8). Successfully built (xenial/miral, xenial/qtmir, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Currently building (xenial/telephony-service). Dependency wait (zesty/telephony-service). Failed to build (xenial/history-service, zesty/history-service, zesty/telepathy-ofono). Successfully built (xenial/empathy, xenial/telepathy-mission-control-5, xenial/telepathy-ofono, zesty/empathy, zesty/telepathy-mission-control-5)
-queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Failed to build (xenial/history-service, zesty/history-service, zesty/telepathy-ofono, zesty/telephony-service). Successfully built (xenial/empathy, xenial/telepathy-mission-control-5, xenial/telepathy-ofono, xenial/telephony-service, zesty/empathy, zesty/telepathy-mission-control-5)
-queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2482 Preparing packages
-queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Preparing packages
-queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2482 Failed to build (xenial/content-hub). Successfully built (zesty/content-hub)
-queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Failed to build (zesty/telepathy-ofono, zesty/telephony-service). Pending binary packages (zesty/history-service). Successfully built (xenial/empathy, xenial/history-service, xenial/telepathy-mission-control-5, xenial/telepathy-ofono, xenial/telephony-service, zesty/empathy, zesty/telepathy-mission-control-5)
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2531 Failed to build
-queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Failed to build (zesty/telepathy-ofono, zesty/telephony-service). Successfully built (xenial/empathy, xenial/history-service, xenial/telepathy-mission-control-5, xenial/telepathy-ofono, xenial/telephony-service, zesty/empathy, zesty/history-service, zesty/telepathy-mission-control-5)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 zesty/unity8: Failed to merge https://code.launchpad.net/~lukas-kde/unity8/fix-window-buttons-touch
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Preparing packages
#ubuntu-ci-eng 2017-03-03
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Failed to build (xenial/unity8). Successfully built (xenial/indicator-keyboard, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-system-settings, xenial/ubuntu-touch-session, zesty/indicator-keyboard, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-keyboard, zesty/ubuntu-system-settings, zesty/ubuntu-touc
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2532 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2532 Pending binary packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2532 Successfully built
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Preparing packages
<Saviq> trainguards, can someone have a look at https://bileto.ubuntu.com/excuses/2523/xenial.html please - it says tests are in progress (for two hours now), but they actually seem lost, looking at http://autopkgtest.ubuntu.com/running :/
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Needs rebuild due to higher version at destination
<Mirv> Saviq: ack, same in my silo https://bileto.ubuntu.com/excuses/2519/xenial.html - we'd need to ping whoever plays pitti at the moment
<Saviq> tx
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Preparing packages
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2534 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Failed to build (xenial/unity8). Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/indicator-keyboard, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-system-settings, xenial/ubuntu-touch-session, zesty/indicator-keyboard, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-keyboard
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2534 Pending binary packages (xenial/miral). Successfully built (zesty/miral)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Currently building (xenial/qtmir). Failed to build (xenial/qtmir-gles, xenial/unity-api, xenial/unity8). Needs rebuild due to new commits (zesty/miral, zesty/unity8). Pending binary packages (zesty/qtmir). Successfully built (xenial/miral, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2534 Successfully built
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir-gles, xenial/unity-api, xenial/unity8). Needs rebuild due to new commits (zesty/miral, zesty/unity8). Pending binary packages (xenial/qtmir). Successfully built (xenial/miral, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api)
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir-gles, xenial/unity-api, xenial/unity8). Needs rebuild due to new commits (zesty/miral, zesty/unity8). Successfully built (xenial/miral, xenial/qtmir, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api)
<Saviq> Mirv, looks like arm64 build fails are back again...
<Saviq> is wgrant the only one that can help?
<Mirv> Saviq: yes, and it was mentioned yesterday already. although, if https://bileto.ubuntu.com/#/ticket/2519 would land we maybe wouldn't need that anymore
<Saviq> Mirv, oh so you got a real fix for that, awesome
<Mirv> Saviq: well it should be, it's just hard to test with the workarounded kernel in place.. although now I could of course really quick compile it in another silo while the new default is available..
<Saviq> Mirv, you could copy it to our silo 2481 :)
<Mirv> anyway, it is testably fixed in 5.7.1 (zesty continued to work during another breakage) and they should be the same patches that are aiming for 5.6.3
<Mirv> Saviq: I'm not sure if it's healthy to copy for the duration of build only without landing it properly. although at least old builds of everything seemed to work fine with new qtdeclarative.
<Mirv> rather than copy though, dependency on that could be added temporarily
<Mirv> and then you can test without my silo
<Saviq> Mirv, bileto will reset PPA deps every status run
<Mirv> ok let's see, arm64 rebuidl ongoing
<Saviq> been there, tried that
<Mirv> Saviq: oh, interesting. but it should be enough when the build starts and the dep is there.
<Saviq> but yeah, maybe you'll be fast enough :)
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2519 Preparing packages
<Mirv> Saviq: was there a functional way to restart autopkgtests results from the beginning without forced rebuilds? La_ney suggested rerunning all the tests, but it's somewhat difficult as the HTML doesn't have the recycle links for those items and I don't have access to the command line tools on the autopkgtest server
<Mirv> I remember at some point simply switching the Lander Signoff was not enough
<Saviq> Mirv, no idea, every time I saw something like this happen people went onto snakefruit to fix it
<Mirv> right, no snakefruit for me
<Mirv> Saviq: maybe you could force rebuild the 2523 then?
<Mirv> I'm trying fake Build run on my manual upload silo, but I remember it didn't use to work
<Saviq> Mirv, not my silo, wouldn't want to step on dobey's toes
<Mirv> Saviq: ok, he can do it then, I commented there
<Laney> Mirv: retry-autopkgtest-regressions --bileto XXX --state RUNNING --series xenial
<Mirv> Laney: ..on snakefruit?
<Laney> no need for any machine access
<Laney> no
<Mirv> oh, that's new then
<Laney> no it's not
<Laney> bzr branch lp:ubuntu-archive-tools contains taht script
<Mirv> yes, I see I have that already. my previous note was that it needs to be executed at snakefruit.
<Laney> it generates URLs
<Saviq> hah, smart
<Mirv> weird, AttributeError: 'NoneType' object has no attribute 'startswith'
<Mirv> oh, right, sorry :)
<Mirv> yeah, works. http://autopkgtest.ubuntu.com/running
<Mirv> nice help too in the tool.
-queuebot:#ubuntu-ci-eng- Mirv, https://bileto.ubuntu.com/#/ticket/2519 Successfully built
<Mirv> Saviq: and arm64 kernel fix validated, thanks to your silo! https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2481/+build/12078016 building debs already
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Preparing packages
<Saviq> Mirv, awesomes
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Failed to build (zesty/telepathy-ofono). Needs rebuild due to new commits (zesty/telephony-service). Successfully built (xenial/empathy, xenial/history-service, xenial/telepathy-mission-control-5, xenial/telepathy-ofono, xenial/telephony-service, zesty/empathy, zesty/history-service, zesty/telepathy-mission-control-5)
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Needs rebuild due to new commits (zesty/unity8). Successfully built (xenial/indicator-keyboard, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-system-settings, xenial/ubuntu-touch-session, xenial/unity8, zesty/indicator-keyboard, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-keyboard, zesty/ubuntu-sys
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Preparing packages
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2522 Publishing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2512 Needs rebuild due to higher version at destination (zesty/qemu). Ready to build (xenial/qemu)
-queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Preparing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2522 Proposed pocket
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Preparing packages
<dobey> hmm
<dobey> jibel: ^^ can we fast track 2523 throough qa please? it's on the qa trello now
-queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2311 Failed to build (xenial/telepathy-qt, zesty/telepathy-qt). Needs rebuild due to new commits (zesty/messaging-app). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/libircclient, xenial/messaging-app, xenial/messaging-framework, xenial/mfw-plugin-irc, zesty/address-book-app, zesty/address-book-service, zesty/libircclient, zesty/messaging-framework, zes
-queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Failed to build (zesty/telepathy-ofono). Needs rebuild due to new commits (zesty/telephony-service). Successfully built (xenial/empathy, xenial/history-service, xenial/telepathy-mission-control-5, xenial/telepathy-ofono, xenial/telephony-service, zesty/empathy, zesty/history-service, zesty/telepathy-mission-control-5)
<jibel> dobey, sure, i'll find someone
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2532 Publishing packages
-queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2482 Preparing packages
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2532 Proposed pocket
-queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2482 Failed to build
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Failed to build (xenial/unity8). Successfully built (xenial/indicator-keyboard, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-system-settings, xenial/ubuntu-touch-session, zesty/indicator-keyboard, zesty/qtmir, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-keyboard, zesty/ubuntu-system-settings, zesty/ubuntu-touc
<Saviq> Mirv, can you please do the dance with https://bileto.ubuntu.com/#/ticket/2481 - thanks :)
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/2532 Release pocket
-queuebot:#ubuntu-ci-eng- Kaleo, https://bileto.ubuntu.com/#/ticket/2533 Failed to build
-queuebot:#ubuntu-ci-eng- kenvandine ahayzen, https://bileto.ubuntu.com/#/ticket/2236 Dependency wait (zesty/qtubuntu-print, zesty/ubuntu-printing-app). Diff missing (xenial/example-printing). Ready to build (zesty/example-printing). Successfully built (xenial/content-hub, xenial/qtubuntu-print, xenial/ubuntu-printing-app, xenial/ubuntu-ui-extras, zesty/content-hub, zesty/ubuntu-ui-extras)
<kenvandine> dobey, woot... the autopilot silo is ready for qa finally :)
<kenvandine> seems even autopilot has flaky tests :-p
<dobey> ?
<dobey> it should be getting tested already
<kenvandine> dobey, i hit retry a couple times for the autopkg tests
<kenvandine> dobey, oh... it's in the ready for testing list
<kenvandine> maybe someone is already testing it though :)
<dobey> kenvandine: i think stuff was just wildly broken outside of autopilot in that regard
<dobey> kenvandine: the ones i saw failing were like compiler crashed and such
<ChrisTownsend> Doesn't seem like autopilot is under QA testing yet and the miral landing just went under testing:(
<dobey> jibel, sbalda: ^^ is autopilot being tested yet or not?
<sbalda> dobey, it is. just tested xenial + overlay. so far so good
<ChrisTownsend> Shewww
<sbalda> dobey, I'll be done in a couple of hours.
<dobey> ok
<jibel> sbalda, I assigned https://trello.com/c/9q0KnpxN/4011-2523-2523-autopilot-dobey to you and moved it to under testing to every one knows what's going on
<sbalda> jibel, ack
<jibel> sbalda, move it to pass or fail when you're done and change the status accordingly on bileto. or ping me or rvr
<sbalda> got it
-queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2381 Failed to build (xenial/ubuntu-system-settings, xenial/ubuntu-ui-extras). Needs rebuild due to new commits (zesty/ubuntu-ui-extras). Successfully built (zesty/ubuntu-system-settings)
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2534 QA Signoff: Approved
<alan_g> trainguards Hi! can we land ticket 2534?
<robru> alan_g: you need a core dev
<alan_g> Oh?
-queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Preparing packages
<robru> alan_g: yes I'm the only train guard that isn't also a core dev. train guards have no special publishing power, haven't for years.
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2523 QA Signoff: Approved
<alan_g> robru: OK, I'll deal with it after the weekend.
-queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2311 Preparing packages
<sil2100> Let me take a look
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2534 Publishing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2523 Publishing packages
-queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2311 Currently building (xenial/messaging-app). Failed to build (xenial/telepathy-qt, zesty/telepathy-qt). Pending binary packages (zesty/messaging-app). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/libircclient, xenial/messaging-framework, xenial/mfw-plugin-irc, zesty/address-book-app, zesty/address-book-service, zesty/libircclient, zesty/messaging-fr
-queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Dependency wait (zesty/telephony-service). Failed to build (xenial/telephony-service, zesty/telepathy-ofono). Successfully built (xenial/empathy, xenial/history-service, xenial/telepathy-mission-control-5, xenial/telepathy-ofono, zesty/empathy, zesty/history-service, zesty/telepathy-mission-control-5)
<dobey> robru: no you're not :)
<robru> dobey: are we counting ted as a train guard?
<dobey> robru: is he not?
<robru> dobey: we trained him on that but I haven't seen him very active lately?
<robru> either way, there's a big imbalance between EU train guards all being core devs and US ones not being.
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2534 Proposed pocket (zesty/miral). Release pocket (xenial/miral)
<dobey> well, technically all core devs are automatically "trainguards" too
<dobey> since the team is a sub-team
<robru> well yeah
<dobey> but yeah
<robru> but not everybody has been trained on it so if you ask random core devs to publish stuff for you they look at you funy
<dobey> yeah
-queuebot:#ubuntu-ci-eng- mzanetti, https://bileto.ubuntu.com/#/ticket/2373 Failed to build (xenial/qtmir-gles, xenial/unity-api, xenial/unity8). Needs rebuild due to higher version at destination (xenial/miral). Needs rebuild due to new commits (zesty/miral, zesty/unity8). Successfully built (xenial/qtmir, zesty/qtmir, zesty/qtmir-gles, zesty/unity-api)
<dobey> but we have mostly decent tz coverage. could probably use some apac support though
-queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2311 Failed to build (xenial/telepathy-qt, zesty/telepathy-qt). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/libircclient, xenial/messaging-app, xenial/messaging-framework, xenial/mfw-plugin-irc, zesty/address-book-app, zesty/address-book-service, zesty/libircclient, zesty/messaging-app, zesty/messaging-framework, zesty/mfw-plugin-irc)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2523 Proposed pocket (zesty/autopilot). Release pocket (xenial/autopilot)
<dobey> yay finally
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2534 QA Signoff:
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2534 Destination version missing from changelog (zesty/miral). Release pocket (xenial/miral)
<tedg>  \o/
<robru> uh
<dobey> robru: i take it that was in response to the miral silo?
<robru> dobey: yeah 'destination version missing' looks wrong
<dobey> hmm
<robru> dobey: the code that should recognize that the version in proposed is our version seems not to be firing. it thinks it's an unexpected manual upload, I'm not sure why
<robru> dobey: stranger still is that it worked once and then failed on the second run
<dobey> robru: looks like it failed to push the branch to lp:miral/release
<dobey> robru: so now the state is weird
<robru> dobey: that happens at finalize time, not at publish time
<dobey> robru: right, and miral is in release pocket in zesty now; so it should be in the branch now
<robru> dobey: wow that was the fastest migration ever.
<robru> dobey: maybe the "weird state" is that it was moved from -proposed to -release while the status job was running.
<dobey> maybe
<dobey> i definitely wouldn't discount the possibility of a race in code that relies on other code on a different server being in a certain state, to work right :)
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2534 QA Signoff: Approved
-queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2534 Release pocket
<robru> dobey: ah, I reran the status job and it's finalizing now: https://bileto.ubuntu.com/log/2534/status/27/
<robru> lunch!
-queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2311 Preparing packages
-queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2311 Failed to build (xenial/telepathy-qt, zesty/telepathy-qt). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/libircclient, xenial/messaging-framework, xenial/mfw-plugin-irc, zesty/address-book-app, zesty/address-book-service, zesty/libircclient, zesty/messaging-app, zesty/messaging-framework, zesty/mfw-plugin-irc). Uploading build (xenial/messaging-app
-queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Failed to build (zesty/telepathy-ofono, zesty/telephony-service). Pending binary packages (xenial/history-service, xenial/telephony-service, zesty/history-service). Successfully built (xenial/empathy, xenial/telepathy-mission-control-5, xenial/telepathy-ofono, zesty/empathy, zesty/telepathy-mission-control-5)
-queuebot:#ubuntu-ci-eng- tiagosh bfiller boiko, https://bileto.ubuntu.com/#/ticket/2311 Failed to build (xenial/telepathy-qt, zesty/telepathy-qt). Successfully built (xenial/address-book-app, xenial/address-book-service, xenial/libircclient, xenial/messaging-app, xenial/messaging-framework, xenial/mfw-plugin-irc, zesty/address-book-app, zesty/address-book-service, zesty/libircclient, zesty/messaging-app, zesty/messaging-framework, zesty/mfw-plugin-irc)
-queuebot:#ubuntu-ci-eng- renatofilho tiagosh boiko, https://bileto.ubuntu.com/#/ticket/2318 Failed to build (zesty/telepathy-ofono, zesty/telephony-service). Successfully built (xenial/empathy, xenial/history-service, xenial/telepathy-mission-control-5, xenial/telepathy-ofono, xenial/telephony-service, zesty/empathy, zesty/history-service, zesty/telepathy-mission-control-5)
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2523 Release pocket
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2535 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2535 zesty/autopilot-legacy: Failed to commit https://code.launchpad.net/~dobey/autopilot/drop-ual. You must supply either a Commit Message on your MP, or a custom debian/changelog entry
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2535 Preparing packages
#ubuntu-ci-eng 2017-03-04
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2535 Failed to build
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2535 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2535 Pending binary packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2535 Successfully built
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2535 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2535 Successfully built
#ubuntu-ci-eng 2017-03-05
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2535 Preparing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2535 Successfully built
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2535 Publishing packages
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2535 Proposed pocket
-queuebot:#ubuntu-ci-eng- kenvandine, https://bileto.ubuntu.com/#/ticket/2521 Release pocket
-queuebot:#ubuntu-ci-eng- dobey, https://bileto.ubuntu.com/#/ticket/2535 Release pocket
-queuebot:#ubuntu-ci-eng- kenvandine ted charles dobey, https://bileto.ubuntu.com/#/ticket/2516 Release pocket
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2531 Preparing packages
-queuebot:#ubuntu-ci-eng- tedg, https://bileto.ubuntu.com/#/ticket/2531 Failed to build
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Preparing packages
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 zesty/qtmir: Failed to merge https://code.launchpad.net/~alan-griffiths/qtmir/tidy-mirserver-deps
-queuebot:#ubuntu-ci-eng- ltinkl, https://bileto.ubuntu.com/#/ticket/2481 Failed to build (xenial/unity8). Needs rebuild due to new commits (zesty/qtmir). Successfully built (xenial/indicator-keyboard, xenial/qtmir, xenial/qtmir-gles, xenial/qtubuntu, xenial/qtubuntu-gles, xenial/ubuntu-keyboard, xenial/ubuntu-system-settings, xenial/ubuntu-touch-session, zesty/indicator-keyboard, zesty/qtmir-gles, zesty/qtubuntu, zesty/qtubuntu-gles, zesty/ubuntu-keyboard, zesty/ubuntu
#ubuntu-ci-eng 2018-02-26
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Diff missing (bionic/qt3d-opensource-src, bionic/qtbase-opensource-src, bionic/qtcharts-opensource-src, bionic/qtconnectivity-opensource-src, bionic/qtdeclarative-opensource-src, bionic/qtgraphicaleffects-opensource-src, bionic/qtimageformats-opensource-src, bionic/qtlocation-opensource-src, bionic/qtmultimedia-opensource-src, bionic/qtquickcontrols-opensource-src, bionic/qtquickcontrols2-opens
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Diff missing
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Currently building (bionic/analitza, bionic/gammaray, bionic/pythonqt, bionic/qtav, bionic/qtcreator). Diff missing (bionic/qt3d-opensource-src, bionic/qtbase-opensource-src, bionic/qtcharts-opensource-src, bionic/qtconnectivity-opensource-src, bionic/qtdeclarative-opensource-src, bionic/qtgraphicaleffects-opensource-src, bionic/qtimageformats-opensource-src, bionic/qtlocation-opensource-src, b
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Currently building (bionic/gammaray, bionic/pythonqt, bionic/qtcreator). Dependency wait (bionic/qtdoc-opensource-src). Diff missing (bionic/qt3d-opensource-src, bionic/qtbase-opensource-src, bionic/qtcharts-opensource-src, bionic/qtconnectivity-opensource-src, bionic/qtdeclarative-opensource-src, bionic/qtgraphicaleffects-opensource-src, bionic/qtimageformats-opensource-src, bionic/qtlocation-
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Generating diffs
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Currently building (bionic/gammaray, bionic/pythonqt, bionic/qtcreator). Dependency wait (bionic/qtdoc-opensource-src). Failed to build (bionic/pyqt5). Successfully built (bionic/analitza, bionic/qt3d-opensource-src, bionic/qtav, bionic/qtbase-opensource-src, bionic/qtcharts-opensource-src, bionic/qtconnectivity-opensource-src, bionic/qtdeclarative-opensource-src, bionic/qtgraphicaleffects-open
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Currently building (bionic/pythonqt, bionic/qtcreator). Dependency wait (bionic/qtdoc-opensource-src). Failed to build (bionic/gammaray, bionic/pyqt5). Pending binary packages (bionic/sddm). Successfully built (bionic/analitza, bionic/qt3d-opensource-src, bionic/qtav, bionic/qtbase-opensource-src, bionic/qtcharts-opensource-src, bionic/qtconnectivity-opensource-src, bionic/qtdeclarative-opensou
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Currently building (bionic/qtcreator). Dependency wait (bionic/qtdoc-opensource-src). Diff missing (bionic/sddm). Failed to build (bionic/gammaray, bionic/pyqt5). Successfully built (bionic/analitza, bionic/pythonqt, bionic/qt3d-opensource-src, bionic/qtav, bionic/qtbase-opensource-src, bionic/qtcharts-opensource-src, bionic/qtconnectivity-opensource-src, bionic/qtdeclarative-opensource-src, bi
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Dependency wait (bionic/qtdoc-opensource-src). Diff missing (bionic/sddm). Failed to build (bionic/gammaray, bionic/pyqt5). Successfully built (bionic/analitza, bionic/pythonqt, bionic/qt3d-opensource-src, bionic/qtav, bionic/qtbase-opensource-src, bionic/qtcharts-opensource-src, bionic/qtconnectivity-opensource-src, bionic/qtcreator, bionic/qtdeclarative-opensource-src, bionic/qtgraphicaleffec
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3154 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3154 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3175 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/3175 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3175 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3175 Proposed pocket
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Currently building (bionic/qtwebengine-opensource-src). Dependency wait (bionic/qtdoc-opensource-src). Diff missing (bionic/sddm). Failed to build (bionic/gammaray, bionic/pyqt5). Successfully built (bionic/analitza, bionic/pythonqt, bionic/qt3d-opensource-src, bionic/qtav, bionic/qtbase-opensource-src, bionic/qtcharts-opensource-src, bionic/qtconnectivity-opensource-src, bionic/qtcreator, bion
#ubuntu-ci-eng 2018-02-27
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Currently building (bionic/qtwebengine-opensource-src). Dependency wait (bionic/qtdoc-opensource-src, bionic/qtwebview-opensource-src). Diff missing (bionic/sddm). Failed to build (bionic/gammaray, bionic/pyqt5). Successfully built (bionic/analitza, bionic/pythonqt, bionic/qt3d-opensource-src, bionic/qtav, bionic/qtbase-opensource-src, bionic/qtcharts-opensource-src, bionic/qtconnectivity-opens
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Currently building (bionic/gammaray, bionic/qtwebengine-opensource-src). Dependency wait (bionic/qtdoc-opensource-src, bionic/qtwebview-opensource-src). Diff missing (bionic/sddm). Failed to build (bionic/pyqt5). Successfully built (bionic/analitza, bionic/pythonqt, bionic/qt3d-opensource-src, bionic/qtav, bionic/qtbase-opensource-src, bionic/qtcharts-opensource-src, bionic/qtconnectivity-opens
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Currently building (bionic/qtwebengine-opensource-src). Dependency wait (bionic/qtdoc-opensource-src, bionic/qtwebview-opensource-src). Diff missing (bionic/sddm). Failed to build (bionic/gammaray, bionic/pyqt5). Successfully built (bionic/analitza, bionic/pythonqt, bionic/qt3d-opensource-src, bionic/qtav, bionic/qtbase-opensource-src, bionic/qtcharts-opensource-src, bionic/qtconnectivity-opens
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2162 Needs rebuild due to higher version at destination (zesty/aethercast). Ready to build (/:, /: Failed to update local lp:aethercast cache., xenial/Failed, xenial/cache., xenial/isc-dhcp, xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/isc-dhcp, zesty/local, zesty/lp:aethercast, zesty/to, zesty/update). Successfully built (xenial/aethercast)
-queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/2924 Ready to build (/:, /: Failed to update local lp:~tdaitx-bileto/autopkgtest/+git/autopkgtest cache., zesty/Failed, zesty/cache., zesty/local, zesty/lp:~tdaitx-bileto/autopkgtest/+git/autopkgtest, zesty/to, zesty/update). Successfully built (zesty/autopkgtest)
-queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/2930 Needs rebuild due to higher version at destination (artful/autopkgtest). Ready to build (/:, /: Failed to update local lp:~tdaitx-bileto/autopkgtest/+git/autopkgtest cache., artful/Failed, artful/cache., artful/local, artful/lp:~tdaitx-bileto/autopkgtest/+git/autopkgtest, artful/to, artful/update)
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2393 Failed to build (xenial/aethercast). Needs rebuild due to higher version at destination (zesty/aethercast). Ready to build (/:, /: Failed to update local lp:aethercast cache., xenial/Failed, xenial/cache., xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:aethercast, zesty/to, zesty/update)
-queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/2930 Needs rebuild due to new commits (artful/autopkgtest). Ready to build (/:, artful/Failed, artful/cache., artful/local, artful/lp:~tdaitx-bileto/autopkgtest/+git/autopkgtest, artful/to, artful/update)
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2393 Failed to build (xenial/aethercast). Needs rebuild due to new commits (zesty/aethercast). Ready to build (/:, xenial/Failed, xenial/cache., xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:aethercast, zesty/to, zesty/update)
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Currently building (bionic/gammaray, bionic/qtwebengine-opensource-src). Dependency wait (bionic/qtdoc-opensource-src, bionic/qtwebview-opensource-src). Diff missing (bionic/sddm). Failed to build (bionic/pyqt5). Successfully built (bionic/analitza, bionic/pythonqt, bionic/qt3d-opensource-src, bionic/qtav, bionic/qtbase-opensource-src, bionic/qtcharts-opensource-src, bionic/qtconnectivity-opens
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2162 Needs rebuild due to new commits (zesty/aethercast). Ready to build (/:, xenial/Failed, xenial/cache., xenial/isc-dhcp, xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/isc-dhcp, zesty/local, zesty/lp:aethercast, zesty/to, zesty/update). Successfully built (xenial/aethercast)
-queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/2924 Ready to build (/:, zesty/Failed, zesty/cache., zesty/local, zesty/lp:~tdaitx-bileto/autopkgtest/+git/autopkgtest, zesty/to, zesty/update). Successfully built (zesty/autopkgtest)
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Currently building (bionic/qtwebengine-opensource-src). Dependency wait (bionic/qtdoc-opensource-src, bionic/qtwebview-opensource-src). Diff missing (bionic/sddm). Failed to build (bionic/pyqt5). Successfully built (bionic/analitza, bionic/gammaray, bionic/pythonqt, bionic/qt3d-opensource-src, bionic/qtav, bionic/qtbase-opensource-src, bionic/qtcharts-opensource-src, bionic/qtconnectivity-opens
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Currently building (bionic/qtdoc-opensource-src, bionic/qtwebengine-opensource-src). Dependency wait (bionic/qtwebview-opensource-src). Diff missing (bionic/sddm). Failed to build (bionic/pyqt5). Successfully built (bionic/analitza, bionic/gammaray, bionic/pythonqt, bionic/qt3d-opensource-src, bionic/qtav, bionic/qtbase-opensource-src, bionic/qtcharts-opensource-src, bionic/qtconnectivity-opens
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Currently building (bionic/qtwebengine-opensource-src). Dependency wait (bionic/qtwebview-opensource-src). Diff missing (bionic/sddm). Failed to build (bionic/pyqt5). Successfully built (bionic/analitza, bionic/gammaray, bionic/pythonqt, bionic/qt3d-opensource-src, bionic/qtav, bionic/qtbase-opensource-src, bionic/qtcharts-opensource-src, bionic/qtconnectivity-opensource-src, bionic/qtcreator, 
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Dependency wait (bionic/qtwebview-opensource-src). Diff missing (bionic/sddm). Failed to build (bionic/pyqt5). Successfully built (bionic/analitza, bionic/gammaray, bionic/pythonqt, bionic/qt3d-opensource-src, bionic/qtav, bionic/qtbase-opensource-src, bionic/qtcharts-opensource-src, bionic/qtconnectivity-opensource-src, bionic/qtcreator, bionic/qtdeclarative-opensource-src, bionic/qtdoc-openso
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Dependency wait (bionic/qtwebview-opensource-src). Diff missing (bionic/sddm). Failed to build (bionic/pyqt5). Pending binary packages (bionic/qtwebengine-opensource-src). Successfully built (bionic/analitza, bionic/gammaray, bionic/pythonqt, bionic/qt3d-opensource-src, bionic/qtav, bionic/qtbase-opensource-src, bionic/qtcharts-opensource-src, bionic/qtconnectivity-opensource-src, bionic/qtcrea
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3167 Proposed pocket
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Diff missing (bionic/qtwebengine-opensource-src, bionic/qtwebview-opensource-src, bionic/sddm). Pending binary packages (bionic/pyqt5). Successfully built (bionic/analitza, bionic/gammaray, bionic/pythonqt, bionic/qt3d-opensource-src, bionic/qtav, bionic/qtbase-opensource-src, bionic/qtcharts-opensource-src, bionic/qtconnectivity-opensource-src, bionic/qtcreator, bionic/qtdeclarative-opensource
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Diff missing (bionic/qtwebengine-opensource-src, bionic/qtwebview-opensource-src, bionic/sddm). Successfully built (bionic/analitza, bionic/gammaray, bionic/pyqt5, bionic/pythonqt, bionic/qt3d-opensource-src, bionic/qtav, bionic/qtbase-opensource-src, bionic/qtcharts-opensource-src, bionic/qtconnectivity-opensource-src, bionic/qtcreator, bionic/qtdeclarative-opensource-src, bionic/qtdoc-opensou
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Publishing packages
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Publish failed: Diff missing
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Generating diffs
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Successfully built
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Publishing packages
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Publish failed: Packaging diff requires ACK
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Publishing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3176 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/3177 Preparing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3177 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Proposed pocket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3176 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3177 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3176 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3177 Diff missing
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Proposed pocket (bionic/analitza, bionic/gammaray, bionic/pyqt5, bionic/pythonqt, bionic/qt3d-opensource-src, bionic/qtav, bionic/qtbase-opensource-src, bionic/qtconnectivity-opensource-src, bionic/qtcreator, bionic/qtdeclarative-opensource-src, bionic/qtdoc-opensource-src, bionic/qtgraphicaleffects-opensource-src, bionic/qtimageformats-opensource-src, bionic/qtlocation-opensource-src, bionic/q
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3176 Diff missing
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Proposed pocket (bionic/analitza, bionic/gammaray, bionic/pyqt5, bionic/pythonqt, bionic/qt3d-opensource-src, bionic/qtav, bionic/qtbase-opensource-src, bionic/qtconnectivity-opensource-src, bionic/qtcreator, bionic/qtdeclarative-opensource-src, bionic/qtdoc-opensource-src, bionic/qtgraphicaleffects-opensource-src, bionic/qtimageformats-opensource-src, bionic/qtlocation-opensource-src, bionic/q
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3176 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3176 Diff missing
-queuebot:#ubuntu-ci-eng- tsimonq2, https://bileto.ubuntu.com/#/ticket/3113 Proposed pocket (bionic/analitza, bionic/gammaray, bionic/pyqt5, bionic/pythonqt, bionic/qt3d-opensource-src, bionic/qtav, bionic/qtbase-opensource-src, bionic/qtconnectivity-opensource-src, bionic/qtcreator, bionic/qtdeclarative-opensource-src, bionic/qtdoc-opensource-src, bionic/qtgraphicaleffects-opensource-src, bionic/qtimageformats-opensource-src, bionic/qtlocation-opensource-src, bionic/q
#ubuntu-ci-eng 2018-02-28
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3176 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3176 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3178 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/3176 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer mdeslaur leosilva, https://bileto.ubuntu.com/#/ticket/3179 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- cpaelzer mdeslaur leosilva, https://bileto.ubuntu.com/#/ticket/3181 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- cpaelzer mdeslaur leosilva, https://bileto.ubuntu.com/#/ticket/3180 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- cpaelzer mdeslaur leosilva, https://bileto.ubuntu.com/#/ticket/3179 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer mdeslaur leosilva, https://bileto.ubuntu.com/#/ticket/3180 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer mdeslaur leosilva, https://bileto.ubuntu.com/#/ticket/3181 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3178 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3178 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3178 Proposed pocket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3176 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer mdeslaur leosilva, https://bileto.ubuntu.com/#/ticket/3179 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer mdeslaur leosilva, https://bileto.ubuntu.com/#/ticket/3180 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer mdeslaur leosilva, https://bileto.ubuntu.com/#/ticket/3181 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3176 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3032 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3032 Diff missing (xenial/device-tree-compiler). Failed to build (xenial/qemu)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3182 Diff missing (bionic/networking-bagpipe, bionic/networking-bgpvpn, bionic/networking-odl, bionic/networking-ovn, bionic/networking-sfc, bionic/neutron-dynamic-routing, bionic/neutron-fwaas, bionic/neutron-lbaas, bionic/neutron-lbaas-dashboard). Pending binary packages (bionic/neutron)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3182 Generating diffs
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3182 Pending binary packages (bionic/neutron). Successfully built (bionic/networking-bagpipe, bionic/networking-bgpvpn, bionic/networking-odl, bionic/networking-ovn, bionic/networking-sfc, bionic/neutron-dynamic-routing, bionic/neutron-fwaas, bionic/neutron-lbaas, bionic/neutron-lbaas-dashboard)
-queuebot:#ubuntu-ci-eng- jamespage coreycb, https://bileto.ubuntu.com/#/ticket/3182 Preparing packages
-queuebot:#ubuntu-ci-eng- jamespage coreycb, https://bileto.ubuntu.com/#/ticket/3182 Publishing packages
-queuebot:#ubuntu-ci-eng- jamespage coreycb, https://bileto.ubuntu.com/#/ticket/3182 Proposed pocket
-queuebot:#ubuntu-ci-eng- jamespage coreycb, https://bileto.ubuntu.com/#/ticket/3182 Proposed pocket (bionic/networking-bagpipe, bionic/networking-bgpvpn, bionic/networking-sfc, bionic/neutron, bionic/neutron-dynamic-routing, bionic/neutron-fwaas, bionic/neutron-lbaas, bionic/neutron-lbaas-dashboard). Release pocket (bionic/networking-odl, bionic/networking-ovn)
-queuebot:#ubuntu-ci-eng- jamespage coreycb, https://bileto.ubuntu.com/#/ticket/3182 Proposed pocket (bionic/networking-bagpipe, bionic/networking-sfc, bionic/neutron, bionic/neutron-dynamic-routing, bionic/neutron-fwaas, bionic/neutron-lbaas, bionic/neutron-lbaas-dashboard). Release pocket (bionic/networking-bgpvpn, bionic/networking-odl, bionic/networking-ovn)
-queuebot:#ubuntu-ci-eng- jamespage coreycb, https://bileto.ubuntu.com/#/ticket/3182 Proposed pocket (bionic/networking-sfc, bionic/neutron, bionic/neutron-dynamic-routing, bionic/neutron-fwaas, bionic/neutron-lbaas). Release pocket (bionic/networking-bagpipe, bionic/networking-bgpvpn, bionic/networking-odl, bionic/networking-ovn, bionic/neutron-lbaas-dashboard)
#ubuntu-ci-eng 2018-03-01
-queuebot:#ubuntu-ci-eng- jamespage coreycb, https://bileto.ubuntu.com/#/ticket/3182 Release pocket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3183 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/3183 Diff missing
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3133 Ready to build (/:, xenial/Failed, xenial/cache., xenial/local, xenial/lp:bamf/xenial, xenial/lp:libunity/xenial, xenial/to, xenial/update). Updates pocket (xenial/bamf, xenial/libunity)
#ubuntu-ci-eng 2018-03-02
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/3158 Release pocket
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3138 Release pocket
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/3155 Release pocket
-queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/3156 Needs rebuild due to new commits
-queuebot:#ubuntu-ci-eng- Trevinho, muktupavels, https://bileto.ubuntu.com/#/ticket/3184 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, muktupavels, https://bileto.ubuntu.com/#/ticket/3184 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, muktupavels, https://bileto.ubuntu.com/#/ticket/3184 Publishing packages
-queuebot:#ubuntu-ci-eng- Trevinho, muktupavels, https://bileto.ubuntu.com/#/ticket/3184 Proposed pocket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3178 Release pocket
-queuebot:#ubuntu-ci-eng- Trevinho, muktupavels, https://bileto.ubuntu.com/#/ticket/3184 Release pocket
#ubuntu-ci-eng 2020-02-24
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Pending binary packages
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Diff missing
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3936 Successfully built
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3936 Generating diffs
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3936 Successfully built
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs, focal/gnome-shell). Diff missing (focal/gnome-shell-extensions, focal/mozjs68). Needs building (focal/mutter). Pending binary packages (focal/adwaita-icon-theme, focal/yaru-theme)
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3938 Ready to build
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs, focal/gnome-shell). Diff missing (focal/gnome-shell-extensions, focal/mozjs68, focal/mutter). Pending binary packages (focal/adwaita-icon-theme, focal/yaru-theme)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs, focal/gnome-shell). Diff missing (focal/adwaita-icon-theme, focal/gnome-shell-extensions, focal/mozjs68, focal/yaru-theme). Pending binary packages (focal/mutter)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs, focal/gnome-shell). Diff missing (focal/adwaita-icon-theme, focal/gnome-shell-extensions, focal/mozjs68, focal/mutter, focal/yaru-theme)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs). Diff missing (focal/adwaita-icon-theme, focal/gnome-shell-extensions, focal/mozjs68, focal/mutter, focal/yaru-theme). Pending binary packages (focal/gnome-shell)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs). Diff missing (focal/adwaita-icon-theme, focal/gnome-shell, focal/gnome-shell-extensions, focal/mozjs68, focal/mutter, focal/yaru-theme)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3921 Needs rebuild due to higher version at destination
#ubuntu-ci-eng 2020-02-25
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2637 Ready to build (/:, vivid/Failed, vivid/cache., vivid/local, vivid/lp:~phablet-team/sync-monitor/vivid, vivid/to, vivid/update). Successfully built (vivid/sync-monitor)
-queuebot:#ubuntu-ci-eng- renatofilho, https://bileto.ubuntu.com/#/ticket/2637 Needs rebuild due to new commits (vivid/sync-monitor). Ready to build (/:, vivid/Failed, vivid/cache., vivid/local, vivid/lp:~phablet-team/sync-monitor/vivid, vivid/to, vivid/update)
-queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/3915 Failed to build
-queuebot:#ubuntu-ci-eng- bfiller, https://bileto.ubuntu.com/#/ticket/2277 Needs rebuild due to higher version at destination (xenial/gallery-app, zesty/gallery-app). Ready to build (/:, xenial/Failed, xenial/cache., xenial/local, xenial/lp:gallery-app, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:gallery-app, zesty/to, zesty/update)
-queuebot:#ubuntu-ci-eng- bfiller, https://bileto.ubuntu.com/#/ticket/2277 Needs rebuild due to higher version at destination (xenial/gallery-app). Needs rebuild due to new commits (zesty/gallery-app). Ready to build (/:, xenial/Failed, xenial/cache., xenial/local, xenial/lp:gallery-app, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:gallery-app, zesty/to, zesty/update)
-queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/3915 Failed to build
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3935 Abandoning ticket
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs). Diff missing (focal/adwaita-icon-theme, focal/gnome-shell, focal/gnome-shell-extensions, focal/mozjs68, focal/mutter, focal/yaru-theme). Pending binary packages (focal/gnome-shell-extension-ubuntu-dock)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs). Diff missing (focal/adwaita-icon-theme, focal/gnome-shell, focal/gnome-shell-extension-ubuntu-dock, focal/gnome-shell-extensions, focal/mozjs68, focal/mutter, focal/yaru-theme)
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3939 Preparing packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3940 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/3940 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3940 Diff missing
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3534 Needs rebuild due to higher version at destination (focal/openvswitch, focal/ovn). Pending binary packages (focal/python-configshell-fb, focal/python-rtslib-fb)
-queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3941 Preparing packages
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3534 Diff missing (focal/python-configshell-fb, focal/python-rtslib-fb). Needs rebuild due to higher version at destination (focal/openvswitch, focal/ovn)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs). Diff missing (focal/adwaita-icon-theme, focal/gnome-shell, focal/gnome-shell-extension-ubuntu-dock, focal/gnome-shell-extensions, focal/mozjs68, focal/mutter, focal/yaru-theme). Uploading build (focal/budgie-desktop)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs). Diff missing (focal/adwaita-icon-theme, focal/gnome-shell, focal/gnome-shell-extension-ubuntu-dock, focal/gnome-shell-extensions, focal/mozjs68, focal/mutter, focal/yaru-theme). Pending binary packages (focal/budgie-desktop)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs). Diff missing (focal/adwaita-icon-theme, focal/budgie-desktop, focal/gnome-shell, focal/gnome-shell-extension-ubuntu-dock, focal/gnome-shell-extensions, focal/mozjs68, focal/mutter, focal/yaru-theme)
-queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3534 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3936 Needs rebuild due to higher version at destination (focal/debian-installer). Successfully built (focal/bind9, focal/bind9-libs, focal/isc-dhcp)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3940 Diff missing (focal/libnbd). Pending binary packages (focal/nbdkit)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs). Diff missing (focal/adwaita-icon-theme, focal/budgie-desktop, focal/gnome-shell, focal/gnome-shell-extension-ubuntu-dock, focal/gnome-shell-extensions, focal/mozjs68, focal/yaru-theme). Failed to build (focal/mutter)
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3936 Needs rebuild due to higher version at destination (focal/bind9, focal/debian-installer). Successfully built (focal/bind9-libs, focal/isc-dhcp)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3940 Diff missing (focal/libnbd). Pending binary packages (focal/nbdkit)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3942 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/3942 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3940 Diff missing (focal/libnbd). Pending binary packages (focal/nbdkit)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3942 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3942 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3940 Diff missing (focal/nbdkit). Pending binary packages (focal/libnbd)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3940 Diff missing
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs). Diff missing (focal/adwaita-icon-theme, focal/budgie-desktop, focal/gnome-shell, focal/gnome-shell-extension-ubuntu-dock, focal/gnome-shell-extensions, focal/mozjs68, focal/mutter, focal/yaru-theme)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs). Diff missing (focal/adwaita-icon-theme, focal/budgie-desktop, focal/gnome-shell-extension-ubuntu-dock, focal/gnome-shell-extensions, focal/mozjs68, focal/mutter, focal/yaru-theme). Pending binary packages (focal/gnome-shell)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs). Diff missing (focal/adwaita-icon-theme, focal/budgie-desktop, focal/gnome-shell, focal/gnome-shell-extension-ubuntu-dock, focal/gnome-shell-extensions, focal/mozjs68, focal/mutter, focal/yaru-theme)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3942 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3936 Needs rebuild due to higher version at destination (focal/bind9, focal/debian-installer, focal/isc-dhcp). Successfully built (focal/bind9-libs)
#ubuntu-ci-eng 2020-02-26
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs). Diff missing (focal/adwaita-icon-theme, focal/budgie-desktop, focal/gnome-shell, focal/gnome-shell-extension-ubuntu-dock, focal/gnome-shell-extensions, focal/mozjs68, focal/mutter, focal/yaru-theme). Pending binary packages (focal/gnome-shell-extension-appindicator)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs). Diff missing (focal/adwaita-icon-theme, focal/budgie-desktop, focal/gnome-shell, focal/gnome-shell-extension-appindicator, focal/gnome-shell-extension-ubuntu-dock, focal/gnome-shell-extensions, focal/mozjs68, focal/mutter, focal/yaru-theme)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3932 Abandoning ticket
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3940 Diff missing (focal/libnbd). Needs rebuild due to higher version at destination (focal/nbdkit)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3940 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3943 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/3943 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3943 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3943 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3943 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3943 Pending binary packages (focal/libcap2). Successfully built (focal/bubblewrap)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3943 Diff missing (focal/libcap2). Successfully built (focal/bubblewrap)
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3943 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3943 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3944 Ready to build
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs). Diff missing (focal/adwaita-icon-theme, focal/budgie-desktop, focal/gnome-shell, focal/gnome-shell-extension-appindicator, focal/gnome-shell-extension-ubuntu-dock, focal/gnome-shell-extensions, focal/mozjs68, focal/mutter, focal/yaru-theme). Pending binary packages (focal/gnome-shell-extension-desktop-icons)
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3945 Preparing packages
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3945 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs). Diff missing (focal/adwaita-icon-theme, focal/budgie-desktop, focal/gnome-shell, focal/gnome-shell-extension-appindicator, focal/gnome-shell-extension-desktop-icons, focal/gnome-shell-extension-ubuntu-dock, focal/gnome-shell-extensions, focal/mozjs68, focal/mutter, focal/yaru-theme)
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3945 Diff missing
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3945 Generating diffs
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3945 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3900 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3945 Successfully built
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3936 Abandoning ticket
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3946 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3946 Pending binary packages
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3946 Diff missing
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3946 Generating diffs
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3946 Successfully built
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3946 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/3947 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/3947 Pending binary packages
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/3947 Diff missing
-queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/3915 Successfully built
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/3947 Generating diffs
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/3947 Successfully built
-queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/3915 Pending binary packages
-queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/3915 Successfully built
-queuebot:#ubuntu-ci-eng- ahasenack, https://bileto.ubuntu.com/#/ticket/3945 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs). Diff missing (focal/adwaita-icon-theme, focal/budgie-desktop, focal/gnome-shell, focal/gnome-shell-extension-appindicator, focal/gnome-shell-extension-ubuntu-dock, focal/gnome-shell-extensions, focal/mozjs68, focal/mutter, focal/yaru-theme). Needs rebuild due to higher version at destination (focal/gnome-shell-extension-desktop-icons)
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3948 Preparing packages
#ubuntu-ci-eng 2020-02-27
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3943 Needs rebuild due to higher version at destination (focal/bubblewrap). Successfully built (focal/libcap2)
-queuebot:#ubuntu-ci-eng- sil2100, https://bileto.ubuntu.com/#/ticket/3947 Proposed pocket
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3949 Preparing packages
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3949 Generating diffs
-queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/3949 Successfully built
-queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/3950 Preparing packages
-queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/3952 Preparing packages
-queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/3953 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3954 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/3955 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/3955 Generating diffs
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3954 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3955 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3955 Abandoning ticket
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3954 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3956 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/3956 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3956 Diff missing
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3956 Pending binary packages
-queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/3952 Successfully built
-queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/3953 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3956 Diff missing
-queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/3950 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3956 Generating diffs
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3956 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3956 Pending binary packages
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3956 Successfully built
-queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3956 Needs rebuild due to higher version at destination
#ubuntu-ci-eng 2020-02-28
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3944 Generating diffs
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3944 Ready to build
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3944 Generating diffs
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3944 Release pocket (focal/gnome-shell-extension-desktop-icons). Successfully built (focal/gjs, focal/gnome-shell, focal/gnome-shell-extension-appindicator, focal/gnome-shell-extension-ubuntu-dock, focal/mutter, focal/yaru-theme)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3944 Publishing packages
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs). Diff missing (focal/adwaita-icon-theme, focal/budgie-desktop, focal/gnome-shell-extensions, focal/mozjs68). Needs rebuild due to higher version at destination (focal/gnome-shell, focal/gnome-shell-extension-appindicator, focal/gnome-shell-extension-desktop-icons, focal/gnome-shell-extension-ubuntu-dock, focal/mutter, focal/yaru-theme)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3944 Proposed pocket (focal/gjs, focal/gnome-shell, focal/gnome-shell-extension-appindicator, focal/gnome-shell-extension-ubuntu-dock, focal/mutter, focal/yaru-theme). Release pocket (focal/gnome-shell-extension-desktop-icons)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3957 Preparing packages
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3944 Proposed pocket (focal/gjs, focal/gnome-shell, focal/gnome-shell-extension-ubuntu-dock, focal/mutter). Release pocket (focal/gnome-shell-extension-appindicator, focal/gnome-shell-extension-desktop-icons, focal/yaru-theme)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3944 Pending binary packages (focal/budgie-desktop). Proposed pocket (focal/gjs, focal/gnome-shell, focal/gnome-shell-extension-ubuntu-dock, focal/mutter). Release pocket (focal/gnome-shell-extension-appindicator, focal/gnome-shell-extension-desktop-icons, focal/yaru-theme)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3944 Diff missing (focal/budgie-desktop). Proposed pocket (focal/gjs, focal/gnome-shell, focal/gnome-shell-extension-ubuntu-dock, focal/mutter). Release pocket (focal/gnome-shell-extension-appindicator, focal/gnome-shell-extension-desktop-icons, focal/yaru-theme)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3957 Generating diffs
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3957 Successfully built (focal/jruby). Uploading build (focal/ruby-psych)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3944 Diff missing (focal/budgie-desktop). Proposed pocket (focal/gnome-shell, focal/gnome-shell-extension-ubuntu-dock, focal/mutter). Release pocket (focal/gjs, focal/gnome-shell-extension-appindicator, focal/gnome-shell-extension-desktop-icons, focal/yaru-theme)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3957 Successfully built
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3957 Generating diffs
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3957 Pending binary packages (focal/jruby). Successfully built (focal/ruby-psych)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3957 Successfully built
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3944 Proposed pocket (focal/budgie-desktop, focal/gnome-shell, focal/gnome-shell-extension-ubuntu-dock, focal/mutter). Release pocket (focal/gjs, focal/gnome-shell-extension-appindicator, focal/gnome-shell-extension-desktop-icons, focal/yaru-theme)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3957 Generating diffs
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3957 Pending binary packages (focal/ruby-psych). Successfully built (focal/jruby)
-queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3954 Abandoning ticket
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3957 Successfully built
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3957 Generating diffs
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3957 Generating diffs
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3957 Generating diffs
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3957 Pending binary packages (focal/ruby-psych). Successfully built (focal/jruby)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3957 Generating diffs
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3957 Successfully built
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3957 Publishing packages
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3957 Merging branches
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Failed to build (focal/ruby-psych). Pending binary packages (focal/jruby)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Generating diffs
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Failed to build (focal/ruby-psych). Pending binary packages (focal/jruby)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Failed to build (focal/ruby-psych). Successfully built (focal/jruby)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Successfully built (focal/jruby). Uploading build (focal/ruby-psych)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Pending binary packages (focal/ruby-psych). Successfully built (focal/jruby)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Successfully built
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Currently building (focal/jruby). Failed to build (focal/ruby-psych)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Failed to build (focal/ruby-psych). Pending binary packages (focal/jruby)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Failed to build (focal/ruby-psych). Successfully built (focal/jruby)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Pending binary packages (focal/jruby). Successfully built (focal/ruby-psych)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Successfully built
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Successfully built (focal/ruby-psych). Uploading build (focal/jruby)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Generating diffs
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Pending binary packages (focal/jruby). Successfully built (focal/ruby-psych)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Generating diffs
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Publishing packages
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Proposed pocket
#ubuntu-ci-eng 2020-02-29
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Proposed pocket (focal/ruby-psych). Release pocket (focal/jruby)
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Needs rebuild due to higher version at destination
-queuebot:#ubuntu-ci-eng- LocutusOfBorg, https://bileto.ubuntu.com/#/ticket/3958 Merging branches
-queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/3658 Failed to build (disco/nux). Ready to build (/:, /: Failed to update local lp:nux cache., disco/Failed, disco/cache., disco/local, disco/lp:nux, disco/to, disco/update)
-queuebot:#ubuntu-ci-eng- andyrock, https://bileto.ubuntu.com/#/ticket/3658 Failed to build (disco/nux). Ready to build (/:, disco/Failed, disco/cache., disco/local, disco/lp:nux, disco/to, disco/update)
-queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/3937 Dependency wait (focal/gjs). Diff missing (focal/adwaita-icon-theme, focal/budgie-desktop, focal/mozjs68). Needs rebuild due to burned version number (focal/gnome-shell-extensions). Needs rebuild due to higher version at destination (focal/gnome-shell, focal/gnome-shell-extension-appindicator, focal/gnome-shell-extension-desktop-icons, focal/gnome-shell-extension-ubuntu-dock, focal/mutter, focal/y
#ubuntu-ci-eng 2020-03-01
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2393 Failed to build (xenial/aethercast). Needs rebuild due to higher version at destination (zesty/aethercast). Ready to build (/:, /: Failed to update local lp:aethercast cache., xenial/Failed, xenial/cache., xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:aethercast, zesty/to, zesty/update)
-queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2393 Failed to build (xenial/aethercast). Needs rebuild due to new commits (zesty/aethercast). Ready to build (/:, xenial/Failed, xenial/cache., xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:aethercast, zesty/to, zesty/update)
