[00:45] renatu: ok we're back online if you need to build anything now === robru changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1I2YFOy | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: ci-train.ubuntu.com will be taken offline at 2200UTC for maintenance [00:47] robru, thanks [00:48] renatu: you're welcome === robru changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1I2YFOy | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: Spreadsheet Replacement Rollout largely successful just dealing with some firewall hiccups. [01:19] AlbertA: hi, thanks for being among the first to try out the new train ;-) looks like there's a couple firewall issues stopping things from working, I've notified IS, hopefully will be resolved within an hour [01:21] robru: no prob. new site looks great! [01:21] AlbertA: thanks! [01:43] robru, is there any change to landing a silo once the testing has passed? [01:44] bregma: nope that part is the same for now. you need QA to approve (sometimes) and then you need me to hit publish [01:44] robru, ok, just making sure [01:45] bregma: yeah the goal is to make it so that people can publish their own stuff too, but that's a ways off still [05:16] AlbertA: ok wow, apologies on that horrible delay! retrying your build now, should be working: https://ci-train.ubuntu.com/job/ubuntu-landing-009-1-build/329/console === chihchun_afk is now known as chihchun [06:32] michi: sorry about that dput failure, retried for you, should be working now: https://ci-train.ubuntu.com/job/ubuntu-landing-051-1-build/14/console [06:33] robru: Hey, no problem! Thanks for picking it up on it. I figured that, with everything in flux, I’d just wait a while for things to settle down :) [06:33] There was little point in shouting at you guys, I thought :) [06:33] michi: yeah that was a scary 8 hours of downtime that should only have been 2 hours of downtime. but as far as I know everything is perfect now, so have at it ;-) [06:34] The new stuff looks nice. [06:34] I haven’t gone through the process of starting a new landing yet. [06:34] michi: thanks! please email me with any improvement ideas you may have. I'm going to try to focus on papercuts over the next week or so [06:34] But it sure looks easier than the spreadsheet. [06:34] Will do, if I come across something that isn’t obvious. [06:34] yeah [06:34] michi: alright, 11:30 here, goodnight ;-0 [06:35] Well-deserved sleep coming up. Enjoy it! :) [07:30] robru, hey, just to confirm, the data from the spreadsheet won't be migrated to bileto? [07:30] jibel: correct [07:31] jibel: well maybe some of it, by hand, but generally no, they will coexist for a while [07:32] robru, that's fine, it's just to know where we should approve landing requests for cards already created. [07:33] jibel: good luck! Email me if you have any questions about the api [07:34] robru, it should be all right, the API is easy to use and clear. Much simpler than scanning a spreadsheet :) [07:35] jibel: hehe yeah. [07:35] jibel: OK I'm just winding down, goodnight! [07:36] good night [07:58] sil2100: fyi, we came up with a workaround for the thumbnailer gstreamer issues, so should be able to do a trunk landing with the gcc 5 fixes soon. [07:59] jamesh: excellent, would like that ASAP [08:00] cihelp: I got this error from the generic-land portion of an autolanding job: http://s-jenkins.ubuntu-ci:8080/job/generic-land/27514/console [08:00] jamesh: let me take a look [08:01] jamesh, hey, is there a bug about that gstreamer issue? [08:01] psivaa: everything built fine on the arch specific subjobs that preceded that bit [08:02] seb128: I haven't yet. I believe the bug is tied to the fdsrc element though, which has given us problems in the past [08:02] seb128: I changed the thumbnailer to not depend on that element any more. [08:02] jamesh, would be nice to have a bug, forwarded upstream if possible [08:02] k [08:03] seb128: right. I've done that for a number of fdsrc bugs in the past, but hadn't narrowed this one down. [08:06] psivaa: if it helps, the MP for that landing is merging a copy of lp:thumbnailer to lp:thumbnailer/devel. I wonder if this is some edge case for branch stacking, since there are no revisions in lp:/~jamesh/thumbnailer/devel-sync-20150725 that are not in the development focus branch [08:08] jamesh: that could be a possibility, i have seen this error once and trying to remember/dig for that information [08:12] jibel, hey, I marked silo 6 ready for QA validation a while ago, and it hasn’t appeared in the trello board yet, known issue? [08:13] oSoMoN, I disabled the bot last night while robru was migrating the spreadsheet, just in case. [08:13] Let me run it [08:14] thanks [08:15] ah, and robru moved the dashboard so now it crashes because it cannot find it [08:15] I'll fix that [08:16] jibel: new dashboard is a bit different [08:17] robru, where is the raw data? [08:17] robru: grrrrrrr changing all the urls ;) [08:17] jibel: requests.ci-train.ubuntu.com/static/json/index.txt lists assigned silos [08:19] oSoMoN, it'll take a moment [08:19] looks like we'll create cards manually this morning [08:19] jibel, that’s alright, that one’s not super urgent [08:19] jamesh: would there be any possibility that there was a rev manually pushed to the devel branch [08:19] ? [08:20] psivaa: no. [08:20] jibel: the filenames listed in index.txt can then be accessed relative to that url for the raw json statuses [08:20] oSoMoN, thanks, it'll be fixed soon. I didn't plan to make the bot work with the spreadsheet and bileto at the same time :) [08:22] oSoMoN, BTW, on the dashboard the state is 'Package Built' not 'Ready for QA' [08:23] it'll be a quiet day, nothing is ready for QA [08:23] robru, ^ [08:23] jibel, then there’s an issue with the dashboard. robru: I marked silo 6 ready for QA validation in the spreadsheet earlier this morning, and apparently the dashboard didn’t pick it up [08:24] The dashboard doesn't seem to fetch statuses from the spreadsheet at all now [08:24] psivaa: the revision ci-train-bot@canonical.com-20150715020328-bq2ohz4ufnerale2 it says is a ghost is the head revision of lp:thumbnailer (and also of the devel-sync branch that is the source of the merge) [08:24] oSoMoN: the dashboard no longer cares about the spreadsheet [08:24] robru, so how do we track statuses during the transition? [08:24] jibel: you'd have to look at the spreadsheet directly [08:25] robru, of course [08:25] lol [08:25] :-P [08:25] jibel: sil2100: yes the transition may be a little bit rougher than i anticipated, to many moving pieces [08:26] jibel: the trick is that the spreadsheet won't automatically update statuses either, so manual poking will be necessary to make it actually say "ready for qa" [08:27] so the spreadsheet lives on? [08:27] it's like picking up your phone every 10 minutes just in case someone calls you because the ring is broken [08:27] but behind the scenes now? [08:27] no way we scan the spreadsheet manually [08:33] jamesh: i see a similar issue in this lp bug, https://bugs.launchpad.net/bzr/+bug/1161018/comments/4 [08:33] Ubuntu bug 1161018 in Bazaar "bzr revno fails on ghost ancestry" [High,Confirmed] [08:33] would you mind trying the workaround in comment #4 [08:34] ah right, okay just transitional :) [08:34] jibel: we may need to tell people to just irc ping each other until the spreadsheet fully dies [08:35] psivaa: sure. [08:37] psivaa: If I have any trouble after retrying the landing, I'll ask again. Thanks. [08:37] jamesh: sure, i tried it after copying your branch and it works. [08:38] jamesh: to test, 'bzr revno lp:~jamesh/thumbnailer/devel-sync-20150725' command should just work [08:40] psivaa: pushed an empty commit, and "bzr revno" works, so hopefully Jenkins will be happy. [08:43] jamesh: http://s-jenkins.ubuntu-ci:8080/job/generic-land/27517/console was happy :) [08:50] robru, yeah, there is no other choice anyway [08:50] psivaa: thanks for your help. [08:50] jamesh: np [08:54] sil2100, robru don't you think that silos on the spreadsheet that must be rebuilt or reconfigured should be moved to bileto instead? [08:54] jibel: that's one proposition, yes [08:54] sil2100, and every team is responsible of moving their records [08:54] We'll probably doing that, but currently it requires some manual work... [08:55] sil2100, otherwise the spreadshhet will stay there forever [08:55] Manual work not really suited for normal team members [08:55] sil2100, checking lines manually also requires manual work [08:57] I know, just saying it's not something normal landers can do, we'll be migrating entries slowly ourselves [09:02] I didn't expect we'd have to be doing that as a priority, thought that the dashboard would support both during the grace period [09:05] sil2100, if a line is copied from the spreadsheet does it mean the silo will have to go through the whole process again, merge, build, ... [09:05] ? [09:05] No, it won't have to be reassigned, just needs to be hm, hacked into the Bileto ;) [09:06] I'll probably create a jenkins job for migrating entries, give me a few minutes [09:06] Then it should be cool [09:08] sil2100, you can export the spreadshhet and recreate the request with the API [09:14] Anyway, I'll get to it in a minute, just need to finish something up real quick first [09:23] jibel: ok, on it [09:45] hmmm [09:46] jibel: looks like it won't be as easy [09:58] trainguards: does the new dashboard show if silo ready for QA signoff? My silo11 should be in that state, but the dash doesn't show it [10:08] greyback, it doesn't [10:09] greyback, your request is in the old spreadsheet? [10:09] jibel: ah, that's still alive? Let me see [10:10] greyback, status in the dashboard are not updated for request still in the spreadsheet [10:10] jibel: yep, ok spreadsheet reports it's ready for QA. Thanks! [10:11] sil2100, ^ data have to be migrated, we'll lose things otherwise [10:15] jibel: yeah, I know, I tried migrating an entry as per robru's instructions but it doesn't work [10:16] I'll try something [10:17] ANyway, I have no idea why we couldn't have just left the spreadsheet working for the grace period [10:17] Yeah, so it will be a bit more painful, the migration that is [10:17] A watch-only rebuild is required [10:18] (or actually any other operation) [10:37] sil2100, do you know how I differentiate deb package landings from tarball and clicks? [10:37] how to* [10:38] jibel: I think the only difference is if it has Manual Download Urls defined or not [10:38] okay, thanks [10:44] sil2100, where can I find the list of sources packages for a request? For example in https://requests.ci-train.ubuntu.com/v1/tickets?qa_signoff=Ready 'sources' is empty but it filled on the dashboard. [10:44] sorry for all the questions [10:46] sil2100, nm, found it [10:48] jibel: k, no worries, just remember only robru knows the system well [10:49] I'm a consumer here as well [10:49] sil2100, I know but he's sleeping and it helps asking questions. Look I found the answer ;) [10:49] I'm a bit surprised with a few things, since after the public deployment so many things unexpectively changed [10:49] jibel: btw. do you know if we still have HTTP access to the config files that were exported to lillypilly before? [10:50] sil2100, yeah it's related to my previous question [10:50] sil2100, https://requests.ci-train.ubuntu.com/static/json/index.txt will give you a list of the data available [10:51] index.txt? No wonder https://requests.ci-train.ubuntu.com/static/json/ didn't work when I tried that [10:51] sil2100, then for the data itself about a silo replace index.txt by the silo you want [10:51] sil2100, https://requests.ci-train.ubuntu.com/static/json/ubuntu/landing-002 for example [10:51] Yeah, got it [10:52] sil2100, fixing the bot is a bit more work than I expected TBH [10:53] sil2100, but now it should work for deb package landing, I need to validate click and tarballs now [10:54] but it's a post-lunch task [10:56] jibel: btw. migration might be really really painful to do [10:57] Eh, now I feel bad I didn't have enough time to test bileto before deployment [10:57] There's so many things I'd need to see fixed [11:00] jibel: anyway, since one can't write a script that just migrates entries straight away as it requires 3 different isolated steps, I'm actually thinking of at least enabling the spreadsheet status updates [11:04] hmmmm [11:04] Bileto silo assignment doesn't seem to work? [11:08] robru: the assignment URL has some bad urlencoded signs, you can't assign any silos [11:08] greyback_: hey! Could you try assigning your newly filled request? [11:09] greyback_: I want to know if you also get the wrong urlencoded urls in the prepare job [11:09] sil2100: ok [11:10] Need to know if it's b0rken in overall, or just for me [11:10] sil2100: looks broken: https://ci-train.ubuntu.com/job/prepare-silo/5561/ [11:11] greyback_: yeah, same here [11:11] https://code.launchpad.net/~dandrader/unity8/app-state-handling/+merge/258653 [11:11] It copy-pastes correctly, but in reality it's wrong [11:11] %253A [11:11] https%253A//code.launchpad.net <- things like these are in the request [11:12] yeah, someone not urldecoding [11:12] The funny thing is, I don't have access to hot-fix it [11:12] funny ha ha? [11:12] :) [11:12] Very funny ;) I love having everything under IS control [11:12] well there's no hurry with that silo, I need to wait until silo11 lands [11:13] but can't say I'm impressed [11:13] We can assign it by urldecoding by hand [11:13] ;p [11:18] hah [11:18] I'll try looking into fixing that [11:20] jibel, sil2100: I'm trying to test silo 51 unfortunately I can't make it actually install anything it looks like there are just -dev and -doc files or am I missing something? [11:22] davmor2, I don't even know which line of the spreadsheet it was [11:22] jibel: 60 [11:23] davmor2, and the commit log is not helpful either "Initial revision for landing." [11:24] jibel, hey, is there something wrong with silo 35? [11:24] I see lots of other silos coming in after that but getting tested beforehand [11:24] jibel, sil2100: http://paste.ubuntu.com/11965973/ [11:25] jibel: citrain didn't pull anything in, I can't see a default package to actually install and apt refuse to do anything :) [11:25] davmor2, no idea, ask michi for clarification [11:25] jibel: will do [11:26] davmor2, oSoMoN said silo 6 is ready but there is no card due to the death of the spreadsheet. [11:45] sil2100: would you be able to help me with the silo assignement, please? I have just entered a new line to the new interface [11:46] bzoltan_: as per e-mail, assignment is a bit broken right now - let me assign it for you with manual intervention [11:46] I'm looking into fixing that, but I don't know robru's bileto code, so it'll take a while [11:46] sil2100: Yes, i have read the mail :) [11:46] In the meantime I can manually help ;p [11:46] sil2100: thank you [11:48] greyback_: I'll assign your silo in a moment too, if you don't mind I'll use it shortly as test-bed [11:48] sil2100: no prob, that's what I kept it there for [11:53] greyback_: thanks === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [12:06] Strange, it looks like suddenly our CI Train jenkins simply stopped urldecoding the GET requests [12:13] sil2100, new bot updated and in production [12:13] ubuntu-qa ^ === _salem is now known as salem_ [12:23] jibel: sweet [12:23] Ok, I still didn't find the reason why jenkins doesn't suddenly not urldecode [12:29] * sil2100 goes of to lunch [12:32] sil2100: can we have a redirect for the dashboard please? [12:33] robru: ^ I guess :) [12:34] robru, and also fix the link 'RAW' on the dashboard [12:39] jibel: why are there 2 ticket for silo2 [12:40] davmor2, the request ids in the spreadsheet and its replacement don't match [12:40] davmor2, you can delete the second card [12:41] jibel: they are breeding [12:48] davmor2, it is just that the testing request exists in the spreadsheet and bileto. It has been created yesterday from the spreadsheet, then today I ported the bot to bileto which discovered this request. Since the request ids are different between the 2 systems it thought it was new and added a ticket [12:49] davmor2, it will happen again if people create requests that already existed in the spreadsheet. [12:50] jibel: it's the fact we are upto 3 that is concerning, it's like each time the import happens it creates a new ticket [12:50] davmor2, yeah, I think I just fixed that [12:50] davmor2, with click package updates in the custom tarball, do you know how these get applied during the update? is it via click install or is it via the image diff? [12:54] pmcgowan: iirc the image pulls in the updates from trunk/store and then creates the tarball, then I believe it just uses image diff to install on the device, cwayne might be able to give you more clarity though [12:56] the ones in the custom tarball are via image diff i *think* [12:56] pmcgowan, it's a diff, everything is already unpacked in the tarball === chihchun is now known as chihchun_afk [13:01] jibel, thats what I thought thanks, so there is no way a single click could fail to update [13:02] sil2100: Do you know what should be the cure for the "error pushing:" failure of the ubuntu-device-flash? [13:05] bzoltan_, is that arale? probably the flaky usb [13:06] pmcgowan: no, it is both krillin and mako. Bootstrapping works fine, but simple flash fails [13:06] hmm [13:07] bzoltan_, latest u-d-f from the PPA? [13:08] pmcgowan: it should be up to date.. I check the versions [13:09] I have 0.20-0ubuntu1 [13:09] fwiw [13:12] pmcgowan: I have 1.1+15.10.20150519-0~341~ubuntu15.04.1 from the recipe .. that is newer then any release [13:13] pmcgowan: hmm... now it works... it could be USB flakiness [13:20] pmcgowan: it is random... "error pushing: error: protocol fault (no status)" and never finishes with the flashing :( [13:21] jibel: Who was your new victim for dkms testing issues? [13:21] jibel: Looks like the current builds have been running for 27 hours. :P [13:21] infinity, still me [13:22] bzoltan_, that weird maybe your laptop [13:22] jibel: Oh. Well, hi you. Iz broke. [13:22] pmcgowan: it happens on both my laptops... checking the third one [13:23] bzoltan_, I am not sure where you got that version [13:23] I don't see that in the ppa [13:23] pmcgowan: from here -> https://code.launchpad.net/~bzoltan/+recipe/sdk-tools-dev [13:24] bzoltan_, why not the one in the ppa? [13:24] infinity, the execution node is down again [13:24] infinity, I'll restart it [13:25] pmcgowan: :) somebody need to test the release candidate of the phablet-tools. [13:25] pmcgowan: but i will downgrade now and see... if it works then the phablet-tools trunk is broken [13:25] jibel: Is that same node used by autopkgtests, cause they seem a bit backed up too. [13:28] infinity, yeah but adt jobs are distributed, it shouldn't be a problem [13:28] infinity, let me restart whatI can === chihchun_afk is now known as chihchun [13:34] infinity, dkms node is back [13:34] jibel: Will the jobs need a kick, or should they wake up? [13:34] infinity, they'll wake up [13:34] jibel: Ta. [13:35] cihelp: ^ can you monitor wazn-adt, it's the second time it crashes in 2 weeks and no one notice [13:38] jibel, it's just the 'wazn-adt' slave right. not the node itself or the two other slaves running there? [13:38] fginther, yes, the jenkins-slave process dies and doesn't respawn [13:41] sil2100: does the dashboard still show the silos as marked as tested and ready for QA? [13:42] jibel, I'm a little curious as to what's going on here. initctl reports 'auto-package-testing-jenkins-slave stop/waiting', but the slave is running. Do you know how it was restarted? [13:42] boiko: yes, but not from the spreadsheet... sadly Robert removed support for the spreadsheet completely [13:43] sil2100: so, yesterday I marked some silos as tested on the spreadsheet, was that migrated or do I need to mark them as tested again? [13:43] boiko: no, all is fine [13:43] sil2100: I just don't see them marked as so in the dashboard [13:44] boiko: yes, since as I said, the dashboard doesn't understand the spreadsheet anymore, and there was no migration to bileto yet [13:44] So it's just marked on the spreadsheet, QA is aware of those [13:44] sil2100: ok, good, just checking, thanks for the info :) [13:45] This switch to bileto is a bit faulty [13:46] jibel, Oh, I think I see now. Looks like you manually started it. [13:51] fginther: hey! Did you have an issue with jenkins and the parambuild plugin before that suddenly it wasn't urldecoding the parameters from the URL? [13:52] sil2100, no, I can't say I've seen that [13:54] fginther, sorry was otp. I restarted it [13:54] jibel, thanks for clarifying [13:56] jibel: I question the efficacy of your restart. Or your claim that the jobs would unstick themselves. :) [13:56] jibel: All of them still seem to be in the "building for over a day" state, I'd have expected a few to be done by now. [13:57] hi, could I please have a silo for line 44, or should I open a bileto ticket now instead of using the spreadsheet (line was already there, been sitting in the queue for over a week)? [13:57] cyphermox: please open a bileto ticket :) [13:57] sil2100: thanks! [14:01] jibel: hey did the current silo11 slip through the cracks? I don't see it in the QA testing board [14:01] sil2100: am I also the person supposed to hit assign? [14:02] cyphermox: yes, but it's broken a bit right now, let me assign it for you [14:02] ah ok [14:02] just wanted to know if it was all self-serve ;P [14:02] awe_: ^^ [14:02] next time, you'll be able to do it all yourself [14:02] k [14:03] morphis: ^ I guess this is relevant for you too [14:03] Aaah, I see the issue [14:06] Not sure why suddenly firefox decides to urlencode already urlencoded strings [14:08] infinity, jenkins is slowly digesting the queue. The UI is a bit confusing but if you scroll down to a node called wazn-adt, you'll see that all the builds with a number in front of them are recent. [14:09] infinity, the jobs without number are virtual jobs that jenkins create to keep track of its upcoming tasks [14:09] boiko: ping [14:10] sil2100: To approve a silo, is the spreadsheet still working? [14:10] Looks like an apache misconfiguration [14:10] rvr: yeah, for approving yes - since those are simple formulas [14:10] jibel: Ahh, check. I'll attempt more patience. [14:11] greyback_, it probably slipped through the cracks [14:11] sil2100: Ok [14:11] jibel: shall I add a card? [14:12] greyback_, which line of the spreadsheet is it? [14:12] rvr: pong [14:12] jibel: 59 [14:13] jibel: thank you [14:13] greyback_, added [14:13] boiko: Silo 8 [14:14] rvr: yep [14:14] boiko: Does the bug has any manual test? [14:14] boiko: Skip network checks on always dispatchable accounts [14:15] rvr: ah yes, let me check the testplan, salem_ said something about addind that to the testplan, let me double check [14:15] rvr: the manual test is: disable data connections (both wifi and mobile data) and reboot the device [14:16] rvr: the dialer needs to show the carrier name, if it doesn't, that's the bug [14:16] rvr, yes, just ensure there are not network (wifi/data) connections active after a reboot and try making/receive calls/messages. [14:16] s/not/no/ [14:17] salem_: Ok, I'll check that. Please update the test plan. [14:17] rvr, will do, thanks. [14:26] robru: I see that you're double urlencoding all your requests - it was done like this in the spreadsheet as well [14:27] robru: now apache seems confused by this and triple-urlencodes everything [14:27] robru: is there any reason we have to urlencode urlencoded strings? [14:31] sil2100: silo006 is good to go [14:33] Publishing [14:37] rvr, just updated telepathy-ofono testplan. [14:40] salem_: Hmmm [14:41] Something weird [14:41] I'm in a call, but dialer app doesn't show any call [14:41] sil2100: how in an automatic test environment can I unlock the screen? Once I have adb connection :) I could unlock it with a gdbus call... but there is no adb when the screen is locked [14:41] rvr, is the green call indicator at the top? [14:41] salem_: Nope [14:42] rvr, incoming call? [14:42] salem_: Yes [14:42] salem_: Second try seems good [14:43] rvr, do you have wifi/data connection? [14:43] salem_: Nope, deactivated them [14:43] rvr, ok, but it was like this when you got the incoming call, right? [14:44] hey udf is tellig me --revision is unknown flag, what am I doing wrong [14:44] salem_: Yes. call was established but then the UI reverted to the offline state, even when the call was active. I could talk, etc. [14:45] rvr, that's really weird, but I would say that's a separate bug. [14:45] Damn, this bug is a waste of time [14:46] robru: anyway, found how it's happening that it's broken, but I need you to understand why it's happening [14:47] bzoltan_: I think once developer mode is enabled then the screen doesn't need to be unlocked to get adb access [14:47] bzoltan_: at least that's how my device is working ;) [14:47] rvr, the original bug would prevent you from receiving the call in first place. [14:47] popey, davmor2 ? hey udf is tellig me --revision is unknown flag, what am I doing wrong [14:48] sil2100: makor or krillin? I have flashed with --developer-mode --password=${PASSWORD} [14:48] bzoltan_: I'm using arale here with developer mode, but I also switched the switch in system-settings [14:48] pmcgowan: --revision has to go before touch in the command [14:49] pmcgowan: should be u-d-f --revision x touch --channel whatever/channel [14:49] omg [14:49] hehe [14:49] davmor2, thanks so lame [14:49] i love u-d-f [14:49] what's the logic to have this option before touch [14:49] I have to re-learn it every time [14:49] every one try after [14:49] sil2100: I hve developer mode enabled and the adb gets closed when the lock screen comes up ... on mako with vivid overlay [14:49] yeah there is even an open bug [14:50] bzoltan_: hmm, that's strange - could you poke cihelp about that? They might know more since they use devices in the lab for testing [14:50] So they should know how to properly unlock it [14:52] but u-d-f does everything, creates images, flash them, query the server... [14:52] it just needs to parse arguments now [14:54] ah right, it's a detail [14:55] bzoltan_, sil2100, the krillins and arales require a special recovery image to be used during u-d-f flashing [14:55] which enables adb while the screen is locked [14:55] fginther: I amnot sure if I understand that [14:55] fginther: I am on mako this time .. [14:55] bzoltan_, oh, mako doesn't require it [14:56] pmcgowan: run u-d-f --help and it lists the order of arguments and options as you build up the command [14:56] unless things have changed very recently [14:56] fginther: my mako with the latest vivid image it does [14:57] fginther: I see in the --help it says about the --recovery-image= so, where can i get that? [14:57] davmor2, RTFM is not a good answer :) when a user does the same mistake each time he uses a tool, it supposes something is wrong with the tool [14:57] salem_: boiko: Silo 8 approved [14:58] bzoltan_, http://people.canonical.com/~plars/touch [14:58] rvr, awesome, thanks [14:58] fginther: Thank you ... I will ask plars to make a mako version too >( [14:59] jibel: no that was a genuine piece of advice, just append --help and it fills you in on the options available after each step not saying that it is a good thing just a helpful one :) [14:59] bzoltan_, these were not made by plars, that was just the only easily place we had to store them [15:00] davmor2, write a qml front end to it please :) [15:00] bzoltan_, let me see if I can dig up who made them, but if mako now needs them :-( [15:00] bzoltan_: oh, we need one for mako now also? I just grabbed those from an older image because there was no official place at the time, there may be some official place now though [15:00] bzoltan_: maybe sil2100 knows? [15:00] pmcgowan: if you see the code I write you wouldn't even joke about that ;) There are way more competent coders in the room ;) [15:01] plars: Yes, I was strugling my way thru the tools today to figure it out [15:01] heh [15:03] bzoltan_, FWIW, I can see version 202 from ubuntu-touch/rc-proposed/ubuntu channel being flashed on mako with no need for a recovery image [15:09] sil2100: as a workaround for right now, it works if you s/%2520/ /g on the text field and leave the URLs doubly encoded: https://ci-train.ubuntu.com/job/prepare-silo/5565/console [15:18] robru, sil2100 when I log into https://requests.ci-train.ubuntu.com/ I just get the header and no request [15:18] I checked "ci-train-users" on the sso page [15:19] jibel: yeah I was getting an error as well, it seems intermittent, try reloading a few times [15:19] Same here [15:19] Yeah, after a few reloads it works now [15:19] ah it is just terribly slow [15:20] robru, you didn't have to reimplement everything from the spreadsheet :P [15:20] jibel: no no, what's happening is that it's doing an ajax request in the background that silently fails, it retries every few minutes. it's fast when it works [15:21] jibel: and of course I can't access the log, will need IS to poke at it, sigh [15:22] robru, where should I file bugs? when I edit then cancel it logs me out [15:22] jibel: yeah file bugs against lp:bileto, but again this is the same issue, ajax request is failing intermittently [15:23] I'll be patient until you get the logs then [15:24] rvr: thanks [16:07] I just put a redirect in place for the old dashboard URL [16:11] sil2100: jibel: ok sorry my IRC client has picked the perfect time to explode [16:12] sil2100: I'm in webops trying to get things sorted out, apparently the problem is logrotate misconfigured and then bileto can't log properly and gets angry [16:12] sil2100: jibel: it should be temporarily ok now, but I'm working on a permanent fix [16:13] is the spreadsheet still around enough to let me reconfigure a silo? [16:15] Laney: yes [16:15] Laney: the spreadsheet won't update status but it can reconfigure an existing silo [16:16] OK, thanks! === chihchun is now known as chihchun_afk [16:29]