[00:48] <robru> oh
[00:49] <robru> Ursinha: what's happening? is stuff working now? looks like silo 20 migrated
[00:57] <Ursinha> robru: it's slowly coming together
[00:57] <robru> Ursinha: I'm confused as hell. train migration thinks 27.1 is in wily and thus merged, but lp reports latest wily version of media-hub as 22 (eg the proper 27.1 is nowhere to be found)
[00:59] <Ursinha> robru: uh, I can understand there will be lots of inconsistencies, or might be, I'd ask wgrant for advice there
[01:01] <wgrant> robru: https://launchpad.net/ubuntu/+source/media-hub will only show things that are published. https://launchpad.net/ubuntu/+source/media-hub/+publishinghistory would have shown 27.1 as pending at the time of your query.
[01:03] <robru> wgrant: thanks, I see it now
[01:51] <kenvandine> jgdx, :(
[01:51] <kenvandine> random failures suck
[06:39] <oSoMoN> good morning
[06:40] <oSoMoN> ubuntu-qa: migration of oxide-qt and webbrowser-app from proposed to release in wily is blocked by a boottest regression, both of them seem to be bug #1421009 (timed out waiting for Unity greeter), can these tests be re-run please?
[06:58] <jibel> Hey oSoMoN, cihelp ^ can you help ?
[07:34] <seb128> cihelp is anyone working on making those boot test reliable?
[07:34] <seb128> the current address-book-app version is blocked the same way
[07:34] <seb128> the log indicates "EnvironmentError: Unsupported device, autodetect fails device" as the error
[07:34] <seb128> not likely something due to the addressbook itself in this case
[07:36] <seb128> shrug
[07:37] <seb128> sil2100, Mirv, pmcgowan, slangasek, I guess that's not wanted but my bq which was on  rtm-proposed got the vivid update but apparently non-bq version
[07:38] <seb128> e.g it lost HERE, cut the rope, today's lens, etc
[07:38] <seb128> shrug, I knew I shouldn't have applied that update and waited for more feedback from others :-/
[07:55] <Mirv> seb128: urgh. I think there was some channel change before too, those definitely need to be correct.
[07:56] <seb128> do you know how I can fix my device to get my apps/lenses back
[07:56] <seb128> ?
[08:12] <Mirv> seb128: no I don't know (for sure), even though flashing an older image should work
[08:13] <seb128> Mirv, right, I especially don't want to do that
[08:13] <seb128> it's my main phone
[08:14] <seb128> I don't want to wipe it
[08:27] <Mirv> seb128: shouldn't flashing a system image be safe, in general? to user data.
[08:27] <Mirv> without --wipe etc
[08:27] <Mirv> it'd help if we had good backup functionality..
[08:29] <seb128> Mirv, I don't want to do that, I want the upgrade to be fixed for everyone
[08:31] <Mirv> sil2100: hangouts or no hangouts today?
[08:31] <Mirv> seb128: sure, if it's not only rtm-proposed -> vivid it's completely broken, and pretty broken even if it's just rtm-proposed -> vivid
[08:32] <popey> landing call toay?
[08:32] <popey> *today
[08:32] <Mirv> no-one yet besides me, I guess it's up to sil2100 to decide
[08:34] <seb128> Mirv, I didn't change anything, my phone is on rtm-proposed for ever
[08:35] <seb128> Mirv, and that just proposed me an upgrade that wiped out HERE and cut the rope and the bq lenses
[09:30] <pstolowski> trainguards hey, a question; since landings are closed for vivid-overlay atm, what happens to 'dual' landings? will packages be released to wily but queue up and blocked for vivid-overlay?
[09:33] <seb128> I guess no cihelp this yesterday?
[09:33] <seb128> since*
[09:37] <alf_> cihelp: Hi! I would like to change the default parameters of the mir-mediumtests-runner-mako job to add another test suite to run ('mir_privileged_tests').
[09:49] <Mirv> pstolowski: I'd think both are blocked since the landing line is blocked waiting for QA signoff until QA starts again with the queue.
[09:50]  * Mirv hasn't yet published any dual landings, not sure if half of it can be done earlier and half later
[09:54] <pstolowski> Mirv, oh, i see the problem. but that's not good :(
[09:58] <Mirv> pstolowski: the development focus for now is vivid, so delaying wily as itself is not that bad. but it breaks the _flow_ of development if something tested cannot be QA signoff:d / landed so hopefully the gates would be reopened sooner rather than later. but I fear it might be another week.
[09:58] <pstolowski> Mirv, ack :(
[09:59] <Mirv> pstolowski: https://ci-train.ubuntu.com/job/prepare-silo/5048/console some non-MP url:s, could you fix?
[10:01] <pstolowski> Mirv, fixed, sorry about that!
[10:08] <Mirv> thanks!
[10:49] <oSoMoN> cihelp: anyone around to help me with those oxide-qt and webbrowser-app packages blocked in -proposed because of a boottest failure?
[10:58] <Mirv> oh right sil2100 is away today, I had even marked it on my calendar :) well, no-one has anything specific to ask from sil anyway so far.
[10:59] <Mirv> seb128: I still don't seen an actual answer on why you got to vivid from rtm-proposed, but I guess the answer is that only the new ones documented at https://wiki.ubuntu.com/Touch/Channels are "supported" in a sense
[11:00] <Mirv> seb128: I assume current rtm non-proposed channelers will be guided correctly to the ubuntu-touch/stable/bq-aquaris.en
[11:01] <jibel> oSoMoN, I triggered boottests for oxide-qt and webbrowser-app
[11:01] <oSoMoN> jibel, thanks
[11:18] <Mirv> if the boottest problems have reappeared on wily, they should be investigated (when did they start?). the problem was resolved/workarounded on vivid.
[11:19] <Mirv> if it's the same problem in the first place.. that can be seen with the bug report's test case and attaching to the unity8 process.
[11:29] <jibel> oSoMoN, webbrowser passed but oxide-qt failed in test getpkgsrc
[11:31] <oSoMoN> jibel, what does that test do?
[11:31] <jibel> oSoMoN, I have no idea, I don't maintain oxide :)
[11:32] <oSoMoN> jibel, this is not an oxide test
[11:34] <psivaa> oSoMoN: jibel: Failures in boottesting with oxide-qt is known and iirc, the release team does add hint for that to be forced
[11:35] <oSoMoN> psivaa, who do we need to ping to get that whitelisted?
[11:35] <psivaa> oSoMoN: someone in the release team, afaik
[11:35] <psivaa> Foundations i suppose
[11:42] <jibel> psivaa, getpkgsrc is something specific to boottest?
[11:43] <psivaa> jibel: for oxide-qt in phones getpkgsrc doesn't have enough space
[11:43] <jibel> psivaa, OK
[11:43] <jibel> psivaa, maybe it should fail with an error a human can understand?
[11:45] <Laney> It should probably not fail in a way that requires a release team override
[11:45] <Laney> Can someone fix that?
[11:47] <seb128> is somebody supposed to watch the cihelp thing?
[11:47] <Laney> yes
[11:48] <Mirv> the CI team, but I've found cihelp doesn't respond much during early EU hours, more like during afternoon and then onwards. I've been thinking that it should be clearer if the messages go to /dev/null or if they're being logged.
[11:49] <Mirv> the trainguards tag does work since at least me and robert have IRC on 24h so we can take a look at even past requests. but if CI team doesn't have anyone with IRC in a shell it doesn't work and the requesters don't get notified that no-one is listening
[11:49] <jibel> psivaa, looking at getpkgsrc you don't need the source package to find the list of binaries to install, you have all the information you need in the apt index files
[11:50] <Laney> Mirv: In that case maybe it would be better if there were to be a named vanguard in the topic
[11:50] <Laney> So you can know whether to expect service or not
[11:50] <psivaa> ping to cihelp will be answered by the vanguard of the day and most of the days the vanguards are not in the EU timezone
[11:54] <psivaa> jibel: boottesting has some other issues too and is not in the current backlog to take deeper look at... if you would not mind sending an email to the team about any issues that you find it would help
[11:55]  * psivaa slaps him both sides for answering when he is not vanguard
[11:55] <Laney> psivaa-lunch: should we disable it then?
[11:55] <Laney> for wily
[11:55] <Laney> I'm interested in people not wasting their time looking at issues
[11:58] <jibel> Laney, it is not my call but there is no way this test will ever pass, it tries to unpack a package bigger than the physical space available on the device.
[11:59] <jibel> Laney, and the history in jenkins shows that it never passed, and there is no reason to mark it as regression in update_excuses
[12:00] <Laney> jibel: Mmm. Who gives britney that information?
[12:01] <jibel> Laney, CI would know, I never worked on boottest
[12:01] <Laney> Is it their side and not britney's side?
[12:05] <seb128> Mirv, I tried to ping cihelp yesterday european afternoon, this european morning and this european midday, so basically all around the clock on a day and nobody seems to read those...
[12:05] <seb128> ev, ^ is anybody supposed to watch cihelp?
[12:09] <Mirv> seb128: yes, it's most of all that CI is not in Europe at all. usually I've gotten some response at some point in my afternoon, but never in my morning.
[12:09] <seb128> Mirv, well, as said I tried in the afternoon yesterday
[12:09] <Mirv> yep
[12:09] <seb128> and they had all night to look at the issue
[12:09] <seb128> it's a bit ridiculous things just get blocked and ignored this way
[12:10] <Mirv> I agree the 'cihelp' tag should be stopped to be advertised when there's no-one to hear it
[12:11] <cprov> seb128: I was the slack vanguard yesterday (UTC-3), it's probably my personal fault, not the team's. We all watch IRC around the clock (irccloud, mostly)
[12:11] <seb128> cprov, hey
[12:12] <seb128> cprov, how are you?
[12:12] <seb128> cprov, maybe you can help today then? ;-)
[12:13] <cprov> seb128: hey! yes, always. Can you re-paste the issue and save me the time to find it in the logs ... yesterday was pretty hectic on us (PS4 outage)
[12:14] <seb128> cprov, basically address-book-app is blocked in wily-proposed because it has "boot regression" (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html)
[12:14] <seb128> cprov, https://jenkins.qa.ubuntu.com/job/wily-boottest-address-book-app/1/console
[12:15] <seb128> cprov, the error is "EnvironmentError: Unsupported device, autodetect fails device" so I doubt it's something due to the package
[12:15] <Laney> jibel: Looks like boottest doesn't have this concept of regressions
[12:15] <Laney> s/regressions/always failed/
[12:16] <seb128> Laney, are we talking about the issue problem or just similar ones on different packages? ;-)
[12:16] <seb128> the same problem*
[12:16] <Laney> seb128: not the same
[12:16] <seb128> k
[12:16] <cprov> seb128: okay, I am on it, looks like a retry would sort it out, but let me find exactly what caused it
[12:16] <seb128> cprov, it has been retried
[12:16] <seb128> cprov, https://jenkins.qa.ubuntu.com/job/wily-boottest-address-book-app/2/console is the same
[12:17] <seb128> well "retried"
[12:17] <seb128> it's a new upload
[12:17] <seb128> but that's another run and it hit the same error
[12:18] <Laney> jibel: Where did you find the source of the test script? It might be easier to try to fix it or at least make it skip rather than fail
[12:18] <jibel> Laney, lp:ubuntu-test-cases/touch
[12:18] <Laney> thx
[12:18] <jibel> Laney, I found it from the console output
[12:18] <Laney> yeah I'm sure it's in there
[12:19] <Laney> but ... it's pretty hard to read and I knew you had found it :)
[12:19] <cprov> seb128: there was a phone recovering-task at some point last afternoon, let me check if it already helped this issue. If not we will dig further
[12:19] <seb128> cprov, thanks, let me know if I should file a bug about that or something
[12:20] <cprov> seb128: will do
[12:30] <cprov> seb128: it's behaving nicer this time -> http://d-jenkins.ubuntu-ci:8080/view/Wily/view/BootTest/job/wily-boottest-address-book-app/3/console
[12:30] <seb128> cprov, great, do you know what happened in the previous tries? is that a flacky test? is somebody working on making it more reliable?
[12:32] <cprov> seb128: the phone provisioning has a potential/subtle issue and we are working on isolating and fixing it. It's rare, but known at this point.
[12:32] <seb128> k
[12:33] <seb128> is there any report I can subscribe to to see work ongoing there?
[12:34] <cprov> seb128: I wil have to double-check with plars in a bit when he starts, I will subscribe you.
[12:34] <Ursinha> Mirv: seb128, cihelp is the CI vanguard of the day, and as psivaa-lunch said most of us aren't in EU timezone
[12:34] <seb128> cprov, thanks
[12:35] <Ursinha> yesterday there was the outage and we had to firefight that moving to old infrastructure
[12:35] <cprov> seb128: and you have a test-pass
[12:35] <seb128> cprov, thanks!
[12:36] <Mirv> Ursinha: yep, thanks, it's as I thought it was. it might be useful to respond with something to the early EU requests so that they don't feel like going to /dev/null.
[12:36] <seb128> Ursinha, ok, fair enough, I did ping first yesterday on 13:30 utc (http://irclogs.ubuntu.com/2015/05/28/%23ubuntu-ci-eng.html#t15:24), which was after start of day for U.S and several hours before the outage, still got no reply at all, not even an ack that somebody read the ping
[12:41] <Ursinha> seb128: sorry we overlooked your request, if that happens again and you don't mind pinging us again that helps (I've replied to several requests yesterday but I missed yours)
[12:41] <cprov> seb128: when it happens, please escalate to ev or Ursinha, email, phone ... don't be blocked, ever.
[12:43] <Ursinha> Mirv: and what cprov said :) when we don't reply we're not ignoring you, we're just really busy possibly firefighting something else, but we'll always try to get to all requests
[12:43] <cprov> seb128: and since I was the vanguard, the shame is on me.
[12:45] <seb128> Ursinha, hey, no worry, thanks
[12:45] <seb128> cprov, don't be too harsh, I guess I just got unlucky the few times I used "cihelp"
[12:45] <seb128> but as Mirv pointed out, that system doesn't give you back any feedback that your request/question is going to be read
[12:46] <Ursinha> we need a cibot
[12:46] <Ursinha> :)
[12:46] <seb128> so it's easy to get lost wondering if you did the right thing
[12:46] <seb128> if we used bugs or a ticket system you could see the status
[12:46] <Ursinha> "your request is really important to us. please wait on hold while there is no vanguard available"
[12:47] <Laney> cprov: hmm, you know boottest, right?
[12:47] <Laney> cprov: does getpkgsrc have a purpose or can I replace it with a call later on to apt-get source --diff-only?
[12:48] <Ursinha> seb128: that is an interesting idea that might have been suggested and discarded at some point, I'll go today and figure out how to improve that
[12:49] <cprov> Laney: I can't tell you precisely, but how would "apt-get source --diff-only" be better in that case ?
[12:49] <Laney> cprov: oxide-qt's test fails because it is too big to be downloaded to whatever device is being used
[12:49] <Laney> I don't see that it is necessary to download the whole source
[12:50] <Laney> you just copy its debian directory out
[12:50] <seb128> Ursinha, thanks
[12:50] <jibel> Mirv, can you assign an id to lines 22 and 23 of the tarballs sheet?
[12:51] <jibel> I tried from the menu as sil2100 told me but it did assign anything
[12:51] <jibel> didn't*
[12:54] <cprov> Laney: I see, the big-sources issue. It looks like a good idea that I don't remember being mentioned before. I will check with team how it could work and will get back to you, okay ?
[12:55] <Laney> cprov: I have a MP, let me propose it and we can discuss there
[12:55] <cprov> Laney: fantastic! thank you
[13:04] <Laney> cprov: https://code.launchpad.net/~laney/ubuntu-test-cases/touch-boottest-no-download-orig/+merge/260584
[13:04] <Laney> cprov: Sorry to be annoying but it's blocking oxide-qt so I'd appreciate it if someone could review soon-ish :)
[13:05] <Laney> I could skip it but then we lose the real-world test cases
[13:05] <Laney> s/cases/case/
[13:05] <Laney> oSoMoN: ^ btw this is a fix for your issue
[13:07] <Mirv> jibel: sure
[13:07] <jibel> Mirv, sorry, I finally did it
[13:07] <Mirv> jibel: oh, ok :)
[13:07]  * Laney goes to lunch
[13:08] <jibel> Mirv, the requests were not marked 'tested'
[13:08] <Mirv> I haven't used the tarballs sheet myself either
[13:10] <oSoMoN> Laney, awesome, thanks!
[13:12] <plars> cprov: seb128: was there anything else you needed me to look at related to that device? We did see a problem on it yesterday and cprov fixed it iirc, which probably helped clear this up also
[13:12] <seb128> plars, seems fine now, so nothing else from my side for the moment, thanks
[13:27]  * Mirv preparing for sprint, next up in guarding train robert in ~3h. I'll try to glance here though as sil is away today.
[14:22] <oSoMoN> trainguards: can I have a silo for line 59 please?
[14:47] <Mirv> oSoMoN: 001
[14:47] <oSoMoN> Mirv, thanks!
[14:50] <oSoMoN> Mirv, what does this mean? ERROR webbrowser-app 0.23+15.10.20150522.1-0ubuntu1 is missing from the changelog, which has up to 0.23+15.04.20150522.1-0ubuntu1. Please sync destination version back to trunk.
[14:55] <Mirv> oSoMoN: I'm eod and on phone already so I can't check well, but sounds like vivid - wily version clash.
[14:56] <oSoMoN> yeah, I guess it’s expecting wily entries in the changelog, but lp:webbrowser-app only has vivid entries, because so far everything landed first in vivid and was then synced back to wily
[15:02] <jibel> kgunn, ^ silo 19 passed verification, but won't be published to vivid, only wily. correct?
[15:04] <kgunn> jibel: it does actually need to be both...
[15:05] <kgunn> vivid+overlay was in an incorrect state, qtubuntu using an old libmircommon version
[15:05] <kgunn> it obvisously didn't break anything in vivid+overlay since it passed everyones testing
[15:06] <kgunn> but was wrong
[15:06] <kgunn> wily proposed is truly stuck, so we really need to land it there
[15:07] <kgunn> jibel: another way to look at it, that qtubuntu landing _should_ have been part of our original mir0.13.0 landing
[15:07] <kgunn> for vivid+overlay
[15:07] <jibel> kgunn, I understand, publication to vivid will have wait until the image is released. There will be a rebuild to include the last location fix and we don't want silo 19 in.
[15:18] <kgunn> jibel: ok, i understand....wily is the real problem
[15:18] <kgunn> we've clogged the proposed pipe
[15:21] <kgunn> jibel: i noticed alan_g had picked "dual landing" so will it still auto-magically go into wily, even tho it's being held out of vivid+ ??
[15:21] <kgunn> actually might be a question for trainguards ^
[15:35] <kgunn> gotta go dark for a sec
[15:38] <slangasek> seb128: the previous channels had a lot of ambiguity wrt things having the BQ custom or not, and there is no way to redirect a channel to different new channels for the different devices in the channel.  If you want the BQ custom, you should re-flash from one of the bq-aquaris.en channels
[15:39] <seb128> slangasek, couldn't we just not redirect those users and let them opt in to the right channel manually?
[15:39] <slangasek> seb128: as for "fixed for everyone", you were on a -proposed channel, and -proposed channels are meant for developers not users
[15:39] <ogra_> slangasek, then we should block the old channel
[15:39] <ogra_> and not point it to a communiity one
[15:39] <slangasek> seb128: you can do that right now by re-flashing
[15:39] <seb128> slangasek, that's the point, let users do that, rather than propose them an update that screw their device
[15:40] <gQuigs> so it looks like apt (http://people.canonical.com/~ubuntu-archive/pending-sru.html) is stuck as "In Progress"   any idea how to get that reset?
[15:40] <gQuigs> (for precise)
[15:40] <ogra_> you can switch channels very easily with the system-image-cli --switch command ... and i know many bq users did that to switch to a more recent dogfood channel (14.09-proposed) to help finding bugs
[15:41] <ogra_> these users all end up without HERE and without the bq custom stuff with todays update
[15:41] <seb128> that's going to teach them to try to help testing :p
[15:41] <ogra_> yeah
[15:41] <slangasek> seb128: how does this "screw" the device?  It just gives you different content and you have to reflash
[15:41] <slangasek> leaving you on a stale image is also "screwing" the device
[15:41] <ogra_> slangasek, i dont mind either way, but blindly switching users without announcement is slightly evil i think
[15:41] <seb128> slangasek, well, it wiped out some of my config and the apps I use
[15:42] <seb128> HERE, today's scope, ...
[15:42] <slangasek> I'm happy to send out an announcement today
[15:42] <slangasek> seb128: it shouldn't have wiped the config
[15:42] <slangasek> it removes the apps, which you'll get back when you reflash
[15:42] <ogra_> there should at least be an annoncement how to use system-image-cli to switch to a sane channel again
[15:42] <seb128> slangasek, well, unity8 goes "oh, those scope in your config don't exist anymore, they are invalid, let's clean out"
[15:42] <slangasek> oh really
[15:42] <ogra_> re-flashing means you need a PC
[15:42] <slangasek> ok, that's bad
[15:42] <seb128> that as well
[15:42] <slangasek> yes, I'll drop the redirect channel
[15:42] <seb128> thanks
[15:43] <slangasek> well, system-image-cli --switch too
[15:43] <ogra_> yeah, i thinnk thats the easier option
[15:44] <slangasek> seb128: ubuntu-touch/ubuntu-rtm/devel-proposed was the one we were advertising?
[15:44] <ogra_> yeah, ubuntu-touch/ubuntu-rtm/14.09-proposed was the alias
[15:44] <ogra_> (or the other way round, not sure)
[15:44] <slangasek> yes, I'm not after the alias but the name that was in the documentation
[15:45]  * ogra_ has ubuntu-touch/ubuntu-rtm/14.09-proposed in channel.ini
[15:45] <seb128> slangasek, I'm unsure if it was devel- or 14.09-
[15:45] <seb128> I had 14.09
[15:45] <slangasek> the one ogra_ showed me yesterday was ubuntu-touch/ubuntu-rtm/devel-proposed
[15:45] <ogra_> but i dont think we advertised the versioned channels recently
[15:46] <ogra_> knowing they are dead ends
[15:46] <slangasek> it wasn't the 14.09 one, that one had already been changed
[15:46] <ogra_> well, what i showed yesterday was my active krillin ... curremntly on #277 offering me an update to 233
[15:47] <ogra_> (which i didnt apply after reading sebs mail)
[15:47] <slangasek> I've removed the ubuntu-touch/ubuntu-rtm/devel-proposed redirect now
[15:47] <seb128> slangasek, thanks
[15:48] <ogra_> urgh ... i just noticed my krillin only has 39MB free
[15:48] <ogra_> i guess i'll find oout this weekend what happens when i hit the limit
[15:58] <jibel> trainguards, could you publish silo 19 to wily but not to vivid or the overlay ppa?
[16:36] <robru> jibel: yes that can be done, but it involves deleting the vivid packages. is that ok, or should we copy those somewhere safe first?
[16:41] <robru> Mirv: publishing a silo will publish what it finds in the PPA (even if you reconfigure it not as a dual landing!) so if you want to publish only the wily pckages from a dual, you have to delete the vivid packages.
[16:42] <robru> cihelp: can I get a boottest retry on https://jenkins.qa.ubuntu.com/job/wily-boottest-oxide-qt/  ? thanks
[16:42]  * ev looks
[16:44] <robru> ev: oh a couple more here too: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-themes
[16:44] <ev> why are we retrying these?
[16:45] <Laney> these boottests seem seriously fragile
[16:45] <Laney> did it get worse?
[16:46] <robru> ev: because those packages are blocked in proposed?
[16:47] <robru> Laney: yeah I see this a lot, stuff held in proposed because of failed boottest, retry and it works.
[16:47] <ev> retry without understanding if the failure is the test itself?
[16:47] <robru> ev: well I don't know much about boottest. all I know is that I've never seen one that failed honestly. I've only ever seen false positives that went away after retrying.
[16:48] <ev> are you going to retry every time there's a failure at all?
[16:48] <robru> ev: so far it seems like the right approach, if the failure is never indicative of an actual problem in the package.
[16:48] <Laney> it's easy to scan the log to see if it's a real failure
[16:48] <Laney> for example: https://jenkins.qa.ubuntu.com/job/wily-boottest-ubuntu-themes/lastBuild/console
[16:48] <Laney> it tells you that boottest passed and then something blew up afterwards
[16:51] <Laney> this happens so frequently that it's probably worth looking into though
[16:51] <Ursinha> Laney: we will next week
[16:51] <Laney> great
[16:51] <robru> Laney: ev: so you guys think it's legit that a change in ubuntu themes causes a timeout loading unity greeter? my money's on infra issue, needs to be retried.
[16:51] <Ursinha> two cases that are on our radar for investigation and fix are the src being too large (like oxide-qt) and the provisioning having problems
[16:52] <Ursinha> robru: timeout loading unity greeter was a legit bug
[16:52] <Laney> robru: No I explicitly think that this is an infrastructure problem, I'm on your side here
[16:52] <Laney> Ursinha: I filed a merge proposal for that first issue
[16:52] <Ursinha> not in the infra
[16:52] <ev> robru: if there's an underlying bug in unity greeter we should push on that to get fixed, not continously hit CI with the retry hammer
[16:52] <ev> the latter is a great way to paper over serious bugs
[16:52] <robru> Laney: ok thanks. I just find so many stuck boottests that I just ask to retry them without looking at the log anymore.
[16:52] <Laney> Ursinha: if someone wants to review that :)
[16:53] <ev> Laney: where is this?
[16:53] <ev> I'll happily do so
[16:53] <Laney> https://code.launchpad.net/~laney/ubuntu-test-cases/touch-boottest-no-download-orig/+merge/260584
[16:53] <ev> cheers
[16:53] <Laney> oxide-qt is there as a current test case
[16:53] <robru> jgdx: kenvandine: https://ci-train.ubuntu.com/job/ubuntu-landing-036-1-build/12/console is caused by having a wily version number in trunk but having your branch targetted at vivid. you need to either do a dual landing, branch vivid, or mangle the changelog yourself
[16:55] <robru> davmor2: do we want silo 5 in vivid overlay?
[16:56] <ogra_> i think it is supposed to be part of the OTA
[16:58] <Ursinha> Laney: from the top of my head there are only two packages that have big sources, oxide-qt and boost
[16:59] <Mirv> robru: ok thanks
[16:59] <Mirv> makes sense
[16:59] <kenvandine> robru, yeah i think we'll be changing that to a backport branch
[17:00] <kgunn> trainguards hey there, will silo 19 still land/migrate to wily even tho its a dual landing and it's being held out of vivid+ (due to freeze)
[17:00] <kenvandine> jgdx, should we just kill that silo for now?
[17:00] <kgunn> wily is stuck atm for several projects until that lands
[17:00] <Mirv> kgunn: robru answered that 19mins ago. the silo contents need to be exactly what's wanted to be published, ie vivid deleted
[17:01] <robru> kgunn: yeah I need to know if you want the vivid packages deleted, or if we should copy those somewhere safe, because publishing only wily requires deleting vivid packages.
[17:01] <kgunn> thanks Mirv, i was off
[17:01] <kgunn> robru: right, we do eventually want those in vivid+
[17:02] <kgunn> it's just that vivid+ is considered locked down for those
[17:02] <robru> kgunn: ok I'll make a new silo for those and delete them from the current silo so we can publish just wily then.
[17:02] <kgunn> so happy to do whatever we're told
[17:02] <kgunn> e.g. if you can copy somewhere safe for later great
[17:02] <robru> jibel: any ETA on when vivid gates will open again? just curious.
[17:03] <kgunn> robru: and thanks, sorry it's all still a little dynamic
[17:03] <Laney> Ursinha: Maybe now, but we don't know about the future - and more importantly it seems like there's no reason to need the full source anyway
[17:04] <Mirv> mandel: tvoss: needs top-approval https://code.launchpad.net/~mandel/ubuntu-location-provider-here/move-to-vivid/+merge/257910
[17:04] <Ursinha> Laney: sure, just giving you the current situation about the packages I know that fail
[17:04] <robru> kgunn: no worries. just growing pains for the new dual landing feature
[17:04] <Ursinha> Laney: or, I agree :)
[17:05] <Mirv> or rsalveti ^ 005 top-approval
[17:06] <kgunn> thanks, i'll keep an eye on silo32 for the vivid+ thaw
[17:07] <jibel> rsalveti, ^^ can you approve the merges for silo 5?
[17:08] <robru> kgunn: ok I'm not sure why that's exploding but rest assured the packages are safe in the ppa anyway
[17:08] <jibel> robru, after OTA4 on krillin
[17:08] <kgunn> ;)
[17:09] <robru> jibel: yeah but like... how many days away is that? ;-)
[17:15] <robru> kgunn: ok more hiccups, should be publishing now
[17:17] <jibel> robru, when it is ready, sometimes next week
[17:19] <jibel> or tvoss if you're still online, there are unapproved merges in silo 5. that's the last bit we need.
[17:25] <rsalveti> jibel: Mirv: let me check
[17:26] <rsalveti> ChickenCutlass: can you review https://code.launchpad.net/~mandel/ubuntu-location-provider-here/move-to-vivid/+merge/257910 ?
[17:26] <rsalveti> I prefer not reviewing since I have no familiarity with the code
[17:28] <tvoss> jibel, top approved
[17:28] <tvoss> rsalveti, ChickenCutlass ^
[17:35] <jibel> tvoss, thanks
[17:35] <Mirv> tvoss: thanks
[17:36] <jibel> trainguards, can you publish 5 now?
[17:39] <Mirv> jibel: I did.
[17:39] <jibel> Mirv, perfect, how do I know it is available in destination and an image can be built?
[17:42] <ev> Laney: if you'd be so kind, I have a question in https://code.launchpad.net/~laney/ubuntu-test-cases/touch-boottest-no-download-orig/+merge/260584
[17:43] <Mirv> jibel: when they have similar status to others at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages instead of the current symbol + arch list
[17:43] <jibel> Mirv, there is no rmadison4ppa ;)
[17:44] <Mirv> jibel: exactly..
[17:49] <jgdx> kenvandine, didn't we agree on targetting wily? :) /cc robru
[17:50] <jgdx> I'm happy to target wily now, reconfigure, then backport for vivid
[17:50] <robru> jgdx: ok will do
[17:51] <jgdx> robru, hey, thanks.
[17:52] <robru> jgdx: you're welcome
[17:52] <ahayzen> Hey, we switched focus of the music-app from lp:music-app/remix to lp:music-app/refactor and I'm now spotting double autolandings eg http://91.189.93.70:8080/job/music-app-autolanding/686/ and http://91.189.93.70:8080/job/music-app-refactor-autolanding/42/ ... does something on jenkins need to be changed to respect to change of focus?
[17:52] <robru> jgdx: kenvandine: so you'll need to reupload libqofono for wily, right now only the vivid version is in there
[17:53] <robru> ahayzen: sounds like you need cihelp
[17:53] <jgdx> kenvandine, ^r u able?
[17:53] <jgdx> kenvandine, I'd like not to kill it for at least another week.
[17:53] <ev> ahayzen: I'll have a look after lunch
[17:54] <ahayzen> ev, thanks :-)
[17:54] <ahayzen> ev, i suspect it is because there is a job based on trunk and the one on refactor just needs disabling now or something like that
[17:55] <robru> jgdx: ok silo looks good, I deleted the vivid packages so they don't accidentally get published later. if you want you can use the build job to build the wily version now
[17:55] <robru> jgdx: of system settings i mean
[17:57] <jgdx> robru, okay
[18:02] <jibel> Mirv, you confirm that silo 5 is published to the PPA and an image can be buil?
[18:02] <jibel> +t
[18:02] <kenvandine> jgdx, i already uploaded libqofono to wily
[18:03] <kenvandine> and we have the other silo for settings/apn for wily
[18:03] <kenvandine> jgdx, robru: silo 33 is the wily landing for it
[18:04] <kenvandine> i think we should free silo 36
[18:05] <jibel> ogra_, rsalveti if I trust launchpad location-service is now in the overlay PPA, can you trigger a build of vivid? (rc-proposed/meizu.en)
[18:05] <rsalveti> jibel: sure
[18:06] <jibel> rsalveti, thanks
[18:06] <ogra_> rsalveti, while you're at it, a wily build too
[18:06] <ogra_> (to see the last cdimage changes work ... i didnt get to that yet)
[18:06] <rsalveti> ogra_: sure, maybe a beer too I guess
[18:06] <rsalveti> :-)
[18:07] <ogra_> +1
[18:07] <rsalveti> done
[18:07] <rsalveti> just the beer that is a bit more complicated
[18:10] <ogra_> really ?
[18:10]  * ogra_ would hand you one from the sixpack but my arm is so short
[18:16] <rsalveti> lol
[18:31] <robru> kenvandine: hm, silo 33 doesn't have libqofono configured for it
[18:31] <robru> kenvandine: oh I see, 33 and 36 have the same MP. ok I'll free 36 then.
[18:34] <robru> jgdx: sorry for the confusion, just use silo 33, it's the same MP there.
[18:34] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20150529-8e13c5f.changes
[18:34] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-20150529-8e13c5f.tar.xz
[18:34] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_krillin-testresults-20150529-8e13c5f.ods
[18:34] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_vegetahd-20150529-8e13c5f.changes
[18:34] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_vegetahd-20150529-8e13c5f.tar.xz
[18:34] <john-mcaleely> http://people.canonical.com/~jhm/barajas/master/device_vegetahd-testresults-20150512-3912934.ods
[18:35] <john-mcaleely> sil2100, ^ lots of device tarballs for landing early next week
[18:35] <john-mcaleely> :-)
[18:35] <kenvandine> robru, thcx
[18:35] <kenvandine> thx
[19:29] <sil2100> john-mcaleely: oh oh!
[19:29] <sil2100> I just got back, didn't have time to take a look at my IRC session
[19:29] <sil2100> john-mcaleely: how's the situation so far?
[20:25] <ogra_> sigh, so my location that worked wondeful on image 7 (like never before actually) doesnt work at all anymore in image 8
[20:25] <ogra_> (on arale)
[20:26] <ogra_> sil2100, i assume that was not the plan ?
[20:27] <ogra_> hmm, probably because location detection is now completely turned off
[20:27] <ogra_> and i cant enable it
[20:28] <jibel> ogra_, it was definitely not the plan
[20:28] <ogra_> yeah, thought so :)
[20:28] <jibel> ToyKeeper, ^ do you confirm?
[20:28] <ToyKeeper> I'll check.
[20:29] <ogra_> the toggle buttons in the indicator are greyed out
[20:29] <ogra_> so i guess the service doesnt start anymore
[20:29] <ToyKeeper> Sorry, I missed the notice that image 8 had finished.
[20:29] <ogra_> there was none
[20:30] <ogra_> the bot hasnt been ported to the new channel design yet ... and since the new vivid channel has a way lower version now this is quite tricky
[20:31] <jibel> ogra_, confirmed :(
[20:31] <ogra_> what was that silo supposed to fix ? it worked really nice the last image
[20:32] <jibel> ogra_, it was supposed to fix no location on first boot
[20:32] <ogra_> hah
[20:32] <ToyKeeper> Hey, at least every boot is the same now.  :)
[20:33] <ogra_> lol, yeah
[20:33] <jibel> not funny
[20:33] <jibel> ogra_, who can revert the package in the overlay?
[20:34] <jibel> it was location-service
[20:34] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/vivid/20150529.changes
[20:38] <rsalveti> jibel: was silo 5
[20:38] <jibel> rsalveti, yes
[20:38] <rsalveti> same issue we got when we were trying to land it a few days ago
[20:38] <rsalveti> that's why I didn't want to approve the code
[20:38] <rsalveti> of course who did, didn't test
[20:39] <rsalveti> ubuntu-location-provider-here from 0.1+15.04.20141110-0ubuntu1 to 0.1+15.04.20150529-0ubuntu1
[20:39] <jibel> rsalveti, can you revert the package? I think this fix should definitely not go in this release.
[20:39] <rsalveti> that's probably the one
[20:40] <rsalveti> actually, that one was backporting the workaround we had for RTM
[20:40] <rsalveti> so here should be safe
[20:40] <rsalveti> https://code.launchpad.net/~mandel/location-service/simple-trust-store-fix/+merge/260497
[20:40] <rsalveti> this is probably the one that caused it
[20:41] <rsalveti> ogra_: jibel: ToyKeeper: can you try manually reverting that and see if it works again?
[20:44] <rsalveti> /usr/share/upstart/sessions/ubuntu-location-service-trust-stored.conf
[20:45] <rsalveti> brb, walking the dog
[20:45] <jibel> rsalveti, sure, trying now
[20:45] <rsalveti> if it works by manually reverting that I can upload a new package reverting the change
[20:47] <ogra_> that code can never work
[20:47] <ogra_> it doesnt make sure that the session dbus has even started
[20:47] <jibel> I'm wondering how it worked for davmor2_hols when he did the verification
[20:49] <ogra_> sigh, no wifi this boot :(
[20:51] <ToyKeeper> Location works great after 'apt-get install ubuntu-location-provider-here=0.1+15.04.20141110-0ubuntu1'.
[20:52] <jibel> rsalveti, I reverted the change for it is still broken
[20:52] <ToyKeeper> Well, it works anyway...  and it works better than I've seen the arale do for quite a while.
[20:52] <ogra_> image 7 worked awesome already
[20:52] <jibel> rsalveti, lets just revert all of silo 5
[20:52] <jibel> ogra_, agreed
[20:52] <ogra_> yeah, hacking the upstart job definitely doesnt fix it
[20:53] <rsalveti> https://code.launchpad.net/~mandel/ubuntu-location-provider-here/move-to-vivid/+merge/257910
[20:53] <rsalveti> this is the other change for here
[20:53] <rsalveti> but that's just for wizard
[20:53] <rsalveti> need to brb, can check this later today
[20:53] <rsalveti> super weird
[20:54] <ogra_> the diff in the silo PPA is aquite a bit bigger
[20:54] <ogra_> *quite
[20:54] <ogra_> (but that might be LP being silly)
[20:57] <ogra_> ok, reverting the above fixes it
[20:59] <ogra_> rsalveti, it is the wizard thing ... (not sure what the purpose of that thing is at all ... it will run every boot after dbus started)
[21:00]  * ogra_ needs to go afk for a while
[21:29] <ToyKeeper> Hopefully the torrential downpour here will stop before I have a new image for location testing...
[21:36]  * rsalveti back
[21:36] <rsalveti> alright, let me investigate what happened
[21:44] <camako> cihelp : migration of qtubuntu{-gles} from proposed to release in wily is blocked by a boottest regression according to 'excuses', seems to be bug #1421009 (timed out waiting for Unity greeter), can these tests be re-run please?
[21:44] <camako> kgunn ^^
[21:45] <rsalveti> in theory the here-wizard thing only runs as part of the wizard
[21:46] <kgunn> camako: that is weird, testbed pkgs is mir12 ?
[21:46] <kgunn> i thot it would be mir13 since silo 30 is stuck in proposed and that's it's contents
[21:46] <camako> kgunn, well perhaps it didn't get to that point
[21:47] <camako> i.e. got stuck at boottest and didn't get to testbed
[21:47] <kgunn> mmm
[21:48] <camako> kgunn, if you look at the scrollback, the same thing happened with  oxide-qt and webbrowser-app...
[21:49] <kgunn> camako: ta
[21:49] <kgunn> i'll stop freaking out :)
[21:50] <camako> :-)
[22:01] <jibel> rsalveti, there are at least 2 problems, 1. this job runs on every boot not only after the wizard. 2. ubuntu-location-provider-here-slpgwd is already running, so start exit with 1, the job stops and location-service is not restarted
[22:01] <rsalveti> right, but afaik we have the same package on rtm
[22:02] <rsalveti> but yeah, it shouldn't be running at every boot
[22:02] <rsalveti> let me just revert this guy then
[22:02] <jibel> a workaround is to change to start ubuntu-location-provider-here-slpgwd || true but why does it run on every boot
[22:02] <Ursinha> camako: I'll have a look
[22:03] <rsalveti> the start syntax "looks" correct
[22:03] <rsalveti> since it's waiting the create event
[22:04] <rsalveti> maybe it's always getting the create event
[22:04] <camako> than Ursinha
[22:04] <Ursinha> camako: just so you know, oxide-qt is a different problem
[22:05] <Ursinha> camako: that we plan to address early next week, along with other handful of boottest annoyances
[22:05] <camako> Ursinha, ack
[22:05] <rsalveti> yeah, that's because it's not an empty commit
[22:05] <rsalveti> like it says
[22:05] <Ursinha> the unity bug is a real bug unfortunately
[22:06] <Ursinha> (in unity and friends, not boottest)
[22:19] <rsalveti> jibel: I just deleted the here package from the overlay
[22:19] <rsalveti> jibel: it was the first version available in there
[22:19] <rsalveti> so next image will get the previous version from vivid
[22:20] <rsalveti> there are so many issues with this upstart job
[22:23] <rsalveti> https://bugs.launchpad.net/ubuntu/+source/ubuntu-location-provider-here/+bug/1460215
[22:23] <rsalveti> mandel: ^^^
[22:24] <jibel> rsalveti, thanks, can you build an image and I'll really go on week end.
[22:24] <rsalveti> yup, just waiting launchpad to really delete the package
[22:26] <rsalveti> so I should be able to trigger a new image in at most 20 minutes
[22:30] <plars> Ursinha: camako: looks like the first one succeeded, I just rekicked the -gles one also
[22:39] <camako> plars, great thanks
[22:40] <rsalveti> jibel: ToyKeeper: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch/
[22:41] <rsalveti> should be done in ~1:15
[22:41] <ToyKeeper> Thanks.
[22:41] <rsalveti> aaaaaaand I'm out
[22:41]  * rsalveti EOW
[22:46] <plars> camako: and that one passed too
[22:47] <plars> should be reflected in excuses soon
[23:01] <camako> plars, awesome... does that mean they 'll be migrating soon?
[23:02] <plars> camako: well, I don't see them on excuses anymore, so I assume that already happened. But we don't have any control over it at that point
[23:03] <camako> plars, ok.. qtubuntu doesn't show to be in proposed according to rmadison... But it shows the old version in wily :
[23:03] <camako> qtubuntu | 0.60+15.04.20150318-0ubuntu3   | wily/universe                     | source
[23:03] <camako> I'm assuming it's on its way
[23:06] <wgrant> camako: https://launchpad.net/ubuntu/+source/qtubuntu/+publishinghistory
[23:06] <wgrant> That'll show things before they've made it all the way out to rmadison.
[23:07] <camako> wgrant.. Yeap I see it... and mir 0.13.1...
[23:08] <camako> plars, Ursinha, wgrant thank you all for your help..