[06:49] <slangasek> thomi: hi there
[06:52] <slangasek> 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] <slangasek> thomi: to make sure that I'm shipping the right filenames to match the way it's being invoked
[07:00] <slangasek> 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] <sil2100> Mirv: Timo! You're back! :)
[07:11] <thomi> slangasek: I'm not really here, but that sounds about right
[07:12] <slangasek> ok
[07:12] <slangasek> 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] <thomi> slangasek: I can take a look in a bit
[07:13] <slangasek> thomi: ok
[07:16] <slangasek> thomi: unrelated, why does libautopilot-qt-autopilot have a hard-coded dependency on the obsolete python-support?
[07:22] <Mirv> sil2100: hey! and yes! :)
[07:22] <Mirv> sil2100: I've just read through all your status reports among else, very helpful
[07:23] <thomi> slangasek: veebers is the person to talk to about that. I'm not sure, I can take a look tomorrow
[07:24] <slangasek> thomi: ok.  It seems to have been part of the packaging since mzanetti first added the libautopilot-qt-autopilot packages
[07:25] <thomi> slangasek: we can probably remove that dep
[07:31] <thomi> slangasek: you don't have a problem shipping shared libs in a package that doesn't start with 'lib' ?
[07:32] <slangasek> thomi: they're not really shared libs, they're all plugins
[07:33] <slangasek> thomi: it would be just fine to build these without any SONAME at all
[07:33] <thomi> slangasek: OK, LGTM
[07:34] <slangasek> thomi: ok, cool
[07:34] <slangasek> thomi: should I upload direct to the archive, or do you want this in a silo?
[07:34] <thomi> slangasek: Given that we can't release anything at the moment, uploading it directly might be the best thing
[07:35] <thomi> 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] <slangasek> thomi: if I upload it directly, I can pester the archive admins to review it in the queue
[07:43] <slangasek> thomi: the MP review request was because silos buggily bypass the NEW queue
[07:43] <thomi> ok, cool - I'll top-approve it now then
[07:43] <slangasek> thomi: great, thanks :)
[07:44] <slangasek> thomi: now, what's this about being unable to release things at the moment?  TRAINCON-0?
[07:44] <thomi> no worries - thanks for sorting that out for us - it's been on my TODO list for a while
[07:44] <slangasek> yes, it's been on mine for a while too ;)
[07:44] <thomi> 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] <slangasek> ah, ok
[07:50] <slangasek> 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] <sil2100> slangasek: ACK! :)
[08:17] <Mirv> yay for no more Qt4 on the images, I noticed it at some point
[08:30] <pete-woods> 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] <popey> 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] <brendand> popey, didn't you configure the ap on the iphone manually?
[08:37] <mhr3> 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] <mhr3> pete-woods, plus you rebuild the components of course
[08:39] <davmor2> 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] <dbarth_> hi
[08:43] <dbarth_> not sure who's the current vanguard
[08:46] <pete-woods> mhr3: okay, cool. well I've already done the rebuild
[08:46] <pete-woods> just need to ping the right people
[08:59] <dbarth_> i have a silo which may need some manual care: 013
[09:14] <bzoltan> Mirv:  it is so cool that you are back and I can ask for silo even from you :)
[09:14] <brendand> popey, what did you edit to get it to work?
[09:18] <popey> brendand: bug 1352247  cc davmor2 sil2100
[09:23] <piiramar> 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] <popey> but I did change the sim
[09:25] <popey> and it didnt reprovision correctly
[09:26] <popey> although I changed the sim for another on the same network, it was a sim change nonetheless
[09:26] <piiramar> popey: could indeed be fallout from that change, I'll comment in the bug soon
[09:28] <Mirv> bzoltan: :D
[09:29] <Mirv> bzoltan: landing-005
[09:30] <popey> piiramar: thanks
[09:34] <dbarth_> Mirv: hi, can i ask for help for 2 of my silos?
[09:35] <dbarth_> Mirv: i have both 11 and 13 which are stuck in publishing
[09:35] <dbarth_> the packages wee validated, but publication failed because some branches didn't have the approve flag on the merge
[09:42] <Mirv> dbarth_: I published 11, but 13 is not marked as tested yet? also the build has seemingly been aborted for that one.
[09:42] <tvoss> trainguards, could someone reconfigure silo 10 for me?
[09:42] <sil2100> tvoss: sure :)
[09:44] <Mirv> 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] <Mirv> 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] <cjwatson> That wasn't a watch-only build.
[09:46] <tvoss> sil2100, could use some help: https://ci-train.ubuntu.com/job/landing-010-1-build/79/console
[09:46] <cjwatson> https://ci-train.ubuntu.com/job/landing-013-1-build/93/parameters/
[09:46] <cjwatson> dbarth_: ^-
[09:48] <sil2100> 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] <Saviq> tvoss, you need a merge like this one https://code.launchpad.net/~saviq/qtmir/gles-sync-20140716/+merge/227000
[09:52] <dbarth_> Mirv, cjwatson: thanks!
[09:56] <tvoss> Saviq, thanks. So we would only need the changelog entry, right?
[09:57] <Saviq> tvoss, the watch change as well
[09:57] <Saviq> tvoss, it needs to point at the correct silo
[09:57] <tvoss> Saviq, ah okay
[10:02] <tvoss> Saviq, dednick https://code.launchpad.net/~thomas-voss/qtmir/gles-sync-20140804/+merge/229424
[10:04] <dednick> tvoss: targetting lp:qtmir ?
[10:04] <tvoss> dednick, just resubmitted
[10:06] <tvoss> sil2100, could you reconfigure silo10 again?
[10:06] <tvoss> sil2100, just added the gles twin
[10:09] <brendand> sil2100, i get all the same failures locally as in ci
[10:09] <Saviq> tvoss, you did something wrong
[10:09] <Saviq> Conflict adding file debian.  Moved existing file to debian.moved.
[10:10] <Saviq> 2	[10:10] <tvoss> Saviq, already resubmitted
[10:10] <Saviq> tvoss, ah k
[10:10] <tvoss> Saviq, https://code.launchpad.net/~thomas-voss/qtmir/gles-sync-20140804/+merge/229425
[10:10] <Saviq> tvoss, that's wrong
[10:10] <Saviq> tvoss, the version in changelog needs to be the same as you got in silo
[10:11] <Saviq> tvoss, it builds from the tarball built from the main (non -gles) package, so versions need to be the same
[10:11] <tvoss> Saviq, okay ... so how do I get the silo version? need to explicitly set that for the qtmir mp?
[10:11] <Saviq> tvoss, you build it in silp
[10:11] <Saviq> silo
[10:11] <Saviq> tvoss, only then you build qtmir-gles
[10:12] <Saviq> tvoss, you need the non-gles package to be built first
[10:12] <tvoss> Saviq, ah, but I still need the silo to be reconfigured now
[10:12] <Saviq> tvoss, it can be reconfigured whenever
[10:12] <Saviq> tvoss, if you didn't have qtmir there yet, then yes
[10:13] <Saviq> tvoss, and then just build qtmir alone, update the qtmir-gles MP and then build that one
[10:13] <tvoss> Saviq, ack
[10:16] <sil2100> tvoss: ok, reconfiguring
[10:22] <brendand> sil2100, if someone could file a bug in address-book-app that would be a good idea
[10:23] <sil2100> 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] <sil2100> hmmm
[10:24] <sil2100> I might have to modify the twin check a little bit
[10:30] <tvoss> sil2100, is that for: https://ci-train.ubuntu.com/job/landing-010-1-build/80/console
[10:30] <tvoss> ?
[10:31] <sil2100> tvoss: yeah, I guess Saviq is simply overriding the error for now when using this method he told you to use
[10:31] <sil2100> Saviq: you're normally overriding the error, right? ^
[10:31] <sil2100> Saviq, tvoss: I'll modify it to take the source package name, not the name of the branch
[10:31] <tvoss> Saviq, ack
[10:32] <Saviq> sil2100, we didn't need twins for build until now, so yeah, we'll be overriding it
[10:32] <sil2100> I'll change it so that it won't be needed in a moment
[10:42] <Saviq> Mirv, o/
[10:42] <Saviq> Mirv, re bug #1349705 if you can just take the patch with you to the upload you're preparing
[10:42] <Saviq> Mirv, no point it being in a rather unrelated silo...
[10:46] <Chipaca> is the x86 emulator terminally broken at this point?
[10:47] <Mirv> 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] <Saviq> Mirv, no, we're still fixing two issues on the silo
[10:50] <Mirv> 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] <Saviq> Mirv, yup, I'll scrap it from that silo already
[10:51] <Mirv> thanks
[10:52] <Saviq> Mirv, can you please del the package from silo 7 then? already reconfiguring
[10:52] <Saviq> Mirv, oh actually looks like recon deals with that now :)
[10:52] <Saviq> Mirv, so done
[10:53] <Mirv> Saviq: yes it does :)
[10:53] <psivaa> 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] <psivaa> now digging why they failed in that one device
[10:56] <Mirv> 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
[11:02] <cjwatson> Mirv: probably needs a full rebuild at this point
[11:17] <Chipaca> sil2100: question for you sir, can you top-approve a system settings merge?
[11:17] <sil2100> Chipaca: hello! I think I could, show me teh merge
[11:18] <Chipaca> sil2100: https://code.launchpad.net/~ralsina/ubuntu-system-settings/notification-plugin/+merge/227344
[11:18] <Chipaca> sil2100: it's related to https://code.launchpad.net/~chipaca/gsettings-ubuntu-touch-schemas/just-the-touch-settings/+merge/228317
[11:19] <Chipaca> sil2100: where we addressed all of seb's concerns
[11:19] <sil2100> Oh my god, that's a big merge
[11:19] <sil2100> Chipaca: could we get someone to review the current version of the branch?
[11:20] <Chipaca> sigh
[11:20] <Chipaca> sil2100: yes, yes we could.
[11:22] <Chipaca> sil2100: asking mardy. Could you check if there's anything further needed to land silo #6?
[11:27] <Chipaca> sil2100: did you just add the comment about schema changes still being discussed, or did I only just notice it?
[11:32] <sil2100> Chipaca: I didn't add it, I just saw it a few moments ago
[11:32] <sil2100> I thought it's a known thing
[11:32] <sil2100> Maybe seb added it?
[11:33] <Chipaca> sil2100: nah, if it's older, that's fine
[12:21] <sil2100> brb, lunch
[12:24] <Mirv> 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.
[12:31] <psivaa> 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] <psivaa> and the issue is not reproducible
[12:31] <ogra_> oh my
[12:32] <psivaa> I dont see much difference in the old failed syslog: http://paste.ubuntu.com/7951407/
[12:32] <psivaa> and the new passed one: http://paste.ubuntu.com/7951406/
[12:33] <psivaa> 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"
[13:13] <slangasek> 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] <sil2100> slangasek: feel free do to that, we don't have any promotion candidate right now so no need to build anything before
[13:15] <sil2100> slangasek: so please update the seed, we can kick an image once that's done to make sure everything is ok
[13:15] <slangasek> sil2100: ok, uploading - and that was my next question.  Thanks
[13:17] <dbarth__> Mirv: ack
[13:36] <bzoltan1> 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] <t1mp> bzoltan1: ^l.83 on that seems to be a duplicate
[13:41] <t1mp> bzoltan2: ^l.83 on that seems to be a duplicate
[13:41] <t1mp> https://code.launchpad.net/~bzoltan/click/extend_1410_fw/+merge/227675
[13:45] <popey> sil2100: can you find someone to assign bug 1351024 to?
[13:59] <sil2100> popey: let me try that...
[14:04] <sil2100> 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] <sil2100> 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] <ogra_> jdstrand, i really think there is something systemic broken and apparmor is just the fallout
[14:09] <jdstrand> 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] <jdstrand> that is the same thing we discussed last week
[14:09] <ogra_> didnt you fix that too ?
[14:09] <jdstrand> no
[14:09] <jdstrand> that is something in the ci infrastructure
[14:10] <jdstrand> plars and I looked at it, but couldn't see what the issue was
[14:10] <jdstrand> what I suggested was to add a test to see if the rules were applied, and abort
[14:10] <jdstrand> so it is clear what happened
[14:11] <plars> 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] <jdstrand> 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] <sil2100> Oh
[14:11] <sil2100> Ok, so this is the same as last week
[14:11] <jdstrand> sil2100: yes
[14:12] <jdstrand> plars: right, me either. it is a bit of a mystery atm with the available information
[14:14] <jdstrand> 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] <jdstrand> s/to checks/two checks/
[14:14] <plars> '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] <jdstrand> yep
[14:15] <plars> jdstrand: from that point, the very next thing that appears to actually do anything, is phablet-test-run
[14:15] <jdstrand> I compared the two logs-- there is nothing significantly different. need to have more debugging info
[14:15] <ogra_> it secretly turned into a toggle :)
[14:15] <ogra_> everey second time you run it it unapplies ;)
[14:15] <ogra_> j/k
[14:16] <plars> ogra_: we thought of that actually :)
[14:16] <jdstrand> I suspect something may be triggering an aa-clickhook, which would unapply the rules
[14:16] <ogra_> heh
[14:16] <plars> jdstrand: if that's the case, it would almost have to be in the test itself
[14:16] <plars> which doesn't make any sense
[14:17] <jdstrand> if the test is installing a click, that would do it
[14:18] <plars> we could ask someone in QA to be sure, but I seriously doubt ubuntu_calculator_app is installing a click package
[14:18] <plars> jdstrand: is there anything else other than just running the check that would yield more debug data too while I'm at it?
[14:21] <plars> 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] <jdstrand> 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
[14:22] <plars> jdstrand: ahh, hang on
[14:22] <jdstrand> plars: that shell script could also redirect aa-clickhook output to the logfile for your last question
[14:22] <plars> jdstrand: I suspect it's possible that aa-clickhook is giving some error and phablet-config could be swallowing it
[14:22] <plars>  def shell(self, command, ignore_errors=True)
[14:22] <jdstrand> oh
[14:22] <jdstrand> interesting
[14:22] <jdstrand> aa-clickhook should fail with error or traceback
[14:22] <plars> the default is to ignore errors, and that's not getting overridden in phablet-config
[14:22] <jdstrand> if it isn't, I think that would be a bug
[14:23] <plars> I would think we should still see anything it prints though
[14:23] <jdstrand> would that include a traceback on stderr?
[14:23] <jdstrand> it does print a warning on stderr in the normal case
[14:24] <jdstrand> the normal case of using --include that is
[14:24] <jdstrand> it will error out if the --include doesn't exist, if it does, it prints a warning:
[14:25] <jdstrand> warn("--include specified, including '%s' in all profiles" % include)
[14:25] <plars> 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] <plars> oh
[14:25] <plars> I don't see that
[14:25] <plars> I didn't see any output from phablet-config when it ran that
[14:25] <plars> let me play with it some more today and see what I can find out
[14:26] <jdstrand> cool, thanks
[14:31] <plars> jdstrand: so, phablet-config is, indeed eating all output from that command
[14:31] <cjwatson> 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] <plars> and ignoring failures
[14:32] <cjwatson> sil2100: hm, did you consider renaming that to ubuntu-rtm/landing-000 as I suggested by mail?
[14:32] <sil2100> cjwatson: sure, this is all temporary for testing, I don't want to change it now as it would require rebuilding
[14:32] <cjwatson> ok
[14:33] <sil2100> cjwatson: so for now it's on the old naming scheme
[14:33] <sil2100> cjwatson: but no worries, it doesn't force anything on the PPA naming
[14:35] <cjwatson> sil2100: hm, not seeing an upload corresponding to that queuebot message
[14:36] <cjwatson> where are the jenkins jobs?
[14:36] <cjwatson> oh, https://ci-train.ubuntu.com/job/landing-000-2-publish/, huh, no separate jobs for RTM?
[14:36] <sil2100> Let me check what could have happened
[14:36] <sil2100> It's that for now, I'm using the preprod jobs for now
[14:37] <sil2100> Only the name is the same, the silo itself is landing-000.rtm
[14:37] <jdstrand> plars: oh!
[14:37] <bzoltan> 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] <cjwatson> sil2100: I bet snakefruit tries to do the copy on production
[14:37] <jdstrand> plars: it is possible that is enough debugging, however those extra checks may still be worthwhile
[14:37] <cjwatson> unless you've taken steps there ...
[14:38] <plars> jdstrand: agree
[14:38]  * jdstrand hates intermittent failures
[14:38] <plars> jdstrand: going to try to see if I can reproduce them here
[14:38] <cjwatson> sil2100: I think copy2distro probably needs work
[14:39] <sil2100> Right, hm, I must say that I wasn't sure if copy2distro is used at all
[14:39] <plars> 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] <cjwatson> sil2100: http://paste.ubuntu.com/7952411/
[14:39] <cjwatson> not sure if that's checked in
[14:39] <sil2100> Oh!
[14:40] <sil2100> So it's used on snakefriut then
[14:40] <cjwatson> yup
[14:40] <jdstrand> plars: ok, cool
[14:40] <sil2100> 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] <cjwatson> sil2100: you'd probably need to have the rsynced control file say which LP instance to use
[14:40] <cjwatson> sil2100: and default to production
[14:41] <sil2100> cjwatson: thanks for the code snippet, now at least I know how it's being called
[14:56] <oSoMoN> sil2100: can I have a silo for line 36 ?
[14:57] <bzoltan> sil2100: Mirv: I need a silo to land a critical bugfix of the QtC plugin
[14:58] <sil2100> bzoltan, oSoMoN: assigning!
[14:58] <bzoltan> sil2100:  thanks a lot
[15:00] <oSoMoN> sil2100, thanks!
[15:15] <Chipaca> could i plz have a landing for silo 6?
[15:18] <sil2100> slangasek: btw. did the seed change land?
[15:18] <sil2100> slangasek: if yes, I'll kick a new image then (due to all this I forgot about it)
[15:21] <sil2100> cjwatson: do you know if snakefruit is using anything else from cu2d than copy2distro?
[15:22] <cjwatson> sil2100: that's all I know of
[15:24] <sil2100> Since temporarily we'll have to switch it to use the RTM development branch then, in a moment
[15:26] <cjwatson> sil2100: Uh, why switch?
[15:26] <cjwatson> Shouldn't it gain the ability to do either?
[15:27] <cjwatson> rolling builder downtime for launchpad-buildd upgrades
[15:32] <sil2100> 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] <Chipaca> sil2100: if you were looking to package silo 6, hold it, fixing something that just came up
[15:33] <cjwatson> 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] <cjwatson> sil2100: if they were looking at different incoming directories
[15:33] <cjwatson> sil2100: but if the same branch can do both safely, I guess that would be fine
[15:35] <sil2100> 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] <cjwatson> sil2100: OK, I can certainly switch it, just give me a URL when you're ready
[15:37] <sil2100> Let me redeploy it in ci-train first maybe
[15:42]  * ogra_ glares at his inbox and wonders why he got two acceptance mails for the last lxc-android-config upload
[15:43] <pete-woods> 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] <ogra_> hmm
[15:43] <ogra_> and the second one has an empty changelog
[15:47] <sil2100> pete-woods: all is fine :) We'll land it as soon as the image that I just kicked fetches all packages
[15:47] <pete-woods> cool, if I just need to wait for build to finish then great! :)
[15:48] <ogra_> 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] <sil2100> ogra_: yeah, it's building now
[15:48] <ogra_> bah :(
[15:48] <ogra_> ok
[15:48] <sil2100> ogra_: is it too early? :<
[15:49] <ogra_> i would have liked the fixes yeah, so a certain device doesnt drain its battery over night :)
[15:49] <sil2100> Oh oh!
[15:49] <ogra_> but well, next will do (have to) then
[15:51] <sil2100> cjwatson: anyway, I guess could you temporarily use lp:~sil2100/cupstream2distro/cu2d-rtm as the cupstream2distro source on snakefruit?
[15:53] <sil2100> We had guests here at home and I hope I didn't make any mistakes
[15:53] <sil2100> Love all those distractions
[15:55] <imgbot> [15:56] <bzoltan> sil2100:  Sorry folks :) I keep you busy. The UITK could use a silo ^
[15:56] <bzoltan> sil2100:  an dthe QtC in sil11 is good to go
[15:56] <sil2100> bzoltan: please approve branches for QtC ;) And I'll try assigning a silo for you
[16:00] <Chipaca> xnox: ping
[16:01] <slangasek> sil2100: yes, seed change landed, thanks for having kicked off the image
[16:01] <xnox> Chipaca: hey!
[16:02] <Chipaca> xnox: hiya!
[16:02] <Chipaca> xnox: so, is the dbus machine id usable?
[16:02] <sil2100> cjwatson: just give me a sign once the branch is on snakefruit, I'll re run the publish job then
[16:02] <xnox> Chipaca: yes.
[16:02] <Chipaca> xnox: it wasn't on the image itself?
[16:02] <xnox> Chipaca: no, it is not.
[16:03] <Chipaca> xnox: what is it on?
[16:03] <cjwatson> sil2100: done
[16:03] <sil2100> cjwatson: thanks!
[16:03] <xnox> Chipaca: it's generated first boot / first time dbus is started.
[16:03] <cjwatson> bzoltan: buildd upgrades in progress, so might take a while
[16:03] <xnox> Chipaca: and saved.
[16:03] <cjwatson> (since I know you tend to notice such things)
[16:03] <Chipaca> xnox: on the phone?
[16:03] <xnox> Chipaca: yes.
[16:04] <xnox> Chipaca: /var/lib/dbus/machine-id -> on all platforms.
[16:04] <ogra_> ++
[16:04] <Chipaca> xnox: ah! not /etc/machine-id ?
[16:04] <bzoltan> cjwatson: :)
[16:04] <xnox> Chipaca: no, not /etc/machine-id, that one is broken on ubuntu at the moment.
[16:04] <Chipaca> ah, ok
[16:04] <Chipaca> goed
[16:04] <xnox> Chipaca: as in, it's unique per batch of install media =)))))
[16:05] <Chipaca> yeah
[16:05] <Chipaca> good enough
[16:05] <Chipaca> everybody on the team should know everybody else's emails by heart already anyway
[16:05] <xnox> Chipaca: nah, uterly pointless =)
[16:06] <Chipaca> xnox: sorry, i forgot to include the sarcasm signs. Consider them sprinkled over all of the above from 'yeah' on down.
[16:12] <bzoltan> sil2100: sorry! I top approved the MR
[16:20] <Chipaca> yes. yes you can.
[16:20] <oSoMoN> sil2100, can silo 5 be published, please?
[16:21] <sil2100> oSoMoN: sure! We just finished the meeting, publishing
[16:21] <oSoMoN> sil2100, thanks!
[16:27] <Chipaca> sil2100: can silo 6 be published, please?
[16:33] <sil2100> Chipaca: sure thing :)
[16:34] <Chipaca> whee :)
[16:35] <sil2100> Chipaca: all +1ed, approved and accepted by the overall community ;p?
[16:35] <Chipaca> sil2100: yep
[16:36] <Chipaca> sil2100: 1 sec, let me get you a link
[16:36] <Chipaca> sil2100: https://code.launchpad.net/~chipaca/gsettings-ubuntu-touch-schemas/just-the-touch-settings/+merge/228317/comments/556372
[16:37] <Chipaca> that includes both seb's "ok, let's do this thing", and laney's parting "beware"
[16:37] <Chipaca> ominous :)
[16:43] <sil2100> Chipaca: ok, last one thing - do you know why mediumtests are failing for the system-settings branch all the time?
[16:43] <sil2100> Is that normal?
[16:43] <Chipaca> sil2100: I don't know, no
[16:43] <Chipaca> sil2100: it's not even all the time, is it?
[16:44] <sil2100> Chipaca: I don't know, but I saw at least the last 2 CI runs failing there
[16:44] <Chipaca> sil2100: can you poke jenkins to do them again?
[16:45] <Chipaca> i can't, otherwise i would've
[16:45] <sil2100> Chipaca: from what I'm seeing from the test failure logs, all cellular tests are failing, hmmm
[16:46] <sil2100> https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-utopic/1954/testReport/ <- is this normal?
[16:47] <Chipaca> sil2100: i don't know
[16:47] <sil2100> Chipaca: let me just poke someone from system settings about that to make sure all is ok
[16:51] <sil2100> Chipaca: let me re-run the CI tests again
[16:55] <pmcgowan> sil2100, CI runs have been inconsistent, not sure if kenvandine ever learned anything about it
[17:10]  * ogra_ wonders why slangasek only changed the seeds for x86 based arches
[17:11] <bzoltan> sil2100:  would you please reconfigure the silo16, i have added there the -gles package
[17:14] <bzoltan> rsalveti: I put the MR for the UITK gles -> https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/sync_landing_0804/+merge/229494
[17:26] <sil2100> bzoltan: sure thing, one moment :)
[17:28] <sil2100> bzoltan: reconfiguring
[17:28] <kgunn> sil2100: mmm robru is out, sorry to pester... i got a build that seems stuck on armhf
[17:28] <kgunn> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+build/6239627
[17:30] <sil2100> kgunn: hmm... powerpc also seems stuck
[17:30] <bzoltan> sil2100:  thanks
[17:31] <sil2100> cjwatson: ^ do you know by any chance why it's taking so long to pick up the armhf/powerpc builds?
[17:51] <popey> 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] <bzoltan> popey: wow.... I want that tooo
[17:53] <popey> published, look for "quickmemo"
[17:54]  * ogra_ wonders what happened to the image build ...
[18:17] <ogra_> sil2100, hmm, looks to me like there was no image build triggered at all
[18:17] <sil2100> ogra_: the bot reacted, didn't it?
[18:17] <ogra_> yeah, it definitely did
[18:17] <ogra_> but i dont see a new rootfs on cdimage.u.c
[18:17] <ogra_> which should be there by now
[18:17] <sil2100> hmmm
[18:18] <ogra_> last one is from 2:56 UTC this morning
[18:19] <ogra_> cjwatson, err ... https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/utopic/ubuntu-touch/+build/3271
[18:19] <ogra_> "Start in 7 hours"
[18:19] <ogra_> "Started 2 hours ago"
[18:20] <ogra_> oh my
[18:21] <rsalveti> bzoltan: looks fine
[18:22] <jibel> there are only 2 armhf builders up according to LP
[18:22] <ogra_> ugh
[18:23] <ogra_> well,i have no clue how to bump the score (or if that would help at all)
[18:30] <ogra_> sil2100, so that looks like we wont have any images til someone sorts this
[18:30] <sil2100> uh
[18:31] <ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/utopic/ubuntu-touch is the LP rootfs build page btw
[18:31] <sil2100> 17:27 < cjwatson> rolling builder downtime for launchpad-buildd upgrades <- can this be related?
[18:31] <ogra_> oh, yeah !
[18:31] <sil2100> Not sure what Colin had in mind here
[18:32] <ogra_> well, you made me look at the backlog :)
[18:32] <ogra_> looks like we just badly hit the maintenance window
[18:33] <ogra_> sadly the emulator image got even more out of sync now
[18:33] <ogra_> since i386 could build before that started
[18:33] <rsalveti> let's just do a few armhf only builds
[18:33] <rsalveti> one every day
[18:33] <rsalveti> until it's in sync
[18:34] <ogra_> haha
[18:34] <ogra_> yeah
[18:34] <ogra_> until building fails on one of the arches again :)
[18:34] <ogra_> and we get out of sync again
[18:36] <rsalveti> ogra_: yeah, that's a by design issue
[18:36] <ogra_> yep
[18:37] <Chipaca> sil2100: any news for me?
[18:41] <sil2100> Chipaca: did you test the whole landing? Since we seem to be lacking armhf builders right now so CI couldn't finish the testing
[18:43] <Chipaca> sil2100: I did, yes, on mako
[18:44] <sil2100> Chipaca: ok, then I will publish it in hopes we have all under control ;) o/
[18:45] <Chipaca> sil2100: much appreciated
[19:13] <jgdx> have anyone seen this before https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-utopic/1963/consoleFull ?
[19:13] <jgdx> relevant parts? http://pastebin.ubuntu.com/7954523/
[19:23] <sil2100> slangasek: hi! You have access to snakefruit, yes?
[19:25] <sil2100> Ah, crap
[19:27] <sil2100> stgraber: are you around by any chance? :)
[19:28] <stgraber> sil2100: yeah
[19:28] <sil2100> stgraber: could you log into snakefruit and branch lp:cupstream2distro back to $HOME/cupstream2distro/ ?
[19:28] <sil2100> stgraber: right now it's a different, experimental branch which I need to work at a bit
[19:29] <sil2100> stgraber: where I need to revert it back to trunk to be able to safely publish some landings now
[19:30] <sil2100> stgraber: I would be very grateful :)
[19:30] <stgraber> sure, will do in a minute
[19:31] <sil2100> Thanks :)
[19:31] <sil2100> btw. how is cu2d/run.sh called on snakefruit? Is it like a timed run? Do you know?
[19:34] <stgraber> through cron I believe
[19:40] <pete-woods> sil2100: sorry to nag again. do you have time to go through the packaging changes for the unity-scopes-api silo? basically it's bumping the so version to 3, and making all the dependent packages depend on the new 0.6.0 package version
[19:40] <stgraber> sil2100: ok, I've moved the current cu2d aside and branched the one from lp:cupstream2distro
[19:40] <pete-woods> I really want to give the PES guys time to update their broken click packaged scopes well in advance of RTM
[19:40] <sil2100> stgraber: excellent, thanks, that should do it :)
[19:40] <stgraber> sil2100: I doubt it
[19:40] <stgraber> sil2100: cron is calling a script which doesn't exist in lp:cupstream2distro
[19:40] <sil2100> stgraber: which one?
[19:41] <stgraber> run.sh
[19:41] <sil2100> hm, from what I see here:
[19:41] <sil2100> http://paste.ubuntu.com/7952411/
[19:42] <sil2100> There's the cu2d directory which is supposed to have run.sh, and in the same directory there is the cupstream2distro directory
[19:42] <sil2100> stgraber: so from the contents of the pastebin that I got from cjwatson, it seems that run.sh is supposed to be outside of the cupstream2distro
[19:43] <sil2100> stgraber: ah, you said you moved the cu2d directory aside? I guess you can move it back and simply branch lp:cupstream2distro inside cu2d/
[19:43] <stgraber> sil2100: fixed
[19:43]  * sil2100 only has a vague idea of how things look there as he never had access there
[19:43] <sil2100> ;)
[19:43] <sil2100> Thanks!
[19:44] <sil2100> pete-woods: will do, just wanted to bring back sanity to CI Train
[19:44] <pete-woods> ah, okay
[19:44] <pete-woods> that's okay :) I'm just pretty desperate to get this out the door
[19:44] <sil2100> pete-woods: sorry for all this but today we're a bit under-staffed in the train ;D
[19:44] <pete-woods> I totally understand
[19:44] <sil2100> Especially with all the RTM test-work
[19:44] <pete-woods> sil2100: it seems like you pretty much run the thing at the moment
[19:45] <pete-woods> at least it's always you running my jobs, allocating silos, etc
[19:53] <slangasek> ogra_: mmm! only changed for x86-based arches?  must have been a caching bug on the network here, sigh
[19:53] <slangasek> ogra_: and I was distracted so didn't notice :/
[19:56] <sil2100> stgraber: just a quick question - how often is this run.sh script being called by cron?
[19:56] <stgraber> sil2100: every 5 minutes
[19:56] <sil2100> ACK, thanks
[19:59] <sil2100> pete-woods: hmm, looking at the packaging diff right now...
[19:59] <sil2100> Aw, crap ;|
[20:06] <popey> sil2100: did you speak to thostr about bug 1350529 ?
[20:06] <ogra_> slangasek, ah, well, i wasnt sure if this wasnt wanted
[20:06] <sil2100> popey: I poked jamesh who is responsible for mediascanner - he didn't answer on IRC, but I saw him looking at the bug
[20:07] <ogra_> ah, seems you just missed the image build
[20:07]  * ogra_ notes https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/utopic/ubuntu-touch shows a running build now 
[20:08] <slangasek> ogra_: well, I don't see that image 170 has finished yet, despite having been started hours ago
[20:08] <slangasek> so even on i386, my changes haven't taken effect
[20:08] <ogra_> there was buildd maintenance going on
[20:09] <slangasek> ah, ok
[20:09] <ogra_> it was stuck for 2-3h
[20:09] <slangasek> well, I can at least have a look at the i386 build log and see if there's anything else I need to do
[20:10] <ogra_> i dont really get why it hasnt been pushed to cdimage (the i386 build)
[20:10] <ogra_> there should be a 04.1 build with i386
[20:10]  * ogra_ would have liked to see the size difference
[20:17] <plars> jdstrand: I merged the change to the ci scripts we discussed, and future runs will also add an error entry (in addition to the test failures) if it detects the clickhooks were not set up properly
[20:17] <plars> jdstrand: we also need https://code.launchpad.net/~pwlars/phablet-tools/phablet-config-autopilot-errors/+merge/229485 for phablet-config to report errors though
[20:23] <slangasek> ogra_: anyway, qt4 is still on the image because something is still keeping autopilot-qt4 in the seed
[20:23] <slangasek> working through it now
[20:24] <sil2100> mhr3: ok, I'll fix up some of the issues in the staging branch for pete-woods and rebuild it
[20:29] <mhr3> sil2100, like what?
[20:29] <sil2100> mhr3: changelog was b0rken, I fixed it up quickly
[20:30] <mhr3> ah, thx
[20:31] <mhr3> wow, pete doesn't read my reviews :/
[20:31] <mhr3> sil2100, https://code.launchpad.net/~unity-team/unity-scopes-api/staging/+merge/229188/comments/556029
[20:32] <sil2100> hah ;)
[20:32] <jdstrand> plars: nice!
[20:33] <plars> jdstrand: hopefully between the two, we'll get some more feedback on what's going on. I'm running tests here to try to reproduce but so far no luck
[20:33]  * jdstrand nods
[20:36] <sil2100> barry: sorry again for the unapproved check!
[20:36] <sil2100> ;)
[20:36] <barry> sil2100: no worries!  at least i can approve it now ;)
[20:38] <barry> hey queuebot, i just manually acked them!
[21:25] <imgbot> [21:25] <imgbot> [21:26]  * popey updates devices
[21:44] <sil2100> slangasek, stgraber: if you don't mind, I'll be publishing the new unity-scopes-api silo - theoretically it adds a new binary package, but in practice it's just an soname bump
[21:45] <stgraber> sil2100: what should I review?
[21:45] <sil2100> Just so you know, I don't want to publish such a thing without the archive admins knowing
[21:46] <sil2100> https://ci-train.ubuntu.com/job/landing-017-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity-scopes-api_0.6.0+14.10.20140804.1-0ubuntu1.diff <- this will basically add libunity-scopes3
[21:47] <sil2100> All rdeps have been rebuilt, I checked the packaging for those and everything seems green for take off
[21:47] <sil2100> So if there are no objections, I'll press the publish button
[21:57] <boiko> hey guys, can I please get a silo assigned to spreadsheet row 30?
[22:03] <sil2100> boiko: let me take care of that
[22:03] <boiko> sil2100: nice! thanks! btw, silo 15 is tested and ready to land
[22:03] <sil2100> (we don't have US coverage today, but I'm working late today)
[22:03] <sil2100> Oh! Ok :)
[22:09] <sil2100> boiko: could you approve https://code.launchpad.net/~phablet-team/address-book-app/rtm-fit-finish/+merge/228529 ?
[22:09] <sil2100> (i.e. make sure it's reviewed ;) )
[22:09] <sil2100> boiko: oh, and once I publish this, only then build the packages in the silo assigned for row 30
[22:09] <boiko> sil2100: that's the one on silo 15
[22:09] <sil2100> Yeah
[22:09] <sil2100> boiko: I know, but it's unapproved - it needs to be approved to be published
[22:10] <sil2100> i.e. made sure it's reviewed by someone and accepted ;)
[22:10] <boiko> sil2100: it was approved (I have the page opened here without refreshing)
[22:10] <sil2100> Oh, ok, the status is 'Merged', hm
[22:10] <boiko> sil2100: and now it says 'Merged'
[22:11] <sil2100> Yeah, so it seems that it's target to staging
[22:11] <sil2100> Not to trunk?
[22:11] <sil2100> boiko: is that what was intended?
[22:11] <boiko> sil2100: err, ouch, let me talk to Renato, I didn't notice this, sorry
[22:11] <sil2100> boiko: no problem, let's just make sure it's the right merge and targetting the right thing - we might need to rebuild it
[22:12] <boiko> sil2100: yep
[22:12] <boiko> sil2100: talking to renatu right now
[22:13] <boiko> sil2100: ok, renatu is doing a new MR against trunk this time, I will change the silo to use that, and build/test it
[22:13] <boiko> sil2100: sorry for the trouble
[22:13] <sil2100> boiko: I'll AFK now for some time, once you build/test and I'm back I'll publish it if it's available
[22:14] <boiko> sil2100: nice! thanks a lot!
[22:15] <sil2100> yw!
[23:19] <cjwatson> sil2100,ogra_: The upgrade ran into a glitch and webops stopped; unfortunately it was while I was at dinner etc.
[23:19] <sil2100> cjwatson: ACK
[23:19] <cjwatson> Since it actually only needed to stop on ia64/sparc
[23:19] <ogra_> all fine ... the image cam eout eventually
[23:19] <cjwatson> Well, not fine yet, but yeah
[23:25] <sil2100> Ok, I need to go to sleep already
[23:25] <Chipaca> sil2100: sleep is overrated
[23:25] <sil2100> boiko: I'll publish your silo if it's ready in the morning
[23:25] <sil2100> Chipaca: ;)
[23:26] <sil2100> o/