[00:30] <robru> bregma, I tried assigning row 24 for you but the third mp in your list 404'd
[00:43] <robru> bfiller, do you know what's going on in silo 12? I can't seem to publish it, it claims that the packages don't have the latest revisions from distro, but distro doesn't seem to have anything new in it...
[01:29] <boiko> robru: so, no idea what is going on on silo 12
[01:29] <robru> boiko, ok, me either. I rebuilt everything because that's what the error message seemed to indicate it wanted me to do. no idea why though
[01:30] <boiko> robru: well, thanks for rebuilding it
[01:31] <robru> boiko, you're welcome! i hope it works now...
[01:38] <robru> boiko, oh well, it's published now
[01:55] <boiko> robru: nice, thanks!
[01:55] <robru> boiko, you're welcome!
[02:04] <imgbot> [02:28] <bregma> robru, I fixed the errant MP from row 24 if you want to try again
[02:29] <robru> bregma, good to go in silo 2
[02:29] <bregma> ta
[02:29] <robru> yw
[02:31] <robru> bregma, oh, and http://people.canonical.com/~rbpark/citrain/#?q=bregma ;-)
[02:57] <cyphermox> robru: could you reconfigure 14 with the added MPs if you're still around?
[02:59] <robru> cyphermox, done
[03:01] <cyphermox> ah crap
[03:01] <cyphermox> robru: cool thanks
[03:01] <robru> cyphermox, you're welcome. what's wrong?
[03:01] <cyphermox> sorry for the noise, it was coming back to me now how to do this
[03:01] <robru> cyphermox, yeah you gotta use the prepare job from the spreadsheet
[03:02] <cyphermox> yeah, and these things are all already in another silo :X
[03:02] <cyphermox> grr, I knew it was better to just land urfkill first and then do the rest
[03:05] <cyphermox> shiny, this is going to be fun to deal with
[03:13] <cyphermox> Wellark: please check with tvoss to approve https://code.launchpad.net/~kaijanmaki/dbus-cpp/read-only-properties-changed-fix/+merge/221839 and any other of the merges you provided me for flight mode
[03:13]  * cyphermox is going to bed
[03:44] <imgbot> [03:44] <imgbot> [06:38] <veebers> infinity: Can I ask you about this SRU? https://bugs.launchpad.net/ubuntu/+source/pygobject/+bug/1333512
[06:40] <veebers> I was hoping to get an idea of when it might get accepted for Trusty?
[06:41] <infinity> veebers: 3 seconds ago.
[06:42] <infinity> veebers: Go forth and verify the build in proposed (once it happens).
[06:50] <oSoMoN> sil2100, hey, can we land silo 4 ?
[06:50] <oSoMoN> s/land/publish/
[06:51] <veebers> infinity: awesome, thanks :-)
[06:55] <Mirv> oSoMoN: I'm looking at it, but we need a packaging ack
[06:55] <oSoMoN> Mirv, is there a link to the packaging diff?
[06:56] <oSoMoN> Mirv, and who do you reckon could ack them?
[06:56] <Mirv> oSoMoN: any core dev can ack them. there's no automated link for manually uploaded sources.
[06:56] <Mirv> oSoMoN: this's the debian/ http://pastebin.ubuntu.com/7769054/ at least
[06:58] <Mirv> I'm not entirely sure how to do this for such a big package, usually the automated diff for real Train packages contains also Makefile diffs etc. but that debian dir ack should probably be fine acked alone too.
[06:58] <Mirv> obviously the maintainer change is not needed, but it's simply because I fixed it in my Qt 5.3 rebuild upload and the fix wasn't integrated back
[06:58] <Mirv> oh, right, it also removes the changelog entry for the 5.3 rebuild
[06:59] <oSoMoN> :/
[06:59] <oSoMoN> let’s not request a full rebuild just for a changelog entry, shall we?
[07:00] <Mirv> I wouldn't, although I'd still hope that eventually there would be lp:oxide that can actually match the package (ie have packaging & all)
[07:01] <oSoMoN> I mean: is there a way to avoid rebuilding the entire package (takes 4+ hrs on armhf) while fixing the changelog?
[07:01] <Mirv> bzr isn't very scalable to oxide needs, though
[07:01] <Mirv> no, there's no way to fix that manually. I don't mind me being erased from history, myself ;)
[07:03] <oSoMoN> lool, hey, if you’re around, we’re trying to land version 1.1.0 of oxide (it’s in silo 4) and we need a packaging ack from a core-dev, changes are there: http://pastebin.ubuntu.com/7769054/
[07:08] <Mirv> thanks, let's see who we'll catch
[07:12] <Mirv> probably all Germans have partied through the night or such
[07:18] <oSoMoN> lool, nevermind, I got an ack from dholbach already
[07:18] <Mirv> oSoMoN: the silo needs a juggle, but probably I can fix it the same way I fixed the other silo. it seems to me some indexes have been erased from the system or such.
[07:18] <Mirv> I need to prepare silo (reconfigure) and watch only build
[07:19] <Mirv> so I just wanted to say something before that scary error pops up :) resolving.
[07:19] <oSoMoN> Mirv, not sure I understand exactly what’s going on, but if you say you can fix it, then go ahead :)
[07:19] <Mirv> oSoMoN: it says version "0" now somewhere, for some reason
[07:19] <Mirv> and errors out because of that, but refreshing seemed to help
[07:21] <Mirv> sil2100: ^ you might be interested, since this is the second silo now where I get Version in ... (0) is not the last one prepared (real-version-number)
[07:25] <Mirv> worked again
[07:31] <sil2100> hmmm
[08:11] <Eisbrecher_xnox> i vaguely remember seeing an email about airline, something about verification of it. But i'm fuzzy on the details and can't find that email atm.
[08:11] <Eisbrecher_xnox> was there some email about it? and what is ci-engineering-airline?
[08:12] <cjwatson> It's still going through acceptance testing
[08:12] <cjwatson> I was doing some of that with click; got stalled on a bug
[08:15] <Eisbrecher_xnox> ok. Oh, and found the email.
[08:18] <cjwatson> Eisbrecher_xnox: ci-engineering-airline is the analogue of ci-train-ppa-service.  Gotta have something to own the PPAs.
[08:18] <Eisbrecher_xnox> ack.
[08:18] <brendand> sil2100, so we're right back to where we started. that's really annoying
[08:20] <sil2100> brendand: yeah... doubt we'll have a green image till the end of the week ;/
[08:20] <sil2100> brendand: what's up with those UITK failures?
[08:20] <ogra_> unity8 seems to have crashed during the test
[08:21] <ogra_> (during the UITK test)
[08:21] <brendand> ogra_, the dashboard is angry at what you did to brazil ;)
[08:21] <ogra_> lol
[08:22] <brendand> sil2100, i can only hope all the issues we see are clear and reproducible
[08:23] <ogra_> well i wonder if the unity8 crash will happen again if you re-run the UITK test
[08:23] <Mirv> brendand: sil2100: it seems we lack the required app updates in the store at least to go with UITK
[08:24] <ogra_> if it reproducable there is surely some issue ...
[08:24] <brendand> Mirv, probably that is true for most of the failures
[08:24] <sil2100> Mirv: I thought popey already updated those
[08:24] <ogra_> which ones were that, do we have a list ?
[08:24] <Mirv> sil2100: yes he did (on #sdk)
[08:24] <sil2100> popey: ^ right? You uploaded the required core apps for the new UITK, right?
[08:25] <Mirv> so already two days ago
[08:25] <brendand> Mirv, i just don't want to see another issue like we had with webbrowser where it takes months to figure out what is happening
[08:25] <popey> I updated the ones bzoltan asked me to
[08:25] <Mirv> that just seemed like a logical explanation since there are eg. swipe/delete related failures
[08:25] <ogra_> popey, i dont see updates since 118
[08:25] <popey> ogra_: yes, that was two days ago, when the apps were updated
[08:26] <ogra_> oh
[08:26] <ogra_> i thought they were supposed to go in alongside not ahead
[08:26] <popey> it doesn't matter
[08:26] <ogra_> k
[08:26] <popey> i tested all of them on both my devel and proposed phones
[08:26] <popey> to make sure existing users were not affected
[08:31] <sil2100> ogra_: I'll be late 2-3 minutes
[08:34] <Mirv> no worries, we're listening to music here
[08:42] <ogra_> bzoltan, seems the sdk package test is failing again (checking for an obsolete transitional package)
[08:43] <bzoltan> ogra_: arghh...
[08:43] <ogra_> http://ci.ubuntu.com/smokeng/utopic/touch/mako/121:20140709:20140709/8946/sdk/1348095/
[08:44] <Mirv> bzoltan: we discussed it already, we need to poke someone since it's using an old name for a package that doesn't exist anymore
[08:44] <bzoltan> Mirv: ogra_: I fix it in a sec
[08:45] <Mirv> I think someone did some deserved archive cleaning just finally
[08:45] <ogra_> thanks :)
[08:47] <cjwatson> Mirv: I deleted that package on 2014-03-14!
[08:48] <rsalveti> sil2100: can you reconfigure silo 14?
[08:48] <cjwatson> https://launchpad.net/ubuntu/trusty/armhf/libqt5graphicaleffects5
[08:48] <bzoltan> ogra_: Mirv: I pushed the change... but the next natural step with that sdk tests would be to move to the real project and drop that obsolate for good
[08:48] <sil2100> cjwatson: want to reconfigure that one? ^ You have to do it from the spreadsheet, find the row with the landing and do the same thing as while assigning
[08:49] <sil2100> cjwatson: once a silo is assigned already, assigning it again opens up the reconfigure window
[08:49] <Mirv> sil2100: I added notes-app to bug #1330352 where these swipe things were handled
[08:50] <rsalveti> and I'm getting a weird issue with silo 5
[08:50] <rsalveti> 2014-07-09 08:49:50,925 ERROR Version in ci-train-ppa-service/landing-005 (0) is not the last one prepared (0.3+14.10.20140708-0ubuntu1) (direct upload?).
[08:50] <rsalveti> 2014-07-09 08:49:56,156 ERROR Some packages in the ppa are not at the latest version. Please rerun the prepare job, eventually only with that project.
[08:51] <cjwatson> sil2100: looking
[08:51] <ogra_> Saviq, we seem to have a unity8 crash during the UITK tests (which makes a lot for the tests fail then) http://ci.ubuntu.com/smokeng/utopic/touch/mako/121:20140709:20140709/8946/ubuntuuitoolkit/
[08:51] <Mirv> brendand: see the 1330352 above too ^
[08:51] <ogra_> (not sure if it is even reproducable)
[08:52] <cjwatson> sil2100: newbie question, why does it need reconfiguring?  Is it because it previously only contained urfkill?
[08:52] <cjwatson> rsalveti: which job produced that output?
[08:53] <rsalveti> cjwatson: silo 5
[08:53] <rsalveti> just triggered a rebuild
[08:53] <rsalveti> said it was already built, but can't publish because it's not the latest version
[08:53] <cjwatson> rsalveti: I mean which URL to the jenkins console output
[08:53] <rsalveti> cjwatson: https://ci-train.ubuntu.com/job/landing-005-2-publish/50/console
[08:54] <imgbot> [08:54] <Saviq> ogra_, lemme have a look
[08:55] <Mirv> rsalveti: cjwatson: I found out earlier today with two silos there's something funky going on, train thinks a version is 0. I know how to fix it, though (no-op reconfigure + build with "watch_only")
[08:55] <Mirv> it feels like some table got resetted or such
[08:55] <cjwatson> I'm wondering if it has anything to do with the recent change in LP PPA URL format
[08:56] <sil2100> cjwatson: reconfigurations are needed when new merges and/or sources are added, since the backend doesn't fetch those from the google spreadsheet on build time but only during assignment
[08:57] <Mirv> sil2100: this particular issue is the one I mentioned in the morning
[08:57] <cjwatson> sil2100: OK - where can I see what the backend currently has?
[08:57] <Mirv> but hmm I think you discuss another thread here, ignore moe
[08:57] <sil2100> cjwatson: most of the time the lander itself can reconfigure the silo, but whenever a new 'project' is added to the silo list, we actually have to reconfigure it for them
[08:57] <sil2100> cjwatson: it's in the backend, let me find the link
[08:57] <cjwatson> sil2100: Does "09:53 -queuebot:#ubuntu-ci-eng- Silos: landing-014 (cyphermox) state is now 'Preparing packages' (connectivity-api, dbus-cpp, indicator-network, ubuntu-system-settings)" mean you already reconfigured?
[08:57] <sil2100> cjwatson: http://people.canonical.com/~platform/citrain/
[08:58] <sil2100> cjwatson: I didn't reconfigure any silo right now, maybe Mirv did that?
[08:58] <sil2100> Mirv: what was the exact case in the morning that you had?
[08:58] <Mirv> no, I did not reconfigure anything but the ones I published
[09:00] <Mirv> sil2100: well the one I pointed out at http://irclogs.ubuntu.com/2014/07/09/%23ubuntu-ci-eng.html#t07:21 and that ricardo is seeing above too
[09:00] <rsalveti> it seems mhr3 tried to build the silo
[09:01] <rsalveti> silo 14
[09:01] <cjwatson> rsalveti: ubuntu-system-settings conflicts with silo 6; dbus-cpp conflicts with silo 8 (ignorable?); connectivity-api and indicator-network conflict with silo 11
[09:01] <mhr3> rsalveti, yep, i started the rebuild, anything wrong with that?
[09:01] <Mirv> I saw that for both oxide and qtdeclarative silos, the version in PPA is thought to be 0
[09:02] <rsalveti> mhr3: just because I was asking for it to be reconfigured, and it seems we also got a few conflicts
[09:02] <rsalveti> let me check the conflicts
[09:02] <mhr3> rsalveti, oh, can you pls sync with Wellark then?
[09:03] <sil2100> cjwatson: yeah, silo 11 also can be ignored for now from what the upstream developer mentioned
[09:03] <sil2100> (but yeah, it's also our job to make sure the conflicts are sane and all parties know what's going on)
[09:04] <cjwatson> >>> from cupstream2distro import packagemanager
[09:04] <cjwatson> >>> packagemanager.get_current_version_for_series("goget-ubuntu-touch", "utopic", "ci-train-ppa-service/landing-005")
[09:04] <rsalveti> sil2100: cjwatson: yeah, the conflicts are all fine
[09:04] <cjwatson> u'0.3+14.10.20140709-0ubuntu1'
[09:04] <cjwatson> hmm
[09:05] <cjwatson> rsalveti: ok, I'll reconfigure harder
[09:05] <rsalveti> silo 6 is also in testing mode
[09:05] <cjwatson> done
[09:06] <rsalveti> thanks
[09:07] <Mirv> reconfigure + build with watch_only checked fix both silos for me to be in publishable state again
[09:08] <Mirv> sil2100: so just in case you see the similar error still with the other silos
[09:11] <Saviq> ogra_, looks like a crash in Mir, uploading now
[09:12] <ogra_> ah, cool
[09:12] <ogra_> thanks for looking !
[09:12] <cjwatson> Mirv,sil2100: hang on a bit, would like to investigate this centrally ...
[09:12] <cjwatson> I suspect this has to do with silos configured before the PPA URL format change
[09:13] <sil2100> Oh
[09:14] <cjwatson> Though I'm not having any luck reproducing it
[09:14] <Saviq> ogra_, nothing in .changes suggests any relation :|
[09:15] <ogra_> no, it doesnt
[09:15] <cjwatson> Maybe it's best just to reconfigure/build-watch-only everything affected, but I'd like to hear about it if anything configured from now on shows this
[09:15] <Saviq> ogra_, bug #1339610, let's see what a retrace comes up with and will make public then
[09:15] <Saviq> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1339610
[09:15] <Saviq> ubot5, yeah yeah
[09:15] <ogra_> well, we had a new libhybris and accompanying android rebuild
[09:15] <ogra_> but looking at the changelogs that shouldnt cause such issues
[09:18] <Mirv> ok
[09:19] <cjwatson> I'll see about fixing up the silos that look like they may be affected by this and that aren't building or publishing at the moment - that's 3, 6, 7, 8, 11, 15, 18
[09:19] <rsalveti> ogra_: no, minor change
[09:19] <cjwatson> Unless anyone thinks this is foolish?
[09:19] <rsalveti> changes
[09:19] <ogra_> right
[09:19] <cjwatson> sil2100: ^-
[09:22] <sil2100> cjwatson: seems fair, please do o/
[09:25] <rsalveti> cjwatson: yeah, got the same issue on silo 5
[09:25] <rsalveti> https://ci-train.ubuntu.com/job/landing-005-2-publish/51/console
[09:26] <cjwatson> rsalveti: will sort it
[09:27] <cjwatson> wish I could see the cupstream2distro bug, but whatever, this is good enough; not like the URL format's going to change every day :)
[09:29] <cjwatson> rsalveti: Try now?
[09:29] <cjwatson> (queuebot's a little behind)
[09:29] <cjwatson> I ran the watch-only build too
[09:29] <rsalveti> cjwatson: seems it finished fine now, thanks
[09:29] <cjwatson> Great
[09:37] <Saviq> ogra_, humpf, retracer barfed :|
[09:37] <ogra_> dang
[09:37] <Saviq> ogra_, I'll try and see if I can repro locally
[09:38] <Saviq> with all packages up to daye
[09:38] <Saviq> date
[09:40] <cjwatson> ok, all should be fixed now apart from 0 (test), 1, 10, 19 (migrating)
[09:40] <cjwatson> if it affects m&c for any of the last three then I guess we force
[09:45] <cjwatson> sil2100: do merges need to be top-approved before we can assign silos?
[09:47] <sil2100> cjwatson: normally, yes, but CI Train actually checks for that itself - it will allow a silo to be assigned but the lander won't be able to build anything if the merges are not approved
[09:47] <sil2100> So you can assign a silo and CI Train will make sure they're approved before proceeding
[09:47] <cjwatson> ok
[09:49] <cjwatson> mhr3: This conflicts with silo 8 - assigning anyway since that's some way off ready, but please coordinate with tvoss
[09:51] <mhr3> cjwatson, what doesn't conflict with 008? :) but yea, thx
[09:51] <cjwatson> Indeed
[09:52] <cjwatson> sil2100: So I did a first run of assignment for line 26, and got a conflict; I'd now like to run it again overriding that, but Landing team tools -> Assign to silo brings up a Reconfigure script which fails.  Do I need to clear the request ID manually or something?
[09:53] <sil2100> cjwatson: ah, there is a trick to that
[09:54] <sil2100> cjwatson: so, just dismiss that pop-up, move to column number K of that landing and remove the UID generated there
[09:54] <sil2100> cjwatson: and now you can run the assignment again
[09:54] <cjwatson> right, clear the request ID then
[09:54] <cjwatson> thanks
[09:54] <ogra_> sil2100, not sure you saw the conversation above but it seems the UITK failures are Mir issues
[09:55] <sil2100> cjwatson: the deal is: once you open the pop-up, until it's open you can assign the silo as long as you want, but if it gets closed and you want to 'assign' instead of 'reconfigure', you have to clear out the UID
[09:55] <Wellark> rsalveti: hi, could you trigger a rebuild on silo 14.. there was an outdated version requirement to dbus-cpp on connectivity-api. fixed now.
[09:55] <ogra_> (or rather the unity8 crash is a Mir issue and the UITK failures are fallout)
[09:55] <sil2100> ogra_: Mir issues? We didn't have a new Mir upload since 0.4.0, now did we?
[09:55] <sil2100> huh
[09:55] <cjwatson> sil2100: Got it, thanks
[09:55] <sil2100> cjwatson: yw!
[09:55] <rsalveti> Wellark: I just triggered a build a few minutes ago
[09:56] <rsalveti> Wellark: do you want another rebuild after this one finishes?
[09:56] <ogra_> sil2100, well, Mir causes unity8 to crash ... which in turn causes the failures
[09:56] <ogra_> sil2100, bug 1339610
[10:00] <Wellark> rsalveti: gimme a sec. let's see how it goes.
[10:03] <sil2100> ogra_: I guess we need to escalate that to the upstream, but it makes me wonder why it suddenly started happening after the UITK landing
[10:04] <sil2100> And why not before
[10:04] <sil2100> But I see Daniel already commented on the bug
[10:05] <ogra_> sil2100, no idea ... but Saviq is on it
[10:05] <sil2100> Ok, I jump out for that quick meeting with my old thesis supervisor
[10:06] <sil2100> Be back soon
[10:07] <Wellark> rsalveti: ok, please trigger a rebuild.
[10:07] <rsalveti> Wellark: ok
[10:15] <rsalveti> Wellark: done
[10:16] <Saviq> can anyone reconfigure silo 6 for us? unity8-desktop-session was added
[10:16] <Saviq> rsalveti, sympathies...
[10:17] <rsalveti> Saviq: yeah :-(
[10:18] <cjwatson> Saviq: looking
[10:19] <cjwatson> Saviq: conflicts with silo 2, please check with bregma
[10:19] <imgbot> [10:19] <imgbot> [10:19] <Saviq> cjwatson, I'll coordinate, bregma will land his before ours
[10:20] <cjwatson> Saviq: ok, I'll add a note that yours needs to be rebuilt after his lands
[10:20] <Saviq> cjwatson, yup, thanks
[10:25] <cjwatson> Saviq: ^-
[10:25] <Saviq> cjwatson, thanks
[10:25] <Saviq> ogra_, 269 tests OK on my phone
[10:25] <Saviq> running again, but no high hopes
[10:27] <davmor2> sil2100: I just got that welcome screen lock up on my mako again \o/
[10:34] <davmor2> sil2100: oh I wonder if the Qt5 crash has anything to do with it :(
[10:34] <davmor2> Mirv: ^
[10:45] <Mirv> hmm
[10:46] <greyback> cjwatson: hey, I'm getting strange error on silo 6: ERROR Some projects are missing their 'twin package' uploads (e.g. their -gles counter-parts): qtubuntu-gles.
[10:46] <greyback> cjwatson: seen that before? qtubuntu-gles is not a package name, qtubuntu-android is the right name for the package with gles support
[10:47] <cjwatson> greyback: qtubuntu-gles is the source package name - https://launchpad.net/ubuntu/+source/qtubuntu-gles
[10:47] <ogra_> greyback, nope, that error is right ...
[10:48] <ogra_> there are many ptubuntu packages with -gels equivalent that the emulator uses (gles support is a compile time switch atm ... so for the i386 emulator we needed to rebuild the packages with that enabled)
[10:48] <ogra_> *qtubuntu
[10:49] <ogra_> the -gles packages always need to be recompiled alongside thier nonn -gles equivalents
[10:50] <Laney> is it really exactly the same thing with a different flag?
[10:50] <rsalveti> yeah, the problem is that qtubuntu has qtubuntu-desktop and qtubuntu-gles
[10:50] <popey> bzoltan: bug 1339616 and bug 1339627 reported against core apps after UITK landing. How come these weren't found during testing before landing?
[10:50] <greyback> so how do I proceed?
[10:50] <rsalveti> but what we need is qtubuntu-gles for x86
[10:51] <rsalveti> and for that we need to build against a different qt (qt-gles)
[10:51] <rsalveti> that's why we have qtubuntu-gles
[10:51] <rsalveti> greyback: just need to sync the qtubuntu-gles package with your changes, and upload that to the silo
[10:52] <greyback> ok
[10:52] <ogra_> Laney, it should be, yes
[10:52] <bzoltan> popey: for some reason I got false OK for these ... no idea how
[10:53] <Laney> ogra_: couldn't they be a single source which does multiple builds then?
[10:53] <ogra_> Laney, it is a temporary solution that we can drop if the runtime detection of QT5 works right
[10:53] <bzoltan> popey: We have sent MRs for like 6 apps to fix tests... we could have done 8
[10:54] <ogra_> Laney, that would be a pretty complex package change (there are quite a few -gles packages) for a temporary hack that we plan to drop asap
[10:57] <rsalveti> yup, that's why we decided to do another src package for it
[10:59] <brendand> bzoltan, who gave the ok?
[11:00] <bzoltan> brendand:  me
[11:00] <bzoltan> brendand:  so it is only me to blame
[11:02] <cjwatson> ricmm: please let tvoss and mandel know to rebase silos 8 and 11 on top of yours, if you land before them
[11:02] <mandel> cjwatson, got it, he can land first, I'll rebase, not a big deal
[11:02] <brendand> bzoltan, there's no need to assign blame to anyone - just try and figure out where the process can be improved
[11:03] <ricmm> cjwatson: ok, although we just decided to change the branch
[11:03] <Saviq> ogra_, sil2100, second UITK run 269 OK
[11:03] <ricmm> not sure if CI train scripts play well with utopic packaging branches
[11:04] <cjwatson> I doubt it
[11:04] <ogra_> Saviq, yeah, i guess if you dont hit the crash you wont see failures in the tests
[11:04] <Saviq> ogra_, yeah, no crash at all
[11:04] <ogra_> right :(
[11:04] <Saviq> like /var/crash *empty*
[11:04] <cjwatson> Well, since you're merging into lp:media-hub it should be OK actually, but better style to keep the namespaces separate
[11:04] <Saviq> this doesn't happen too often
[11:04] <Saviq> ogra_, sil2100, I say we monitor it
[11:04] <ogra_> yup
[11:05] <ogra_> 122 just started its test run ...lets see how it comes out
[11:06] <ricmm> can I get a reconf on silo 005 ?
[11:07] <ricmm> sorry, bad timing :)
[11:07] <ricmm> actually I can probably do that myself from jenkins
[11:14] <ricmm> cjwatson: colin, could you configure 005 with force enabled? for the conflict
[11:16] <cjwatson> ricmm: the force flag would need to be on the build, not a reconfigure
[11:16] <cjwatson> ricmm: you don't have that checkbox?
[11:17] <cjwatson> ricmm: actually, I don't see a conflict, it's just an unapproved merge; you could get the merge approved?
[11:17] <ricmm> cjwatson: yup its approved now, salveti said we'd need the force flag on configure
[11:17] <ricmm> but if its on build, I can do it, thank you
[11:18] <cjwatson> yeah, I think that's all it needs
[11:19] <bzoltan> brendand: To run the full test suite locally on the device for the UITK is a very heavy process. Even in the best case it requires 8-10 runs, several reflashes, dozens of reboots and 4-6 hours with 3-7MB output. False failures and false OK results are expected at each run.
[11:19] <bzoltan> brendand:  so missing 3 tests is actually not that bad
[11:21] <bzoltan> brendand:  the real improvement would be to review and rewrite many app tests
[11:33] <brendand> bzoltan, we've done a lot of work on improving the stability of the test runs
[11:34] <brendand> bzoltan, so if you're still getting false failures then let us know about them, because we've certainly done our best to rid the CI dashboard of them
[11:36] <bzoltan> brendand: I can confirm that there is significant improvement. For real. It is way much better than it was before!
[12:00] <popey> sil2100: who is looking after webapps while dbarth is on vacation? bug 1339686
[12:01] <sil2100> popey: that is a valid question - dbarth didn't inform me of anyone filling in for him as a lander at least
[12:03] <sil2100> popey: but I guess alex-abreu and mardy should be around if anything
[12:03] <popey> ok.
[12:04] <cjwatson> silo 2 packaging changes look fine to me; publishing
[12:18] <brendand> bzoltan, good to hear, but it will really help us if when you are doing landings, you alert us of any issues with false failures
[12:20] <asac> sil2100: did we miss our change to get this nice t-shirt done?
[12:20] <asac> chance
[12:21] <asac> or are we trying that for our next promotion  run/iteration?
[12:21] <asac> :)
[12:21] <sil2100> asac: there's still chance, but it might take longer!
[12:25]  * asac will remember :)
[12:26] <brendand> sil2100, i think if we push hard and don't allow any more huge landings then we can do it by friday
[12:26] <brendand> sil2100, maybe with a bit of luck ;)
[12:27] <sil2100> brendand: yeah... there's currently nothing big planned for this week, so I guess that's doable
[12:28] <brendand> sil2100, we just need to try and get these few new app failures fixed asap
[12:28] <Mirv> brendand: did the SDK team now reproduce the sudoku/calendar ones locally?
[12:29] <brendand> Mirv, no - timp was just asking me if i did reproduce them locally
[12:29] <Mirv> right
[12:30] <ogra_> well, at least UITK passed in 122
[12:30] <Mirv> the timeout problems might be caused by UITK in some cases from what I've heard, but there's also still a change it's some combination of what went in to 120 that's giving the sudoku/calendar the trouble
[12:32] <bzoltan> brendand: during the last round I have experienced that for example the gallery app tests go crazy if they are run in a long sequence of tests. Also the UITK theme did not get installed with the plugin and that broke half of the app tests. It took some time to figure out.
[12:35] <bzoltan> brendand:  the other silly bug what confused us before figuring out the workaround is that the phablet-click-test-setup must be run before adding the Silo ... otherwise the click tests can not be set up
[12:37] <bzoltan> brendand:  plus the phablet-click-test-setup installs the stock UITK autopilot tests to the /home/phablet/autopilot and that overides the ubuntu-ui-toolkit-autopilot. So the ~/autopilot/ubuntuuitoolkit must be removed before the tests are run otherwise the new AP tests from the landing silo are not used and so many tests fail
[12:38] <bzoltan> brendand: also missing the `phablet-config autopilot --dbus-probe enable`  after AP test configuration (or maybe after reboot) caused failures
[12:38] <brendand> bzoltan, oh - that shouldn't happen
[12:38] <brendand> bzoltan, a lot of these things are issues you should have faced before though
[12:39] <bzoltan> brendand:  so these issues can easily waste 4-5 hours test rounds... nothing killing, mostly avoidable. But it is easy to miss out something and that delays the testing
[12:39] <brendand> bzoltan, is the process very manual?
[12:39] <bzoltan> brendand:  these issues I am facing continuously
[12:39] <bzoltan> brendand:  I have a script what I keep tuning ...
[12:41] <bzoltan> brendand:  http://paste.ubuntu.com/7770080/
[12:43] <bzoltan> brendand:  it is one line on one out, one changed, few commented out ... every round I add few more paranoid and most likely unnecessary line :) You might say to this script that it is silly... but after all it works :) ... or not
[12:45] <brendand> bzoltan, what happens if one test fails, do you have a way to rerun just that test suite?
[12:46] <bzoltan> brendand:  when a test fails usually I reboot and re-run, sometimes I even reflash and run it again on a clean device. I consider sure failure if it fails-fails-reboot-fails-fails-reflash-fails-fails ...
[12:47] <bzoltan> brendand:  I rerun single test cases if there are only few... but if 10-20 fails I look for pattern and re-run the whole set. Sometimes when I suspect the UITK I re-run the test without the silo.
[12:48] <bzoltan> brendand:  and I always save the test outputs, i have 15 log files from the previous landings
[12:49] <brendand> bzoltan, i can't help but think this would be much better to have in jenkins
[12:50] <brendand> bzoltan, with all the traceability and you can run the tests in parallel on different devices
[12:50] <brendand> bzoltan, is it the case that elopio also helps you somewhat with this process?
[12:51] <bzoltan> brendand:  Yes, i know.. i am lobbying for productizing the CI dash and assign one dash to each Silo with the defined test set according to the test plan
[12:51] <bzoltan> brendand:  Ohh, absolutely .. I would be dead without elopio. He supports me in all way!
[12:52] <brendand> bzoltan, btw how aften are you releasing now?
[12:53] <bzoltan> brendand:  :) it is a wrong time to ask that question. We had now 3 weeks without release. Normally it is weekly or at least every second week.
[12:54] <bzoltan> brendand: shorter the release cycle easier it gets
[12:54] <brendand> bzoltan, well of course
[12:55] <brendand> bzoltan, you should definitely have a consistent cycle, whatever its length
[12:55] <brendand> bzoltan, since the testing is mostly automated (even if it does take some time), one week should be realistic no?
[12:56] <bzoltan> brendand:  the aim is the weekly release ... but sometimes single MRs take days to land on our staging branch, and few messed up verification round can waste days too
[12:58] <brendand> bzoltan, well don't you have a cut off point? so if a MR doesn't make it by a certain day then it doesn't get in that release?
[13:00] <bzoltan> brendand: it depends on the MR ... if it is a critical fix or an RTM related improvement then I wait for the MR or merge it to the landing branch
[13:01] <bzoltan> brendand:  we have the trunk and we have a staging branch, I make the landing branch from  the staging and sometimes I merge into that MRs what I know safe and important. But that is more an exception than a real practice
[13:09] <cjwatson> sil2100: I need to step out for an errand - should only take me 30-40 minutes
[13:11] <sil2100> cjwatson: no worries, I'm around if anything, battling some debhelper right now
[13:13] <t1mp> Mirv, brendand, bzoltan I can reproduce the sudoku-app failure on my device https://pastebin.canonical.com/113193/
[13:14] <bzoltan> t1mp: congrats ... me too
[13:14] <brendand> t1mp, good start. here's how it looked in 119: http://people.canonical.com/~brendan-donegan/sudoku.png
[13:15] <t1mp> interesting
[13:15]  * t1mp checking whether positioning of dialogs changed
[13:18] <t1mp> brendand: what's the full name of the failing calendar_app tests?
[13:18] <t1mp> so I can run those without running the full set of calendar_app tests
[13:18] <brendand> t1mp, it's in the bug
[13:18] <Mirv> brendand: do you know if we have elopio around? he could be asked to check the notes-app swipe-left problem (bug #1330352) similar to the fixes he did on other apps
[13:19] <brendand> t1mp, autopilot list calendar_app and grep for the long name
[13:19] <Mirv> I added notes there but I didn't assign it yet
[13:20] <brendand> Mirv, i thought swipe left was deprecated so the tests that test that explicitly should be deleted?
[13:20] <ogra_> plars, the tests in 122 look suspiciously like a hanging mako ... didnt move since quite a while
[13:21] <Mirv> brendand: yes, probably that's just the thing that should be done to notes
[13:21] <t1mp> brendand: ok
[13:22] <brendand> t1mp, so for the sudoku one there seems to be a change in the layout of dialogs?
[13:22] <brendand> t1mp, the body of the dialog is appearing far down the screen
[13:23] <brendand> t1mp, http://people.canonical.com/~brendan-donegan/sudoku122.png as compared with the other screen
[13:25] <t1mp> brendand: I don't know why this is happening, I don't see any recent changes to Dialog
[13:26] <brendand> t1mp, but you're going to figure it out, right ;)
[13:27] <plars> ogra_: I'll take a look
[13:36] <t1mp> brendand: I hope so :) the text and focus handling is complex with lots of workarounds that I am not yet familiar with
[13:36] <t1mp> brendand: so I'm searching..
[13:38] <plars> ogra_: it was an unlock problem that caused other issues. I need to sort out how to isolate that better, preferably retry, and keep it from killing things in that way. It's running again now
[13:49] <t1mp_> why does phablet-test-run calendar_app work fine for me, but
[13:49] <t1mp_> tim@tim-desktop:~/dev/landing-tests$ phablet-test-run calendar_app.tests.test_custom_proxy_objects.NewEventFormTestCase.test_fill_formsh: 1: /usr/bin/python: not found
[13:49] <t1mp_> some times it wants to use python, some times python3?
[13:51] <t1mp_> linking python->python3 works for me, but still odd
[13:57] <ogra_> plars, thanks
[14:06] <rsalveti> Wellark: connectivity-api and indicator-network failed to build for powerpc
[14:09] <Wellark> rsalveti: please, trigger a rebuild. powerpc is flaky sometimes with connectivity-cpp :(
[14:10] <rsalveti> Wellark: ok, retrying
[14:52] <elopio> brendand, sil2100, bzoltan, Mirv_: I'll take care of the notes app. I'm sorry we missed it with our testing.
[14:52] <brendand> elopio, i pushed a branch. we just need to delete the test
[14:52] <brendand> elopio, we might also fix up the swipe_right test so that it doesn't use the deprecated argument
[14:52] <brendand> elopio, what do you think?
[14:53] <elopio> brendand: yes, that's the way. Can you also update the swipe_right test now that you are there?
[14:54] <brendand> elopio, will do
[14:55] <elopio> brendand: thanks. And so, what apps are left for me? Have you taken care of them all?
[14:56] <brendand> elopio, timp is looking at sudoku and calendar
[14:56] <elopio> brendand: ok, I'll look at the dialer.
[14:58] <brendand> elopio, dialer is false positives
[14:58] <elopio> I see a crash there.
[14:58] <brendand> elopio, i reran them this morning
[14:58] <elopio> also on the ui toolkit.
[15:00] <brendand> elopio, same. there was a unity8 crash, but it's not reproducible
[15:00] <brendand> elopio, we'll need to see if they crop up again
[15:01] <brendand> elopio, wait - actually i haven't looked at 122 yet
[15:02] <elopio> wooohooo, toolkit back to 100%
[15:03] <elopio> we need to add keyboard tests to these runs.
[15:07] <brendand> elopio, apparently the keyboard tests are completely bogus
[15:07] <brendand> elopio, the ones that are there are for an old version
[15:07] <brendand> elopio, so first we need to write some keyboard tests :)
[15:09] <ogra_> sil2100, 122 doesnt look as bad as expected ... http://ci.ubuntu.com/smokeng/utopic/touch/mako/122:20140709.1:20140709/8958/
[15:09] <brendand> ogra_, just a new filemanager failure, oddly
[15:09] <ogra_> yeah
[15:09] <elopio> brendand: oh, well, we can do it when the dash is back to green.
[15:10] <sil2100> ogra_: yeah, but still... we seem to be having flaky tests in overall since we had so many random ones in the previous 2 images
[15:16] <ogra_> sil2100, yep, but at least its only 6 of them now
[15:17] <davmor2> popey: can you try something, Open the web browser, then swipe back to the apps lens, expand the My apps section, then scroll to the Ubuntu store, click on that, have a quick browse then hit the back button, where do you wind up on that apps lens?  For me it is like row 3-4 of the list of apps.
[15:21] <cyphermox_> Wellark: connectivity-api fails to build on powerpc... it's not critical, but if you could look at it, it seems like it should be pretty simple to fix these two wifi tests: https://launchpadlibrarian.net/179619203/buildlog_ubuntu-utopic-powerpc.connectivity-api_0.0.1%2B14.10.20140709.2-0ubuntu1_FAILEDTOBUILD.txt.gz
[15:26] <Eisbrecher_xnox> !ci-help plars: latest trusty daily image is 20140709, yet desktop testing has not run against trusty since april. http://ci.ubuntu.com/smokeng/trusty/desktop/
[15:27] <plars> Eisbrecher_xnox: that's odd... let me look, I just looked and saw it had run today
[15:27] <plars> oh, hah
[15:27] <plars> Eisbrecher_xnox: have there been new trusty daily images since then?
[15:28] <Eisbrecher_xnox> plars: since 0417, yes.
[15:28] <plars> Eisbrecher_xnox: last I checked there were not yet, so we didn't have a location to check yet
[15:28] <Eisbrecher_xnox> plars: there are daily trusty images build for a weeks now, with proposed enabled.
[15:28] <plars> Eisbrecher_xnox: so it's looking at the pending location for utopic, but downloading from the last place it knew to get trusty
[15:29] <plars> Eisbrecher_xnox: I'll need to update some locations
[15:29] <Eisbrecher_xnox> plars: yes. devel are /daily-live/$distro...., but stable images are /$distro/daily-live/$distro.....
[15:30] <plars> Eisbrecher_xnox: right, I see them
[15:33] <cjwatson> mhr3: want me to publish silo 4?
[15:33] <mhr3> cjwatson, yes pls
[15:34] <cjwatson> "2014-07-09 15:33:51,571 INFO Don't upload the silo automatically.
[15:34] <cjwatson> "
[15:34]  * cjwatson wonders what that means
[15:34] <cjwatson> Ah right
[15:41] <cjwatson> mhr3: Why isn't this a soname change in libunity-scopes?
[15:41] <cjwatson> mhr3: There are symbols here with changed ABIs
[15:43] <mhr3> cjwatson, no, they're just added
[15:44] <cjwatson> That's not what the symbols file diff says
[15:44] <cjwatson> - (c++)"unity::scopes::Category::Category(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unity::scopes::CategoryRenderer const&)@Base" 0.4.0+14.04.20140312.1
[15:44] <cjwatson> + (c++)"unity::scopes::Category::Category(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::shared_ptr<unity::scopes::CannedQuery const> const&, unity::scopes::CategoryRenderer const&)@Base" 0.5.2+14.10.20140709.2
[15:44] <cjwatson> - (c++)"unity::scopes::internal::ScopeConfig::parse_appearance_attribute(std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, unity::scopes::Variant, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, unity::scopes::Variant> > >&, std::basic_string<char, ...
[15:44] <cjwatson> ... std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)@Base" 0.5.1+14.10.20140626
[15:44] <cjwatson> + (c++)"unity::scopes::internal::ScopeConfig::parse_appearance_attribute(std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, unity::scopes::Variant, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const, unity::scopes::Variant> > >&, std::basic_string<char, ...
[15:44] <cjwatson> ... std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)@Base" 0.5.2+14.10.20140709.2
[15:44] <cjwatson> and others
[15:53] <mhr3> cjwatson, because generation of the symbol file is weird and it duplicates stuff
[15:53] <Eisbrecher_xnox> plars: i did this http://paste.ubuntu.com/7770858/ is my utah old?
[15:53] <cjwatson> mhr3: Then shouldn't I be seeing equivalent removals somewhere else?
[15:53] <mhr3> cjwatson, the "removed" one is two lines up
[15:54] <cjwatson> mhr3: oh, hmm
[15:54] <cjwatson> mhr3: I'll look harder when I'm off this call
[15:54] <plars> Eisbrecher_xnox: don't think I've seen that before, what version are you on?
[15:55] <popey> davmor2: yes, and I see icons overlaying eachother
[15:55] <plars> Eisbrecher_xnox: you can also pass it an already-downloaded image, which is typically what we do
[15:55] <plars> Eisbrecher_xnox: with -i, and a preseed with -p
[15:55] <davmor2> popey: nice one ta
[15:55] <mhr3> cjwatson, and btw removals/changes in unity::internal don't matter
[15:56] <Eisbrecher_xnox> plars: hm. ok.
[15:57] <plars> Eisbrecher_xnox: something like: run_utah_tests.py -d -m physical+  --name power-test-1 -i /utopic-desktop-amd64.iso tests/master.run -p preseed.cfg
[15:58] <Eisbrecher_xnox> plars: i definately do not have anything physical to provision.
[15:58] <Eisbrecher_xnox> plars: let me try -i and -p
[15:58]  * ogra_ wonders about the prefic Eisbrecher_xnox carries ... 
[15:59] <plars> Eisbrecher_xnox: VM installs are not going to work either, but for entirely different reasons
[15:59] <ogra_> *prefix
[15:59] <popey> i wondered that too
[15:59] <ogra_> is that Eisbrecher like Rammstein ?
[16:00] <Eisbrecher_xnox> plars: i boot vm, i install, it reboots.
[16:00] <Eisbrecher_xnox> plars: now i'm trying to make sure utah in a vm also works.
[16:00] <robru> ogra_, yeah I suppose you can break ice with a ramming stone...
[16:00] <ogra_> robru, lol
[16:00] <plars> Eisbrecher_xnox: apparently utah now has to do some kind of trick in utopic to determine that it rebooted the VM
[16:00] <cjwatson> mhr3: shouldn't they have their symbol visibility set to hidden?
[16:00] <plars> Eisbrecher_xnox: that's an entirely different bug though
[16:01] <mhr3> cjwatson, it's complicated... but no
[16:01] <Eisbrecher_xnox> plars: let me try trusty, i haven't used my utah setup in a while, but it used to run things.
[16:01] <mhr3> cjwatson, what's important is that proper users of the lib never see them
[16:03] <bfiller> robru: I need a silo for line 28 please
[16:07] <cjwatson> mhr3: ok, looked again and acked
[16:07] <mhr3> cjwatson, cheers
[16:17] <oSoMoN> hi, can I haz a silo for line 29 ?
[16:18] <cjwatson> oSoMoN: yep, looking
[16:18] <Eisbrecher_xnox> cjohnston: hey. My UTAH doesn't run a basic VM provision and a basic test/runlist.
[16:18] <Eisbrecher_xnox> times out at the very beginning with a typeerror
[16:19] <Eisbrecher_xnox> cjohnston: can you help? or e.g. do you have any place where you know utah setup is correct and would you be able to run some runlists for me with a few changes?
[16:20] <cjohnston> Eisbrecher_xnox: probably best to talk to doanac
[16:21] <doanac> Eisbrecher_xnox: I think psivaa-off could probably run some without too much effort for you.
[16:22] <ogra_> if he wasnt off :)
[16:24] <Eisbrecher_xnox> cjohnston: hm ok.
[16:24] <Eisbrecher_xnox> doanac: well, for me utah from stable ppa trusty does not work at all against a VM.
[16:24] <Eisbrecher_xnox> doanac: is it known to be working? which utah version is in production?
[16:25] <cjwatson> oSoMoN: did you notice you have silo 12?  you can build now
[16:26] <robru> bfiller, http://people.canonical.com/~rbpark/citrain/#?q=bfiller ;-)
[16:31] <rsalveti> Wellark: still nothing even after a few rebuilds
[16:35] <oSoMoN> cjwatson, thanks
[16:38] <doanac> Eisbrecher_xnox: psivaa-off is using our stable ppa for our testing right now.
[16:38] <doanac> it probably requires a config tweak for the installer
[16:39] <cjwatson> robru: silo 19 is going to fail to build as far as citrain is concerned because arm64/powerpc/ppc64el won't work, but that's intentional - it was a mistake that those were built in the version in -proposed, and I've been working with the webapps team to get things back in order relative to utopic
[16:40] <robru> cjwatson, do you want me to publish it after it fails to build?
[16:40] <cjwatson> robru: once it's built on amd64/arm64/i386 and they've tested it (maybe alex-abreu can fast-track that?), it should be OK to forcibly publish it
[16:40] <robru> ok
[16:40] <cjwatson> robru: then I'll need to remove the stale binaries from -proposed, which I can do a bit later
[16:41] <cjwatson> robru: (might also need to abort the build job once amd64/armhf/i386 have finished, to avoid it taking forever?  not sure)
[16:42] <robru> cjwatson, ok, i'll keep an eye on it
[16:42] <cjwatson> thanks
[17:05] <cjwatson> robru: looks like it does indeed need to be aborted, probably
[17:06] <robru> cjwatson, hm, yeah, seems so
[17:08] <robru> cjwatson, I asked alex abreu to test it, then I'll publish it later
[17:08] <cjwatson> thanks
[17:26] <Eisbrecher_xnox> doanac: e.g. i've purged and re-installed utah from 2013 december, yet i fail to run e.g. basic default tests against precise images.
[17:26] <Eisbrecher_xnox> doanac: and that's on utopic host, provisioning VMs.
[17:27] <Eisbrecher_xnox> doanac: i'll try trusty host again with current packaging.
[17:27] <Eisbrecher_xnox> doanac: are the configs commited somewhere? and/or default configs in the packaging adjusted appropriately?
[17:27] <doanac> Eisbrecher_xnox: let me find our jenkins job in production where this happens
[17:30] <doanac> Eisbrecher_xnox: is this your issue: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1329254
[17:30] <doanac> it looks like we've been broke for a while: http://ci.ubuntu.com/smokeng/utopic/desktop/
[17:31] <Eisbrecher_xnox> doanac: no, that is not my issue. no VMs ever start nor attempt provisioning.
[17:32] <Eisbrecher_xnox> doanac: but noting that bug. I should be able to e.g. use precise host to run utah.
[17:32] <Eisbrecher_xnox> doanac: or i'd be happy to port desktop tests away from utah. And onto MAAS/Openstack.
[17:33] <doanac> Eisbrecher_xnox: that's the long term goal.
[17:33] <Eisbrecher_xnox> doanac: can MAAS & canonistack boot custom images from object store with externally provided boot options, etc.
[17:33] <Eisbrecher_xnox> ?
[17:33] <doanac> Eisbrecher_xnox: i think the custom images thing is the tough part. I think MAAS might be able to do it now, they used to have troubles with that
[17:33] <doanac> MAAS is more about booting a few images a lot of times, not boot lots images one time
[17:35] <doanac> Eisbrecher_xnox: here's our jenkins job/configuration for how we run this: http://d-jenkins.ubuntu-ci:8080/job/utopic-desktop-i386-smoke-default/
[17:39] <plars> Eisbrecher_xnox: http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/Smoke%20Testing/job/trusty-desktop-amd64-smoke-default/163/console
[17:39] <plars> Eisbrecher_xnox: looks like I can produce this problem on VM with latest trusty now that we have them
[17:41] <plars> doanac: I've not seen a way to do custom images in maas, did you find something about that? that would be really useful if we could
[17:41] <doanac> plars: i haven't looked in forever, but i thought it was on their roadmap
[17:43] <bzoltan> robru:  I have put a simple packaging fix for the UITK in the line31. It will unblock several app landings as Jenkins have an old -theme package.
[17:43] <robru> did somebody say 'unblock'?
[17:43]  * robru ears perk up
[17:44] <Eisbrecher_xnox> plars: what about release trusty (14.04.0) ?
[17:45] <plars> Eisbrecher_xnox: we tested all the way through the end of trusty with this, and it only broke again when we started pulling images from the new location for daily builds, so that one should be fine
[17:45] <sil2100> 'unblock' is the magic keyword here
[17:45] <robru> bzoltan, http://people.canonical.com/~rbpark/citrain/#?q=bzoltan ;-)
[17:45] <bzoltan> robru: :D nice, thanks
[17:46] <robru> bzoltan, you're welcome!
[18:14] <slangasek> wgrant: do we get dbgsym packages for packages built in the CITrain silo ppas?
[18:15] <slangasek> infinity: ^^ maybe you know the answer to this offhand
[18:19] <infinity> slangasek: We do if they're configured correctly.
[18:20] <slangasek> so... who can check the configuration?
[18:20] <infinity> slangasek: I can if I'm on the right teams.  Point me at a PPA.
[18:21] <slangasek> infinity: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-0<n><n>
[18:21] <slangasek> e.g., https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-001
[18:21] <infinity> Ahh, yeah, I'm not in a team that can upload to those.
[18:21] <infinity> asac: Want to add me to https://launchpad.net/~ci-train-ppa-service/+members ?
[18:21] <slangasek> infinity: can you tell robru what to look for?
[18:22]  * infinity asks, before realizing this is signing up for a bunch of FTBFS spam.
[18:22] <infinity> robru: Unintuitively, what you want in the config is for "build debug symbols" and "publish debug symbols" to both be unchecked.
[18:22] <robru> excellent
[18:22] <infinity> I assume this is the case already, or we'd surely have had a lot of complaints.
[18:23] <robru> infinity, where would I find that under? I don't see a 'config' option on the silos.
[18:23] <infinity> slangasek: To be fair, this is a whole lot of shoestring and bubblegum and prone to failure until we have librarian space to do it the right way.
[18:24] <slangasek> infinity: who would have complained?  We're still trying to find our way to reliable ARM crash reporting
[18:24] <infinity> robru: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+admin
[18:24] <robru> infinity, i'm not allowed in there apparently
[18:24] <infinity> robru: Quite possibly a page you don't have access to see, but I would if I were in that team.
[18:24] <slangasek> and it's entirely possible it's set for some but not all of the silos
[18:25] <infinity> slangasek: Well, this affects all arches, it's not just arm.  I'd think someone would have complained if silo uploads lacked ddebs.
[18:25] <infinity> slangasek: But yes, some of them might be misconfigured.
[18:25] <robru> infinity, I'm in that team and don't have permissions to that page. i guess asac is the only person who can answer this question
[18:25] <slangasek> infinity: yes; and AIUI we're not going to have space in the librarian in time to make a difference for RTM, and we rather need to be able to be able to debug crashes on the phone before then
[18:25] <infinity> Anyhow, we need either me in that team, or a WeBop to check for us.
[18:25] <infinity> robru: No, I mean if *I* were in that team, *I* could see it, not that everyone in the team can.
[18:25] <slangasek> infinity, robru: I have a list of affected packages, is there a way to backtrack from the current binary package in the archive to the silo it was built in?
[18:25] <robru> ok, magic, got it
[18:25] <infinity> robru: It's an intersection of "being in the team" and some other magic permissions I have.
[18:26] <infinity> slangasek: Yeah, we can see where it built.
[18:26] <slangasek> infinity: where do I see that
[18:26] <robru> slangasek, yeah, that shows up somewhere
[18:26] <infinity> slangasek: The build log, if nothing else.
[18:26] <infinity> slangasek: Also, publishing history of the source shows the copy source.
[18:26] <slangasek> ok
[18:27] <robru> slangasek, if you go to the source package page: https://launchpad.net/ubuntu/+source/connectivity-api and click the triangle to expand the latest release, it'll say 'copied from ubuntu utopic in Landing PPA xxx by Ubuntu Archive Auto-Sync..."
[18:27] <robru> slangasek, or this page also: https://launchpad.net/ubuntu/+archive/primary/+sourcepub/4175790/+listing-archive-extra
[18:28] <slangasek> ok, so the only one I can confirm was in a silo so far is https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-005/+build/6072141
[18:29] <robru> slangasek, oh, you're talking about qt5.3?? that was an enormous landing from silo 5, from a few weeks ago... like dozens of packages in there together
[18:30] <slangasek> robru: I'm talking about any of the packages that bdmurray tells me missing dbgsyms are causing problems for
[18:30] <slangasek> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-006/+build/6146609
[18:30] <slangasek> that one seems to also be missing dbgsyms
[18:31] <robru> slangasek, ok but like... if that first one you linked was missing debugsyms, it would follow then that all the packages built in that silo at that time should also be missing them, right? is bdmurray telling you about dozens and dozens of qt5.3 packages?
[18:31] <infinity> slangasek: That qtwebkit upload didn't produce ddebs at all.
[18:32] <slangasek> hmm, scratch that, the above mir build does have its dbgsyms
[18:32] <slangasek> infinity: oh? buggy source then?
[18:32] <infinity> slangasek: Oh, no.  I mean the build didn't produce them as an artifact.  You would see "Publishing debug debs" in the sbuild log if it had been instructed to publish.
[18:32] <infinity> slangasek: So, quite likely a misconfigured PPA.
[18:32] <slangasek> ok
[18:33] <infinity> Actually, no.  I see no mention of .ddebs being built in the build either.
[18:33] <infinity> ... which might be the same misconfiguration.
[18:33] <infinity> So, yeah.
[18:33] <slangasek> asac: ^^ please add infinity to ~ci-train-ppa-service so he has access to administer the ppa configs as needed
[18:33] <infinity> We should check the PPA configs.
[18:34] <infinity> robru: Are those PPAs automagically created by some scripting mojo?
[18:34] <slangasek> asac: (and please consider adding another admin to the team)
[18:34] <infinity> robru: I can fix the current ones (given access), but if more will be (re)created, we need to stamp it out at the root.
[18:34] <robru> infinity, I think they might have once been, but they're stable now, eg, so changes you make are permanent and won't be wiped out
[18:35] <robru> infinity, I don't think we're in any danger of adding more silos... some months ago we had a huge crunch for silos and didn't add any then, we're chugging along smoothly now, no need to add any now...
[18:35] <robru> infinity, i don't even know where that code would be ;-)
[18:35] <infinity> slangasek: Hrm.  Looking at how sbuild was called, I think the PPA is configured correctly, though.
[18:36] <infinity> slangasek: So, it could be a source bug, or a pkg-create-dbgsyms bug.
[18:38] <robru> infinity, yeah, I've got the code that creates the jenkins jobs from templates, but I don't see anything about actually creating the silos. I think they're created by hand.
[18:38] <slangasek> so, thumbnailer is special.
[18:39] <slangasek> we have dbgsyms for libthumbnailer0 (in main), but not for thumbnailer-service and qtdeclarative5-ubuntu-thumbnailer0.1 (in universe).
[18:39] <infinity> slangasek: Another random build from 005 shows it building and publishing ddebs: https://launchpadlibrarian.net/179474606/buildlog_ubuntu-utopic-arm64.address-book-app_0.2%2B14.10.20140707-0ubuntu1_UPLOADING.txt.gz
[18:39] <slangasek> ok
[18:39] <slangasek> so probably not a silo config issue
[18:39] <infinity> slangasek: So, qtwebkit or pkg-create-dbgsyms are being jerks.
[18:39] <slangasek> however, the above points to ddebs.u.c not coping well with cross-component packages
[18:40]  * slangasek nods and takes a closer look
[18:40] <infinity> slangasek: IME, ddebs.u.c just publishes the lot to main (ie: nscd.ddeb is in main, despite nscd.deb being in universe)
[18:41] <slangasek> infinity: fine in theory, but in this case there are no ddebs for those binary packages in either main or universe
[18:41] <slangasek> so /something/ went wrong
[18:41] <infinity> slangasek: Hrm, though the thumbnailer thing is broken, I see.
[18:41] <infinity> slangasek: That would be a pitti question.
[18:42]  * slangasek nods
[18:42] <cyphermox_> mandel: kgunn: greyback: mzanetti: I'd like to land silo 14; that means I'll need to rebuild my silo now, this will impact yours and require a rebuild before landing
[18:43] <slangasek> build log shows the ddebs were built. https://launchpadlibrarian.net/174196976/buildlog_ubuntu-utopic-armhf.thumbnailer_1.1%2B14.04.20140401.1-0ubuntu2_UPLOADING.txt.gz
[18:43] <cyphermox_> mandel: kgunn: greyback: mzanetti: I'd just like to make sure we're all on the same page, let me know if you're already ready to land so we can coordinate
[18:43] <infinity> slangasek: Right, I checked the same thing.  So, assuming they all got in the tarball (which they should have), the failure is on the ddeb-retriever/publisher side.
[18:44] <infinity> Unfortunately, we don't keep history that far back, so those ones are completely unrecoverable.
[18:52] <asac> slangasek: done x2/3
[18:52] <asac> welcome
[18:52] <asac> admin u r
[19:03] <asac> infinity: ppas were initially created by me manually and devirtualized and other tweaks through RT
[19:03] <asac> the other tweaks i dont know details... we asked IS to duplicate the features of the unity-daily ppa we had back then for the old syste
[19:03] <asac> m
[19:04] <asac> slangasek: ^ ... have fun
[19:04]  * asac out for couple hours
[19:05] <infinity> asac: They first few I've looked at look correct.  Looks like all of slangasek's complaints are outside the CI system, for once.
[19:06] <asac> cool.
[19:06] <slangasek> infinity: ok, thanks for checking
[19:10] <infinity> slangasek: Alright, checked 000 through 020, and all look fine.
[19:10] <slangasek> ok
[19:15] <bzoltan> rsalveti: robru: the UITK with a fixed packaging is ready and tested in the silo16
[19:17] <robru> bzoltan, coolio!
[19:19] <bzoltan> rsalveti: would you please ^
[19:20] <bzoltan> or anybody with jedi power :)
[19:21] <robru> done
[19:22] <bzoltan> robru:  awesome :) we just made Renato happy. After yesterdays soccer game he deserves it :)
[19:22] <robru> hehehe
[19:23] <slangasek> infinity: hmm, how about bzip2? nothing about ddebs in the build log, nothing on ddebs.u.c
[19:23] <slangasek> robru: um?  all packaging changes are supposed to be signed off by an Ubuntu dev, which AIUI you aren't yet?
[19:24] <robru> slangasek, it was a trivial version bump though, no new deps or even build system changes
[19:24] <slangasek> robru: it's not a bump, it's a hard-coding of a versioned dependency; this is probably ok, but an Ubuntu dev should be making that determination
[19:25] <robru> slangasek, hm, ok, sorry
[19:25] <slangasek> robru: please don't take advantage of the landing team's backdoor into the Ubuntu archive ;)
[19:25] <slangasek> also please /do/ feel free to impose upon the members of the Foundations team to review these
[19:26] <slangasek> infinity: because bzip2 doesn't use debhelper. SCORE
[19:27] <Saviq> robru, huh, any idea what changed with ci-train ordering branches to merge?
[19:27] <Saviq> robru, see https://ci-train.ubuntu.com/job/landing-018-1-build/110/console (ignore the conflict)
[19:27] <bzoltan> slangasek:  it is my fault, I was pushy with this fix to land
[19:27] <robru> Saviq, no idea, sorry... sil2100 is the only person to toys with that code really
[19:28] <Saviq> robru, mhm, worried I have no control over ordering any more :|
[19:28] <sil2100> Saviq: hi! So!
[19:28] <Saviq> sil2100, oh, you're around
[19:28] <Saviq> sil2100, check out line 20
[19:28] <Saviq> sil2100, and then the output from build job https://ci-train.ubuntu.com/job/landing-018-1-build/110/console
[19:28] <Saviq> sil2100, ignore the conflict
[19:28] <sil2100> Saviq: sometime in the past I added a modification as per sergio's request to re-order merges whenever there are pre-requisites present, but only in this case
[19:29] <Saviq> sil2100, ah
[19:29] <Saviq> sil2100, fine in that case
[19:29] <sil2100> Saviq: are there any prereqs?
[19:29] <Saviq> sil2100, there are, yes
[19:29] <sil2100> Saviq: I might add a flag to disable that ;p
[19:29] <Saviq> sil2100, ok, we should be fine then, just need to make sure to keep prereqs up to date
[19:29] <sil2100> Saviq: sorry for the confusion anyways, since this is to make sure people didn't push out changelogs that didn't make sense
[19:30] <sil2100> Saviq: as sometimes because of this, changelogs were b0rken and if there was no packaging changes then those were pushed to the archive looking terrible
[19:30] <robru> Saviq, indeed https://code.launchpad.net/~mzanetti/unity8/launcher-new-background/+merge/225317 has a pre-requisite
[19:30] <sil2100> As no one noticed that to inform people that the 'order was wrong'
[19:31] <Saviq> sil2100, robru, yeah, understood, was always caring about ordering prereqs myself, better for us that train does it itself :)
[19:31] <sil2100> Saviq: but it's trying to do it in a smart way, and not change the order of those that are not prerequisite-enabled ;)
[19:31] <sil2100> Saviq: indeed! :)
[19:31] <sil2100> Saviq: that's good practice in overall - but as I said, I'll add a flag to disable that just in case
[19:37] <Saviq> sil2100, thanks
[19:38] <Saviq> robru, btw, I'm sometimes having issues with the MP bubbles going away too quickly (can't reach the MP links in time) in the train dashboard
[19:38] <robru> Saviq, which?
[19:38] <robru> oh, the MP links
[19:38] <Saviq> robru, as I hover over components in the silo
[19:39] <robru> Saviq, yeah, the trick there is you're probably moving the mouse over the next lower entry on your way to the bubble. works better if you start with your mouse not at the left side of the package names
[19:40] <Saviq> robru, yeah, moving down (for the last component) results in the same
[19:40] <Saviq> robru, oh, on that note
[19:40] <Saviq> robru, check out silo 18 for unity8
[19:40] <Saviq> robru, no MPs there
[19:40] <robru> Saviq, yeah, so the bubble only stays visible when your mouse is directly over the <a> tag, so if it goes off even for a second, the bubble disappears.
[19:41] <robru> Saviq, heh, you mean the way that bubble extends beyond the bottom of the screen?
[19:41] <Saviq> robru, no, I just get a circle here ;)
[19:41] <robru> Saviq, screenshot?
[19:42] <Saviq> robru, http://imgur.com/J8oX4sc
[19:43] <robru> Saviq, weird! try reloading the page? works for me...
[19:43] <Saviq> robru, heh, same in chromium, must've cached somewhere
[19:44] <robru> Saviq, that's weird because I specifically use a trick to prevent caching of those status files...
[19:44] <Saviq> robru, I know, I told you to timestamp the requests ;)
[19:44] <Saviq> robru, the json looks fine
[19:45] <Saviq> robru, sounds like a related error http://pastebin.ubuntu.com/7771733/ ?
[19:46] <Saviq> nah, get that multiple times
[19:46] <Saviq> aaanyway
[19:52] <elopio> fginther: could you change runners configs to put the empty keyring files?
[19:52] <elopio> not putting extra pressure, just trying to figure out what to do next
[20:00] <kgunn> cyphermox_: just tell me when you land...when those packages are in we'll need to rebuild
[20:00] <kgunn> cyphermox_: ours is a test silo that i stated ahead of time, we would not land before monday to give it a little time
[20:01] <robru> kgunn, I'm about to publish right now, is that ok?
[20:01] <kgunn> robru: absolultely
[20:02] <cyphermox_> kgunn: so it's connectivity-api, dbus-cpp, indicator-network and ubuntu-system-settings
[20:27] <fginther> elopio, sorry about that, I meant to give that a try once the bug was updated. let me through something together and test this out
[20:28] <elopio> fginther: thanks.
[21:06] <oSoMoN> robru, hey, can silo 12 be published?
[21:09] <robru> oSoMoN, I dunno, looks like we need a core dev ack here... pretty complicated diff you got there...
[21:10] <robru> kenvandine, mterry anybody around for a quick core dev ack? ^^
[21:10] <oSoMoN> robru, is it? the changes to debian/control are very minimal, just bumping a runtime dep iirc
[21:10] <kenvandine> robru, sure
[21:10] <robru> oSoMoN, yeah I was being sarcastic, sorry
[21:10] <mterry> robru, ack
[21:10] <robru> hehe
[21:10] <kenvandine> haha
[21:11] <oSoMoN> robru, haha, sorry it’s late for sarcasm here :)
[21:11] <mterry> :)
[21:11] <robru> oSoMoN, ok it's publishing now ;-)
[21:11] <robru> mterry, kenvandine thanks
[21:11] <oSoMoN> robru, mterry, kenvandine: thanks
[21:25] <fginther> elopio, do you have an MP to exercise those keyring changes?
[21:26] <robru> mterry, another ack please? this one's a bit bigger ;-) https://ci-train.ubuntu.com/job/landing-018-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity8_7.90+14.10.20140709.2-0ubuntu1.diff
[21:27] <mterry> robru, sure looks ok
[21:28] <robru> mterry, thanks
[21:37] <robru> heh, kgunn started a build job and then signed off before seeing the error message. I guess I could fix that for him...
[21:38] <robru> oh, he got it
[21:38] <robru> ok, i'm off for late lunch, bbl
[22:52] <elopio> fginther: one second, I'll make the branch.
[22:52] <elopio> it's one line.
[23:05] <Saviq> robru, you're too fast!
[23:05] <Saviq> thanks!
[23:07] <robru> Saviq, hehe, I just happened to notice it even before the bot pinged. you're welcome!
[23:13] <elopio> fginther: https://code.launchpad.net/~elopio/unity-scope-click/enable_credentials/+merge/226226