=== Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === fginther is now known as fginther|away === fginther|away is now known as fginther === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [03:26] popey: are you able to reproduce bug 1334940? [03:26] bug 1334940 in mediascanner2 (Ubuntu) "Can't scan videos on ubuntu touch (flo, image 100)" [Undecided,New] https://launchpad.net/bugs/1334940 === wgrant_ is now known as wgrant [07:16] sil2100, can we kick M&C on silo 5 do you think? [07:23] good morning [07:24] sil2100, can I get a silo for line 28? [07:31] o/ [07:35] tvoss: let's see if there will be no conflicts [07:35] sil2100, there most likely will be, but it's really only build system setups [07:35] sil2100, also note that the list of mps is not complete, yet [07:56] tvoss: anyway, silo 008 is for you [07:56] sil2100, thank you [07:57] sil2100, I will add a bunch of MPs now, and ping you once done to ask for a reconfigure [08:02] tvoss: ok :) === sil2100 changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train Status: #87 promoted | CI Train Sheriff: sil2100 | Known issues: The spreadsheet is extremely slow, http://people.canonical.com/~rbpark/citrain/ knows the statuses before the spreadsheet does. Long mako wait times on s-jenkins. [08:31] davmor2: hey, meeting? [08:51] sil2100, thanks for handling that settings landing! seems like you can m&c it now as well [08:52] any ideas why jenkins is so slow these days? It takes >10h for a happroved MR to land in a branch [09:04] psivaa, ping? [09:04] psivaa, would you happen to know anything about foo:native not working on jenkins? [09:05] t1mp, there was a mail [09:06] mhr3: do you have a link for the job [09:06] psivaa, here's one https://jenkins.qa.ubuntu.com/job/unity-team-unity-scope-click-devel-utopic-amd64-ci/129/console [09:07] psivaa, another https://jenkins.qa.ubuntu.com/job/mediascanner2-utopic-amd64-ci/38/console [09:07] psivaa, and there will be few more [09:10] ogra_: ah yes, I see now. [09:10] thanks.. I hope a solution can be found [09:11] sil2100, hey, would you mind publishing silo 13? [09:25] sil2100, could you reconfigure silo 27 please? [09:27] o/ [09:27] One moment please and I'm handling your requests [09:28] Your call is important to us [09:30] sil2100, can I push build and see the world explode? [09:30] sil2100, pushed the button :) [09:36] mhr3: sorry, could not find much info as to why it's failing except: [09:36] sh: 1: x86_64-linux-gnu-gcc-4.9: not found [09:36] dpkg-architecture: warning: couldn't determine gcc system type, falling back to default (native compilation) [09:37] psivaa, hmm, wouldn't you anyway get that error *after* the dep checks? [09:38] psivaa, plus it's not really an error... just a warning :) [09:39] sil2100: ogra_ i can't land camera it in the store right now because the frameworks has been updated.. [09:40] mhr3: ok, but i dont see that in passing jobs. [09:40] to something non existing ?? [09:40] -dev2 was pushed to click and the camera app uses it, but the docs, the store and the reviewers tools aren't updated [09:40] exists on the device, yeah [09:40] but nowhere else [09:40] looks like a conversation in #phablet last night [09:40] wish people would use the public channels [09:41] mhr3: the installed version of gcc in the host is: 4.8.2-19ubuntu1, if that points to anything. [09:42] psivaa, well what changed is the addition of gcc-4.9:native to the control file, and apparently pbuilder doesn't like that, i've heard that you were stripping the native suffix because of that, but i guess that stripping isn't global? [09:42] sigh [09:42] mhr3: i have no idea about that :), sorry. i'll ask fginther when he's around. [09:42] * sil2100 sighs [09:43] too many sighs :) [09:43] psivaa, ok, thanks for looking into it anyway [09:43] * mhr3 sighs too [09:43] tvoss: the reconfigure has failed it seems, let me reconfigure again [09:43] sil2100, hmmm, the silo is building [09:43] mhr3: np. [09:44] tvoss: ok, it might not have built all the components then [09:44] tvoss: let me re-run it in a moment [09:44] sil2100, yup, the build failed [09:45] popey, ah, to prevent it from being offered to images with older frameworks [09:45] yes [09:45] k [09:45] do we have any ETA for the update of the tools ? [09:45] (and docs) [09:47] tvoss: ok, the build failed also from a different reason, let me try and get to the source of it [09:47] ogra_: jdstrand owns the docs and tools, asked james for ETA on store [09:47] thanks [09:49] hmmm [09:49] tvoss: so, it seems that the unity-scope-click merge proposal branch targets lp:unity-scope-click/devel which is not up to sync with the archive [09:51] tvoss: not sure if lp:unity-scope-click/devel should be used? What is the main branch for this project? I see lp:unity-scope-click being in sync with the archive [09:55] I think you'll have to ask the author to retarget the merge [09:56] ogra_, popey: you think we should wait with 102 for that to happen? [09:56] sil2100, no, lets build one [09:57] Ok then, let's kick a new image [09:57] ☹ [09:58] ogra_: before you do.. [09:58] yeah ? [09:58] any chance you can add my libkeychain to the image? [09:59] that will cost another publisher run, but yeah, i can [09:59] https://code.launchpad.net/~popey/ubuntu-seeds/add-keychain/+merge/224667 [09:59] thanks [10:00] thostr_, ^ please see sil's comment === tvoss is now known as tvoss|food [10:10] mhr3: As I noted in whatever unity-scope-click MP it was, I really think the advice to use g++-4.9:native is wrong - even though there does seem to be something suspicious here going on in jenkins. [10:14] cjwatson, well pbuilder not supporting :native is what's wrong [10:15] cjwatson, i'll let you fight with xnox about the need for :native, imo explicitely picking gcc version on individual packages like this is already what's wrong :P [10:17] cjwatson: well the intention is to protect from c++11 abi breaks. [10:17] cjwatson: yet, without breaking cross compilation.... [10:18] cjwatson: not add that dependency at all? [10:18] * xnox ponders where pbuilderjenkins is maintained. [10:33] psivaa, mhr3, the ':native' stripping is not global. I'm applying it to unity-scopes-api now [10:34] fginther, well, it would need to be applied to about ~15 projects [10:34] at least [10:36] fginther: ack, thanks. i'll take a look at it later for future ref :) [10:37] mhr3: No, there are excellent reasons to control the timing of C++11 ABI changes [10:39] xnox: The thing we need to do to make explicit compiler build-dependencies work for cross-building isn't to use :native, but to have sbuild know when to turn g++-4.9 into g++-4.9-$triplet [10:39] mhr3: Thomas is working on that set of packages, after discussion with me and Steve [10:41] xnox: g++-4.9:native doesn't help the cross case - sure, it'll give you a compiler that executes on the build architecture rather than on the host architecture, but it'll also target the build architecture so it's no good [10:41] xnox: I've been over this extensively with Wookey :-) [10:41] cjwatson, i know, i just don't like that they're even needed... anyway that doesn't mean that half of unity stack should stop being cross buildable [10:42] xnox: I agree that this set of changes regresses cross-compilation, but realistically that's less important than controlling ABI changes in this case [10:42] (Well, may regress; I don't know what the current state of cross-building for this particular set of packages is) [10:42] mhr3: Like I say, we can and should fix this centrally [10:42] cjwatson, and meanwhile any development can suffer? [10:42] mhr3: This is just making a well-known problem cover a few more packages [10:43] mhr3: Um, development suffers either way, this change isn't being made for no reason! [10:43] mhr3: We had to revert a toolchain defaults change until this was sorted out [10:45] mhr3: There is no currently-available method that both preserves cross-building and permits control of C++11 ABI changes across g++ version changes, to the best of my knowledge. You could always not use a C++ version with experimental toolchain support :P [10:45] (But that ship has sailed, I know) [10:45] cjwatson: yes, i am aware that there is no way to declare cross-compilers as a build-dependency. Without adding any dependency the package will fail to build from source, given the export in the debian/rules. The extra dependency helps to keep native build working even after g++4.9 -> g++4.10 default change, but will not help x-building. [10:46] cjwatson, For CI, we have to strip out :native as pbuilder doesn't parse it correctly even though we are already doing native builds [10:46] fginther: yes, I know, but that apparently isn't working quite right in all cases, given this conversation [10:46] cjwatson, this is applied as a hook and currently only to the projects when needed [10:46] fginther: https://jenkins.qa.ubuntu.com/job/unity-team-unity-scope-click-devel-utopic-amd64-ci/129/console [10:46] imho, just adding the export of CC/CXX in debian/rules is suffcient to guarantee package builds against expected compiler abi. [10:47] fginther: aha, why not globally? [10:47] xnox: No, because the point is to decouple these changes from our toolchain default switch [10:47] cjwatson, it was new and I didn't want to introduce it global until it was needed globally [10:47] xnox: That would make it impossible to continue building against g++-4.8 after we switch to g++-4.9, for instance, or vice versa [10:48] xnox: Which is the point (not to do that for an extended period of time, but to give those projects control over when they switch because they have to coordinate SONAME changes and such) [10:48] mhr3, cjwatson, it's been working fine so far, so I see no reason to not apply it to all projects. It's just that it's time didn't come until today :-) [10:48] cjwatson: right. There was proposal emailed to allow specifying cross-compilers, such that they are appropriately remapped using a build profile something a keen off "gcc-4.9 , ARCH-gcc-4.9 " [10:49] tvoss|food: ^- you might want to be aware of the above conversation [10:49] but exact semantics have not been implemented yet. [10:49] I think we will be discussing this at the Debconf. [10:49] xnox: right, exactly, that's what I discussed with Wookey years ago [10:49] ack. so same thing. [10:50] xnox: AFAIK the only thing that needs to be sorted is the way to tell which packages this should be applied to; I think I suggested a control field in the various relevant compiler packages, although I forget the name we settled on [10:50] (and of course implementation in dpkg-checkbuilddeps and sbuild) [10:50] ogra_, you won't believe the explanation for the autopilot bug :) [10:50] cjwatson, ack and thanks [10:51] brendand: this one weird autopilot bug, discovered by a mom [10:52] cjwatson, earn $$$ without doing anything!!! [10:52] ogra_, here's the guilty landing http://paste.ubuntu.com/7710576/ [10:52] ogra_, start with #95 [10:53] ogra_, then install qtubuntu-sensors [10:53] ogra_, run the test suite and autopilot gets dbus *errors* === oSoMoN__ is now known as oSoMoN [10:53] ogra_, then install ubuntu-application-api2-touch and they turn from errors into delays [10:54] ogra_, so i guess they tried to fix the dbus error incorrectly [10:54] ogra_, i do wonder though why autopilot has to scan the whole bus [10:54] ogra_, i need to ask them that [10:59] ogra_, so what can we do? revert that? i guess we need to get ricmm and/or rsalveti involved === MacSlow is now known as MacSlow|lunch [11:24] brendand, show it to ricmm [11:25] brendand: \o/ [11:26] ogra_, ok [11:26] brendand: yeah, as per ogra_'s proposition, let's wait for ricmm to comment on this [11:26] ricmm: ^ [11:40] Suggestion: some html page with an graphic representation of number of failures/crashes vs build number. Something like http://ci.debian.net on ci.ubuntu ? [11:41] h0x15, do you mean http://ci.ubuntu.com/smokeng/utopic/touch/ ? [11:42] or more detailed http://ci.ubuntu.com/smokeng/utopic/touch/mako/99:20140626.1:20140625/8744/ [11:42] yes, but visual grafig [11:43] chart [11:44] could somebody reconfigure silo * [11:44] silo 8 that is [11:45] sil2100: so whats the issue? [11:45] ogra_: [11:45] ricmm, seems our testing got extremely slow sinse papi2 [11:45] *since [11:46] or rather with the new qtubuntu-sensors [11:46] 95 is the orient [11:46] not papi2 [11:46] see brendand above [11:46] right, sorry [11:47] * sil2100 off to lunch [11:47] brendand: extremely slow in what way? do you have a bug number with the information? [11:48] ricmm, the UITK autopilot tests turned into a several hour job ... there is a dbus timeout that adds ~30sec per loop [11:48] ricmm, https://bugs.launchpad.net/autopilot/+bug/1334676 [11:49] Ubuntu bug 1334676 in ubuntu-touch-meta (Ubuntu) "Applications have a dead open dbus connection (since image #96)" [Critical,New] [11:49] all other AP tests got slow too [11:50] trainguards: can anybody reconfigure silo 8 [12:01] brendand: and reverting the changes from the usensord landing fixes it? [12:01] it might be dbus-cpp which we use to reach the usensord service [12:02] which became apparent now that usernsord is a dbus service [12:02] I'll examine after lunch if you dont mind [12:02] as its getting cold [12:02] ricmm, yes === alan_g is now known as alan_g|lunch [12:20] ogra_: sil2100 camera updated in store [12:24] sil2100: can you reconfigure silo 8 [12:30] davmor2, around? [12:30] mandel, oSoMoN you fine with me setting silo 11 to tested? [12:35] tvoss: I am [12:35] davmor2, hey there :) [12:35] thostr_: sure [12:35] popey: \o/ [12:36] thostr_: I'm on lunch now so it's taking a bit longer for me to notice pings :) [12:36] davmor2, I filed the issue you encountered in bug https://bugs.launchpad.net/location-service/+bug/1335102 [12:36] Ubuntu bug 1335102 in platform-api "Stopping positioning updates/the gps provider should release wake lock" [High,Confirmed] [12:36] davmor2, mandel, oSoMoN are you guys then fine with me setting silo 11 to tested? [12:36] tvoss: yeap everything works in 011 and it doesn't really break anything. Except for killing the battery :) [12:36] davmor2, ack, thank you [12:47] is something wrong with s-jenkins? [12:47] can't reach it === renato_ is now known as Guest94157 === alan_g|lunch is now known as alan_g [12:58] if only i knew its ip [12:59] mhr3: $ host s-jenkins.ubuntu-ci [12:59] s-jenkins.ubuntu-ci is an alias for mayura.ubuntu-ci. [12:59] mayura.ubuntu-ci has address 10.98.3.13 [13:00] mhr3: working fine here [13:00] tvoss, yup, as far as I’m concerned silo 11 is good to go [13:00] popey, thx, works via ip here too, just no dns it seems [13:01] i'll blame the upgrade that i just did [13:05] tvoss: ping === josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: josepht | CI Train Status: #87 promoted | CI Train Sheriff: sil2100 | Known issues: The spreadsheet is extremely slow, http://people.canonical.com/~rbpark/citrain/ knows the statuses before the spreadsheet does. Long mako wait times on s-jenkins. [13:07] ogra_ (and popey): tools are fine (we don't have to change anything atm-- we will in the future so keeping them in mind with new frameworks is a good idea). I used to be able to edit the docs, but part moved out to a spreadsheet that I can't edit. I've asked lool to update it [13:08] sweet, thanks [13:15] === trainguard: IMAGE 102 building (started: 20140627 13:15) === [13:16] josepht: there seems to be something odd with https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-autolanding/ [13:16] I'd expect it to correspond with the "ready to land" in https://code.launchpad.net/mir/+activereviews [13:16] But 804 is still in the latter and the other six in the latter are not in the former. [13:16] Any idea what's going on? [13:16] Ursinha: ^ sorry if i'm a redundant ping [13:17] alan_g: let me take a look [13:18] fginther, so is the :native stripping going to be global? === stgraber changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: josepht | CI Train Status: #87 promoted | CI Train Sheriff: sil2100, stgraer | Known issues: The spreadsheet is extremely slow, http://people.canonical.com/~rbpark/citrain/ knows the statuses before the spreadsheet does. Long mako wait times on s-jenkins. [13:26] fyi, just sent to the list. I did an emergency no-code-change upload for bug #1334940, but that has an unrelated testsuite failure [13:26] bug 1334940 in mediascanner2 (Ubuntu) "Can't scan videos on ubuntu touch (flo, image 100)" [Critical,Fix committed] https://launchpad.net/bugs/1334940 [13:27] alan_g: it looks like the generic-land job failed to aquire a lock on bzr+ssh://ps-jenkins@bazaar.launchpad.net/~mir-team/mir/development-branch/ [13:27] I have alerted Satoris, who is looking into it [13:27] alan_g: I'll try re-running that build [13:28] davmor2: once 102 is built, could you take a look at it promotion-wise? [13:28] sil2100: if the issue with not displaying music or videos is still there then no [13:29] josepht: that may take some time. [13:31] alf__: ^^ [13:34] davmor2: you mean the mediascanner bug? [13:35] alan_g: sorry, I meant the generic-land build, it's pretty quick and it failed again trying to acquire the lock. [13:35] sil2100: yes [13:35] sil2100: people having no access to their music or videos kinda sucks [13:36] davmor2: I see a fix in the archive... I wonder if it made it to this image [13:36] Of course it didn't make it ;/ [13:36] As it's still in -proposed [13:37] sil2100: it failed to build see mailing list team are on it now I think [13:37] josepht: weird. I just tried running break-lock --verbose ... it reported nothing [13:38] Ah, right, email from 15 minutes ago [13:38] Ok, so I'm starting to feel pressure here... [13:39] alan_g: Unable to obtain lock held by alan-griffiths@bazaar.launchpad.net on taotie (process #28697), acquired 20 hours, 57 minutes ago. [13:40] josepht: That's me. But...! I'll try merging that MP locally and push it - see what happens then [13:40] alan_g: hold on [13:42] tvoss, +1 from me for silo 11 [13:42] alan_g: it seems to have merged that time [13:42] ricmm: how's the dbus-related regression analysis proceeding? [13:42] \o/ [13:45] sil2100: we are looking into it [13:45] josepht: thanks. Any idea why jenkin's hasn't picked up the other jobs? [13:45] sil2100: but no definitives. it should be related to using dbus-cpp to reach usensord [13:45] trying to figure out which bit is actually timing out [13:45] alan_g: it also looks like jenkins has kicked off builds for the others as well [13:45] brendand_: do you know exactly what it is that autopilot is trying to do? [13:46] ricmm, the bug should say. but if it's not clear i can describe it in more detail [13:46] josepht: where do you see that? [13:46] alan_g: s-jenkins [13:48] josepht: Ah. I was looking at https://jenkins.qa.ubuntu.com - and that doesn't show the pending ones. [13:48] brendand_: describe it in more detail, what exactly is autopilot trying to do by probing into connection peers? [13:48] josepht: thanks for the help [13:48] brendand_: to find it is a testability interface? [13:48] if it is* [13:48] alan_g: my pleasure [13:49] brendand_: also, got a test that fails every time? [13:49] or is it all of them [13:49] ricmm, yes it seems to be trying to find if that connection has the introspection interface [13:50] ricmm, i run ubuntuuitoolkit. using --verbose [13:50] brendand_: ok [13:50] ricmm, you should see it hang for ~30 seconds, and then the error described [13:51] ricmm, i think this log from pitti might be helpful: http://paste.ubuntu.com/7709407/ === MacSlow|lunch is now known as MacSlow [14:02] brendand_: right, and the bug there is what, the app exit behaviour? [14:02] I'm not seeing any timeouts in that log [14:03] ricmm, the messages at the bottom [14:03] ricmm, it seems to suggest a problem closing the connection [14:03] those only show when the application exits [14:04] ricmm, ok i won't read too much into it then [14:04] ricmm, i'll leave it to you. if you have any more questions for me or need me to try anything, let me know [14:04] brendand_: so if its the usage of the dbus usensord interface, reverting qtubuntu-sensors to anything before 24.3 should fix it [14:05] is that correct? [14:06] ricmm, well doing qtubuntu-sensors:armhf from 0.6+14.10.20140623.3-0ubuntu1 to 0.6+14.10.20140624.3-0ubuntu1 broke it [14:06] ricmm, i didn't try then reverting it again [14:07] ricmm, i can do that now [14:07] 23.3 fixes it just checked [14:07] ricmm, read my last comment on the bug though. if you *just* upgrade qtubuntu-sensors then it is broken in a different, less subtle way [14:07] ricmm, ok cool [14:08] if you just upgrade qtubuntu-sensors the API wont be available from platform-api [14:10] ricmm, yeah [14:10] ricmm, so is it that the new api is broken then? [14:10] the API is using dbus-cpp to open a connection to the vibration service [14:11] something there is setting itself up in a way that it baffles autopilot [14:11] thomas will help in a minute as he knows that code best [14:11] it'd be great if I could know the exact autopilot lines that are doing this probing [14:11] which them timeouts [14:13] ricmm, you can reproduce it without AP like this: http://pastebin.ubuntu.com/7709477/ [14:13] ricmm, using qdbus [14:14] ricmm, i could give you the autopilot lines as well if you want [14:14] brendand_: ah thats amaizing :) [14:15] ricmm, but probably easier with those steps [14:15] sure, but this looks good enough [14:17] brendand_: the one thing I dont get is why autopilot needs to probe into the application's connections [14:17] is that to see if the application connected back to autopilot? if it finds itself in the tree? [14:19] mhr3, yes, it will be made global. It will take a day or two to roll it out, so if another project needs it right now, we'll need to update it individually. [14:23] ricmm, i need to find that out. but i don't think it's worth getting hung up on it. it can't be good that some dead dbus connection is being left around like that, right? [14:27] brendand_: its not a dead dbus connection, its a timing out introspect call [14:27] brendand_: the bug lies either with usensord or dbus-cpp [14:27] brendand_: I just want to know why the need to introspect the tested app's connections to find itself === alan_g is now known as alan_g|tea [14:29] hey, we need a/win 32 [14:29] meh [14:31] cjwatson, fginther, ev: I think we can skip the hangout if you want. I just sent an email. cjwatson: your response was very helpful and I think I have a better idea of what is needed. [14:32] sil2100: hi, could you please reconfigure landing-006? renato just told me there are some extra MRs needed for that one [14:32] cool [14:33] plars: Ah, good timing, I was just about to engage in battle with audio [14:33] plars, ack [14:33] boiko: sure [14:33] plars: Cool [14:35] hey, can I have a silo for mediascanner2 (line 31) [14:35] boiko: reconfigured [14:36] it is a no-code-change update to bring the packaging in sync with my emergency upload from today and then a ftbfs fix on top of that. the fix is to disable a test that is broken due to a change in sqlite behavior === alan_g|tea is now known as alan_g [14:36] that test failure doesn't indicate that mediascanner2 is broken (I'm told) and simply needs to be updated [14:37] tvoss: ok, so we might need to rebuild location-service from silo 11 - the changelog is too poor... there is a lot of changes but they're not mentioned in the changelog :| [14:37] The core devs would kill me if this would go to the archive [14:37] Especially oSoMoN [14:37] I mean [14:37] ogra_: [14:37] * sil2100 has some typing problems it seems [14:37] oSoMoN: ignore my ping ;) [14:38] * ogra_ hopes oSoMoN also check for proper changelog though ;) [14:38] * oSoMoN can also kill [14:39] ogra_, not just improper changelogs, also poor commit messages [14:39] yeah [14:42] note, this mediascanner2 landing is crucial for the mediascanner2 to be able to scan on the device, because the apparmor fix to fix that can't land without the fix for the ftbfs [14:42] jdstrand: you got silo 7 [14:42] thanks! [14:43] AlbertA: you've got silo 13 [14:43] sil2100: hey, I don't understand this error; care to explain? [14:44] sergiusens: hey! Which one? [14:44] sil2100: lolz; Friday woes :-) https://ci-train.ubuntu.com/job/landing-002-1-build/120/console [14:44] forgot to paste the link :) [14:45] === trainguard: IMAGE 102 DONE (finished: 20140627 14:45) === [14:45] ohoho, oh my [14:45] === changelog: http://people.canonical.com/~ogra/touch-image-stats/102.changes === [14:45] This is one absurd error [14:45] sergiusens: I noticed you have a gift of making citrain confused! [14:46] Let me dive into this one [14:46] tvoss: libjsoncpp-dev and libnet-cpp-dev are universe packages, location-service is in main, so you'll need to file an MIR for each of them before I can let your package in [14:46] Ah [14:46] sergiusens: ok, I see the problem I think [14:47] sergiusens: I mean... not sure if that's it, but it might lead to the confusion of citrain [14:48] sergiusens: so, the problem seems to be that there is a mismatch between the lp-project name (lp:udm) and the source package name (golang-udm) [14:48] stgraber, ack [14:48] sergiusens: the principle of all citrain (and also cu2d) project is that the lp project name needs to be the same as the source package name [14:48] stgraber, or alternatively patch out those dependencies, correct? [14:49] tvoss: right, dropping those two dependencies works too :) [14:49] sergiusens: this migth be the problem, and it's not really fixable in citrain as it's as I mentioned - it's a principle which CI Train enabled projects need to follow :) [14:50] stgraber, can I patch them out from the existing MR? [14:51] tvoss: yeah, that should be fine, update the current MR, rebuild it in the silo and that should do the trick [14:51] sil2100: hrmm, failure to merge the source :\ [14:51] jdstrand: where? [14:51] jdstrand: I've updated the spreadsheet and gave you write acess [14:51] stgraber, I'm confused, isn't the unity-scopes-api in main? [14:51] sil2100: it merges fine here. I have a feeling it is because of the changelog. the MR updates the changelog to sync to what is in the archive, but then expects something more [14:52] Ah [14:52] Let me take a look [14:52] sil2100: should we update the changelog too? [14:52] tvoss: unity-scopes-api | 0.5.1+14.10.20140626-0ubuntu1 | utopic/universe | source [14:52] tvoss: so, no [14:52] stgraber, ack and thx [14:52] stgraber, my bad then [14:52] sil2100: eg, to have ubuntu3? [14:52] jdstrand: wait, from what I see the build failure in silo 007 is caused by something else? [14:53] (we're talking about 007, right?) [14:53] oh, right, not approved [14:53] yes, let me address that [14:53] sil2100: we had this discussion once; and didrocks told us it was supported though [14:54] sergiusens: it sure should be, otherwise we wouldn't be able to land any of the system-image stuff [14:55] sergiusens: so we know the issue, go-dbus has no default error if the interfaces are no introspectable [14:55] sil2100: ^ [14:55] sergiusens: that wasnt for you, was for sil [14:55] I assumed :-) [14:55] so sergio will try his best, but ultimately this exposes an architectural issue with autopilot [14:55] brendand_: ^ [14:55] sil2100: I'll fix that and you fix my issue ;) fair trade :-) [14:55] I still dont understand why it needs to probe into the application's connections to check if the application has connected to autopilot [14:56] sergiusens: ok, let me dig in deeper then ;) Didn't know Didier removed this restriction [14:56] Ah [14:56] hm [14:56] yeah, stgraber brings me some confidence that it should be working [14:56] sil2100: also, this is the first train landing for this [14:56] Ok, I think I know what's up then ;) But let me double check first before I spout out another theory! [14:57] Yeah, this might be the reason, I think citrain might be confused by the lack of tags [14:57] sergiusens: could you try tagging in bzr the revision that's released into the archive? [14:58] sil2100: in trunk I asume; will do [14:58] i.e. 0.1-0ubuntu1 in trunk, probably revision no 2 [14:58] Yeah :) [15:01] * sergiusens tries build [15:03] sil2100: still breaks [15:03] sil2100: I can force build I guess === josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train Status: #87 promoted | CI Train Sheriff: sil2100, stgraer | Known issues: The spreadsheet is extremely slow, http://people.canonical.com/~rbpark/citrain/ knows the statuses before the spreadsheet does. Long mako wait times on s-jenkins. [15:04] sergiusens: let me take a look again then [15:05] ricmm, it might not be an 'issue' though - it might be essential for autopilot to do it, so please - keep looking on your side for a solution [15:05] fginther, can you have a look at https://code.launchpad.net/~nskaggs/reminders-app/fix-evernote-sdk-python3/+merge/223493 again? I see the pep8 errors again that you tried to get rid of earlier in the week. I fixed the errors in the code we want to be checking [15:06] ricmm, i really don't understand autopilot well enough to know if there is another approach that can be used. we need to wait for someone who does to come online [15:06] Ah! [15:06] sergiusens: I see the problem... it's a bit more trivial it seems [15:07] ricmm, did you find any root cause yet? [15:07] ricmm, is it the go-dbus thing you mentioned? [15:07] sergiusens: so, only now I noticed that trunk still has 0.1-0ubuntu1 in the changelog as UNRELEASED [15:08] sergiusens: so... please make a quick direct push to trunk where you change 0.1-0ubuntu1 to utopic and maybe re-tag this one to 0.1-0ubuntu1 [15:08] sergiusens: it should work like a charm then [15:08] sil2100: ah, that can actually be it; is there a way to remove the tag easily though? [15:09] or only with --overwrite? [15:09] sergiusens: I'm not sure... I know I did it a few times, but I don't remember if I didn't have to --overwrite in the end [15:09] ack, I'll figure it out [15:10] As it's a new project I guess even --overwrite wouldn't hurt I guess... still, you might try doing a bzr tag --delete and then re-tagging it and pushing without it [15:10] Who knows? Maybe it'll allow it [15:10] if you are the only committer --overwrite is ok [15:10] balloons, did the packaging change recently? It looks like it's now looking in the temporary install path, should just add that to the exclude list [15:11] fginther, yes, I needed to add those modules to the packaging.. failed to do that originally :-) [15:12] balloons, I'll have to update the hook then, hang on [15:17]