[02:05] <anonynimity> could someone tell me why in the first step of the porting process several necessary packages are removed from 12.04LTS x64?
[02:19] <Neverevermind> hiho
[02:20] <Neverevermind> question
[02:21] <anonynimity> what's your question?
[02:24] <Neverevermind> which smartphone should i buy to play with .......to get unbuntu on it ..... cause i want one ..... and i ruled me not to  buy one until a independent os run on one
[02:25] <anonynimity> I don't know. I'm working on a port for the SGSIII (pain in my ass)
[02:27] <nhaines> Neverevermind: the best thing to do (unless you're a developer) is to order one from ubuntu.com later this year.
[02:28] <Neverevermind> it only has to be able to make and receive calls and wlan
[02:28] <Neverevermind> yeah i read sthn about that
[02:28] <anonynimity> nhaines... could I get your help with this bro?
[02:29] <nhaines> anonynimity: I do a tiny bit of SDK advocacy but I don't know anything about the system level stuff, unfortunately.  :(
[02:29] <nhaines> I know the ubuntu-phone mailing list has some updated porting instructions.
[02:29] <anonynimity> during compilation it gave me some errors most of which i was able to figure out except for com.android.nfc_extras.xml is required by .....
[02:30] <anonynimity> and I found the .xml file, but the jar file was missing in the "firmware" folder... which I had downloaded, and set in the firmware folder... but it wouldn't take it...
[02:30] <anonynimity> :/
[02:31] <anonynimity> right now I'm following this guide: https://wiki.ubuntu.com/Touch/AndroidDevel then will go back to the porting guide tomorrow.
[02:34] <anonynimity> using the aosp and phablet mirrors. I'm determined to get the networking working, as well as the gsm, audio, camera, etc...
[02:42] <Neverevermind> @nhaines,anony ;-) no im not a developer but i like it to play with this things/progs/osses since i got my first own pc when i was a kid .... so my question is (exept buying an unbuntu - phone which i would and will do if it will/would come out;-) : ..... which smartphone with ubuntu f. ph. can make and receive calls/sms (hdy-speaker) and manage wlan with the rest i can play ;-)
[02:50] <anonynimity> check ubuntu.com/phone?
[02:50] <anonynimity> or ubuntu.com/touch
[03:23] <alfonsojon> Hi.
[03:23] <alfonsojon> Cyanogenmod just committed a "quickboot" feature, which essentially hibernates the phone when shutting down instead of doing a complete shutdown.
[03:23] <alfonsojon> Would it be possible that Ubuntu Touch would include some similar functionality?
[04:08] <lotuspsychje> can someone confirm this tutorial is good to go, to install ubuntu touch on nexus7: http://itsfoss.com/install-ubuntu-touch-nexus-7-2013/
[07:20] <dholbach> good morning
[08:11] <AskUbuntu> make bootable usb stick for ubuntu touch | http://askubuntu.com/q/444376
[08:47] <JamesTait> Good morning all; happy Monday, and happy No Housework Day! :-D
[09:23] <ogra_> Saviq, so i was doing bootcharts over the weekend, and was wondering if it would be possible that unity8 re-orders its own start phase a bit ... if you look at http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-279.png and scroll down to where the indicators start,
[09:24] <ogra_> you see that it takes 8 seconds of the boot until the panel service gives them the upstart event to start ... that really holds up the boot process, would it be possible to start it earlier ?
[09:25] <ogra_> (if i put the event into a post-start script in unity8's upstart job they start about 3 seconds after unity and i dont see any ill effects, so i assume it could be emitted earlier)
[09:28] <cwayne> lool, ping re: ubuntu-touch-customization-hooks
[09:32] <Saviq> ogra_, yeah, it could be emitted earlier indeed, right now it's the indicators QML plugin that kicks those, but that won't happen until late in unity8 startup
[09:32] <ogra_> it would be really helpful in speeding up the boot if we could start it earlier ...
[09:33] <ogra_> (and if indicator-messages could finally be ported to upstart startup ... )
[09:36] <Saviq> ogra_, I'll have a chat with dednick on what'd be required there (i.e. would we need to parse things or something), but ultimately maybe we just need to emit a custom signal (indicators-ui-starting) in unity8 post-start that the indicator jobs would start on?
[09:38] <ogra_> Saviq, right, thats what i'm doing here for the above test ... i just added an initctl emit for the event the indicators listen for to post-start script ... but i was execting that unity8 actually needs to have the service ready so that seemed suboptimal
[09:38] <ogra_> *expecting
[09:39] <Saviq> ogra_, nope, they can be started early
[09:39] <ogra_> cool
[09:40] <Saviq> ogra_, so just MP a new event from unity8 pre-start, even
[09:40] <ogra_> that and fixing the messaging indicator might bring us towards a 25sec boot :)
[09:40] <ogra_> will do
[09:40] <sil2100> dbarth: hello!
[09:40] <sil2100> dbarth: are you around?
[09:40] <Saviq> ogra_, huh, apparently there's actually a custom event already
[09:41] <ogra_> Saviq, right
[09:41] <ogra_> and unity seems to emit it from its code too ... just a little late
[09:41] <dbarth> sil2100: yes
[09:42] <dbarth> whatś up?
[09:42] <sil2100> dbarth: ah, just PMed you ;)
[09:43] <Saviq> ogra_, indicator-services-start and indicator-services-end
[09:43] <ogra_> Saviq, right
[09:44] <Saviq> ogra_, we should probably yank most of that code out of unity8, too http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/plugins/Unity/Indicators/indicatorsmanager.cpp#L220
[09:46] <ogra_> Saviq, yeah
[09:47] <Saviq> ogra_, think you could do that as part of the same MP?
[09:48] <ogra_> the whole "IndicatorsManager::setLoaded" function ?
[09:49] <ogra_> or the whole file ?
[09:49]  * ogra_ has not much clue about that code 
[10:05] <sil2100> oSoMoN: hi!
[10:05] <oSoMoN> sil2100, hey
[10:05] <sil2100> oSoMoN: silo for your webbrowser landing assigned o/
[10:05] <oSoMoN> sil2100, awesome, thanks!
[10:15] <davmor2> Morning all
[10:41] <axoin> regarding the converged desktop experience: is there any way to install plain ubuntu and then add ubuntu-touch related packages afterwards? Any other hints to bring ubuntu-touch to x86 (http://askubuntu.com/questions/444376/make-bootable-usb-stick-for-ubuntu-touch ? ) Thanks!
[11:27] <asac> sergiusens: hello
[11:27] <asac> sergiusens: do you know the status of python3 in AP?
[11:27] <asac> sergiusens: didrocks believed it landed but was disabled
[11:27] <asac> but i had to fix a python3 issue ... so seems it got enabled?
[11:27] <asac> is that through phablet-test-run?
[11:28] <sergiusens> asac: yes; it's through phablet-test-run; it pics it depending on the packaging
[11:28] <sergiusens> the clicks need to change for py3
[11:28]  * sergiusens will brb
[11:29] <asac> sergiusens: so i see it tries to be smart, falling back to py2?
[11:29] <asac> if imports blow up
[11:29] <asac> i think we should somehow figure how to keep those highlighted that are still py2
[11:29] <tteke> hello
[11:30] <popey> sergiusens: can you please look at https://code.launchpad.net/~dpm/ubuntu-filemanager-app/include-plugin/+merge/213368 - dpm has a q for you..
[11:31] <janimo> ogra_, is lxc-console or similar available to run inside the android container?
[11:32] <tteke> I have a nexus 4 and when I try to flash it with ubuntu-device-flash --channel=stable --bootstrap I get error autodeploy.zip not found error in cwm recovery
[11:32] <ogra_> janimo, sur
[11:32] <ogra_> e
[11:32] <ogra_> lxc-console -nandroid -t0
[11:33] <ogra_> needs an explicit "enter" once you are in the console
[11:33] <janimo> ogra_, ah, the explicit enter tripped me up, thanks :)
[11:33] <ogra_> yeah, i think lxc-console should just send a newline here
[11:34] <ogra_> but didnt strike me as important enough to file a bug for it yet :)
[11:34] <janimo> Well I have been trying this feature for a while, and typing ctrl-a and other combinations it prints as a greeting
[11:34] <ogra_> yeah
[11:34] <janimo> so maybe just saying 'press return' is good enough without actually sending it
[11:34] <janimo> ogra_, actually no, the -t0 matters too
[11:35] <janimo> by default tt1 does not work
[11:35] <ogra_> yup
[11:35] <janimo> so the default setting for lxc=cosnole is not optimal I'd say
[11:35] <ogra_> well, for our container
[11:35] <janimo> yes
[11:35] <ogra_> open a bug and discuss it with stgraber :)
[11:36] <janimo> ogra_, against the lxc package
[11:36] <janimo> ?
[11:36] <ogra_> dunno, i think so
[11:36] <ogra_> dpkg -S $(which lxc-console)
[11:36] <ogra_> :)
[11:37] <janimo> ogra_, sure I just wsnt' sure whether there's some lxc-touch-android package ship[ping config options for lxc :)
[11:37] <sil2100> bfiller: hi!
[11:37] <sil2100> bfiller: are you already around?
[11:37] <ogra_> janimo, nope, there isnt
[11:37] <janimo> I think changing the default is not a good idea if it affects all other lxc uses
[11:37] <AskUbuntu> Publish a QML/C++ application as a click package | http://askubuntu.com/q/444446
[11:39] <janimo> ogra_, filed https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1303756
[11:40] <ogra_> confirmed
[11:40] <janimo> ogra_, thanks
[11:46] <cwayne_> mardy, https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/app-access2/+merge/211711 doesn't have the account-plugin click hooks -- is that expected?
[11:53] <mardy> cwayne_: uh... let me double check, looks like a directory is missing from that branch...
[11:54] <mardy> cwayne_: I can blame the CI train, anyway :-)
[11:55] <cwayne_> mardy, :) i blame the CI train for everything, it's awesome
[12:02] <mardy> cwayne_: ah, lol, the click-hooks dir is already in trunk
[12:03] <cwayne_> yeah, the dir is, but the hooks themselves are missing right?
[12:03] <mardy> cwayne_: the files are there, but the directory is not listed in the qmake file, so they won't be installed
[12:04] <cwayne_> ah
[12:04] <mardy> cwayne_: the story was that CI merged this branch, then reverted it (but apparently not completely)
[12:04] <mardy> cwayne_: and this app-access2 branch is the second attempt
[12:05] <cwayne_> ah, right
[12:12] <dbarth> ogra_. popey: about https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1303676
[12:13] <dbarth> i can reproduce, and suspect this could be the app lifecycle stopping instances because of memory pressure
[12:13] <dbarth> thre is an open bug to handle memory pressure callbacks, which the container does not handle yet
[12:13] <ogra_> dbarth, well, it should only SIGSTOP them, not kill
[12:13] <sergiusens> asac: what's the problem, that change landed 2~ weeks ago?
[12:14] <dbarth> ogra_: unless the signal is not handled, and so the app stops, right?
[12:14] <ogra_> dbarth, to me it looks more like the apps all end up under the same appid or some such
[12:14] <ogra_> oh, indeed the app needs to know to stop on SIGSTOP and to start again on SIGCONT
[12:14] <asac> sergiusens: the problem was that everyone believed that autopilot didnt swithc to python3 yet
[12:15] <asac> they thought it was landed disabled
[12:15] <dbarth> ogra_: so that could be it
[12:15] <asac> so the issue that was not caught by the import fallback mechanism
[12:15] <ogra_> great :)
[12:15] <asac> came unexpected and also folks didnt know they should start using autopilot3 now
[12:15] <asac> for pre-landing testing
[12:15] <dbarth> right, apps are killed onc i have ~4 of them, whichever i start first
[12:15] <asac> (which i dont agree with to be clear - they should use phablet-test-run)
[12:16] <asac> sergiusens: so for me the biggest thing left is that its not making clear where we still run python2
[12:16] <asac> e.g. too much magic
[12:16] <asac> without warning/error/feedback
[12:16] <asac> maybe adding a big WARNING that counts as an error unless you pass --allow-py2
[12:17] <asac> would be the solution
[12:17] <popey> dbarth: I don't think that's it. I still see lots of webapp-container processes, and oxider-renderers but the apps all disappeared (bar one) from unity
[12:17] <ogra_> dbarth, the thing that made me think about the app id was that the last remaining app gets constantly replaced once you start new ones
[12:17] <sergiusens> asac: oh, warnings could be fine
[12:17] <sergiusens> and easy to add
[12:17] <ogra_> but that might be just a coincidence
[12:18] <popey> sergiusens: did you see my comment earlier about https://code.launchpad.net/~dpm/ubuntu-filemanager-app/include-plugin/+merge/213368 ?
[12:18] <sergiusens> ogra_: btw, the ofono/rild job seems racy, it wasn't that start stanza; it sometimes comes up, sometimes doesn't
[12:18] <ogra_> sergiusens, btw, mind to review my phablet-bootchart MP (before asac pokes me about bootcharts again :P )
[12:18] <sergiusens> popey: no, not really, sorry
[12:18] <asac> sergiusens: really think we should be failing unless you epxlicitely set it to ignore, so that folks using phablet-test-run get reminded that they are not done yet.
[12:18] <popey> np
[12:18] <asac> and in infra continue running with ignore flag with big warnings
[12:18] <sergiusens> ogra_: saw it yesterday, looked fine. But didn't test it out yet
[12:18] <asac> or something
[12:18] <sergiusens> will do
[12:18] <asac> ok have to cook lunch
[12:18] <asac> bbiab
[12:18] <ogra_> sergiusens, thanks ... i'll take a look at the ofono thing ... probably we need to start later
[12:20] <ogra_> whee !
[12:20] <ogra_> http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-280.png
[12:20] <ogra_> 27seconds :)
[12:30] <cwayne_> ogra_, nice!
[12:30] <ogra_> cwayne_, i want to reach 20 :) (and the screen is up around 18 already in that bootchart btw)
[12:31] <cwayne_> ogra_, that's awesome
[12:31] <ogra_> yup
[12:32] <cwayne_> poor mterry and MacSlow did all that work for the boot animation, and you'll never even be able to see it if we boot too fast :)
[12:33] <ogra_> well, the last time i tried the animation silo it added another 5 sec to the boot
[12:33] <ogra_> :P
[12:33] <ogra_> that should be enough to see some animation :)
[12:33] <cwayne_> lol
[12:41] <MacSlow> cwayne_, :)
[12:41] <MacSlow> cwayne_, well see it this way... if anything messes up our boot-time... we're at least ready with nice bling ;)
[12:42] <cwayne_> haha yep! im excited to see it land in the image MacSlow
[12:42] <MacSlow> cwayne_, going to push a few more tweaks later today.
[12:45] <ogra_> MacSlow, the problem is that the boot *before* u-s-c starts is way longer than the few seconds it takes from u-s-c to the shell
[12:45]  * ogra_ would love if we could start u-s-c earlier
[12:46] <MacSlow> ogra_, I see... are the finer details for the boot-process documented somewhere?
[12:46] <ogra_> not finer than in the bootchart above i fear ... point is that we need the android container up for the graphics driver
[12:47] <ogra_> which takes about 10-12 seconds alone
[12:47] <ogra_> (if you look at the chart you see a second init being started by lxc-start, thats the container startup)
[12:50] <MacSlow> ogra_, there's nothing coming that'll give us full native (non-android) startup, right? We need that because of all the hardware-drivers?!
[12:51] <ogra_> yeah
[12:51] <ogra_> specifically for the graphics driver
[12:52] <MacSlow> ogra_, it's not just the graphics-driver I assume... but also other SoC-parts too... DSPs, WiFi-chips etc
[12:53] <ogra_> wifi is handled on the ubuntu side, but yeah. the rest
[12:53] <ogra_> what i'm currently working on is to get the container start earlier and faster ... so we can cut down that time
[12:53] <ogra_> but there is only so much i can do :)
[12:54] <ogra_> with luck i can get it to 8 seconds or so
[12:57] <MacSlow> ogra_, I understand... good luck hunting for those fractions of seconds! :)
[12:58] <ogra_> :)
[13:00] <sergiusens> popey: what was your comment? Don't see it in the MR
[13:02] <popey> sergiusens: not mine, dpm's
[13:03] <dpm> sergiusens, I'm here now if you prefer to chat directly instead of via comments (re: the filemanager MP)
[13:03] <sergiusens> popey: yeah, he answered my question, so I think it's fine; not entirely fine, but fine; my original question implied that if they knew what they were doing and wasn't an accident it was ok
[13:04] <sergiusens> dpm: want me to do a full review?
[13:04] <popey> dpm: is https://code.launchpad.net/~dpm/ubuntu-terminal-app/enable-translations/+merge/187986 still needed?
[13:05] <dpm> sergiusens, that'd be great
[13:06] <sergiusens> ok, will add to my TODO
[13:06] <popey> mhall119: is https://code.launchpad.net/~vthompson/ubuntu-terminal-app/fix-1284602/+merge/208949 good to go?
[13:07] <dpm> popey, yes, it just never got reviewed or merged. I guess it'd need to be slightly changed now, as it's an old branch
[13:07] <popey> right
[13:07] <dpm> awesome, thanks sergiusens, that'll allow us to land file manager to the store, as the version there now is a few months old
[13:08] <popey> dpm: if you get a chance can you confirm bug 1303763
[13:08] <dpm> popey, looks like a duplicate of elopio's bug last week
[13:09] <popey> maybe
[13:10] <popey> dpm: but mine was built on jenkins, not click-buddy - so *should* work
[13:10] <popey> (lol)
[13:10] <dpm> famous last words? :)
[13:10] <dpm> popey, what does jenkins use to build the click package?
[13:11] <popey> as far as I know, magic.
[13:12] <popey> dpm: cmake - http://s-jenkins:8080/job/reminders-app-click/6/console - build looks sane to my eye
[13:12] <dpm> fginther, could you join us today as well at the core apps call?
[13:13] <dpm> popey, I don't seem to be able to see that URL
[13:13] <popey> are you on the vpn?
[13:13] <popey> if not, thats why
[13:13] <dpm> ok, yeah, I try to stay away from setting up VPNs :)
[13:13] <dpm> in any case, de-duplicated, it seems to be another bug
[13:14] <ogra_> Spironal
[13:14] <ogra_> oops
[13:14] <fginther> dpm, I have a meeting conflict, I could 5-10 minutes early
[13:15] <dpm> fginther, np, shall we jump on the hangout then, say 15 minutes before time?
[13:16] <dpm> popey, balloons, would that work for you too? I.e. start the core apps review 15 mins earlier just for today?
[13:16] <popey> dpm: sure
[13:16] <popey> balloons is on vacation dpm
[13:16] <dpm> ah, I thought he'd be back today
[13:17] <popey> done
[13:17] <popey> oh, maybe, i thought he was out till wednesday at least
[13:17] <popey> yes, his calendar confirms this
[13:20] <fginther> dpm, yes, works for me
[13:20] <dpm> perfect, thanks
[13:21] <dpm> popey, you're probably right, I've not checked the calendar, I just thought he'd be back Monday
[13:32] <ogra_> rsalveti, sergiusens, i just noticed we still ship /var/lib/lxc/android/pre-start.d/15-no-uchroot ... i assume we can drop that nowadays ?
[13:37] <rsalveti> ogra_: I think so
[13:37] <ogra_> great
[13:37] <rsalveti> the original file is not even there
[13:37] <rsalveti> that is really old stuff
[13:38] <ogra_> right
[13:38] <ogra_> and wastes a sed call on startup
[13:40] <ogra_> rsalveti, when did you last look at logcat output of one of our images ?
[13:40] <ogra_> W/Adreno-ES20( 2074): <core_glReadPixels:212>: GL_INVALID_OPERATION
[13:40] <ogra_> W/Adreno-EGLSUB( 2074): <CacheInvalidateHandle:243>: PMEM_INV_CACHES undefined
[13:40] <ogra_> i cant remember seeing that last time i looked ... but thats admittedly weeks ago
[13:41] <ogra_> now it seems to be a frequent error
[13:41] <ogra_> (like every few seconds)
[13:41] <rsalveti> hm, not sure if that normal
[13:41] <rsalveti> let me flash latest
[13:41] <rsalveti> flo?
[13:42] <ogra_> mako
[13:43] <ogra_> flo has it too though
[13:43] <ogra_> just checked
[13:45] <ogra_> rsalveti, seems to happen every time i switch apps or slide back to the applications scope
[13:45] <rsalveti> right
[13:45] <ogra_> smells like something caused by the new app switcher
[13:46] <rsalveti> just flashing an older image to check
[13:46] <ogra_> 250 should be fine
[13:46] <ogra_> was the last promoted one
[13:46] <rsalveti> as I remember we had such warnings before, but not sure if that frequently
[13:46] <ogra_> without the new switcher iirc
[13:47] <ogra_> not sure i have ever seen "INVALID_OPERATION"
[13:47] <ogra_> i know we had stuff there before ...
[13:47] <ogra_> but iirc only on load of the driver
[13:47] <stgraber> janimo: the reason why lxc-console won't attach to tty0 but always to tty1 or higher is that attaching to tty0 only works for backgrounded containers
[13:47] <stgraber> janimo: containers which aren't backgrounded have tty0 attached to the original lxc-start process and so can't be opened by lxc-console
[13:48] <oSoMoN> didrocks, hey, I have packages in silo 4 that build-depend on the latest oxide-qt that is currently in trusty-proposed, is there a way to have the PPA depend on proposed to build the packages?
[13:48] <ogra_> stgraber, well, probably having a config file for lxc-console would help :)
[13:48] <stgraber> ogra_: not sure if you saw in scrollback/e-mails but it looks like I've got cgmanager working reliably on touch now. I'll give you a debdiff for the lxc-android-config change in a bit.
[13:49] <ogra_> stgraber, yeah, i saw that !
[13:49] <ogra_> thanks a lot !
[13:49] <ogra_> lxc-android-config is currently blocked in a silo so we cant "just upload" atm
[13:51] <stgraber> ogra_: so in theory if lxc-console could query LXC to know whether a given container was started on the background or not, then it could default to tty0 when it's backgrounded. However there's no way to query that at the moment and I believe adding that feature would require an API break of the internal communication protocol, so probably not something we can do until the next major upstream release (as we try not to break our API or commun
[13:52] <ogra_> you cut off after "API or commun"
[13:52] <stgraber> ogra_: I don't think lxc-android-config is terribly urgent, but we probably want to make sure this gets done this week, quite likely before final freeze
[13:52] <ogra_> yeah
[13:52] <stgraber> "or communication protocol within the same SOVER)"
[13:52] <ogra_> stgraber, well, i personally know about -t0 and my fingermemory uses it ... i dont think it is urgent :)
[13:53] <ogra_> janimo might disagree though
[13:53] <ogra_> for me its in the "nice to have" category
[14:03] <didrocks> oSoMoN: it does depend on proposed normally
[14:03] <didrocks> oSoMoN: let me recheck
[14:03] <oSoMoN> didrocks, ok, so it might be that the oxide build wasn’t completed in proposed when I triggered the build in the PPA
[14:03] <annerajb> hello all
[14:04] <oSoMoN> didrocks, so the next question would be: if I hit the build button again on the silo page, will the packages be rebuilt in the PPA?
[14:04] <didrocks> oSoMoN: yep, checked again, it does dep on proposed
[14:05] <annerajb> rsalveti, do commands like breafkast not work on the new aosp branch?? you gave me to checkout last friday??
[14:05] <didrocks> oSoMoN: better to not rebuild a source package for nothing, if it does say it build-deps, there is a cron every 30 minutes on launchpad PPA retrying a build
[14:05] <rsalveti> annerajb: you need to use lunch and then make
[14:05] <annerajb> but the device i am porting too is not listed there
[14:06] <annerajb> rsalveti, I am porting (or trying) the lG G2 which should be d802 but is not listed since it has no notion of it existing.
[14:06] <oSoMoN> didrocks, it’s been more than 30min since oxide-qt hit proposed (lp says 4hours), and no rebuilt has happened
[14:06] <didrocks> oSoMoN: more than 30 minutes that it's published in proposed?
[14:07] <didrocks> oSoMoN: so built + published?
[14:07] <oSoMoN> didrocks, yes, I think so
[14:08] <didrocks> oSoMoN: it's because you not build-dep
[14:08] <didrocks> oSoMoN: did you forgot to bump the build-dep on latest oxide-qt?
[14:08] <didrocks> you just FTBFS
[14:08] <rsalveti> annerajb: you need to add the target to lunch
[14:09] <oSoMoN> didrocks, ok, got it, there’s no explicit version number requested in the build dep, there’s only a builddep on liboxideqt-qmlplugin
[14:09] <didrocks> oSoMoN: yeah, it should have been with the explicit version number
[14:09] <oSoMoN> didrocks, I’ve hit build again, it should fix the ftbfs
[14:09] <didrocks> oSoMoN: can you fix the version number in next build?
[14:10] <didrocks> oSoMoN: you surely want to provide "webbrowser-app" in rebuild only package list
[14:10] <didrocks> to not rebuild the qml component
[14:10] <oSoMoN> didrocks, it doesn’t make sense for webbrowser-app to depend on an explicit version number, as oxide is a moving target, it would only be a maintenance burden
[14:10] <oSoMoN> didrocks, I did
[14:10] <annerajb> rsalveti, any hints on the syntax i searched on google and tried doing which lunch to find the source of lunch but I had no luck
[14:10] <annerajb> also tried lunch -? --help -h
[14:10] <rsalveti> annerajb: check build/envsetup.sh
[14:11] <rsalveti> annerajb: you have all the used functions in there
[14:11] <didrocks> oSoMoN: well, don't expect magic happening then from LP, you need to rebuild everytime :)
[14:11] <rsalveti> you can also source it with bash -x, and see the output when calling lunch
[14:11] <oSoMoN> didrocks, that’s alright, thanks for explaining :)
[14:12] <didrocks> oSoMoN: yw ;)
[14:12] <oSoMoN> didrocks, I like magic though, when it makes my life easier ;)
[14:13] <didrocks> oSoMoN: well, there is no magic info though to know you need latest oxide-qt ;)
[14:13] <oSoMoN> yeah, I was just kidding :)
[14:16] <annerajb> rsalveti, found out how you have to add it to vendersetup.sh the add_lunch_combo and when you run build/envsetup.sh it updates the menu
[14:16] <rsalveti> annerajb: right
[14:16] <annerajb> rsalveti, should this be documented on the porting guide?
[14:16] <rsalveti> but I guess you might need a few additional files and defined variables in your device specific repository
[14:16] <rsalveti> annerajb: yes, if you have the time, please do so
[14:19] <rsalveti> ogra_: E/MP-Decision(  879): Error 13 setting online status to 0 for cpu2
[14:19] <rsalveti> E/MP-Decision(  879): Error(-19) changing core 2 status to offline
[14:19] <rsalveti> guess this is expected?
[14:19] <rsalveti> logcat is now basically useless
[14:19] <rsalveti> the entire ringbuffer is full of those messages
[14:19] <ogra_> i was wondering if it makes sense to put mpdecisionn into late start
[14:19] <ogra_> only for the first 60 sec
[14:20] <rsalveti> not sure if that will help, let me check that
[14:21] <ogra_> rsalveti, rsalveti echo manual >/etc/init/no-cpu-hotplug.override
[14:21] <ogra_> and reboot
[14:21] <pmcgowan> popey, did you file a bug on some webapps not starting properly
[14:22] <popey> pmcgowan: can you be more specific?
[14:22] <pmcgowan> popey, I run facebook and get a whitescreen
[14:22] <popey> pmcgowan: wikipedia is the only one (in the store, not ours) that didnt start
[14:22] <popey> wfm
[14:23] <ogra_> facebook is out, use G+
[14:23] <popey> http://popey.com/~alan/phablet/device-2014-04-07-152300.png
[14:23] <pmcgowan> hmm
[14:23] <pmcgowan> will reboot and try again
[14:23] <sergiusens> pmcgowan: facebook works fine for me too
[14:23] <sergiusens> ogra_: you can only share to facebook from the gallery ;-)
[14:23] <pmcgowan> thanks
[14:24]  * ogra_ wonders if any of our app developers care about migrating app data etc ...
[14:24] <sergiusens> so facebook wins now
[14:24] <ogra_> pfft
[14:24] <mhall119> oSoMoN: ping
[14:24] <sergiusens> ogra_: as a user I was bothered to need to relog in given that I don't remember all my passwords :-)
[14:25] <oSoMoN> mhall119, pong
[14:25] <ogra_> see that as an opportunity to memorize them better ;)
[14:25] <rsalveti> ogra_: yeah, it's fine after you override that job
[14:25] <ogra_> rsalveti, sure
[14:25] <rsalveti> let me see if late start helps, but I don't think it'll help much
[14:25] <ogra_> i just wonder how we could make mpdecision be quiet about it
[14:25] <mhall119> oSoMoN: does UbuntuWebView support the UrlSchemeDelegate overrides that WebKit has in experimental?
[14:26] <ogra_> yeah, it will cut a few messages
[14:26] <ogra_> but surely not all
[14:26] <ogra_> as the ro/rw switch for the sysfs node only happens after 60sec
[14:28] <oSoMoN> mhall119, no
[14:29] <rsalveti> ogra_: why 60sec?
[14:29] <ogra_> rsalveti, to have all cores up during the whole boot
[14:30] <ogra_> 45 would suffice for us i guess ... but i want it to be fast on slower devices too
[14:37] <oSoMoN> ogra_, hey, seen my last comment on bug #1303676 ?
[14:38] <ogra_> oSoMoN, nope ... will check and comment ...
[14:38] <oSoMoN> ogra_, thanks
[14:40] <ogra_> oSoMoN,
[14:40] <ogra_> ogra@styx:~/Devel/apps$ adb shell ps ax |grep -c webapp-container
[14:40] <ogra_> 9
[14:40] <ogra_> ogra
[14:40] <ogra_> thats with only one app visible in the scope
[14:40] <ogra_> so yes, i can confirm
[14:40] <rsalveti> ogra_: changing to late_start doesn't help much
[14:41] <oSoMoN> ogra_, so it seems like a bug in unity8, right?
[14:41] <ogra_> oSoMoN, also a good bunch of "[oxide-renderer] <defunct>"
[14:41] <rsalveti> and mpdecision is a binary blob afaik
[14:41] <rsalveti> so not much we can do
[14:41] <rsalveti> just annoying that while you fixed the kernel to have a useful dmesg, now logcat is useless lol
[14:41] <ogra_> rsalveti, hmm, then we have to live with it i fear ... i wont give up the 4seconds that cgains us
[14:42] <ogra_> well, you can disable the upstart job ...
[14:42] <ogra_> its just useless if you didnt do that
[14:42] <rsalveti> right, but I mean for debugging
[14:42] <rsalveti> without making it rw
[14:43] <ogra_> could we redirect mpdecision at startup ... to /dev/null ?
[14:44] <rsalveti> ogra_: nops, because this is part of the androd log system
[14:44] <rsalveti> not stdout
[14:44] <ogra_> (i dont want to add more sed commands to pre-start.d though)
[14:44] <rsalveti> but guess not much we can do, unfortunately
[14:44] <rsalveti> if we want to have a super fast boot :-)
[14:44] <ogra_> yeah
[14:44] <ogra_> this was one of the more noticeable speedups
[14:44] <stgraber> ogra_: so where's the latest lxc-android-config? you mentioned it being in a silo somewhere. I'd like to base my debdiff on that so it's easier to apply once the current one has landed.
[14:45] <ogra_> i'm curious what the next one will give ... once we rebuild android my new handling of the container unpacking will land
[14:45] <ogra_> stgraber, silo 19
[14:45] <ogra_> stgraber, but i want to have at least a few people test it ... i'm a bit scared about breaking the lab for days again
[14:46] <ogra_> and testing that change is time consuming ...
[14:53] <rsalveti> ogra_: the invalid was also happening with 250
[14:53] <ogra_> ok
[14:53] <rsalveti> ogra_: every time you bring the launcher
[14:54] <rsalveti> so not a regression, but maybe something to investigate at some point
[14:54] <ogra_> well, the launcher shouldnt use inavlid functions ...
[14:54] <ogra_> but yeah, not urgent then
[14:54] <rsalveti> I think this is a side effect of the UI effect you have when you bring the launcher
[14:54] <rsalveti> probably something in qt/mir
[14:59] <janimo> stgraber, I do not know much about lxc internal, I was just assuming there may be some config option to set that would only be valid on touch
[15:00] <janimo> or have an android-console shell wrapper shipped on touch :)
[15:08] <stgraber> ogra_: I'll build that debdiff I attached to the bug and start a loop on up to date mako, hopefully that'll give you the assurance you need that things work fine :)
[15:09] <ogra_> stgraber, i would like to have someone test it thats not you or me ... like davmor2 or popey
[15:10] <davmor2> don't look at me I hate you both remember ;)  is this the no boot fix if so popey might be your better bet I need my phone for testing on
[15:11] <stgraber> yeah, that's the "sometimes every 80 boots or so, the device may hang" bug
[15:11] <popey> happy to sacrifice a device if it's easy for me to setup (i.e. a deb or something) rather than me manually patching stuff
[15:11] <ogra_> right easy to let the test script run over night
[15:12] <popey> but can't do that until ~19:00 UTC
[15:12] <ogra_> popey, yeah, like last time, let it run over night
[15:12] <ogra_> same script/test ... let it loop-reboot ... sleep 30sec etc etc
[15:12] <stgraber> popey: yeah, the test script is pretty simple and I'll have a new lxc-android-config for you that you can manually install to test.
[15:13] <popey> ok, stgraber can you fire simple instructions at me when its ready - I'm guessing wipe clean install, install a deb, run the script, right?
[15:13] <stgraber> popey: sounds about right, yeah
[15:13] <ogra_> popey, only copy the upstart job iover the old one
[15:13] <ogra_> not even install a deb :)
[15:14] <ogra_> trying to install lxc-android-config is pointless anyway
[15:19] <ogra_> stgraber, so awe_ is looking for a way to run an upstart job exactly once on first boot, does the boot-hooks mechanism off sich features ?
[15:19] <ogra_> *such
[15:20] <ogra_> (i see "initctl emit boot-hooks WHEN=every-boot" in /etc/init/boot-hooks-emit.conf ... would are there other options for "WHEN" ?)
[15:21] <awe_> ogra_, no that's not quite right
[15:21] <ogra_> awe_, once on upgrades ?
[15:21] <awe_> I'm looking for a way to do a one time deletion of ofono gprs files *without* creating a unique upstart job to do this
[15:22] <awe_> what would be nice, is if we had a some generic mechanism in our updates that could handle this case
[15:24] <stgraber> so you could use book-hooks WHEN=new-version and then have your job write a stampfile, check it in pre-start so you can do the removal just one time and reduce the number of times that job will be attempted to a minimal
[15:24] <ogra_> awe_, right, i think the boot-hooks mechanism offers something like that
[15:24] <stgraber> but there's no way to do that without upstart jobs because the boot-hooks are upstart jobs (located in /etc/init/boot-hooks/)
[15:24] <ogra_> awe_, but you wont get around shipping *something* that does it
[15:24] <ogra_> be it an upstart job, or a wrapper script for ofonod or whatever
[15:25] <awe_> so we have no hooks on our server-side?
[15:25] <ogra_> how would it help to have it server side ?
[15:25] <ogra_> you want to change variable data of an installed system no ?
[15:26] <ogra_> so you have to run something on the system
[15:29] <ogra_> awe_, so i thinnk the trick for you is to ship that upstart job ... leave it in some versions and have it only run on upgrade löike stgraber described above and then rip it out in some subsequent upload of your package (once you are sure people are converted)
[15:30] <ogra_> either ship it in ofono ... or i'm happy to drag it into lxc-android-config
[15:31] <awe_> rsalveti, ^^
[15:32] <ogra_> "book-hooks WHEN=new-version" means  that it will at least only run on upgrades and not on every boot
[15:36] <rsalveti> ogra_: would that logic work when upgrading images?
[15:36] <rsalveti> if so, then it should be fine for us
[15:36] <ogra_> rsalveti, right, it should only fire the job after an upgrade
[15:36] <rsalveti> then fine, better at least
[15:37] <ogra_> not exactly a one time thing indeed
[15:41] <ogra_> stgraber, i think i want to delete ureadaheads pack files on upgrades ... i assume that needs to happen in the system-image-upgrader script, right ?
[15:42] <stgraber> ogra_: probably, I guess boot hooks run a bit too late to do that using WHEN=new-image
[15:43] <mhall119> bzoltan: I can't assign it to you, but could we get https://bugs.launchpad.net/qtcreator-plugin-ubuntu/+bug/1303535 done sooner rather than later?
[15:43] <ogra_> stgraber, yeah, that would waste one boot as ureadahead would only profile on the next one
[15:43] <bzoltan> mhall119:  will be fixed today
[15:44] <mhall119> thanks
[15:44] <mhall119> bzoltan: I just realized it's pointing to local API docs though....which might be better
[15:44] <mhall119> I thought it was still pointint to old online docs
[15:44] <mhall119> but the header and footer are outdated and point ot pages on developer.ubuntu.com that don't exist anymore
[15:45] <didrocks> beuno: is click store dead?
[15:46] <didrocks> beuno: nothing appears anymore in the available click scopes
[15:46] <didrocks> ok, it's back
[15:47] <didrocks> mhr3: we don't get any feedback when the click store can't be reached
[15:47] <didrocks> like you click on a clic app and get the preview view which is empty
[15:48] <mhall119> didrocks: sounds like the click scope died
[15:48] <mhall119> didrocks: are you on wifi or cellular data?
[15:48] <mhr3> didrocks, yea... design was trying to design what happens when you don't have internet the week they left
[15:49] <mhall119> bfiller: is there a plan to get video recording working again on mako?
[15:50] <didrocks> mhr3: ok, so it's known and tracked?
[15:50] <didrocks> mhall119: wifi, but the store itself died for a while
[15:50] <didrocks> mhall119: we were 3 at multiple parts of the planet seeing it :p
[15:51] <mhr3> didrocks, i suppose somewhere on bottom of mikenagle's list :)
[15:51] <bfiller> mhall119: phonedations team working on that, not sure when it will be done
[15:52] <sil2100> dbarth: when was #1271436 fixed you say?
[15:52] <didrocks> mhr3: nice :p
[15:53] <dbarth> alex_abreu: ^^ apperently that was in january
[15:53] <dbarth> so that's a recent regression
[15:53] <alex_abreu> dbarth, so the issue reappeared?
[15:54] <dbarth> alex_abreu: apparently so
[15:54] <mhall119> Chipaca: when will push notifications be open for 3rd party testing?
[15:54] <alex_abreu> dbarth, ok I'll have a look
[15:55] <dbarth> can't see it on #280 though
[15:55] <mhall119> oSoMoN: re-ping from Friday, is moving UbuntuWebView to Ubuntu.Browser something we can do before ubuntu-sdk-14.04 is frozen?
[15:58] <oSoMoN> mhall119, we just discussed it in a call with bfiller, dbarth, jdstrand and alex_abreu, and while we agree on the rationale of doing the move, we think the timing is pretty bad
[15:58] <davmor2> mhall119: trojita needs to handle signed mails better
[15:59] <mhall119> davmor2: it needs a lot of things, you can help
[15:59] <mhall119> oSoMoN: agreed on the timing, I wish I knew there was an issue months ago
[15:59] <bfiller> mhall119: we can't get that done in time, too many changes have to happen
[15:59] <davmor2> mhall119: I can file lots of bugs and test stuff I'm not really one for coding
[16:00] <oSoMoN> mhall119, sorry I gotta rush out now, let’s continue the discussion by e-mail/through the bug report if you don’t mind
[16:00] <Chipaca> mhall119: I don't know, yet
[16:00] <mhall119> ok, so then can we support it in Ubuntu.Components.Extras.Browser and get the API docs online?
[16:00] <Chipaca> mhall119: why?
[16:00] <mhall119> Chipaca: I have a candidate app (community-cast)
[16:00] <Chipaca> mhall119: post-14.04 in any case :)
[16:01] <mhall119> Chipaca: ok
[16:01] <ogra_> davmor2, is there a click for it already ?
[16:01] <ogra_> (trojita i mean)
[16:02] <mhall119> ogra_: not in the store, but you can use http://people.ubuntu.com/~mhall119/trojita/com.ubuntu.developer.mhall119.trojita-ubuntu_0.2_armhf.click
[16:02] <ogra_> perfect
[16:02] <ogra_> lol
[16:03] <ogra_> funny that firefox offers me the software-center to open a click package
[16:03] <davmor2> mhall119: you need to update you instructions for install, you need to do sudo -u phablet -i or it will only appear for root ;)
[16:03] <mhall119> ogra_: it thinks it's a .deb
[16:03] <mhall119> for good reason
[16:03] <ogra_> aww
[16:03] <ogra_> then i wont test it
[16:03] <mhall119> davmor2: good point
[16:03] <ogra_> my production phone is readonly and stays that way
[16:03] <mhall119> ogra_: all click packages are nearly-debs
[16:03] <mhall119> ogra_: but it's a proper click
[16:04] <davmor2> mhall119:  at least when installing from adb anyway :)
[16:04] <ogra_> oh, you mean i can click install it ?
[16:04] <mhall119> ogra_: yes
[16:04] <ogra_> thats all i need ...
[16:04] <ogra_> i just dont want to install debs on that phone
[16:04] <ogra_> (or make it writable)
[16:05] <mhall119> ogra_: just pkcon install-local as phablet
[16:05] <ogra_> yeah
[16:06] <mhall119> ogra_: it'll be called Trojitá in the Installed section
[16:06] <ogra_> yep
[16:06] <mhall119> didrocks: no promotion today?
[16:06] <didrocks> mhall119: none :(
[16:23] <beuno> didrocks, what was the symptom
[16:23] <beuno> ?
[16:23] <didrocks> beuno: so, if you booted before the outage, you click on an available app
[16:23] <didrocks> you end up in an empty preview view
[16:24] <didrocks> of course, if you reboot, no available apps at all are shown
[16:24] <didrocks> mhr3: maybe one way for a quick fix first will be to collapse and hide the available apps when you can't reach the click scope?
[16:24] <beuno> didrocks, ah, I see there was a code rollout
[16:24] <didrocks> (like you ping regularly?)
[16:25] <beuno> didrocks, which atm has a small period of unavailability
[16:25] <didrocks> beuno: ok, I think that the client code should be smarter anyway about it
[16:25] <beuno> didrocks, +1
[16:25] <mhr3> didrocks, that's for design to decide
[16:25] <didrocks> mhr3: I hope we do have a clear ETA of course!
[16:28] <beuno> mhr3, also, s/decide/input?   :)
[16:30] <mhr3> beuno, shhh, some of them read this channel ;)
[16:40] <dbarth> sil2100: about that toolbar issue, i can't reproduce it on #280, am i missing something?
[16:40] <dbarth> i tried on a couple of webapps from a recent restart though
[16:43] <sil2100> dbarth: you would have to ask the bug reporter
[17:12] <davmor2> mhall119: lets see trojita should I be able to send a message/read a message/access attachments?
[17:13] <mhall119> davmor2: not in the Ubuntu UI yet
[17:14] <davmor2> mhall119: right so currently it's an app that tells me how full my inbox is then not a bad start though to be fair,  one annoying things is the scrolling... I'd much rather scroll be slowed and read the text
[17:15] <davmor2> mhall119: I'm assuming though that search will possibly take care of that :)
[17:15] <mhall119> davmor2: yeah, I think that's a pre-mature optimization
[17:35] <ogra_> mhall119, hmm, trojita doesnt show my mails in the Inbox ... only subfolders
[17:38] <mhall119> ogra_: yeah, I noticed that, it's either/or, it doesn't mix messages and subfolders, file a bug please
[17:39] <ogra_> well, i'd be happy only seeing messages and no subfolders :)
[17:39] <ogra_> mhall119, where ?
[17:39] <mhall119> V
[17:39] <mhall119> https://bugs.kde.org/buglist.cgi?product=trojita&component=Ubuntu&resolution=---&list_id=997226
[17:39] <ogra_> thx
[17:40] <mhall119> \np
[17:46] <ogra_> mhall119, kde bug 333166
[17:47] <ogra_> bah, i typoed :P
[17:49] <mhall119> thanks ogra_
[17:54] <mhall119> cjwatson: are click package versions compatible with debian package version numbering?
[17:54] <mhall119> like, can I have version 4.0-ubuntu1 ?>
[17:55] <mhall119> or 4.0~git123456
[17:58] <beuno> mhr3, yes
[17:58] <beuno> er
[17:58] <beuno> mhall119, yes
[17:58] <mhall119> beuno: perfect, thanks
[17:58] <beuno> they use the same code to compare versions
[18:07] <jdstrand> jhodapp, rsalveti, mdeslaur: hey-- over the weekend I played with the media-hub (as you know). I confined the music-app and removed its access to ~/Music, but gave ti access to @{HOME}/.cache/media-art/ and @{HOME}/.cache/mediascanner/
[18:08] <jdstrand> jhodapp, rsalveti, mhall119: the music-app used the media-hub without needing the direct access to the files, which is great
[18:08] <jhodapp> jdstrand, that's awesome!
[18:09] <jhodapp> jdstrand, how about letting media-hub have network streaming access from say an http server?
[18:09] <jdstrand> jhodapp, rsalveti, mdeslaur: however, it occured to me that the mediascanner and media-art access is an information leak currently. ie, if I add that access to a 'common' policy group like audio or video, then any app would be able to enumerate all the music, videos, etc on the device
[18:09] <jdstrand> jhodapp: I gave media-hub that already based on previous conversations (I don't think I mentioned that in the email)
[18:10] <jhodapp> jdstrand, ok, I'll have to give that a good testing then once we all align
[18:10] <mdeslaur> so, we were supposed to get rid of ~/Music and have music be owned by the music app
[18:10] <jdstrand> jhodapp, rsalveti: mdeslaur asked a question about the app only being able to play its own music
[18:11] <mdeslaur> how does the musicscanner restrict media scanning to an application's directory currently?
[18:11] <mdeslaur> s/musicscanner/mediascanner/
[18:11] <jdstrand> I think we could maybe achieve that by making mediascanner a trusted helper
[18:11] <jdstrand> mdeslaur: I *think* it just looks in ~/Music only right now
[18:12] <jdstrand> well, and ~/Videos I guess
[18:12] <mdeslaur> We probably need to start by having a discussion whether music and videos are global locations, or if apps should own their own files
[18:13] <jhodapp> indeed, and are there ever any exceptions?
[18:14] <jdstrand> right now we handle exceptions by have the music_files_read and video_files_read reserved policy groups
[18:15] <jdstrand> 'reserved' means that app uploads are stopped on manual review in the store
[18:15] <mdeslaur> if we do decide that music and videos should be a global location, then yeah, it would make sense for mediascanner/media-hub to be a trusted helper
[18:15] <jdstrand> I think I can add the necessary access to the audio and video policy groups (common, ie non-blocking) for access to the media-hub itself, but that the mediascanner accesses would not be common yet
[18:16] <jhodapp> jdstrand, so an app can be classified as being in one of those groups?
[18:16] <mdeslaur> jdstrand: I think it needs to be a trusted helper before you make them non-blocking
[18:16] <jdstrand> jhodapp: the way it works is that the click manifest specifies a security manifest, the security manifest says what policy template to use along with any policy groups needed by the app. eg, audio, video, networking, location, etc
[18:17] <jdstrand> jhodapp: there are common policy groups that any app may use, and reserved ones that apps typically cannot use
[18:18] <jhodapp> jdstrand, that's interesting...so the app store is the point at which that gets reviewed then
[18:18] <jdstrand> mdeslaur: so I get that with the mediascanner, but why for the media-hub?
[18:18] <jhodapp> jdstrand, err, submission to the app store
[18:18] <mdeslaur> jdstrand: something needs to prevent apps from playing songs blindly outside of their own directories, no?
[18:19] <jdstrand> jhodapp: the sdk is clear about which policy groups people can and can't use, and the review tools on clicks can be run prior to upload. but yes, upon upload we will run the checks. anything that uses a reserved policy group is blocked
[18:20] <jhodapp> jdstrand, thanks for the explanation
[18:20] <jdstrand> mdeslaur: it is true that an app could blindly guess what is installed on the device, yes
[18:21] <mdeslaur> right, so they need to be trusted helpers, and possibly both use the same permission
[18:21] <jdstrand> I was trying to decide if that is a problem. I suppose it is
[18:21] <mdeslaur> ie: you get prompted for "Access your media library"
[18:21] <mdeslaur> the other thing, is that is only for the common ~/Music directory, but you don't want an app to attempt to play a sound from the facebook app folder to see if facebook is installed, for example
[18:22] <jdstrand> we wouldn't want to prompt though for accesses within the app-specific directory
[18:22] <mdeslaur> so the media-hub needs to perform access control
[18:22] <jdstrand> mdeslaur: re facebook> yes
[18:22] <jdstrand> (that is what made me suppose it was a problem, but also what prompted this discussion)
[18:22] <mdeslaur> so the media-hub would allow playing sounds from the apps own directory, would prevent the app from playing sounds from other app directories, and would prompt to play from ~/Music
[18:23] <jdstrand> that wouldn't be too terribly difficult though
[18:23] <mdeslaur> I suppose the mediascanner would only do ~/Music
[18:23] <jdstrand> it does the libapparmor api call to get the label (APP_ID), parses that and sees if the file is in ~/.local/share/$pkgname
[18:24] <mdeslaur> ep
[18:24] <mdeslaur> yep
[18:24] <jdstrand> if it is, lets it play, if it isn't, see if it is in the global directory (eg, ~/Music), if it is, prompt, if it isn't reject
[18:24] <jdstrand> maybe the last one could be refined for sharing...
[18:25] <jdstrand> sharing should be via content-hub
[18:26] <mdeslaur> jdstrand: yep
[18:27] <jdstrand> it will be an interesting user experience though to access the mediascanner and then the hub
[18:27] <mdeslaur> that's why they should probably both use the same trusted-helper database
[18:27] <jdstrand> cause those are different processes. I suppose there is nothing saying that they couldn't share the same trust store
[18:27] <jdstrand> hehe
[18:27] <jdstrand> yeah
[18:27] <mdeslaur> yeah :)
[18:27] <mdeslaur> lol
[18:27] <jdstrand> haha
[18:27] <mdeslaur> STOP COPYING ME OR I'LL TELL MOM
[18:27] <jdstrand> mdeslaur: see, I like talking to you
[18:28] <jdstrand> :)
[18:28] <mdeslaur> hehe
[18:29] <mdeslaur> jdstrand: so sounds like we have a plan?
[18:30] <jdstrand> I think so, yes. I'll file a bug against mediascanner2 and add media-hub to it when it is in the archive
[18:31] <mdeslaur> jdstrand: cool, thanks
[18:32] <rsalveti> jdstrand: jhodapp: mdeslaur: I'd guess we want the media files to be globally available
[18:32] <rsalveti> in case we have more than one player
[18:32] <rsalveti> at least that was a quite common use case for me when using android
[18:32] <rsalveti> n900 and others
[18:33] <jhodapp> rsalveti, same for me on the iPhone
[18:33] <rsalveti> globally for the same user I mean :-)
[18:33] <rsalveti> right
[18:50] <popey> stgraber: do you have a package or something for me to test on my phone?
[18:52] <stgraber> popey: https://dl.stgraber.org/lxc-android-config_0.161_all.deb
[18:52] <stgraber> popey: you'll need to "umount /lib/udev/rules.d/70-android.rules", then remount / rw, install that package, then remove cgroup-lite and after that do the reboot loop
[18:53] <popey> stgraber: from a very clean wiped recent image?
[18:53] <stgraber> yeah, latest -proposed, factory reset isn't really needed but you might as well
[18:54] <popey> kk
[18:54] <stgraber> the reboot loop is something like: http://paste.ubuntu.com/7218298/
[18:54] <stgraber> popey: oh, you'll also need "rm /etc/init/cgproxy.override /etc/init/cgmanager.override"
[18:55] <stgraber> because they are conffiles so won't automagically disappear when you dpkg -i the package
[19:00] <pmcgowan> ogra_, what time do the automatic builds run?
[19:01] <popey> stgraber: not sure I got this right.. http://pad.ubuntu.com/RebootTesting
[19:03] <stgraber> popey: you don't need to remount the file, it's only used at boot time so the reboot will take care of it
[19:03] <popey> ok
[19:04] <jdstrand> mdeslaur, rsalveti: can you review bug #1303962?
[19:04] <mdeslaur> sure, /me looks
[19:04] <jdstrand> I haven't added the task for media-hub yet since it hasn't landed
[19:06] <mdeslaur> jdstrand: you have "prompt user for access to global music files" in the video section
[19:08] <jdstrand> fixed
[19:08] <mdeslaur> cool
[19:09] <jdstrand> tyhicks: since this is happening over dbus, is there a better method than aa_getcon() in bug #1303962?
[19:09] <mdeslaur> I added a little note that we probably don't want personal videos taken with the camera to be stored in the common ~/Videos folder
[19:11] <ogra_> pmcgowan, 2am UTC
[19:11] <pmcgowan> ogra_, only one per day then?
[19:11] <ogra_> yes
[19:11] <pmcgowan> aw rats
[19:11] <ogra_> a test run takes 5h ... and the tests start delayed
[19:11] <ogra_> all in all the time from starting a build to test results is 8h
[19:11] <pmcgowan> wow need to fix that, wheres that emulator
[19:12] <ogra_> pmcgowan, well, we could easily fix that by just buying 20 makos with broken screens off ebay
[19:12] <ogra_> or 40
[19:13] <pmcgowan> ogra_, I am still surprised we dont do a second build
[19:13] <tyhicks> jdstrand: I'm a little bit confused by the psuedocode
[19:13] <ogra_> its a joke that we only fiddle with a handfull of devices ... even with the emulator around you will need full image tests
[19:13] <tyhicks> jdstrand: aa_getcon() gets the current process' label, but you're really wanting the label of the process connecting to media-hub/mediascanner, correct?
[19:13] <ogra_> *on* the devices
[19:13] <pmcgowan> true
[19:13] <rsalveti> pmcgowan: working on it still, but people keep breaking it over the time
[19:13] <rsalveti> :-)
[19:13] <ogra_> pmcgowan, we usually do
[19:13] <pmcgowan> ogra_, just manual start you mean
[19:13] <pmcgowan> ok
[19:13] <ogra_> pmcgowan, one automated one, one during the EU workday normally
[19:14] <ElectroPug> hello there, somebodey willing to help me? I have a question concerning the porting guide :)
[19:14] <rww> johnjohn101: tl;dr: if you have a sysvinit script and there isn't a systemd unit file that replaces it installed, it'll happily work with the sysvinit script
[19:14] <ogra_> so we can adjust the build time for the landings and make sure everything we want in one test run is actually landed
[19:14] <pmcgowan> yep makes sense
[19:15] <jdstrand> tyhicks: yes-- I didn't read the man page close enough. I was thinking I could give the pid to aa_getcon, but I cannot
[19:15] <tyhicks> jdstrand: ok, then the answer is 'yes', there's a better way to do it all within dbus
[19:15] <ogra_> sergiusens, so for the ofono race i think just changing the upstart job to "start on android" should be enough for now ... we can do fancy fine grained stuff later
[19:15] <tyhicks> jdstrand: the bus method org.freedesktop.DBus.GetConnectionAppArmorSecurityContext() can be used
[19:15] <ogra_> seems there is an issue with the property watcher sometimes
[19:16] <tyhicks> jdstrand: I've documented that method in the aa_getcon() man page
[19:17] <jdstrand> tyhicks: ok, updated the pseudocode
[19:17] <tyhicks> jdstrand: looks good to me!
[19:18] <jdstrand> tyhicks: thanks! I should have tapped 'PgDn' once :P
[19:18] <sergiusens> ogra_: if that works, do you mind pushing it in?
[19:18] <tyhicks> jdstrand: :)
[19:18] <ogra_> sergiusens, well, do you have a test setup ?
[19:18] <ogra_> to do a quick test (since you reproduced the race)
[19:19] <sergiusens> ogra_: just loop reboot and ofono should be online (list-modems) (and ofono started)
[19:20] <ogra_> sergiusens, that means i need to fiddle with setting up a phone with the ppa etc
[19:20] <ogra_> i thought you have one around already
[19:21] <jdstrand> jhodapp, rsalveti: you said that music-app didn't have to be updated to use media-hub, that it all happened way down underneath
[19:21] <jhodapp> jdstrand, only partially true
[19:21] <jhodapp> jdstrand, it must be modified to use the new BackgroundPlaylist object to continue playing music when the app loses focus or the screen turns off
[19:21] <rsalveti> right, for the proper implementation I believe we're still missing playlist
[19:22] <jdstrand> jhodapp, rsalveti: how many other apps use the same api as the music-app? I was thinking the trust store integration doesn't affect the silo, but now I'm less sure
[19:22] <rsalveti> jhattara: is the BackgroundPlaylist implementation done already?
[19:22] <popey> stgraber: uh, after doing those steps and rebooting for the first time it's stuck at the google logo!
[19:23] <jdstrand> which the actual code for media-hub would be like 50 lines or something, but the problem is, we need the mir support to land
[19:23] <jhodapp> rsalveti, I assume you meant me :) It is, but there are limitations with a client dying and then reconnecting
[19:23] <rsalveti> jdstrand: right now I believe only music-app and mediaplayer-app
[19:23] <rsalveti> jhodapp: yeah, sorry
[19:23] <jhodapp> only music-app
[19:23] <jhodapp> mediaplayer-app won't change
[19:23] <jdstrand> ok, and mediaplayer-app is shipped as a deb and unconfined
[19:23] <jhodapp> yep
[19:24] <rsalveti> jhodapp: but did you test if it works if the app gets a sigstop at least?
[19:24] <rsalveti> but dying would also be a valid use case, as the user can just kill the app
[19:24] <pmcgowan> jhodapp, rsalveti do we know it has to change? isnt music-app already using a std API for playlists?
[19:24] <jhodapp> rsalveti, ricmm has, I haven't personally gotten a chance to try it yet
[19:24] <ahayzen> jhodapp, i guess we only need to make it add the current play queue to the media-hub?
[19:24]  * ahayzen has come in half way through the conversation
[19:25] <jhodapp> ahayzen, yeah, you would construct your playlist as a BackgroundPlaylist and pass it to the MediaPlayer instance
[19:25] <rsalveti> where is ricmm now :-)
[19:25] <jhodapp> furniture shopping :)
[19:25] <jdstrand> jhodapp, rsalveti: what is not clear (as mentioned in bug #1303962) is if apps are supposed to use a dbus api for the mediascanner files are access the db directly. it seems like music-app is doing the latter based on the apparmor policy I had to add
[19:25] <rsalveti> pmcgowan: I believe we'd need to change it to use the background playlist api
[19:25] <pmcgowan> jhodapp, how is this being exposed through qt
[19:25] <ahayzen> jhodapp, awesome, at the moment we have a ListModel with the queue would that be easy to pass to the MediaPlayer?
[19:25] <pmcgowan> rsalveti, we dont want apps calling papi
[19:25] <jhodapp> pmcgowan, as a new QML type (plugin)
[19:26] <jdstrand> s/are access/or access/
[19:26] <pmcgowan> cool, right answer!
[19:26] <rsalveti> right, not done by papi directly
[19:26] <jhodapp> ahayzen, no, you'd use this as your List instead (or parallel)
[19:26] <pmcgowan> jhodapp, is it based of the existing Qmobility api?
[19:26] <pmcgowan> jhodapp, who did the QML api design?
[19:26] <jhodapp> pmcgowan, no because it didn't have this support at the QML level
[19:26] <jhodapp> pmcgowan, ricmm
[19:27] <pmcgowan> sounds good
[19:27] <jhodapp> pmcgowan, we are ahead of upstream on this
[19:27] <pmcgowan> fair enough, we can give it to them
[19:27]  * davmor2 wonders when we get a mami to go with the papi 
[19:27] <jhodapp> pmcgowan, and they'd be interested in using our solution possibly
[19:27] <ahayzen> jhodapp, cool :) i can't remember, does it handle shuffle/repeat for us as well?
[19:27] <jhodapp> ahayzen, yes it will
[19:28] <ahayzen> jhodapp, \o/ awesome, when will it ready for us to move?
[19:28] <jhodapp> ahayzen, trying to finish up one last thing here and media-hub will land...we can then start to engage the music-app team
[19:29] <ahayzen> jhodapp, great work, let me know when it has landed and either me or Victor will move the music-app over :)
[19:29] <jhodapp> ahayzen, sounds good
[19:30] <popey> pmcgowan: who owns music scope ?
[19:30] <rsalveti> jhodapp: remember we also need to do the powerd integration before pushing the background api implementation forward as well
[19:30] <rsalveti> otherwise the device will suspend :-)
[19:30] <jhodapp> rsalveti, right
[19:31] <pmcgowan> popey, strehl owns all scopes, not sure who works on music
[19:31] <popey> ok, ta
[19:31] <pmcgowan> popey, well, all but click I guess
[19:31] <pmcgowan> or no, all of em now
[19:32] <ChickenCutlass_> rsalveti, jhodapp just need to move the call to powerd dbus api from app to hub
[19:32] <jhodapp> yeah
[19:32] <rsalveti> right, but I'm surprised that the app is allowed to call that dbus api
[19:32] <rsalveti> in theory the app shouldn't be allowed to do that
[19:33] <rsalveti> would need to check
[19:33] <ChickenCutlass_> rsalveti, yeah -- was always temp
[19:33] <rsalveti> for media-hub is fine because it's a service
[19:33] <ChickenCutlass_> right
[19:33] <rsalveti> right, but we never had the right permission for the phablet user to call the powerd dbus api
[19:33] <rsalveti> that's the interesting piece
[19:34] <rsalveti> I know we also added the app itself as part of our app lifecycle
[19:34] <ChickenCutlass_> rsalveti, we whitelisted it
[19:34] <rsalveti> but that wouldn't block the device to suspend
[19:34] <rsalveti> let me give it a try and see what is really happening regarding powerd
[19:35] <mterry> doanac, so were you OK with lp:~mterry/unity8/unlock-script ?
[19:36] <doanac> mterry: i think so. i haven't had time to re-work our daily image testing in a way that we can use it yet
[19:36] <mterry> doanac, that's OK.  We can land the script and it won't hurt anything.  (It doesn't remove the existing support that jenkins is using)
[19:36] <doanac> exactly
[19:37] <mterry> doanac, can you approve the branch then?  I'd like to land this in the next unity8 drop
[19:37] <doanac> mterry: done
[19:38] <mterry> doanac, thanks!
[19:41] <stgraber> popey: hmm, weird, it's been happily running here...
[19:41] <stgraber> popey: oh, I see, you missed purging cgroup-lite
[19:42] <popey> ah,
[19:42] <popey> stgraber: can i do that now and reboot?
[19:46] <stgraber> popey: if you can get into a shell using adb, then yes
[19:47] <rsalveti> ChickenCutlass: pmcgowan: jhodapp: yeah, just confirmed, music-app is not allowed to request a sysstate from powerd
[19:47] <rsalveti> so if you try to play a music and suspend the device, it'll try to suspend
[19:47] <rsalveti> nothing is blocking that
[19:47] <jhodapp> ok
[19:47] <rsalveti> as I thought initially, the app is not allowed to call that powerd interface, and never was
[19:48] <rsalveti> people were just lucky because some other process had a wakelock, which is usually what happens on mako
[19:48] <rsalveti> but if you try to play a music in background with flo, you'll see that it try to suspend
[19:49] <rsalveti> so landing media-hub should fix that (once the powerd integration is done)
[19:49] <pmcgowan> rsalveti, btw can we ever fix that wakelock thing?
[19:49] <rsalveti> pmcgowan: nops
[19:49] <pmcgowan> rsalveti, but you can fix anything ;(
[19:50] <rsalveti> we could try to spend some time to improve it a bit more, but would need kernel changes and so on
[19:50] <rsalveti> well, I could try to fix it, just don't have the time right now :-(
[19:50] <pmcgowan> rsalveti, so I take it its not just merge an upstream patch
[19:50] <rsalveti> pmcgowan: no, as that patch is already part of our current tree
[19:50] <rsalveti> would need some further investigation in there
[19:51] <rsalveti> I saw that we might have some other changes that could improve a bit
[19:51] <rsalveti> but would need to find the time to do that
[19:51] <pmcgowan> ok
[19:51] <rsalveti> mostly busy with the emulator now
[19:51] <pmcgowan> right more important
[19:51] <rsalveti> yeah
[19:51] <pmcgowan> maybe one of kernel team could look into it
[19:51] <rsalveti> yeah, that was my suggestion to ChickenCutlass
[19:51] <pmcgowan> I can ask
[19:52] <rsalveti> pmcgowan: bug 1267570
[19:52] <pmcgowan> rsalveti, I have that on speed dial :)
[19:52] <rsalveti> :-)
[19:53] <rsalveti> I can help if you're able to get someone to look into that
[19:53] <pmcgowan> ok let me ask
[19:57] <popey> stgraber: its hanging trying to remove cgroup-lite ⍨
[19:57] <popey> stgraber: shall i start again?
[20:17] <Rienzilha> lol
[20:36] <popey> stgraber: sorted, how many reboot loops do you want me to do?
[20:49] <rsalveti> ogra_: [  135.380000] init: enable-cpu-hotplugging main process (1046) terminated with status 1
[20:49] <rsalveti> ogra_: there's no online in the emulator
[20:49] <rsalveti> for cpu in /sys/devices/system/cpu/cpu?/online; do chmod 644 $cpu; done
[20:49] <rsalveti> ogra_: mind fixing that?
[20:51] <stgraber> popey: not sure how many ogra_ wants, around 200 would probably be good
[20:51] <rsalveti> pmcgowan: Saviq: it seems the app lens is always empty for me in the emulator now, can you guys reproduce the issue?
[20:51] <popey> stgraber: kk
[20:52] <stgraber> popey: my own box + nexus 4 are up to 164 now with the same setup as you so I'm pretty confident you won't get any problem :)
[20:53] <popey> stgraber: yay
[21:26] <mhall119> do we override XDG_CONFIG_HOME when running apps under confinement?
[21:32] <popey> stgraber: bad news, 36 passes and it's at the google logo
[21:32] <popey> stgraber: just noticed 30 mins have passed since last reboot
[21:34] <popey> stgraber: adb devices shows nothing
[21:42]  * popey starts the loop again
[21:59] <stgraber> popey: hmm, that's not good... here I'm up to 249 passes
[22:05] <popey> stgraber: run again and I have 13 passes
[22:05] <popey> and failed
[22:09]  * popey starts another run
[22:16] <stgraber> popey: I wonder what's different in our setups...
[22:18] <popey> well indeed
[22:18] <popey> stgraber: any confirmations of package versions or somesuch?
[22:18] <popey> (i should do?)
[22:24] <popey> stgraber: i followed the etherpad
[22:26] <stgraber> popey: I'm resetting my device again here to see if I can reproduce what you're seeing, though it's giving me a hard time when trying to install the new lxc-android-config
[22:27] <popey> stgraber: i had to adb shell, then dpkg -i it in the shell, it wont let me do it all in one line
[22:27] <popey> happy to reset and do same as you
[22:27] <stgraber> popey: just to make sure things look good, can you pastebin "dpkg -l | grep cg", "ls -l /etc/init/" and "dpkg -l lxc-android-config"
[22:27] <popey> ok
[22:28] <stgraber> popey: what I'm going to do here is wipe my device completely, reflash the latest image from trusty-proposed, then from the recovery partition, push the new deb and install it which will ensure I don't get into any trouble because the system is running.
[22:28] <popey> you can install the deb from the recovery part?
[22:29] <popey> stgraber: http://paste.ubuntu.com/7219165/
[22:34] <stgraber> popey: ok, so you have cgroup-lite that's still sort of around (its init scripts anyway), you probably should purge it, not sure whether that would cause your problem though
[22:34] <popey> hmmm odd.
[22:34] <stgraber> dpkg --purge cgroup-lite ought to do it
[22:34] <popey> ok
[22:35] <popey> bah, yes, i messed up earlier, only removed, didn't purge
[22:35] <popey> root@ubuntu-phablet:~# apt-get remove cgroup-lite
[22:35] <popey> sorry
[22:36] <popey> have purged via dpkg and will start the reboot loop again
[22:44] <stgraber> popey: that's how you install a package from recovery: http://paste.ubuntu.com/7219206/
[22:45] <stgraber> loop re-running here following those instructions, that should be as close as we can get short of spinning a new image
[22:46] <popey> stgraber: handy
[22:46] <popey> will leave this loop running overnight
[22:46] <popey> assuming it gets further
[22:47] <stgraber> let's hope it will... if it doesn't I hope mine will get stuck too, otherwise this will be a pain to figure out
[22:49] <micahf> hey, I did "apt-get install ubuntu-touch" on my tablet with 14.04 and it got me into loads of trouble!
[22:50] <micahf> specifically, the lxc-android-config package was preventing me from booting up.
[22:51] <popey> stgraber: got stuck again
[22:52] <popey> after 15 boots
[22:55] <stgraber> popey: is that mako you're testing with?
[22:55] <popey> stgraber: yes
[22:58] <stgraber> popey: so I really should be getting the same thing here... up to loop 17 here
[23:01] <popey> stgraber: want me to do a clean start to confirm I didn't balls it up?
[23:01] <popey> based on your pastebin?
[23:02] <stgraber> popey: yeah, I think that'd be interesting that way we know we have exactly the same thing
[23:02] <popey> ok, will do
[23:16] <popey> stgraber: btw thanks for the -f in reboot recovery, didn't know that the -f was needed, will update docs
[23:18] <stgraber> popey: it depends on what adb you have. In some cases you can do "adb reboot recovery" so asking adb to do the reboot for you and in some others you need to actually call the reboot command with "adb shell reboot -f recovery", the latter tends to always work so I usually stick to that
[23:18] <popey> i've never had reboot recovery work with ubuntu
[23:51] <decopump> is the Nexus 7 the best device for booting android, ubuntu touch, and firefox os?
[23:51] <popey> which nexus 7?
[23:51] <decopump> 2013 i guess?
[23:52] <popey> does ffos support the nexus 7 2013?
[23:52] <decopump> there is some support but i'm not sure of the extent
[23:52] <popey> ok
[23:53] <decopump> i'm looking for a magical device that can do all 3
[23:53] <popey> so we support ubuntu on the nexus 7 2013
[23:53] <wolflarson> hey popey
[23:53] <popey> dunno about ffos, but sure, android can ☻
[23:53] <decopump> im not really experienced with this kind of stuff either
[23:53] <popey> hello wolflarson
[23:53] <wolflarson> do you guys support nexus 5 yet? :)
[23:53] <wolflarson> i cant find the community port in english
[23:54] <popey> wolflarson: we don't, no.
[23:54] <wolflarson> aww