[06:49] thomi: hi there [06:52] thomi: I'm working on splitting the autopilot-qt packages in an orderly fashion, in order to get Qt4 off the phone images, and I had a question about how the libqttestability.so is being loaded [06:52] thomi: to make sure that I'm shipping the right filenames to match the way it's being invoked [07:00] thomi: it appears, based on inspection of the Qt libs, that it's probably looking for libqttestability.so when -testability is passed? (Contrary to the Internet's claims that it looks for 'libtestability.so') [07:10] Mirv: Timo! You're back! :) [07:11] slangasek: I'm not really here, but that sounds about right [07:12] ok [07:12] thomi: if you're not really here, then I'll go ahead and push https://code.launchpad.net/~vorlon/autopilot-qt/split-qt4-qt5-binaries/+merge/229378 to the archive :) [07:13] slangasek: I can take a look in a bit [07:13] thomi: ok [07:16] thomi: unrelated, why does libautopilot-qt-autopilot have a hard-coded dependency on the obsolete python-support? [07:22] sil2100: hey! and yes! :) [07:22] sil2100: I've just read through all your status reports among else, very helpful [07:23] slangasek: veebers is the person to talk to about that. I'm not sure, I can take a look tomorrow [07:24] thomi: ok. It seems to have been part of the packaging since mzanetti first added the libautopilot-qt-autopilot packages [07:25] slangasek: we can probably remove that dep [07:31] slangasek: you don't have a problem shipping shared libs in a package that doesn't start with 'lib' ? [07:32] thomi: they're not really shared libs, they're all plugins [07:33] thomi: it would be just fine to build these without any SONAME at all [07:33] slangasek: OK, LGTM [07:34] thomi: ok, cool [07:34] thomi: should I upload direct to the archive, or do you want this in a silo? [07:34] slangasek: Given that we can't release anything at the moment, uploading it directly might be the best thing [07:35] Do you still want Adam Conrad to review it as well? If so, just make sure it gets top-approved and CI will merge it into our trunk [07:43] thomi: if I upload it directly, I can pester the archive admins to review it in the queue [07:43] thomi: the MP review request was because silos buggily bypass the NEW queue [07:43] ok, cool - I'll top-approve it now then [07:43] thomi: great, thanks :) [07:44] thomi: now, what's this about being unable to release things at the moment? TRAINCON-0? [07:44] no worries - thanks for sorting that out for us - it's been on my TODO list for a while [07:44] yes, it's been on mine for a while too ;) [07:44] slangasek: no, just that we can't get consistent test run results due to problems in the image, so we can't release anything autopilot-related until they clear up (which they should, soon) [07:45] ah, ok [07:50] sil2100: ^^ hi, you probably want to be aware of this - I'm splitting the autopilot-qt package so we can get qt4 off the images; this should be a complete no-op, but just in case it isn't [08:11] slangasek: ACK! :) [08:17] yay for no more Qt4 on the images, I noticed it at some point [08:30] trainguards: hi, could I get silo 17 upgraded to a 'full' not for testing silo? alecu's silo has landed now (and I've merged from his trunk) [08:37] davmor2: brendand looks like both my devel and devel-proposed phones are unable to connect, so yeah you might be right, a giffgaff change somewhere. My iphone (also giffgaff) can connect fine. [08:37] popey, didn't you configure the ap on the iphone manually? [08:37] pete-woods, there's no such distinction, you just drop the comment and talk to others that have the component in their silo [08:38] pete-woods, plus you rebuild the components of course [08:39] popey: try checking online what the 3g setting should be and then have a look at /usr/share/ofono/scripts/list-modems & list-contexts and see if they match [08:42] hi [08:43] not sure who's the current vanguard [08:46] mhr3: okay, cool. well I've already done the rebuild [08:46] just need to ping the right people [08:59] i have a silo which may need some manual care: 013 === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss [09:14] Mirv: it is so cool that you are back and I can ask for silo even from you :) [09:14] popey, what did you edit to get it to work? [09:18] brendand: bug 1352247 cc davmor2 sil2100 [09:18] bug 1352247 in ofono (Ubuntu) "3g stopped working on giffgaff (o2) on mako" [Undecided,New] https://launchpad.net/bugs/1352247 [09:23] popey: a change to oFono's Access Point provisioning landed ca. two weeks ago https://code.launchpad.net/~phablet-team/ofono/mbpi-nettime-plus-oem-fixes , would that roughly fit the timeframe of your observations? Usually oFono does not re-provision (even on reboot) until the SIM card has changed. [09:24] but I did change the sim [09:25] and it didnt reprovision correctly [09:26] although I changed the sim for another on the same network, it was a sim change nonetheless [09:26] popey: could indeed be fallout from that change, I'll comment in the bug soon [09:28] bzoltan: :D [09:29] bzoltan: landing-005 [09:30] piiramar: thanks [09:34] Mirv: hi, can i ask for help for 2 of my silos? [09:35] Mirv: i have both 11 and 13 which are stuck in publishing [09:35] the packages wee validated, but publication failed because some branches didn't have the approve flag on the merge [09:42] dbarth_: I published 11, but 13 is not marked as tested yet? also the build has seemingly been aborted for that one. [09:42] trainguards, could someone reconfigure silo 10 for me? [09:42] tvoss: sure :) [09:44] dbarth_: I ran watch_only build for 13 so that its status would be correct, but it seems the silo status is cleared/empty or something [09:45] dbarth_: I'm afraid you may need to rebuild landing-013 since the build does not recognize there would have been packages built in there, but sil2100 might know better (seems similar to the issues there were before my vac) [09:46] That wasn't a watch-only build. [09:46] sil2100, could use some help: https://ci-train.ubuntu.com/job/landing-010-1-build/79/console [09:46] https://ci-train.ubuntu.com/job/landing-013-1-build/93/parameters/ [09:46] dbarth_: ^- [09:48] tvoss: yeah, so you'll have to upload the qtmir-gles package with qtmir as well :) rsalveti and Saviq have some well known easy method of doing that [09:49] tvoss, you need a merge like this one https://code.launchpad.net/~saviq/qtmir/gles-sync-20140716/+merge/227000 [09:52] Mirv, cjwatson: thanks! [09:56] Saviq, thanks. So we would only need the changelog entry, right? [09:57] tvoss, the watch change as well [09:57] tvoss, it needs to point at the correct silo [09:57] Saviq, ah okay [10:02] Saviq, dednick https://code.launchpad.net/~thomas-voss/qtmir/gles-sync-20140804/+merge/229424 [10:04] tvoss: targetting lp:qtmir ? [10:04] dednick, just resubmitted [10:06] sil2100, could you reconfigure silo10 again? [10:06] sil2100, just added the gles twin [10:09] sil2100, i get all the same failures locally as in ci [10:09] tvoss, you did something wrong [10:09] Conflict adding file debian. Moved existing file to debian.moved. [10:10] 2 === renamed directory 'debian' => 'debian.moved' [10:10] Saviq, already resubmitted [10:10] tvoss, ah k [10:10] Saviq, https://code.launchpad.net/~thomas-voss/qtmir/gles-sync-20140804/+merge/229425 [10:10] tvoss, that's wrong [10:10] tvoss, the version in changelog needs to be the same as you got in silo [10:11] tvoss, it builds from the tarball built from the main (non -gles) package, so versions need to be the same [10:11] Saviq, okay ... so how do I get the silo version? need to explicitly set that for the qtmir mp? [10:11] tvoss, you build it in silp [10:11] silo [10:11] tvoss, only then you build qtmir-gles [10:12] tvoss, you need the non-gles package to be built first [10:12] Saviq, ah, but I still need the silo to be reconfigured now [10:12] tvoss, it can be reconfigured whenever [10:12] tvoss, if you didn't have qtmir there yet, then yes [10:13] tvoss, and then just build qtmir alone, update the qtmir-gles MP and then build that one [10:13] Saviq, ack [10:16] tvoss: ok, reconfiguring [10:22] sil2100, if someone could file a bug in address-book-app that would be a good idea [10:23] brendand: ok, thanks! I'll try doing that, and if not I'll just directly poke Bill or someone from the telephony team [10:24] hmmm [10:24] I might have to modify the twin check a little bit [10:30] sil2100, is that for: https://ci-train.ubuntu.com/job/landing-010-1-build/80/console [10:30] ? [10:31] tvoss: yeah, I guess Saviq is simply overriding the error for now when using this method he told you to use [10:31] Saviq: you're normally overriding the error, right? ^ [10:31] Saviq, tvoss: I'll modify it to take the source package name, not the name of the branch [10:31] Saviq, ack [10:32] sil2100, we didn't need twins for build until now, so yeah, we'll be overriding it [10:32] I'll change it so that it won't be needed in a moment [10:42] Mirv, o/ [10:42] Mirv, re bug #1349705 if you can just take the patch with you to the upload you're preparing [10:42] bug 1349705 in qtdeclarative-opensource-src (Ubuntu) "[PATCH] Flickable gets confused when there's other flickables on top" [Undecided,In progress] https://launchpad.net/bugs/1349705 [10:42] Mirv, no point it being in a rather unrelated silo... [10:46] is the x86 emulator terminally broken at this point? [10:47] Saviq: o/ oh, ok, I was thinking it was tightly bound to the rest of the landing. what's the ETA for landing-007? if you're already being testing the silo with your changes, then it'd be still maybe better to release it first. I can actually even prepare the next upload in another silo at the same time, just taking the changelog entry. [10:48] Mirv, no, we're still fixing two issues on the silo [10:50] Saviq: ok, I'll prepare 'ubuntu8' in another silo instead of 'ubuntu9', with the idea that 007's ubuntu8 won't be landing. [10:51] Mirv, yup, I'll scrap it from that silo already [10:51] thanks [10:52] Mirv, can you please del the package from silo 7 then? already reconfiguring [10:52] Mirv, oh actually looks like recon deals with that now :) [10:52] Mirv, so done [10:53] Saviq: yes it does :) [10:53] sil2100: just an update.. as you might have seen the reruns on different devices came back with most of the failed tests passing. [10:53] now digging why they failed in that one device [10:56] dbarth_: back to the 013, cjwatson commented on the earlier aborted build run by you that wasn't a watch only build (maybe it was the one that cleared data), so the issue with the silo is not resolved as a watch only build gives no packages https://ci-train.ubuntu.com/job/landing-013-1-build/94/console === MacSlow is now known as MacSlow|lunch [11:02] Mirv: probably needs a full rebuild at this point [11:17] sil2100: question for you sir, can you top-approve a system settings merge? [11:17] Chipaca: hello! I think I could, show me teh merge [11:18] sil2100: https://code.launchpad.net/~ralsina/ubuntu-system-settings/notification-plugin/+merge/227344 [11:18] sil2100: it's related to https://code.launchpad.net/~chipaca/gsettings-ubuntu-touch-schemas/just-the-touch-settings/+merge/228317 [11:19] sil2100: where we addressed all of seb's concerns [11:19] Oh my god, that's a big merge [11:19] Chipaca: could we get someone to review the current version of the branch? [11:20] sigh [11:20] sil2100: yes, yes we could. [11:22] sil2100: asking mardy. Could you check if there's anything further needed to land silo #6? [11:27] sil2100: did you just add the comment about schema changes still being discussed, or did I only just notice it? [11:32] Chipaca: I didn't add it, I just saw it a few moments ago [11:32] I thought it's a known thing [11:32] Maybe seb added it? [11:33] sil2100: nah, if it's older, that's fine [12:21] brb, lunch [12:24] dbarth__: landing-013 has now rebuilt (no change rebuilds), and would need at least quick rechecking that it's still good for publishing. set testing to yes for it when ready. === MacSlow|lunch is now known as MacSlow [12:31] ogra_: sil2100: for the apparmor denials related failures during the first run on smoke, i ran gallery_app test on the same failed device again a couple of times [12:31] and the issue is not reproducible [12:31] oh my [12:32] I dont see much difference in the old failed syslog: http://paste.ubuntu.com/7951407/ [12:32] and the new passed one: http://paste.ubuntu.com/7951406/ [12:33] i mean not any obvious differences. except on the failed one, i do not see this dbus message: "Successfully activated service 'org.freedesktop.hostname1' is not in the failed job" === pete-woods is now known as pete-woods|lunch [13:13] sil2100: so I've landed the autopilot-qt package split in the archive; are you ok for me to update the seed at the same time, to drop the qt4 stuff? [13:14] slangasek: feel free do to that, we don't have any promotion candidate right now so no need to build anything before [13:15] slangasek: so please update the seed, we can kick an image once that's done to make sure everything is ok [13:15] sil2100: ok, uploading - and that was my next question. Thanks === tedg` is now known as tedg === dobey_ is now known as dobey [13:17] Mirv: ack [13:36] cjwatson: would it be possible to get this MR to the click package? https://code.launchpad.net/~bzoltan/click/extend_1410_fw/+merge/227675 [13:41] bzoltan1: ^l.83 on that seems to be a duplicate [13:41] bzoltan2: ^l.83 on that seems to be a duplicate [13:41] https://code.launchpad.net/~bzoltan/click/extend_1410_fw/+merge/227675 [13:45] sil2100: can you find someone to assign bug 1351024 to? [13:45] bug 1351024 in Ubuntu Calendar App "Date & Time picker is not working on device." [Critical,Triaged] https://launchpad.net/bugs/1351024 [13:59] popey: let me try that... [14:04] jdstrand: hey! We have some new issues related to apparmor, a re-run made them go away - but the syslog for many of the tests included a lot of denials during autopilot tests [14:05] jdstrand: https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/643/artifact/clientlogs/ubuntu_calculator_app/syslog/*view*/ <- for instance the syslog here has most of them [14:09] jdstrand, i really think there is something systemic broken and apparmor is just the fallout [14:09] sil2100: Aug 4 05:04:04 ubuntu-phablet dbus[1462]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/com/canonical/Autopilot/Introspection" interface="com.canonical.Autopilot.Introspection" member="GetVersion" name=":1.98" mask="receive" pid=6298 profile="com.ubuntu.calculator_calculator_1.3.291" peer_pid=3516 peer_profile="unconfined" [14:09] that is the same thing we discussed last week [14:09] didnt you fix that too ? [14:09] no [14:09] that is something in the ci infrastructure [14:10] plars and I looked at it, but couldn't see what the issue was [14:10] what I suggested was to add a test to see if the rules were applied, and abort [14:10] so it is clear what happened [14:11] jdstrand: I haven't gotten a chance to hook in that extra check just yet, but I don't see how this can happen really [14:11] then I suggested to add instrumentation to the CI infrastructure to see why the rules weren't applied. I suggested two places to add the above check/abort wich might help see what is happening [14:11] Oh [14:11] Ok, so this is the same as last week [14:11] sil2100: yes [14:12] plars: right, me either. it is a bit of a mystery atm with the available information [14:14] plars: it is entirely possible that the rules got applied and then unapplied at some later point (which is why I suggested to checks-- one immediately after the aa-clickhook --include... to see if there is a bug in aa-clickhook, and one just before the tests are run to see if the rules got unapplied in between aa-clickhook and the test start) [14:14] s/to checks/two checks/ [14:14] 'phablet-config autopilot --dbus-probe enable' runs (and appears to exit normally) every time we run a test, and should set up all the aa-clickhook stuff [14:14] yep [14:15] jdstrand: from that point, the very next thing that appears to actually do anything, is phablet-test-run [14:15] I compared the two logs-- there is nothing significantly different. need to have more debugging info [14:15] it secretly turned into a toggle :) [14:15] everey second time you run it it unapplies ;) [14:15] j/k [14:16] ogra_: we thought of that actually :) [14:16] I suspect something may be triggering an aa-clickhook, which would unapply the rules [14:16] heh [14:16] jdstrand: if that's the case, it would almost have to be in the test itself [14:16] which doesn't make any sense [14:17] if the test is installing a click, that would do it [14:18] we could ask someone in QA to be sure, but I seriously doubt ubuntu_calculator_app is installing a click package [14:18] jdstrand: is there anything else other than just running the check that would yield more debug data too while I'm at it? === pete-woods|lunch is now known as pete-woods [14:21] jdstrand: also, another question: if running 'aa-clickhook -f --include=/usr/share/autopilot-touch/apparmor/click.rules' ran into some problem, would it fail silently? or would it print something and exit with status? [14:21] plars: I really think aa-clickhook is being run without arguments after it is being run with --include. you could move /usr/bin/aa-clickhook to /usr/bin/aa-clickhook.orig, then create a /usr/bin/aa-clickhook shellscript that logs the timestamp and arguments called, then calls aa-clickhook with those args === oSoMoN_ is now known as oSoMoN [14:22] jdstrand: ahh, hang on [14:22] plars: that shell script could also redirect aa-clickhook output to the logfile for your last question [14:22] jdstrand: I suspect it's possible that aa-clickhook is giving some error and phablet-config could be swallowing it [14:22] def shell(self, command, ignore_errors=True) [14:22] oh [14:22] interesting [14:22] aa-clickhook should fail with error or traceback [14:22] the default is to ignore errors, and that's not getting overridden in phablet-config [14:22] if it isn't, I think that would be a bug [14:23] I would think we should still see anything it prints though [14:23] would that include a traceback on stderr? [14:23] it does print a warning on stderr in the normal case [14:24] the normal case of using --include that is [14:24] it will error out if the --include doesn't exist, if it does, it prints a warning: [14:25] warn("--include specified, including '%s' in all profiles" % include) [14:25] jdstrand: all this is coming over adb, so it's having to do some tricks to get the return code and determine if it passed or failed, but stderr vs. stdout should be a problem [14:25] oh [14:25] I don't see that [14:25] I didn't see any output from phablet-config when it ran that [14:25] let me play with it some more today and see what I can find out [14:26] cool, thanks [14:31] jdstrand: so, phablet-config is, indeed eating all output from that command [14:31] bzoltan: OK, I'll look at that along with the click deployment I'll need to do this week for signing. Perhaps you could remove the duplicated line 83 that t1mp pointed out and save me doing it by hand (since that renders the file syntactically invalid, I think, so can't have passed tests ...) [14:31] and ignoring failures [14:32] sil2100: hm, did you consider renaming that to ubuntu-rtm/landing-000 as I suggested by mail? [14:32] cjwatson: sure, this is all temporary for testing, I don't want to change it now as it would require rebuilding [14:32] ok [14:33] cjwatson: so for now it's on the old naming scheme [14:33] cjwatson: but no worries, it doesn't force anything on the PPA naming [14:35] sil2100: hm, not seeing an upload corresponding to that queuebot message [14:36] where are the jenkins jobs? [14:36] oh, https://ci-train.ubuntu.com/job/landing-000-2-publish/, huh, no separate jobs for RTM? [14:36] Let me check what could have happened [14:36] It's that for now, I'm using the preprod jobs for now [14:37] Only the name is the same, the silo itself is landing-000.rtm [14:37] plars: oh! [14:37] cjwatson: OK, done. The last addition (UITK docs) is specially important, because I just changed the SDK to show the API docs of the currently selected target fw and not the local one... what is an old crap on LTS [14:37] sil2100: I bet snakefruit tries to do the copy on production [14:37] plars: it is possible that is enough debugging, however those extra checks may still be worthwhile [14:37] unless you've taken steps there ... [14:38] jdstrand: agree [14:38] * jdstrand hates intermittent failures [14:38] jdstrand: going to try to see if I can reproduce them here [14:38] sil2100: I think copy2distro probably needs work [14:39] Right, hm, I must say that I wasn't sure if copy2distro is used at all [14:39] jdstrand: at the very least I'll have it do that check and put up some big warnings - it seems like it already generates quite a bit of failures [14:39] sil2100: http://paste.ubuntu.com/7952411/ [14:39] not sure if that's checked in [14:39] Oh! [14:40] So it's used on snakefriut then [14:40] yup [14:40] plars: ok, cool [14:40] hm, ok, then it's a problem, I'll have to change it in such a way that it won't break the current train usage [14:40] sil2100: you'd probably need to have the rsynced control file say which LP instance to use [14:40] sil2100: and default to production [14:41] cjwatson: thanks for the code snippet, now at least I know how it's being called === pete-woods is now known as pete-woods|at-do [14:56] sil2100: can I have a silo for line 36 ? [14:57] sil2100: Mirv: I need a silo to land a critical bugfix of the QtC plugin [14:58] bzoltan, oSoMoN: assigning! [14:58] sil2100: thanks a lot [15:00] sil2100, thanks! === plars changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | CI Train support: trainguards | Vanguard (general help): plars | CI Train Status: #157 promoted | CI Train Dashboard: http://bit.ly/1mDv1FS | Known issues: - [15:15] could i plz have a landing for silo 6? [15:18] slangasek: btw. did the seed change land? === gatox is now known as gatox_lunch [15:18] slangasek: if yes, I'll kick a new image then (due to all this I forgot about it) [15:21] cjwatson: do you know if snakefruit is using anything else from cu2d than copy2distro? [15:22] sil2100: that's all I know of [15:24] Since temporarily we'll have to switch it to use the RTM development branch then, in a moment [15:26] sil2100: Uh, why switch? [15:26] Shouldn't it gain the ability to do either? [15:27] rolling builder downtime for launchpad-buildd upgrades [15:32] cjwatson: by this I mean snakefruit will have to use a different branch for cupstream2distro than lp:cupstream2distro, as to get this working for ubuntu-rtm I need many changes from this branch which are not safe for production [15:32] sil2100: if you were looking to package silo 6, hold it, fixing something that just came up [15:33] sil2100: oh, uh, we could add a separate checkout and a separate copy of run.sh, and run both [15:33] * Chipaca wonders where the +x bit got lost [15:33] sil2100: if they were looking at different incoming directories [15:33] sil2100: but if the same branch can do both safely, I guess that would be fine === oSoMoN_ is now known as oSoMoN [15:35] The cu2d-rtm branch should be able to do both old and new copy2distro safely, but only the other parts are not safe (which are not used on snakefruit) [15:36] sil2100: OK, I can certainly switch it, just give me a URL when you're ready [15:37] Let me redeploy it in ci-train first maybe === oSoMoN_ is now known as oSoMoN === pete-woods|at-do is now known as pete-woods [15:42] * ogra_ glares at his inbox and wonders why he got two acceptance mails for the last lxc-android-config upload [15:43] trainguards: hey guys. just wanted to check if there was anything else I needed to do to get silo 17 landed? if I just need be more patient, that's fine! :) [15:43] hmm [15:43] and the second one has an empty changelog [15:47] pete-woods: all is fine :) We'll land it as soon as the image that I just kicked fetches all packages [15:47] cool, if I just need to wait for build to finish then great! :) [15:48] sil2100, did you consider building an image for slangasek's changes ? (though i would like to have my recent lxc-android-config changes in too) [15:48] ogra_: yeah, it's building now [15:48] bah :( [15:48] ok [15:48] ogra_: is it too early? :< [15:49] i would have liked the fixes yeah, so a certain device doesnt drain its battery over night :) [15:49] Oh oh! [15:49] but well, next will do (have to) then [15:51] cjwatson: anyway, I guess could you temporarily use lp:~sil2100/cupstream2distro/cu2d-rtm as the cupstream2distro source on snakefruit? [15:53] We had guests here at home and I hope I didn't make any mistakes [15:53] Love all those distractions [15:55] === trainguard: IMAGE 170 building (started: 20140804 15:55) === [15:56] sil2100: Sorry folks :) I keep you busy. The UITK could use a silo ^ [15:56] sil2100: an dthe QtC in sil11 is good to go [15:56] bzoltan: please approve branches for QtC ;) And I'll try assigning a silo for you [16:00] xnox: ping [16:01] sil2100: yes, seed change landed, thanks for having kicked off the image [16:01] Chipaca: hey! [16:02] xnox: hiya! [16:02] xnox: so, is the dbus machine id usable? [16:02] cjwatson: just give me a sign once the branch is on snakefruit, I'll re run the publish job then [16:02] Chipaca: yes. [16:02] xnox: it wasn't on the image itself? [16:02] Chipaca: no, it is not. [16:03] xnox: what is it on? [16:03] sil2100: done [16:03] cjwatson: thanks! [16:03] Chipaca: it's generated first boot / first time dbus is started. [16:03] bzoltan: buildd upgrades in progress, so might take a while [16:03] Chipaca: and saved. [16:03] (since I know you tend to notice such things) [16:03] xnox: on the phone? [16:03] Chipaca: yes. === gatox_lunch is now known as gatox [16:04] Chipaca: /var/lib/dbus/machine-id -> on all platforms. [16:04] ++ [16:04] xnox: ah! not /etc/machine-id ? [16:04] cjwatson: :) === oSoMoN_ is now known as oSoMoN [16:04] Chipaca: no, not /etc/machine-id, that one is broken on ubuntu at the moment. [16:04] ah, ok [16:04] goed [16:04] Chipaca: as in, it's unique per batch of install media =))))) [16:05] yeah [16:05] good enough [16:05] everybody on the team should know everybody else's emails by heart already anyway [16:05] Chipaca: nah, uterly pointless =) [16:06] xnox: sorry, i forgot to include the sarcasm signs. Consider them sprinkled over all of the above from 'yeah' on down. [16:12] sil2100: sorry! I top approved the MR === Ursinha is now known as Ursinha-afk [16:20] yes. yes you can. [16:20] sil2100, can silo 5 be published, please? [16:21] oSoMoN: sure! We just finished the meeting, publishing [16:21] sil2100, thanks! === boiko_ is now known as boiko [16:27] sil2100: can silo 6 be published, please? [16:33] Chipaca: sure thing :) [16:34] whee :) [16:35] Chipaca: all +1ed, approved and accepted by the overall community ;p? [16:35] sil2100: yep [16:36] sil2100: 1 sec, let me get you a link [16:36] sil2100: https://code.launchpad.net/~chipaca/gsettings-ubuntu-touch-schemas/just-the-touch-settings/+merge/228317/comments/556372 [16:37] that includes both seb's "ok, let's do this thing", and laney's parting "beware" [16:37] ominous :) [16:43] Chipaca: ok, last one thing - do you know why mediumtests are failing for the system-settings branch all the time? [16:43] Is that normal? [16:43] sil2100: I don't know, no [16:43] sil2100: it's not even all the time, is it? [16:44] Chipaca: I don't know, but I saw at least the last 2 CI runs failing there [16:44] sil2100: can you poke jenkins to do them again? [16:45] i can't, otherwise i would've [16:45] Chipaca: from what I'm seeing from the test failure logs, all cellular tests are failing, hmmm [16:46] https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-utopic/1954/testReport/ <- is this normal? [16:47] sil2100: i don't know [16:47] Chipaca: let me just poke someone from system settings about that to make sure all is ok [16:51] Chipaca: let me re-run the CI tests again [16:55] sil2100, CI runs have been inconsistent, not sure if kenvandine ever learned anything about it === alan_g is now known as alan_g|EOD === plars changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | CI Train support: trainguards | Vanguard (general help): cihelp | CI Train Status: #157 promoted | CI Train Dashboard: http://bit.ly/1mDv1FS | Known issues: - === retoad changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | CI Train support: trainguards | Vanguard (general help): retoaded | CI Train Status: #157 promoted | CI Train Dashboard: http://bit.ly/1mDv1FS | Known issues: - [17:10] * ogra_ wonders why slangasek only changed the seeds for x86 based arches [17:11] sil2100: would you please reconfigure the silo16, i have added there the -gles package [17:14] rsalveti: I put the MR for the UITK gles -> https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/sync_landing_0804/+merge/229494 [17:26] bzoltan: sure thing, one moment :) [17:28] bzoltan: reconfiguring [17:28] sil2100: mmm robru is out, sorry to pester... i got a build that seems stuck on armhf [17:28] https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+build/6239627 [17:30] kgunn: hmm... powerpc also seems stuck [17:30] sil2100: thanks [17:31] cjwatson: ^ do you know by any chance why it's taking so long to pick up the armhf/powerpc builds? [17:51] sil2100: you'll be pleased to see someone has made a nice 3rd party note taking app which should be published in the store soon. It looks really nice. [17:52] popey: wow.... I want that tooo [17:53] published, look for "quickmemo" [17:54] * ogra_ wonders what happened to the image build ... === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [18:17] sil2100, hmm, looks to me like there was no image build triggered at all [18:17] ogra_: the bot reacted, didn't it? [18:17] yeah, it definitely did [18:17] but i dont see a new rootfs on cdimage.u.c [18:17] which should be there by now [18:17] hmmm [18:18] last one is from 2:56 UTC this morning [18:19] cjwatson, err ... https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/utopic/ubuntu-touch/+build/3271 [18:19] "Start in 7 hours" [18:19] "Started 2 hours ago" [18:20] oh my === retoad changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | CI Train support: trainguards | Vanguard (general help): cihelp | CI Train Status: #157 promoted | CI Train Dashboard: http://bit.ly/1mDv1FS | Known issues: - [18:21] bzoltan: looks fine [18:22] there are only 2 armhf builders up according to LP [18:22] ugh === Ursinha-afk is now known as Ursinha [18:23] well,i have no clue how to bump the score (or if that would help at all) [18:30] sil2100, so that looks like we wont have any images til someone sorts this [18:30] uh [18:31] https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/utopic/ubuntu-touch is the LP rootfs build page btw [18:31] 17:27 < cjwatson> rolling builder downtime for launchpad-buildd upgrades <- can this be related? [18:31] oh, yeah ! [18:31] Not sure what Colin had in mind here [18:32] well, you made me look at the backlog :) [18:32] looks like we just badly hit the maintenance window [18:33] sadly the emulator image got even more out of sync now [18:33] since i386 could build before that started [18:33] let's just do a few armhf only builds [18:33] one every day [18:33] until it's in sync [18:34]