[02:02] <bzoltan> ToyKeeper: i have the AP logs if you need
[02:03] <bzoltan> robru: ToyKeeper: i will check with zsombi the cursor issue, but i agree that it is a small thing
[02:09] <imgbot> [02:26] <ToyKeeper> bzoltan: BTW, where are the autopilot tests for things like the music app, calculator, clock, file manager, terminal, weather app, etc?
[02:27] <ToyKeeper> I found the AP tests for some of the items in the ui-toolkit test plan, but wasn't able to find at least half of them.
[02:27] <bzoltan> ToyKeeper: I use them from their packages
[02:28] <bzoltan> ToyKeeper: apt-get install -y ubuntu-ui-toolkit-autopilot gallery-app-autopilot share-app-autopilot address-book-app-autopilot messaging-app-autopilot dialer-app-autopilot camera-app-autopilot notes-app-autopilot friends-app-autopilot webbrowser-app-autopilot mediaplayer-app-autopilot unity8-autopilot ubuntu-system-settings-online-accounts-autopilot
[02:29] <ToyKeeper> Yes, I found the ones which had a corresponding -autopilot package.  Not sure about the ones which don't, though.
[02:29] <bzoltan> ToyKeeper:  they are click packages, right?
[02:29] <ToyKeeper> Yes, I think so.
[02:30] <bzoltan> ToyKeeper:  that is how those are done  -> phablet-config autopilot --dbus-probe enable;phablet-click-test-setup --click com.ubuntu.calculator;       phablet-test-run ubuntu_calculator_app
[02:32] <ToyKeeper> Hmm, okay.  Thanks.  I've only had minimal direct exposure to AP, but that should change during the upcoming sprint.
[02:32] <bzoltan> ToyKeeper:  consider yourself lucky :)
[02:34] <bzoltan> ToyKeeper:  I see the UITK package in the queue here https://launchpad.net/ubuntu/utopic/+queue?queue_state=0&queue_text=
[02:34] <bzoltan> ToyKeeper: is there anybody I could ping to push it?
[02:35] <ToyKeeper> bzoltan: Sorry, I'm not sure who has control of that.
[02:36] <bzoltan> ToyKeeper:  I will look around ... because that seems to be the slowest part of the process
[03:15] <bzoltan> ToyKeeper: do you know wthat is the -gles ending in the UITK package names? like qtdeclarative5-ubuntu-ui-toolkit-plugin-gles here https://launchpad.net/ubuntu/utopic/+queue?queue_state=0&queue_text=
[03:15] <ToyKeeper> Nope, haven't seen that suffix before.
[03:19] <imgbot> [03:19] <imgbot> [03:20] <bzoltan> ToyKeeper:  i wonder if I should be worried about it ...
[03:21] <bzoltan> ToyKeeper: I just crosschecked that I have not changed anything in the debian/control ... so no idea
[06:50] <Mirv> ogra_: I think we'd need #19 to get https://launchpad.net/ubuntu/utopic/+source/ubuntu-system-settings-online-accounts/0.3+14.10.20140506.1-0ubuntu1 in that finally migrated to release pocket, to fix Friends
[07:32] <dbarth> sil2100: hello
[07:32] <sil2100> dbarth: morning!
[07:32] <dbarth> sil2100: i'm trying to resolve the landing of that online account settings module
[07:32] <dbarth> what type of change or config do we need to push?
[07:33] <dbarth> appparently the branch got merged, but then autopkgtest rejected the upload
[07:33] <dbarth> now if we ty to push a fix in the same silo it blocks
[07:33] <dbarth> do we need a new silo for uploading that change and unblocking the upload further down?
[07:33] <sil2100> Let me take a look
[07:33] <sil2100> But I guess we'll only have to force things in
[07:34] <sil2100> Let me just double check things
[07:34] <dbarth> sure
[07:35] <sil2100> dbarth: are you sure it got rejected from -proposed?
[07:36] <sil2100> dbarth: since I see 0.3+14.10.20140506.1-0ubuntu1  in the archive (saying it came from silo 18)
[07:36] <sil2100> https://launchpad.net/ubuntu/+source/ubuntu-system-settings-online-accounts/0.3+14.10.20140506.1-0ubuntu1 <- wasn't that the thing that was blocked on autopkgtests?
[07:37] <dbarth> sil2100: checking, hold on
[07:38] <dbarth> mardy: ^^
[07:39] <mardy> dbarth, sil2100: mmm... yes, I think that's what was blocked
[07:39] <sil2100> mardy, dbarth: so, what could have happened...
[07:39] <mardy> sil2100: I'm quite confused of what happened and also what's the current state
[07:40] <sil2100> mardy, dbarth: in overall there were some issues with autopkgtests lately, and yesterday even with the migration... so most probably the autopkgtests simply failed as a false-positive
[07:40] <dbarth> but in the end it's uploaded
[07:40] <dbarth> ah
[07:40] <dbarth> right, that may be it
[07:40] <dbarth> mardy: but your change can still be added as a new upload
[07:40] <sil2100> And maybe someone (or the migrator) re-ran the test and it passed (had the same case yesterday)
[07:40] <dbarth> since it makes things better wrt to autopkgtests
[07:41] <sil2100> Need to think of a nice way to resolve this
[07:41] <sil2100> Since I see 2 options:
[07:42] <sil2100> 1) You include this 'released' changelog entry in a merge request which you add to the list of MRs
[07:42] <sil2100> 2) We 'release' the old version (merge to trunk) and we prepare a new landing for all the other stuff
[07:43] <sil2100> 2 is more time consuming, but it seems a bit better than 1 - as with 1, we won't have the release tagged correctly
[07:43] <sil2100> Which I guess is not a big deal
[07:43] <sil2100> But still
[07:43] <mardy> sil2100: either is fine with me; dbarth?
[07:44] <dbarth> 2 is better right?
[07:44] <dbarth> so let's do that
[07:44] <Mirv> sil2100: mardy: yes, I noticed in the morning that the release had migrated to -release. so the silo should have been merge & clean:d.
[07:45] <dbarth> do i need to m&c it still?
[07:45] <Mirv> dbarth: if something is stuck in -proposed, it needs to be waited to know whether it will be really rejected or not
[07:45] <sil2100> dbarth: yes, I would say it would be the best way, if you could just move the new MRs to a different landing and leave only the one that was there before, I will take care of cleaning it up ;)
[07:45] <dbarth> ok, perfect
[07:45] <sil2100> As I guess it might require some additional 'mojo';p
[07:46] <dbarth> mardy: i guess you have that single branch from yesterday
[07:46] <dbarth> sil2100: yeah ;)
[07:46] <Mirv> yep, I agree. I was waiting for you to come online, but I was a bit worried first about the build error since a rebuild had been triggered, but luckily the CI Train had blocked the build so the PPA is still intact
[07:46] <sil2100> Thanks! Just give me a sign ;)
[07:46] <Mirv> dbarth: if the the PPA rebuild would have succeeded yesterday, the PPA contents would have differed from the archives so this would have been trickier
[07:47] <sil2100> Mirv: yes, it all should be ok - and well, we don't even care abotu the PPA state right now, only thing that matters is the utopic-proposed branch
[07:47] <sil2100> Mirv: which should have stayed intact, ready to be merged
[07:47] <Mirv> sil2100: oh, right, utopic-proposed being the "real thing" makes it easier, a build wouldn't have even harmed that directly, only another publish
[07:48] <Mirv> so m&c it is
[07:49] <mardy> dbarth: https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/autopilot/+merge/218777
[07:51] <dbarth> sil2100: i'm on line 35 now
[07:56] <sil2100> dbarth: thanks :)
[07:57] <Mirv> sil2100: so are you running the m&c for the 018 silo?
[07:57] <sil2100> In a moment
[07:57] <sil2100> Need to make sure all is ok
[07:57] <Mirv> yeah, just checking
[07:59] <sil2100> Ok, all seems ok, let me try now
[08:00] <Mirv> hmm where dig ogra drop
[08:00] <Mirv> did
[08:01] <Mirv> I'd like him to launch an image build
[08:01] <sil2100> didrocks: do you remember if packages are in destination and utopic-proposed branches are prepared, if I press m&c with 'ignore step' - will it merge in the old utopic-proposed branch to trunk? :)
[08:01] <sil2100> Mirv: something important landed? :)
[08:02] <didrocks> sil2100: it will merge whatever is in the silo (so, the latest that you prepared)
[08:02] <Mirv> sil2100: yes, the friends would work now because of the migration
[08:02] <sil2100> \o/
[08:02] <sil2100> 2x \o/
[08:03] <sil2100> I just love didrocks's CITrain, it's so smart o/
[08:03] <didrocks> sil2100: hum, not sur eyou got it right :p
[08:03] <didrocks> so, if you rebuilt
[08:03] <didrocks> in the same silo
[08:03] <didrocks> that's what it will merge
[08:03] <didrocks> not what's in proposed
[08:04] <sil2100> Well, it never processed the build correctly, as it was bailing out on the build job
[08:05] <sil2100> oh
[08:05] <sil2100> Ouch
[08:06] <didrocks> well, if it started to consider the component, that's a start of preparation
[08:07] <sil2100> I might have to fix trunk manually, oh well ;/
[08:07] <didrocks> you just have to bzr pull -proposed
[08:07] <didrocks> from LP
[08:07] <didrocks> and get that to trunk
[08:09] <popey> anyone else ( ogra_ ?) get this when their phone does alarms? https://www.youtube.com/watch?v=vRQI8DnTEIg (it's only 22s long)
[08:09] <sil2100> Well, bzr pull is not enough, need to merge it ;/
[08:10] <ogra_> popey, yes, had that once
[08:10] <dbarth> sil2100: i also have line 36 with an SRU request
[08:10] <Mirv> ogra_: you dropped off but if image would be built now, Friends app would work again
[08:10] <ogra_> sil2100, ^^^ do you want an image ?
[08:12] <sil2100> ogra_: yes :) as per Mirv's request
[08:13] <sil2100> The more images, the merrier
[08:13] <ogra_> triggered
[08:13] <ogra_> :)
[08:14] <Mirv> thanks!
[08:19] <imgbot> [08:21] <sil2100> dbarth: phew, it should be ok - the system worked differently then I expected so it took some manual tinkering, but we should be fine now
[08:21] <sil2100> Time to put on some daily clothes
[08:26] <Mirv> dbarth: continuing from above, line 35 now has landing-001 for it
[08:32] <dbarth> sil2100: nice, thanks for bringing us back to clear here
[08:32] <dbarth> Mirv: thank you sir! :)
[08:34] <popey> Accidentally pressed the suspend button while in a hangout. Started PC back up and the hangout carried on. Phew!
[08:38] <Mirv> popey: I've needed some hunting for my OpenWRT Barrier Breaker running secondary WiFi AP (combined with possible utopic wifi issues on my laptop), and I've noticed Hangouts quite nicely recovers from anything that lasts for short enough amount of time
[09:07] <Wellark> sil2100: around?
[09:09] <Wellark> sil2100: I now added  libconnectivity-cpp-dev (>=0.0.1+14.10.20140509) to the build-deps of indicator-network
[09:09] <Wellark> that should now get it to dependency-wait in the silo
[09:11] <mhr3> thostr_, taking care of the issue in 009?
[09:11] <Wellark> mhr3: which issue?
[09:11] <mhr3> Wellark, no gcc4.7 on utopic ppc64
[09:11] <Wellark> we don't care about ppc64
[09:12] <mhr3> Wellark, previous upload of indicator-network worked on it
[09:12] <mhr3> so you're dropping it?
[09:13] <Wellark> well, if gcc-4.7 is not available then it's not available
[09:14] <mhr3> why do you force build with it?
[09:14] <Wellark> because all of the -cpp libs are forced to be built with 4.7
[09:14] <Wellark> because platform api is built with 4.7
[09:14] <Wellark> and there is a ABI breakage between 4.7 and 4.8
[09:15] <mhr3> so platform api won't be buildable either?
[09:15] <sil2100> Wellark: \o/
[09:15] <sil2100> Wellark: thanks, will rebuild this component in the silo to get it into the PPA
[09:15] <mhr3> sounds like a problem that should be fixed, anyone let foundations know?
[09:15] <Wellark> they know
[09:16] <Wellark> sil2100: already asked thostr to do a complete rebuild
[09:16] <sil2100> Wellark: excellent
[09:16] <Wellark> sil2100: but didn't get reply from him, so could you hit the build button?
[09:16] <Wellark> sil2100: also to make sure it works correctly, could the ppa be cleared first?
[09:17] <Wellark> I don't know if reconfigure does that
[09:17] <Wellark> mhr3: they know
[09:17] <Wellark> mhr3: tvoss knows
[09:17] <Wellark> on their TODO list
[09:17] <Wellark> g++-4.7  sucks on multiple counts
[09:19] <Wellark> sil2100, thostr_: I let you guys figure it out. :)
[09:19] <sil2100> Wellark, thostr_: running a build for those ;)
[09:20] <thostr_> sil2100: you mean 4.8?
[09:21] <thostr_> sil2100: or 4.7 for ppc
[09:21] <sil2100> thostr_: I mean, I ran a re-build of silo's 009 connectivity-api and indicator-network so that the new dep-version change is picked up
[09:22] <thostr_> sil2100: ah
[09:22] <sil2100> Since we need those two rebuilt so that the new build-dep version makes sense
[09:24] <cjwatson> The standard practice in other packages is to use gcc-4.8 on only ppc64el
[09:24] <cjwatson> You'll find this in several of the *-cpp packages
[09:25] <Wellark> the only real fix is that we get rid of g++-4.7
[09:25] <cjwatson> Nevertheless, this is a fix
[09:26] <cjwatson> I mean, I agree it would be good to upgrade, but there's no need to block on that (complex) change for this
[09:28] <Wellark> ok, I see dbus-cpp now has some magic to select between 4.7 and 4.8
[09:28] <Wellark> will add that later to indicator-network and connectivity-api as well
[09:32] <cjwatson> Right, same thing should work
[09:33] <cjwatson> Is the failure in https://launchpad.net/~ci-train-ppa-service/+archive/landing-009/+build/5989594 likely to be racy, i.e. worth retrying?
[09:34] <Wellark> never seen that before
[09:34] <Wellark> it might be racy if the builder is really really slow
[09:34] <Wellark> or under exterme load
[09:34] <Wellark> let's see how the rebuild goes
[09:34] <Wellark> cjwatson: there is already a rebuild happening
[09:34] <Wellark> i need to run some errands
[09:35] <Wellark> I'll be back later
[09:36] <ogra_> davmor2, popey, do we have a bug for the clock being always halted/behind on resume of the phone ?
[09:36] <popey> i haven't seen that
[09:37] <ogra_> popey, your clock is not several minuted behind and jumps to the right time when you unlock (after it was off for a while) ?
[09:37] <ogra_> *minutes
[09:38] <ogra_> i think that is what makes me miss the alarms all the time
[09:39] <ogra_> (when it appens that the alarms are  missed i usually see it being 1-2 mins before the alarm and when i unlock it jumps past the alarm time so the app never sees the marker to actually trigger the alarm)
[09:39]  * ogra_ notes his french accent today ...
[09:39] <ogra_> *happens
[09:39] <imgbot> [09:39] <imgbot> [09:41]  * ogra_ notes that ToyKeeper silently dropped the "haptics are audible during calls" bug from her list
[09:59] <bzoltan1> ogra_: do you know who needs to click on a button to move this queue: https://launchpad.net/ubuntu/utopic/+queue?queue_state=0&queue_text= The UITK seems to be blocked for 10 hours
[10:00] <ogra_> bzoltan1, ubuntu archive ... best to ask in the #ubuntu-release channel that an archive admin gets active on it
[10:01] <ogra_> bzoltan1, the package ships new binary packages, these need manual approval
[10:01] <jussi> !test
[10:01] <ogra_> you win !
[10:01] <ogra_> :)
[10:01] <jussi> popey: you are welcome :)
[10:02] <popey> \o/
[10:02] <popey> thanks
[10:02] <bzoltan1> ogra_: it is not my package, I did not do that ... I did not touch the debian/control .. this is for the x86 emulator image
[10:02] <popey> ogra_: no
[10:02] <ogra_> bzoltan1, sure, but if you want it to move now instead of waiting for ricardo, poke an archive admin
[10:03] <bzoltan1> ogra_: I wonder why ricardo put me in this place ...
[10:04] <ogra_> bzoltan1, surely because there is an evil conspiracy against you :P
[10:04] <ogra_> (i bet he just forgot about that)
[10:05] <bzoltan1> ogra_:  I do not say that :) But it is uncool to hijack other peoples landings and block them for whatever reason... Ricardo could have made a separate integration round
[10:06] <ogra_> well, he announced it various times on the ML that he rebuilds everything for gles for emulator use ...
[10:06] <bzoltan1> ogra_:  that does not sound like "hey I will hijack your MRs and block them for a day"
[10:08] <bzoltan1> ogra_: I am not against the -gles packages... me too need it for the emulator. But at the same time core app devs are waiting for the UITK fixes. These -gles rebuilds should be on a different track
[10:08] <ogra_> come on, we all have to do our work and at times there is no other way for you but block others ... and he properly announced the work
[10:09] <bzoltan1> ogra_: no, that is a different thing...
[10:09] <ogra_> you would be as well screwed if we had issues with the images ad would stop all landings ... even if the image breakage wouldnt be your fault
[10:09] <bzoltan1> ogra_:  creating a new binary package and landing a fix for apps are two different tracks... I would not even mix these, because even I know, that landing new packages are slow
[10:09] <ogra_> that is what happens in big teams
[10:10] <ogra_> no need to get upset about it
[10:10] <bzoltan1> ogra_: I am not upset :) I just do not agree that it is OK to hijak a landing and block it for a totally different purpose than the landing was initiated
[10:11] <ogra_> you *do not own* a package in ubuntu ...
[10:12] <ogra_> while it is nice from the upload to notify you there is no requirement at all ... i could right now upload your package and completely break it if i wanted ... (indeed i wont do that) ... we have explicitly no package ownership in the archive for anything
[10:12] <bzoltan1> ogra_:  häh ... wait a sec :) Mirv says that this -gles packaging does not actually block te UITK landing ...
[10:12] <ogra_> *uploader
[10:13] <bzoltan1> ogra_:  I though that the UITK back merging is blocked by this https://launchpad.net/ubuntu/utopic/+queue?queue_state=0&queue_text=
[10:13] <ogra_> if foundations does a low level library transition and your package needs touching (and gets a new dep that prevents it from publishing) they can do that ...
[10:14] <bzoltan1> ogra_: sure, of course
[10:14] <ogra_> bzoltan1, yes, i know what you thought :) i'm just saying you cant claim ownership of that package and if someone else uploads and breaks it you have to live with that ...
[10:15] <ogra_> no policy that forces anyone to notify you about an upload of y package you work most on (it is simply good practice, but doesnt need to happen oor some such)
[10:16] <bzoltan1> ogra_: those people who have license to upload are in some way on a different trust level. That is natural and good
[10:16]  * bzoltan1 got the point :D no need for further punishment 
[10:17] <ogra_> heh, i didnt mean to "punish" :P
[10:18] <ogra_> (though popey accused me of being "hulky" yesterday :P ...)
[10:18] <bzoltan1> not understanding something and realizing that I was talking crap feels like punishment :)
[10:19] <bzoltan1> you, ogra_ being hulky ... LOL
[10:19] <ogra_> well, you werent talking crap ... what you assumed *could* happen all the time
[10:19] <Mirv> yeah so the gles is not related to the normal uitk landing, instead it looks like autopkg tests are stuck or something
[10:19] <ogra_> yeah ... say "new toolbar" and i'll turn green :)
[10:21]  * didrocks missed ogra_'s hulk moment?
[10:29] <cjwatson> I've forced the autopkgtests that were blocking ubuntu-ui-toolkit; one had never passed (though I'll see if I can fix it, looks easy enough) and the other actually did pass but our buggy integration code didn't notice
[10:29] <bzoltan1> didrocks: and bzoltan1's double facepalm monent ... nothing new here :D
[10:29] <didrocks> bzoltan1: ahah :)
[10:53] <cjwatson> bzoltan1: ubuntu-ui-toolkit is migrating to the release pocket now
[10:53] <bzoltan1> cjwatson: thanks a lot
[11:05] <Mirv> that's great indeed, now there
[11:34]  * sil2100 goes to prepare lunch
[11:38] <zsombi> guys, I need to get CI to run on this MP https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-1315775/+merge/218206
[11:39] <ogra_> psivaa, see the last comment on bug 1316978 ... do we have some product i can open a bugtask for that reflects "hey we need this new test in the test suite"
[11:40] <zsombi> fginther: can someone enable CI on https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-1315775/+merge/218206
[11:41] <psivaa> ogra_: let me take a look. missing a bit of context. will go through the bug report
[11:52] <psivaa> ogra_: ok, now i understood the question :), that's 'Ubuntu CI Services' : https://bugs.launchpad.net/ubuntu-ci-services-itself
[11:52] <ogra_> ah, thanks :)
[12:03] <Wellark> sil2100: ok, I'm back
[12:03] <Wellark> but I see no new packages in the silo..
[12:04] <Wellark> are the builders under such load atm that the uploads are queued?
[12:06] <cjwatson> No, there's plenty of spare capacity in the build farm used by silos
[12:06] <cjwatson> https://launchpad.net/builders/ - silos use the "Official distributions" bit
[12:07] <Wellark> ug, oh..
[12:07] <Wellark> https://ci-train.ubuntu.com/job/landing-009-1-build/68/console
[12:07] <Wellark>   File "/srv/juju/vol-0000005d/var/lib/jenkins/citrain/citrain/cupstream2distro/branchhandling.py", line 302, in grab_committers_compared_to
[12:07] <Wellark>     raise Exception("bzr missing on {} returned a failure: {}".format(lp_branch_to_scan, stderr.decode("utf-8").strip()))
[12:07] <Wellark> Exception: bzr missing on lp:~unity-api-team/indicator-network/indicator-network-cpp returned a failure: Permission denied (publickey).
[12:08] <Wellark> help...
[12:09] <Wellark> didrocks: ^
[12:10] <didrocks> Wellark: as the logs says, seems bzr missing lp:~unity-api-team/indicator-network/indicator-network-cpp failed
[12:10] <Wellark> didrocks: nothing to do with my branch
[12:10] <didrocks> Wellark: well, nothing to do with the train either :p
[12:11] <ogra_> psivaa, hmm, seems one mako went astray in the recent test run for image 19
[12:11] <didrocks> Wellark: seems it's working, can be a hickup
[12:11] <didrocks> Wellark: so you should just retry a build on that one
[12:11] <Wellark> didrocks: well, the reason is that citrain public key got Permission denied from LP
[12:11] <Wellark> so yes, it's a citrain issue :)
[12:11] <psivaa> ogra_: yea, i've kicked them on another device, which is flashing now
[12:11] <Wellark> I don't have permissions to rebuild..
[12:11] <ogra_> psivaa, thanks
[12:12] <Wellark> didrocks: could you hit the button on the sheet?
[12:12] <didrocks> Wellark: what is the citrain public key? it's just calling bzr
[12:12] <psivaa> the earlier one was stuck in fastboot btw. the same device twice this week
[12:12] <didrocks> so can be a network hickup with LP
[12:12] <didrocks> Wellark: but it's between bzr and LP
[12:12] <ogra_> sigh ..
[12:12] <didrocks> Wellark: there is no "CI Train public key"
[12:12] <Wellark> ok, so ci train can't access private repos then?
[12:12] <Wellark> roger.
[12:13] <Wellark> (not that my repo would be private)
[12:13] <didrocks> Wellark: is ps-jenkins part of the ~unity-api-team team?
[12:13] <didrocks> Wellark: it's the only consideration for getting bzr working
[12:13] <didrocks> Wellark: if it was a hikcupp, I can rerun
[12:13] <Wellark> didrocks: it most probably is a hickup, as the train already built those repos once
[12:14] <didrocks> ok, /me retries
[12:14] <didrocks> with the same parameter that sil2100 setup
[12:14] <sil2100> didrocks: o/ Thanks, I'm still in the middle of lunch preparation
[12:14] <didrocks> Wellark: restarted
[12:14] <Wellark> didrocks: thanks!
[12:35] <renato> sil2100, good morning, do you know the status of silo4?
[12:35] <sil2100> renato: let me check in a moment :)
[12:36] <renato> sil2100, thanks
[12:38] <sil2100> renato: ok, so, I guess we'll have to ask someone to remove address-book-app for the non-supported archs
[12:39] <cjwatson> Did my patch not help?
[12:40] <sil2100> cjwatson, didrocks: could anyone of you get rid of address-book-app and address-book-app-dbg from the archive for archs for arm64, powerpc and ppc64el? With the patch the archs are out-of-date now
[12:40] <cjwatson> Oh, it did, yes I can just remove the binaries - but please copy it to -proposed first
[12:40] <sil2100> cjwatson: I might be misunderstanding update_excuses ;)
[12:40] <cjwatson> Ah, it's in -proposed, OK
[12:40] <cjwatson> I'll deal with it
[12:40] <sil2100> cjwatson: those seem to be in -proposed already
[12:40] <sil2100> cjwatson: thank you!
[12:40] <sil2100> :)
[12:41] <dpm> hi josepht, I've seen a couple of failures on https://code.launchpad.net/~rpadovani/reminders-app/1316950/+merge/218829 and https://code.launchpad.net/~reminders-app-dev/reminders-app/new-design/+merge/218341 I couldn't understand. As far as I can see, they're not related to the tests. Could you give me a hand figuring them out or retriggering the jobs?
[12:41] <renato> sil2100, how important is have the addres-book-app in other arch? Maybe we can split the qml keyboard plugin in a individual projects that not depend on keyboard code
[12:42] <Wellark> sil2100: it works! https://launchpad.net/~ci-train-ppa-service/+archive/landing-009/+build/5992875
[12:42] <josepht> dpm: sure, looking
[12:42] <cjwatson> sil2100: done
[12:42] <dpm> cool, thanks
[12:42] <cjwatson> renato: it's dealt with
[12:43] <cjwatson> renato: it's not particularly important to have the app itself - I just wanted to minimise the amount of fallout from reverse-dependencies
[12:43] <cjwatson> renato: so if you think splitting it would be a better design, by all means, but you shouldn't feel obliged and there are probably more important things to do
[12:44] <renato> cjwatson, ok lets keep this for now
[12:44] <renato> thank you guys
[12:45] <cjwatson> (and really, I'd rather get platform-api building everywhere so that we don't have to care about this in lots of individual packages, but that's not this week's project ...)
[12:46]  * didrocks goes for a run
[12:47] <ogra_> cjwatson, how would you do that without having android bindings ? with fake packages that do not work ?
[12:49] <Wellark> sil2100: although, now it seems indicator-network got stuck to that dependency-wait
[12:50] <Wellark> there are packages available of the connectivity-api for i386 and amd64 to satisfy the dependency, but the builds are not starting..
[12:50] <Wellark> or is it just a really slow cron job that checks the dependency-wait tasks only ever so often?
[12:52] <cjwatson> ogra_: yeah, I'm not sure
[12:52] <cjwatson> Wellark: dep-waits are checked every 30 minutes
[12:53] <Wellark> cjwatson: sweet
[12:54] <cjwatson> Wellark: I'll prod them for you now
[12:54] <cjwatson> (done)
[12:55] <cjwatson> Wellark: there's a lot of reverse-dependency fallout from connectivity-api/ppc64el though - would it help if I put together a patch for that?
[12:56] <Wellark> cjwatson: should only affect indicator-network if connectivity-api is not available
[12:56] <cjwatson> which it isn't
[12:56] <cjwatson> needs the gcc-4.8 fix
[12:57] <Wellark> cjwatson: well, if you are offering your help how could I refuse :)
[12:57] <cjwatson> heh
[12:57] <Wellark> although I could cook it up myself during the weekend also
[12:57] <Wellark> you probably have better things to do..
[12:57] <Wellark> right now
[12:58] <cjwatson> eh, I've already written the patch, just need to build-test it
[12:59] <Wellark> just make sure to crosscompile it then
[12:59] <Wellark> build time tests wont work if you compile with g++-4.8
[12:59] <cjwatson> rather than native compile?
[12:59] <Wellark> if you have a ppc64el at hand then you can do a native compilation as well :)
[13:00] <cjwatson> which I do
[13:00] <Wellark> oh
[13:00] <Wellark> ok
[13:00] <Wellark> carry on then! :D
[13:00] <Wellark> cjwatson: just remind me again, why is it a priority right now to get the unity8 stack compiling on ppc64el
[13:00] <Wellark> I though it is a server architecture
[13:01] <Wellark> (don't mean to be a dick, just honestly curious about this)
[13:01] <cjwatson> it's not in itself, but our dependency stacks are very tightly interwoven in many places
[13:01] <cjwatson> in this case indicator-network was already built on ppc64el
[13:01] <Wellark> right. ok.
[13:01] <cjwatson> undoing that would mean tearing out the UOA stack, which is really painful to make arch-specific, we've been there before and I would rather not go back
[13:02] <cjwatson> lots of explicit architecture annotations - it's easier to just make it build everywhere
[13:02] <Wellark> but just to point out indicator-network it's totally useless wihtout unity8
[13:02] <cjwatson> sure, I know
[13:02] <cjwatson> as I say the rdeps are more of an annoyance
[13:02] <ogra_> just wait til apple announced the iphone 9 with ppc64el CPU ;)
[13:03] <cjwatson> the general rule is that packages must build on all architectures where they used to build
[13:03] <cjwatson> and we generally try to build all packages everywhere, insofar as it's possible - our dependency stack is really a tremendously messy graph and things you might not expect to be useful on a server arch wind up in the oddest places when sorting out build-deps
[13:04] <Wellark> yep
[13:04] <Wellark> which tells about a different kind of a problem to solve, but let's not go there
[13:04] <cjwatson> also having high build percentages makes us look good to the client :)
[13:04] <Wellark> :D
[13:05] <ogra_> (and while i was joking above, nobody would have predicted an arm64 phone two years ago, so you never know ...)
[13:05] <cjwatson> and once we do the whole convergence thing, we might want things like unity8 for remote sessions
[13:06] <Wellark> ogra_: well, Apple does have quite some history with ppc, but I think the breakup was so bad that they will never go back :)
[13:06] <Wellark> if for nothing else then just on plain principle
[13:06] <ogra_> lenovo builds phones too and still stands pretty close to IBM ;)
[13:07] <ogra_> (though i admit ppc64el is probably not designed for mobile power consumption)
[13:07] <Wellark> nope..
[13:07] <Wellark> clouds..
[13:07] <ogra_> yep
[13:08] <Wellark> "who cares about power concuption.. We have our own power plant just to run this data center. Give me calculation power."
[13:08] <cjwatson> anyway mostly my motivation is not having to do evil things to reverse-dependencies elsewhere.  I don't really care horribly much if stuff that never built continues to not build
[13:08] <cjwatson> Wellark: https://code.launchpad.net/~cjwatson/connectivity-api/ppc64el-gcc-4.8/+merge/218984, build-tested cleanly on ppc64el
[13:09] <cjwatson> basically copied and pasted from dbus-cpp
[13:09] <Wellark> well, IMO indicator-network should never have been built for ppc64el, but "mistakes" happen ;)
[13:09] <Wellark> cjwatson: cool. I will merge that in
[13:09] <cjwatson> thanks
[13:09] <Wellark> cjwatson: thanks!
[13:09] <Wellark> cjwatson: I need to do the same for indicator-network also
[13:09] <Wellark> or do you have a branch for it, too? :)
[13:10] <cjwatson> I can make one for you if you can point me to the branch I need to base it on
[13:11] <josepht> dpm: the job is running now
[13:11] <cjwatson> although I'm not sure if I can land something that involves a prerequisite branch through the ci train, so it might be easier if I gave you a patch
[13:11] <Wellark> https://code.launchpad.net/~unity-api-team/indicator-network/indicator-network-cpp
[13:11] <dpm> josepht, great, thanks!
[13:11] <Wellark> cjwatson: if you could just propose a MP against that one
[13:12] <Wellark> I can then merge it directly in if any other modifications are needed to the -cpp branch
[13:15] <cjwatson> Wellark: ok, https://code.launchpad.net/~cjwatson/indicator-network/ppc64el-gcc-4.8/+merge/218986 - can't easily test that until connectivity-api lands, but it's not very complicated so should be fine
[13:16] <Wellark> cjwatson: thanks!
[13:16] <Wellark> oh, one more thing
[13:16] <Wellark> could you make this: https://code.launchpad.net/~cjwatson/connectivity-api/ppc64el-gcc-4.8/+merge/218984
[13:16] <Wellark> proposed to be merged to this:
[13:17] <sergiusens> sil2100: any update on my changelog issue?
[13:17] <Wellark> https://code.launchpad.net/~unity-api-team/connectivity-api/devel
[13:17] <sergiusens> sil2100: should I just dput myself?
[13:17] <cjwatson> Wellark: done, resubmitted as https://code.launchpad.net/~cjwatson/connectivity-api/ppc64el-gcc-4.8/+merge/218987
[13:18] <Wellark> cjwatson: it has merge conflict
[13:19] <cjwatson> sigh, one sec
[13:19] <Wellark> cjwatson: also, is this outdated? https://wiki.debian.org/CrossBuildPackagingGuidelines
[13:20] <Wellark> as it says that DEB_HOST_GNU_TYPE is not always available
[13:20] <cjwatson> where does it say that?
[13:21] <Wellark> cjwatson: "Sadly we can't just set $(DEB_HOST_GNU_TYPE)-gcc always because that doesn't work natively"
[13:21] <cjwatson> oh, I think that *may* have changed in Ubuntu very very recently
[13:21] <Wellark> therefor /dev already had that ifeq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
[13:22] <Wellark> cjwatson: ok. feel free to remove the ifeq else endif then :)
[13:22] <cjwatson> it's not harmful to use that, so I'll just leave it
[13:22] <Wellark> I'm not going back
[13:22] <Wellark> :)
[13:22] <Wellark> cjwatson: thanks!
[13:22] <cjwatson> merge conflict fixed
[13:23] <Wellark> cjwatson: thank you sir!
[13:25]  * cjwatson goes back to cdimage hacking
[13:35] <davmor2> sil2100: so I see very little difference between mako and flo, 2 outstanding things being it looks like flo is using more power than mako (I'm assuming expected due to bigger screen etc) there are issues on some webpages where the app say mobile so sets page to the top left corner, planet.ubuntu.com is a good example of this
[13:36] <sil2100> sergiusens: so, I'm working on that now, give me 30 minutes
[13:37] <davmor2> sil2100: that of course could be the same on mako but with the smaller screen the feed fits it
[13:37] <sil2100> davmor2: ok, thanks, at least it seems similarily usable
[13:37] <davmor2> sil2100: pretty much identical
[13:38] <davmor2> sil2100: so it looks like manta is the new maguro the unloved one in the corner ;)
[13:38]  * sil2100 feels sad for manta :<
[13:40] <davmor2> sil2100: so what I might start doing is a regular look at manta and mako as flo is so similar to mako, until they land landscape mode on flo then things might change a little
[13:47] <sil2100> sergiusens: so, I'm trying to somehow make us handle this case, but the thing is that citrain doesn't really 'do something wrong' here
[13:48] <sil2100> sergiusens: because your branch has ogra's one set as prereq and by being based on that branch, this basically means that the branch you want to merge in includes both commits from you and ogra_
[13:48] <sergiusens> sil2100: but that means prerequisites aren't really supported
[13:49] <sil2100> sergiusens: citrain currently doesn't really support prereqs right now - for now what we were doing were either merging prereqs manually to the branch being proposed
[13:49] <sil2100> Trying to add basic support, but still need some time
[13:50] <sergiusens> that really breaks my bzr pipeline development as the changelog would be a lie
[13:53] <sergiusens> sil2100: the way the changelog is formatted now it even adds the bug fix to the bot instead of ogra_
[13:54] <sil2100> Oh, right, damn, this I missed
[13:56] <sil2100> Ah ha, I've got an idea
[14:01] <sergiusens> sil2100: can't you walk the prereq chain for unmerged branches and snatch the commit message and linked bugs?
[14:02] <sil2100> The theory is not hard, the practical part is a bit more work-consuming ;)
[14:02] <sil2100> But working on that
[14:05] <ogra_> hmpf
[14:06] <ogra_> i dont get why https://code.launchpad.net/~ogra/ubuntu-ui-toolkit/improve-haptics/+merge/218966 fails the CI bot
[14:06] <ogra_> ( i re-targeted the MP to a different branch, looks like CI doesnt pick that up properly)
[14:23] <dpm> josepht, are those Jenkins jobs for Reminders still running? I've not yet seen any new output from Jenkins on the MP
[14:43] <josepht> dpm: they are still running, though I might need to run them again since the MP wasn't top-approved when they ran
[14:43] <dpm> ok, thanks josepht
[14:48] <sil2100> sergiusens: can I experiment by doing rebuilds on your silo?
[14:48] <sil2100> Need to do a few tests
[14:48] <sergiusens> sil2100: yeah
[14:48] <sil2100> Thanks
[14:57] <dpm> josepht, thanks, Jenkins now auto-landed one branch, but failed on the other - https://code.launchpad.net/~reminders-app-dev/reminders-app/new-design/+merge/218341
[15:03] <josepht> dpm: k, I'll rerun that one
[15:04] <dpm> awesome, thanks josepht
[15:07] <sil2100> sergiusens: so, the changelog is fixed for that landing, but I still have to do this support 'better'
[15:07] <sil2100> But at least you shouldn't be blocked anymore
[15:17] <sil2100> popey: do you know if there is a new filemanager release pending?
[15:18] <popey> sil2100: yeah, we are 4 revs behind trunk
[15:18] <popey> fm still fails sometimes..
[15:20] <popey> balloons: is it worth me testing r173 and pushing to store?
[15:20] <sil2100> popey: since for instance balloons wrote that some issues we're having on smoketesting should be fixed, at least most of the flakyness
[15:21] <popey> lemme run the ap tests locally and let you know
[15:21] <ogra_> josepht, i seem to have confused the CI bot on my MP https://code.launchpad.net/~ogra/ubuntu-ui-toolkit/improve-haptics/+merge/218466 ... (i was asked to rebase on a adifferent branch and update the MP to point to that branch for the merge too ... now the bot doesnt like to pass)
[15:21] <balloons> popey, sil2100 it worked MUCH better on my devices, but I was still able to produce the issue sometimes
[15:21] <balloons> needs a continued look
[15:21] <ogra_> josepht, is there anything i can do ? or should i just do a new MP
[15:21] <balloons> I enabled more tests and did alot of cleanup work
[15:23] <sil2100> balloons: would love having that released
[15:23] <sil2100> plars: hi! Are you around to maybe try re-running some tests for us ? :)
[15:24] <plars> sil2100: yes
[15:24] <sil2100> plars: on 19 we had some new failures, could you try re-running camera_app, sudoku_app and weather_app? :)
[15:24] <sil2100> plars: thanks!
[15:24] <ogra_> yeah, #19 doesnt look so great :/
[15:24] <plars> sil2100: will do
[15:25] <sil2100> Thank you!
[15:35] <sil2100> popey, davmor2: how does #19 look dogfooding-wise on mako? :)
[15:36] <davmor2> sil2100: I'm just double checking mako but flo was on 19
[15:36] <popey> sil2100: I haven't been dogfooding much today. I'll give it a run through in a moment when these AP tests finish
[15:36] <sil2100> Thanks :)
[15:36] <davmor2> sil2100: camera app is fine. I'll check weather and sudoku now though
[15:36] <sil2100> Since I guess we could promote #19 today, as there wasn't much changes from 18, so the additional failures have to be old flaky tests
[15:37] <sil2100> But we'll see after the re-runs finish
[15:37] <sil2100> As the diff between 18 and 19 is are only packages from the ubuntu-system-settings-online-accounts source
[15:37] <sil2100> And this fixes friends-app
[15:38] <sil2100> But we'll discuss that on the meeting
[15:38] <davmor2> sil2100: weather is fine unless you add Saint Julians, malta oddly
[15:38] <sil2100> uh?
[15:38] <sil2100> How come?
[15:38] <davmor2> sil2100: try it
[15:41] <popey> balloons: why can't i run ubuntu_filemanager_app tests?
[15:41] <popey> could not import package ubuntu_filemanager_app: No module named ubuntu_filemanager_app
[15:42] <popey> oh, it's just filemanager now
[15:42] <sil2100> davmor2: seems to work here
[15:42] <sil2100> But hm, wait
[15:42] <sil2100> davmor2: no, it's fine here it seems
[15:42] <sil2100> I'm on #19
[15:46] <elopio> ping josepht: we have a test that works in trusty, but fails in utopic.
[15:46] <elopio> https://code.launchpad.net/~elopio/reminders-app/test_with_account/+merge/218688
[15:46] <elopio> can you help us finding what's different on the machines?
[15:46] <elopio> fginther was helping us yesterday with this test.
[15:46] <josepht> elopio: looking
[15:47] <davmor2> sil2100: I add saint julians and then I get could not load weather
[15:47] <fginther> elopio, josepht I'll have to do this (due to machine access issues)
[15:48] <sil2100> davmor2: here after adding the city it displays the weather normally here, saying it's 71F etc.
[15:48] <sil2100> Strangeness
[15:48] <davmor2> sil2100: let me reboot
[15:49] <davmor2> sil2100: I'm wondering if it was because there were 3 cities already with data accrued and then adding another city just killed it
[15:49] <josepht> fginther: ack
[15:51] <plars> sil2100: sudoku and camera did fine on the rerun, weather is going now
[15:51] <sil2100> plars: \o/ thanks, then it's as I suspected
[15:52] <popey> balloons: one failure in filemanager
[15:52] <popey> testtools.matchers._impl.MismatchError: After 10.0 seconds test failed: '/tmp/tmpj5xetj18/tmpfmql_pr_2g' != '/tmp/tmpj5xetj18'
[15:52] <popey> is that what you get?
[15:57] <elopio> josepht, fginther: ok, thanks.
[16:04] <popey> balloons: joining the call?
[16:05] <fginther> elopio, this testing worked yesterday. http://91.189.93.70:8080/job/generic-mediumtests-utopic/58/ and there are some output differences visible there vs the trusty run
[16:06] <popey> balloons: can you push filemanager to the store please?
[16:06] <popey> 173 works for me
[16:06] <fginther> elopio, I double checked that the same change was made to /etc/signond.conf (which was to set "SecretsStorage=default")
[16:08] <fginther> elopio, I need to step away for a bit but will try some more experiments later. The best answer I have so far is that there is already a difference in behavior between trusty and utopic.
[16:17] <sil2100> ogra_: reminding about promotion!
[16:18] <ogra_> sil2100, dude !
[16:18] <ogra_> the script takes 10min ... give it time to finish
[16:18] <sil2100> Make it run FASTER
[16:18] <ogra_> [16:18] <robru> ogra_, did you promote yet!?!? ;-)
[16:18] <ogra_> :P
[16:18] <sil2100> Thanks ;)
[16:19] <ogra_> fginther, hey ... i had to rebase an MP onto a staging branch of the same code ... now the CI bot is playing tricks on me (and rebuilding seems to be a no-op) ... is there anything i can do ? https://code.launchpad.net/~ogra/ubuntu-ui-toolkit/improve-haptics/+merge/218466
[16:23]  * sil2100 notes down to start sending out G+ info about landing team annoucements
[16:24] <ogra_> ++
[16:24] <ogra_> i wouldnt mind doing it ... *IF* the silly G+ app we have would support posting links !
[16:25] <ogra_> (and if copy paste would work :P )
[16:25]  * ogra_ does G+ mostly on the phone
[16:30] <sil2100> ;p
[16:30] <sil2100> No worries, I'll do it! Just need to prepare myself mentally
[16:30] <sil2100> robru: leaving landing in your hands o/
[16:31] <sil2100> Good luck ;p
[16:31] <robru> sil2100, thanks, have a good weekend!
[16:32] <sil2100> Same to you
[16:32] <sil2100> See you next week!
[16:32]  * sil2100 goes of to the vet with his animals
[16:43] <balloons> popey, yep, fm is pushed to the store now
[16:43] <popey> thanks
[16:51] <t1mp> what can cause errors like this in autolanding? W: Failed to fetch bzip2:/var/lib/apt/lists/partial/archive.ubuntu.com_ubuntu_dists_utopic_universe_binary-amd64_Packages  Hash Sum mismatch
[16:51] <t1mp> from https://jenkins.qa.ubuntu.com/job/ubuntu-sdk-team-ubuntu-ui-toolkit-staging-utopic-amd64-autolanding/10/console
[16:56] <cjwatson> race with mirror updates, I suggest just retrying
[17:00] <t1mp> cjwatson: okay, thanks
[17:10] <popey> can someone please confirm bug 1317986
[17:10] <popey> robru: ^
[17:11] <robru> popey, ah, just flashing now
[17:12] <robru> popey, confirmed
[17:12] <popey> thanks
[17:14]  * popey goes to get food, back in a bit
[17:18]  * sil2100 sighs
[17:18] <sil2100> popey: did anyone else reproduce it?
[17:19] <ogra_> seems so
[17:19] <ogra_> (in #ubuntu-app-devel)
[17:19] <sil2100> davmor2: we need to add it too to the dogfooding exercise
[17:20] <sil2100> I would prefer getting this fixed ASAP, as reverting ubuntu-system-settings-online-accounts would mean simply going back to 18
[17:20] <sil2100> dbarth: are you around still?
[17:21]  * sil2100 feels ashamed having an image with such a flaw promoted
[17:21] <sil2100> Sorry guys!
[17:21] <ogra_> happens ... not the first time, dont worry
[17:23] <sil2100> mardy: ping!
[17:23] <sil2100> mardy: are you around?
[17:23] <dbarth> sil2100: i am
[17:24] <dbarth> sil2100: what's up?
[17:24] <sil2100> dbarth: o/ big regression: https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings-online-accounts/+bug/1317986
[17:24] <dbarth> uh
[17:24] <sil2100> dbarth: last ubuntu-system-settings-online-accounts upload broke online accounts it seems, I would prefer not to revert, but if needed we can do that temporarily
[17:24] <sil2100> Since it's in the promoted image ;/
[17:24] <dbarth> oh my
[17:25] <sil2100> dbarth: do you think it's still possible to fix today?
[17:25] <dbarth> it feels like the dialog does not appear
[17:25] <dbarth> because of another surface priority issues
[17:25] <dbarth> sil2100: not possible, i recommend to revert at the very least
[17:26] <dbarth> (mardy may come back online later)
[17:26] <sil2100> dbarth: ACK, let me try and revert that then
[17:26] <dbarth> but i suspect a bad interaction with a unity/mir landing though
[17:26] <sil2100> ogra_: if I prepare a debdiff, would you be so kind and publish it? A revert - we would promote the image with the revert then
[17:26] <dbarth> i did not notice it when testing on wednesday
[17:26] <sil2100> ogra_: since basically #18 was good anyway
[17:26] <sil2100> dbarth: could be...
[17:27] <ogra_> sil2100, sure, np
[17:28] <sil2100> popey: thanks for catching this one!
[17:34] <davmor2> sil2100: arse monkeys my accounts were already full on phone and flo :(
[17:34] <davmor2> sil2100: Mondays I tend to wipe the system and start from scratch
[17:35] <sil2100> davmor2: no problem, let's just add such a test to our testing plan - I also don't really touch my accounts after setting them up once ;p
[17:35] <ogra_> same here
[17:37] <davmor2> sil2100: I'll add it when I get back from Tea unless you want to add it popey
[17:37] <ogra_> sil2100, there were a bunch of uploads and changes during the day a new image will pick up, even if you roll back
[17:37] <ogra_> just fyi
[17:37] <davmor2> sil2100: personally I'm ashamed of how few autopilot tests the settings app must have if this got through
[17:38] <davmor2> anyway tea
[17:38] <dbarth> sil2100: i'm staying around if you need me
[17:38] <sil2100> Ah, crap, hmmm
[17:38] <sil2100> Right, we can't block and only allow one new update
[17:38] <ogra_> mainly rsalveti rebuilding the world for gles ...
[17:39] <ogra_> which shouldnt have any impact
[17:39] <sil2100> robru: ^
[17:39] <ogra_> but i also see ubuntu-download-manager
[17:39] <ogra_> and libphonenumber
[17:40] <robru> sil2100, hey what's up? yeah I published udm for mandel
[17:40] <dbarth> sil2100: is there an older rev. of the package somwhere i could try downgrading to?
[17:40] <ogra_> oh, and a new UITK
[17:40] <sil2100> Ok, so we're officially screwed
[17:40] <dbarth> ie, i still worry about other parts being the cause
[17:40] <mandel> sil2100, robru what happened?
[17:41] <ogra_> phew
[17:41] <sil2100> ogra_: we can't somehow like, you know, cheat and make #18 as the next one and promote it as #20 ;) ?
[17:41] <ogra_> and camera-app
[17:41] <robru> mandel, nothing, there's a big regression in image #19 unrelated to udm, but we can't just revert it and re-promote because there's new bits that would appear in image #20
[17:41] <ogra_> and qtorganize5-eds
[17:41] <fginther> ogra_, your MP is in the jenkins autolanding queue
[17:41] <mandel> robru, ah, ok
[17:41] <ogra_> fginther, oh, so its just slow ?
[17:41] <mandel> robru, sil2100 one questions, ti seems that sergiusens and I lost permissions to clean, is due to that block, right?
[17:42] <fginther> ogra_, it's waiting on other MPs to merge, autolanding is 1 at a time
[17:42] <Saviq> UGH
[17:42] <ogra_> fginther, ok
[17:42] <ogra_> i'll be patient then :)
[17:42] <Saviq> "saviq is missing the Job/Build permission" on ci train? what happened?
[17:42] <sil2100> ogra_: ^
[17:42] <robru> mandel, uh, not sure. I'll just clean it for now but we should figure out how to get your permissions back ;-)
[17:42] <sil2100> ogra_: I mean, is that cheat possible? ;)
[17:42] <mandel> robru, great, thx, sergiusens has the same issue
[17:42] <ogra_> sil2100, yes, looking ... never done that before i might mess up the world ...
[17:43] <Saviq> boo :|
[17:43] <Saviq> I'll be back, please ping when resolved
[17:43] <robru> sil2100, how do we change the ci train build permissions? is it done with LP groups?
[17:43] <ogra_> and no stgraber :(
[17:43] <sil2100> hm
[17:44] <sil2100> robru: we need adding to ci-train-users, but Saviq was there last time I looked
[17:45] <robru> sil2100, hm, mandel and saviq and sergiusens are all in that group...
[17:45] <ogra_> sil2100, i pinged stgraber, lets see what he says
[17:45] <sil2100> robru: hm, I think it's time to ping webops about that
[17:45] <sergiusens> robru: might be a broken link on the jenkins instance?
[17:46] <fginther> ogra_, I'm looking into 'rebuilding seems to be a no-op'. What did you see that led to this?
[17:47] <fginther> ogra_, oh, you mean the 'rebuild' link in the MP comments?
[17:47] <ogra_> fginther, well, i clicked rebuild and nothing happened for quite a while
[17:47] <ogra_> yeah
[17:47] <sil2100> ogra_: thanks o/
[17:47] <ogra_> sil2100, i *think* i know how to do that but i'm uncertain
[17:47]  * ogra_ ponders to just take the risk and hit the button 
[17:48] <sil2100> ogra_: wouldn't want anything broken, but if it would be possible, I guess that would be a 'safe' way to proceed
[17:48] <sil2100> As the delta is only this one package I guess
[17:48] <ogra_> right
[17:48]  * popey returns
[17:48] <popey> I can dogfood 20 when it's done
[17:48] <popey> if that helps?
[17:48] <ogra_> it will be incosistent between the channels ... since promoted #20 wont be what -proposed #20 is anymore
[17:48] <sil2100> We would release the revert anyway to have all the other images not-broken temporarily
[17:49] <sil2100> hmmm
[17:49] <ogra_> popey, no need if i can just copy #18 to be #20
[17:49] <popey> oh i see
[17:49] <popey> neat, well, have we tested that #18 isn't broken?
[17:49] <sil2100> ogra_: can't we somehow copy 18 to be 20 in the -proposed channel as well?
[17:49] <popey> this sounds very hacky
[17:50] <ogra_> sil2100, well, it is unlikely that we will ever promote the real 20
[17:50] <ogra_> so i think we are safe ...
[17:50] <sil2100> popey: you mentioned that accounts is not broken in #18, right?
[17:50] <ogra_> there are ways to copy within a channel but these are hacks i prefer to leave to stephane
[17:50] <popey> sil2100: i did not
[17:50] <sil2100> Argh
[17:50] <ogra_> i saw someone mention it works in #17
[17:50] <dbarth> so are we going #20 + some reverts or from 19?
[17:51] <sil2100> Ok, so I misunderstood something then
[17:51] <ogra_> dbarth, no, we just copy 18 to be 20
[17:51] <sil2100> popey: could you quickly flash 18 and check?
[17:51] <sil2100> ogra_: wait a moment pelase
[17:51] <ogra_> dbarth, existing images
[17:51] <ogra_> sil2100, yeah indeed :)
[17:52] <popey> sil2100: i can, yes
[17:52] <sil2100> popey: thanks
[17:52]  * sil2100 ran into the channel after he saw the issue e-mail and is still a bit untidy
[17:52] <popey> downloading now
[17:53] <popey> Sorry I didn't spot this earlier, we don't have manual tests for creating online accounts ☹
[17:53] <dbarth> mardy: ping? if you come back this evening
[17:54] <dbarth> can you check if a ubuntu-system-settings-online-accounts revert also implies a revert of friends-app?
[17:55] <sil2100> dbarth: from what Timo told me, those two are interconnected, but we already had one without the other
[17:56] <robru> sil2100, no vanguard in #webops so I filed this RT: https://rt.admin.canonical.com/Ticket/Display.html?id=70171&results=cc511376a9798e5b669d6f9015596abf
[17:57] <dbarth> sil2100: they are connected, but friends-app should still run without the revert
[17:58] <sil2100> dbarth: I remember we had an autopilot test failure in friends_app then
[18:00] <robru> sil2100, if there was an AP failure for friends_app then either friends_app crashed on launch or it was a bug in some other component, because friends_app test is basically a no-op
[18:00] <sil2100> dbarth: ^
[18:00] <dbarth> sil2100: but so if you switch back to #18, then the problem is gone?
[18:00] <ogra_> dbarth, popey is just confirming that
[18:00] <ogra_> we know it works in #17
[18:01] <popey> taking a while to download, will take another 10-15m
[18:01] <sil2100> dbarth: on #18 there was that friends-app problem, but the problem with accounts might be gone
[18:01] <dbarth> sil2100: was online accounts already in #18?
[18:01] <dbarth> friends-app needs a patch to work with the new app-access scheme, and that was reason for the crash i think
[18:01] <ogra_> people.canonical.com/~ogra/touch-image-stats/18.changes
[18:02] <ogra_> signon-plugin was ...
[18:02] <dbarth> but not the friend-app update?
[18:02] <dbarth> i thought silos was landing in one op
[18:02] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/19.changes
[18:02] <sil2100> dbarth: so, fiends-app update was in 18 but online-accounts in 19
[18:02] <ogra_> thats 19
[18:02] <sil2100> dbarth: online-accounts got blocked in -proposed
[18:03] <dbarth> oh geez, so friends-app with the patch, crashes
[18:03] <sil2100> dbarth: so both got out-of-sync in the archive... nothing we could do about that ;/
[18:06] <sil2100> ogra_: here should be the debdiff
[18:06] <sil2100> ogra_: http://paste.ubuntu.com/7422675/
[18:06] <ogra_> sil2100, yeah, but that woont help without a full re-test of the image
[18:06] <sil2100> ogra_: yeah, I just want it in for now, so that the next images in -proposed won't be badly broken
[18:07] <ogra_> btw, why dont we just roll back to 17 ...
[18:07] <ogra_> that was the last promoted one
[18:07] <sil2100> ogra_: we can...
[18:07] <sil2100> ogra_: wanted to have some progress though ;p
[18:08] <dbarth> ogra_: i think that's required
[18:08] <dbarth> #18 will have that out-of-sync set of packages between friends and OA
[18:08] <ogra_> indeed :) lets wait for popey ... but we can definitely go back to that one
[18:08] <sil2100> dbarth: 17 still has that...
[18:08] <dbarth> the same package set?
[18:08] <sil2100> dbarth: friends-app landed in 16 :<
[18:09] <sil2100> dbarth: that is why I wanted 19 promoted, as I knew it will fix any outstanding friends-app issues
[18:10] <popey> flashing now...
[18:10] <sil2100> dbarth: but it seems this big regression slipped through our hands
[18:10] <sil2100> Ok guys, I need to go now, leaving things in ogra_'s hands:
[18:10] <sil2100> - If popey gives a +1 on the issue fixed in 18, let's promote 18 as 20
[18:10] <sil2100> - If there are doubts, promote 17 as 20
[18:11] <sil2100> - In the meantime, please land the revert :)
[18:11] <ogra_> which package is that for ?
[18:11] <ogra_> ah, i see it
[18:12] <sil2100> ogra_: it's ubuntu-system-settings-online-accounts
[18:12] <sil2100> ogra_: I'll push the revert to trunk now, ok?
[18:12] <ogra_> yeah, its in the paths ...
[18:12] <ogra_> ok, and i'll upload a deb
[18:12] <sil2100> Thank you :)
[18:12] <sil2100> ogra_: I'm thinking of reverting friends-app maybe as well, hmm
[18:13] <sil2100> Although not sure if I have the time to do that now ;p
[18:14] <ogra_> sil2100, hrm ...
[18:14] <ogra_> patching fails on the .po file
[18:14] <sil2100> Did I mess up something?
[18:14] <ogra_> i guess that got updated at build time
[18:15]  * sil2100 sighs
[18:15] <sil2100> btw. I won't push that to trunk, as I remember Didier saying we don't have to
[18:15] <sil2100> Since it's a temporary revert
[18:15] <popey> 18 is broken too it seems...
[18:15] <ogra_> i can just cut that file out of the patch ... but not sure if anything breaks then
[18:16] <sil2100> ogra_: no, I guess let's not upload
[18:16] <ogra_> sil2100, lets eave it in the hands of the owners
[18:16] <popey> shall i confirm 17 is okay?
[18:16] <sil2100> popey: yes, please :)
[18:16] <ogra_> proposed is not guaranteed to be working all the time
[18:16] <sil2100> ogra_: so, 18 is bad, so let's give popey a moment to check 17 and could you re-promote that one?
[18:16] <dbarth> so #19 is -proposed or stable?
[18:16] <ogra_> can as well be broken over the weekend (just announce it in a mail)
[18:17] <ogra_> dbarth, both currently
[18:17] <ogra_> well, stable is trusty ...
[18:17] <ToyKeeper> ogra_: I didn't drop the bug; people asked me to change focus a bit and not re-test so many bugs every time.
[18:17] <popey> will take 20 mins to download and flash
[18:17] <dbarth> ah
[18:17] <ogra_> devel vs devel-proposed
[18:17] <ogra_> (stable is not used by anyone or promoted anywhere anyway)
[18:17] <ogra_> its always devel vs devel-proposed
[18:18] <ogra_> ToyKeeper, well, i have a "fix" (by adjusting the haptics to sane values) ...
[18:18] <ToyKeeper> Good news.  :)
[18:19] <ogra_> yeah, i got tired by being scared that all screws will loosen over time :)
[18:19] <popey> hah
[18:21] <sil2100> popey, ogra_, dbarth: thanks for your swift reactions to the problem :)
[18:21] <popey> np, lets add a manual test to find this next time ☻
[18:21] <sil2100> Sorry for making this slip, but I guess we'll make sure such a thing doesn't happen again!
[18:22] <ogra_> :)
[18:22] <sil2100> See you later - I'll be reading e-mails in case something else explodes ;_;
[18:22] <ogra_> sil2100, can you actually write one too ?
[18:22] <sil2100> ogra_: just did
[18:22] <popey> ogra_: if you cpoy #17 to #20 then wont it be #17 internally?
[18:22] <ogra_> so people know about the broken accounts over the weekend
[18:22] <ogra_> ah, good
[18:22] <ogra_> popey, nope
[18:22] <sil2100> I hope I made it clear that it will be broken
[18:23] <sil2100> See you guys o/
[18:23] <popey> ok, you know best ☻
[18:23] <ogra_> enjoy
[18:23] <popey> see you sil2100
[18:23] <ogra_> popey, i will copy from -proposed again ... that process actually generates a new image on top of 19 in devel
[18:24] <popey> neat
[18:40] <popey> ogra_: 17 looks good
[18:40] <ogra_> ok, pushing (or trying at least ... i hope it works like i think :P )
[18:41] <popey> hehe
[18:42] <ogra_> [18:42] <ogra_> :)
[18:42] <ogra_> seems to have worked
[18:43] <popey> I'll try and upgrade
[18:44] <popey> my #19 phone doesnt see it yet
[18:44] <dbarth> same here
[18:47] <ogra_> my 17 one des
[18:48] <ogra_> (blank updater window now ... but i expect it to finish)
[18:48] <robru> ogra_, hm, just tried ubuntu-device-flash and it tries to flash 19
[18:48] <ogra_> robru, with the devel channel ?
[18:48] <davmor2> all I see on 19 is File manager update
[18:49] <popey> oh
[18:49] <popey> mine is devel-proposed
[18:49] <ogra_> lol
[18:49] <robru> ogra_, oh, utopic-proposed
[18:49] <ogra_> yeah, i dont touch that
[18:49] <popey> i have a non-proposed phone too
[18:49] <popey> will get that
[18:50] <dbarth> any chance to get it on #19 or should i ubuntu-device-flash?
[18:50] <popey> yay, 17 is getting 20
[18:50] <popey> nice one ogra_
[18:51] <ogra_> ;)
[18:51] <davmor2> software is now up-to-date :(
[18:51] <popey> davmor2: what channel?
[18:51] <davmor2> popey: devel-proposed
[18:52] <ogra_> see backlog :)
[18:53] <ogra_> 17 from devel-proposed became 20 in devel
[18:53] <ogra_> devel-proposed didnt change
[18:53] <ogra_> (and will only change to 20 once there is a new build)
[18:54] <davmor2> ogra_: booo!
[18:54] <popey> cron will mean you'll get a new image tomorrow
[18:55] <davmor2> popey: indeed
[18:55] <ogra_> yeah, and then 20 wont be what you would expect ;)
[18:55] <popey> thanks for sorting that out ogra_
[18:55] <ogra_> np
[18:56] <davmor2> ogra_, popey: I'm assuming this is just a cowboy to fix the accounts issue right?
[18:56] <ogra_> yup, system info says i'm on 20
[18:56] <mardy> dbarth: hi! Yes, friends indeed needs to be reverted as well
[18:56] <dbarth> mardy: we're reverting to 3 images back to be safe
[18:56] <mardy> dbarth: I'm a bit surprised by this bug, I wonder how that's possible...
[18:57] <dbarth> however that whole set of hacks to get around the absence of the trusted session
[18:57] <dbarth> i think that needs to go
[18:57] <dbarth> and disable account creation until this is fixed
[18:57] <mardy> dbarth, robru: could it be that not all packages where installed?
[18:58] <mardy> I mean, updated
[18:58] <dbarth> mardy: i tried, it works fine for the testlogin account but the ui for creating accounts with a web interface; that ones never shows up
[18:58] <robru> mardy, I doubt it. for that to be the case, some of the packages would have to be held in -proposed, but I don't see anything there.
[18:59] <mardy> dbarth, robru: something like this could happen if u-s-s-o-a is updated, but not  qtdeclarative5-online-accounts-client0.1
[18:59] <dbarth> mardy: where can i see logs that say what happens once the web pocess starts (or not?)
[18:59] <dbarth> i looked into dbus.log
[18:59] <dbarth> but it says [19:00] <dbarth> mardy: ah, and there is no version lock in the packaging?
[19:00] <dbarth> ie requiring an exact identical vesion to tie them
[19:00] <mardy> dbarth: no, forget what I wrote, it cannot be that
[19:01] <mardy> robru: this didn't land, did it? https://code.launchpad.net/~mardy/unity-mir/signonui-with-oxide/+merge/216845
[19:02] <robru> mardy, doesn't look like it
[19:02] <mardy> dbarth: it's weird, I don't think we changed anything that would impact that
[19:02] <robru> mardy, should it have? if it was landed it would be merged.
[19:02] <mardy> robru: no, it shouldn't have
[19:03] <mardy> dbarth: but this worked in the silo, didn't it?
[19:04] <dbarth> mardy: this is what landed: http://pastebin.ubuntu.com/7422936/
[19:04] <mardy> dbarth: looks fine
[19:05] <dbarth> mardy: it did, but i was testing with TestLogin mainly
[19:05] <mardy> dbarth: right
[19:06] <dbarth> can't remember if i did the twitter manual test all along on that image; and that image was probably around #16 when i did
[19:09] <dbarth> mardy: where does signon-ui put its logs then?
[19:09] <mardy> dbarth: standard output. You must kill it, and then:
[19:09] <mardy> export SSOUI_LOGGING_LEVEL=2
[19:10] <mardy> export SSOUI_DAEMON_TIMEOUT=9000
[19:10] <mardy> dbarth: then run signon-ui and try to create an account
[19:11] <dbarth> actually, i remember that it worked for twitter, so that's another change that crashed it
[19:11] <dbarth> mardy: ok
[19:13] <dbarth> mardy: what's the cmd line to stat it; even with a desktop_file_hint i won't see anything on screen
[19:13] <dbarth> ?
[19:16] <mardy> dbarth: check /usr/share/dbus-1/services/com.nokia.singlesignonui.service
[19:16] <mardy> I think it was just /usr/bin/signon-ui
[19:17] <dbarth> it is but that doesn't display anything
[19:17] <mardy> robru: were there landings of unity8, mir or unity-mir in these latest images?
[19:18] <dbarth> mardy: /usr/bin/signon-ui --desktop_file_hint=/usr/share/applications/signon-ui-browser-process.desktop
[19:18] <robru> mardy, there was a unity8 landing recently, let me check
[19:18] <mardy> dbarth: OK, try that then
[19:18] <robru> mardy, yeah, #18 had unity8 http://people.canonical.com/~ogra/touch-image-stats/18.changes
[19:19] <mardy> robru: I have a suspicion
[19:19] <mardy> robru: I bet that if those libsignon-* packages are reverted, it will work
[19:20] <mardy> robru: or, in alternative, signon-plugin-oauth2 must be rebuilt
[19:20] <robru> mardy, ok, should I start a silo with a no-change rebuild of signon-plugin-oauth2?
[19:21] <mardy> robru: yes please
[19:21] <robru> (better than reverting if it'll work)
[19:21] <robru> ok
[19:21] <dbarth> mardy: which packages?
[19:21] <dbarth> the account plugins?
[19:22] <mardy> dbarth: no, someone uploaded signond (and its libraries) to move the libs from /usr/lib/ to /usr/lib/$ARCH
[19:22] <dbarth> oh!
[19:22] <mardy> dbarth: but that path also affects the location where signond will look for plugins
[19:22] <dbarth> ugh
[19:22] <mardy> dbarth: so the oauth2 plugin is not found
[19:23] <dbarth> i'll try a symlink to confirm
[19:23] <mardy> dbarth: yes thanks. IIRC, it's in /usr/lib/signon/
[19:23]  * mardy brb
[19:29] <dbarth> mardy: not sure what to symlink from / to
[19:29] <dbarth> mardy: i tried all sorts of them, but that doesn't seem to solve the issue
[19:30] <dbarth> mardy: which .so should i move? oauth2 or the whole set of libsignon-something?
[19:30] <robru> dbarth, mardy: ok I have that rebuild going in silo 4, will test that on image #19 as soon as it's done
[19:35] <mardy> dbarth: my VM is off, but you should symlink all the files which currently are in /usr/lib/signon/ to /usr/lib/armhf.../signon/
[19:37] <dbarth> mardy: ah, that i haven't tried
[19:37] <dbarth> uh yes i did
[19:38] <dbarth> there is just liboauth2plugin.so as far as i can see
[19:39] <dbarth> mardy: uh it's all over the place: there is stuf in /usr/lib/signon and /usr/lib/armhf and in /usr/lib/armhf.../signon/
[19:40] <robru> mardy, ugh, no-change rebuild is failing: https://launchpadlibrarian.net/175042956/buildlog_ubuntu-utopic-amd64.signon-plugin-oauth2_0.19%2B14.10.20140509-0ubuntu1_FAILEDTOBUILD.txt.gz
[19:40] <dbarth> ok, you need to link from /usr/lib/signon to /usr/lib/armhf.../signon
[19:40] <dbarth> and then it works again
[19:40] <mardy> robru: oh, indeed, because now files are installed in a different place
[19:40] <dbarth> mardy, robru ^^ this is the change that broke OA account creation support
[19:41] <robru> mardy, well as far as I can see in the error, you just need to update debian/*install to the current expectations.
[19:41] <mardy> robru: would you be able to fix the debian packaging? should be a matter of changing "usr/lib/signon/*.so" to "usr/lib/*/signon/*.so"
[19:42] <dbarth> right
[19:42] <dbarth> robru: i guess it's over for promoting another one this week-end, isn't it?
[19:43] <robru> dbarth, pretty much...
[19:43] <robru> dbarth, unless you can sweet-talk the dogfooders + ogra to put in some weekend hours
[19:43] <robru> dbarth, but we can at least get this fixed for promotion on monday
[19:44] <dbarth> we should be back to the safe zone with the image that was reverted to
[19:45] <dbarth> ogra_: ^^ right? so we can prep. this one calmly for promotion on monday
[19:45] <dbarth> mardy, robru: thanks for the quick turnaround on this btw
[19:50] <robru> you're welcome
[19:59] <robru> mardy, oh, missed your message. yeah I can make that change
[20:07] <dbarth> thanks robru
[20:08]  * dbarth going eow now
[20:08] <robru> dbarth, have a good weekend!
[20:08] <robru> building now: https://ci-train.ubuntu.com/job/landing-004-1-build/63/console
[20:08] <dbarth> cool
[20:11] <bfiller> robru: need a silo for line 28 please
[20:12] <robru> bfiller, silo 5
[20:16] <bfiller> robru: getting this weird error when trying to build silo 5: bfiller is missing the Job/Build permission
[20:17] <robru> oh god
[20:17] <robru> bfiller, it seems you and everybody else. there's an RT open for this
[20:17] <robru> ...
[20:17] <robru> bfiller, https://rt.admin.canonical.com/Ticket/Display.html?id=70171&results=cc511376a9798e5b669d6f9015596abf
[20:17] <bfiller> robru: ah ok
[20:18] <robru> bfiller, so I can just hit build for you there for now
[20:18] <robru> in fact just ping me for anything really
[20:19] <bfiller> robru: yes please :)
[20:19] <robru> bfiller, merge conflict: https://ci-train.ubuntu.com/job/landing-005-1-build/48/console
[20:20] <bfiller> doh
[20:20] <bfiller> renato: ^^^
[20:20] <bfiller> renato: trying to build new silo there is a merge conflict
[20:21] <bfiller> robru: lines 29 and 30 need silos too and builds kicked off
[20:22] <robru> sure
[20:54] <renato> robru, bfiller I will fix
[20:57] <robru> renato, thanks
[20:58] <robru> popey, davmor2 hey are either of you around? I believe silo 4 contains a fix for bug 1317986, please test it (works for me on mako).
[20:59] <robru> mardy, dbarth ^
[21:00] <renato> robru, bfiller, fixed
[21:01] <robru> renato, alright, rebuilding
[21:01] <popey> urochord i am
[21:01] <popey> er
[21:01] <popey> robru: i am
[21:02] <robru> popey, cool. yeah, image #19 + silo 4, and I was able to add an account.
[21:02] <popey> ok, lemme fresh flash
[21:05] <robru> renato, bfiller: still conflicting: https://ci-train.ubuntu.com/job/landing-005-1-build/49/console
[21:05] <renato> robru, fixing
[21:11] <renato> robru, fixed
[21:11] <robru> building
[21:11] <renato> robru, I have update the MR: https://code.launchpad.net/~renatofilho/sync-monitor/remove-addressbook/+merge/219073, do you need to change something ?
[21:11] <renato> I added "lp:~renatofilho/sync-monitor/i18n" as prerequisite
[21:12] <robru> renato, is that the same MR or a new one?
[21:13] <renato> I resubmitted the proposal
[21:14] <robru> renato, oh yeah, have to reconfig with the new URL, thanks
[21:16] <robru> renato, please add the commit message on the new MP
[21:16] <renato> robru, sorry
[21:16] <renato> robru, done :D
[21:17] <robru> finger crossed: https://ci-train.ubuntu.com/job/landing-005-1-build/52/console
[21:19] <popey> robru: got a link to silo 4?
[21:20] <robru> popey, https://launchpad.net/~ci-train-ppa-service/+archive/landing-004
[21:20] <popey> ta
[21:20] <robru> popey, also helpful: https://github.com/robru/dotfiles/blob/master/.profile.d/citrain.sh#L39
[21:22] <popey> ooh
[21:24] <popey> its just finished flashing so won't be long to test
[21:24] <robru> sweet
[21:24] <popey> you gonna kick an image or leave it for cron?
[21:24] <robru> popey, probably leave it for cron...
[21:25] <popey> yeah
[21:25] <robru> not urgent since we got that reverted image promoted
[21:25] <popey> yeah
[21:42] <robru> any luck popey?
[21:44] <popey> robru: sorry, yup
[21:44] <popey> looks good to me
[21:44] <popey> better than it was before, auth windows are sized correctly
[21:56] <robru> popey, great, I'll publish it
[21:56] <Laney> how come that works without you having to change LIBDIR in debian/rules?
[21:57] <robru> Laney, because I have no idea what I'm doing. ;-)
[21:57] <Laney> I think it's weird that it does work!
[22:35] <robru> lunchtime!