[00:52] awe: disregard messages you may see here, the publication is in progress [00:52] ofono publication, that is [00:59] lies [01:01] awe_: had to manually copy the pacakge, it looks like it was borked again, I'll watch the publication [01:02] it's in proposed now [01:02] brb [01:06] thanks cyphermox_ [01:58] 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] 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] 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] 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] === trainguards: IMAGE 235 building (started: 20140910 02:05) === [02:07] 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] 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] infinity: I kept saying eglibc. of course I meant glibc [02:10] jdstrand: Hard habit to break. :) [02:10] indeed [02:11] infinity: so, ubuntu-rtm has 2.19-4ubuntu2 and utopic 2.19-10ubuntu1 [02:11] infinity: you are comfortable with the -5 - -10 changes? [02:11] 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] 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] oh heh, phablet-shell just *might* work a bit better if I plug in my phone [02:21] cyphermox_, what's wrong with it? [02:26] jdstrand: I have zero issues with those changes going into RTM. [02:27] ok [02:27] jdstrand: Most don't affect ARM one way or the other, some are small packaging nits, etc. [02:27] 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] 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] infinity: no, they won't. man isn't even on the phone :) [02:28] jdstrand: Right, which is one of the reasons we're trying to drop manpages and move them to the manpages package. :P [02:29] $ man man [02:29] -bash: man: command not found [02:29] ah [02:29] jdstrand: Well, not phone specifically, but just that people with libc installed really shouldn't expect bloaty docs with it. [02:29] jdstrand: That, and we're sick of maintaining them. ;) [02:29] 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] jdstrand: Works for me. [02:30] * jdstrand happens to like those docs, but I also have man installed :) [02:30] 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] === trainguards: RTM IMAGE 27 building (started: 20140910 03:05) === [03:21] ToyKeeper: sounds good. The actual goal would be to validate regularly core components, like Qt, UITK, Unity, etc [03:49] 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] === trainguards: IMAGE 235 DONE (finished: 20140910 03:50) === [03:49] === changelog: http://people.canonical.com/~ogra/touch-image-stats/235.changes === [03:51] 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] 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] robru: spreadsheet seems fixed now? [03:55] or at least it has updated since yesterday [04:14] ok about ~everyone should be happy again with silos [04:16] bzoltan: The click setup failure didn't provide a very useful error; am planning to go back and find out more later. [04:19] === trainguards: RTM IMAGE 27 DONE (finished: 20140910 04:20) === [04:19] === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/27.changes === [04:23] well, almost... [04:28] ToyKeeper: check if you have the silo PPA enabled. that could be a troublemaker [04:29] Yes, I have the silo PPA enabled. It didn't seem to be an issue. [04:41] 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] Mirv: forced rebuild seems to help... but that is not very logical [05:30] hmm, bzoltan disappeared [05:58] 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] robru: excellent, thanks! where/how did you fix it? [06:01] 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] that's however "usual" [06:02] robru: oh, you might maybe have access to some server too? I remember some hunting for truncated files in the past. [06:05] 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] ha, of course, the good ol' cyphermox-test ;) [06:06] Mirv: saved my butt so many times ;-) [06:07] Mirv: OK I'm in bed with a high fever, good luck today. [06:08] robru: uh oh :( rest well [06:46] Mirv, looks like you get the next landing by virtue of being present [06:47] brendand: :D it's more kalikiana really regarding details and testing, but he should be around too [06:49] 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] 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] bzoltan: I think I'll let it run overnight though, in hopes that the latest changes I made will help. [06:58] 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] ToyKeeper: also, the install bits are necessary ... all the packages I listed will be needed by some app tests. [06:58] bzoltan: The flash/install bits have to be removed or disabled before I can even get a valid test result. [06:59] Setting up the SUT and running the tests are two logically independent steps. [06:59] ToyKeeper: just do not give the -c parameter and it will not cflash [06:59] ToyKeeper: Sorry my ignorance :) but what is SUT? [06:59] System Under Test [07:00] ToyKeeper: Sound scientific :) what is that? [07:01] 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] 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] I provision the device with scripts too, but they're separated from the scripts used for testing. [07:02] ToyKeeper: It is a separated function in my tool too. But the UITK test plan starts with provisioning. [07:02] Almost every test plan starts with provisioning. [07:03] 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] I didn't remove it, just made sure it wouldn't execute. [07:04] ToyKeeper: not giving the -c makes it very sure :) [07:04] 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] 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] In any case, I just wiped it and am getting it ready for an overnight run. [07:07] 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] ToyKeeper: also the camera tests just hang .. i put it last in the sequence for that reason. [07:09] 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] 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] ToyKeeper: and be careful with the apt-get upgrade ... it might bring unwanted packages [07:09] ToyKeeper: I do not trust the tests... I trust apt-get install [07:10] 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] 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] 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] Oh, er, also... I had to update the click setup for rtm: phablet-click-test-setup --distribution=ubuntu-rtm --series=14.09 [07:12] ToyKeeper: Coool. that is what i was looking for! Thank you a lot. [07:12] I think it had been pulling regular ubuntu bits instead of rtm bits, which invalidated all the test results. [07:13] ToyKeeper: yeps... you saved my day :) [07:13] But I can't get that to work on UITK. It seems to work on everything else though. [07:14] "Fetching ubuntu-ui-toolkit - into /tmp/tmppIkYZ1" ... "IndexError: list index out of range" [07:15] This bit fails: get_source_package_tests(package['source'], version, test_dir) [07:15] For now, I'm working around it by catching and printing the exception instead of bailing. [07:16] ToyKeeper, someone else can take over - it's pretty late for you, no? [07:16] 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] The provisioning is ... a bit uncertain though, so that's manual for now. [07:17] ToyKeeper, did you ever try ci teams provision.sh? [07:18] 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] Some part of the process is producing different test results, and I've been investigating why. [07:20] 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] ToyKeeper: disable the music tests if you want to sleep :D [07:21] 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] The test plan for a project is (or should be) the one and only plan in use. [07:22] ToyKeeper: Running the same AP tests on a totally different RTM image is as pointless as using different test tools ... [07:23] bzoltan, have you provided us your results yet? [07:23] 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] 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] 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] ToyKeeper: it sounds very redundant to me [07:25] bzoltan, if you could zip up the xml files and link them somewhere that would be great [07:25] brendand: i do not do xml files [07:26] bzoltan, you don't keep any sort of verbose output from autopilot? [07:26] brendand: The logs are saved, just not in XML. [07:26] It's custom. [07:26] 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] ToyKeeper: not custom, I use the standard tool... [07:27] ToyKeeper: phablet-test-run [07:27] bzoltan, i would actually [07:27] Well, the test tool is standard, the logging is custom. [07:27] ToyKeeper: the xml is custom :) and it is not good for local tests [07:28] brendand: I have hundreds of files all very verbose [07:28] 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] bzoltan, like we got on the ci dashboard [07:29] 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] bzoltan: It would indeed be very helpful to have the test logs for each new silo available. [07:30] bzoltan, you shouldn't have to 'dig them up' [07:30] bzoltan, they should be somewhere you can just give us the link to and we never need to ask again [07:30] bzoltan, like people.canonical.com [07:30] 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] bzoltan, it really should be way easier just to tar them up and scp them to people.canonical.com [07:32] bzoltan, store them by version or whatever and just give us (or anyone else who asks) a link to the root directory [07:32] 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] 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] brendand: sure i can do that [07:34] brendand: But keep in mind that we have no tools for doing these.. .so I need to invent my own :) [07:35] brendand: It is all happening, but slowly ... and to be honest, the changing platform does not make my job easier :) [07:36] 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] bzoltan, if a test fails, where do you look to get a clue as to why? [07:36] brendand: The script saves the output of phablet-test-run to a file. [07:37] The full test result is a directory of these logs, with test names and time stamps. [07:37] ToyKeeper, that's just stdout though isn't it? [07:38] It's the terminal output, not the full log from the device. [07:38] there should be something that has the traceback if the test fails [07:38] ToyKeeper, do you have the output of bzoltan's script? can you scp it somewhere? [07:39] brendand: I see tracebacks in the logs. [07:39] ... and the only results I have so far are somewhat ... broken. I'm attempting to get a valid result overnight. [07:40] 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] [07:41] Once I get things working I'll add the steps to the test plan. [07:42] For now though, sleep. :) [07:42] 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] ToyKeeper: just please do not modify the UITK test plan without me :) After all, it is my job to run those tests... [07:45] 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] 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] brendand: http://paste.ubuntu.com/8307160/ this is an example... the output of the reminder app tests [07:47] bzoltan, okay that seems fine [07:47] bzoltan, all of those uploaded to people.canonical.com would be perfect [07:48] brendand: hmmm... nice that AP puts there the file listing :D :D :D Please ignore the inappropriate words :D [07:53] Mirv, i hope this silo didn't break location [07:53] Mirv, i thought it was meant to be working in RTM right now? [08:07] lool: bq phone crashes after wizard [08:07] did we not add mterries fix? [08:07] can someone delete lp:~ps-jenkins/unity8/ubuntu-utopic-proposed ? it's got bad tags [08:07] trainguards ↑? [08:08] Saviq hates tags ;-) [08:08] seb128, I do, I hate bzr for being stupid about them, too [08:08] Saviq, what's the issue with tags? I don't even notice they exist... [08:08] brendand: kalikiana reported at least that everything worked great with it [08:08] can't you just not care/ignore the buggy ones? [08:08] seb128, no [08:08] NO [08:08] NOOO [08:08] kalikiana: see brendand's questions about locationing ^ [08:09] by principle? [08:09] seb128, yeah, more than anything else [08:09] Mirv, just trying with the stock image now [08:09] Saviq: we don't have rights to ~ps-jenkins [08:09] Mirv, i noted that he tested on mako [08:09] Saviq, k, so you decide to create issues for yourself...? [08:09] seb128, it just makes me cry a little [08:09] seb128, no, bzr + lp created it for me by making them viral [08:09] brendand: on the other hand, the actual positioning we have happens way below Qt, so I think it couldn't break it [08:09] Saviq, is that a bzr bug? [08:10] or launchpad? [08:10] lool: also osmtouch tells me no GPS availalble on krillin even after accepting terms [08:10] lool: thought this was only on N4 a race? [08:10] asac, so it might be broken anyway? [08:10] seb128, unlikely, it's just how tags work in bzr (and in lp when you're under the same project) [08:10] asac, i think tvoss and lool found other issues last night [08:10] seb128, basically we got the tags from lp:unity when we were under lp:unity/8.0 [08:10] ogra_: for the wizard crash? [08:10] (which i mentioned in the landing mail) [08:11] asac, no, with the service startup [08:11] 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] seb128, so that was hundreds of tags that did not make sense in unity8's history [08:11] brendand: wouldnt say so without knowing more... besides the wizard crashing it currently behaves like the N4 did a few days before [08:11] have to wait for tvoss and lool and mandel tell me wats the situation on krillin [08:12] 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] 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] seb128, the other is just not being able to look through them easily [08:14] seb128, but yes, mostly it's OCD [08:14] Saviq, thanks for explaining [08:16] Mirv, do you know who does have access to it? [08:17] Saviq: fginther mostly I think. at least his SSH key is mentioned at https://launchpad.net/~ps-jenkins [08:17] Mirv, cool, thanks [08:18] asac, lool - at least for me it doesn't work here on krillin [08:18] asac, lool - i thought everyone was testing on krillin? [08:18] Mirv, i'll ask kalikiana more about his change [08:23] 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] soif its just that you need to run one command to make it work [08:26] brendand: /var/log/upstart/ubuntu-espoo-service.log should show the coordinates you are at [08:27] asac, i get a position in there [08:27] asac, so why can't maps app use it? [08:28] 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] +works fine [08:34] 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] 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] 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] jodh: otherwise yes [08:47] pete-woods: done [08:47] Mirv: thanks! :) [08:50] I do like how unity8 comes out with a shades wearing emoticon every time the bot talks about it [08:59] Saviq, unity8 crashes when pressing 'Play in music app' for a track on the SD card [09:00] Saviq, can i install some symbols etc to get a good trace for you? [09:01] Saviq, it's a BadURL error, where does that come from? [09:01] Saviq, is it from url-dispatcher or elsewhere [09:01] ? [09:07] 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] 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] 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] 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] brendand, even when url-d craps out, it should never bring down the calling app.. [09:09] brendand, as for symbols, best just use apport-cli to upload the crash to lp and let it retrace [09:13] 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] 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] jodh: thanks! ok, I'll mark the landing as tested. which rtm image # you used where you added the new upstart? [09:21] jodh: and did you test on mako or krillin? [09:23] Mirv: if we have some spare silos can I get one for testing purposes? [09:24] Mirv: it's line 55 [09:24] thostr_: current situation is good, I'll assign it [09:25] Mirv: great, thanks! [09:26] 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] ogra_, i suppose that does the trick === vila changed the topic of #ubuntu-ci-eng to: Train support: trainguards | Vanguard: vila | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: robru is sick, please ping cyphermox or rsalveti for landings. [09:29] 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] 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] and it's building the .deb:s already in there [09:32] 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] brendand, yeah, sounds like [09:52] Mirv, do you want me to finish with silo 15 or is there anything more urgent [09:57] brendand: given the assumed unity8 landing dependency on the oxide one, feel free to continue on that one [10:01] Mirv: yeah, i read on the silo [10:02] Mirv: ok, i'll ask mardy who as an rtm phone for testing [10:02] Mirv: yes, the dependency is fine, and that's the right version; thanks for taking care of that [10:05] dbarth: ok, thanks for confirming! [10:10] kalikiana, how can i check your change worked? [10:10] kalikiana, any place i can check? [10:10] brendand: use OSMTouch [10:11] tile caching will retain maps even if you have no network [10:12] positioning has not changed - not by me anyway - and it works fine [10:13] kalikiana, ok seems good [10:14] who's next? [10:14] pete-woods, any progress on a fix for silo 14? [10:18] brendand: see the landing request on line 56 [10:23] pete-woods, ok - tests, check :) [10:23] pete-woods, waiting for the RTM silo to be updated really though [10:23] pete-woods, and did anything happen with the results spreadsheet/document? [10:23] brendand: not yet [10:24] I'll set up a sheet when we do the actual test [10:25] 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] pete-woods, otherwise i won't sign it off [10:27] 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] 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] brendand: sure. but I've never set it to true. [10:29] 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] pete-woods, somebody has though :) maybe Satoris or jamesh [10:29] brendand: those guys don't have write access to the sheet [10:30] pete-woods, this is starting to worry me :) [10:47] Mirv, can i test silo 2 with apparmor in it? [10:48] brendand: sure, ogra thought it's important so it's probably a good choice [10:49] 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] ogra_: :( [10:50] but nontheless its a security feature indeed [10:50] brendand: ok, then it doesn't matter probably too much which one you choose [10:50] so independently of teeh failures, get it in [10:51] FIFO sounds like a good method for choosing [10:54] 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] psivaa, yes, cjwatson and mvo_ landed this [10:54] i guess the test might need adjustment [10:59] 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] psivaa: the click signature changes are now in both utopic and rtm as of yesterday [10:59] pete-woods: :) [11:00] Mirv: ogra_: ack. so we should ping security team then? [11:00] to adjust the test that is [11:00] psivaa, right [11:03] psivaa: where's this failure? [11:03] 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] psivaa: do you know where the source code for that test lives? [11:06] cjwatson: just a sec pls [11:07] (it's not in apparmor-easyprof-ubuntu itself) [11:08] 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] thanks [11:09] cjwatson: let me know if you want me to fix this, but it probably really straightforward [11:09] psivaa: do you know if that's a private branch? [11:09] I don't seem to be able to see it here [11:10] mvo_: I should be able to handle it if I can find the code to modify :) [11:10] cjwatson: i dont think so: http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/files/head:/tests/ [11:11] cjwatson: ok :) I wonder if I should send a mail to ubuntu-phone so that people are aware of the change [11:12] 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] psivaa: oh, but I see the script in question now, so maybe the syntax is just ambiguous :-/ [11:13] bzr fail [11:14] 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 === MacSlow is now known as MacSlow|lunch [11:38] 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] 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] Mirv: looks like it's what you said. this just confirms I was being stupid :) [11:45] my branch was the problem [11:55] 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] bzoltan: it is. but if you flash with --developer-mode, you get root. [11:59] otherwise you need sudo [11:59] Mirv: I doubt [11:59] Mirv: i have flashed --developer-mode and it shelled me to $ [11:59] and without developer mode you need a password set, otherwise you can't adb in [12:00] Mirv: the ` phablet-config writable-image` does not even work on RTM image [12:00] Mirv: i know that, that is OK [12:00] 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] they dont [12:01] rtm is still as it always was, no changes there [12:01] ogra_: how I suppose to validate RTM silo? [12:01] ogra_: `phablet-config writable-image` does not work [12:01] bzoltan, how about you ask soomeone who does that every day ? [12:02] ogra_: who would that be? [12:02] everyone from QA in here ? [12:02] for example brendand [12:02] obviously they can test the silos, else we wouldnt land anything ;) [12:02] bzoltan, whats the effect you see ? [12:03] rtm definitely has the right backends for phablet-config writable-image [12:03] ogra_: http://pastebin.ubuntu.com/8308814/ [12:03] shouldnt behave any differently to utopic in that regard (just that adbd runs as root) [12:04] bzoltan, that doesnt even remotely look like an issue in phablet-config :) [12:04] ogra_: it does not do the job :) and that is enough problem for me [12:05] bzoltan, can yoou run phablet-network --skip-setup manually ? [12:05] i wonder why it would fail, it doesnt here [12:05] ogra_: it hangs [12:06] it tries to ping launchpad ... is your network working ? [12:06] ogra_: :) what do you think? :D [12:06] (it will likely eventally time out and return 127 :) ) [12:06] ogra_: there is no network on the device [12:07] well, how do you expect it to add a PPA then ? [12:07] it needs to be able to reach LP [12:07] ogra_: well.... maybe an error? === MacSlow|lunch is now known as MacSlow [12:08] bzoltan, please file a whichlist bug against phablet-tools to provide a better error message if there is no network [12:08] to fix your issue, just enable networking with phablet-network before running writable-image [12:09] 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] davmor2, right, but you set up networking in the wizard [12:09] ogra_: yes [12:09] ogra_: that is what I will do. Thanks a lot. [12:10] ... which you could also do with phablet-network if desired [12:10] davmor2: I try to do things from a script [12:10] bzoltan: ah fair enough. [12:12] ogra_: davmor2: my problem was simple that my device lost the network... during the provisioning [12:23] 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] jdstrand: yup, I'll have a branch for you after lunch [12:26] 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] Yeah, I already found that :) [12:28] I thought it might catch your eye :) [12:31] cjwatson: fyi, for testing the fix on desktop, see point 3 of https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor#Desktop_only [12:31] cjwatson: for testing the fix on touch, see point 3 in https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor#Touch_only [12:32] jdstrand: can I beg for help on that? I *cough* haven't upgraded to utopic yet [12:32] cjwatson: either is fine (you shouldn't have to do both) [12:32] absolutely [12:32] anyway, branch is pushing, going out for some fresh air, will get back to you after lunch [12:32] ah, right, your lunch is at a different time than mine :) [12:33] cjwatson: enjoy your meal and air :) [13:06] zbenjamin: would you be able to test the silo3 qtc plugin? [13:06] zbenjamin: My device is testing RTM UITK [13:24] davmor2, So the music on the SD card is known and in progress. I marked it as a dup. [13:24] cjwatson: https://code.launchpad.net/~cjwatson/qa-regression-testing/click-install-untrusted: "This branch has not been pushed to yet." [13:24] tedg: ah awesome [13:25] tedg: sorry about that I'd forgotten that the music was on sd [13:25] tedg, ah it was because it is outside of ~/Music [13:25] tedg, FYI we support music:///path/to/file as a protocol which may be of use? [13:25] ahayzen: yes we figured it out this morning [13:26] ahayzen, Yes, so the music scope is moving to that. In progress. [13:26] ahayzen, bug 1340952 [13:26] bug 1340952 in url-dispatcher (Ubuntu) "Video and Music scopes should provide non-file:/// based URIs" [High,In progress] https://launchpad.net/bugs/1340952 [13:27]