[01:32] Hi, I'm having an issue flashing back to Android from Ubuntu Touch. My backup is on my PC, but my PC is not recognizing my phone, I assume because USB Debugging is not on. I also can't seem to download a ROM though the Ubuntu browser. I have TWRP, but everything was wiped, so no ROM's or backups are on my phone. Would someone be able to help me out? On a nexus 4 by the way. [01:33] SquirrelNuts, Can't you download it from the fastboot recovery [01:33] you in linux or windows [01:33] Download a ROM from recovery? [01:33] Windows [01:34] I dont have Ubuntu PC [01:34] SquirrelNuts, what is the access tool used in windows? [01:34] I don't know what you mean. [01:37] SquirrelNuts, I wondered if there is a tool run in windows to do many things, for example I have a nexus 7 I use the google nexus tool kit it does it all loading roms rooting backing up and much more. [01:38] Oh, yes, I used Wugz Toolkit for all stuff. But it useless because it cant run adb commands without usb debugging enabled. [01:39] SquirrelNuts, If it were me I would look at the side load from recovery for the stock or you backup rom, just a guess though. [01:40] I think you can use the terminal in windows to load stuff, in linux you can, but as you have noticed without the usb debugging running it is harder. [01:41] you might try #android as well [01:42] Ok, thanks. I'll google how to run adb w/o debugging [01:47] hello [01:51] Hello everyone. [01:51] hi [01:52] I was wondering if someone could answer a simple question for me. Will I be able to install ubuntu touch on any old-rooted android phone? I have a beloved Japanese Sharp SH7218u flip-phone that runs 2.2 Gingerbread and I think that Ubuntu OS on it would be awesome considering I can't upgrade it. Is this something that would be possible like being able to install linux on virtually any PC? or will it need to be configured for specific devices? [02:22] AbuAyyoub: to enable a new device, a port needs to be done. At the moment all ports are Ice-cream sandwich based as far as I can tell. Is there a cyanogenmod available for that device? that would be the first step. [02:31] hello === robert_ancell_ is now known as robert_ancell === Namidairo`bnc is now known as Namidairo [03:02] Any updates for porting yet? [03:16] Sooo just a couple of questions, how do you go back a screen on the Nexus 7 o.o === Ursinha is now known as Ursinha-afk === roasted_ is now known as roasted === RAOF_ is now known as RAOF [05:29] hi didrocks ogra_` [05:29] hey rickspencer3 [05:30] so, I guess today is about getting to green on the dashboard? [05:30] didrocks, ^ ? [05:31] * rickspencer3 brews strong cup of coffee [05:32] rickspencer3: it is AFAIK :) [05:32] looks like the tests are running over the weekend, but they failed for the apps [05:33] pitti, good morning [05:37] didrocks, is it the case that auto-pilot needs a bug fix to run those tests, or do the tests just need to be fixed? [05:38] rickspencer3: I would guess it's the case of tests needing to be fixed, if those packages went to distro, they pass on desktop [05:38] rickspencer3: but I think upstream should do the full analyze, I've tons of emails to answer to get Mir ASAP in distro [05:38] didrocks, do you know who from the applications team can answer the question definitively, who would be awake now r soon? [05:38] didrocks, I think they did that analysis on Friday [05:38] rickspencer3: osomon should be one of the first european folk [05:39] didrocks, and ack, I'll follow up with gema and whoever from the apps team [05:39] rickspencer3: do you want me to stop on click packages and mir and track that? [05:39] didrocks, no [05:39] I'll follow up with osomon if/when he's up [05:39] :) [05:39] great ;) [05:39] gema, good morning :) [05:41] I'm going to release all the stuff that are in manual publishing mode [05:41] but some packages are blocked because tests failing [05:41] oh, looks like lots of the apps team is european-based :) === pipedrea1 is now known as pipedream [06:04] rickspencer3: morning [06:04] hi gema [06:04] gema, so, any idea where we are at getting the application tests passing? [06:05] rickspencer3: on the QA side we are working to keep the tests running and to remove infrastructure issues [06:05] gema, do you know why the tests are failing? === Ursinha-afk is now known as Ursinha [06:06] rickspencer3: regarding the runs, I know that adb is failing at times and retrying makes it work so we are going to implement an automatic retry when adb fails [06:06] gema, is it the case that when the tests run, they pass, or is it the case that when they run, they fail? [06:07] rickspencer3: regarding the tests themselves we did some investigation on friday and have some bugs/problem reports on this pad: http://pad.ubuntu.com/test-triaging [06:07] where "the tests" are the application auto-pilot tests are that making the dashboard red? [06:07] rickspencer3: on the 18th image which we did a full read of the logs and why tests were failing [06:07] rickspencer3: there were failures that are either the tests being wrong or the code being wrong [06:08] rickspencer3: we have no way to tell by looking at the logs, it's up to the developers [06:08] rickspencer3: we are going to look at more logs today and continue to raise bugs [06:08] rickspencer3: we are marking any bugs we raise on this qa-touch [06:08] (tagging) [06:10] rickspencer3: atm there are many failures, and the QA team cannot cope with all the triaging alone, so it'd be good to have developers doing this as well [06:10] gema, I can't imagine that there is a set of new issues since last Monday [06:10] rickspencer3: I hope not, will tell you when we've gone through the logs [06:10] from what I understood on Friday, the problem was that the tests were incompatible with auto-pilot [06:11] rickspencer3: ok, so you think they'll pass today? [06:11] rickspencer3: have there been fixes on the tests side? [06:11] gema, I don't [06:11] rickspencer3: ok [06:11] I don't think so because I think that everyone is just saying that it's everyone else's problem [06:11] and I can't find out if the tests have even been fixed yet [06:11] however, it's still early today [06:11] I think I got up too early ;) [06:12] rickspencer3: I will go through them this morning and let you know the status [06:12] gema, I suspect we can make it green today if it's just a matter of fixing the tests [06:12] rickspencer3: ideally [06:12] but if auto-pilot also needs to be fixed, then I am not so certain [06:12] I suspect the case is that the tests just need to be fixed [06:12] rickspencer3: we have people in the US that can fix autopilot if we know what's wrong with it [06:13] gema, I suspect that auto-pilot is red herring [06:13] rickspencer3: me too [06:13] that what really happened was that they didn't look at the tests until Friday, and realized that they were written in a desktop specific manner [06:13] but no one is up yet who can tell me what's up ;) [06:14] rickspencer3: ok, I will wait for that as well before going through the same logs [06:14] * rickspencer3 tries to be patient [06:14] rickspencer3: need to go out for a bit, bb a bit later [06:14] bye [06:41] wow... Ubuntu Touch on my Nexus 7 uses more power on my tablet than I'm able to provide using USB from my desktop. [06:41] and it's just been idling. [06:44] sbeattie: Couple of quick things I noticed about click-apparmor while looking over it on the train: undefined 'error' name in aa-clickprototype; and I think "Trigger: yes" in your .click-hook is unnecessary and can only cause problems? [06:45] (i.e. click-apparmor doesn't define a dpkg trigger) [06:46] Does anyone know what the state of the application lifecycle work is, i.e. whether it'll be usable by, oh, say, Tuesday? [07:00] tvoss_, can you answer cjwatson? ^ [07:00] cjwatson, what do you need in terms of lifecycle? [07:01] rickspencer3, sure [07:04] cjwatson, we have the basic app lifecycle in place, so would be good to know what you need and check if that is available [07:05] tvoss_: Enough to implement the desktop file handling from near the bottom of https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest [07:05] tvoss_: If you could tell me what source package(s) implement the app lifecycle then I can go look [07:08] cjwatson, ah, I think we are talking about a different app lifecycle here :) I'm talking about lifecycle at runtime, stopping and killing apps when they are not in the foreground [07:08] I suspect we are [07:28] ogra_`: when are we expecting the next image? === Ursinha is now known as Ursinha-afk [07:35] Hi Paolo. Thnx for the delete icon. I got it merged to trunk [07:35] Hi nik90|Office :) No problem for me, I like design stuff ;) [07:35] PaoloRotolo: It is now also being used by the weather app :) [07:37] nik90|Office, cool :D [07:38] BTW, who designed the original icon? [07:39] that came from the canonical design team [07:46] gema, as i wroite in my mail on saturday, the build now starts at ~10:00 UTC [07:46] (we had to move it by 1.5h) [07:47] ogra_`: to which list did you send it? [07:47] nik90|Office, so, why they didn't release any .svg? [07:47] gema, ubuntu-phone indeed [07:48] PaoloRotolo: I did ask for them, however I think that they are too busy with the design of the core apps to create and release them [07:48] as a folowup to the former mail that told about build times [07:48] ogra_`: thanks, I am not on that list, I will join :) [07:48] heh yeah. you should ... [07:49] gema, so we had to move it due to daily-release seemingly not being movable and that started to late to make it on the images otherwise [07:49] bevore it ran at 8:30 UTC [07:50] *before [07:50] ogra_`: it's not due to the time when daily release starts [07:50] it's due to the fact that we have to manually ack packaging changes [07:50] so apart if you want to ask people with upload rights to wake up at 3am… [07:50] didrocks, ogra_`: sounds good, just wanted to be able to plan my morning around when the images will be ready [07:51] didrocks, 3am isnt 3am :) [07:51] ogra_`: ? [07:51] (we're on the internet ... ) [07:52] ogra_`: well, there is nobody in the AU time on our team [07:52] didrocks: when are you going to be daily releasing automatically for touch? (phew, I avoided the autolanding word) [07:52] gema: ? we already do that automatically [07:52] for months [07:52] if US people could review the work it would be in at 11pm :) [07:52] ogra_`: it's branching and running automatically for 240+ components [07:52] didrocks: I thought you were going to start running the tests on the mobile devices that we got you a week or so ago? [07:53] gema: but that's not linked to daily releasing automatically or not, what do you mean? [07:53] ogra_`: well, on Sunday as well? :p [07:53] didrocks, indeed not on weekends :) [07:53] didrocks: uhmmm, I may be confused then, I thought you wanted those for autolanding (to be able to run on touch as well as the ones you already do, desktop) [07:54] autolanding* [07:54] gema: right now, we daily release everyday [07:54] automatically [07:54] the only difference is that: [07:54] - tests are running on desktop [07:54] not on phone [07:54] then, we'll run the tests on desktop AND phones [07:54] but for that, we need time to wire things up [07:54] didrocks: ok, do you have an ETA for the wiring to be done? [07:55] seeing the number of requests and backlog, I can't promise any deadline, already 13h a day isn't enough to get new requests unstacked :p [07:55] didrocks, the point is that we delay everyone who needs to work with the images in europe until the afternoon ... but we'll have a meeting for that today, lets not talk it through now :) [07:55] gema: so if your team can help, that would be appreciated [07:55] didrocks: I believe jibel is helping with that === 45PAA6HVN is now known as tvoss [07:55] ogra_`: if you want, you can ack manual packaging changes yourself, I can give you the right for that :) [07:55] ogra_`: so please, do that while I'm sleeping and everything will be fixed :p [07:56] gema: he is, but he has other autopkgtests demands as well [07:56] didrocks: ack, I will talk to him later today about that [07:56] didrocks: do you know at least how much effort is involved in the wire up? [07:57] gema: not that much, I think 3 days would be enough [07:57] didrocks: ok [07:57] didrocks, i'm not attacking you, dont always take it personal, we need to find solutions for delays in the process in the long term, that has nothing to do with you or me [07:57] just need to find those [07:57] ogra_`: +1 :) [07:57] ogra_`: right, but we need to find solutions as you tell. It seems you just want requirements :p [07:57] ogra_`: because why not as well building the image during the european night, instead of the morning? [07:58] we need to define the requirementsd before knowing what we need to improve, no ? [07:58] ogra_`: building overnight doesn't sound bad, it'd give us some more time to look at results and maybe respin in the mornings [07:58] EU mornings [07:58] gema, I gave you an ETA for daily-release tests on touch which is first half of this week [07:59] didrocks, because there are other scheduled builds running before, we only have one livefs builder .... see its not only daily stuff that delays it, this one is in need of fixing too [07:59] well, since last week, I just read some "that sucks" or comparable sentences without any kind of "I want to understand the issues or work on those to help them working". Also, when you are telling others about why this is that way, you don't mention the real details [07:59] jibel: true, thanks for the reminder [07:59] gema, I did all the deployment test on a grouper and since I received a phone last week it needs some adjustements [07:59] didrocks, on the image side i would even like to get to 4 builds/day or so [07:59] didrocks, remember, apt will soon be gone [07:59] ogra_`: you can have image builds without having new components to release [08:00] so that's not related :) [08:00] so fixes and updates obnly come via image updates [08:00] jibel: ack, fyi grouper seems more stable than mako or maguro when it comes to running autopilot tests [08:00] remember that we need a way for upstream to sync their work [08:00] jibel: that doesn't mean they are passing, though [08:00] which is 00 UTC as of now, as it seems it was the best times across teams === jussi01 is now known as jussi [08:00] didrocks, as i said, lets not discuss it before asac's meeting this afternoon [08:01] jibel: it'd be good to know, whenever you have the tests running, how they compare to our runs on images [08:01] jibel: and if the failures are in the same places [08:01] ogra_`: right, just try to give details rather than pointing "this is because of that, but I don't know why" when this was explained :) [08:01] gema, indeed, it'd be good to publish thomein the dashboard too so we can compare :) [08:02] s/thomein/ them in/ [08:02] didrocks, sorry, i dont point, and its a fact that daily releases only run once a day [08:02] jibel: yep, we are working on that as well, even though the views are not straight comparable yet [08:02] ogra_`: which is again, a requirement for upstream to sync their work [08:02] as I explained you multiples times :) [08:02] cjwatson, tvoss: to be precise, I think this relates to the way apps are started / stopped rather than to other application states such as running/suspended, foregrounded/backgrounded etc. [08:02] didrocks, yeah and i'm still not willing to accept that this is not changeable [08:03] cjwatson: Specifically I guess you want to ensure that we stop and prevent apps from launching before an upgrade of said apps, then allow it again once upgrade is complete? [08:03] ogra_`: once we start to keep things backward compatible, it will be possible [08:03] ogra_`: from experience, I can tell you it won't be before 1.0 [08:03] (at best) [08:03] lets keep that for the meeting, so we dont need to talk it through twice [08:06] gema: btw, another way to compare is you having the autopilot tests running on desktop as well :) [08:06] gema: so that we see if the issue is in infra, in difference since latest image and so on [08:07] gema: but yeah, having already our existing tests showing up on the dashboard would be great :) [08:07] didrocks: we were going to land it friday but there were errors when doing a full import of the data, so we held it [08:07] didrocks: we should get there soon [08:07] you mean testing on desktop? [08:07] or publishing our results? [08:07] didrocks: no, the dashboard results for daily release testing [08:08] gema: oh excellent! I wasn't in the loop, so I hope they took the right jobs :) [08:08] didrocks: I hope so too, we can iterate fairly quickly after we land it so I will let you know as soon as it is there so that you can have a look [08:09] oki [08:09] didrocks: fginther and alesage are working on it, hopefully they know what jobs they are dealing with :) [08:09] gema: they never asked, so I hope as well ;) [08:10] ho :) [08:10] ogra_`: FYI, everything is published now (apps is currently moving from proposed to release pocket) [08:10] ogra_`: so, once done, you are able to kick manually an image to get results beforehand [08:11] gema: jcollado: seesm dashboard populated itself nicely during weekend; maguro 21 seem to have fallen over a bit though: http://reports.qa.ubuntu.com/smokeng/saucy/image/3086/ [08:11] only unity isn't published for tests failing, but that doesn't impact you [08:11] cjwatson: is that the only interface you would need? [08:11] asac, mako 20 hasnt run the app tests [08:12] cjwatson: I guess we would also want to signal progress of the upgrade to the shell [08:12] there seems to still be a race that is hit sometimes [08:12] lool, cjwatson so basically the upstart-based application launching, right? [08:12] good morning asac [08:12] ogra_`: right. but thats more stable than it was :) [08:12] tvoss_: Yes [08:12] definitely :) [08:12] rickspencer3: helo :) [08:12] asac, I agree with you, the tests *ran* (mostly) so that's a good start [08:13] ogra_`: what was the last day we propagated an image? [08:13] to current? [08:13] asac, 16th [08:13] ok ... [08:14] asac: it needed a bit of handholding from doanac, but yes it did [08:14] gema: oh. you say, whole weekend doanac was pushing buttons? [08:14] asac: haven't you read his emails? :P [08:15] asac: I am not sure if the whole weekend, but he was definitely diagnosing problems and retrying things [08:15] asac: good thing is, he knows where our unstability comes from (for the most part) and we are going to be working on fixing that [08:16] gema: "weekend view of smoke testing for touch" ? [08:16] that one? [08:16] asac: yep, and automated testing notes 2013-07-19 [08:30] asac: main issues hitting us according to doanac's analysis are adb failing randomly and wifi not being available quickly enough, so we will be working on those two === Ursinha-afk is now known as Ursinha [08:33] lool: I don't care even a little bit about whether apps are prevented from launching or whatever. I want a documented way to create .desktop files that launch apps :) [08:33] lool: I don't care about signalling progress either [08:35] gema: have you seen my phablet-tools merger requests? [08:35] they were about wifi [08:35] or rather having more accurate debugging etc. [08:35] let me see if someone reviewed them by now :) [08:37] cjwatson: oh ok; .local/share/applications/ should work, but indeed we should confirm the best path [08:37] ogra_` and friend: https://code.launchpad.net/~asac/phablet-tools/wait-for-online-with-nm-tool/+merge/174894 [08:37] this thing will help :) [08:37] lool: I know that part, but there's rather more to it than that [08:37] didrocks: who would be the best person to discuss dash / launcher integration with click packages? (place to write generated .desktop files) [08:37] lool: see the wiki page I cited above [08:38] lool: should be mhr3 [08:38] asac, you didnt answer my question :) [08:38] cjwatson: Yeah I looked at it, but it wasn't obvious what's handled by click packages and what's handled by dash [08:39] why the extra subshell spawning [08:39] lool: a click hook needs to write out a .desktop file that arranges for the app to be launched under apparmor [08:39] er, with the appropriate profile I mean [08:39] I don't think the dash can be very much involved in that part [08:39] cjwatson: write, and for now the only way is to prepend aa-exec [08:40] unfortunately what I read in the wiki page seems to be that we have to write an auxiliary shell script, which is pretty rubbish [08:40] (due to bug 1200437( [08:40] cjwatson: so you're looking for a package to transport the click hook that would take an input .desktop file and generate one with aa-exec [08:40] bug 1200437 in qtubuntu "startProcess reverses arguments from desktop files." [High,In progress] https://launchpad.net/bugs/1200437 [08:41] well, knowing which package to put it in would be nice, yes, but I was hoping to be told that the insane generate-auxiliary-shell-script rubbish might be avoidable [08:42] didrocks: thanks [08:42] ogra_`: as i said, the code can be improved... grep played some games on me, so I used sh -c ... [08:43] ogra_`: see the comment i posted during submission [08:43] lool: yw ;) [08:43] "I don't like the sh -c "..." way of doing this, but couldn't get the | easily wrapped in a variable without doing it that way :)..." [08:43] asac, oh, i totally missed that sentence [08:44] asac, so set a commit message and we can approve [08:44] greyback: Did you have a chance to review https://code.launchpad.net/~saviq/qtubuntu/fix-reversed-arguments/+merge/174313 and update app manager? [08:44] (so that jenkins stops failing) [08:44] ogra_`: ok i submitted one branch for each commit... [08:44] ogra_`: will merge bot process them one by one? [08:44] lool, greyback's only on that because he's working on the next app manager [08:44] lool, you need to harass ricmm for that MP [08:44] Saviq: thanks :-) [08:45] asac, i think they are merged in order, yeah [08:45] lool, or rsalveti at least [08:45] lool, I failed, I'm afraid [08:45] Saviq: np [08:45] ricmm: https://code.launchpad.net/~saviq/qtubuntu/fix-reversed-arguments/+merge/174313 is pretty urgent as to fix running click packages confined; would you mind taking a look when you get online? [08:46] cjwatson: Outside of landing the fix (but we're a bit frozen right now), finding a package to hold the hook, would you miss other parts? === pete-woods1 is now known as pete-woods [08:46] asac, hmm, gur there are no branches attached (or at least no changes shown) not sure you can do it like that [08:47] s/gur/but/ [08:48] ogra_`: i think i did a mistake [08:48] now i have: https://code.launchpad.net/~asac/phablet-tools/check-device-and-ip-state-after-sleep/+merge/176145 [08:49] and https://code.launchpad.net/~asac/phablet-tools/improve-network-bringup-console-output/+merge/176144 [08:49] (2nd) [08:49] and 3rd: https://code.launchpad.net/~asac/phablet-tools/wait-for-online-with-nm-tool/+merge/174894 [08:49] lool: I think that's *probably* it, although I'm generally finding with this project that I'm not certain how much there is to do until I've done it :) [08:49] cjwatson: hehe [08:49] ogra_`: odd ... first proposal didnt add the bot [08:49] https://code.launchpad.net/~asac/phablet-tools/check-device-and-ip-state-after-sleep/+merge/176145 [08:50] * greyback is wondering is Saviq 's irc client has a notification whenever he gets pinged [08:50] he=greyback [08:50] In particular I'm going to have to think about how the apparmor and desktop hooks (and presence/absence of either) interact [08:50] But I have to solve it before Wednesday one way or another [08:50] ogra_`: so what needs doing to start building images from my android package? (at least out of ppa to begin with) [08:51] cjwatson: I can see that with the .desktop files in local/ we'll eventually need some helper to fix inconsistenticies in case your system crashes right while we were adding/removing one; we also haven't touched on the signalling upgrades part :-/ [08:51] ogra_`: shall I automate uploads when/if: android, hybris, platform-api, kernels change? [08:51] ogra_`: or simply launch daily builds? [08:51] xnox, we need to add the ppa to livecd-rootfs ... then have a code snipped that installs the debs and copies the files out of the chroot into the build dir [08:52] cjwatson: concerning absence of hooks, this is why I was pushing towards defaulting to no permission at all (entirely confined) for apps; jdstrand would know the final story on this [08:52] xnox, and in the second step cdimage needs to learn to publish them [08:52] err I meant abscence of profile, not hook [08:52] * lool needs another coffee, it's way too hot here [08:53] greyback, no, I get a notification whenever "saviq" shows up in a merge request URL ;) [08:53] lool: Yes, we talked about that on appstore-devel [08:53] Saviq: aha [08:53] xnox, given your bootimg has the right stuff in it i would suggest we replace the bootimg creation code in live-build/auto/build with the copy around code [08:53] lool: I don't see why we need to signal anything to the shell; surely it should notice changes in .local/share/applications via inotify [08:54] ogra_`, do you guys get input in apps working on pending? [08:54] popey_, ↑ [08:54] Saviq, i doubt he is up, he is in oregon this week [08:54] ah [08:55] and i havent tested on the weekend, let me sync a fresh image [08:56] ogra_`, manta seems fine, my maguro must be b0rked, bootstrapping [08:57] 19 definitely worked here, thats the one i have installed accordign to the stamp [09:00] gema: do we want to add more tests :)? [09:00] i mean ... we are half way through the first batch only [09:00] asac, do you think i could mark a newer image as /current now ? or do we actually want to hold back until all of utah is fixed ? [09:01] asac, stgraber needs the newer recovery image stuff in /currend so a fresh bootstrap gets the new added ubuntu features that live in the recovery images [09:01] else system based upgrades wont work [09:01] asac: I'd like to get these fixed before we add more to the batch [09:01] asac: but I guess it's your call [09:02] (--bottstrap doesnt pull from --pending iirc) [09:02] gema: ok... is there a way to have more tests added, but not report them on our main dashboard? [09:02] in that way we could give more warnings to folks that havent been added [09:02] so they can prep [09:02] asac: that'd make it even more difficult for us to keep running [09:02] ok [09:02] asac: I'd like to fix the adb problem and the wifi unstability issue and then add the second batch [09:02] gema: you think it can be more difficult? [09:02] gema: you won't be able to solve the wifi issue unless its fixed by my bug [09:03] err merge proposal [09:03] asac: we will, we will make the test environment more resilient [09:03] asac: can I have a look at your MP? [09:03] gema, see above ... we will need testing of the recovery mode too in the future, at least for the bits that were added on top of the stock recovery (gpg, parted and the system upgrader scripts) [09:03] sure... it basically cleans stuff up and fixes that we still identify a device as online [09:03] that is online on two net devices [09:04] gema: https://code.launchpad.net/~asac/phablet-tools/wait-for-online-with-nm-tool [09:04] gema: the real real solution would be to focus on adb [09:04] and then somehow make networking go through adb [09:04] at least the networking needed to setup device (e.g. pull new packages etc) [09:04] wifi in a lab is always interference etc. [09:05] asac: ok, if that's possible, but we also need to run tests on wifi [09:05] asac: i.e. we need to make wifi robust [09:05] ogra_`: can you maybe help gema getting some magic to get the networking through adb forward? [09:05] gema: we can have wifi tests [09:05] gema: but thats different from having all devices requiring wifi [09:05] and pulling data [09:05] asac, ssh via adb you mean ? [09:05] you could then tag one or two devices as wifi test devices [09:05] rather than having all devices in parallel going on a wifi rampage [09:05] asac: wifi is not failing randomly during execution, it is just sometimes taking longer to be up when provisioning [09:06] asac: and the test tools wanting to start before the wifi is actually there [09:06] we dont have any network gardget support via usb atm in case you mean actual networking through USB [09:06] gema: you are sure? my fix will also give us 20 more seconds :) [09:06] *gadget [09:06] and better logging (so we really see if thats the problem) [09:06] asac: if you fix does that, then it's most likely going to get rid of many of our problems [09:06] gema: do our devices have a SIM? [09:06] asac: some of them [09:07] if so the current network code will not only fail if we are not waiting long enough [09:07] but also will fail if both data as well as wifi are up too quick :) [09:07] asac: so do you want sim on smoke testing devices or no sim? === b0bben_ is now known as b0bben [09:08] gema: thats fine to be in there... [09:08] asac: so you want the devices to have sim [09:08] correct? [09:08] just saying that current phablet-tools "wait for networking" code will fail if we are online on wifi and gsm :) [09:08] gema: i guess so [09:08] asac: ok [09:08] asac: then we'll have to fix the tools not to fail in that case [09:09] asac: right now I don't think we have a sim on the devices we are using [09:09] for smoke testing [09:10] asac: we have two other devices with sim that we are using to get the connected tests ready [09:10] and the lab infrastructure to do that [09:10] gema: right. that sim might also explain why the networking falls over [09:10] asac: no sim on smoke testing [09:10] we have not enough logging to see whether with current code our network is up too quick or too late [09:10] gema: ah ok [09:11] then well, it will give us 20 seconds more [09:11] asac: ack, we will try that [09:11] ogra_`: well, dont want to add more requirements [09:11] but maybe there is something smart we can do through adb forward [09:11] asac: let me know when your fix lands so that we can update the phablet tools in the lab [09:11] like doing a revert ssh tunnel [09:11] for the http and ssh ports [09:11] and seeding [09:11] dnsmasq [09:13] sbeattie: FYI there's a "click pkgdir" in click 0.2.1 which you can use to get the top-level app directory from either the package name or any path underneath that directory [09:13] cjwatson: I was thinking progress of the upgrade [09:13] lool: doesn't seem worth it [09:13] cjwatson: e.g. over the duration of the download, and over the duration of the install [09:14] download, yes, but install I don't see the point [09:14] cjwatson: unpacking a GB of data will take some time surely [09:14] maybe, but we don't have much of an opportunity to hook into the unpack to send signals [09:14] android doesn't bother with install progress [09:14] so I don't see a need to [09:15] cjwatson: Right, neither does iOS show progress of the installation itself; but they both show when switching from download to installation [09:15] but I guess that's implicit from the download progress [09:16] right, sure - that'll be a packagekit signal [09:16] asac, well, the androiid gadget driver has rndis networking support, the prob is that our adbd cant do that atm [09:16]