[00:52] <cyphermox_> awe: disregard messages you may see here, the publication is in progress
[00:52] <cyphermox_> ofono publication, that is
[00:59] <cyphermox_> lies
[01:01] <cyphermox_> awe_: had to manually copy the pacakge, it looks like it was borked again, I'll watch the publication
[01:02] <cyphermox_> it's in proposed now
[01:02] <cyphermox_> brb
[01:06] <awe_> thanks cyphermox_
[01:58] <jdstrand> infinity: wrt eglibc-- you are core-dev and only features have to get QA signoff. if this is a bugfix update and you are happy with the changes, then I think we could just copy it. that said, if you want, I can work with the landing team tomorrow to get an rtm silo for it, and I can install it on my phone and comment in the spreadsheet
[01:59] <jdstrand> infinity: as you said before, we could just copy the binaries into said silo, then I could test. otherwise, we can wait for cjwatson to come online and make the call to avoid the silo or not
[02:02] <ToyKeeper> bzoltan: Not sure when you'll be around, but I've been following up on UITK.  I'll have some adjustments for the test plan, most likely.  Also I'm a little confused why phablet-click-test-setup fails on UITK.
[02:03] <ToyKeeper> bzoltan: There was a reasonably good response about extending CI tools for personal use, though also a bit of confusion about the actual goal.
[02:04] <imgbot> [02:07] <infinity> jdstrand: Colin didn't have an obvious opinion on silo versus not, but agreed that copying the binaries is the only sane thing (whether to PPA or straight to RTM)
[02:08] <infinity> jdstrand: If you want to do the silo paperwork, go nuts and ask for an empty one, some of us (like me) have the powers to copy directly to them, so I can do that if you have one assigned. :P
[02:09] <jdstrand> infinity: I kept saying eglibc. of course I meant glibc
[02:10] <infinity> jdstrand: Hard habit to break. :)
[02:10] <jdstrand> indeed
[02:11] <jdstrand> infinity: so, ubuntu-rtm has 2.19-4ubuntu2  and utopic 2.19-10ubuntu1
[02:11] <jdstrand> infinity: you are comfortable with the -5 - -10 changes?
[02:11] <jdstrand> as in, there isn't anything there that should affect ubuntu-rtm/14.09?
[02:12]  * jdstrand realizes he can just grab said binaries from the archive and put them on his phone
[02:15]  * jdstrand does so
[02:16] <jdstrand> infinity: I'd rather not do an rtm only patch, but want your explicit opinion. I've installed the binaries on my rtm phone
[02:20] <jdstrand> oh heh, phablet-shell just *might* work a bit better if I plug in my phone
[02:21] <jhodapp> cyphermox_, what's wrong with it?
[02:26] <infinity> jdstrand: I have zero issues with those changes going into RTM.
[02:27] <jdstrand> ok
[02:27] <infinity> jdstrand: Most don't affect ARM one way or the other, some are small packaging nits, etc.
[02:27] <jdstrand> I rebooted with it and it all seems good. let me use my phone for a bit and I'll coordinate with you tomorrow. thanks!
[02:27] <infinity> jdstrand: The only real change-change is dropping some manpages (which we need a manpages merge for, now that I think about it), but I doubt anyone gives a damn about a few missing manpages on a phone if we forget to also copy over the manpages merge for the takeover.
[02:28] <jdstrand> infinity: no, they won't. man isn't even on the phone :)
[02:28] <infinity> jdstrand: Right, which is one of the reasons we're trying to drop manpages and move them to the manpages package. :P
[02:29] <jdstrand> $ man man
[02:29] <jdstrand> -bash: man: command not found
[02:29] <jdstrand> ah
[02:29] <infinity> jdstrand: Well, not phone specifically, but just that people with libc installed really shouldn't expect bloaty docs with it.
[02:29] <infinity> jdstrand: That, and we're sick of maintaining them. ;)
[02:29] <jdstrand> infinity: k, so you and I can handle this. we'll speak on it here so everyone knows what is happening, but I fuly expect us to do the binaries pocket copy tomorrow
[02:30] <infinity> jdstrand: Works for me.
[02:30]  * jdstrand happens to like those docs, but I also have man installed :)
[02:30] <infinity> jdstrand: Right, proper unixy people and developers have manpages and manpages-dev installed, so you get all the goodness.
[02:32]  * jdstrand nods
[03:04] <imgbot> [03:21] <bzoltan> ToyKeeper:  sounds good. The actual goal would be to validate regularly core components, like Qt, UITK, Unity, etc
[03:49] <bzoltan> Is the phablet-click-test-setup expected to work with the rtm image #31? Or is there a trick to make it work?
[03:49] <imgbot> [03:49] <imgbot> [03:51] <bzoltan> ToyKeeper: how the phablet-click-test-setup fails on UITK? For me the relevance of the UITK pulled down by this tool is zero. The first thing I do is to remove the ~phabet/autopilot/ubuntuuitoolkit
[03:51] <bzoltan> ToyKeeper:  but yet again, these tools need black magic. For example you can not set up the cick tests if you have a silo added to the sources.
[03:55] <Mirv> robru: spreadsheet seems fixed now?
[03:55] <Mirv> or at least it has updated since yesterday
[04:14] <Mirv> ok about ~everyone should be happy again with silos
[04:16] <ToyKeeper> bzoltan: The click setup failure didn't provide a very useful error; am planning to go back and find out more later.
[04:19] <imgbot> [04:19] <imgbot> [04:23] <Mirv> well, almost...
[04:28] <bzoltan> ToyKeeper:  check if you have the silo PPA enabled. that could be a troublemaker
[04:29] <ToyKeeper> Yes, I have the silo PPA enabled.  It didn't seem to be an issue.
[04:41] <bzoltan> Mirv:  I git this from the silo3 "2014-09-10 04:40:03,595 WARNING A version (3.1.1+14.10.20140908-0ubuntu1) is available at the destination archive for that component but is not in the destination branch which is still at 3.1.1+14.10.20140903.3-0ubuntu1. You need to ensure that your version contains the fix in the destination or you can force rebuild to bypass the check."
[04:44] <bzoltan> Mirv:  forced rebuild seems to help... but that is not very logical
[05:30] <Mirv> hmm, bzoltan disappeared
[05:58] <robru> Mirv: yeah, ENOSPACE truncated some silos which broke spreadsheet updating and also queuebot. Fixed it early in my shift. Should be fine now but still syncs escape me.
[06:00] <Mirv> robru: excellent, thanks! where/how did you fix it?
[06:01] <Mirv> the spreadsheet was a bit messed up again otherwise too - id:s disappearing, id:s on wrong rows (!). managed to fix them all by comparing with landed packages and the dashboard
[06:01] <Mirv> that's however "usual"
[06:02] <Mirv> robru: oh, you might maybe have access to some server too? I remember some hunting for truncated files in the past.
[06:05] <robru> Yeah in the Jenkins there's a job called cyphermox-test, you can edit it to do arbitrary shell execution on the server, so you have to poke around a bit. There were two files named config that were zero length and causing json parsing errors. I nuked the whole silos and reassigned, then it was good
[06:06] <Mirv> ha, of course, the good ol' cyphermox-test ;)
[06:06] <robru> Mirv: saved my butt so many times ;-)
[06:07] <robru> Mirv: OK I'm in bed with a high fever, good luck today.
[06:08] <Mirv> robru: uh oh :( rest well
[06:46] <brendand> Mirv, looks like you get the next landing by virtue of being present
[06:47] <Mirv> brendand: :D it's more kalikiana really regarding details and testing, but he should be around too
[06:49] <ToyKeeper> bzoltan: To get things running, I had to strip out all the flash/install bits and reduce/modify the auto-rebooting.  Plus manual setup beforehand, using bits from the silo and rtm instead of source and non-rtm feeds.  It's still only so-so though, with a lot of tests failing completely.
[06:50] <ToyKeeper> I'm not sure if anyone can pick it up from here or if it needs me to keep pushing on it...  but I will need to get back to regular silo testing in the morning.
[06:51] <ToyKeeper> bzoltan: I think I'll let it run overnight though, in hopes that the latest changes I made will help.
[06:58] <bzoltan> ToyKeeper:  i would not suggest to modify that script so radically ... there is a good reason for each line there. I burned my hand with UITK validation several times ... rebooting is good, regardless who says what. I have seen tests failing because they were run in a specific order. Some apps or tests just do not  quit in a clear way ...
[06:58] <bzoltan> ToyKeeper:  also, the install bits are necessary ... all the packages I listed will be needed by some app tests.
[06:58] <ToyKeeper> bzoltan: The flash/install bits have to be removed or disabled before I can even get a valid test result.
[06:59] <ToyKeeper> Setting up the SUT and running the tests are two logically independent steps.
[06:59] <bzoltan> ToyKeeper:  just do not give the -c parameter and it will not cflash
[06:59] <bzoltan> ToyKeeper:  Sorry my ignorance :) but what is SUT?
[06:59] <ToyKeeper> System Under Test
[07:00] <bzoltan> ToyKeeper:  Sound scientific :) what is that?
[07:01] <ToyKeeper> Heh, it's exactly what it says it is...  but without reusing the same words, it's the device+config on which the tests will be run.
[07:01] <bzoltan> ToyKeeper:  I put the commissioning steps in my script because they take time and I run that script mostly by night .. daytime I do not use the -c
[07:01] <ToyKeeper> I provision the device with scripts too, but they're separated from the scripts used for testing.
[07:02] <bzoltan> ToyKeeper: It is a separated function in my tool too. But the UITK test plan starts with provisioning.
[07:02] <ToyKeeper> Almost every test plan starts with provisioning.
[07:03] <bzoltan> ToyKeeper:  but it is not relevant. You do not need to remove the code.. just do not use the -c and that is it.
[07:03] <ToyKeeper> I didn't remove it, just made sure it wouldn't execute.
[07:04] <bzoltan> ToyKeeper: not giving the -c makes it very sure :)
[07:04] <ToyKeeper> I initially tried to disable all the rebooting too, but found that a lot of tests wouldn't even run when executed in sequence.
[07:04] <ToyKeeper> Some of the other failures I'm not totally sure about.  Like the gallery test works for a while then completely barfs when it tries to manipulate the image database.
[07:07] <ToyKeeper> In any case, I just wiped it and am getting it ready for an overnight run.
[07:07] <bzoltan> ToyKeeper:  yeps, that is why I reboot all the time .. I rather waste 1-2 minutes on each reboot than 4-6 hours on a blocked nightly test
[07:08] <bzoltan> ToyKeeper:  also the camera tests just hang .. i put it last in the sequence for that reason.
[07:09] <bzoltan> ToyKeeper:  also importan, that click test setup  will fail if you have added the PPA aready ... so first flash, then click setup and only after that add the PPA
[07:09] <ToyKeeper> BTW, if you start with a debian-packaged test instead of a click app, I don't think it needs the manual package installation before the tests start.
[07:09] <bzoltan> ToyKeeper:  and be careful with the apt-get upgrade ... it might bring unwanted packages
[07:09] <bzoltan> ToyKeeper: I do not trust the tests... I trust apt-get install
[07:10] <bzoltan> ToyKeeper:  if the device looses the network (seen that) during the tests then the missing packages can screw up the tests... so I play safe and install all the AP packages first.
[07:10] <ToyKeeper> The tests keep their dependencies up to date by necessity; the test harness can easily get its deps out of date.  It's the wrong place to put that information.
[07:11] <bzoltan> ToyKeeper:  I keep my eye on the deps. I trust my eyes.. i do not trust the tests. And as I said I realized that offline tests are safer.
[07:11] <ToyKeeper> Oh, er, also...  I had to update the click setup for rtm:  phablet-click-test-setup --distribution=ubuntu-rtm --series=14.09
[07:12] <bzoltan> ToyKeeper:  Coool. that is what i was looking for! Thank you a lot.
[07:12] <ToyKeeper> I think it had been pulling regular ubuntu bits instead of rtm bits, which invalidated all the test results.
[07:13] <bzoltan> ToyKeeper:  yeps... you saved my day :)
[07:13] <ToyKeeper> But I can't get that to work on UITK.  It seems to work on everything else though.
[07:14] <ToyKeeper> "Fetching ubuntu-ui-toolkit - into /tmp/tmppIkYZ1"  ...  "IndexError: list index out of range"
[07:15] <ToyKeeper> This bit fails: get_source_package_tests(package['source'], version, test_dir)
[07:15] <ToyKeeper> For now, I'm working around it by catching and printing the exception instead of bailing.
[07:16] <brendand> ToyKeeper, someone else can take over - it's pretty late for you, no?
[07:16] <ToyKeeper> brendand: Yes, it's pretty late...  I'm heading to bed as soon as I start this test.  It'll take like 6 hours to finish anyway.
[07:17] <ToyKeeper> The provisioning is ... a bit uncertain though, so that's manual for now.
[07:17] <brendand> ToyKeeper, did you ever try ci teams provision.sh?
[07:18] <ToyKeeper> brendand: The idea right now is to get bzoltan and QA testing the same bits using the same process, so the test results can be compared.
[07:19] <ToyKeeper> Some part of the process is producing different test results, and I've been investigating why.
[07:20] <bzoltan> brendand: ToyKeeper:  A side question :) Why do you want to run exactly the same tests I have run like 6 times? Should not the QA validation mean some manual sanity test?
[07:21] <bzoltan> ToyKeeper:  disable the music tests if you want to sleep :D
[07:21] <ToyKeeper> bzoltan: QA should be doing the manual bits, not the AP bits...  but UITK has only AP bits.  And more importantly, developers and QA need to have the same set of tests.
[07:22] <ToyKeeper> The test plan for a project is (or should be) the one and only plan in use.
[07:22] <bzoltan> ToyKeeper:  Running the same AP tests on a totally different RTM image is as pointless as using different test tools ...
[07:23] <brendand> bzoltan, have you provided us your results yet?
[07:23] <bzoltan> ToyKeeper:  we have two blocked UITK landing in the RTM queue ... you will not get the same results for 28.08 UITK on #31 as I got on #22 .
[07:23] <ToyKeeper> Maybe the image gets bumped between publishing a silo and landing it...  in which case it's kind of important to re-test before landing to make sure it still works.
[07:24] <bzoltan> brendand:  I have hundreds of logs on my machine... when I flip the "tested" switch on the CI sheet it means that I have run the UITK test plan and I have the same or less failures as on the CI dash.
[07:25] <bzoltan> ToyKeeper:  it sounds very redundant to me
[07:25] <brendand> bzoltan, if you could zip up the xml files and link them somewhere that would be great
[07:25] <bzoltan> brendand:  i do not do xml files
[07:26] <brendand> bzoltan, you don't keep any sort of verbose output from autopilot?
[07:26] <ToyKeeper> brendand: The logs are saved, just not in XML.
[07:26] <ToyKeeper> It's custom.
[07:26] <bzoltan> brendand: do you guys really want me to send you the test results of the previous UITK landing form the last week? They are kind of otdated by now
[07:27] <bzoltan> ToyKeeper: not custom, I use the standard tool...
[07:27] <bzoltan> ToyKeeper: phablet-test-run
[07:27] <brendand> bzoltan, i would actually
[07:27] <ToyKeeper> Well, the test tool is standard, the logging is custom.
[07:27] <bzoltan> ToyKeeper:  the xml is custom :) and it is not good for local tests
[07:28] <bzoltan> brendand:  I have hundreds of files all very verbose
[07:28] <brendand> bzoltan, the format is not that important, what's import is that there is a detailed log that has the results of all the tests and the output of any failed ones
[07:28] <brendand> bzoltan, like we got on the ci dashboard
[07:29] <bzoltan> brendand: ToyKeeper: but to be honest, i would prefer to focus on the 05.09 RTM validation instead of digging up ancient test results on ancient image
[07:29] <ToyKeeper> bzoltan: It would indeed be very helpful to have the test logs for each new silo available.
[07:30] <brendand> bzoltan, you shouldn't have to 'dig them up'
[07:30] <brendand> bzoltan, they should be somewhere you can just give us the link to and we never need to ask again
[07:30] <brendand> bzoltan, like people.canonical.com
[07:30] <bzoltan> brendand: ToyKeeper: Earlier I used to pastebin all the logs .. but nobody seemed to care :) People simple beleived when I said that it is tested.
[07:32] <brendand> bzoltan, it really should be way easier just to tar them up and scp them to people.canonical.com
[07:32] <brendand> bzoltan, store them by version or whatever and just give us (or anyone else who asks) a link to the root directory
[07:32] <ToyKeeper> Well, sort of.  We're kind of hoping that each silo will have a link for a test plan (including tests for changes made / bugs fixed in the silo) and a link for the test logs.
[07:33] <ToyKeeper> Okay, maybe I made the reboot timings a bit slow...  but it at least appears to be working now.  Almost time to sleep.
[07:34] <bzoltan> brendand:  sure i can do that
[07:34] <bzoltan> brendand:  But keep in mind that we have no tools for doing these.. .so I need to invent my own :)
[07:35] <bzoltan> brendand:  It is all happening, but slowly ... and to be honest, the changing platform does not make my job easier :)
[07:36] <brendand> bzoltan, i think you might be missing something then - phablet-test-run should definitely be able to provide some kind of detailed log, you then just copy that off the device
[07:36] <brendand> bzoltan, if a test fails, where do you look to get a clue as to why?
[07:36] <ToyKeeper> brendand: The script saves the output of phablet-test-run to a file.
[07:37] <ToyKeeper> The full test result is a directory of these logs, with test names and time stamps.
[07:37] <brendand> ToyKeeper, that's just stdout though isn't it?
[07:38] <ToyKeeper> It's the terminal output, not the full log from the device.
[07:38] <brendand> there should be something that has the traceback if the test fails
[07:38] <brendand> ToyKeeper, do you have the output of bzoltan's script? can you scp it somewhere?
[07:39] <ToyKeeper> brendand: I see tracebacks in the logs.
[07:39] <ToyKeeper> ... and the only results I have so far are somewhat ... broken.  I'm attempting to get a valid result overnight.
[07:40] <ToyKeeper> brendand: If you want to investigate, it's all linked from the test plan in the wiki.  But you'd be starting from scratch and it could take a while to get things functioning.
[07:41] <brendand> <sad face>
[07:41] <ToyKeeper> Once I get things working I'll add the steps to the test plan.
[07:42] <ToyKeeper> For now though, sleep.  :)
[07:42] <bzoltan> brendand:  Sorry, I was not clear. I am running phablet-test-run with full logs... as it runs that way by default. And I have millions of lines of logs of each test run.
[07:43] <bzoltan> ToyKeeper:  just please do not modify the UITK test plan without me :) After all, it is my job to run those tests...
[07:45] <bzoltan> brendand:  so.. let's clarify few things :) I am running the app tests with phablet-test-run and log  the full output to a file. It has all the traceback what we needed so far. Is there something more than that on the device after the phabelt-test-run is done?
[07:46] <brendand> bzoltan, in my experience the output of phablet-test-run is not verbose enough, but maybe you did something a bit different. until i see the logs i can't really judge
[07:46] <bzoltan> brendand: http://paste.ubuntu.com/8307160/ this is an example... the output of the reminder app tests
[07:47] <brendand> bzoltan, okay that seems fine
[07:47] <brendand> bzoltan, all of those uploaded to people.canonical.com would be perfect
[07:48] <bzoltan> brendand:  hmmm... nice that AP puts there the file listing :D :D :D Please ignore the inappropriate words :D
[07:53] <brendand> Mirv, i hope this silo didn't break location
[07:53] <brendand> Mirv, i thought it was meant to be working in RTM right now?
[08:07] <asac> lool: bq phone crashes after wizard
[08:07] <asac> did we not add mterries fix?
[08:07] <Saviq> can someone delete lp:~ps-jenkins/unity8/ubuntu-utopic-proposed ? it's got bad tags
[08:07] <Saviq> trainguards ↑?
[08:08] <seb128> Saviq hates tags ;-)
[08:08] <Saviq> seb128, I do, I hate bzr for being stupid about them, too
[08:08] <seb128> Saviq, what's the issue with tags? I don't even notice they exist...
[08:08] <Mirv> brendand: kalikiana reported at least that everything worked great with it
[08:08] <seb128> can't you just not care/ignore the buggy ones?
[08:08] <Saviq> seb128, no
[08:08] <Saviq> NO
[08:08] <Saviq> NOOO
[08:08] <Mirv> kalikiana: see brendand's questions about locationing ^
[08:09] <seb128> by principle?
[08:09] <Saviq> seb128, yeah, more than anything else
[08:09] <brendand> Mirv, just trying with the stock image now
[08:09] <Mirv> Saviq: we don't have rights to ~ps-jenkins
[08:09] <brendand> Mirv, i noted that he tested on mako
[08:09] <seb128> Saviq, k, so you decide to create issues for yourself...?
[08:09] <Saviq> seb128, it just makes me cry a little
[08:09] <Saviq> seb128, no, bzr + lp created it for me by making them viral
[08:09] <Mirv> brendand: on the other hand, the actual positioning we have happens way below Qt, so I think it couldn't break it
[08:09] <seb128> Saviq, is that a bzr bug?
[08:10] <seb128> or launchpad?
[08:10] <asac> lool: also osmtouch tells me no GPS availalble on krillin even after accepting terms
[08:10] <asac> lool: thought this was only on N4 a race?
[08:10] <brendand> asac, so it might be broken anyway?
[08:10] <Saviq> seb128, unlikely, it's just how tags work in bzr (and in lp when you're under the same project)
[08:10] <ogra_> asac, i think tvoss and lool found other issues last night
[08:10] <Saviq> seb128, basically we got the tags from lp:unity when we were under lp:unity/8.0
[08:10] <asac> ogra_: for the wizard crash?
[08:10] <ogra_> (which i mentioned in the landing mail)
[08:11] <ogra_> asac, no, with the service startup
[08:11] <seb128> Saviq, I see, anyway sorry for asking, I was trying to understand if that cause practical issues since I didn't see much problems due to them (out of the fact that they shouldn't be there/buggy)
[08:11] <Saviq> seb128, so that was hundreds of tags that did not make sense in unity8's history
[08:11] <asac> brendand: wouldnt say so without knowing more... besides the wizard crashing it currently behaves like the N4 did a few days before
[08:11] <asac> have to wait for tvoss and lool and mandel tell me wats the situation on krillin
[08:12] <Mirv> brendand: the kalikiana's code change was in a map view component regarding where to save the offline tile cache to, not the actual positioning component.
[08:12] <Saviq> seb128, so one practical problem is that bzr craps out when trying to talk remotely to that branch in a few cases, complaining about missing revisions
[08:12] <Saviq> seb128, the other is just not being able to look through them easily
[08:14] <Saviq> seb128, but yes, mostly it's OCD
[08:14] <seb128> Saviq, thanks for explaining
[08:16] <Saviq> Mirv, do you know who does have access to it?
[08:17] <Mirv> Saviq: fginther mostly I think. at least his SSH key is mentioned at https://launchpad.net/~ps-jenkins
[08:17] <Saviq> Mirv, cool, thanks
[08:18] <brendand> asac, lool - at least for me it doesn't work here on krillin
[08:18] <brendand> asac, lool - i thought everyone was testing on krillin?
[08:18] <brendand> Mirv, i'll ask kalikiana more about his change
[08:23] <asac> brendand: well it was on utopic first so i tested it on my N4 that runs utopic ... need to wait for lool to tell us what the state is... we had a race wrt service startup though before
[08:23] <asac> soif its just that you need to run one command to make it work
[08:26] <asac> brendand: /var/log/upstart/ubuntu-espoo-service.log should show the coordinates you are at
[08:27] <brendand> asac, i get a position in there
[08:27] <brendand> asac, so why can't maps app use it?
[08:28] <kalikiana> Mirv: brendand the only change was the path to the tile cache - I saw that new packages were implicitly added that weren't there before related to positioning, I don't know who is in charge of these. for me positioning
[08:30] <kalikiana> +works fine
[08:34] <jodh> Mirv: hi - I've now tested the upstart packages from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-007/+packages on a device. Is that sufficient to mark the first level of testing as done (line 36 on spreadsheet)?
[08:43] <pete-woods> trainguards: hi folks. could I get silo 9 reconfigured (had to fix someone's branch who is on holiday) - https://ci-train.ubuntu.com/job/ubuntu-landing-009-0-reconfigure/build?delay=0sec
[08:43] <Mirv> jodh: well, there'd need to be a written testplan for the landing  (like https://wiki.ubuntu.com/Process/TestPlans/libusermetrics) so that the QA people know what to execute for their signoff
[08:43] <Mirv> jodh: otherwise yes
[08:47] <Mirv> pete-woods: done
[08:47] <pete-woods> Mirv: thanks! :)
[08:50] <pete-woods> I do like how unity8 comes out with a shades wearing emoticon every time the bot talks about it
[08:59] <brendand> Saviq, unity8 crashes when pressing 'Play in music app' for a track on the SD card
[09:00] <brendand> Saviq, can i install some symbols etc to get a good trace for you?
[09:01] <brendand> Saviq, it's a BadURL error, where does that come from?
[09:01] <brendand> Saviq, is it from url-dispatcher or elsewhere
[09:01] <brendand> ?
[09:07] <cjwatson> bzoltan: landing-003, "not in the destination branch"> something is definitely weird there.  http://bazaar.launchpad.net/~ubuntu-sdk-team/qtcreator-plugin-ubuntu/trunk/revision/255 has the substantive changes from 3.1.1+14.10.20140908-0ubuntu1, but not the changelog entry.  Is there something else fighting with citrain to land changes on that branch?
[09:08] <cjwatson> bzoltan: https://ci-train.ubuntu.com/job/ubuntu-landing-003-3-merge-clean/9/console says "Pushed up to revision 255", so I don't understand why the changelog would be missing ...
[09:09] <Saviq> brendand, yeah, that's url-dispatcher, but if u8 crashes when you try and open it, that will be a platform-api / qtubuntu bug
[09:09] <cjwatson> bzoltan: the proper way to resolve this for now is probably to grab the source package for the current version in the archive, and manually apply the changes in debian/changelog to your trunk branch.  but it's strange that it ended up this way
[09:09] <Saviq> brendand, even when url-d craps out, it should never bring down the calling app..
[09:09] <Saviq> brendand, as for symbols, best just use apport-cli to upload the crash to lp and let it retrace
[09:13] <cjwatson> bzoltan: (it would probably be a good idea to sort this out while your silo is still in the "Silo ready to build packages" state according to the dashboard ...)
[09:18] <jodh> Mirv: I've created https://wiki.ubuntu.com/Process/TestPlans/upstart - could you add that to the spread-sheet and arrange for that to be actioned?
[09:19] <Mirv> jodh: thanks! ok, I'll mark the landing as tested. which rtm image # you used where you added the new upstart?
[09:21] <Mirv> jodh: and did you test on mako or krillin?
[09:23] <thostr_> Mirv: if we have some spare silos can I get one for testing purposes?
[09:24] <thostr_> Mirv: it's line 55
[09:24] <Mirv> thostr_: current situation is good, I'll assign it
[09:25] <thostr_> Mirv: great, thanks!
[09:26] <brendand> ogra_, ah i might have been wrong about citrain - it appears to use some scheme of pinning packages, then updating with '-o Dir::Etc::SourceList=/dev/null'
[09:26] <brendand> ogra_, i suppose that does the trick
[09:29] <Mirv> dbarth: hey! regarding the RTM landing of silo 017, I made the pre-emptive move 5 hours ago that I copied oxide-qt over to that silo too, similar to what I did in utopic. was that a right thing to do?
[09:30] <Mirv> dbarth: the silo should be ready for testing in around 30 mins now, since the ARM build has had its 5 hours to build :)
[09:30] <Mirv> and it's building the .deb:s already in there
[09:32] <Mirv> dbarth: note that it's also properly "1.2.0", no ~:s in there - I never directly learned what were the dependency problems, but I understood that the oxide's version needs to be that final 1.2.0 and that's what it is
[09:35] <ogra_> brendand, yeah, sounds like
[09:52] <brendand> Mirv, do you want me to finish with silo 15 or is there anything more urgent
[09:57] <Mirv> brendand: given the assumed unity8 landing dependency on the oxide one, feel free to continue on that one
[10:01] <dbarth> Mirv: yeah, i read on the silo
[10:02] <dbarth> Mirv: ok, i'll ask mardy who as an rtm phone for testing
[10:02] <dbarth> Mirv: yes, the dependency is fine, and that's the right version; thanks for taking care of that
[10:05] <Mirv> dbarth: ok, thanks for confirming!
[10:10] <brendand> kalikiana, how can i check your change worked?
[10:10] <brendand> kalikiana, any place i can check?
[10:10] <kalikiana> brendand: use OSMTouch
[10:11] <kalikiana> tile caching will retain maps even if you have no network
[10:12] <kalikiana> positioning has not changed - not by me anyway - and it works fine
[10:13] <brendand> kalikiana, ok seems good
[10:14] <brendand> who's next?
[10:14] <brendand> pete-woods, any progress on a fix for silo 14?
[10:18] <pete-woods> brendand: see the landing request on line 56
[10:23] <brendand> pete-woods, ok - tests, check :)
[10:23] <brendand> pete-woods, waiting for the RTM silo to be updated really though
[10:23] <brendand> pete-woods, and did anything happen with the results spreadsheet/document?
[10:23] <pete-woods> brendand: not yet
[10:24] <pete-woods> I'll set up a sheet when we do the actual test
[10:25] <brendand> pete-woods, you don't strictly have to do it for the utopic silo - if you only do it once make sure it is for the RTM landing
[10:25] <brendand> pete-woods, otherwise i won't sign it off
[10:27] <pete-woods> brendand: I'm not really sure how the RTM testing works. I've never done any, yet an RTM request magically appears underneath everything I land to utopic
[10:28] <brendand> pete-woods, so i'm not sure how the RTM landing exactly gets created either, but when it is, the Testing pass column (column K) will be set to No
[10:29] <pete-woods> brendand: sure. but I've never set it to true.
[10:29] <brendand> pete-woods, that first needs to be set to yes, with the image number you tested against and now the results as well
[10:29] <brendand> pete-woods, somebody has though :) maybe Satoris or jamesh
[10:29] <pete-woods> brendand: those guys don't have write access to the sheet
[10:30] <brendand> pete-woods, this is starting to worry me :)
[10:47] <brendand> Mirv, can i test silo 2 with apparmor in it?
[10:48] <Mirv> brendand: sure, ogra thought it's important so it's probably a good choice
[10:49] <ogra_> brendand, Mirv well, i said that when i thought that it might fix the security test issues ... but psivaa trashed my dreams there ... the failures are also in utopic
[10:50] <Mirv> ogra_: :(
[10:50] <ogra_> but nontheless its a security feature indeed
[10:50] <Mirv> brendand: ok, then it doesn't matter probably too much which one you choose
[10:50] <ogra_> so independently of teeh failures, get it in
[10:51] <Mirv> FIFO sounds like a good method for choosing
[10:54] <psivaa> ogra_: Mirv: brendand: the security failure is due to signature failure in some *_armhf.click package installation. i remember popey mentioning about click package and signature in one conversation, but missed the context of it :). could be related
[10:54] <ogra_> psivaa, yes, cjwatson and mvo_ landed this
[10:54] <ogra_> i guess the test might need adjustment
[10:59] <pete-woods> trainguards: going to have to ask again for silo 9 to be reconfigured (https://ci-train.ubuntu.com/job/ubuntu-landing-009-0-reconfigure/build?delay=0sec) fixing holiday people's branches again :)
[10:59] <Mirv> psivaa: the click signature changes are now in both utopic and rtm as of yesterday
[10:59] <Mirv> pete-woods: :)
[11:00] <psivaa> Mirv: ogra_: ack. so we should ping security team then?
[11:00] <psivaa> to adjust the test that is
[11:00] <ogra_> psivaa, right
[11:03] <cjwatson> psivaa: where's this failure?
[11:03] <psivaa> cjwatson: it's the security test suite in smoke: http://dashboard.ubuntu-ci:8080/smokeng/utopic/touch_stable/krillin/27:20140910:20140908-d8c11f3/411/security/128529/
[11:05] <cjwatson> psivaa: do you know where the source code for that test lives?
[11:06] <psivaa> cjwatson: just a sec pls
[11:07] <cjwatson> (it's not in apparmor-easyprof-ubuntu itself)
[11:08] <psivaa> cjwatson:  lp:qa-regression-testing/tests is the one i get from http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/view/head:/tests/security/setup.sh
[11:08] <cjwatson> thanks
[11:09] <mvo_> cjwatson: let me know if you want me to fix this, but it probably really straightforward
[11:09] <cjwatson> psivaa: do you know if that's a private branch?
[11:09] <cjwatson> I don't seem to be able to see it here
[11:10] <cjwatson> mvo_: I should be able to handle it if I can find the code to modify :)
[11:10] <psivaa> cjwatson: i dont think so: http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/files/head:/tests/
[11:11] <mvo_> cjwatson: ok :) I wonder if I should send a mail to ubuntu-phone so that people are aware of the change
[11:12] <cjwatson> psivaa: doesn't that bzr export line mean "the branch called lp:qa-regression-testing/tests" (i.e. the focus branch of the "tests" series of the "qa-regression-testing" project), rather than the "tests" subdirectory of lp:qa-regression-testing?
[11:13] <cjwatson> psivaa: oh, but I see the script in question now, so maybe the syntax is just ambiguous :-/
[11:13] <cjwatson> bzr fail
[11:14] <psivaa> cjwatson: i'm not really sure about that, but we do 'bzr export' subdirectories somewhere else too, not the series. mostly where utah runlist comes in
[11:38] <pete-woods> Mirv: before I start thrashing around in this silo, does the ci machinery perform the merges in the order that is specified in the sheet? / does it try and understand the dependencies the MRs / is it pseudo-random (alphabetical?)
[11:39] <Mirv> pete-woods: you could direct those fine questions to someone who understands ci machinery ;) I'd guess it's the order in which they are listed, not considering the LP meta-data on dependencies. you can check the build job's log to see in which order they're tried.
[11:45] <pete-woods> Mirv: looks like it's what you said. this just confirms I was being stupid :)
[11:45] <pete-woods> my branch was the problem
[11:55] <bzoltan> Mirv:  do you know if the new adbd policy is landed on the RTM image or not? It seems that it still adb shells in #
[11:59] <Mirv> bzoltan: it is. but if you flash with --developer-mode, you get root.
[11:59] <Mirv> otherwise you need sudo
[11:59] <bzoltan> Mirv:  I doubt
[11:59] <bzoltan> Mirv:  i have flashed --developer-mode and it shelled me to $
[11:59] <Mirv> and without developer mode you need a password set, otherwise you can't adb in
[12:00] <bzoltan> Mirv: the ` phablet-config writable-image` does not even work on RTM image
[12:00] <bzoltan> Mirv:  i know that, that is OK
[12:00] <Mirv> bzoltan: I'm not sure what part of the new adbd policy you talk about, but ogra is your best bet in knowing whether utopic & rtm currently match each other
[12:01] <ogra_> they dont
[12:01] <ogra_> rtm is still as it always was, no changes there
[12:01] <bzoltan> ogra_:  how I suppose to validate RTM silo?
[12:01] <bzoltan> ogra_: `phablet-config writable-image` does not work
[12:01] <ogra_> bzoltan, how about you ask soomeone who does that every day ?
[12:02] <bzoltan> ogra_:  who would that be?
[12:02] <ogra_> everyone from QA in here ?
[12:02] <Mirv> for example brendand
[12:02] <ogra_> obviously they can test the silos, else we wouldnt land anything ;)
[12:02] <ogra_> bzoltan, whats the effect you see ?
[12:03] <ogra_> rtm definitely has the right backends for phablet-config writable-image
[12:03] <bzoltan> ogra_:  http://pastebin.ubuntu.com/8308814/
[12:03] <ogra_> shouldnt behave any differently to utopic in that regard (just that adbd runs as root)
[12:04] <ogra_> bzoltan, that doesnt even remotely look like an issue in phablet-config :)
[12:04] <bzoltan> ogra_: it does not do the job :) and that is enough problem for me
[12:05] <ogra_> bzoltan, can yoou run phablet-network --skip-setup manually ?
[12:05] <ogra_> i wonder why it would fail, it doesnt here
[12:05] <bzoltan> ogra_:  it hangs
[12:06] <ogra_> it tries to ping launchpad ... is your network working ?
[12:06] <bzoltan> ogra_: :) what do you think? :D
[12:06] <ogra_> (it will likely eventally time out and return 127 :) )
[12:06] <bzoltan> ogra_:  there is no network on the device
[12:07] <ogra_> well, how do you expect it to add a PPA then ?
[12:07] <ogra_> it needs to be able to reach LP
[12:07] <bzoltan> ogra_: well.... maybe an error?
[12:08] <ogra_> bzoltan, please file a whichlist bug against phablet-tools to provide a better error message if there is no network
[12:08] <ogra_> to fix your issue, just enable networking with phablet-network before running writable-image
[12:09] <davmor2> bzoltan:  flash it, run throught the wizard (setting up wifi etc), then when the phone is logged in, I then run phablet-config writable-image no issues here and I do it 4+ times a day
[12:09] <ogra_> davmor2, right, but you set up networking in the wizard
[12:09] <davmor2> ogra_: yes
[12:09] <bzoltan> ogra_:  that is what I will do. Thanks a lot.
[12:10] <ogra_> ... which you could also do with phablet-network if desired
[12:10] <bzoltan> davmor2:  I try to do things from a script
[12:10] <davmor2> bzoltan: ah fair enough.
[12:12] <bzoltan> ogra_: davmor2: my problem was simple that my device lost the network... during the provisioning
[12:23] <jdstrand> cjwatson: it is lp:qa-regression-testing, in the tests/ subdirectory. I'm guessing you figured that out. feel free to ping me with questions
[12:25] <cjwatson> jdstrand: yup, I'll have a branch for you after lunch
[12:26] <jdstrand> cjwatson: thanks. note click-apparmor which is next to apparmor-easyprof-ubuntu will likely need the same fix, but I can do that by examining your fix for apparmor-easyprof-ubuntu
[12:27] <cjwatson> Yeah, I already found that :)
[12:28] <jdstrand> I thought it might catch your eye :)
[12:31] <jdstrand> cjwatson: fyi, for testing the fix on desktop, see point 3 of https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor#Desktop_only
[12:31] <jdstrand> cjwatson: for testing the fix on touch, see point 3 in https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor#Touch_only
[12:32] <cjwatson> jdstrand: can I beg for help on that?  I *cough* haven't upgraded to utopic yet
[12:32] <jdstrand> cjwatson: either is fine (you shouldn't have to do both)
[12:32] <jdstrand> absolutely
[12:32] <cjwatson> anyway, branch is pushing, going out for some fresh air, will get back to you after lunch
[12:32] <jdstrand> ah, right, your lunch is at a different time than mine :)
[12:33] <jdstrand> cjwatson: enjoy your meal and air :)
[13:06] <bzoltan> zbenjamin:  would you be able to test the silo3 qtc plugin?
[13:06] <bzoltan> zbenjamin:  My device is testing RTM UITK
[13:24] <tedg> davmor2, So the music on the SD card is known and in progress. I marked it as a dup.
[13:24] <jdstrand> cjwatson: https://code.launchpad.net/~cjwatson/qa-regression-testing/click-install-untrusted: "This branch has not been pushed to yet."
[13:24] <davmor2> tedg: ah awesome
[13:25] <davmor2> tedg: sorry about that I'd forgotten that the music was on sd
[13:25] <ahayzen> tedg, ah it was because it is outside of ~/Music
[13:25] <ahayzen> tedg, FYI we support music:///path/to/file as a protocol which may be of use?
[13:25] <davmor2> ahayzen: yes we figured it out this morning
[13:26] <tedg> ahayzen, Yes, so the music scope is moving to that. In progress.
[13:26] <tedg> ahayzen, bug 1340952
[13:27] <ahayzen> tedg, cool :) should i detail in the bug that we support music:/// as i don't see if mentioned there?
[13:27] <ahayzen> *it
[13:27] <tedg> ahayzen, Sure, but I think it's not mentioned because it already worked :-)
[13:28] <ahayzen> tedg, :) i'll mention it so it is clear
[13:30] <ahayzen> tedg, ah yes i see you using it in one of the merge proposals awesome :)
[13:50] <balloons> plars, popey mentioned https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1367654. This is a simple fix; https://code.launchpad.net/~nskaggs/ubuntu-test-cases/fix-1367654/+merge/234113
[13:51] <plars> balloons: ah, more dependencies?
[13:51] <plars> balloons: looks like it depends on address-book-service-dummy even
[13:51] <balloons> plars, yep :-)
[13:52] <plars> balloons: thanks, I'll get that merged right away
[14:06] <sergiusens> trainguards, why 43 for sergiusens
[14:06]  * sergiusens didn't fill in any entry in the sheet...
[14:07] <sergiusens> ah, seems merge and clean is broken!
[14:08] <ogra_> yeah, everything is flaky
[14:08] <ogra_> a little
[14:08] <sergiusens> instead of transitioning from Published to Landed; it went to Unassigned
[14:08] <ogra_> sergiusens, did you pull in pittis MP already ?
[14:08] <sergiusens> ogra_: no; I haven't even reviewed that
[14:09] <sergiusens> I just wanted to land the no brainer MP
[14:09] <ogra_> sergiusens, i tested and top approved it
[14:09] <ogra_> ok
[14:09] <ogra_> oh, that was the click buddy thing, riight
[14:09] <ogra_> yeah, better land that ... :)
[14:10] <ogra_> tvoss, lost interest ?
[14:10] <ogra_> :)
[14:11]  * ogra_ wonders why the bot didnt mention cyphermox_ 
[14:11] <tvoss> ogra_, nope, it was only meant for testing, the network manager version has been uploaded to the archive by cyphermox right now
[14:11] <ogra_> tvoss, ah, i just never had seen this message ... curious :)
[14:12] <cyphermox_> moo?
[14:12] <cyphermox_> ah, it's because it mentions the lander in the spreadsheet
[14:12] <cyphermox_> only tvoss' name was there
[14:12] <ogra_> ah
[14:12] <tvoss> ogra_, :)
[14:12] <ogra_> when i opened it yours was there as well ... good timing i guess :)
[14:12] <cyphermox_> I uploaded the package directly since the version was messed up in the PPA anyway
[14:13] <ogra_> yeah
[14:13] <cyphermox_> ogra_: you may have been looking at a different entry
[14:13] <ogra_> last line
[14:13] <cyphermox_> I was just adding that one :)
[14:13] <ogra_> ah
[14:14]  * ogra_ twiddles thumbs waiting for lxc-android-config 0.201 in the archive ... 
[14:14] <cyphermox_> ogra_: now just to wait for nm to finish building and publishing and I'll be able to set the silo ready and get this rtm landing done :)
[14:15] <ogra_> cyphermox_, same for me ... 0.210 is the last utopic upload ... then i need a sync into my rtm silo and can land
[14:15] <ogra_> err
[14:15] <ogra_> 201
[14:15] <ogra_> developer mode, here we come :)
[14:15] <cyphermox_> woo!
[14:16] <ogra_> silly emulator ... stole me day ...
[14:16] <Mirv> sergiusens: I think there was this earlier phablet-tools landing, now in
[14:20] <sergiusens> Mirv: that just landed 3 minutes ago!
[14:20] <Mirv> sergiusens: yes, so now you have a silo for the new landing :)
[14:20] <sergiusens> the MP in http://people.canonical.com/~platform/citrain_dashboard/#?q=sergiusens has merged
[14:21] <Mirv> oh, right it's already in
[14:21] <sergiusens> Mirv: no, the spreadsheet broke, it's supposed to be marked Landed
[14:21] <Mirv> sergiusens: welcome to the world of Google docs
[14:21] <elopio> rvr: are you taking care of the location silo?
[14:21] <sergiusens> Mirv: merge and clean silo must of done that
[14:22] <Mirv> sergiusens: already done?
[14:22] <Mirv> https://code.launchpad.net/~phablet-team/phablet-tools/trunk 306
[14:30] <rvr> elopio: Yes
[14:32] <Mirv> sergiusens: yes, I did it, just too many silos to remember it all
[14:32] <elopio> rvr: ok, thanks. Let me know if you need a hand.
[14:33] <rvr> elopio: I left a comment in trello
[14:38] <sergiusens> Mirv: see ^
[14:39] <Mirv> sergiusens: funny. well, ignoring that, I marked it as Landed manually. the only way to fix it would be to search prepare-silo jobs for the landing id, and it's not really worth it. disappearing id:s happen every day in the sheet unfortunately
[14:39] <Mirv> psivaa: assigning! :)
[14:40] <psivaa> Mirv: thanks :)
[14:48] <ogra_> cyphermox_, (or Mirv) cuold one of you  sync the latest lxc-adnroid-config and andrpid-tools from utopic into rtm silo 13 ?
[14:49] <ogra_> geez, bad typing today
[14:49] <jdstrand> cjwatson: ok, seems it just took a really long time. I have everything I need to test
[14:49] <cjwatson> jdstrand: yeah, big branch, slow ADSL
[14:50] <cyphermox_> sure, I will. Mirv ^
[14:50] <cjwatson> jdstrand: I'll just write the MP now
[14:50] <cjwatson> jdstrand: https://code.launchpad.net/~cjwatson/qa-regression-testing/click-install-untrusted/+merge/234132
[14:53] <cyphermox_> ogra_: done
[14:55] <ogra_> merci !
[14:55] <Mirv> cyphermox_: thanks. I'm kind of off, but monitoring since sil2100 is off still todaay
[14:55] <brendand> jdstrand, still 4 tests fail with cjwatsons changes
[14:55] <cyphermox_> oh my
[14:55] <cjwatson> oh?
[14:55] <cyphermox_> I hope robru will be ok later
[15:02] <Mirv> cyphermox_: landing-009 would need packaging acks https://ci-train.ubuntu.com/job/ubuntu-landing-009-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity-scopes-api_0.6.5+14.10.20140910.1-0ubuntu1.diff + https://ci-train.ubuntu.com/job/ubuntu-landing-009-2-publish/lastSuccessfulBuild/artifact/packaging_changes_unity-scopes-shell_0.5.4+14.10.20140910.1-0ubuntu1.diff
[15:12] <jdstrand> brendand: what is failing?
[15:12] <jdstrand> brendand: and what are you testing on?
[15:14] <brendand> jdstrand, the click-apparmor tests
[15:14] <brendand> jdstrand, on krillin with your silo
[15:14] <jdstrand> brendand: can you paste the output?
[15:14] <ogra_> cyphermox_, hmpf, i think i made a mess ...
[15:20] <davmor2> kenvandine: hey dude, online accounts on first account creation always exits back to settings app who would be responsible for that?
[15:21] <kenvandine> davmor2, i guess mardy
[15:22] <jdstrand> brendand: did you see my request for test output?
[15:25] <brendand> jdstrand, yeah, just getting it now
[15:25] <jdstrand> thanks
[15:30] <brendand> jdstrand, http://paste.ubuntu.com/8310311/
[15:30] <brendand> is pastebinit really not available?
[15:32] <jdstrand> brendand: you ran click-apparmor as root. don't run it with sudo
[15:32] <jdstrand> brendand: the same goes for apparmor-easyprof-ubuntu
[15:33] <jdstrand> brendand: is https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor#Touch_only unclear? (not being an ass, I want to make sure it is clear for people)
[15:34] <jdstrand> I can add a test for root actually
[15:34] <jdstrand> let me do that
[15:34] <brendand> jdstrand, not really - but i ran it non-root and it complained about permissions ?
[15:35] <brendand> jdstrand, i'll double check that
[15:35] <jdstrand> brendand: please run it as non-root and give me the paste if there are failures
[15:35] <brendand> jdstrand, sure i'll run it all again
[15:40] <ogra_> cyphermox_, could you reconfigure rtm-13 for me ?
[15:47] <cyphermox_> ogra_: sure
[15:47]  * ogra_ hugs cyphermox_ 
[15:47] <davmor2> ogra_: user visible should appear on the issue page hopefully https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings-online-accounts/+bug/1367804
[15:47] <jdstrand> brendand: fyi, I committed changes to fail if click-apparmor and apparmor-easyprof-ubuntu are run as root
[15:47] <ogra_> davmor2, thanks !
[15:47] <jdstrand> brendand: no need to pull those in and invalidate your test run. just fyi
[15:48] <brendand> jdstrand, yeah looks like everything is ok now
[15:48] <jdstrand> cool
[15:48] <cyphermox_> ogra_: why are you reconfiguring?
[15:48] <Mirv> if coredevs around ready for packaging checking/acking, both https://ci-train.ubuntu.com/job/ubuntu-landing-002-2-publish/26/ and https://ci-train.ubuntu.com/job/ubuntu-landing-009-2-publish/16/ would need checking
[15:48] <ogra_> cyphermox_, because lxc-android-config wasnt in that silo originally
[15:49] <ogra_> cyphermox_, so a watch only build falls over telling me i need to reconfigure
[15:53] <cyphermox_> yep, just reran the watch build now too
[15:54] <cyphermox_> thar
[15:54] <cyphermox_> ogra_: you should be good to test
[15:58] <ogra_> cyphermox_, you rock !
[15:59] <cyphermox_> Mirv: looking
[16:01] <jdstrand> infinity: so, the glibc in utopic to fix the security vulnerability works fine on rtm. based on that and your feedback, I will copy the binaries to ubuntu-rtm (note to landers: this is a bug fix uploaded by core-dev to fix a security issue. there are some packaging updates that do not affect touch)
[16:03] <jdstrand> infinity: 97 packages successfully copied.
[16:04] <cyphermox_> dobey: Mirv: for ubuntuone-credentials, what happens if applications used the old Token constructor?
[16:06] <ogra_> robru, meeting ?
[16:07] <cyphermox_> Mirv: silo 9 looks fine
[16:08] <Mirv> thanks. I was wondering about the Token one too.
[16:10] <cyphermox_> Mirv: I know the answer, but I'd like to hear it from dobey :)
[16:20] <jdstrand> cjwatson: are the various -proposed tests being run on ubuntu-rtm and if so, is there a different report for rtm than http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html?
[16:21] <cyphermox_> robru: poke. still sick?
[16:22] <cjwatson> jdstrand: http://people.canonical.com/~ubuntu-archive/proposed-migration/ubuntu-rtm/
[16:22] <jdstrand> cool, thanks!
[16:22] <cjwatson> jdstrand: I don't think autopkgtests are hooked up yet though
[16:22] <jdstrand> ok
[16:23] <cjwatson> should probably get on that ... not fatal though
[16:26] <brendand> jdstrand, how long do these apparmor-easyprof-ubuntu tests take?
[16:27] <brendand> jdstrand, they've been running for probably 45 minutes now
[16:27] <jdstrand> brendand: a long time. they should be almost done
[16:31] <brendand> jdstrand, two failures
[16:31] <jdstrand> brendand: can you paste them?
[16:31] <jdstrand> brendand: or paste all the output if easier
[16:33] <brendand> jdstrand, http://paste.ubuntu.com/8310762/
[16:34] <jdstrand> that is weird
[16:35] <jdstrand> brendand: can you give me a tarball of 'tar -xcvf /tmp/jdstrand.tar.gz /etc/apparmor.d/ /usr/share/apparmor /var/lib/apparmor'
[16:36] <jdstrand> those tests pass on emulator and mako and there is no reason they should fail on krillin unless someone changed the policy
[16:39] <brendand> jdstrand, that command isn't valid?
[16:40] <jdstrand> brendand: I wonder if there is a race condition. does /home/phablet/.config/unity-scopes/com.example.confined-basic_confined-basic/settings.ini exist? the test creates the file if it doesn't exist and immediately runs the check. I wonder if it wasn't flushed to disk
[16:40] <brendand> jdstrand, doesn't appear to be there
[16:41] <brendand> ah it is
[16:41] <brendand> but is empty
[16:41] <jdstrand> brendand: whoops: I meant -zcvf
[16:41] <jdstrand> empty is fine
[16:41] <jdstrand> I bet if you ran the test again, it would pass
[16:41] <jdstrand> brendand: is the disk full?
[16:43] <brendand> jdstrand, don't think so
[16:43] <brendand> jdstrand, only about 3gig used
[16:43] <brendand> jdstrand, can i rerun an individual test?
[16:44] <brendand> don't want to rerun the whole thing
[16:44] <jdstrand> right
[16:44] <jdstrand> not as conveniently as you'd like, but let me get you a command
[16:46] <jdstrand> brendand: I'd like to see 'sudo tar -zcvf /tmp/jdstrand.tar.gz /etc/apparmor.d/ /usr/share/apparmor /var/lib/apparmor' first
[16:47] <jdstrand> brendand: oh, did you run these as root first?
[16:47] <brendand> jdstrand, hmm - yeah i would have
[16:49] <ogra_> root .... so last century  ...
[16:51] <jdstrand> brendand: can I have the full output from the tests?
[16:53] <jdstrand> brendand: actually, nm. what is the output of: ls -l /home/phablet/.config/unity-scopes/com.example.confined-basic_confined-basic/settings.ini
[16:54] <jdstrand> brendand: also, the output of ls -l /home/phablet/.local/share/unity-scopes/leaf-net/com.example.confined-basic/test.rw
[16:55] <jdstrand> brendand: and ls -ld /home/phablet/.local/share/unity-scopes/leaf-net/com.example.confined-basic/
[16:55] <jdstrand> brendand: and ls -ld
[16:56] <jdstrand> /home/phablet/.local/share/unity-scopes/leaf-net/
[16:56] <jdstrand> let me give you a paste
[17:06] <dobey> cyphermox_: nothing. the old ctor didn't go away
[17:06] <dobey> cyphermox_: so they will continue working just fine
[17:07] <cyphermox_> oh, indeed, it was duplicated in symbols
[17:07] <dobey> cyphermox_: and the new ctor is only used internally. anything using the old ctor just won't have valid updated or created times
[17:07] <dobey> cyphermox_: right. i just replaced a duplicate there :)
[17:07] <cyphermox_> Mirv: ack for dobey's silo 2.
[17:08] <Mirv> cyphermox_: okie. sleep in 1h, I can still watch if something to be published before that.
[17:08] <cyphermox_> nah, I can publish things too, so feel free to leave
[17:08] <Mirv> that ken's landing ^ needed the full "new normal" treatment for publish to work - prepare-silo reconfig, build watch_only..
[17:09] <cyphermox_> yes
[17:09] <Mirv> oh, that is, changing the sync:N to manual list of packages in the silo, _then_ prepare-silo reconfig
[17:09] <Mirv> if you do prepare-silo reconfig with sync:N silo that is borken, it'll remove the packages
[17:10] <Mirv> that can also be salvaged by binary copying a deleted package into the ppa itself. all the things CI train teaches you.. :)
[17:11] <cyphermox_> Mirv no worries
[17:11] <cyphermox_> actually
[17:11] <cyphermox_> since you're saying you'd still be around for an hour
[17:12] <cyphermox_> I only had a little bit of leftovers for lunch; I'd go grab something, and I would be back in 15-20 minutes
[17:12] <Mirv> cyphermox_: sure, I'll glance every now and then
[17:25] <jdstrand> infinity: fyi, http://people.canonical.com/~ubuntu-archive/proposed-migration/ubuntu-rtm/update_excuses.html
[17:26] <jdstrand> glibc-doc/i386 unsatisfiable Depends: glibc-doc-reference (>= 2.18)
[17:41] <cyphermox_> Mirv: I'm back
[17:43] <Mirv> ok, good night then!
[18:11] <brendand> jdstrand, apologies - i got dragged away from my laptop and now i seem to have err, misplaced the output
[18:11] <brendand> jdstrand, i have the log tar file though
[18:12] <brendand> jdstrand, here it is: http://people.canonical.com/~brendan-donegan/jdstrand.tar.gz
[18:33] <jdstrand> brendand: hey, can you give me the output from these commands: http://paste.ubuntu.com/8310923/
[18:34] <brendand> jdstrand, i'm just running the test again
[18:34] <jdstrand> brendand: after a reflash?
[18:35] <brendand> jdstrand, no - but i suppose i should have
[18:36] <brendand> jdstrand, should i reflash, run it from scratch and report back in an hour?
[18:36] <jdstrand> brendand: yes. I don't expect a change to the results otherwise. so, either reflash or give me that output
[18:36] <jdstrand> brendand: reflash is best
[18:48] <cyphermox_> tedg: just checking, you're aware there seems to be issues with dbus-test-runner autopkgtest right? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#dbus-test-runner
[18:51] <tedg> cyphermox_, Yeah, I haven't been able to get it to run locally :-/
[18:51] <tedg> cyphermox_, Not sure why the tests pass during the package build but not during autotest.
[18:51] <tedg> autopkgtest
[19:04] <robru> cyphermox_: ogra_ I'm still sick :-(
[19:07] <cyphermox_> robru: ack
[19:11] <bfiller> robru: can I get silos for line 61 and 67 when you have a chance
[19:11] <cyphermox_> tedg: have you been running it in the same kind of autopkgtest chroot?
[19:12] <cyphermox_> bfiller: looking
[19:12] <tedg> cyphermox_, Been trying the qemu thing, but it can't install X
[19:12] <cyphermox_> qemu thing?
[19:12] <tedg> cyphermox_, http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
[19:12] <tedg> cyphermox_, Those 2 paragraphs are all I know about autopkgtest :-)
[19:13] <cyphermox_> ah, yeah that looks about right
[19:13] <cyphermox_> tedg: do you know which test is failing then? or what kind of issue it is?
[19:15] <tedg> cyphermox_, Not really, it seems to be a timeout of some kind.
[19:16] <tedg> cyphermox_, But what's weird is that it runs on pkg build as well, and fine there.
[19:17] <cyphermox_> I guess
[19:31] <brendand> jamesh, around?
[19:37] <ogra_> robru, get well ! (go sleep)
[19:39] <bfiller> cyphermox_: I need a reconfig on silo 8, we added another package
[19:40] <cyphermox_> sure
[19:41] <cyphermox_> bfiller: what line is that?
[19:41] <bfiller> cyphermox_: line 44
[19:50] <ralsina_> cyphermox_: can I get a silo for row 64?
[19:56] <cyphermox_> yes
[19:56] <cyphermox_> ralsina_: I'll assign as soon as things are landed in utopic
[19:59] <ralsina_> cyphermox_: cool, thx
[20:42] <infinity> jdstrand: Thanks for the copy and, uhm, how can glibc-doc-reference not be in rtm?
[20:43] <infinity> cjwatson: What crack is the rtm britney smoking?
[20:44] <infinity> cjwatson: Oh, hrm, according to rmadison, britney's not wrong, glibc-doc-reference isn't in rtm, but why?  It should have been in the initial copy set, surely.
[20:45] <infinity> wgrant: ^
[20:48] <cjwatson> infinity: Yeah, I think that was my fault in the copy script, not wgrant's - I didn't follow the chain from extras
[20:48] <cjwatson> So I missed out on runtime deps of binaries that are delivered by sources we wanted to copy for other reasons, but which were not themselves in the main germination
[20:48] <cjwatson> infinity: I'd just force it and we can see about doing better next time
[20:49] <infinity> cjwatson: Or we could just copy g-d-r and make it happy?
[20:51] <cjwatson> infinity: We could, but there are lots of other things in the same boat.
[20:54] <infinity> cjwatson: :/
[20:55] <infinity> cjwatson: That's not actually comforting.
[20:55] <infinity> cjwatson: But okay.  Can force, where's the hints branch?
[20:55] <cjwatson> I know.  But.
[20:55] <cjwatson> lp:~ubuntu-release/britney/hints-ubuntu-rtm - you'll want both force and force-hint, see r1
[20:58] <infinity> cjwatson: Ta, committed.
[20:59] <infinity> cjwatson: Same permissions on the britney instance as ubuntu, I assume (ie: I don't need to go adding myself for it to pick up the adconrad hint?)
[20:59] <cjwatson> Should be
[20:59] <cjwatson> Yep, you have permissions
[21:00] <cjwatson> snakefruit:~ubuntu-archive/proposed-migration/britney-rtm.conf
[21:03] <jdstrand> brendand: did everything go ok?
[21:16] <brendand> jdstrand, just getting the tests started again - they seemed to take an age to branch from bzr
[21:17] <jdstrand> brendand: oh, hrmm. I just adb push them as per the test plan
[21:17] <jdstrand> cd qa-regression-testing
[21:17] <jdstrand> adb push ./test /tmp/tests
[21:17] <jdstrand> then use adb to start the tests
[21:18] <ToyKeeper> So, UITK in rtm/012 was *really* close to passing...  looks like it broke a camera app test for the flash.  The other ~1000 or so test results were the same or better than the base.  Good enough?
[21:18] <brendand> jdstrand, if it comes out clean i'll sign it off
[21:18] <jdstrand> ok, thanks
[21:19] <brendand> ToyKeeper, how did it break it? is it something camera-app has to adjust to maybe?
[21:19] <ToyKeeper> I'm not sure.  It's another rabbit hole I'm not sure I should dive into since other silos are waiting.
[21:57] <cyphermox_> ^ ignore this
[22:12] <brendand> jdstrand, congrats - you're all clear
[22:18] <ralsina> cyphermox_: can I get the silo for row 64 now? The utopic migration is done.
[22:19] <cyphermox_> I guess so
[22:22] <ralsina> thanks cyphermox_!
[22:22] <cyphermox_> let me hit build and I'll check that things behave
[22:23] <ralsina> I already hit it
[22:23] <cyphermox_> oh well :)
[22:23] <ralsina> seems to be going well so far
[22:25] <cyphermox_> wow yuck
[22:25] <cyphermox_> oh well, now I get to get it done right
[22:25] <cyphermox_> ralsina: I'll copy the packages to the ppa; that will work properly
[22:25] <cyphermox_> you can disregard the build bit
[22:26] <ralsina> cyphermox_: ack
[22:26] <ralsina> yeah, that failed rather spectacularly
[22:28] <jdstrand> brendand: woohoo! thanks :)