[00:00] <cjwatson> yeah, there was a totally unnecessary change there, people need to stop being clueless about this :-/
[00:00] <cjwatson> unnecessary and non-productive
[00:01] <cjwatson> robru,bfiller: the reasoning is that we shouldn't have hardcoded arch lists where we don't need to; it's technical debt.  and in this case it didn't help in the slightest because a hardcoded arch list does not have any influence on proposed-migration's rules about regressions in architecture support.
[00:02] <robru> cjwatson, heh.
[00:03] <ogra_> robru, silo 7 is ready
[00:03] <robru> ogra_, thanks
[00:03] <robru> ogra_, please mark it as testing pass in the spreadsheet
[00:03]  * cjwatson is beginning to get the impression that this stuff is only done right when he's around all the time :-/
[00:03] <ogra_> oops, yep
[00:05] <robru> cjwatson, maybe you should lead some kind of info session at the next sprint
[00:05] <cjwatson> "stop freaking out about architectures you don't care about"
[00:05] <cjwatson> end of session
[00:06] <ogra_> :)
[00:06] <cjwatson> basically just leave things alone unless people who know about this stuff tell you otherwise
[00:06] <cjwatson> I mean seriously don't know what else to say
[00:07] <robru> ogra_, ok published
[00:07] <ogra_> thanks
[00:08] <ogra_> bootspeed++ tomorrow ;)
[00:08] <robru> ogra_, great
[00:09] <robru> cjwatson, i would absolutely love to stop freaking out about arches. seems every day there's depwaits causing problems though. maybe if I wasn't spending all my time waiting for you to resolve depwaits I wouldn't freak out about it
[00:11] <cjwatson> but this wasn't a problem
[00:11] <cjwatson> iolypeople freaked out totally unnecessary
[00:11] <cjwatson> sigh
[00:11] <cjwatson> people
[00:11] <cjwatson> freaked out totally unnecessarily
[00:11] <cjwatson> lag
[00:12] <cjwatson> and applied a change that did ABSOLUTELY NOTHING to fix the problem
[00:12] <cjwatson> if people had done the basic due diligence of searching scrollback they would have found that I had explained the problem and solution in detail in this very channel
[00:13] <cjwatson> so I am pretty pissed off that nobody could be bothered
[00:13] <robru> cjwatson, IRC is the most ephemeral communication medium there is. not everybody has scrollback, not everybody was signed on when you said whatever you said. "just read the scrollback" is literally the worst advice you can give anybody.
[00:14] <cjwatson> or, you know, wait until somebody qualified is around before committing flailing patches.
[00:15] <cjwatson> doesn't take that long.
[00:15] <cjwatson> my conclusion is that non-core-devs are not qualified to mess with the Architecture field.
[00:16] <cjwatson> sure, in this case maybe it doesn't matter a whole lot, but this sort of flailing is why new ports are a vastly unnecessary amount of effort.
[00:16] <cjwatson> which is why it annoys me
[00:17] <infinity> Not even just new ports, but an old port suddenly getting a new stack available to it, and then having to unwind all the brain damage to make it work.
[00:17] <infinity> (say, qtdeclarative on powerpc)
[00:17] <cjwatson> it's short-termism.
[00:20] <cjwatson> anyway, I also expected that explaining the situation to the webapps team engineering manager and agreeing with him that he would let me know when they were ready to land and I'd take care of it would be sufficient.
[00:22] <robru> cjwatson, unfortunately bfiller and dbarth are different people. I question the assumption that you can tell dbarth one thing and expect bfiller to know it. I'm flattered, really, but we are not psychic.
[00:23] <cjwatson> I expect people to not flail.
[00:24] <cjwatson> Understand the consequences of your change before making it.    The arch change was made becuase we (get this) *actually thought it would solve the problem*
[00:26] <cjwatson> well sorry but I keep trying to explain this and nobody seems to be listening, so I'm sorry if I get annoyed about it
[00:26] <cjwatson> also just back from the pub :)
[00:26] <infinity> It's not remotely the first time that the harm in arch restriction has been pointed out. :/
[00:26] <cjwatson> but I wish people would recognise that we aren't actually doing these ports for fun
[00:27] <infinity> Perhaps the most forcefully and grumpily.
[00:27] <cjwatson> you and your "cjwatson's personal mission"
[00:27] <cjwatson> I'm trying to get my job done
[00:27] <robru> cjwatson, that was a joke because you're the only person I ever hear talking about this arch stuff.
[00:27] <infinity> robru: Lots of us talk about it.
[00:27] <robru> infinity, not to me, or in this channel.
[00:28] <infinity> robru: But most of us don't hang out in here and talk about it.  Colin braves these waters.
[00:28] <infinity> To be fair, this channel is a really narrow and limited view of Ubuntu development.
[00:28] <robru> infinity, every channel is a really narrow and limited view of ubuntu development. that's the point of having channels.
[00:29] <infinity> Except that crazy ubuntu-devel channel.
[00:29] <infinity> Where this has been pointed out time and again.
[00:29] <cjwatson> I have been saying for a couple of weeks now several variations of the theme "if you have a problem with the non-primary ports, please come and talk to us before you change things, we're happy to help"
[00:29] <infinity> Granted, maybe seb and didier aren't relaying the messages back everytime someone like me gets annoyed, again.
[00:29] <robru> infinity, yep, nope havent' heard about this from seb or didier for sure
[00:30] <robru> cjwatson, yes, I've heard about it from you a few times, I'm sorry that I don't memorize every detail about -proposed, this might surprise you but it's (usually) not very relevant to the work that I do each day.
[00:30] <cjwatson> right, so I've bent over *backwards* to help you guys at some really strange times for me
[00:31] <infinity> robru: If proposed isn't relevant to you, then why go about trying to trick it? :P
[00:31] <cjwatson> I had hoped that this might be an indication that I could be relied upon to help in the future
[00:31] <robru> infinity, because in this rare and isolated case it became relevant briefly.
[00:31] <cjwatson> and you don't have to memorise it, it's documented
[00:33] <infinity> robru: Anyhow, can we pass around the very simple rule that "arch-restriction is for things that literally can never work on an arch" (like, say, powerpc-utils, or intel-pstate).
[00:33] <robru> cjwatson, just checked the scrollback. 3hrs elapsed between when bfiller asked me for the arch details and when you got here. you can't really just expect people to wait 3hrs for whatever without trying things that they can do that they think might help
[00:33] <cjwatson> people expect me to wait three hours for things all the time
[00:33] <robru> infinity, ok, yes, some better communication is warranted
[00:33] <robru> cjwatson, that's not what I said
[00:34] <cjwatson> I'm afraid this is a particular hot button because it's something that causes porting teams to have to do lots of really boring work
[00:34] <robru> cjwatson, of course we can be expected to wait up to a day if you're sleeping or whatever. but what I mean is, it's reasonable that while we're waiting, if we have an idea that we don't realize won't work, we'll try it.
[00:35] <cjwatson> I guess I would be less frustrated if this were the first time
[00:35] <cjwatson> from my perspective this is like the twentieth time I've had this.  I realise that from your perspective this may be unfair, sorry
[00:35] <robru> cjwatson, you're right, I should have remembered, but I didn't, and bfiller just asked for the syntax before I could think it through and remember it wouldn't work
[00:37] <cjwatson> and it's kind of impossible for me to guess who I need to inform about something.  FWIW my comment earlier was basically "I am happy to fix this for you, but please let me know when you're ready to land because if I do it earlier I might end up having to do the work twice and I'd prefer to avoid that"
[00:38] <infinity> "Not knowing who to inform" is why I often just inform seb or didier and I suspect it gets lost in the telephone game.
[00:38] <cjwatson> so I'd expected David to pass that on as necessary because it was explicitly an interaction thing
[00:39] <infinity> I suspect Canonical upstreams aren't really aware of how amazingly opaque some of their uploads appear to the average core-dev, without doing commit-level blames.
[00:39] <cjwatson> I'm not bothered by opacity in this case, I knew what was going on.  But I'd tried to be as helpful as clear as I could be
[00:39] <cjwatson> *and clear
[00:40] <jdstrand> robru: it wasn't ready at the time, but it is now
[00:40] <robru> jdstrand, great
[00:40] <jdstrand> robru: so, yes, if I could have a silo, that would be great (these are just bug fixes)
[00:40] <jdstrand> robru: I'll do the pocket copy like last time
[00:41] <robru> jdstrand, sure thing. you got silo 8
[00:41] <jdstrand> robru: thanks!
[00:41] <robru> jdstrand, you're welcome
[00:42] <robru> cjwatson, ok, well, i don't think there's much left to say at this point. there were many small failures of communication. thanks for fixing the issue on your end. I emailed bill to tell him to revert the arch changes so he'll get to that tomorrow.
[00:42] <cjwatson> ok, I'm sorry for being intemperate
[00:42] <robru> cjwatson, ugh, me too
[00:43] <cjwatson> is that silo ready to land so I can check it, or is it waiting for tomorrow?
[00:43] <cjwatson> (I can't easily check it until it hits -proposed, unfortunately)
[00:45] <robru> cjwatson, bill will have to rebuild it tomorrow, it's not ready
[00:46] <cjwatson> ok, I'll be around until at least 1800 UTC, SMSable after that point
[00:47] <robru> cjwatson, ok thanks
[01:10] <rsalveti> jhodapp|afk: yeah, there's no specific order, you need to make sure the build-deps are specified correctly, and with the right version
[01:11] <jhodapp|afk> rsalveti, yeah I did modify that but it didn't seem to do the trick
[01:12] <jhodapp|afk> rsalveti, media-hub must come before qtubuntu-media, and so I set that build-dep version of media-hub for qtubuntu-media...didn't seem to make a difference
[01:14] <jhodapp|afk> rsalveti, I take that back, it did make a difference, but it seems that the qtubuntu-media build, which uses a header from libmedia-hub-dev, uses headers from libdbus-cpp-dev, but those are missing from the build
[01:14] <cjwatson> if you've set a strict build-dep then it would be impossible for the latter to build without the declared requirements
[01:18] <jhodapp|afk> cjwatson, yeah
[01:18] <cjwatson> jhodapp|afk: which silo's this?
[01:18] <jhodapp|afk> 006
[01:19]  * cjwatson looks
[01:20] <cjwatson> jhodapp|afk: looking at https://launchpadlibrarian.net/170907017/buildlog_ubuntu-trusty-amd64.qtubuntu-media_0.7.1%2B14.04.20140327.4-0ubuntu1_FAILEDTOBUILD.txt.gz, it *looks* as though whatever package ships /usr/include/core/media/player.h is missing a dependency on libproperties-cpp-dev
[01:21] <jhodapp|afk> cjwatson, let me check
[01:21] <jhodapp|afk> cjwatson, nope, it has it as a build-dep
[01:21] <cjwatson> runtime dep
[01:22] <cjwatson> which package ships /usr/include/core/media/player.h ?
[01:22] <jhodapp|afk> libmedia-hub-dev
[01:22] <cjwatson> right, so libmedia-hub-dev should Depends: libproperties-cpp-dev
[01:22] <cjwatson> Build-Depends isn't sufficient - that's only taken into consideration when building media-hub itself
[01:23] <cjwatson> not when building stuff that depends on it
[01:23] <jhodapp|afk> ah, I didn't know that
[01:23] <jhodapp|afk> that makes sense now
[01:23] <jhodapp|afk> cjwatson, thanks
[01:23] <cjwatson> you generally don't want to fill in everything from Build-Depends into your -dev package's Depends, but anything that provides header files you include definitely needs to be there
[01:24] <cjwatson> np
[01:24] <jhodapp|afk> ok
[01:24] <jhodapp|afk> learned something new today :)
[01:24] <cjwatson> either the landing team folks or anyone in ~launchpad-buildd-admins can retry the failed builds after you've fixed media-hub
[01:25] <cjwatson> (no need to trigger a fresh upload of qtubuntu-media)
[01:25] <jhodapp|afk> ok
[01:28] <jhodapp|afk> cjwatson, does that include you?
[01:29] <jhodapp|afk> cjwatson, just pushed the fix, so it's ready to try the build again
[01:34] <cjwatson> jhodapp: it does, although presumably it'll take a little while for media-hub to build and publish
[01:35] <cjwatson> jhodapp: oh, have you poked the jenkins job?
[01:35] <jhodapp> cjwatson, I just pushed a new version of media-hub
[01:37] <cjwatson> jhodapp: right, but just to bzr, by the looks of things?
[01:38] <jhodapp> cjwatson, yes
[01:38] <cjwatson> ok, let me see if I can move that along for you
[01:38] <jhodapp> thanks much
[01:48] <cjwatson> jhodapp: media-hub building
[01:48] <jhodapp> excellent
[01:52] <cjwatson> infinity: I think I need to go to bed - could you retry qtubuntu-media/{amd64,armhf,i386} in https://launchpad.net/~ci-train-ppa-service/+archive/landing-006/+packages once the latest media-hub has built and published there?
[01:53] <infinity> cjwatson: Yeahp.
[01:53] <cjwatson> Ta
[01:55] <bregma> rsalveti, would you be willing to grant me a silo for line 44?
[01:55] <cjwatson> jhodapp: ^- handing over
[01:56] <jhodapp> thanks cjwatson
[02:04] <rsalveti> jhodapp: yeah, runtime build-dep only works automatically like that when you have a dependency at the library level
[02:05] <rsalveti> not in the header itself
[02:05] <rsalveti> but great that cjwatson was able to help you
[02:05]  * rsalveti is preparing dinner
[02:06] <jhodapp> rsalveti, ok, there's still much about packaging
[02:06] <jhodapp> much to learn
[02:06] <rsalveti> jhodapp: do you need me to trigger another build?
[02:06] <jhodapp> rsalveti, yeah, try qtubuntu-media
[02:06] <jhodapp> media-hub just about finished
[02:08] <rsalveti> right, but I can trigger another rebuild for everything
[02:08] <jhodapp> ok
[02:08] <rsalveti> easier and good to know if we're all good in the dep level
[02:08] <rsalveti> bregma: don't have enough permission to allocate a silo :-(
[02:09] <rsalveti> oh, colin did a rebuild in the silo itself
[02:09] <rsalveti> so yeah, let's just wait
[02:09] <rsalveti> brb
[02:41] <infinity> cjwatson: Hrm, was that expected to build? :P
[03:04] <imgbot> [03:34] <jhodapp> rsalveti, did you kick off another build for qtubuntu-media?
[03:35] <rsalveti> jhodapp: nops, can do that
[03:35] <rsalveti> just a sec
[03:35] <jhodapp> rsalveti, k thanks
[03:36] <jhodapp> rsalveti, media-hub builds just fine except for 3 architectures that libhybris isn't built for
[03:36] <rsalveti> right, that's fine
[03:36] <rsalveti> ok, triggered a new build for qtubuntu-media
[03:37] <rsalveti> let's wait a few minutes and we should know if it worked or not
[03:37] <jhodapp> alright, cross your fingers :)
[03:37] <rsalveti> yeah :-)
[03:48] <jhodapp> rsalveti, ok so I just need to temporarily disable the tests for this and then it'll build successfully
[03:50] <rsalveti> are you sure?
[03:50] <rsalveti> ../src/aal/aalvideorenderercontrol.cpp: In member function 'void AalVideoRendererControl::updateVideoTexture()':
[03:50] <rsalveti> ../src/aal/aalvideorenderercontrol.cpp:162:97: error: cast from 'AalMediaPlayerService::GLConsumerWrapperHybris {aka void*}' to 'unsigned int' loses precision [-fpermissive]
[03:50] <rsalveti>          frame.setMetaData("GLConsumer", QVariant::fromValue((unsigned int)m_service->glConsumer()));
[03:50] <rsalveti>                                                                                ^
[03:51] <rsalveti> check the latest build, failed for all arches
[03:52] <rsalveti> armhf failed when running the test cases indeed
[03:52] <jhodapp> rsalveti, yeah that's for the amd64 case and I fixed that earlier for my schroot
[03:52] <rsalveti> and it failed differently on i386
[03:52] <jhodapp> lol
[03:52] <rsalveti> no, this was amd64
[03:52] <jhodapp> ok
[03:52] <rsalveti> sorry, thought you said arm64
[03:52] <jhodapp> I'll fix that too with what I did earlier
[03:53] <rsalveti> https://launchpadlibrarian.net/170926953/buildlog_ubuntu-trusty-i386.qtubuntu-media_0.7.1%2B14.04.20140328-0ubuntu1_FAILEDTOBUILD.txt.gz
[03:53] <rsalveti> jhodapp: right, just let me know when you're ready for another rebuild
[03:53] <jhodapp> k
[03:56] <rsalveti> kgunn: when are you planning to land the landscape mode?
[03:57] <kgunn> rsalveti: let me chat it up tomorrow...its definitely been pushed to back burner....
[03:57] <kgunn> anyone begging for it ?
[03:57] <rsalveti> no, just curious
[03:57] <kgunn> i realize its nice...
[03:57] <kgunn> ok, lemme check
[03:58] <rsalveti> as you said you're about to land the right edge navigation I thought the landscape mode would be close as well
[03:58] <rsalveti> but don't worry, as I said, just curious :-)
[04:07] <jhodapp> rsalveti, so I have a fix for 2 architectures, but the i386 issue I'm not sure about yet...it's a clash between the qgl stuff and the platform GLES headers
[04:08] <rsalveti> weird, conflicting declaration
[04:09] <jhodapp> rsalveti, yeah, which we've seen before but I thought was taken care of more at a platform level
[04:09] <jhodapp> or similar to it
[04:14] <rsalveti> maybe you don't actually need to include the GLES headers when you already included qopengl.h
[04:14] <rsalveti> or qgl.h
[04:14] <rsalveti> just not sure why this didn't happen on amd64
[04:14] <rsalveti> it could be a gles x gl thing (as qt uses gles only on armhf), but not the case here it seems
[04:15] <jhodapp> rsalveti, hmm yeah
[04:15] <jhodapp> rsalveti, I'm going to take a fresh look in the morning, my eyes are too tired
[04:15] <jhodapp> rsalveti, have a great night
[04:17] <rsalveti> yeah, better, you too
[04:30] <imgbot> [04:30] <imgbot> [07:05] <Mirv> jdstrand: I ran "watch only" built for landing-008 / apparmor, the publishing could work now
[07:07] <Mirv> jdstrand: and yes, it worked now
[07:16] <Mirv> didrocks: morning. when you have time, I'm getting an error when using prepare silo http://<IP_ADDRESS>/job/prepare-silo/728/console
[07:16] <didrocks> oh?
[07:16]  * didrocks looks
[07:16] <didrocks> Mirv: what line is it?
[07:16] <Mirv> prepare-silo-using-spreadsheet-info", line 89
[07:17] <didrocks> Mirv: no, I meant on the spreadsheet :)
[07:17] <Mirv> yeah, I was wondering :) line 35 seb
[07:17] <didrocks> ok
[07:17] <Mirv> I first tried the tempting "experimental" option, and got the same error
[07:17] <didrocks> someone should have entered non ascii chars on the spreadsheet I guess
[07:17] <didrocks> yeah
[07:18] <Mirv> ascii should be enough for everybody
[07:19] <didrocks> heh :)
[07:19] <Mirv> yeah, it's on the unity7 landing line
[07:19] <Mirv> ’ character
[07:20] <Mirv> I can remove it or you can debug it
[07:20] <didrocks> let me try something
[07:21] <didrocks> Mirv: fixed!
[07:22] <Mirv> so it seems from your prepare-silo run :)
[07:22] <didrocks> yeah ;)
[07:22] <didrocks> (and deployed)
[07:23] <bzoltan> Hello Mirv, may I ask for  Silo for the line 47?
[07:24] <Mirv> bzoltan: sure
[07:26] <bzoltan> Mirv:  thanks
[07:26] <Mirv> didrocks: there'd be messaging-app packaging ack http://<IP_ADDRESS>/job/landing-001-2-publish/63/artifact/packaging_changes_messaging-app_0.1+14.04.20140327-0ubuntu1.diff
[07:27] <Mirv> bzoltan: landing-010 ready for build
[07:27] <bzoltan> Mirv:  thanks
[07:27] <didrocks> Mirv: +1
[07:28] <Mirv> thanks
[07:29] <Mirv> didrocks: can I bug you with NEW review of qtlocation packaging merge with Debian, for which I got FFe approval bug #1298208 ? FFe just states that I need to find a willing archive admin. it's ready to be published, and splits the -dev package into two plus adds doc packages.
[07:30] <Mirv> the reason for FFe was that the packaging merge introduces those "new" packages (old content though regarding the dev package)
[07:30] <didrocks> Mirv: do you have a debdiff on the bug?
[07:30] <didrocks> Mirv: it's a binary NEW, so yeah
[07:30] <Mirv> didrocks: via the buildlog link, yes https://launchpadlibrarian.net/170841866/qtlocation-opensource-src_5.2.1-0ubuntu1_5.2.1-1ubuntu1.diff.gz
[07:31] <Mirv> it's mitya57's work, I just commented and tested it
[07:32] <didrocks> Mirv: you didn't discuss with him with the finale , and so on?
[07:32] <didrocks> and it's inconsistent, some, still have :/
[07:33] <Mirv> didrocks: finale?
[07:33] <Mirv> so it's consensus on what Debian agrees to do when they package qtlocation fully
[07:33] <didrocks> Mirv: like the last dep having ,
[07:33] <Mirv> yeah, sure, that's just what pkg-kde does
[07:33] <didrocks> argh…
[07:34] <didrocks> I hate when you get useless diff
[07:34] <Mirv> they've removed my ,:s from many places :)
[07:34] <didrocks> Mirv: weird that they impose their standard on us
[07:34] <didrocks> as we are upstream for it
[07:34] <didrocks> Mirv: I don't think it's good to sacrifize that
[07:34] <Mirv> they don't see it that way, they just have their habits and if we keep bigger delta then it's harder for us to diff what's different in packaging to them
[07:35] <Mirv> now I can do diff -urN debian/ ubuntu/ quite easily, but I need to keep on adapting to the styles they use
[07:35] <Mirv> the interesting parts of the diff are the Breaks/Replaces and that qtlocation5-dev depends on the new qtpositioning5-dev, so everything continues to work
[07:36] <Mirv> nothing else has really changed on practical level
[07:36] <didrocks> Mirv: yeah, but what about our consistency?
[07:36] <didrocks> Mirv: anyway, ok, it's not part of the archive review and we are not upstream (as upstream dev) for it
[07:36] <didrocks> so +1
[07:36] <Mirv> didrocks: our Qt packaging is nowadays pretty consistent with Debian, so we have less ending ,:s there to make it easier to diff between the two
[07:36] <didrocks> but don't introduce the same on the other packages please…
[07:37] <Mirv> wrap-and-sort -a -t is the default for everything we are upstream to
[07:37] <didrocks> interesting that they don't unmangle the symbols
[07:37] <didrocks> not sure how it builds on all archs
[07:37] <Mirv> it built fine https://launchpad.net/~ci-train-ppa-service/+archive/landing-016/+packages
[07:39] <didrocks> Mirv: ok, you can release
[07:40] <Mirv> done
[07:40] <Mirv> well, it's in the unapproved queue first since some others seed it
[07:41] <didrocks> ok
[08:02] <didrocks> Mirv: as we are low on silo, I would say let's assign/m&c ourselves today
[08:02] <didrocks> sil2100: ^
[08:02] <didrocks> if people aren't around
[08:10] <Mirv> sure
[08:10] <Mirv> soon at 3 again
[08:14] <ogra_> hmm, seems screen unlocking failed for all tests ... would be so nice to have a powerd and a unity8 log (both had changes related to that)
[08:14] <vila> yeah, just finished deciphering all nagios/pager duty mess about *4* makos having issues, 2 are down now
[08:15] <vila> the others seem to have trigger a bunch of test failures indeed related to screen unlocking
[08:15] <ogra_> right
[08:15] <vila> I've restarted http://q-jenkins.ubuntu-ci:8080/job/trusty-touch-mako-smoke-daily/190/console as a full run
[08:15] <vila> for #265 that is
[08:15] <ogra_> and both, powerd itself (emulator related) and unity8 (taking over power setting management) had changes that could cause this
[08:16] <vila> ogra_: we discussed the raise of mako failures yesterday, no explanation so far
[08:16] <vila> ogra_: ha, great
[08:16] <ogra_> i would actually blame the latter
[08:16] <ogra_> i.e. the dbus address might have changed
[08:16] <vila> ogra_: something that can be reproduced locally ?
[08:17] <ogra_> dunno, 2M line here ... i'm still downloading
[08:17] <ogra_> ;)
[08:17] <vila> ;)
[08:18]  * vila starts diff'ing MB files again O_o
[08:18] <vila> failed to open trace file: [Errno 20] Not a directory: '/dev/null/.bzr.log' yeah really ? Someone did set HOME to /dev/null ???
[08:18] <vila> not a failure, just....
[08:19] <ogra_> created by some automation thingie ?
[08:19] <vila> ogra_: forget about it, just a distraction, probably there for ages
[08:20] <vila> ogra_: sorry for even mentioning it ;)
[08:20] <ogra_> lol
[08:28] <ogra_> aha, seems powerd changed its dbus policy file
[08:28] <ogra_> http://launchpadlibrarian.net/170895519/powerd_0.13%2B14.04.20140129-0ubuntu1_0.13%2B14.04.20140327-0ubuntu1.diff.gz
[08:28]  * ogra_ assumes thats related
[08:31] <sil2100> geh, feel sicklish todays
[08:31] <didrocks> sil2100: :( headache?
[08:32] <didrocks> ogra_: yeah, agreed
[08:33] <sil2100> didrocks: some pain in the bones and nausea, seems like I might be sick during the weekend
[08:33] <sil2100> Lucky me ;p
[08:33] <ogra_> 10min and my install will be done, i'll take a look
[08:33] <didrocks> vila: I'm afraid that if the lock issue is still there, you would have to downgrade powerd on the device (we can help you getting the debs)
[08:33] <didrocks> sil2100: argh, not nice. Too many germs exchange at your exercise time yesterday I guess :/
[08:42] <ogra_> yay
[08:42] <ogra_> http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-265.png
[08:45] <didrocks> ogra_: powerd?
[08:46] <ogra_> didrocks, no, my changes
[08:46] <didrocks> again, all your fault! :)
[08:46] <didrocks> please add that to your testing plan :p
[08:46] <ogra_> all CPU cores are on now so we get a much snappier boot
[08:46] <ogra_> and ureadahead works (as you can see in the disk usage chart there is a big burst at the start)
[08:47] <didrocks> oh, you are not talking about screen unlocking?
[08:47] <ogra_> i'm confident we can get to 20second boots :)
[08:47] <sil2100> didrocks, Mirv: should we still leave 3 silos free, or should we only consider upmost 1?
[08:47] <didrocks> sweet!
[08:47] <ogra_> not at all
[08:47] <ogra_> talking about the good things ;)
[08:48] <didrocks> ogra_: heh, I thought you were on the bad things :)
[08:48]  * ogra_ goes to look at the bad things now
[08:48] <didrocks> sil2100: I would go for it, and maybe assign more even, knowing that we can flush the unity8 split greeter one
[08:48] <didrocks> sil2100: I would really count the flushable as "free ones"
[08:53] <ogra_> http://paste.ubuntu.com/7167330/
[08:53]  * sil2100 feels tempted to push the EXPERIMENTAL button
[08:53] <ogra_> does it blink ?
[08:53] <didrocks> ogra_: interface change?
[08:53] <sil2100> ogra_: no :<
[08:53] <ogra_> didrocks, permission change i think
[08:54] <sil2100> But it's big and bluish
[08:54] <didrocks> sil2100: it's robru doing that change, feel free, especially if you are not logged in
[08:54] <didrocks> I asked him how that would react without getting logged in
[08:54] <didrocks> and I don't know how this works with the options
[08:55] <didrocks> ogra_: so, due to new powerd?
[08:55] <didrocks> ogra_: can you try to revert powerd on your device?
[08:55] <ogra_> didrocks, trying to chnage a part of the policy file change back, lest see
[08:55]  * ogra_ reboots
[08:56] <didrocks> ok :)
[08:56] <ogra_> i think its only two lines at fault here ...
[08:56]  * didrocks always like the "-ic" :)
[08:56] <ogra_> if that doesnt help i'll do a complete revert
[08:56] <didrocks> sounds good :)
[08:56]  * ogra_ wits for the screen to suspend
[08:57] <ogra_> bah, not enough
[08:57] <didrocks> sil2100: rather than giving silos to ricardo, I would prefer we focus on fixing the blockers
[08:57] <didrocks> sil2100: like the line 42 mentionned
[08:58] <didrocks> (41 as well, but not ready yet)
[08:59] <ogra_> didrocks, the prob is that the new autobrightness feature in unity8 uses the new powerd
[08:59] <didrocks> ogra_: they were on the same silo I reckon?
[08:59] <ogra_> no idea
[08:59] <didrocks> seems not
[08:59] <didrocks> Saviq: if we revert powerd, we will have to revert unity8?
[09:00] <didrocks> weird those 2, if dependent on each others, were not in the same silo
[09:00] <seb128> is anyone having a non uptodate device?
[09:00] <ogra_> oh, wait, unlock-screen should only unlock ? it should not set the brightness ?
[09:00] <Saviq> didrocks, yeah they were in separate silos indeed
[09:00] <ogra_> i might be testing wrong
[09:00] <ogra_> one sec
[09:01] <didrocks> ogra_: yeah, only unlock
[09:01] <didrocks> seb128: I do
[09:01] <seb128> if anyone is having a non-uptodate-device I would appreciate testing of https://launchpad.net/~ci-train-ppa-service/+archive/landing-007/
[09:01] <ogra_> ok, let me try that again
[09:01] <seb128> it's integrating click updates to system updates
[09:01] <seb128> didrocks, ^
[09:01] <didrocks> seb128: not sure we have new click packages though
[09:01] <seb128> didrocks, if you could install that and do your update with it
[09:01] <didrocks> seb128: ok, only system update?
[09:02] <seb128> didrocks, well, main goal is ensure system updates are still solid :p
[09:02] <didrocks> k ;)
[09:02] <seb128> if you have no clicks
[09:02] <seb128> if clicks have a bug that's ok, that's new code/feature and not a regression
[09:02] <ogra_> oh, finally !
[09:02] <didrocks> ogra_: not done yet
[09:02] <seb128> I tested both system and click updates for the record, and that has mocks and autopilot tests
[09:02] <seb128> so it should be fine
[09:02] <didrocks> ogra_: don't shout victory :p
[09:02] <ogra_> haha
[09:02] <seb128> hehe
[09:02] <didrocks> seb128: we still have system-image-dbus failing, right?
[09:03] <seb128> we have been bouncing back until bugs and tests were fixed, so hopefully it's ok
[09:03] <didrocks> (the mock crashing for weeks now)
[09:03] <seb128> on desktop?
[09:03] <didrocks> on the phone at least
[09:03] <didrocks> it's barry's but not sure if you knew about it
[09:03] <Saviq> didrocks, I don't think we'd need to revert unity8, the call to powerd would fail, but I don't think would have any consequences
[09:03] <seb128> not that I noticed
[09:03] <didrocks> Saviq: ok, good, thanks! :)
[09:03] <seb128> the tests are green on the phone when run through phablet-test-run
[09:03] <didrocks> seb128: yeah, but there is a crasher
[09:04] <seb128> I didn't run into it
[09:04] <seb128> well anyway, settings should be fine, but an extra confirmation would be welcome
[09:04] <seb128> thanks ;-)
[09:04] <didrocks> yeah
[09:04] <dbarth> sil2100: good morning; i have finished testing silo 011; good to publish for me
[09:05] <didrocks> seb128: confirmed, no click package showing
[09:05] <ogra_> didrocks, ok, rolling back gets it to work again, but i would like to look if there is any fix we can do
[09:05] <seb128> I guess you have none in the downloader app either?
[09:05] <didrocks> at least, the install seems to work
[09:05] <sil2100> dbarth: I'm already on it!
[09:05] <didrocks> seb128: well, I have the bug where it shows the same available than what I installed :p
[09:06] <seb128> haha
[09:06] <didrocks> ogra_: ok, I think we should give it 30 minutes
[09:06] <didrocks> ogra_: and revert otherwise
[09:06] <didrocks> we have no test result on latest image
[09:06] <didrocks> not good
[09:06] <seb128> didrocks, ok, anyway I managed to test some click update so it should be fine
[09:06] <didrocks> seb128: it rebooted and its installing the update now (and logs confirms)
[09:06] <seb128> didrocks, let me know when your update is done, if it worked fine I'm going to land the silo
[09:06] <didrocks> seb128: so +1 for me
[09:06] <seb128> didrocks, thanks
[09:06] <ogra_> didrocks, well, then revert it ... i doubt i can find something in 30min
[09:07] <didrocks> ogra_: powerd, ok?
[09:07] <ogra_> didrocks, yep
[09:07] <sil2100> didrocks: packaging ACK needed! Looking safe http://<IP_ADDRESS>/job/landing-011-2-publish/34/artifact/packaging_changes_unity-webapps-qml_0.1+14.04.20140327-0ubuntu1.diff
[09:07]  * didrocks fires up the reverter!
[09:07] <didrocks> THE reverter :p
[09:07] <sil2100> ;)
[09:08] <didrocks> ogra_: do we have a bug report to track it?
[09:08] <dbarth> oh wow, that sounds terrifying
[09:08] <ogra_> not yet
[09:08] <dbarth> didrocks: btw, thanks an awful lot for the new citrain interface
[09:09] <dbarth> the new reconfig screen "just works"
[09:09] <dbarth> :)
[09:09] <Saviq> sil2100, hi, when you think we're better with remaining silos, could we get one for row 49 please?
[09:09] <didrocks> dbarth: heh, yw! :)
[09:09] <sil2100> Saviq: let me see ;)
[09:10] <sil2100> Oh, that's something fresh, didn't see it a few minutes ago!
[09:10] <didrocks> ogra_: mind putting more infos on bug #1298869?
[09:10] <sil2100> Saviq: yes, crashers have a bigger priority, let me assign
[09:10] <vila> ogra_: thanks for confirming !
[09:11] <vila> http://q-jenkins.ubuntu-ci:8080/job/trusty-touch-mako-smoke-daily/190/console is busted as well
[09:11] <didrocks> vila: another way is to revert that manually on the device
[09:11] <didrocks> rather than reverting on the image
[09:11] <vila> didrocks: that won't help the automated tests right ?
[09:11] <didrocks> vila: do you know how to connect to the devices?
[09:11] <didrocks> vila: it will, but you have to run all test runs manually
[09:12] <ogra_> oha
[09:12] <ogra_> root@ubuntu-phablet:/# cat /var/log/upstart/powerd.log
[09:12] <ogra_> dbus name lost or unable to acquire dbus name, is another copy of powerd running?
[09:12] <ogra_> g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
[09:12] <vila> in the lab ??
[09:12] <ogra_> which is funny... powerd works fine
[09:12] <didrocks> vila: yeah, that's what psivaa_ is doing most of the time
[09:12] <didrocks> vila: seems you don't know how to do? (I don't either), if so, just tell me and I revert in distro…
[09:13] <vila> didrocks: yeah, absolutely no idea, I think psivaa_ does that locally not in the lab
[09:14] <didrocks> ok, revert uploaded then
[09:14] <didrocks> vila: I'm sure it's in the lab as then, he rerun the official jobs
[09:14] <vila> didrocks: the reason being that the devices are flashed and adding manual steps to an automated process... urgh, I wouldn't trust any results coming out
[09:15] <didrocks> vila: he's doing that and then rerun all slaves jobs AFAIK
[09:15] <didrocks> (so don't rerun the flash and so on)
[09:15] <vila> didrocks: ok, I'll discuss about that with him when he;s back then
[09:15] <didrocks> thanks :)
[09:15] <didrocks> so 90% of pass rate -> means no app/shell test run :p
[09:15] <didrocks> ev: I guess this value is really something to work on, the logic is misleading if you don't know about it ^
[09:16] <tvoss> sil2100, didrocks Mirv can I get a preliminary silo for line 48?
[09:16] <vila> didrocks: yeah, tests not run are errors and not counting them anymore is messy
[09:16] <didrocks> tvoss: it's for experimenting? we are very low on silo, so we are rather reclaiming them
[09:16] <didrocks> vila: +1
[09:17] <vila> didrocks: but at least on http://ci.ubuntu.com/smokeng/trusty/touch/ you have the total. A variation from ~640 to 134 is a clear indication something went horribly wrong
[09:17] <vila> didrocks: not enough, but still valuable
[09:17] <tvoss> didrocks, not experimenting, marcus and me are confident that the changes are good, but would like to provide reviewers with testing packages, too
[09:17] <didrocks> vila: yeah, that should be in red mayve
[09:17] <didrocks> maybe
[09:17] <didrocks> vila: like loosing > 10% of tests?
[09:17] <didrocks> tvoss: do you think you will release within the day?
[09:18] <tvoss> didrocks, that's the plan, yes. If not, we can immediately flush
[09:18] <vila> didrocks: good idea, not sure how easy it is (you need to compare by device)
[09:18] <didrocks> tvoss: seems legit then
[09:18] <tvoss> didrocks, thanks
[09:18] <Mirv> didrocks: you or me?
[09:18] <Mirv> we've indeed two flushable silos for emergencies
[09:18] <didrocks> tvoss: putting the request to being ready?
[09:19] <didrocks> Mirv: I'm doing it
[09:19] <Mirv> thanks
[09:20] <didrocks> Mirv: I'm flushing line 46 due to powerd revert
[09:20] <ogra_> YIPPIEE !!!!
[09:20] <ogra_> (imgbot reconnected on its own ... finally :) )
[09:20] <didrocks> ogra_: hum?
[09:20] <didrocks> ok :)
[09:21] <tvoss> didrocks, can do so, kept it in not ready for the lack of approval
[09:21] <didrocks> tvoss: ok, making sense (I didn't read the description when I asked it)
[09:22] <didrocks> ERROR:root:https://code.launchpad.net/~marcustomlinson/process-cpp/fix_env_var_split doesn't seem to be a valid merge proposal url
[09:22] <didrocks> tvoss: ^
[09:23] <didrocks> sil2100: hum, seems you are not around, I'm assigning line 42 as discussed above
[09:23] <seb128> didrocks, sil2100: can you get a silo for the unity desktop bugfix update in l44 once we get some? (I know touch is important but the lts also is, why that one got skipped over to get other silos assigned?)
[09:23] <didrocks> Mirv: you as well, let's try to favor the releases
[09:23] <Mirv> yes, I read that
[09:24] <didrocks> seb128: we have no more silo at all, I hope we can reclaim some before bregma starts his day
[09:24] <tvoss> didrocks, fixed
[09:24] <seb128> didrocks, right, you assigned some to Saviq though :p
[09:24] <seb128> where you had some
[09:24] <seb128> when unity was waiting for longer
[09:24] <didrocks> seb128: I didn't, but saviq is around
[09:24] <didrocks> bregma isn't
[09:24] <ogra_> heh, i think i found the issue .... the at_console powerd policy was dropped
[09:24] <seb128> I'm around and wanting to test unity desktop
[09:24] <seb128> should I change the lander to me?
[09:24] <didrocks> seb128: yes please
[09:25] <seb128> done
[09:25] <Saviq> seb128, didrocks, we have the split greeter silo that can be flushed if needed
[09:25] <sil2100> Ok
[09:25] <Mirv> I think we could consider freeing up "Silo ready" ones that have been so for days
[09:25] <sil2100> seb128, didrocks: was in the bathroom, will assign 44 then
[09:25] <seb128> didrocks, I've landed 2 desktop changes, so we are going to have 2 silos back soon, I would appreciate getting one for unity then
[09:25] <Mirv> like line10, thostr isn't around
[09:25] <seb128> sil2100, ^
[09:25] <sil2100> Mirv: good point
[09:25] <didrocks> seb128: 5 silos are blocked by UNAPPROVED
[09:26] <didrocks> this is going to become more and more of a trouble
[09:26] <seb128> Laney, cjwatson: ^ can you help to let some unapproved in to get silos back?
[09:26] <sil2100> Mirv: let me free the url-dispatcher one
[09:26] <seb128> infinity, ^
[09:26] <Laney> I don't believe it is 5
[09:26] <didrocks> seb128: I ditched one silo, just waiting for the sync to happen and will assign you that one
[09:26] <Mirv> sil2100: yeah, just do it. it wasn't requested in the first place, we just gave it but it hasn't seen any action
[09:26] <Laney> https://launchpad.net/ubuntu/trusty/+queue?queue_state=1
[09:26] <didrocks> Mirv: sil2100: agreed, please add a comment
[09:26] <seb128> Laney, ubuntu-themes qtlocaltion indicator-power ... at least 3
[09:27] <seb128> Laney, apparmor = 4
[09:27] <Laney> Yep
[09:27] <ogra_> didrocks, i got a fix
[09:27] <Laney> Still exaggerating
[09:27] <Laney> But yes, I'll look
[09:27] <seb128> Laney, by 1, and I think that was u-s-s that got autoapproved
[09:27] <didrocks> Laney: hum
[09:27] <Laney> So it was never blocked by that then
[09:27] <seb128> but let's not nitpick
[09:27] <didrocks> Laney: I saw 5
[09:27] <didrocks> when I looked at the spreadsheet
[09:27] <didrocks> let me compare
[09:27] <seb128> Laney, I think the status was "in unapproved" for a short time
[09:28] <seb128> Laney, please let's assume honest mistakes
[09:28] <Laney> Okay, I was seeing more "raargh release team blocking our work" coming ;)
[09:28] <sil2100> ;)
[09:28] <seb128> Laney, well, we can do friday trolling if you want :p
[09:28] <didrocks> ubuntu-themes, ubuntu-system-settings, qtlocation-opensource-src, apparmor, indicator-power
[09:28] <didrocks> was the one listed
[09:28] <seb128> Laney, but it's more "urg, no silo, want to land u-c-c and other things, please help me" ;-)
[09:29] <didrocks> so yeah, 4 + u-s-s
[09:29] <seb128> didrocks, right, u-s-s was a short/transient one, thanks to the autoapprove bot
[09:29] <didrocks> yep
[09:29] <Mirv> dbarth: how's the oxide resolving of ppc64el/arm64/powerpc issues going? at least the silo claims to be 'building' while the build job is just stuck because it doesn't build for those archs it used to build for before
[09:29] <didrocks> so no "exageration", just the status when looking at it, but really 4 blocked
[09:29] <ogra_> didrocks, see the bug, patch attached
[09:30] <didrocks> ogra_: feel free to revert my revert then and send it away
[09:30] <didrocks> ogra_: want me to have a look?
[09:30] <ogra_> didrocks, that would be good
[09:30] <sil2100> Mirv: cjwatson was to look into that issue with dbarth from what I remember, not sure how that ended up?
[09:30] <ogra_> is revert-revert a plain upload ?
[09:30] <ogra_> or do you need the MP dance
[09:31] <didrocks> dbarth: sil2100: -1 on the packaging change
[09:31] <didrocks> ogra_: no, plain upload
[09:31] <ogra_> awseom, will do that after the meeting then
[09:31] <didrocks> dbarth: sil2100: liboxideqt-qmlplugin is in universe, is the MIR approved?
[09:31] <didrocks> yeah, meeting, and still in night suits…
[09:31] <didrocks> let me change
[09:32] <ogra_> heh
[09:32] <sil2100> didrocks: oh, should we also consider MIR mismatch on Suggests as well?
[09:32] <didrocks> sil2100: ah sorry, not awaken
[09:32] <didrocks> you're right, suggests
[09:32] <didrocks> sil2100: +1 then :p
[09:32]  * ogra_ has collected a nice collection of bathrobes over the years
[09:32] <didrocks> sorry
[09:32] <didrocks> forget about me
[09:32]  * seb128 hands didrocks some coffee
[09:32] <didrocks> ogra_: yeah, mine is just white, uninteresting to you guys
[09:32] <sil2100> Ah :)
[09:32] <didrocks> ogra_: coming in 2 minutes
[09:32] <sil2100> dbarth: no worries then ;p
[09:33] <sil2100> didrocks: in the meantime, I see that the oxide MIR seems Fix Committed already, so it might be even approved!
[09:39] <dbarth> didrocks: the mir is approved for oxide, yes
[09:40] <dbarth> didrocks: but we decided not to push to main (ie seed/depend) just yet while we verify the silo content
[09:41] <dbarth> Mirv: cjwatson advised to not make specific package changes and handle uploads "manually" afaict
[09:41] <dbarth> i think this is to keep the packaging clean and help with maintaining other ports
[09:43] <Mirv> dbarth: ok, I aborted the hung build job then. the packages are there for amd64/i386/armhf for testing, but I'm not sure if there's a better way to handle this in CI Train or will we just force the publishing after manual testing done.
[09:44] <dbarth> Mirv: perfect, yes we've been already using / testing those
[09:44] <dbarth> just so i know (cause i may need a few rebuilds in that silo before it's good to publish)
[09:45] <dbarth> should i ping you guys to fliush the hung builds each time, or would that clear itself if i do a ppa rebuild
[09:45] <dbarth> (i don't want to break the nice ci system)
[09:48] <Mirv> dbarth: someone needs to abort the running/hung job at http://<IP_ADDRESS>/job/landing-009-1-build/ first before running a rebuild
[09:48] <Mirv> otherwise ok
[09:50] <dbarth> noted, i should have access to that, otherwise i'll come here
[09:52] <sil2100> dbarth: soo...
[09:53] <sil2100> dbarth: it seems we'll have to rebuild the packages in silo 11 ;/
[09:53] <sil2100> Or wait
[09:54] <dbarth> sil2100: what's wrong?
[09:55] <dbarth> oh
[09:56] <didrocks> dbarth: you requested conflicting silos
[09:56] <dbarth> sil2100: the changelog needs fixing
[09:56] <didrocks> dbarth: not only changelog, binary package itself
[09:56] <didrocks> you need to rebuild
[09:56] <sil2100> dbarth: yeah, so, an ignore-conflicts was requested, and in the meantime we released another version of it
[09:56] <didrocks> that's why it's an expectional option
[09:56] <dbarth> did i?
[09:56] <sil2100> dbarth: so now the package needs to be rebuilt and retested, so that we have everythin that's in trunk
[09:56] <didrocks> not something to integrate on the workflow
[09:56] <dbarth> ah i see
[09:56] <dbarth> ok, nw, i'll do that
[09:57] <dbarth> eh, fine by me
[09:57] <dbarth> can i keep the silo up to ~3pm CET though?
[09:57] <didrocks> Webapps fixes (pre-Oxide landing) dbarth
[09:57] <didrocks> dbarth: you won't be able to build/retest before?
[09:57] <dbarth> that one was published already
[09:58] <didrocks> yeah
[09:58] <didrocks> that's the conflicting one which was requested
[09:58] <dbarth> i can publish faster
[09:58] <Mirv> cleanins silo 007 (seb128's) that got published
[09:58] <dbarth> just that i may request a new one just after
[09:58] <seb128> Mirv, thanks
[09:58] <dbarth> it's fine, i'll -retest and clear the deck
[09:59] <didrocks> dbarth: thanks
[09:59] <didrocks> dbarth: so rebuild
[09:59] <didrocks> it will pick latest trunk
[09:59] <seb128> Mirv, it was not a minute ago, you have notifications of changes or what? ;-)
[09:59] <sil2100> Mirv, didrocks: cleaning silo 2
[09:59] <didrocks> sil2100: great!
[09:59] <Mirv> and silo-0... oh thanks lukasz :)
[09:59] <Mirv> seb128: you're just too slow :)
[10:00] <Mirv> we just happened to discuss the low amount of silos once again on the call so I browsed through
[10:00] <seb128> Mirv, lol
[10:01] <Laney> Mirv: did you find someone to new review qtlocation?
[10:01] <Laney> (just read ScottK's comment)
[10:02] <Mirv> Laney: yes, didier
[10:02] <didrocks> Laney: I did it
[10:02] <Laney> R0X0R
[10:02] <didrocks> complained a little bit about wrap-and-sort
[10:02] <didrocks> but that's it :p
[10:02] <ogra_> didrocks, hmm., what about the version of powerd do i keep yours and increment to -ubuntu2 or should i just turn it into 0.13+14.04.20140327-0ubuntu2 ?
[10:03] <Laney> 'did' as some kind of pre-review?
[10:03] <didrocks> ogra_: 0.13+14.04.20140327-0ubuntu1
[10:03] <sil2100> Mirv: we're doing silo mining today :D
[10:03] <didrocks> Laney: yeah, looked at debdiff and binaries
[10:03] <Laney> neat
[10:03] <ogra_> didrocks, -0ubuntu1 ?
[10:03] <didrocks> hum
[10:03] <sil2100> uh
[10:03] <didrocks> sorry
[10:03] <didrocks> -0ubuntu2
[10:03] <ogra_> :)
[10:03] <didrocks> yeah
[10:03] <ogra_> k
[10:03] <ogra_> thanks :)
[10:03] <Mirv> sil2100: :)
[10:03] <sil2100> didrocks: suddenly http://<IP_ADDRESS> stopped working for me
[10:03] <didrocks> I thought the version was from yesterday
[10:03] <sil2100> Is that just me?
[10:04] <didrocks> ogra_: hum
[10:04] <didrocks> ogra_: that's < than my version, right?
[10:04] <didrocks> one sec
[10:04] <sil2100> I get 503
[10:04] <didrocks> let me look
[10:04] <didrocks> ogra_: yeah, it's lower
[10:04] <Mirv> oh, I thought it was my network or something, but now it indeed gives an error
[10:04] <didrocks> ogra_: so you can use .1
[10:04] <didrocks> 0.13+14.04.20140327.1-0ubuntu1
[10:05] <didrocks> ogra_: then, feel free to push your change + tag directly into thei trunk
[10:05] <didrocks> their
[10:05] <ogra_> bah
[10:05] <dbarth> sil2100: same here; service down
[10:07] <didrocks> Laney: thanks for the accept btw :)
[10:07] <didrocks> sil2100: urgh
[10:07] <Laney> you know i'm a sucker for reducing diffs over debian
[10:08] <didrocks> sil2100: Mirv: dbarth: I just restarted jenkins
[10:08] <didrocks> same OOM kill
[10:08] <sil2100> didrocks: thanks! uuh
[10:08] <didrocks> funny that I sent an email to ev about prodstack today
[10:08] <sil2100> heh ;)
[10:09] <didrocks> seb128: dbarth: if you had jobs running, you may need to relaunch them
[10:09] <didrocks> sil2100: mind help on deciphering?
[10:09] <didrocks> sil2100: those should be "building" on the spreadsheet
[10:09] <didrocks> still
[10:09] <didrocks> so watch only?
[10:10] <didrocks> (if they were "preparing", reprepare it needed)
[10:11] <seb128> didrocks, thanks
[10:12] <didrocks> yw
[10:12] <didrocks> ogra_: powerd on the way? :p
[10:12] <ogra_> didrocks, https://code.launchpad.net/~ogra/powerd/fix-1298869/+merge/213225
[10:12] <didrocks> ogra_: ah, using a silo then?
[10:12] <didrocks> as you have a MP
[10:12] <dbarth> ok, restarting
[10:12] <ogra_> well, i want the version to be proper
[10:13] <didrocks> ogra_: ok, pease add the line and let's get that in quickly
[10:13] <ogra_> didrocks, you can just wave it through i suppose ?
[10:13] <sil2100> Ok
[10:13] <sil2100> Will decipher ;)
[10:13] <didrocks> ogra_: yeah
[10:14] <ogra_> line 50
[10:14] <didrocks> ogra_: assigned and building: http://<IP_ADDRESS>/job/landing-002-1-build/102/console
[10:15] <didrocks> failing as expected
[10:15]  * didrocks uses "force rebuild" to tell to ignore the revert in archive
[10:15] <ogra_> hrm, i thought it generates a new version
[10:15] <didrocks> http://<IP_ADDRESS>/job/landing-002-1-build/103/console
[10:16] <didrocks> ogra_: yeah, it's just telling "you have a version in archive that I don't in your changelog, you need to ensure it's fine"
[10:16] <didrocks> see*
[10:16] <ogra_> ah
[10:16] <didrocks> 2014-03-28 10:15:02,152 WARNING A version (0.13+14.04.20140327.is.0.13+14.04.20140129-0ubuntu1) is available at the destination archive for that component but is not in the destination branch which is still at 0.13+14.04.20140327-0ubuntu1. You need to ensure that your version contains the fix in the destination or you can force rebuild to bypass the check.
[10:16] <didrocks> read the logs! :)
[10:16] <ogra_> aha
[10:20] <sil2100> Mirv: freeing silo 19 ;p
[10:20] <sil2100> seb128: ^
[10:21] <seb128> sil2100, thanks
[10:22] <sil2100> Saviq: can you re-run the build for your silo 004?
[10:22] <sil2100> Saviq: the jenkins outage caused the job to disappear
[10:22] <Saviq> sil2100, sure
[10:22] <sil2100> Saviq: thanks!
[10:23] <ev> didrocks: we're OOM on the ci train jenkins? Didn't we give that thing 2G+?
[10:23] <didrocks> ev: we couldn't change the machine, so it's still 1G
[10:23] <didrocks> ev: as we told it's ok as we are going to move to prodstack
[10:23] <didrocks> which has the G+
[10:24] <didrocks> I really think we should just move ASAP as told in this morning email
[10:25] <Mirv> sil2100: thanks :)
[10:25] <tvoss> didrocks, did jenkins die on us?
[10:25] <didrocks> tvoss: yeah, that's why I asked sil2100 to relaunch everything for you
[10:27] <didrocks> argh, seems he didn't rerun yours :/
[10:27] <didrocks> tvoss: doing
[10:28] <sil2100> didrocks: didn't reach his yeat ;)
[10:28] <tvoss> didrocks, thanks
[10:28] <Mirv> didrocks: hmm, what happened to your line42 gallery-app assignment?
[10:28] <sil2100> Is google down?
[10:28] <Mirv> works here
[10:29] <didrocks> Mirv: nobody assigned it I guess
[10:29] <Mirv> didrocks: 11:23 < didrocks> sil2100: hum, seems you are not around, I'm assigning line 42 as discussed above
[10:29] <ev> didrocks: ah yes, now I remember
[10:29] <sil2100> Mirv, didrocks: ok, I can assign it now then
[10:30] <ev> and yes, I haven't had a chance to dig into your mail yet, but I agree - we should finish the prodstack work quickly
[10:30] <didrocks> Mirv: yeah, but we went even more down in term of silos
[10:30] <Mirv> right
[10:30] <didrocks> seems ok to assign it now then
[10:30] <Mirv> thanks sil2100
[10:30] <didrocks> thanks
[10:30] <didrocks> ev: great :)
[10:31] <didrocks> tvoss: no time lost FYI, as I just rerun with "watch only" (as everything was prepared and it was building in the ppa)
[10:31] <tvoss> didrocks, cool, thank you
[10:33] <cjwatson> infinity: I knew it fixed one problem, I didn't know about anything else :-)
[10:35] <sil2100> Aw come on, again jenkins died
[10:35] <sil2100> didrocks: ^ ?
[10:35] <cjwatson> dbarth,Mirv: I removed webbrowser-app/{arm64,powerpc,ppc64el}, so it should no longer be a blocker from the archive's point of view.  I don't know if the silo stuff is confused by it but I shouldn't have thought it ought to be ...
[10:36] <didrocks> hum
[10:36] <cjwatson> dbarth,Mirv: if a build job still hangs, let me know?
[10:36] <sil2100> What the heck is happening with that machine ;/
[10:36] <sil2100> cjwatson: ok, thanks!
[10:36]  * didrocks doesn't get it
[10:36] <didrocks> -/+ buffers/cache:        519        476
[10:36] <ogra_> didrocks, binary from soli 2 tested ... works fine ... (marked in the silo too)
[10:36] <dbarth> cjwatson: we're just rebuilding it now
[10:36] <dbarth> sil2100: ^^
[10:36] <didrocks> ogra_: great!
[10:36] <seb128> jenkins down?
[10:36] <didrocks> yeah
[10:36] <dbarth> we'll let you know if that breaks
[10:36] <seb128> :-(
[10:36] <didrocks> ev: it's really urgent to migrate :/
[10:37] <didrocks> restarted
[10:37] <ev> didrocks: just finishing an email and then I'll cut straight over to this
[10:37] <ev> I'll make the day's focus helping you get the remaining prodstack changes done
[10:37] <didrocks> ev: thanks :)
[10:38] <didrocks> ok,
[10:38] <didrocks> let me see what needs to be rerun
[10:38] <didrocks> and do that in order
[10:38] <didrocks> quickly
[10:39] <didrocks> recrash
[10:39] <didrocks> ok
[10:39] <didrocks> let me try to restart the host
[10:40] <sil2100> o_O
[10:40]  * didrocks crosses fingers
[10:40] <ev> okay, here we go
[10:41] <didrocks> ev: I shouldn't have sent that email
[10:41] <ev> didrocks: when you say "(DONE: this morning)" do you mean you got webops to update the code?
[10:41] <ev> oh?
[10:41] <didrocks> I'm sure canonistack got upset
[10:41] <ev> lol!
[10:41] <ev> poor thing
[10:41] <didrocks> ev: the DONE was "DONE by me, directly"
[10:41] <ev> does the prodstack deployment auto-update its code?
[10:42] <didrocks> ev: yeah, it will as well
[10:42] <didrocks> so, it's back
[10:42] <didrocks> let's see
[10:43] <didrocks> seb128: thanks
[10:44] <ev> didrocks: erm, where? Grepping for update or pull doesn't turn up anything relevant.
[10:44] <seb128> didrocks, for? retrying the silo 1? ;-)
[10:44] <didrocks> seb128: yep
[10:44] <ev> we should cut over to the canonical-is-charms version of the jenkins charm
[10:45] <seb128> didrocks, yw! let's see if we managed to get through this time
[10:45] <didrocks> ev: let me put things in shape before
[10:45] <ev> sure thing
[10:47] <sil2100> Should I rebuild anything?
[10:47] <sil2100> Or wait for now?
[10:48] <ev> ah, found it
[10:50] <didrocks> ogra_: powerd done
[10:50] <didrocks> sil2100: well, I did it, we needed to act quickly
[10:50] <didrocks> ok, all done and published
[10:50] <sil2100> No OOM?
[10:50] <didrocks> sil2100: I rebooted the machine…
[10:50] <ev> didrocks: what do you want for the rsync frequency of those dirs?
[10:50] <didrocks> and reconcialiate everything
[10:50] <ogra_> yay
[10:50] <didrocks> ev: hum, you didn't want to expose them directly?
[10:50] <ev> oh right, I see now
[10:50] <ev> yeah
[10:51] <ev> and that data is safe for public viewing?
[10:51] <didrocks> ev: the rsync is only for the out/ dir
[10:51] <didrocks> ev: yep
[10:53] <sil2100> hm, someone tried publishing 001? Since it's not tested yet
[10:54] <didrocks> ev: so $AS_JENKINS $JENKINS_HOME/citrain/citrain/manual/setup-citrain --allsilos --prepare --deploydeploy --deploypreprod deploys latest code
[10:54] <didrocks> ev: but actually, they just need to redo JENKINS_HOME/citrain/citrain/manual/setup-citrain --deploydeploy as per email
[10:54] <didrocks> and I'm dealing with the rest
[10:55] <didrocks> ev: hum, actually with the preprod/prod, I need to change the script
[10:55] <didrocks> ev: will they rerun this job?
[10:55] <ev> didrocks: just filed https://rt.admin.canonical.com/Ticket/Display.html?id=68826
[10:55] <didrocks> [ -e $JENKINS_HOME/citrain ] || $AS_JENKINS bzr branch lp:cupstream2distro $JENKINS_HOME/citrain
[10:55] <ev> you should have it in your inbox, so if there are additional instructions for webops, do add them there
[10:55] <didrocks> ok
[10:55] <didrocks> let me change the charm
[10:56] <ev> should that actually be --deploydeploy? I assumed it a typo and wrote it as --deploy in the instructions
[10:56] <didrocks> ev: no, we deploy the deploy job
[10:56] <ev> working on the apache charm now
[10:56] <didrocks> (the job use for future code update)
[10:56] <ev> ah okay, please follow up on that email then
[10:56] <ev> and when you do I'll take it over to #webops for score bumping
[10:56] <didrocks> ok
[10:56] <ev> upgrade-charm will call the install hook, for what it's worth
[10:57] <ev> so that will handle installing python-requests
[10:57] <didrocks> yeah
[10:57] <didrocks> so it's fine if we use that
[10:57] <didrocks> let me fix the charm to have the preprod thing
[10:57]  * ev nods
[10:58] <ogra_> didrocks, something in the changelog generation tried to be clever and appended a bug reference to my line with the bug reference :P
[10:59] <ogra_> (it should probably check if there is an entry for this bug already before blindly appending it a second time)
[10:59] <didrocks> ogra_: patches welcomed, should be easy enough :p
[10:59] <didrocks> (but you need to take into account the fact that it can split in 2 lines and so on)
[11:03] <didrocks> ev: ok, changes in the charm done and pushed
[11:03] <didrocks> let me followup on your email
[11:04] <seb128> sil2100, Mirv: can I get a silo for l36 next time you have one (pinging because I'm unsure if it's skipped over because it's further up in the table and people don't go to look there)
[11:05] <sil2100> seb128: it's skipped because of lacking description ;p
[11:05] <sil2100> seb128: see comment ;)
[11:06] <seb128> sil2100, there should be a color in the comments entry when it's blocked on feedback :p
[11:06] <seb128> sil2100, done
[11:06] <sil2100> seb128: well, it seems the person commenting forgot about the color ;p Sorry ;p
[11:06] <seb128> no worry!
[11:07] <sil2100> seb128: let me add you a silo once we have one more free
[11:07] <seb128> thanks
[11:09] <sil2100> Mirv: merge and cleaning silo 16!
[11:09] <Mirv> thanks again :)
[11:11] <sil2100> yw :)
[11:11] <didrocks> dbarth_: landing silo 11
[11:11] <Mirv> I was polling on that one too since it was acceptes
[11:12] <sil2100> I'm scanning the spreadsheet very frequently because of our free-silo deficiency
[11:13] <dbarth_> didrocks: ah ok, thanks
[11:13] <sil2100> seb128: assigning a silo for you, since one silo will be free now in some moments
[11:13] <sil2100> didrocks: the 11 publish job failed somehow?
[11:14] <didrocks> sil2100: yeah, I double click :/
[11:15] <didrocks> sil2100: but the migration job fixed the status
[11:15] <didrocks> sil2100: you can assign seb128's one, as the other is getting freed
[11:15] <didrocks> sil2100: then, I think we have 0 requests ready pending on us
[11:15] <sil2100> \o/
[11:15] <didrocks> sil2100: I added a comment for the powerd one
[11:16] <sil2100> didrocks: there's one url-dispatcher landing that we didn't assign, but as thostr doesn't seem around it seems pointless to assign
[11:16] <didrocks> yeah
[11:19] <Saviq> didrocks, 013 can be published please
[11:19] <sil2100> Saviq: o/
[11:19] <sil2100> didrocks: handling that
[11:19] <didrocks> thanks :)
[11:20] <didrocks> Saviq: on the unity8 crashers, davmor2 has another reproducer btw
[11:20] <didrocks> he will file you with a bug for it
[11:20] <Saviq> didrocks, yeah, we found a way, too (for the "browsing dash" one), Albert is on it
[11:20] <didrocks> Saviq: do you have a bug for it?
[11:21] <sil2100> didrocks: packaging ACK - copyright fixes: http://<IP_ADDRESS>/job/landing-013-2-publish/19/artifact/packaging_changes_unity-scope-texdoc_0.1+14.04.20140328-0ubuntu1.diff
[11:21] <davmor2> From a bootstrap of of the latest image I add the music video and images  flick between scopes and hit the following:
[11:21] <davmor2> _usr_bin_mediascanner-service-2.0.32011.crash
[11:21] <davmor2> _usr_bin_mediascanner-service.32011.crash
[11:21] <davmor2> _usr_bin_unity8.32011.crash
[11:21] <davmor2> _usr_lib_arm-linux-gnueabihf_upstart-app-launch_desktop-hook.32011.crash
[11:22] <didrocks> sil2100: +1, seems to match the content :)
[11:22] <didrocks> mhr3: hey, maybe you sohuld be involved as well ^
[11:22] <didrocks> (seeing mediascanner thingy)
[11:23] <davmor2> didrocks, Saviq, mhr3: I'll report all 3
[11:23] <didrocks> all 4 rather, no?
[11:24] <davmor2> the last one I think is the notes bug that has been around on fresh installs for a while but I'll check on that
[11:24] <didrocks> ok
[11:24] <davmor2> didrocks: root@ubuntu-phablet:/var/crash# cat _usr_lib_arm-linux-gnueabihf_upstart-app-launch_desktop-hook.32011.crash | grep notes
[11:25] <davmor2> AppID: com.ubuntu.notes_notes_1.4.253
[11:25] <davmor2> DuplicateSignature: icon-path-unhandled-com.ubuntu.notes_notes_1.4.253
[11:25] <davmor2> IconPath<EMAIL_ADDRESS>[11:25] <didrocks> k
[11:25] <davmor2> So I'll ignore that one :)
[11:25] <ev> didrocks: gnuoy is looking at the RT now
[11:25] <didrocks> but maybe upstart-app-launch should be more resilient to the crash
[11:26] <didrocks> ev: ok, FYI, the last step once we transition will be to rsync 2 folders between canonistack and prodstack
[11:26] <didrocks> ~jenkins/silos/ and ~jenkins/status
[11:26] <didrocks> we stop jenkins on canonistack
[11:26] <didrocks> rsync those
[11:26] <didrocks> and start prodstack
[11:26] <didrocks> hum, the url of things running won't match any reality though
[11:27] <didrocks> we'll need to discuss :p
[11:27] <davmor2> didrocks: by the way the system still writeable
[11:27] <didrocks> davmor2: well, I didn't get any time to change it…
[11:28] <didrocks> davmor2: so yeah…
[11:28] <didrocks> and I don't envision having time soon
[11:28] <mhr3> davmor2, pls ping satoris about the mediascanner crash
[11:29] <davmor2> mhr3: will do once the report is done
[11:29] <mhr3> ty
[11:29] <ev> didrocks: *nods* gory details in #webops
[11:30] <ev> we're working through how to expose /var/lib/jenkins/silos*
[11:34] <Saviq> davmor2, let's see how our kill timeout coped! :)
[11:34] <didrocks> ev: excellent!
[11:35] <ev> didrocks: can you join #webops?
[11:35] <didrocks> ev: I did 2s before you joined :p
[11:35] <didrocks> asked*
[11:48] <didrocks> ogra_: powerd in, building an image
[11:48] <ogra_> one sec
[11:48] <seb128> sil2100, lol (I was typing and got sidetracked, should have waited for the ready = yes :p)
[11:48] <ogra_> let me get the bot back
[11:49] <didrocks> get the bot back NOW! :)
[11:49] <sil2100> ;)
[11:50] <ogra_> |HELP
[11:50] <imgbot> I am the firendly image watchbot
[11:50] <ogra_> didrocks, go for it
[11:51] <didrocks> ogra_: I already kicked it when I wrote "building an image"
[11:51] <ogra_> (damned, i thought it was properly detection connection now ... )
[11:51] <didrocks> it was really "building"
[11:51] <ogra_> shit
[11:51] <didrocks> not about to build :p
[11:51] <ogra_> right
[11:51] <didrocks> or I'm going to biuld
[11:51] <sil2100> booo!
[11:51] <didrocks> or… well, you got it :p
[11:54] <ogra_> ah, the cron jobs had not kicked in yet
[11:54] <ogra_> it should be fine
[11:54] <imgbot> [11:55] <ogra_> there it is
[11:55]  * sil2100 already said it that's he knows it's jus ogra_ manually inputting this to imgbot - using voice recognition of course
[11:55] <ogra_> heh
[11:56] <sil2100> didrocks, didrocks: m&c'ing silo 11
[11:56] <Mirv> merge and cleaning 011
[11:56] <didrocks> m&c race!
[11:56] <sil2100> !
[11:56] <sil2100> :D
[11:56] <sil2100> Who was first?!
[11:56] <Mirv> sil2100: damn you, you take all the fun :D
[11:56] <Mirv> sil2100: you, because my login had timed out
[11:57] <sil2100> Mirv: ;)
[11:57] <ogra_> hmm
[11:57] <ogra_> ogra@anubis:~$ ps ax|grep compiz
[11:57] <ogra_> 31691 ?        Sl   10564:13 compiz --replace
[11:57] <ogra_> interesting times :P
[11:57] <sil2100> Yessss I wooon! I wonder what I won though, what's the prize?
[11:57] <Mirv> sil2100: 008!
[11:57] <sil2100> ! Darn!
[11:57] <Mirv> :D
[11:58] <sil2100> Ok, today really feels like friday ;p
[11:58] <Mirv> hehe
[11:58] <sil2100> ubot5 just told me he doesn't know anything about Darn!
[11:58] <sil2100> ubot5: then stop talking to me!
[12:00] <sil2100> Mirv: in the meantime, I'll assign the last silo to seb128, as we will have 2 free in a moment
[12:00] <seb128> sil2100, thanks!
[12:00] <seb128> hum, interesting
[12:00] <seb128> 4 ppc builds, 1 building libreoffice, 1 openjdk, 1 linux
[12:00] <Mirv> yeah, seb handles his silos swiftly on average and doesn't leave them hanging around for a week :)
[12:00] <seb128> so we are virtually down to 1 and having some hours backlog :/
[12:00] <didrocks> seb128 has 4 silos for him, 20% of our silos!
[12:00] <seb128> Mirv, ;-)
[12:02] <seb128> didrocks, I'm doing that to be nice to Saviq, so he doesn't feel like he's the only one stealing all the available silos :p
[12:02] <didrocks> seb128: ah, compassion, got it!
[12:02] <seb128> ;-)
[12:04] <Saviq> WHO ME?
[12:04] <seb128> YES, YOU!
[12:04] <didrocks> Saviq: 15% of our silos! how dare you! :)
[12:05] <Saviq> didrocks, that's only because I took over from thostr!
[12:05] <didrocks> (well, more than 15% of our landings anyway ;))
[12:05] <Saviq> didrocks, and when you say 15% that's manipulating - it's 3!
[12:05] <didrocks> Saviq: that's stats! :)
[12:05] <sil2100> ;p
[12:05] <didrocks> stats are manipulation in essence
[12:05] <Saviq> ;)
[12:06]  * seb128 just notice that didrocks has no silo and wonder if the guy is doing any work
[12:06] <seb128> no silo = slacking, right?
[12:06] <didrocks> seb128: exactly, we should fire him!
[12:06] <seb128> ;-)
[12:06]  * seb128 hugs didrocks
[12:06]  * didrocks hugs seb128 back
[12:07]  * sil2100 hides as well
[12:07] <Saviq> also, I'd have cleared one of them already if it wasn't stuck in proposed :P
[12:08] <Saviq> there's too much hugging in this channel
[12:08] <ogra_> especially for a friday !
[12:08] <didrocks> yeah, let's stop being nice!
[12:08] <didrocks> :)
[12:09] <davmor2> sorry for the delay mother in law meds were  due I hadn't realised it was that late.
[12:09] <didrocks> noooooooooooooooooo, but what is happening today?
[12:09] <didrocks> jenkins down AGAIN
[12:10] <ogra_> friday ...
[12:10] <t1mp> jenkins started his weekend early
[12:10] <jdstrand> Mirv: thanks-- I did that the first time, and it said it failed
[12:10] <davmor2> mhr3: satoris what channel/time am I likely to get him on?
[12:10] <seb128> didrocks, do you know what happened with https://code.launchpad.net/~attente/unity-gtk-module/no-handlers/+merge/211857 ? it ended up under CI bot in https://launchpadlibrarian.net/171027868/unity-gtk-module_0.0.0%2B14.04.20140328-0ubuntu1_i386.changes
[12:10] <didrocks> Mar 28 12:03:10 juju-openstack-machine-2 kernel: [ 4954.407410] Out of memory: Kill process 934 (java) score 221 or sacrifice child
[12:10] <sil2100> jdstrand: I think it wasn't migrated to the archive fully yet back then
[12:11] <sil2100> Aw come ooon
[12:12] <didrocks> jdstrand: the failed told you what exactly?
[12:12] <sil2100> didrocks: it seems we never overused jenkins as much as today, as things are being marked as 'ready to land' really frequently
[12:12]  * didrocks reboots
[12:12] <didrocks> sil2100: yeah, but still, it's not like the load after 4 weeks…
[12:12] <sil2100> That's true ;|
[12:12] <didrocks> ok back
[12:12] <didrocks> let's watch ppa for what was building
[12:13] <jdstrand> didrocks: http://<IP_ADDRESS>/job/landing-008-2-publish/46/console
[12:13] <didrocks> sil2100: I start at the end of the list, you start from top?
[12:13] <didrocks> jdstrand: did you run the build job with "watch ppa"?
[12:13] <jdstrand> didrocks: I copied apparmor from security-proposed ppa to silo 008
[12:13] <jdstrand> didrocks: I did
[12:13] <didrocks> jdstrand: do you remember the run #?
[12:14] <jdstrand> I'm not sure what this is. Build history says '46' was the issue
[12:15] <didrocks> sil2100: landing-002 done
[12:15] <didrocks> sil2100: landing-010 done
[12:15] <jdstrand> didrocks: oh sorry, you meant for the build where I used WATCH_ONLY
[12:15] <jdstrand> ?
[12:15] <didrocks> sil2100: landing-001 done
[12:15] <didrocks> jdstrand: yes
[12:15] <Mirv> jdstrand: didrocks: it seemed to indeed work after I ran it with WATCH_ONLY
[12:16] <didrocks> sil2100: landing-019 done
[12:16] <didrocks> sil2100: landing-017 done
[12:16] <sil2100> Oh oh
[12:16] <didrocks> sil2100: landing-019 done
[12:17] <sil2100> This always happens when I don't look at the irc window
[12:17] <sil2100> Aaaa staph!
[12:17] <sil2100> Not so faaast!
[12:17] <didrocks> and end of the list
[12:17] <seb128> didrocks, what, what?
[12:17] <didrocks> sil2100: well, we have to be fast
[12:17] <jdstrand> didrocks: http://<IP_ADDRESS>/job/landing-008-1-build/66/console?
[12:17] <didrocks> seb128: new jenkins outage
[12:17] <seb128> didrocks, oh, your restarted the jobs?
[12:17] <seb128> shrug
[12:17] <didrocks> seb128: I had to restart everything :/
[12:17] <didrocks> well
[12:17] <sil2100> ;/
[12:17] <seb128> those were done out of ppc
[12:17] <didrocks> we don't loose time, it's building in the ppa
[12:17] <seb128> right
[12:17] <didrocks> so only watch ppa
[12:17] <seb128> we are blocked on ppc anyway
[12:17] <seb128> it has some hours backlog
[12:18] <didrocks> sil2100: please, you saw there was an outage…
[12:18] <didrocks> sil2100: so don't go aware from IRC, we need to work all together
[12:18] <didrocks> seems I have to restart all of them alone, that's really really not nice…
[12:18] <didrocks> jdstrand: it seems you did it before the package was published in the ppa?
[12:18] <didrocks> jdstrand: as it didn't show the source
[12:19] <didrocks> jdstrand: like in the next run: http://<IP_ADDRESS>/job/landing-008-1-build/67/console
[12:19] <jdstrand> didrocks: ah, I'll add that to my notes
[12:19] <didrocks> jdstrand: yeah, basically, as people can iterate, we don't block on that until the publication
[12:19] <didrocks> jdstrand: as for instance, they want to upload Mir, build it, and then push xorg, and only build xorg
[12:20] <didrocks> so only during the publication we say "oh oh oh, we never monitor that package that you declared as part of your landing"
[12:20] <didrocks> monitored*
[12:20] <jdstrand> ok
[12:20] <jdstrand> thanks for looking at it
[12:20] <Mirv> what does the restarting after a crash involve? just aborting a job + rerunning with watch_only for those silos that were Building?
[12:20] <didrocks> jdstrand: yw, it's always more puzzling with direct upload compared to using branch :)
[12:21] <didrocks> Mirv: no abort, just running with watch only for the silos that were building
[12:21] <didrocks> Mirv: or rerunning build if they were preparing (ideally only what wasn't send to the ppa)
[12:21] <Mirv> ok, thanks. useful in case these become frequent.
[12:21] <didrocks> Mirv: sil2100: so, something to know, the job links are only refreshed if the status change
[12:21] <didrocks> it's to minimize spreadsheet writing
[12:21] <sil2100> didrocks: in the spreadsheet?
[12:22] <didrocks> yep
[12:22] <didrocks> so if you go to silo 002
[12:22] <didrocks> click on building
[12:22] <didrocks> you see that there is no job
[12:22] <didrocks> as it's still the old link
[12:22] <didrocks> now that we restarted everything, the easiest for you is just to delete the status
[12:22] <didrocks> (in the silo)
[12:22] <didrocks> next sync will set the right one
[12:22] <sil2100> didrocks: in the silo sheet?
[12:23] <sil2100> Ok, I'll do that then
[12:23] <sil2100> 13 migrated, m&c'ing!
[12:23] <sil2100> Mirv: ^
[12:23] <cjwatson> seb128: most of that was a mass give-back, ci-train should be ahead of it ...
[12:23] <didrocks> sil2100: done for all
[12:24] <sil2100> didrocks: I remember last time hm, it somehow suddenly refreshed itself?
[12:24] <cjwatson> hmm.  openjdk-7, libreoffice, linux, scilab.
[12:24] <cjwatson> that's a tedious set
[12:24] <didrocks> sil2100: yeah, if new status message is != old status message
[12:24] <didrocks> without counting the url
[12:25] <cjwatson> I think linux is fairly close to done
[12:26] <didrocks> -/+ buffers/cache:        745        249
[12:26] <didrocks> we are quite short, indeed
[12:27] <cjwatson> oh, maybe not, looking at the wrong bit of log :-/
[12:27] <sil2100> Wonder why it's suddenly so bad
[12:27] <didrocks> sil2100: unsure…
[12:27] <cjwatson> infinity: we could really use those new powerpc VMs :-/
[12:33] <dbarth_> o/ line 53 for some polish on the OA settings; when a silo is available
[12:33] <didrocks> -/+ buffers/cache:        756        239
[12:33] <didrocks> now
[12:34] <sil2100> didrocks: looking at it right now
[12:34] <sil2100> I mean
[12:34] <sil2100> dbarth_: ^
[12:34] <sil2100> dbarth_: since I'm looking at the bugs
[12:34] <didrocks> without any new process…
[12:35] <sil2100> dbarth_: since this bug: https://bugs.launchpad.net/ubuntu-system-settings-online-accounts/+bug/1289443 <- it modifies the UI, not sure if we won't need an UIF?
[12:36] <sil2100> I mean, wait, not this one
[12:36] <sil2100> Wrong bug
[12:36] <sil2100> I meant this https://bugs.launchpad.net/ubuntu-system-settings-online-accounts/+bug/1289406
[12:36] <sil2100> ...
[12:37] <sil2100> *UIFe
[12:38] <sil2100> Let me comment on the landing, give us a sign once it's 'cleared'
[12:40] <dbarth_> sil2100: that's minor layout changes, and the string change is for a string that was already in the translation catalog
[12:40] <sil2100> dbarth_: ah, ok
[12:43] <sil2100> dbarth_: assigned
[12:44] <sil2100> Ok, I drive to eat something, will have my PC with me, so will be available during lunch
[12:44] <Saviq> sil2100, reconfigure silo 15 please
[12:45] <ogra_> crap !
[12:45] <ogra_> why does it think it lost connection :(
[12:47] <didrocks> -/+ buffers/cache:        842        152
[12:47] <didrocks> and down again
[12:47] <didrocks> grrrrr
[12:47] <didrocks> out of memory
[12:48] <ogra_> no, that was me now
[12:48] <didrocks> no no
[12:48] <didrocks> jenkins is down again
[12:48] <ogra_> ah
[12:48] <ogra_> heh
[12:48] <didrocks> sil2100 left for lunch, Mirv around?
[12:48] <didrocks> ev: help
[12:48]  * ogra_ renames this day from friday to downday
[12:48] <didrocks> ev: is there any way even to add swap to the machine?
[12:48] <ev> didrocks: the machine in canonistack?
[12:49] <didrocks> ev: yep
[12:49] <didrocks> 4th failure
[12:49] <didrocks> we file the Gb of mem
[12:50] <ev> didrocks: juju ssh ci-train-jenkins/0; dd if=/dev/zero of=/var/swap bs=1M count=$((1024 * 1024)); chmod 0600 /var/swap; swapon /var/swap
[12:50] <ev> or something to that effect
[12:51] <Saviq> ev, 1024 * 1024 megabytes?
[12:51] <Saviq> or am I reading that wrong
[12:51] <Mirv> didrocks: uh
[12:52] <Mirv> going through
[12:52] <Saviq> Mirv, didrocks, stuff's down, can we reconfigure silos?
[12:52] <didrocks> Saviq: wait please
[12:52] <Saviq> didrocks, ok
[12:52] <didrocks> Saviq: yeah, ev was wrong, fixed it
[12:52] <didrocks> however, i can't swapon
[12:53] <cjwatson> you'd need to mkswap
[12:54] <didrocks> yeah
[12:54] <didrocks> ok done
[12:54] <didrocks> Swap:         1023          0       1023
[12:55] <didrocks> that should short-bandaid it
[12:55] <didrocks> Saviq: do you need to reconfigure?
[12:55] <didrocks> Saviq: or it's because of the outage?
[12:55] <didrocks> (you don't need to)
[12:55] <didrocks> thanks cjwatson, ev
[12:55] <bfiller> dbarth_: I've repushed the MR for silo 9 after merging with latest osomon with-oxide trunk
[12:55] <didrocks> imgbot: where are you with it?
[12:56] <didrocks> hum
[12:56] <didrocks> Mirv: where are you with it? (so that I can continue on the other end of the list)
[12:56] <bfiller> didrocks: need to stop the build on silo9 because we need to rebuild it
[12:56] <Mirv> didrocks: at the end now, but probably worth going over again
[12:57] <didrocks> Mirv: ok
[12:57] <didrocks> bfiller: ok, feel free :)
[12:57] <bfiller> didrocks: how?
[12:57] <Mirv> I'm now just rechecking the build jobs
[12:57] <bfiller> didrocks: getting error when going to the biuld page
[12:58] <didrocks> bfiller: http://<IP_ADDRESS>/job/landing-009-1-build/
[12:58] <didrocks> bfiller: we just had a jenkins outage
[12:58] <didrocks> hence the dead links
[12:59] <didrocks> Mirv: ok, all sounds good
[12:59] <didrocks> Mirv: even the reprepare :)
[12:59] <didrocks> Mirv: did you remove the status field to update the links?
[12:59] <didrocks> or should I?
[12:59] <Mirv> didrocks: please do
[12:59] <didrocks> ok
[13:00] <Mirv> didrocks: there was more thing  landing-008 cleaning aborted?
[13:00] <didrocks> (done)
[13:01] <didrocks> ah
[13:01] <didrocks> let me check
[13:01] <bfiller> didrocks: sorry, I don't see any option to stop the build. Can you give me a pointer on that please?
[13:01] <didrocks> Mirv: landed "cleaning silo", so you can use "only free silo" I guess
[13:01] <didrocks> bfiller: on http://<IP_ADDRESS>/job/landing-009-1-build/
[13:01] <didrocks> do you have a red cross next to the progress bar?
[13:02] <didrocks> (can be a permission issue that I need to fix)
[13:02] <didrocks> but you gave the rights to cancel builds normally
[13:02] <Mirv> didrocks: ok, thanks, I'll do that since it seems to be cleaned indeed
[13:02] <bfiller> didrocks: I do now thanks, had to login first
[13:02] <didrocks> bfiller: oh sure, yeah, you have to login :)
[13:02] <didrocks> bfiller: I hope that once we move to prodstack, we won't timeout as much on the sso loging
[13:02] <didrocks> login*
[13:07] <didrocks> Mirv: perfect, all should be sorted now
[13:07] <seb128> cjwatson, right, as I said earlier, would be fine if we didn't get a combo linux/libreoffice/openjdk
[13:08] <dbarth_> Mirv: we have so dep-wait builds stuck for webbrowser-app in silo 009, can you remove them?
[13:08] <dbarth_> i'm about to start a new build
[13:08] <ev> sorry about the mistakes in those swap commands :)
[13:08] <dbarth_> bfiller: ^^ just waiting for some cleanup
[13:09] <cjwatson> dbarth_: dep-waits clear automatically twice an hour FWIW
[13:10]  * Saviq moves the tabs in CI Train ssheet all the time... \o/ for ux...
[13:10] <didrocks> ev: no worry, thanks for the first step (I was thinking about attaching a swap partition) and thanks cjwatson
[13:10] <didrocks> at least, it should help for a band-and solution
[13:10] <cjwatson> dbarth_: and if you're going to start an entirely new upload anyway then they don't matter
[13:10] <dbarth_> ah ok, thanks
[13:10] <dbarth_> then i'll fire up the build now
[13:12] <didrocks> Mirv: yeah, confirming the status is the right one
[13:14] <Mirv> dbarth_: your build seems to have started correctly, let's see how it goes this time
[13:15] <Mirv> didrocks: great
[13:16] <dbarth_> Mirv: yup
[13:19] <plars> ogra_, didrocks: looks like the rootfs has already built with the powerd fix so we should see a new image soon?
[13:19] <ogra_> plars, yeah, soon
[13:20] <imgbot> [13:20] <imgbot> [13:20] <plars> oh
[13:20] <plars> like now :)
[13:20] <ogra_> :)
[13:20] <didrocks> I'm sure ogra_ cheats :)
[13:20]  * sil2100 on lunch at his girlfriends grandparents
[13:20] <sil2100> Free food!
[13:21] <didrocks> sil2100: you missed another outage :p
[13:21] <didrocks> lucky you :)
[13:21] <Saviq> icanhas silo 015 reconfigure please? :)
[13:21] <sil2100> uuuuu ;p
[13:22] <didrocks> Saviq: new component?
[13:22] <Saviq> didrocks, yes, lxc
[13:22] <Saviq> -android-config
[13:22] <Saviq> source only
[13:22]  * didrocks pushes
[13:22] <Saviq> thank you
[13:23]  * ogra_ just got the rejected mail :P
[13:23] <ogra_> can i try again ?
[13:24] <Saviq> ogra_, yeah
[13:24] <Saviq> ogra_, but bump version
[13:24] <ogra_> bah
[13:24] <Saviq> PPAs are really adamant about same-version files
[13:24]  * ogra_ starts ovber then
[13:25] <Saviq> didrocks, ah, and ubuntu-touch-session is a new component there, too, for dropping surfaceflinger support
[13:25] <didrocks> Saviq: reconfigured!
[13:25] <Saviq> didrocks, thanks
[13:25] <didrocks> yw
[13:26] <ogra_> 0.153 uploaded
[13:31] <plars> vila: I'm here
[13:35] <Saviq> didrocks, uh oh http://<IP_ADDRESS>/job/landing-015-1-build/40/console ?
[13:35] <boiko> didrocks: Mirv: sil2100: hey guys, just a heads up that row 41 on the spreadsheet is ready for silo assignment
[13:36] <didrocks> Saviq: can you check with Mirv/sil2100?
[13:36] <Saviq> didrocks, will do, sorry
[13:36]  * Saviq used to pinging didrocks :)
[13:37] <Saviq> there should really be a @landing-team
[13:38]  * Mirv in hangout, sorry
[13:39] <Mirv> boiko: assigning
[13:39] <ogra_> and sil2100 eats his in-laws
[13:39] <ogra_> err
[13:39] <ogra_> *with his in-laws :P
[13:40] <Mirv> boiko: ERROR:root:https://code.launchpad.net/~tiagosh/telephony-service/fix-indicator-voicemail doesn't seem to be a valid merge proposal url
[13:41] <Mirv> obvious fix, please just ping when ready, I try to multi-task listening to the hangout and doing very simple tasks :)
[13:41] <boiko> Mirv: oups, let me fix this, sorry, I got the branch instead of the MP URL
[13:42] <Mirv> and Saviq's question unfortunately looks far from simple
[13:43] <Saviq> there's more :|
[13:43] <boiko> Mirv: fixed
[13:43] <Saviq> http://<IP_ADDRESS>/job/landing-015-0-reconfigure/18/console :/
[13:43] <sil2100> ;p
[13:43] <Saviq> sil2100, Mirv, whenever you can ↑ I can't reconfigure
[13:43] <jhodapp> Can someone do a rebuild of qtubuntu-media in silo 006?
[13:43] <sil2100> Saviq: ok
[13:43] <sil2100> Saviq: doing!
[13:44] <Saviq> sil2100, I mean that there's a failure when reconfiguring
[13:44] <Saviq> sil2100, not that I can't because of new comp
[13:44] <Mirv> sil2100: also related the earlier http://<IP_ADDRESS>/job/landing-015-1-build/40/console
[13:44] <sil2100> Ok, hmmm
[13:44] <Saviq> Mirv, I'm not sure it is indeed related, but yeah, both are my current issues with silo 015 :|
[13:45] <sil2100> Looks strange
[13:46] <jhodapp> sergiusens, you're able to kick off a new silo build, right?
[13:46] <sergiusens> jhodapp, yes
[13:47] <jhodapp> sergiusens, can you rebuilt qtubuntu-media in silo 006 please?
[13:47] <jhodapp> *rebuild
[13:47] <sergiusens> sue
[13:47] <sergiusens> sure
[13:47] <sil2100> Saviq: let me try and debug, but it might be something more tricky requiring jenkins access
[13:47] <jhodapp> thanks
[13:48] <Saviq> sil2100, thanks
[13:49] <sergiusens> jhodapp, was the MR updated or is it a plain retrigger?
[13:49] <jhodapp> sergiusens, MR updated
[13:49] <sergiusens> great
[13:50] <sil2100> Saviq: sooo... it might be a bad sign that in a moment everything in CITrain will be broken
[13:50] <Saviq> sil2100, yeah, the message was rather scary
[13:50] <Saviq> sil2100, IIUC it could not create a tmp file...
[13:50] <Saviq> BAD
[13:51] <sil2100>  java.io.IOException: No space left on device
[13:51] <sergiusens> sil2100, what does this mean java.io.IOException: Failed to create a temp file on /var/lib/jenkins/jobs/landing-006-1-build/workspace ?
[13:51] <sil2100> This makes me worry ;/
[13:51] <sergiusens> oh
[13:51] <sil2100> sergiusens: ouch, so it happened!
[13:51] <sergiusens> jhodapp, guess I can't now..
[13:51]  * ogra_ has some spare space in his basement ... want it ?
[13:51] <sil2100> And I think only didrocks has access to the machine, and he had some emergency
[13:51] <sil2100> ogra_: please ;p!
[13:51] <jhodapp> sergiusens, lack permissions?
[13:52] <ogra_> sil2100, friday :)
[13:52] <Mirv> sil2100: I'm on the server
[13:52] <sil2100> Mirv: oh, you have the creds?
[13:52] <Mirv> sil2100: just tell me what to rm -rf :)
[13:52] <sil2100> I don't know, never been on that server ;) hmmm
[13:52] <sil2100> Look for something big
[13:52] <sergiusens> jhodapp, no space on servers
[13:53] <jhodapp> oh gosh
[13:53] <sil2100> Mirv: how much disk space is there? Maybe look through the jenkins dir and see if there are any leftover source directories that you could remove, i.e. such that won't be used
[13:53] <sil2100> Like, some old versions of existing landings
[13:53] <sil2100> The jenkins outages might have caused some leftovers laying around
[13:54] <Mirv> sil2100: ok a bit freed, ubuntu-themes that was already released
[13:54] <Mirv> oh, but / is different
[13:54] <sil2100> Mirv: yeah, excellent, thanks - how much do we have left now?
[13:55] <sil2100> We need to have free space here: /var/lib/jenkins/jobs/landing-015-0-reconfigure/workspace
[13:55] <jhodapp> sergiusens, try it now?
[13:55] <sil2100> So, i.e. /var/lib/jenkins
[13:55] <Mirv> cd /var/lib/jenkins/jobs/landing-015-0-reconfigure/workspace
[13:55] <Mirv> ls -l
[13:55] <Mirv> :)
[13:55] <Mirv> sil2100: ok there should be space there, right
[13:55] <Mirv> sil2100: I think / being full is a problem too
[13:56] <Saviq> ENOSPC :|
[13:56] <ogra_> Mirv, so rm -rf / then ?
[13:56] <sil2100> hmmm
[13:56] <Mirv> df /var/lib/jenkins/jobs/landing-015-0-reconfigure/workspace
[13:56] <Saviq> the issue was Failed to create a temp file on /var/lib/jenkins/jobs/landing-015-0-reconfigure/workspace
[13:56] <sil2100> Again...
[13:56] <Saviq> is that btrfs? ;D
[13:56] <sil2100> Mirv: so, maybe / is in need of freeing as well
[13:57] <Mirv> /dev/vdc1       82569580 10788052  67587244  14% /srv/juju/vol-0000011d
[13:57] <Mirv> yeah working on it
[13:57] <sil2100> Mirv: thanks, phew, good that you have access to that machine
[13:57]  * sergiusens has the same issue Saviq has but on silo 6
[13:57] <sil2100> Would be nice if I had access as well!
[13:57]  * sil2100 needs to poke didrocks
[13:58] <sil2100> ALthough since we will switch soon, it's not that urgent
[13:58] <Saviq> shall I try again?
[13:58] <Mirv> sil2100: ok now
[13:58] <Mirv> Saviq: yes
[13:58] <sil2100> Saviq: yes
[13:58] <Saviq> \o/
[13:58]  * Mirv removed some useless app translations like French, + apt-get clean
[13:58]  * Saviq wonders how bad ogra got ↑↑↑
[13:59] <Saviq> "Verlassend" sounds like an unpleasant thing to have
[13:59] <ogra_> my palm touched the touchpad while typing ...
[13:59] <Saviq> SUCCESS
[13:59] <ogra_> not siure why it thought i want to leave the channel :P
[13:59] <sil2100> sergiusens: ^
[13:59] <Mirv> Saviq: \o/
[14:00] <sil2100> jdstrand: ^
[14:00] <ogra_> yeah, thats a silly default message someone thought would be clever to translate literally
[14:00] <seb128> Mirv, you removed french translations?!
[14:00] <Saviq> rotfl
[14:00] <Saviq> what will didrocks do!
[14:00] <Mirv> :D
[14:00] <Mirv> now he gets language of the savages on the server
[14:00] <Saviq> Mirv, sil2100, any idea about the touch session failure http://<IP_ADDRESS>/job/landing-015-1-build/40/console ?
[14:00] <sil2100> Saviq: looking
[14:01] <sil2100> Saviq: this was the previous run? Or is it the one now?
[14:01] <Saviq> sil2100, previous
[14:01] <sergiusens> jhodapp, building now
[14:01] <jhodapp> thanks
[14:01] <Saviq> sil2100, I only kicked unity8 now
[14:01]  * sergiusens will brb
[14:01] <Saviq> sil2100, but that didn't look like a transient error
[14:01] <jdstrand> sil2100: ?
[14:01] <Saviq> sil2100, more like some packaging thing
[14:02] <sil2100> Saviq: probably out of disk space caused it...
[14:02] <Saviq> sil2100, could, ok will try
[14:02] <Saviq> sil2100, ignore for now, then
[14:02] <Mirv> sil2100: so our problem might be that / is used for pbuilder cache
[14:02] <Mirv> argh, full again
[14:02] <sil2100> Saviq: will keep an eye on this, but since we had basically 0 disk space, I would say everything could be broken and the same for pbuilder
[14:02] <sil2100> Mirv: crap...
[14:03] <Mirv> you're too quick!
[14:03] <Saviq> sil2100, yup
[14:03] <Saviq> uh oh
[14:03] <sil2100> We need moar free space!
[14:03] <Saviq> yeah, FAIL
[14:03] <Mirv> sil2100: so / is 10GB and 90% of it is in /var/cache/pbuilder
[14:04] <seb128> you probably have staled over build dirs from the reboots
[14:04] <seb128> you can maybe have a look at cleaning those?
[14:04] <sil2100> Mirv: check what seb128 is saying
[14:04] <sil2100> seb128: thank for the pointer!
[14:04] <sil2100> *thanks
[14:04] <seb128> yw
[14:05] <Mirv> I just wonder about potential pitfalls in removing the cow directories
[14:05] <Mirv> but there's stuff from January etc
[14:05] <seb128> I doubt there is any
[14:05] <seb128> old timestamped one are probably fine to rm
[14:06] <seb128> that's a cache
[14:06] <seb128> well, that's from experience of using pbuilder locally, I don't use cow though
[14:06] <sil2100> Caches are meant to be cleaned!
[14:06] <t1mp> Mirv: on the landing proposal sheet, l.31 (zoltan's request) can you remove the tab_selection_timing MR from the list?
[14:06] <seb128> but those are probably temp unpacked that didn't get cleaned because the logout didn't happen normally
[14:06] <sil2100> t1mp: I can do it, Mirv is busy firefighting ;)
[14:06] <t1mp> sil2100: okay, thanks
[14:07] <t1mp> zsombi: ^ fyi. Let's hope that is the MR that caused the failures
[14:07] <Mirv> maybe just pbuilder --clean
[14:07] <zsombi> t1mp: fingers crossed!
[14:07] <t1mp> sil2100: will that update sheet 18, and the silo and create new packages in the PPA?
[14:08] <seb128> Mirv, well, be careful you don't wipe out dirs that are being used
[14:08] <seb128> Mirv, starting by cleaning the ones with old timestamps should be safe
[14:08] <sil2100> t1mp: the silo needs to be reconfigured and rebuilt, but that's basically just 2 buttons - which have to wait a bit since our jenkins right now is not usable
[14:08] <sil2100> So it should be done in some minutes
[14:09] <t1mp> sil2100: will you click those buttons for us? I don't have rights on the document
[14:09] <sil2100> t1mp: sure
[14:09] <t1mp> thanks
[14:09] <t1mp> sil2100: how will I know when the new packages are in the PPA for testing?
[14:10]  * Mirv ran apt-get -o Dir::Cache::archives=/var/cache/pbuilder/trusty-amd64/aptcache autoclean
[14:10] <sil2100> t1mp: the status of the landing-018 will say Packages built - it says so right now, but after rebuilding it will once again say that it's building
[14:11] <Mirv> sil2100: ok, plenty of space now, we just need to check whether everything still works
[14:11] <sil2100> Mirv: thanks!
[14:11] <sil2100> Saviq: can you retry again?
[14:11] <sil2100> You would be our tester
[14:11] <Saviq> sil2100, http://<IP_ADDRESS>/job/landing-015-1-build/44/console
[14:11] <Saviq> going
[14:11]  * sil2100 has his fingers crossed
[14:13] <sergiusens> cannot copy extracted data for './usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_eh.a' to '/usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc_eh.a.dpkg-new': failed to write (No space left on device)
[14:13] <sergiusens> should  just wait for Saviq?
[14:13] <sil2100> sergiusens: from when is that? Did you start it now?
[14:13] <sergiusens> sil2100: 5 minutes ago or so
[14:14] <sergiusens> before I rebooted
[14:14] <sergiusens> http://<IP_ADDRESS>/job/landing-006-1-build/115/console
[14:14] <sil2100> sergiusens: ok, so, we had another issue
[14:14] <sil2100> sergiusens: you can re-try again I guess, it should be fine now
[14:14] <sil2100> Sorry for that, we didn't expect this to happen
[14:14] <dbarth_> sil2100: silo 011, it is /phone only/  in fact, i was confused
[14:14]  * sergiusens retries
[14:14] <sil2100> dbarth_: ah ;) Ok, then no worries!
[14:14] <seb128> sil2100, Saviq, Mirv: that url from Saviq hit a cowbuilder cmd error
[14:14] <dbarth_> sil2100: tested and verified to work, can land (and so no UIF requiredfor the phone case)
[14:15] <sil2100> Saviq: did it just fail?
[14:15] <sil2100> seb128: yea...
[14:15] <Saviq> sil2100, yes, it's the same ubuntu-touch-session fail
[14:15] <dbarth_> sil2100: but keep silo 011 handy, cause i have another one to land for alex-abreu again ;) please
[14:15] <Saviq> sil2100, so not ENOSPC related
[14:15]  * Saviq kicks one with just unity8
[14:15] <alex-abreu> dbarth_, do we put the download api in it ?
[14:15] <Saviq> http://<IP_ADDRESS>/job/landing-015-1-build/45/console
[14:15] <sil2100> Saviq: it doesn't seem the same failure though
[14:16] <alex-abreu> mandel, ping
[14:16] <Saviq> sil2100, same " Use of uninitialized value $ans in pattern match (m//) at /usr/bin/debuild line 1005."
[14:16] <rsalveti> morning
[14:16] <Saviq> sil2100, as here http://<IP_ADDRESS>/job/landing-015-1-build/40/console
[14:16] <Saviq> rsalveti, elo
[14:16] <sil2100> Saviq: ah, right, it's more up now
[14:16] <Saviq> sil2100, yeah, due to the new cache things
[14:16] <rsalveti> sigh, just saw latest powerd caused issues
[14:16] <Mirv> yeah it seems new stuff is being created on the server too
[14:16] <sil2100> rsalveti: morning
[14:16] <rsalveti> for the same annoying unlock logic we already had issues before
[14:17] <mandel> alex-abreu, tell me :)
[14:17] <alex-abreu> mandel, hey sorry to bother you again :)
[14:17] <mandel> alex-abreu, no bother!!! tell me
[14:17] <alex-abreu> mandel, was wondering what are the plans for the dl manager, in terms of landing (MIR) & backport to 13.10 (if it happens)
[14:18] <alex-abreu> mandel, the idea is that I have the html5 bindings for it, but not sure when to land them
[14:18] <mandel> alex-abreu, so, MIR yes as soon as I have all the packages ready and will ping the right person (mainly adding a few new packages for uploads etc..)
[14:19] <Mirv> sil2100: so, two main filling up issues - old pbuilder cow directories probably from the reboots etc, and then the ever-filling pbuilder aptcache
[14:19] <mandel> alex-abreu, those html5 bindings, were are they? in a diff project?
[14:19] <mandel> alex-abreu, backporting is something I'll do if people request it :)
[14:19] <alex-abreu> mandel, yup difff project where we (the #webapps team) handle the bindings
[14:19] <Mirv> the latter was already there, but today's reboots got the first problem to finally fill to 100%
[14:19] <alex-abreu> mandel, ok make sense, then I'll wait for the MIR to land it
[14:20] <alex-abreu> mandel, https://code.launchpad.net/~abreu-alexandre/unity-webapps-qml/download-api
[14:20] <mandel> alex-abreu, what I want to do is have an stable API (there are some changes coming for content-hub) before we make you do extra work
[14:20] <mandel> alex-abreu, they are not big changes, but nevertheless
[14:21] <Mirv> seb128: so for the time being the aptcache clean would have been enough. thanks for the comments/tips.
[14:21] <alex-abreu> mandel, yeah, the content hub changes have landed alreayd I think, the ones that relate to the revamp of the api
[14:21] <sil2100> t1mp: ok, UITK should be rebuilding now
[14:21] <alex-abreu> mandel, ok I'll wait, & try to keep track of the changes in DL manager ... keep me in the loop of you can (we are the team working on html5 apps & the platform bindings)
[14:22] <sil2100> Mirv: ok, a thing to remember then
[14:22] <mandel> alex-abreu, yes, but there are some changes in the pipeline of download manager to accommodate to the content-hub + browser estoy
[14:22] <mandel> alex-abreu, I'll make sure that you get all the info asap
[14:22] <alex-abreu> mandel, ok I'll monitor the changes
[14:22] <mandel> alex-abreu, I want to have everything landing on monday, then MIR then we can move fwd
[14:23] <alex-abreu> mandel, ok so around next week ..
[14:23] <mandel> alex-abreu, yes, that is the goal
[14:23] <alex-abreu> works for me
[14:23] <mandel> alex-abreu, the latests latest date will be the 4th, latest
[14:23] <Mirv> t1mp: so, your request was handled? sorry, during the hangout a situation evolved :D
[14:23] <sil2100> ;)
[14:24] <sil2100> asac: so, the situation seems stable now
[14:24] <alex-abreu> mandel, I am not in a hurry, thats fine, we are on shcedule, just dont like branches lying around
[14:24] <mandel> alex-abreu, yes, I have the same feeling that is why I like to land everything asap
[14:24] <alex-abreu> mandel, & wanted to make you aware of us :)
[14:25] <mandel> alex-abreu, you've been in my radar since last time we talked hehe
[14:25] <alex-abreu> cool
[14:25] <seb128> Mirv, yw!
[14:25] <alex-abreu> mandel,  the dlmanager will be a great piece in the platform apis much needed
[14:26] <sil2100> Driving quickly home from lunch, Mirv is monitoring, afk for 5-10 minutes
[14:27] <rsalveti> ogra_: thanks for fixing powerd, will update the testing plan and also propose another patch to just allow that interface that is needed for the unlock thing
[14:27] <rsalveti> still don't want a normal user to be able to access everything that powerd exports
[14:28] <asac> sil2100: awesome... what was done?
[14:29] <asac> sil2100: please stay on alert :)
[14:29] <rsalveti> sil2100: didrocks: can I get a silo for 46 now that powerd was fixed?
[14:29] <asac> seems today is a fun day :)
[14:29] <Mirv> rsalveti: he's driving, asssigning
[14:29] <Mirv> asac: yes it is :)
[14:29] <rsalveti> Mirv: thanks
[14:29] <t1mp> Mirv: yes it was handled by sil2100
[14:31] <Mirv> oh, boiko's request was left out in all this... :(
[14:31] <rsalveti> ogra_: didrocks: how can I run the same logic used to unlock the screen as done in the lab?
[14:32] <asac> Saviq: is your problem also solved?
[14:32] <Saviq> asac, one of them
[14:32] <asac> Saviq: whats the other?
[14:33] <Saviq> asac, ubuntu-touch-session fails to build the package for some reason http://<IP_ADDRESS>/job/landing-015-1-build/44/console
[14:33]  * Saviq tries locally
[14:33] <mandel> alex-abreu, yes, I think that the over all pict with the download manager and content hub is looking great and having html5 bindings is just great
[14:33] <asac> sil2100: can you check that once back?
[14:34] <Mirv> Saviq: can I flush your greeter split out temporarily as described in it?
[14:34] <rsalveti> asac: doanac: didrocks: can't we move the unlock screen logic to phablet-config or similar?
[14:34] <Saviq> Mirv, yes
[14:34] <asac> sil2100: Mirv: is the log i see here http://<IP_ADDRESS>/job/landing-015-1-build/44/console coming from launchpad?
[14:34] <rsalveti> it seems this is specific to the lab setup, so hard to reproduce outside the lab
[14:34] <asac> or is that preparing tsource packages?
[14:34]  * Saviq wonders if it's the lack of -1ubuntu1 in the version
[14:34] <Saviq> asac, preparing
[14:34] <asac> rsalveti: you hit a big wound
[14:35] <asac> rsalveti: talk sense into thomi
[14:35] <doanac> rsalveti: i would love that. i've ask for it before
[14:35] <rsalveti> asac: I know :-)
[14:35] <Saviq> rsalveti, we are
[14:35] <asac> doanac: how is the effort to standardize screen unlock going?
[14:35] <Saviq> rsalveti, https://code.launchpad.net/~mterry/unity8/unlock-script/+merge/212170
[14:35] <Mirv> Saviq: thanks!
[14:35] <Mirv> rsalveti: landing-008
[14:35] <doanac> asac: a script is now going into unity8 that should help
[14:36] <asac> doanac: a script that makes it easy to unlock?
[14:36] <rsalveti> Saviq: great, let me check
[14:36] <asac> doanac: then where will the unlock logic go? and where will be maintained which test needs unlocking
[14:36] <asac> ?
[14:36] <Saviq> rsalveti, we need to have (parts of it) in unity8 so that we maintain it in case of changes, other parts in lightdm and potentially usc
[14:37] <Saviq> rsalveti, and a bind-them-together script in $yet-unnamed-ubuntu-integration-test-suite
[14:37] <doanac> asac: ^^^
[14:37] <rsalveti> got it, cool
[14:37] <ogra_> rsalveti, i noted down in the bug how to use the same logic
[14:37] <Mirv> boiko: landing-013 for you, sorry for the delay, a bit chaotic today with jenkins crashing and filling up
[14:37] <doanac> so the script is just no longer owned by my team. we still should strive for getting phablet-test-run smart enough to do this for a test
[14:37] <rsalveti> ogra_: yeah, updating https://wiki.ubuntu.com/Process/Merges/TestPlans/Powerd
[14:37] <Saviq> ogra_, any idea on this failure to build a source package http://<IP_ADDRESS>/job/landing-015-1-build/44/console (scroll up a bit)
[14:38] <ogra_> rsalveti, perfect
[14:38] <Saviq> it builds fine locally :/
[14:39] <ogra_> Saviq, i have no clue what robru did to the branch ... i havent used it since he converted it to be a CI one
[14:39] <asac> Saviq: rsalveti: doanac: do we agree that the test itself should export/declare whether it needs an unlocked screen or not?
[14:39] <asac> even if we have a tool outside of the testharness that interprets that and does the unlock?
[14:39] <rsalveti> that would be ideal
[14:39] <rsalveti> a requirement for the test
[14:39] <seb128> sil2100, Mirv: are you debugging Saviq's ubuntu-session issue?
[14:39] <Mirv> boiko: I started a build for you too
[14:40] <ogra_> asac, ++
[14:40] <Mirv> seb128: sorry, no, I thought Saviq restarted it and it's ongoing, but I guess he removed that commit?
[14:40] <doanac> asac: that's ideal, i'm not sure how we'd go about doing that and i suspect thomi will disagree
[14:40] <asac> ok, so once our test declares that we dont need to maintain a separate list. thats a good start
[14:40] <seb128> Mirv, there is still an issue with that source/component that need debugging
[14:40] <doanac> but its ideal for me
[14:40] <asac> then next question is: why the hell are we not hooking the unlock logic into a superclass of all our unity based autopilot tests?
[14:40] <rsalveti> Mirv: thanks!
[14:41] <asac> i have been asking for that for like a year
[14:41] <doanac> asac: +10
[14:41] <Saviq> seb128, Mirv, I _think_ it's because it doesn't have a -0ubuntu0
[14:41] <seb128> Mirv, likely something in the vcs/debian dir that doesn't suit CI
[14:41] <Saviq> ogra_, oh, it doesn't actually have any train-ci entries in debian/changelog
[14:41] <asac> so the concrete class sets autounlock: true/false
[14:42] <Saviq> asac, only problem we need to make sure of is that this doesn't affect testing outside of the device
[14:42] <doanac> asac: and it can detect if its running on phone/desktop so if on desktop unlock is a noop
[14:42] <asac> Saviq: what does testing outside of the device mean?
[14:43] <Saviq> asac, on your desktop
[14:43] <asac> requireScreenUnlocked
[14:43] <asac> if you dont have a lock screen
[14:43] <asac> this would just return
[14:43] <asac> err do nothing
[14:43] <asac> doesnt feel like a big deal
[14:44] <asac> Saviq: are people really still testing apps on desktop?
[14:44] <asac> Saviq: isn't the usefulness of that going down more and more?
[14:44] <asac> i would imagine you usually want to use at least a few things of the touch platform to do anything not trivial
[14:44] <asac> but maybe i am wrong :)
[14:44] <Saviq> asac, apps are meant to run on desktop, too
[14:45] <Saviq> asac, and if anything, it's just about the development process
[14:45] <Saviq> asac, deploying to device every time you want to run a test when developing it is not good enough
[14:45] <doanac> but you could still check if you are on a phone/desktop and know that unlock is a no-op
[14:45] <Saviq> asac, verifying it after you know it's good on your host, sure, but not through the whole process
[14:45] <Saviq> doanac, sure
[14:47] <Mirv> seb128: Saviq: ubuntu-touch-session should drop debian/source/format (1.0) if it's wanted to be using CI Train now. otherwise it could be added to the "Additional source packages to land" and uploaded manually to the Landing PPA
[14:47] <Saviq> ogra_, ↑
[14:47] <Saviq> ogra_, it didn't get converted to train, upload manually?
[14:48] <Mirv> that's the fastest way
[14:48]  * Saviq fixes the line
[14:49] <ogra_> Saviq, hmm ? robru said it did
[14:49] <Mirv> ogra_: it seems it has needed traits mostly but it's probable the source format 1.0 is causing a proble still
[14:49] <ogra_> Saviq, just upload then
[14:49] <Saviq> ogra_, I can't
[14:50] <Mirv> robru probably meant "it has been marked to be converted to CI Train", but it hasn't been ever released via CI Train
[14:50] <ogra_> ??
[14:50] <ogra_> its a PPA
[14:50] <Mirv> dput ppa:ci-train-ppa-service/landing-015 *.changes
[14:50] <Saviq> ogra_, I'm not on the team
[14:50] <seb128> Mirv, you are sure the issue is the source format?
[14:50] <Saviq> ogra_, that can upload
[14:50] <Mirv> but right, ogra can, Savi qcan't
[14:50]  * ogra_ sighs ...
[14:51] <ogra_> ok, i try very hard to have some breakfast atm, then i have a meeting
[14:51] <ogra_> i'll do it after this
[14:51] <Mirv> seb128: not really sure but it's the first thing that gets my attention. I'm just trying to formulate a solution, not The solution.
[14:51] <seb128> ogra_, Mirv: we are sure that the issue is the v1 format?
[14:51] <seb128> Mirv, that might need further debugging rather than guessing?
[14:51] <Mirv> seb128: yes, but probably separately from this landing
[14:51] <Mirv> I can't do it now
[14:52] <seb128> Mirv, if that's the issue what about trying to convert to v3 and try again through CI train?
[14:52] <seb128> why not?
[14:52] <seb128> it seems like just bouncing the issue to the next one that is going to hit it
[14:52] <seb128> and it's probably going to waste time to remember the issue next time
[14:52] <seb128> it would be better handled now
[14:52]  * Saviq can do that
[14:52] <seb128> in a proper way
[14:52] <seb128> Saviq, thanks
[14:52] <Mirv> various reasons, I'm just trying to survive until sil2100 is back while didier is also away
[14:52] <Mirv> but if you have time, please update the MR instead
[14:52] <seb128> where is sil2100?
[14:53] <Mirv> seb128: driving a car :D
[14:53] <dbarth_> sil2100: silo 11 should be fully built now
[14:53] <seb128> he said 5-10 min
[14:53] <seb128> it was 30 min ago
[14:53] <seb128> sil2100, ?
[14:53] <Mirv> Saviq: so, debian/source/format -> 3.0 (native)
[14:54] <Mirv> I just thought saviq couldn't change that as it's mzanetti's branch
[14:54] <Saviq> Mirv, well, resubmit isn't difficult :)
[14:54] <seb128> well, he can add another branch to the landing
[14:54] <rsalveti> davmor2: auto-brightness should work with latest image (not yet on flo, working on it)
[14:55] <rsalveti> davmor2: you just need to enable it in system-settings
[14:55] <davmor2> rsalveti: nice I'm still breaking the last image but I'll certainly upgrade in a bit :)
[14:55] <Saviq> that silo is gonna hate me :D
[14:57] <davmor2> Saviq: we have a special silo just for you now number 666 now you'll know how a silo can hate ;)
[14:57] <Mirv> Saviq: thanks! let's see how it goes. the native versions are a bit rarer but 3.0 (native) could help.
[15:01] <plars> rsalveti, ogra_, ChickenCutlass: given the recent email about surfaceflinger support, can we kill off the sf4p job in CI?
[15:02] <ogra_> plars, ask asac
[15:02] <ogra_> i have never looked at it
[15:02] <plars> ogra_: he said to ask you :)
[15:02] <ogra_> move it then
[15:02] <ogra_> *re
[15:03] <asac> this was set up for ogra_ and rsalveti
[15:03] <asac> :)
[15:03] <ogra_> huh ?
[15:03] <asac> they wanted to keep SF going
[15:03] <rsalveti> yeah, I asked that
[15:03] <asac> for enablement path
[15:03] <ogra_> ah
[15:03] <rsalveti> plars: it's fine to disable it
[15:03] <asac> :)
[15:03] <plars> ogra_: I think the answer is obviously "yes, kill it" as it makes no sense to run something that will always fail. So I guess what I'm really saying is "you all aren't looking at this anymore right?"
[15:03] <rsalveti> plars: it was useful for a while, but yeah, can be killed now
[15:03] <plars> thanks
[15:04] <sil2100> Traffic jams
[15:04] <sil2100> I'm online now
[15:04] <seb128> sil2100, wb
[15:05] <Mirv> sil2100: we missed you! :)
[15:05] <sil2100> I know, sorry for that :<
[15:05] <asac> sil2100: wb :)
[15:05] <asac> can you check out saviq's issue? :)
[15:05] <sil2100> Sure!
[15:05] <sil2100> Mirv: you can go eat food made by your wife ;)
[15:06] <Mirv> sil2100: sounds good :D in a moment
[15:06] <sil2100> dbarth_: publishing your filo!
[15:06] <sil2100> *silo
[15:06] <Mirv> sil2100: so the ubuntu-touch-session hasn't seen a CI Train release before, and it's a native package versioning with debian/source/format set to 1.0. the first try Saviq is doing is change to 3.0 (native)
[15:06] <Saviq> Mirv, didn't help :|
[15:06] <Mirv> sil2100: ...and that didn't help
[15:07] <Saviq> http://<IP_ADDRESS>/job/landing-015-1-build/46/console
[15:07]  * Saviq wonders why it works locally
[15:07] <Saviq> is debuild different on there or something...
[15:07] <sil2100> Mirv: ok, I'll try taking it from here... so you tried the source format then?
[15:08] <Mirv> sil2100: Saviq: the second thing I see is that .bzr-builddeb/default.conf has Native = true. I think we've actually converted all native packages to be non-native now, so it might be that we need to drop both debian/source/ dir _and_ that .bzr-builddeb option and get back to normal 0.145+date-0ubuntu1 format
[15:08]  * Saviq tries
[15:08] <Mirv> sil2100: Saviq: I'm just not 100% sure if we're not supporting 0.145+date format for some package, ie could it work or should the native part be forgotten
[15:09] <sil2100> Mirv: I think it should work for all cases
[15:09] <Mirv> sil2100: second thing, I needed to free up the greeter split silo since we're critically low on silos and I couldn't have fulfilled boiko's request otherwise
[15:09] <sil2100> Mirv: ok, was Saviq informed? ;)
[15:09] <Mirv> sil2100: yes he agreed :)
[15:09] <Saviq> yup
[15:10] <Saviq> mterry is away today anyway, so it's his fault :D
[15:10] <sil2100> ;)
[15:11] <Mirv> sil2100: the CI Train should handle all cases and _convert_ to non-native versioning, is my assumption, but do you know if we have some CI Train package that continues to use native versioning ie. no "-0ubuntu1" part but just appended time stamps?
[15:11] <sil2100> Mirv: hm, no, actually I don't know of any package that would be right that
[15:12] <Mirv> if it's the former, then indeed what saviq is now doing should work, ie. dropping the two native options and letting CI Train do its magic
[15:12] <Saviq> Mirv, no... no go http://<IP_ADDRESS>/job/landing-015-1-build/47/console
[15:13] <sil2100> Mirv: anyway, I think I never saw any native = True project in CITrain and cu2d ;/
[15:13] <Saviq> wonder if I need to put one non-native version there at least
[15:13] <Mirv> Saviq: ah, don't remove the .bzr-builddeb directory, just the native = True!
[15:13] <Saviq> Mirv, oups
[15:14] <sil2100> Saviq, Mirv: so, why suddenly we decided to use citrain for ubuntu-touch-session btw.?
[15:14] <Saviq> sil2100, seb128 told us to :D
[15:14] <sil2100> Normally we have been doing it the source way
[15:14] <sil2100> Ah, ok ;)
[15:15] <seb128> heh, I didn't told you that! you tried it and hit issues, I just said to not work around them because it's just going to delay the debugging and pushing to the next one who is going to hit it
[15:15] <seb128> sil2100, Saviq: ^
[15:15] <sil2100> Right!
[15:16] <sil2100> Well, we can try working this out somehow anyway, let me dig into that now, need to familiarize on what's up
[15:16]  * Mirv goes eat, I hope the world doesn't explode and also that robru would be online too soon :)
[15:16] <Mirv> dinnertime
[15:16] <Saviq> seb128, ;)
[15:16] <sil2100> Mirv: ;p
[15:16] <Laney> Saviq: debian/bzr-builddeb.conf
[15:16] <Saviq> jeez
[15:16] <sil2100> Mirv: I'll mup you if suddenly I would need access to the jenkins instance ;p
[15:16] <Saviq> where else :D
[15:17] <Laney> I have no idea whatsoever what the .bzr-builddeb one is
[15:17] <Mirv> jeez, what's debian/bzr-builddeb.conf doing there...
[15:17] <Mirv> sil2100: :)
[15:17] <sil2100> .bzr-builddeb/default.conf is what you're looking for ;)
[15:17] <Mirv> sil2100: yeah but that debian/ has ^ file
[15:17] <sil2100> huh ;)
[15:18] <Laney> make it say split = True only
[15:18] <Laney> then bzr bd -S makes a proper package for me
[15:18] <Mirv> Laney: it's now there in .bzr-builddeb/, which is what all other packages use
[15:18] <sil2100> Yeah, that was the recommendation
[15:18] <Mirv> but there was duplicate conf files
[15:18] <Laney> Never heard of that
[15:18] <sil2100> native = True is a bad option for cu2d packages
[15:18] <Laney> I also don't get it if I branch that fix-source-package thing
[15:18] <Mirv> Laney: https://wiki.ubuntu.com/DailyRelease/InlinePackaging
[15:18] <sil2100> Laney: https://wiki.ubuntu.com/DailyRelease/InlinePackaging <- we used this since always in cu2d
[15:19] <sil2100> Mirv: ;D
[15:19] <sil2100> Mirv: go eat or you're starve!
[15:19] <Saviq> \o/
[15:19]  * Mirv goes
[15:19] <Saviq> IN YOUR FACE
[15:19] <Laney> weird
[15:19] <Saviq> Laney, thanks!
[15:19] <Laney> seems more obscure than a file in debian/
[15:20] <Laney> np
[15:20] <sil2100> o/
[15:21] <sil2100> *you'll
[15:23] <sil2100> seb128: I guess you're publishing your landings yourself, right? :)
[15:23] <seb128> sil2100, yes, did I overlook any?
[15:24] <seb128> sil2100, just publised 002
[15:24] <seb128> we should have quite some silos back soon
[15:24] <seb128> the release team has approved some items as well
[15:24] <sil2100> seb128: no no, just never sure if I should publish your landings when they are set to ready or not ;)
[15:24] <sil2100> Indeed, ido is still in proposed for isntance
[15:25] <seb128> sil2100, I usually do it if I'm online, but if I'm not around feel free to do it
[15:26] <sil2100> seb128: ok, thanks ;)
[15:34] <sil2100> Still waiting for some silos to finally free up
[15:36] <pmcgowan> bfiller, whats with silo 9 progress
[15:36] <sil2100> I see the silo is still blocked on ppc, even though it shouldn't
[15:36] <bfiller> pmcgowan: it built on supported arches, but CI train not showing correct status
[15:36] <sil2100> pmcgowan, bfiller: let me retry something
[15:36] <pmcgowan> ok cool so going to land?
[15:37] <bfiller> sil2100: it's failing on unsupported arches but that's expected
[15:37] <cjwatson> huh, what, I'm not sure my removal from last night took effect
[15:37] <sil2100> bfiller: yes, but cjwatson removed those arches from the archive, so it should be good now
[15:37]  * cjwatson goes to hit it harder
[15:37] <sil2100> cjwatson: it might, probably the job jwas ran too early
[15:37] <bfiller> pmcgowan: we can test it for sure
[15:37] <sil2100> Let me rekick with watch only
[15:38] <cjwatson> sil2100: no, it's literally still in the archive
[15:38] <bfiller> pmcgowan: still waiting on fix to make existing webapps transition correclty, that's not in yet
[15:38] <sil2100> cjwatson: ah, ouch
[15:38] <cjwatson> oh, bah, this is exactly what I predicted, that I'd have to do the work twice
[15:38] <cjwatson> https://launchpad.net/ubuntu/trusty/arm64/webbrowser-app
[15:39] <sil2100> That's so sad, deleted and republished
[15:39]  * cjwatson re-removes
[15:39] <sil2100> cjwatson: thanks!
[15:39] <asac> sil2100: any idea on the saviq case yet? :)
[15:39] <Mirv> asac: it was solved
[15:40]  * Mirv oh right, I'm not here
[15:40] <sil2100> asac: it's solved ;)
[15:40] <sil2100> asac: it seems there was a duplicate bzr-builddeb config that was forcing native even though we were fixing that
[15:41] <Mirv> it needed fixing in three places :S
[15:41] <sil2100> heh ;)
[15:41] <sil2100> Yay for redundancy!
[15:41] <sil2100> Proposed migration so slooow..! (ignore me)
[15:42] <cjwatson> sil2100: removal should be effective in 30 mins or so
[15:42] <sil2100> cjwatson: excellent, will re run the job then
[15:43] <asac> sil2100: Mirv: awesome!
[15:43] <cjwatson> check "rmadison -s trusty webbrowser-app" first, make sure it only lists supported arches
[15:43] <sil2100> bfiller: so, in that time I'll re-run with watch only and we won't have that irritating infinite-wait anymore
[15:43] <bfiller> sil2100: thanks
[15:45] <cjwatson> sil2100: the compiz/unity and unity-gtk-module silos should be m&c-able nowish
[15:46] <cjwatson> unity-control-center and ido are waiting for autopkgtests
[15:46] <sil2100> cjwatson: thanks! I didn't see ido yet in update_excuses, so I started to worry
[15:46] <cjwatson> it's still updating stats, but I'm watching the log
[15:47] <cjwatson> it's there now
[15:47] <sil2100> cjwatson: big thanks for the live-info ;)
[15:47] <cjwatson> I might have saved you a whole minute ;-)
[15:48] <sil2100> Every second counts!
[15:51] <boiko> Mirv: sil2100: do you by chance know if the silo builders are cleaned up after each build (in terms of package installation)?
[15:51] <sil2100> boiko: by silo builders, you mean those in the PPA?
[15:51] <boiko> sil2100: yep
[15:52] <cjwatson> PPAs start from a fresh chroot each time
[15:52] <sil2100> boiko: so, they work like normal PPA's, so every time a build starts it starts in a clean environment
[15:52] <boiko> sil2100: I'm just curious cause one of the telephony-service tests failed with a timeout, and for me this only happens when there is extra telepathy packages installed (like telepathy-logger for instance)
[15:52] <sil2100> boiko: but the PPA is not cleaned every time the CITrain Build button is pressed
[15:52] <boiko> cjwatson: sil2100: thanks
[15:53] <sil2100> boiko: shouldn't be the case here, if the logs don't say it's installed than it can't be there
[15:53] <cjwatson> it's definitely not possible for stale packages to be left around in a PPA build from a previous build
[15:53] <boiko> ok, so I will have to debug why this is happening
[15:53] <boiko> it is only on powerpc and ppc64el though
[15:54] <sil2100> boiko: try creating a clean pbuilder chroot for powerpc and building it locally - it might be reproducible everytime on that platform
[15:54] <boiko> sil2100: yeah. I will try that, thanks
[15:59] <cjwatson> boiko: maybe it's just racy; it doesn't happen for me on porter-ppc64el
[15:59] <ogra_> Saviq, so i see a bunch of MPs for the session stuff ... do you still need a direct upload from me or will it work now ?
[15:59] <boiko> cjwatson: hmm, shouldn't be, but in any case, is there a way for me to trigger a rebuild only on those archs that have failed?
[16:00] <Saviq> ogra_, works now
[16:00] <ogra_> yay
[16:00] <Saviq> ogra_, there were *3* places with Native = True or similar ;)
[16:00] <sil2100> ;)
[16:00] <ogra_> well, it was native before :)
[16:00] <ogra_> blame rob
[16:00] <sil2100> ogra_: yeah, 2 places with bzr-builddeb configs and the source format
[16:00] <Laney> "No, REALLY REALLY native"
[16:00] <Saviq> ogra_, bzr blames you :D
[16:00] <cjwatson> boiko: I can
[16:00] <ogra_> lol
[16:01] <Saviq> ogra_, at least for debian/bzr-builddeb.conf
[16:01] <ogra_> hmm, i cant remember ...
[16:01] <ogra_> ... the age ... y'know
[16:01] <ogra_> :)
[16:01] <cjwatson> boiko: just trying on one for now though to avoid wasting builder time
[16:02] <boiko> cjwatson: thanks
[16:02] <boiko> cjwatson: meanwhile I will try to create a pbuilder chroot to try locally
[16:02] <Saviq> blames lool for .bzr-builddeb/default.conf, and Renato for the last change to debian/source/format
[16:03] <sil2100> !
[16:03] <sil2100> Everyone's at fault!
[16:03] <cjwatson> hmm, IWBNI if we could grant landers temporary access to their active silos in LP so that they could retry builds themselves
[16:03] <cjwatson> s/ if//
[16:03] <Saviq> oh oh oh, unity won't lock now after I unlock it??! /me wants :D
[16:03] <Saviq> seb128, thanks for pushing ↑ through
[16:03] <seb128> Saviq, yw ;-)
[16:04] <ogra_> what ? did he break the extra added security when locking ?
[16:05] <seb128> sil2100, can I get silos for the 2 lines I added? we are back to 3 and some others cleaning soon
[16:05] <sil2100> seb128: just started assigning
[16:05] <seb128> sil2100, I would like to start builds before going for some exercice ;-)
[16:05] <seb128> sil2100, excellent, thank you!
[16:05] <sil2100> The spreadsheet takes a while to refresh ;)
[16:06] <lool> Saviq: hmm?
[16:09] <cjwatson> boiko: hm, failed again
[16:10] <Saviq> lool, nothing :)
[16:11] <cjwatson> boiko: well, it's grotty, but if you're in a hurry and this is blocking you, then it might be best to just disable that test on the offending arches
[16:11] <cjwatson> not great but it depends how much time you have available
[16:11] <boiko> cjwatson: ouch, well, I will have to try that locally, but pcreate is failing here to create a powerpc chroot,
[16:11] <cjwatson> you'll need the appropriate qemu bits
[16:12] <boiko> cjwatson: is it qemu-user-static? I already have that one
[16:14] <cjwatson> should be
[16:14] <cjwatson> I'm not a pbuilder user though so not going to be much use debugging that
[16:14] <boiko> cjwatson: no problems, thanks for the help
[16:19] <sil2100> seb128: are you away for exercise already?
[16:19] <seb128> sil2100, I just click clean on 3 silos and was about to go
[16:19] <sil2100> seb128: if yes, then I'll m&c your branches
[16:19] <seb128> sil2100, why?
[16:19] <sil2100> Ah
[16:19] <sil2100> Ok ;)
[16:19] <seb128> sil2100, the table has the "cleaning" status ;-)
[16:19] <sil2100> Already m&c'd dbarth_ silo ;)
[16:19] <seb128> great
[16:20] <seb128> back to 4 soon then
[16:20] <sil2100> Yeah, now I see it, when asking it was still m&c possible ;)
[16:20] <seb128> which gives some spare capacity for incoming demands
[16:20] <sil2100> Thanks!
[16:20] <seb128> yw, thanks for checking!
[16:21] <cjwatson> sil2100: hm, I wonder if the landing-009-1-build job needs to be cancelled and restarted in order to notice that the archive now has " webbrowser-app | 0.23+14.04.20140324-0ubuntu1   | trusty         | source, amd64, armhf, i386"?
[16:21] <cjwatson> or is that even something it will automatically notice at all?
[16:24] <cjwatson> ... looks like that worked
[16:25] <sil2100> cjwatson: yeah, I was already working on that ;)
[16:26] <sil2100> cjwatson: the problem was that even though I fixed the jenkins job, the spreadsheet was out of date
[16:27] <sil2100> I had to force it to update its status properly, since on the backend side everything was ok
[16:27] <sil2100> cjwatson: but thanks for the fix!
[16:28] <sil2100> Saviq: should I give you back the 'split greeter' silo?
[16:31] <Saviq> sil2100, next week I think
[16:32] <sil2100> k
[16:34] <sil2100> tvoss: regarding silo 20 - if you want to rebuild packages from the silo, you have to explicitly say which packages you want to rebuild - i.e. write down their source pacakge names in the field during rebuild
[16:35] <tvoss> sil2100, oh, my bad
[16:37] <sil2100> cyphermox, kenvandine: did anyone of you had a moment to take a look at the dee add-symbol-files branch I mentioned yesterday? :)
[16:37] <sil2100> I would love to get rid of that dh_makeshlibs -V already ;)
[16:41] <cyphermox> didn't look
[16:42] <plars> sergiusens: what are your plans with regards to phabletutils under phablet-tools? We were making use of detect_device in there, which throws an exception for flo.  I'm trying to decide if we should just implement our own, add support for flo in phablet-tools or what?
[16:55] <kenvandine> sil2100, sorry... i must have missed that
[16:56] <sil2100> No problem, nothing urgent ;)
[16:56] <sil2100> Just somethign I would prefer dealing with sooner or later
[16:58] <boiko> cjwatson: do you by chance have any example of a CMakeLists.txt that enables/disables stuff depending on the arch? (I'm trying to figure out the correct way of doing that)
[17:00] <cjwatson> boiko: I fear I'm not really much of a cmake expert
[17:02] <kenvandine> sil2100, give me a link, unless cyphermox is handling it
[17:02] <sil2100> kenvandine: one moment ;)
[17:03] <rsalveti> sil2100: can I haz a silo for 57?
[17:03] <sil2100> kenvandine: https://code.launchpad.net/~sil2100/dee-qt/add_cpp_symbols/+merge/202679
[17:03] <sil2100> rsalveti: let me look
[17:03] <sil2100> ogra_: meeting!
[17:05] <balloons> no call today?
[17:06] <kenvandine> sil2100, shouldn't the symbols file have replaceme instead of the version?
[17:06] <ogra_> balloons, feel free to join :)
[17:06] <balloons> I'm sitting alone i one
[17:06] <kenvandine> or is that not supported for c++
[17:06] <ogra_> balloons, in the one from the calendar  ?
[17:06] <balloons> d'oh, wrong g+ invite, hahahah
[17:06] <ogra_> :)
[17:13] <sil2100> Saviq: so, any progress on the unity8 crasher now that we might be able to retrace it?
[17:13] <Saviq> sil2100, yeah, Albert just pushed a fix to be verified
[17:14] <Saviq> sil2100, https://code.launchpad.net/~aacid/unity8/lvwphnoprocessevents/+merge/213306
[17:21] <sil2100> Saviq: thanks!
[17:21] <sil2100> Saviq: can't wait to see it in a silo ;p
[17:32] <balloons> ping retoaded
[17:37] <balloons> retoaded, the click job for calendar is failing to complete successfully because of a mv command at the end of the script. Can you have a look? http://s-jenkins.ubuntu-ci:8080/job/calendar-app-click/103/console
[17:38] <davmor2> Saviq, didrocks, sil2100: Well stone me if that wasn't a waste of time bug #1299129
[17:38] <davmor2> Saviq, didrocks, sil2100: Well stone me if that wasn't a waste of time bug #1299129
[17:39] <davmor2> see even the bug bot hates me
[17:40] <didrocks> davmor2: nice!
[17:40] <davmor2> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1299129
[17:40] <davmor2> didrocks: read the stacktrace so after all that still no better off
[17:41] <didrocks> davmor2: well, it will be for Saviq :)
[17:41] <davmor2> any way teatime
[17:43] <retoaded> balloons, looking
[17:50] <Saviq> davmor2, yeah, same thing
[17:53] <sil2100> uh
[17:54] <sil2100> boiko: so, how's it going with those build problems?
[17:56] <retoaded> balloons, kicked off another build, should complete this time
[17:56] <balloons> retoaded, thank you much
[17:57] <sil2100> balloons: hi! So, could you release something to the store for me? :)
[17:57] <balloons> sil2100, I'd love to
[17:57] <balloons> hopefully it goes better than popey and I's releases :-p
[17:57] <boiko> sil2100: I asked tiago to disable the tests on ppc* for now, will rebuild soon
[17:58] <sil2100> balloons: so, currently lp:~ps-jenkins/gallery-app/trusty-proposed is where the latest gallery-app is right now ;)
[17:58] <sil2100> balloons: this will be merged into trunk pretty soon, but you can use it to release right now ;)
[17:58] <sil2100> balloons: thanks!
[17:59] <sil2100> boiko: excellent!
[18:00] <retoaded> balloons, success
[18:25] <davmor2> Saviq: that was expanding the apps which I guess will be a similar issue as didrocks reported too so looks like they might all be intertwined maybe :)
[18:29] <davmor2> Saviq: that is of course not to say that something else triggered it and the lock up happened on expanding apps :)
[18:44] <Saviq> davmor2, yeah, until we have those two killed, we won't dig deeper
[18:44] <sil2100> Have a nice weekend guys, time to go to bed and get better o/
[18:45] <davmor2> sil2100: enjoy bed if nothing else dude and get well
[18:46] <davmor2> Saviq: oh there is a potential fix too by the look of it I might look at installing it and see what crashers I get over the weekend
[18:49] <Saviq> davmor2, yeah there's two potential fixes
[18:49] <Saviq> davmor2, attached in branches to https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1262711
[18:49] <davmor2> Saviq: should I be worried by https://code.launchpad.net/~aacid/unity8/lvwphnoprocessevents/+merge/213306
[18:49] <Saviq> davmor2, you mean CI results?
[18:49] <davmor2> Saviq: yes
[18:50] <Saviq> davmor2, bad whitespace in line 2112
[18:50] <Saviq> davmor2, so no :)
[18:50] <Saviq> davmor2, fwiw https://wiki.ubuntu.com/CrossBuilding should work for building unity8
[19:08] <davmor2> Saviq: gah I hat this building stuff from source I'll have a look tomorrow if there is a build available.  I'm calling it a week :)
[19:09] <davmor2> s/hat/hate
[19:28] <boiko> cyphermox: rsalveti: robru: landing-013 properly tested already, good to go
[19:28] <robru> boiko, thanks
[19:30] <cyphermox> ok
[20:10] <boiko> robru: do I need to clean the silo or did you already triggered that?
[20:10] <robru> boiko, oh normally you would, but I did it since we're crunched for silos today.
[20:10]  * robru is slightly impatient ;-)
[20:12] <boiko> robru: ok, thanks
[20:12] <robru> boiko, you're welcome!
[22:38] <rsalveti> sergiusens: hey
[22:39] <sergiusens> rsalveti: nice; it works :-)
[22:40] <rsalveti> :-)
[22:47] <bregma> robru, got a quickie needs a silo in line 58, you up to it?
[23:28] <robru> bregma, hey, sure
[23:29] <robru> bregma, sorry, was on lunch there
[23:29] <robru> bregma, ok you got silo 2
[23:29] <bregma> ta
[23:31] <robru> yw
[23:51] <bregma> robru, silo 2 is ready for publish
[23:51] <robru> bregma, wow, already?
[23:51] <bregma> told ya it was quick
[23:51] <robru> nice
[23:51] <bregma> it's a small package, and either it boots or it doesn't
[23:52] <bregma> and it did
[23:52] <robru> bregma, hah. ok, published!
[23:52] <bregma> waited 2 hours for it to build in a PPA earlier today