[01:24] rvr: pong [01:24] jamesh: It's 2:25 AM here X-) [01:24] jamesh: Anyway... [01:24] jamesh: I was testing silo 9 [01:24] rvr: it was 1:30 am when you pinged me :) [01:24] jamesh: Oh, where do you live? [01:25] Australia? [01:25] rvr: Western Australia (UTC +8) [01:25] I see! [01:25] jamesh: silo 9, thumbnailer... I was stress testing gallery-app [01:25] jamesh: I see some freezes when creating/deleting the files [01:26] jamesh: Is that expected? [01:26] I didn't check without the silo [01:27] rvr: I have seen some issues with the stress tests even before we did the big thumbnailer landing a few weeks back. Let me find the bug [01:28] rvr: there is this bug: https://bugs.launchpad.net/ubuntu/+source/gallery-app/+bug/1475210 [01:28] Ubuntu bug 1475210 in gallery-app (Ubuntu) "gallery crashes when trying to preview lot of pictures" [Critical,In progress] [01:28] so I don't think what you are seeing is caused by this silo. [01:28] jamesh: Right [01:29] jamesh: Looks like that's it, thanks. I'll perform some more tests tomorrow morning and will probably approve it. [01:29] rvr: thanks. === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [04:55] o/ === chihchun_afk is now known as chihchun [09:09] hey trainguards, any idea why my silo 41 build failed? I cannot find any clue in the log - e.g. https://launchpadlibrarian.net/213648798/buildlog_ubuntu-vivid-arm64.unity-api_7.99%2B15.04.20150805-0ubuntu1_BUILDING.txt.gz ? [09:17] shrug [09:17] stupid question, but how does one add a landing ask with the new system? [09:17] ignore that [09:18] (logging in with team creds checked) [09:18] I didn't check all the sso team permissions first time I logged in [09:18] (that's stupid that default doesn't include what it should) [09:20] and why do we have editable entries which are "don't touch" [09:20] pstolowski: seems weird, but it's not that'd be a generic armhf problem [09:20] at least the hints should include the "don't touch" [09:20] without having to get the tooltip to hint that [09:20] seb128: bugs/requests to https://bugs.launchpad.net/bileto .. not sure about why they are editable [09:23] pstolowski: let me take a look [09:23] pstolowski: the fatc that it happens on vivid too is especially problematic/weird.. I can't see anything wrong, but can you check with others who may be building unity8 atm? I have a vague memory of reading something yesterday about something breaking up unity something in vivid overlay... and that's all I can remember :D it's the only thing I can think of [09:23] but let's have sil2100 look at it too, maybe his eyes spot something [09:24] and of course, retrying is worth trying [09:25] trainguards: any idea what's wrong in https://ci-train.ubuntu.com/job/ubuntu-landing-019-1-build/189/console ? [09:25] no space left? [09:25] uh oh, oh shit [09:26] urgh [09:26] hm, df says that there's space still, but maybe it's not showing all the volumes or something [09:27] I thought those two volumes (you just checked) were the ones.. [09:27] Mirv, sil2100 ok thanks (note, amd64 build failed for sensible reason, only arm looks weird), retrying anyway [09:28] sil2100: it says the same https://ci-train.ubuntu.com/job/cyphermox-test/1052/console [09:28] Really strange [09:29] tsdgeos: could you retry a watch_only build? [09:29] Since this looks really strange [09:30] Mirv, thanks [09:30] greyback_: can you do what sil2100 said ↑↑↑ [09:36] tsdgeos, greyback_: I did it [09:56] pstolowski: fallout from a buildd upgrade, sorry - retrying is the right thing to do [09:57] Mirv: ^- [09:57] cjwatson: thanks! [09:57] pstolowski: let me retry [09:57] I'll see if I can search for such failures and bulk-retry, after coffee [09:57] was just finishing up the proper fix for the underlying bug [09:58] sil2100, no! [09:58] sil2100, i've kicked the build already [09:58] cjwatson, ack, thanks! [09:58] ACK, since I saw failures in the build, so I thought it failed again [09:59] sil2100, ah, right, it's failing again but for different reason i think [09:59] looking [10:02] pstolowski: bah, you kicked off an all-architectures rebuild for a problem on one architecture? [10:04] cjwatson, yes... i'm still chasing various g++5 related build failures, it's failing on all architectures atm afaict [10:05] pstolowski: vivid can have nothing to do with g++-5 [10:05] pstolowski: for single-architecture failures, please don't use the ci-train "build" function [10:05] it's wasteful of what are actually quite highly contended resources [10:05] cjwatson, fair point... ok, how i do this otherwise? [10:06] pstolowski: get somebody in ~ci-train-ppa-service to use the retry function directly in the PPA [10:06] any train guard should be able to do so [10:07] sil2100: I did watch-only rebuild again (disabled twin check), it went ok [10:07] I wish that the train exposed some function to let people do this by proxy for silos assigned to them [10:10] thanks cjwatson! [10:11] greyback_: it looked like a transient error, there's no way the train could have run out of space... [10:11] cjwatson: trying the herd the people to not run full rebuilds is hard, everyone seems to default to it.. [10:11] CI Train is too easy! [10:12] Mirv: well this is in part because it doesn't expose the function they want, and they can't use it directly in the PPAs unless they're in ~ci-train-ppa-service which most users aren't [10:12] that's true. [10:12] but ci-train proxies uploads, so it would make sense for it to proxy upload-gated functions such as retry as well [10:14] filed https://bugs.launchpad.net/ubuntu-lt/+bug/1481687 about it [10:14] Ubuntu bug 1481687 in Ubuntu Landing Team "Allow landers an option to retry a single arch build for a package" [Undecided,New] [10:14] Mirv: it's a dupe ;) [10:15] sil2100: oh :) I just checked -lt bugs were empty. feel free to mark as so! [10:15] Mirv: thanks [10:15] of course, people tend to use the "Build" without parameters even now when they want to rebuild a single package, so just having the option does not go all the way [10:15] https://bugs.launchpad.net/cupstream2distro/+bug/1397388 I expect [10:15] Ubuntu bug 1397388 in CI Train [cu2d] "Train users should be able to perform failed package PPA rebuilds" [Wishlist,In progress] [10:16] Yes, there's a branch for that already, but missing tests yet [10:16] Need to finish that up [10:16] * cjwatson marks as duplicate [10:16] Thanks :) [10:53] cjwatson, it failed on armhf the same way https://launchpadlibrarian.net/213656647/buildlog_ubuntu-wily-armhf.unity-api_7.99%2B15.10.20150805.2-0ubuntu1_BUILDING.txt.gz [10:54] pstolowski: hm [10:58] pstolowski: this is all going to be connected to https://rt.admin.canonical.com/Ticket/Display.html?id=83632 anyway - I'm just checking that my requested upgrades fix it [11:01] cjwatson, ack. can you ping me when you think i should retry the build? [11:02] pstolowski: I'll deal with retrying them for you [11:03] cjwatson, ok, thanks [11:03] pstolowski: will get IS attention as quickly as I can, but IIRC we have no EU webops coverage this week so it will probably be a few hours :-/ [11:03] uhm [11:03] that means lunch time === pstolowski is now known as pstolowski|lunch [11:03] food is good [11:04] oh, and 2.5 of the architectures are going to need to wait for Adam to be around [11:06] he crashed about five hours ago, so hopefully also in a few hours? [11:07] FWIW I think this affects packages that B-D on something:any or something:native [11:15] ok, probably just :native, and my upgrade will fix it [11:18] * sil2100 off to prepare lunch === alan_g is now known as alan_g|lunch === pstolowski|lunch is now known as pstolowski [12:23] trainguards: so persistent-cache-cpp is landed now, but still got the ridiculously verbose changelog entry, despite the debian/changelog having a manual entry. can we find what is causing this bug exactly and get it fixed? [12:26] dobey: sure, let's create a bug for that - it's interesting, maybe the logic changed after robru rewrote the whole thing, but normally the train should never touch the changelog for a merge that had manually added a changelog entry [12:27] But as I said, the whole code got changed from the times we wrote it with didrocks [12:28] file a bug where? [12:28] o/ trainguards, i'm done with testing silo 26 (oxide), can you help me publish that update to Wily? [12:28] dobey: http://bugs.launchpad.net/cupstream2distro/ [12:28] (for ref. the vivid and trusty security updates have already been released) [12:29] dbarth: wily landing might be blocked by the gcc-5 transition [12:29] ah, this is still on? [12:29] ok, anyway, oxide is ready when the archive reopens [12:29] * ogra_ is curious how you even tested that [12:29] yeah, a lot of things still failing in proposed as a result [12:29] dbarth: hey! hmm, why wasn't this already released to wily by the oxide team? [12:30] anpok_: ping [12:30] rvr: hey; and i've approved the branch in silo 15; let me know when you take that one next [12:31] rvr: pong [12:31] dbarth: Yeah, I know. I already moved the card to the ready for testing lane :) [12:31] anpok_: Hey [12:31] anpok_: Can you take a look to the output of udevadm? I don't know whether it's fine or not. [12:31] sure [12:31] dbarth: indeed, there's the gcc5 rebuild of oxide-qt in proposed at the moment, blocked on gcc-5 migration settling [12:32] anpok_: http://paste.ubuntu.com/12006552/ [12:32] dobey: ouch, that's a big one [12:32] strange though, as it had gcc5 already in the ppa build logs [12:32] maybe not the latest gcc build [12:33] rvr: oh you have to replace with a device path [12:33] dbarth: yes, the silo PPAs build against proposed [12:33] rvr: i.e. run find /sys/ | grep capabilities [12:33] dbarth: but yeah, it's a big one. welcome ot the wonderful world of c++ abi incompatibilities [12:33] :) [12:34] anpok_: http://paste.ubuntu.com/12006568/ [12:34] rvr: then on my system I get.. /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input3/capabilities .. and remove the initial "/sys" and the capabilities suffix.. .. [12:34] dbarth, i suspect you did your testing on wily against last weeks wily ? [12:34] * ogra_ fears you will likely have to re-test after the transition, everything you tested against will have changed then [12:35] anpok_: http://paste.ubuntu.com/12006581/ [12:35] yes.. [12:35] (otoh nobody runs wily on phones anyway, right ? :) ) [12:36] dbarth: if the oxide silo is ready for release, please mark it as ready and we can publish - but it might probably get stuck in -proposed [12:36] rvr: one of those virtual input 1 to 4 is probably the touch screen [12:36] but the output for mtk-kpd looks correct. [12:37] rvr: with the change one of the four yields ID_TOUCHSCREEN=1 [12:37] anpok_: http://paste.ubuntu.com/12006590/ [12:37] anpok_: input4 [12:37] ID_INPUT_TOUCHSCREEN=1 [12:38] cool.. so it still works :) [12:40] sil2100, or others: could you have a look at http://autopkgtest.ubuntu.com/packages/q/qtcreator-plugin-ubuntu/wily/amd64/ ? is this being worked on? [12:41] sil2100: "publish without qa"? [12:41] ogra_: yes, indeed ! :/ [12:45] hmm, i read the fine manual, and that seems to be the right flag :) === alan_g|lunch is now known as alan_g [13:52] sil2100: is oxide getting rebuild in the end? [13:52] sil2100: oSoMoN just noticed -proposed now has the silo/ppa version built last week [13:52] dbarth: not sure, when did you guys build it? Did it build against gcc-5? [13:53] cihelp: ping, are you guys resopnsible for the autopkgtests in proposed migration now? [13:53] sil2100: according to the logs it was gcc-4.9 and there were gcc5 dependencies as well [13:53] dbarth: ok, then we need to rebuild it... [13:54] dbarth: you want to use the silo for the rebuild? Or chrisccoulson will do it in the other PPA? [13:54] https://launchpadlibrarian.net/212992541/buildlog_ubuntu-wily-armhf.oxide-qt_1.8.4-0ubuntu1_BUILDING.txt.gz [13:54] sil2100: pitti is currently working on taking proposed-migration over. [13:55] sil2100: can you reload the silo with a source copy then please? to ensure the right gcc5 packages are used [13:55] dbarth: I can do that, will take a bit of time since even generating the source package takes a while ;) [13:56] josepht: since we seem to be seeing strange issues with multiple autopkgtests, and even the logs are mentioning that it might be a testbed issue - who should we poke about those? [13:57] sil2100: can you paste a link to an example you're seeing please? [13:59] sil2100: thanks; yes, that will take a while [13:59] josepht: http://autopkgtest.ubuntu.com/packages/q/qtcreator-plugin-ubuntu/wily/amd64/ <- here for instance [14:00] josepht: we tried installing the package in mention on a -proposed enabled chroot and everything seems to be fine, but maybe we're misunderstanding something [14:03] sil2100: this is something pitti should be able to answer [14:03] josepht: ok, thanks! [14:10] sil2100, or others: could you have a look at http://autopkgtest.ubuntu.com/packages/q/qtcreator-plugin-ubuntu/wily/amd64/ ? is this being worked on? [14:10] ohh, reading backlog ... [14:11] doko: yeah, on it :) [14:11] doko: some rebuilds will be required sadly... [14:22] sil2100, let me know if should do these directly in the archive [14:37] dbarth: oh, silo 26 migrated? [14:38] I thought we didn't want to have that published without rebuilding with gcc-5 === vrruiz_ is now known as rvr [14:46] someone had marked that as ready to publish [14:48] Probably dbarth, I thought he switched that back to 'no' after asking for a rebuild [14:48] is a rebuild already building? I think if something like that is spotted, it'd be best to set the status and better yet remove the build. [14:48] let's copy it as soon as it's done [14:48] I'm still building the source package [14:48] I'll need a silo to build it in [14:48] Since I wanted to use the existing one, but it got freed, oh no [14:53] Yay, even got the same silo o/ [14:53] Source package almost there, lintian running now [14:54] sil2100: hmm, i had marked it ready to publish indeed, and forgot it was marked as such when we discussed the rebuild [14:55] should i put a new request in the system? [14:55] dbarth: already did that [14:55] ah perfect [15:11] sil2100, hey, could you pls kick the build of unity-scopes-shell in silo 41 for Wily amd64 only? [15:12] pstolowski: on it [15:12] thanks! [15:13] pstolowski: only amd64, yes? It's re-running now [15:13] sil2100, yes, thanks! [15:19] brendand, ping === chihchun is now known as chihchun_afk [15:55] pstolowski, hi [15:55] brendand, hey,i've a humble request [15:56] pstolowski, i humbly accept your request, whatever it is :) [15:56] :) [15:57] brendand, can jhodapp's silo 021 get QA priority when ready for qa testing (should be soon)? we depend on the stuff from this silo for some other feature for ota6 [15:58] pstolowski, it would be best to ask davmor2 that, he's in charge of silo testing while jibel is on holiday - i haven't handled those things in a while [15:59] brendand, ah, ok [16:00] davmor2, ^ ? [16:01] pstolowski: pfff I'm not so humble, I'm more grumpy ;) The queue is fairly quiet currently so it should be doable. When the silo is ready to test just ping rvr with the request and he can reassign to alesage if he is busy. [16:02] davmor2, maybe that's why he asked me :) [16:02] brendand: probably [16:03] phew, that was easy ;) [16:03] thanks davmor2 [16:04] jhodapp, can you do that ^ in case i'm not around (eod soon)? [16:04] pstolowski, when even davmor2 agrees straight away you have nothing to worry about :) [16:05] sometimes he says no just for the fun of it [16:05] pstolowski: brendand sarcasm doesn't work on irc if you miss of the tags [16:05] I'm just taking everyone at their word [16:07] pstolowski, just ping rvr you mean? [16:07] jhodapp, yeah, when your silo 21 is ready for qa [16:08] pstolowski, indeed, I can do that [16:08] thanks for asking QA about it [16:08] renatu, regarding indicator-transfer-buteo, that should be built against vivid with the overlay PPA, correct? [16:08] jhodapp, cool, thanks! [16:10] sil2100, FYI i kidked off the image build we discussed before [16:10] alesage: now remember "bird is the word" [16:11] ogra_: ok, thanks for the info - I saw livecd-rootfs landing in the overlay so I expected that ;) [16:11] I've heard about that [16:11] :) [16:13] alesage: Everybody's hear about the bird [16:15] sil2100, hey, where do i find any trace of the amd64 build for silo 41 that you started some time ago? can't see any new builds in the status of the ppa [16:16] pstolowski: ? Let me check that [16:16] pstolowski: I've almost succeeded in getting IS attention, BTW, should hopefully be sorted soon ... [16:16] pstolowski: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-041/+build/7761970 this is it [16:17] pstolowski: started 1 hour ago, the rest was from 5 hours ago, so this is the newest failure after my manual re-build [16:18] hmm is -gles out of sync in vivid ? i386 just fell over [16:18] sil2100, uhm.. pretty weird, i pushed a fix for this failure 6 hours ago [16:19] ogra_: the emulator is broken since 2 OTAs [16:19] (if that's what you're talking about) [16:19] sil2100, yes, i know that but the image build just failed with a dependency error [16:20] Oh? [16:20] https://launchpadlibrarian.net/213681063/buildlog_ubuntu_vivid_i386_ubuntu-touch_BUILDING.txt.gz [16:20] and thats nothing my livecd-rootfs change could cause [16:21] cjwatson, ack, thanks for heads up [16:22] ogra_: ok, last image was successfull, but I see we had a new UITK landed [16:22] sil2100, armhf definitely got past that point [16:22] so yeah, likely the new UITK [16:24] trainguards: can item 55 in the requests list be marked as abandoned? i presume it was copied over from spreadsheet, but looks like it actually landed last week? [16:26] ogra_: interesting, I don't see any packaging changes in the UITK landing [16:26] dobey: hm, ok, let's mark it landed then - I'll double check and clear it out [16:27] sil2100, perhaps the build of libqt5gui5-gles faile3d or some such ? [16:28] ogra_: well, this one comes from qtbase-opensource-src-gles and we didn't have any uploads of that today [16:29] well, something makes it uninstallable [16:30] perhaps a buildd hiccup, i can triger an i386 build after armhf finished if you want [16:30] to see if it is reproducable [16:31] sil2100, if you do a single arch rebuild in the ppa, it fetches all the LP branches again, right? [16:31] dobey: ok, confirmed it as landed, probably some bogus stuff during migration [16:31] pstolowski: hah, no :) [16:31] pstolowski: if there are changes in the source you need to do a CI Train build [16:31] sil2100, ouch :( [16:32] sil2100, yeah.. i fixed that last error.. ok, rebuild in full then [16:32] pstolowski: a single arch rebuild only 'retries the same build' - it helps in case there are transient issues or some problems with the build env [16:32] pstolowski: ouch? that's the correct thing to do. if you changed the source, then you need to recompile for all archs :) [16:32] pstolowski: yeah, sadly source changes need new uploads [16:33] Sorry I didn't mention that [16:33] dobey, yeah, makes sense. 'ouch' for my naivety [16:33] sil2100, thanks [16:41] cjwatson: do you know of any documentation for the lp "teams" openid extension? for some reason on bileto login the necessary teams are unchecked and I don't see any way to make those teams default checked. [16:42] robru: That's SSO, not Launchpad. [16:42] robru: I don't know very much about it. [16:42] cjwatson: do you know who would know? [16:43] robru: You could try in #u1-internal [16:43] cjwatson: thanks [16:46] https://launchpadlibrarian.net/213682706/buildlog_ubuntu-vivid-armhf.unity-scope-click_0.1.1%2B15.04.20150805-0ubuntu1_BUILDING.txt.gz [16:46] well that's weird [16:46] hey robru, how do I mark my silo as 'all tests passed, you can finally publish now' in the new system? [16:47] bregma: depending on whether or not your silo releases to vivid overlay, you can set the QA field to either 'Publish without QA' or 'Ready for QA' [16:49] whoops, there it is..... [16:56] dobey: That's the bug (or part of it) that I'm waiting for a launchpad-buildd deployment to fix [16:56] cjwatson: ah ok. i guess having it rebuild won't help? [16:56] fginther, yes [16:58] dobey: It will not help, no. [16:58] dobey: I blame dpkg upstream (for convoluted reasons). [16:58] cjwatson: ok, thanks [16:59] mterry: kenvandine: anybody around for a packaging ack? https://ci-train.ubuntu.com/job/ubuntu-landing-043-2-publish/lastSuccessfulBuild/artifact/compiz_packaging_changes.diff/*view*/ thx [17:01] ogra_: give me a sign if a rebuild doesn't help [17:02] ogra_: I'll try to tackle that tomorrow [17:02] sil2100, will do ... damn ... my patch didnt help [17:03] Get:1 http://ftpmaster.internal/ubuntu/ vivid/multiverse android all 20141117-0039-0ubuntu11 [439 MB] [17:03] still pulls from the archive :/ [17:04] ogra_: maybe the existing sources.list before the step you made doesn't have the overlay in it? [17:04] cjwatson, is the EXTRA_PPAS var in the environment for the whole build or does it get unset at some point ? [17:05] * ogra_ wonders why https://launchpadlibrarian.net/213678319/livecd-rootfs_2.300.2%2Bvivid2_2.300.2%2Bvivid3.diff.gz still uses the archive === alan_g is now known as alan_g|EOD [17:05] sil2100, it is the very last step in the build, it should have everything in the sources.list that was used during buiild [17:06] (that is the reason why the initial code that i comment out there actually exists) [17:06] ogra_: Only a limited set of environment variables are passed through to auto/build. [17:06] UGH ! [17:06] if [ ! "$EXTRA_PPAS" ]; then [17:06] * ogra_ needs a refresh course in shell ! [17:06] damn [17:07] that should be -z or "! -n" [17:07] ogra_: But that code looks quite wrong anyway. You still want to do that stuff in the extra-ppas case, just somewhere else. [17:07] Can't you just move it down slightly? [17:08] cjwatson, no, i dont want to wipe the sources.list but pull the android package from the PPA [17:08] and the PPA should be available in the sources.list already so we would just get the newer package from there [17:08] ogra_: ugh, duuh [17:09] Missed that as well, my brain is too much C oriented to notice that [17:09] ogra_: [ -e config/archives/extra-ppas.list.chroot ] would probably work better. [17:09] cjwatson, perfect ! [17:09] I think. [17:10] well, that livecd-rootfs only exists in the overlay anyway ... in the very worst case i could just rip out the whole snippet ... but i'd rather make it generic enough that i can push it upstream [17:16] robru, looking at that compiz packaging diff... [17:17] robru, the Breaks/Replaces changes use the wrong version number... I don't think it causes a problem for the archive itself (the version is still newer than last published one)... But it's still bad practice/we should look at why that happened -- I thought we had a variable we could use and our build system would insert the right version [17:18] mterry: yeah if you use 0replaceme it gets replaced with the generated version. [17:18] bregma: ^^ did you not use 0replaceme? [17:19] the what? [17:21] bregma, do you know who changed the Breaks/Replaces lines in https://ci-train.ubuntu.com/job/ubuntu-landing-043-2-publish/lastSuccessfulBuild/artifact/compiz_packaging_changes.diff/*view*/ ? [17:21] dbarth: hey! Forgot to give you a poke, oxide is building since a while in silo 26: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-026/+packages [17:21] bregma, they use the wrong version, presumably because "0replaceme" wasn't used [17:23] mterry, that's https://code.launchpad.net/~mitya57/compiz/switcher-plugins-in-default/+merge/262518 [17:23] I am unfamiliar with 0replaceme, it's not a Debian packaging thing [17:25] bregma, yeah, it's just a CI thing. Because you don't know the version that will be released when you land your MP [17:27] robru, bregma: anyway, I guess +1 on those packaging diffs, since it won't cause a problem. But just heads up about 0replaceme. Do we have a wiki page that mentions it? [17:27] * bregma has gained a level!! [17:27] mterry: ostensibly [17:29] mterry: well I can't seem to find that in the documentation. awesome. [17:29] so plars, I can't get the intro wizard to go away. I've tried phablet-config. Do you ever have this issue? [17:29] bregma: so yeah, anywhere you want to refer to "the version of the package that the train will generate for me" in any file under debian/* (but not recursively in subdirs), just use "0replaceme" and the train will replace it [17:30] balloons: no, what are you trying? [17:30] mterry: ok thanks [17:30] plars, phablet-config -s JB072312 edges-intro --disable, phablet-config -s JB072312 welcome-wizard --disable [17:32] balloons: oh, one thing to be aware of, iirc using phablet-config just "disables" or turns them off, it doesn't stop the process. So you'll probably need to reboot to see it take effect [17:33] plars, lol. sorry for jumping channels [17:33] robru: I see in the http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html that the 1.3.1549+15.10.20150710.1-0ubuntu2~gcc5.1 UITK is blocked in the proposed migration by the misterious qtcreator-plugin-ubuntu error. Is it something what blocks the landing of the silo13 UITK? [17:33] and right, I've tried toggling them on and off and rebooting [17:33] I'll try setting the timezone and locale too, heh [17:33] that's what's popping up [17:34] balloons: it doesn't give you any kind of error or anything? [17:34] bzoltan_: the qtcreator issue is blocking lots of things including gcc5 [17:34] plars, no. Disabling again tells me it's already disabled. Otherwise they run fine [17:34] bzoltan_: the ubuntu-sdk-libs-dev needs to be updated to either not depend on libboost1.55-dev at all, or to instead depend on libboost-dev [17:34] dobey: the only problem is that I have no idea what is wrong with that package... [17:35] balloons: and is it just edges-intro, or welcome wizard also that fails to disable? [17:35] bzoltan_: that comes from the ubuntu-touch-meta package [17:35] plars, not sure, we don't get to edges intro. Rick tells me it's at the wizard to select language, etc [17:36] dobey: here? http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/view/head:/sdk-libs-dev [17:37] bzoltan_: i don't know what that file is; it's not a debian/control file [17:37] dobey: is anybody working on it? Seems to be a super bitesize job [17:38] dobey: no, it is not... I used to propose MRs for that project.. ogra_ used to take care of that seed as I remember [17:38] dobey: ubuntu-touch-meta is generated from seeds [17:38] ok [17:39] there's an update script. but I don't know how well it will be working at the moment with stuff stuck in -proposed [17:39] (for wily at least :) ) [17:39] dobey: unity-scope-click/armhf building for you now [17:39] balloons: ok, so I actually had a krillin sitting next to me that had been recently installed, and nothing done to it [17:39] dobey: xnox has touched exactly that dependency there [17:39] cjwatson: well, slangasek uploaded a change to ubuntu-touch-meta a few days ago, but it only fixed the runtime deps. the -dev package still needs fixed [17:39] and uploaded [17:40] balloons: I did: phablet-config welcome-wizard --disable ; phablet-config edges-intro --disable ; adb reboot [17:40] balloons: and it came up with the regular unlock screen, I unlocked it and it never gave me the wecome screen or the edges intro (before reboot, it was freshly installed and waiting at the welcome screen) [17:40] bzoltan_: sorry I don't know and I'm a bit swamped fixing SSO at the moment [17:40] dobey: cjwatson: and xnox -> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/revision/308 [17:40] balloons: are you sure it's rebooting? [17:40] robru: ignore it please :) [17:41] plars, I guess I can check uptime [17:42] bzoltan_: do you know why that is the versioned package rather than just "libboost-dev" ? [17:44] dobey: no idea... I think something depends on that particular package... at least the rdepends shows different list for it [17:46] i don't know why it depends on boost at all. exposing boost to consumers of our sdk/apis seems like a bad idea to me :) [17:48] dobey: pete woods added it with other Scope facing APIs [17:48] plars, indeed it's rebooting. I've set everything and rebooted a few times. Time to try again [17:48] oh, hmm [17:56] bzoltan_: so then i guess all that's needed is for someone to run the script to update the package and upload it to the archive [17:56] dobey: it came in here http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.vivid/revision/243 [17:56] dobey: precisely ... "someone" :) [17:57] well, someone with the permissions to do so, of which i am not, or i would have done so on monday :P [17:58] bzoltan_: though, even with that uploaded, i think your package would still be blocked from migrating, by gcc5 [17:59] dobey: very much possible [17:59] * bzoltan_ loves the new toolchain :) [18:00] plars, it's actually running now. Not sure if it was the magic of setting everything or not, but I'll just do that from now one [18:01] balloons: so it works? you may want to retry just to be sure, but I'm not sure what went wrong before [18:01] balloons: I didn't hit any snags here, but perhaps you ran into some weird race or something [18:01] plars, yes it works. I reflashed this morning after not having success yesterday and it didn't seem to change anything [18:02] balloons: the other thing, is of course to make sure you do adb wait-for-device after installing, before using phablet-config [18:02] plars, ahh. also noted [18:02] robru, hey, can you please dput all of the gstreamer source packages in ppa:jhodapp/ubuntu/ppa into silo 21 [18:02] jhodapp: sure one sec [18:02] sure, thanks [18:04] jhodapp: ok copied. You can do a WATCH_ONLY build in the silo if you want to be IRC pinged when the silo builds are complete [18:05] robru, awesome, thanks for the tip! [18:05] robru, btw, silo 38 is no longer needed as 21 replaced it [18:08] jhodapp: will free it, thanks [18:09] np [18:09] jhodapp: lol, how many builds did you do? https://ci-train.ubuntu.com/job/ubuntu-landing-038-3-merge-clean/4/console [18:10] robru, apparently many :) [18:26] robru, any idea why silo 21 is trying to build gst-libav1.0 first when its debian/control specifies that it must build gstreamer1.0 and gst-plugins-base1.0 first? [18:27] jhodapp: I don't think PPAs particularly care about build order. [18:27] jhodapp: if one fails due to another one not being present the PPA will retry it an hour or two later. [18:27] robru, I thought they'd respect the dependency version order and figure it out by that? [18:28] jhodapp: well I'm not an expert on PPA buildds, but I'm not aware of any such thing. you put a package in there and it builds it. [18:29] I'm going to kill my build then and try a manual order [18:29] jhodapp: if the deps aren't available it will just depwait [18:29] yeah I think that's what it was doing, but the deps it needs are in that silo [18:29] jhodapp: if the build shows that it's trying to build and failing, that would suggest that you don't have the packaging right. eg it's not depending on the correct version number. [18:30] jhodapp: ok but if the deps it needs aren't built yet, then they're not really "in the silo" in any meaningful sense ;-) [18:30] well specified to be in that silo :) [18:36] robru, yeah, I don't understand why it can't find libgstreamer1.0-dev...it did successfully build it and it is version 1.5.2 which is what it's looking for [18:37] jhodapp: "Building. Preparing packages. Building. Building. Packages built" can you please stop starting jobs before the previous one finishes? [18:37]