=== genii-around is now known as genii [06:38] good morning === chriadam is now known as chriadam|away === morphis|away is now known as morphis [07:44] o.O [07:45] jaywink: O.o [08:00] hey all [08:01] i had a device view all of the sudden on my phone while having a call, and now I can't find that view anywhere [08:01] didn't even know it existed... [08:01] how do I get to it again? === psivaa_afk is now known as psivaa [08:09] welcome === vrruiz_ is now known as rvr [08:23] hmmmm tried phablet-tools -b to flash all data (maguro) .. it died when trying to transfer autodeploy.zip to device (permission error). Started adb-server as root (first google hint) but now I can only get to recovery mode and phablet-tools does not see the device ... any hints? :) [08:34] ok I think I managed to fix it, deployed autodeploy.zip to device in recovery mode with adb push manually === chihchun is now known as chihchun_afk [08:37] jaywink: cool if you found a way. one thing is that if you get permission problems and adb devices gives you "??????", there might be an USB id change and you need to update udev rules [08:37] or at least I encountered a such thing, even though I don't have maguro [08:38] so in /lib/udev/rules.d/69-libmtp.rules I added a line SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="d002", MODE="0666" [08:38] sudo service udev restart and adb devices (etc) worked again [08:38] but adb root obviously is the first thing to do === chihchun_afk is now known as chihchun [09:11] nik90, hey [09:14] sil2100: the app stack is still failing utah tests, it seems that the dep that oSoMoN added yesterday was not enough, mind checking? === greyback|away is now known as greyback [09:17] didrocks: ACK, ok, in the morning the check job was still waiting for a free slot on the generic job queue, I'll take a look and poke oSoMoN [09:18] sergiusens, hey, I reviewed phablet-tools in NEW, small comment [09:19] "License: GPL-3 [09:19] ... [09:19] See the applicable version of the GNU Lesser General Public [09:19] License for more details." [09:19] sergiusens, seems like somebody took the snippet of the LGPL and dropped the L but forgot to drop the Lesser in the text [09:19] sergiusens, that's not a blocker to accept it but would be nice to fix (in debian/copyright and some of the sources) [09:26] hey Saviq, looks like i18n works well for Unity on the phone, which is pretty cool. I can see translated messages for Applications, Music, etc. Do you know where the strings for "Frequent Apps", "Favourite People" and such come from? [09:28] didrocks: the missing dep is still missing, the autolanding job for my MR failed (and is still failing), it looks like the job itself is broken :/ [09:30] oSoMoN: argh, ok :/ [09:30] sil2100: ^ [09:31] didrocks: I’m considering merging it manually, given that it’s really trivial, I’m tired of fighting windmills, I’ve wasted so much time this week waiting on jenkins [09:32] om26er: would you object to me merging manually https://code.launchpad.net/~osomon/gallery-app/missing-uoa-dep/+merge/166552, to bypass the busted jenkins job? [09:34] oSoMoN: that's fine with me FYI ;) [09:34] dpm, those come from the applications lens [09:34] oSoMoN: tell us, we'll rebuild the daily apps stack then [09:35] so that you can be published [09:35] didrocks: ok, waiting for om26er’s green light [09:35] sure! [09:35] dpm, AFAIK they need to come translated from there already (i.e. we won't ever know all the category names used by all the scopes) [09:36] om26er: hey sry I am at the university, cant talk now [09:36] om26er: but leave any messages to nik90, and I will look at it when I get home [09:38] Saviq, yeah, so we just need to internationalize the apps lens, right? Is this the right branch? -> https://launchpad.net/unity-lens-applications/phablet [09:39] dpm, yes, and it should already be internationalized, no? [09:40] dpm, btw, the Video and Music lens are static, driven by http://bazaar.launchpad.net/~phablet-team/demo-assets/trunk/files/head:/lenses/ [09:40] oSoMoN: fine with me as well [09:40] Saviq, it looks like the apps lens here is i18n'd on that branch above, but it looks like vala code? [09:41] dpm, yup, it is [09:41] oSoMoN, yeah, please merge it manually [09:41] (and my internet sucks for the day) [09:41] ok, thanks, merging [09:41] oSoMoN: could you give me a sign once it's done? [09:41] dpm, here's unity-lens-mock that's driven by the .json files https://code.launchpad.net/~phablet-team/phablet-extras/unity-lens-mock [09:41] Saviq, ack on Video and Music lens, so I guess we cannot do much until they are not static [09:42] dpm, yeah, probably not worth the effort [09:42] nik90, the clock app have a problem starting [09:42] oSoMoN: I'll re-trigger the stack once it's in [09:42] nik90, file:///usr/share/ubuntu-clock-app/ubuntu-clock-app.qml:136 Type TimerPage unavailable [09:42] nik90, tried both trunk and the package from the ppa.. [09:42] Saviq, yeah, I agree, not for now === om26er is now known as om26er|lunch [09:42] om26er: ok, that's weird. Which version r u running it on? [09:43] Saviq, does it make sense to enable translations in LP for the apps lens (as far as I can see it's just a matter of creating and committing the .pot file) or do you expect big changes there? [09:43] sil2100, didrocks, om26er|lunch: merged and pushed [09:44] sil2100: relaunching it? [09:44] oSoMoN: thanks! [09:44] dpm, the apps lens is just a modified lp:unity-lens-applications - it *should* just use the translations that are already there [09:44] dpm, and well, it goes away when we switch to saucy (100 scopes), so... [09:44] (just rebuilding the webbrowser package I guess) [09:45] dpm, we're not going to touch it at all anymore [09:45] didrocks: yep! [09:45] didrocks: should I specify just gallery-app in the run command, or do a whole stack rebuild? [09:46] sil2100: just what needs to be rebuild please, launchpad will be happy :) [09:47] didrocks: I'll abort the current apps check job then [09:47] Saviq, yeah, but it only has one translation, Danish, so it's not very useful for non-Danish speakers :) http://bazaar.launchpad.net/~unity-team/unity-lens-applications/phablet/files/head:/po/ so it might be worth opening translations in LP to get some more languages in [09:48] sil2100: hum [09:48] sil2100: remember that UTAH doesn't like that? [09:49] dpm, that's weird - it's the same for http://bazaar.launchpad.net/~unity-team/unity-lens-applications/trunk/files/head:/po/ === mmrazik is now known as mmrazik|afk [09:49] dpm, it's shipped by the lang pack [09:49] dpm, how does that work? [09:50] didrocks: I did not remember that, although aborting the upstream check job is a problem for UTAH? [09:50] didrocks: did it cause some problems in the past? [09:50] sil2100: if you relaunch one using UTAH, yeah [09:50] sil2100: UTAH won't deprovision the machine and will continue running the tests [09:50] so next -check job -> try UTAH -> FAIL [09:51] Shit [09:51] dpm, btw, I'm off until Monday, so don't expect me to be responsive [09:51] didrocks: I think we should have a document with all the common problems and quirks related to daily-release [09:52] Saviq, yeah, for Ubuntu packages it doesn't matter if the .po files are not in the code, as they are fetched from Launchpad directly by the language packs. But as the language packs are not installed on the phone, and they are not shipped in the package itself, then they can't be loaded from either location. So what needs to be done is enable translations in the upstream project so that they are committed to the branch and then shipped in the package [09:52] dpm, ok, works for me [09:52] Saviq, ack, you've actually been very responsive. Now go and enjoy your time off, thanks! [09:52] didrocks: so that it's more probable that we're all on the same page and at least have no excuse for repeating a mistake like I just did === davmor2_ is now known as davmor2 [09:53] didrocks: so, basically now the check job will fail if re-run, yes? [09:54] sil2100: please feel free to document :) [09:54] sil2100: yeah, it will fail [09:54] until UTAH finishes [09:54] so please, check with the QA guys [09:56] dpm: can you confirm if the clock app is starting for you? om26er|lunch has a problem starting the app. [09:56] didrocks: will do, but just so I have a good understanding of it - what happens if the generic testing job finishes before the -check job is re-ran? [09:56] didrocks: should it be fine then? [09:56] nik90|Mobile, om26er|lunch, it starts from the 144 image. Or do you mean from trunk? [09:56] ogra_: good news ish I decided to run a debug build process for crespo. I did breakfast crespo brunch crespo then hashed out 1 line at a time till I got it to build. Looks like I removed the nfc security lines originally. So now I'm going to see if this build completes then add the Ubuntu specific lines one at a time and see if any of those broke the build :) But I am making headway it seems woohoo :) [09:57] dpm: could you try trunk? [09:57] dpm: he couldn't get it to work from trunk and ppa [09:57] sil2100: is the generic job is still running, that's fine [09:57] that will protect the lock [09:58] didrocks: the generic job is still runinng but it should finish pretty soon [10:00] nik90|Mobile, on the mobile r89 works for me (r92 is latest, but after r89 all changes are just translation commits). On the desktop trunk (r92) works for me too [10:00] sil2100: ok, so once it's finished, it means that UTAH finished [10:00] which is what we want === FUF_ is now known as FUF [10:07] check out the cover of this german pc manazine: http://www.pcwelt.de/tipps/LinuxWelt_3_2013_-_jetzt_am_Kiosk-Neues_Sonderheft-7926353.html?view=zoom&zoom=aufmacher [10:07] nice [10:10] heh, i wonder if they actually ship the images on CD === ubot5` is now known as ubot5 [10:10] err, DVD [10:10] it kind of indicates they do [10:11] didrocks: I think the ati run of the generic job is broken, is it possible to abort that while keeping UTAH happy? [10:12] will get it later and see what's in there [10:21] sil2100: not that I know of, did you ask on #qa? === mmrazik|afk is now known as mmrazik [10:32] nik90|Mobile, dpm it starts fine for me. mmrazik is the one seeing the issue [10:33] nik90|Mobile: I'm getting this (line 10-14): http://pastebin.ubuntu.com/5719267/ [10:34] there is a bit of autopilot stuff around but 10-14 is what I get if I try to run the app without autopilot [10:34] this seems to be the issue: [10:34] file:///usr/share/ubuntu-clock-app/common/AnimationContainer.qml:62 UbuntuNumberAnimation is not a type [10:37] mmrazik: which version of the UITK do you have installed? [10:39] apt-cache policy qtdeclarative5-ubuntu-ui-toolkit-plugin ubuntu-ui-toolkit-theme [10:39] we have r526 now [10:40] timp: the one from raring archives [10:40] looks the canonistack instance is down. will need to check later what exactly is that [10:41] but I did check I have the latest [10:41] 0.1.43 for both of them [10:43] mmrazik: ok. that's the problem, 0.1.43 is old and doesn't have the UbuntuNumberAnimation, so to run the clock app you'll need the UITK from the ppa [10:44] timp: thanks [10:45] mmrazik: ppa is listed here http://developer.ubuntu.com/get-started/ === mmrazik is now known as mmrazik|afk === ckpringle_ is now known as ckpringle [10:52] guys the adb push out/target/product/crespo/*.zip /sdcard/autodeploy.zip line is giving me an error for adb should it be one or the other of the zip file that are in out/target/product/crespo/ I have cm-10.1......crespo.zip and cm_crespo_ota...zip in the directory [11:02] davmor2, you dont want the ota file [11:02] ogra_: thanks === MacSlow is now known as MacSlow|lunch === mzanetti is now known as mzanetti|lunch [11:24] mmrazik|afk, om26er: the reason for that error is because his Ubuntu SDK is not updated. Ensure that both the ppa listed in developer.ubuntu.com are included === mmrazik|afk is now known as mmrazik [11:24] nik90|Mobile: ack [11:25] mmrazik: ack? [11:26] nik90|Mobile: acknowledged/all clear :) [11:26] thanks [11:26] mmrazik: wonderful :) [11:48] Hi [11:49] I am trying to install ubuntu touch in my nexus 7 tablet [11:57] renato_: hi. Do you know where is the source code for ChewieUI? === pete-woods is now known as pete-woods-lunch [12:03] paulliu, indicators-client [12:04] renato_: ok.. thanks. [12:06] renato_: ok. There's a bug cause the datetime mojibake. I guess it is because the fromLation1 function in chewie_datetimeplugin.cpp. I'll see if I can change it to UTF-8 and solves the problem. [12:25] renato_: https://code.launchpad.net/~paulliu/indicators-client/fix-mojibake/+merge/166772 [12:26] renato_: please help review. === mzanetti|lunch is now known as mzanetti [12:42] paulliu, approved [12:49] ~seen dank101 [12:49] renato_: thanks. [12:51] tani: /j #fooo* === MacSlow|lunch is now known as MacSlow [13:29] ogra_: so close yet so far :( recovery fails to do anything with the image :( [13:30] you can forcefully install it by selecting it in the recovery menu [13:32] ogra_: Install /sdcard Finding update package... Opening update package... Verifying update package... Installation aborted. [13:32] ouch [13:34] ogra_: I even tried via adb sideload din't like it from there either [13:34] ricmm, rsalveti, ogra_: I'm reviewing android-audiosystem in NEW, the debian/copyright has some small things are inexact [13:35] * it says [13:35] Files: include/machine/* [13:35] License: BSD [13:35] but there a few other files under BSD in there [13:35] include/cutils/atomics.h: BSD (2 clause) [13:35] include/media/stagefright/WAVEWriter.h: BSD (3 clause) [13:35] include/media/stagefright/QCOMXCodec.h: BSD (3 clause) [13:35] for example [13:36] the files in etc/pulse/ come from pulseaudio and are LGPL2+, that should probably be reflected in the copyright as well [13:38] include/unicude is also Copyright "International Business Machines" which is not listed in debian/copyright [13:38] those files have also no license infos [13:40] but the unicode license afaik stipulate that the files can be used/redistributed/modified but that the copyright notice needs to be kept in the copy [13:40] didrocks, ^ [13:41] didrocks, since you asked to review, I'm fine with the first issues but the unicode one seems like a potential NEW blocker, the redistribution details and license infos should be included with the copy from what I understand [13:44] seb128: thanks for the info, rsalveti: ricmm: can you fix this today? so that next daily have it right [13:45] mzanetti, hey! are the autopilot tests working for the qml-phone-shell on devices now ? [13:45] om26er: I think so... thomi does not want to fix the display thingie in autopilot tho... [13:45] om26er: so I guess we need a workaround for that in the AP tests [13:48] mzanetti, right, do you need help on that ? [13:48] mzanetti, i could try if its not going to be messy === dandrader is now known as dandrader|afk [13:59] om26er: i think a few folks are getting hung up on it....if you could take a run at it [14:02] kgunn, sure, I will look into that. I might need guidance from some [14:04] anyone remember what the clock app bzr url is? [14:05] jounih, lp:ubuntu-clock-app [14:06] om26er: Thank you for your merge proposal :) [14:06] om26er: thanks === dandrader|afk is now known as dandrader [14:07] Oranger, np, if you need any help with autopilot tests there I'll surely help [14:08] om26er: autopilot tests is something new for me, so I think that I will need your help some times [14:09] Oranger, sure [14:16] oSoMoN: do you have anything depending on sphinx? [14:16] * didrocks sees that sphinx-voxforge-hmm-en sphinx-voxforge-lm-en wants to be installed [14:16] I guess it's the hud… [14:17] didrocks: sounds like the hud, indeed [14:17] tedg: any recent transition to libhud2? [14:17] didrocks, ? [14:18] tedg: I see the hud is depending on sphinx-voxforge-hmm-en, [14:18] sphinx-voxforge-lm-en [14:18] which are in universe [14:18] Yup [14:18] we can't have that in ubuntu [14:18] multiverse* [14:18] Why are they in multiverse? [14:19] tedg: sorry, my bad, I need to drink coffee [14:19] The source is GPL [14:19] uh [14:19] tedg: is that really recent, like today? [14:19] or a long time ago? [14:19] No, it's been a while. [14:19] ok, so someone broke the package detection in UTAH [14:19] a long time ago [14:20] and now that otto is checking [14:20] it's working again [14:20] * tedg didn't do it, he promises [14:20] tedg: I believe you on that one :) [14:20] tedg: thanks! [14:20] NP [14:20] didrocks: hm, was there some switch from generic autopilot to autopilot-raring-daily_release ? [14:20] didrocks: for the check jobs? [14:20] sil2100: right, don't touch the apps stack please [14:21] we are pluggin in otto in it [14:21] ! [14:21] \o/ [14:21] sil2100: that's why we see that the package dependencies are not correct :) [14:21] sil2100: so probably some troubles [14:21] in the first run [14:21] to have the list correct [14:23] ACK [14:23] sil2100: so, we are adding the hud for now [14:23] sil2100: as it's transitionning [14:23] to not fail the job everyday [14:23] as long as we are in this transition period [14:24] Since the last correct generic AP job returned just 1 failure, so I've been wondering if maybe we should force publishing? [14:24] Ok, noted [14:24] sil2100: no, don't touch it, we need it for now :) [14:24] didrocks: affirmative ;) [14:24] But excellent to finally see the new test environment in action [14:25] ogra_: so how's that container flip going? [14:26] sil2100: the logs and artefacts looks good for you? [14:27] stgraber, well, waiting for lxc-android-config to show up in the archive, then seeding and the biggest part should be done ... one bit for later this evening for me is to implement the fstab creation somehow [14:28] stgraber, and i found a way to repack the zips in a working way for the flipped model, so on monday we should have the standard dual zip setup available for brave people that want to try it [14:29] stgraber, oh, and the system image ships the initramfs for us in /boot/ on the ubuntu side now [14:29] ogra_: cool. Once we have that, I'll look into what's needed to convert those into the .tar.xz format I need for the new upgrader [14:29] <_salem> ricmm, ping [14:29] pong [14:29] stgraber, unzip .... tar it ... should be trivial [14:30] ricmm, did you see seb128's ping above about the audio stuff ? [14:30] ogra_: unzip => convert all of the weird file metadata to actual file permissions => tar it [14:30] ogra_: the middle part is the not so trivial one ;) [14:30] stgraber, the META-INF stuff ? [14:31] well, it has a binary interpreter that we will need to package anyway === mmrazik is now known as mmrazik|afk [14:31] the rest is text files [14:31] ogra_: yep. That part will be different as we use tar and so can and will ship the files with all the attributes [14:32] ogra_: no [14:32] ogra_: so with the tar.xz format, our metadata file will be completely different and basically limited to removing files and formatiting partitions [14:32] * ricmm scrolls [14:32] ricmm, seems there are copyright issues [14:32] stgraber, we need copying and adding files too [14:33] else things like userdata preservation wont work [14:34] ogra_: iirc rsalveti did that packaging [14:34] lets wait for him [14:34] ah, k [14:34] stgraber, http://bazaar.launchpad.net/~phablet-team/touch-preview-images/phablet-build-scripts/view/head:/ubuntu_data is what we use today [14:35] and indeed http://bazaar.launchpad.net/~phablet-team/touch-preview-images/phablet-build-scripts/files/head:/META-INF/com/google/android/ [14:35] <_salem> ricmm, hey, I just flashed build 145, and it seems the screen doesn't turn off during a call. the proximity sensor should be already working, right? [14:35] for the update-binary we'll have to wait for the toolchain though [14:35] <_salem> ricmm, is there a way to debug what's going wrong? [14:37] ogra_: right, I expect that stuff to be quite different for the tar.xz images but I'll wait for the .zip ones to be ready and then will prepare a clear plan on what'll be the difference for the .tar.xz. Then we can discuss whether it's easier to have the livefs buildd spit out both format or simply have a tool converting them. [14:38] _salem: what device? [14:38] stgraber, well, i think the binary interpreter is needed for installing [14:38] <_salem> ricmm, galaxy nexus [14:38] stgraber, the android recovery mode kind of expects it [14:39] once the device is installled and our own recovery is in place thats indeed different, but for the initial install you will need what androids recovery wants [14:39] _salem: its working fine for me on galaxy nexus, have you flashed everything correctly? [14:40] ogra_: yeah, I'm not against keeping both formats for the time being for those who're not using our recovery image, but for the devices we care about, we'll have our own recovery image that'll understand the .tar.xz format (and possibly only that one) [14:40] _salem: have you tried many times? or just once [14:40] <_salem> ricmm, well, I did a phablet-flash, should I wipe the entire phone? [14:40] ogra_: so we may end up generating a .zip that only contains the recovery image, have that one applied, then push the files and have the new recovery unpack the .tar.xz [14:40] <_salem> ricmm, I tried 3 times [14:40] stgraber, i'm not tallking about "those who're not using our recovery image", i'm talking about everyone ... [14:40] stgraber, the initial install needs something thats compatible with androids recovery mode [14:41] what comes after the initial installl is all in our hands ... but for replacing whats there we will need to use what android wants [14:41] ogra_: sure, but for the devices we care about currently, we can just push the new recovery with fastboot, reboot in recovery, adb push the files, reboot and we're done [14:41] you need to get "our own recovery image" in place first ;) [14:42] ogra_: but yeah, I expect we'll want to build a .zip that does that for the devices that don't have fastboot [14:42] fastboot access is a matter of luck [14:42] sil2100: seb128: http://10.97.0.1:8080/job/cu2d-apps-head-2.2check/44/console \o/ [14:42] we shouldnt rely on it [14:42] _salem: can you pastebin /system/ubuntu_stamp please [14:43] otto: 11 min, utah: 30 min for the same tests :) [14:44] didrocks, \o/ [14:44] but with archives! [14:44] (which takes 1min30) :) [14:45] Ohshit! [14:45] sil2100: want to publish the apps stack now? (I forced the manual publishing on purpose before ;)) === netcurli_ is now known as netcurli [14:46] didrocks: sure thing, I'm just browsing through the artifacts looking how things are now ;) [14:46] Let me fire publish [14:46] <_salem> ricmm, https://pastebin.canonical.com/91935/ [14:47] are there plans to get camera and audio working on the Nexus 7? [14:47] is there an individual bug for data via GSM in addition to the wifi? [14:48] didrocks: publishing forced, but otto testing looks awesome - will we switch all test machines to this platform? [14:48] (once we test it out more of course) [14:49] _salem: all that looks right, how are you trying it? [14:49] when in an active call, put your hand over the prox sensor (top right) [14:49] <_salem> ricmm, yep, exactly that. the screen keeps on. [14:49] sil2100: yeah, we are deploying little by little :) [14:49] ok [14:50] sil2100: we need to have a saucy install as well [14:50] ogra_: stgraber even today, officially for first install we flash our recovery image (it's compatible for other devices), I don't see a need for building the zips [14:50] _salem: gonna need you to install libplatform-api1-hybris-tests and run test_android_sensors_api or something like that, from that package [14:50] sergiusens, so you would go with fastboot for everything ? [14:50] <_salem> ricmm, ok, let me try [14:51] test_android_sensors_api | grep proximity might be easier to parse [14:51] * ogra_ was in the same camp until rsalveti convinced me we should go with adb rather [14:51] ogra_: for the first flash, yes [14:51] ah [14:51] but first run it without the catch to see if you are getting any sensor events at all [14:51] fginther: ping, are you around right now, or in the middle of AFKing? [14:51] sil2100, I'm here [14:51] ogra_: then we would need some instructions to allow people to flash/build these recovery images for other devices [14:52] _salem: I need 5 min, ping me with the result or post it on pastebin [14:52] sergiusens, yeah [14:52] ogra_: and last... we just need to make sure the recovery image is backwards compatible [14:52] i wouldnt want to flash my SGS2 with heimdall all the time [14:52] ogra_: at least for community, for shipping (and nexus line) it wouldn't matter that much [14:52] since that actually can brick it [14:52] yeah [14:52] ogra_: yeah, exactly... [14:53] ogra_: I have to see why my Note is bricked since last week :-P [14:53] <_salem> ricmm, ok, I see the events there [14:53] ugh, isnt that yoour main phone ? [14:53] <_salem> ricmm, void on_new_proximity_event(UASProximityEvent*, void*) [14:54] sil2100, I'll be offline soon though [14:54] right, that was my thought, use fastboot to push a new recovery image, then push the rest through that. I wouldn't use fastboot to push everything (as we know that tends to fail), but using it for the first flash of the recovery partition should be reasonable. [14:55] fginther: \o/ hm, do you remember that strange PPA building problem we encountered on the spring last year when packages for some arch's failed building because the -dev package was somehow available earlier and the lib version was not available during build? [14:55] and for devices that don't support fastboot, they should be able to easily roll a .zip that replaces the recovery partition [14:55] ogra_: my main phone now is an Ubuntu Touch install on maguro ;-) [14:55] (long description) [14:55] sergiusens, doesnt work, i have that here too [14:55] :P [14:56] sil2100, It sounds vaguely familiar [14:56] fginther: let me illustrate it with two pastebined logs [14:57] stgraber: ogra_ I would rather not do it in a zip to update recovery... deploying through zips have chances of breaking too [14:57] just use the tool for the device explicitly, people should know when they do a dangerous operation [14:57] fginther: for instance http://paste.ubuntu.com/5720094/ and http://paste.ubuntu.com/5720095/ [14:57] I'm fine with that [14:58] fginther: getting things like "libunity-dev : Depends: libunity9 (= 7.0.0daily13.05.30ubuntu.unity.next-0ubuntu1)" [14:58] sergiusens, i'll just go with what stgraber implements, i trust him :) [14:59] fginther: it started happening again, this time it seems to attack powerpc - do you remember if we had any ideas on the root cause of that? Since I can't remember anything solid [14:59] sil2100, ah, is this because the -dev packages are built by i386 and are therefore availalble sooner [15:00] _salem: back, can you check your version of powerd? [15:00] <_salem> ricmm, 0.11 [15:00] sil2100, we disabled powerpc builds for unity when pusing to the ppa [15:01] well all seems to be fine then, something might be wrong with your testing. try doing adb logcat and then ringing your phone from another [15:01] fginther: I remember we had a conclusion like this, but the problem is... -dev packages have 'any', so they're being built for every arch seperately [15:01] fginther: so it can't be the case [15:02] _salem: and pastebin the logcat out [15:02] fginther: for instance, libunity-dev is built for i386, amd64, armhf and powerpc [15:02] sil2100: it can be a dependency of this -dev package which is arch:all and not available everywhere [15:03] sil2100, hmmm, sorry, I thought it was just built once... [15:04] didrocks: would make sense, but strange thing only powerpc would be affected, as theoretically armhf is much slower [15:05] sil2100, a very hackish solution would be to insert additional dependencies prior to uploading the source package [15:05] sil2100, for example replacing "libunity-dev," with "libunity-dev,libunity9," [15:06] * rsalveti reads backlog [15:07] <_salem> ricmm, http://pastebin.ubuntu.com/5720120/ [15:08] seb128: didrocks: why did we push audio-audiosubsystem to the archive today? [15:08] yesterday actually [15:08] right [15:08] _salem: is your powerd even running? [15:08] _salem: does the auto turn-off of the screen happen? on timeout, 5 seconds [15:09] I'd like to get a ping or such, as I was maintaining it and knew it needs a bit more love [15:09] rsalveti: because it's part of the stack for phablet-tools, that sergio wanted into saucy [15:09] rsalveti: when I asked about audio-audiosubsystem, he acked that's fine to push to the archive [15:09] sil2100, gotta go, I'll let you know if I think of anything else [15:09] <_salem> ricmm, powerd is running. the screen is turning off correctly. [15:10] didrocks: right, didn't know that [15:10] didrocks: so I'll check, might not be able to check today [15:10] got some other stuff for today === mmrazik|afk is now known as mmrazik [15:10] _salem: can you tell me the steps you are using to test this? [15:10] rsalveti, no worry, it's in the queue but it doesn't need to get in today, you can fix those few issues next week [15:11] rsalveti: ok, thanks, Monday is fine :) [15:11] didrocks: btw. did you see my ping in the morning about the evdev package in NEW? [15:11] seb128: didrocks: cool, ok then [15:11] seb128: thanks for the review anyway [15:11] yw [15:11] <_salem> ricmm, the screen turns off, but it takes 30 seconds, not 5 [15:12] sil2100: hum, I probably misses that [15:12] missed* [15:12] sil2100: I pushed it yesterday evening IIRC [15:12] didrocks: since evdev the old package I see is still in the NEW queue [15:12] ah, interesting [15:12] <_salem> ricmm, well, I make a call, when the call is answered I cover the proximity sensor with my hand, and the screen keeps on [15:12] didrocks: while python-evdev should be if anything (if the packaging looks ok to you) [15:13] sil2100: it's in already [15:13] didrocks: by 'in' you mean 'in saucy'? ;p [15:13] sil2100: evdev rejected [15:13] <_salem> ricmm, when I do the same using the hybris testing program, I see the event is being emitted correctly though. [15:13] sil2100: well, you should be able to check: (and you should be suscribed to saucy-changes :p) [15:13] _salem: I've just run exactly the same test and it works for me, something seems to be wrong with your powerd<->ofono communication [15:13] sil2100: https://launchpad.net/ubuntu/+source/python-evdev [15:14] didrocks: I think I need to add myself to that one indeed ;) [15:14] didrocks: thanks! [15:14] yw :) [15:16] rsalveti: seb128: the only downside is that android-* will be pushed 3 times this week-end until the issues are fixed, we'll need to reject it [15:16] _salem: iow your sensors are working, and they are well wired all the way up and available for powerd. seems to be that powerd isnt even starting it, so it feels like an old powerd version... yet 0.11 is the right one [15:16] <_salem> ricmm, just rebooted my device and now it works. [15:16] can you logcat and *restart* the powerd service? [15:16] ah [15:16] something was wrong with the powerd startup then [15:17] didrocks, rsalveti: I can NEW it with the understanding that the issues I pointed will be addressed next week [15:17] ricmm, i wonder if it is the same issue i see on saucy [15:17] (powerd never starts automatically from the upstart job here) === om26er_ is now known as om26er [15:18] for me it's fine, but better to wait for rsalveti :) [15:18] there seems to be a race that hits harder on saucy i guess [15:19] <_salem> ricmm, probably. it was the first run after flashing, not sure if that should matter. [15:19] seb128: fine by me [15:19] didrocks: why is it going to be uploaded 3 times? [15:19] just curious [15:20] rsalveti: because the NEW queue is not easily accessible to make a diff with [15:20] _salem: it shouldnt, but maybe something was weird [15:20] rsalveti: so hard for daily release to detect it [15:21] <_salem> ricmm, yep, well, thanks for the help, if I manage to reproduce it again I will ping you. === chihchun is now known as chihchun_afk [15:23] _salem: alright, if you do reproduce try to get a logcat of the full boot [15:24] didrocks: right === mmrazik is now known as mmrazik|afk [15:35] seb128: sil2100: stack oif plugged: utah: 18 min, otto: 1.53 min :) (with archive!) [15:35] Damn... [15:35] This makes UTAH look really bad [15:35] ;) [15:36] But it's anyway silly, it was taking so long to run 1-2 tests, all because of provisioning and such [15:36]