[01:10] <achiang> hm, what does this mean: ERROR:phablet-flash:https://system-image.ubuntu.com/daily/mako/index.json cannot be retrieved
[01:10] <achiang> 404 in the web browser
[01:10] <achiang> maybe it's being rebuilt
[01:10] <achiang> meh
[01:11] <stgraber> achiang: this means you didn't update your device in quite some time
[01:11] <stgraber> achiang: or phablet-flash
[01:11] <stgraber> in this case
[01:11] <achiang> stgraber: i just ran the exact same command ~1.5 hours ago and it succeeded
[01:12] <stgraber> achiang: not with daily as a channel name it didn't
[01:12] <stgraber> achiang: that channel has been deprecated since the 16th and was removed from the server on the 26th
[01:13] <achiang> stgraber: you are right, i typed the wrong command
[01:13] <achiang> sorry, i am dumb :)
[01:13] <achiang> stgraber: i was using bash history from the wrong gnome-terminal :-/
[01:14] <stgraber> wow, you must have a pretty long history to still have that channel name in there :)
[01:16] <achiang> pack rat ;)
[02:59] <mfisch> is anyone awake who can top approve a merge into a ubuntuone-hackers branch?
[03:00] <mfisch> achiang: you should be using devel or devel-proposed
[03:00] <achiang> mfisch: right, i used the wrong command from bash history by accident
[03:06] <pkunal-parmar> My Nexus 4 with ubuntu touch on it, won't power on, can any one help ?
[03:08] <mfisch> pkunal-parmar: this has been discussed on the mailing list some.
[03:09] <mfisch> pkunal-parmar: some tricks are use a wall charger for a few hours, or take the battery in and out
[03:09] <pkunal-parmar> ok
[03:10] <mfisch> pkunal-parmar: look at this archive too there's some mail there about it: https://lists.launchpad.net/ubuntu-phone/
[03:10] <pkunal-parmar> does it happens because of battery drain ?
[03:10] <pkunal-parmar> sure, I will have a look
[03:12] <mfisch> I don't know the reason
[03:18] <robot> hello?
[03:18] <Guest79607> is somebody online?
[03:19] <robot20> robot20
[03:19] <robot20> hello?
[03:40] <AskUbuntu> will ubuntu for phones (release in 2 weeks i think) support the "phone" funktion? | http://askubuntu.com/q/352980
[04:44] <nhaines> What's the current recommended way to set the system timezone on Ubuntu Touch?
[05:13] <kevin___> hey, whos got ubuntu running on their galaxy s4?
[06:15] <didrocks> rsalveti: FYI: go ahead on your 2 requests when you are ready
[06:46] <jibel> with MIR enabled application randomly failed to start, which information would be useful to attach to a bug report?
[06:47] <Shiggs|i5-2500k> Hello I'm trying to follow http://forum.xda-developers.com/showthread.php?t=2426924 and I'm stuck on the partitioning stage
[06:47] <Shiggs|i5-2500k> it keeps giving me a bogus error
[06:47] <Shiggs|i5-2500k> saying the /internal isn't a directory
[06:49] <Shiggs|i5-2500k> This is obvs on an HP TouchPad
[06:50] <Shiggs|i5-2500k> /media/internal is a directory, but not /internal, which is why it doesn't make any sense.
[06:51] <Shiggs|i5-2500k> Anyone?
[07:20] <__jim__> is there an expected date when ubuntu touch will be ready for cdma?
[07:23] <nhaines> __jim__: I don't think there are any plans to support it.
[07:24] <__jim__> ooooh well, I thought I'd see, thanks!
[07:33] <Shiggs|i5-2500k> http://pastebin.com/Af1uY4Hc
[08:18] <popey> Huzzah! Ringing and sms tones works in image 78
[08:21] <Lupus> Hello everyone
[08:22] <Lupus> I have a quick question about ubuntu touch...
[08:22] <Lupus> i assume this is the correct place?
[08:26] <popey> !ask | Lupus
[08:27] <Lupus> hahah, well, wondering if ubuntu touch is going to work on all android devices, or only those mentioned as supported - or if the supported ones are the only ones with rollback options if it goes wrong. I have an old samsung galaxy y i want to try it with
[08:32] <nhaines> Lupus: theoretically, it can run on any Android device with high enough specs, but in real life, it'll only work on the phones that have had it ported to them.
[08:32] <nhaines> The good news, though, is that if you have a factory Android image, you should be able to recover back to it if it doesn't work.
[08:33] <Lupus> That isnt a problem, i dont use that phone at all any more. Hm, its not a high spec phone
[08:34] <Lupus> thanks dude, ill just go try when salamander comes out soon :D
[08:34] <nhaines> October 17th.  :)
[08:35] <nhaines> JohnLea: nice job on the 13.10 wallpaper.  I like how smooth it looks.
[08:37] <JohnLea> nhaines; thanks but don't thank me, it was Michal Izydorczyk who did this one
[08:38] <nhaines> JohnLea: I'll have to drop him a note then if I can find his email.  :)
[08:39] <nhaines> And now I have.
[08:48] <JamesTait> Good morning all; happy Virus Appreciation Day! :-D
[08:57] <gema> popey: am I supposed to be able to upgrade from image 75 to 78 on devel-proposed via the UI?
[08:57] <UrbanRunnerX> can someone please help me??
[08:57] <popey> i have not personally tested that scenario
[08:58] <popey> UrbanRunnerX: if you ask your question, we can try
[08:58] <gema> popey: I know they were landing a new upgrade mechanism on 73, so the first image that we are promoting to current with that is 78
[08:58] <JamesTait> Is there a supported way to sync the calendar app with a CalDAV source?
[08:58] <gema> popey: I will go to current and try tomorrow
[08:59] <popey> JamesTait: no
[08:59] <UrbanRunnerX> just dont want to sound dumb tho, but
[08:59] <UrbanRunnerX> im still trying to just get everything loaded in my computer and getting held up with the phablet-dev-bootstrap
[08:59] <gema> UrbanRunnerX: I sound dumb every day, no worries, peole here are quite understanding :)
[09:01] <UrbanRunnerX> sticking at the public key not found
[09:01] <UrbanRunnerX> just trying to get all these tools and what not loaded first obv
[09:01] <gema> UrbanRunnerX: what are you trying to do? if you could give a bit of context on that it'd help
[09:02] <JamesTait> OK, obvious next question is obvious: is there an unsupported way?  For example, does the calendar app integrate with e-d-s, so I could use syncevolution to achieve my goal?
[09:02] <gema> UrbanRunnerX: get everything loaded for what?
[09:03] <UrbanRunnerX> just trying to follow the ubuntu porting guide and just trying to get my "development enviroment" all installed
[09:04] <gema> UrbanRunnerX: ah, ok, not mything, but I am sure someone else in the channel can help you
[09:04] <UrbanRunnerX> not trying any of the porting??
[09:05] <UrbanRunnerX> or any porting exp???
[09:05] <popey> UrbanRunnerX: can you pastebin the error you're seeing?
[09:07] <UrbanRunnerX> its a screenshot
[09:07] <UrbanRunnerX> how can i post that
[09:08] <popey> imgur
[09:09] <UrbanRunnerX> ok nvm, just copied it, sorry new to the developing world so thought id start here but hard to do so when i can't more futher
[09:09] <UrbanRunnerX> sorry its such a long one but just showing the terminal command i used and full results
[09:10] <UrbanRunnerX> http://pastebin.com/AMdeJ4YB
[09:11] <UrbanRunnerX> have to send another pastebin didn't get it al
[09:11] <UrbanRunnerX> nvm its all there
[09:11] <popey> UrbanRunnerX: http://stackoverflow.com/questions/2182938/gpg-warning-unsafe-ownership-on-configuration-file-gpg-fingerprint-on-ubun
[09:12]  * popey prematurely celebrates with tea
[09:14] <UrbanRunnerX> ill check back in a little to see if that helps thanks
[09:15] <UrbanRunnerX> just checked to see if that file/folder was even there thru search and can't find
[09:17] <loukariellow> hello everybody. I never used irc and I hope i'm doing it right. I have a question: I noticed that none of mediacom tablet are listed in "https://wiki.ubuntu.com/Touch/Devices". Has anybody ever tried to install touch on one of these devices?
[09:23] <UrbanRunnerX>  found out it has something to do with the "key" for my gnu, guess it was never imported haha
[09:32] <popey> UrbanRunnerX: huzzah
[09:32] <popey> loukariellow: if it's not on that list, probably not
[09:32] <popey> loukariellow: unless someone on xda has tried and hasn't had success or hasn't documented their success
[09:32] <popey> or other reasons I can't think of
[09:33] <loukariellow> ok thanks. I just wanted to be sure
[09:34] <UrbanRunnerX> could always attempted to build it yourself, then run into a brickwall over small stuff and i didn't even get to any of the building stages :p
[09:34] <UrbanRunnerX> im trying to get a d2spr build
[09:35] <Shiggs|i5-2500k> >_> <_<
[09:35] <UrbanRunnerX> whats that about :p
[09:37] <Shiggs|i5-2500k> me?
[09:38] <Shiggs|i5-2500k> UrbanRunnerX: maybe you can help
[09:38] <UrbanRunnerX> i would if i could im hung in trying to get the gpg key matched
[09:39] <Shiggs|i5-2500k> I have a simple problem that maybe can be fixed
[09:39] <Shiggs|i5-2500k> I was trying to follow this: http://forum.xda-developers.com/showthread.php?t=2426924 earlier, but I hit a wall when trying to run create_partitions.sh
[09:39] <Shiggs|i5-2500k> this is the error:
[09:40] <Shiggs|i5-2500k> http://pastebin.com/Af1uY4Hc
[09:48] <pete-woods> jodh: hi
[09:49] <jodh> pete-woods: hi
[09:49] <pete-woods> jodh: I've been seeing something strange with an upstart session job (hud) on my desktop machine (I think others have too)
[09:50] <pete-woods> jodh: basically, the DBus environment variables weren't being set (I dumped the environment from inside the job)
[09:50] <pete-woods> jodh: this MR fixed the problem (https://code.launchpad.net/~pete-woods/hud/fix-hud-activation/+merge/188090)
[09:52] <pete-woods> jodh: also strange was that when I looked into ~/.dbus/session/*, the environment definition in there is different to the one in my live environment (i.e. echo $DBUS_SESSION_BUS_ADDRESS)
[09:54] <popey> OMG! Headphones work now!?
[09:54]  * popey abuses the music app for a while
[09:55] <xnox> pete-woods: jodh: commented on that merge proposal RE:dbus job. https://code.launchpad.net/~pete-woods/hud/fix-hud-activation/+merge/188090
[09:59] <pete-woods> xnox: ack, the interesting part is that this also failed on a running desktop session
[10:00] <pete-woods> I'm scared that there's some kind of hard to reproduce bug in upstart that fails to pass on the DBus environment set in the dbus job
[10:01] <xnox> pete-woods: check the tests for setting environment variables in upstart, we have pleora of tests to verify correct environment for each job. I'm suspecting ordering problem: where anything dbus-activates session dbus, ahead of session-dbus reaching "started".
[10:02] <davmor2> Morning all
[10:02] <pete-woods> xnox: this was a running desktop session, the environment was set properly in the shell, it just wasn't appearing in the upstart job
[10:03] <xnox> pete-woods: what do you mean "properly set in the shell"?
[10:03] <pete-woods> xnox: if I type "echo $DBUS_SESSION_BUS_ADDRESS" it gives the right value in terminal
[10:03] <davmor2> a new day, a new image
[10:03] <mhr3_> xnox, think this bootchart shows that upstart does indeed start dbus-daemon
[10:03] <mhr3_> http://people.canonical.com/~ogra/ubuntu-touch/bootchart-mako.png
[10:04] <mhr3_> or i'm reading it wrong... one of those :)
[10:04] <xnox> pete-woods: right, so your terminal was launched after "started JOB=dbus" event was emitted, anything that is launched between "starting JOB=dbus" and "started JOB=dbus" will have DBUS_SESSION_BUS_ADDRESS set, which actually isn't spawned yet.
[10:05] <xnox> mhr3_: which of the two upstarts? =) we are talking about session-dbus, not system-dbus. Or do bootcharts cover both?
[10:05] <ogra_> xnox, yes
[10:05] <pete-woods> xnox: I am manually running "start hud" and "stop hud" to test an in-session services
[10:05] <pete-woods> *service
[10:05] <mhr3_> xnox, they do, but that's why i might be reading it wrong
[10:05] <ogra_> pete-woods, the same code is in an /etc/profile.d script we ship that gets executed on start
[10:06] <Shiggs|i5-2500k> >_> >_>
[10:06] <ogra_> pete-woods, theoretically the var should already be in your env
[10:06] <xnox> ogra_: hm, i think i'd rather want the --debug log on session upstart somewhere.
[10:06] <ogra_> root@ubuntu-phablet:/# cat /etc/profile.d/dbus-source.sh
[10:06] <ogra_> # truncate obsolete ~/.dbus-session file if it exists
[10:06] <ogra_> [ -e $HOME/.dbus-session ] && echo >$HOME/.dbus-session
[10:06] <ogra_> # source dbus address from new location
[10:06] <ogra_> [ -e $HOME/.cache/upstart/dbus-session ] && . $HOME/.cache/upstart/dbus-session
[10:06] <xnox> jodh: do we have the graphviz for session-upstart?
[10:06] <ogra_> export DBUS_SESSION_BUS_ADDRESS
[10:06] <ogra_> root@ubuntu-phablet:/#
[10:06] <ogra_> pete-woods, ^^^
[10:07] <mhr3_> xnox, what is the upstart-dbus-bridge process?
[10:07] <xnox> ogra_: ouch, you want $ initctl set-env DBUS_SESSION_BUS_ADDRESS as well!
[10:07] <ogra_> xnox, !
[10:07] <xnox> ogra_: cause otherwise anything started by upstart will not know about correct bus address.
[10:07] <xnox> ogra_: see /usr/share/upstart/session/dbus.conf for the example.
[10:08] <xnox> ogra_: or better just do $ start dbus ;-)
[10:08] <pete-woods> ogra_: that file is only there on touch, right? I was seeing this issue on the desktop
[10:08] <xnox> mhr3_: man upstart-dbus-bridge ? it's a bridge - thus it emits events, which jobs can react to from things that happen on dbus - e.g. objects apearing/going away, messages broadcasted etc.
[10:08] <ogra_> xnox, if dbus does that already, it should be all fine
[10:09] <mhr3_> xnox, ah, right... ok
[10:09] <ogra_> xnox, the profile.d file is for non graphical logins ... sudo etc
[10:09] <xnox> ogra_: yeah =/
[10:09] <Shiggs|i5-2500k> >_> >_>
[10:09] <ogra_> xnox, if dbus stratup has exported it into upstart all should be fine
[10:09] <xnox> ogra_: i'm not so sure.
[10:09] <ogra_> ?
[10:10] <ogra_> the login shell connects to the running upstart session
[10:10] <xnox> ogra_: is the user-session dbus job used at all?
[10:10] <ogra_> xnox, see http://people.canonical.com/~ogra/ubuntu-touch/bootchart-mako.png
[10:10] <xnox> ogra_: i like text not pictures =)
[10:10] <ogra_> it is used but goes into some weird zombie state after startup
[10:11]  * ogra_ doesnt have any text that would visualize this :P
[10:11] <xnox> ogra_: in essence "$ env | grep DBUS_" should match "$ initctl list-env | grep DBUS" if they don't, things will be broken.
[10:12] <xnox> ogra_: and if one is updating login ENV with new dbus, the running upstart user-session's environment should be updated to match.
[10:12] <ogra_> phablet@ubuntu-phablet:~$ env |grep DBUS
[10:12] <ogra_> DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-ecBUlQCJwE
[10:12] <ogra_> phablet@ubuntu-phablet:~$ initctl list-env |grep DBUS
[10:12] <ogra_> DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-ecBUlQCJwE
[10:13] <ogra_> same on terminal
[10:13] <ogra_> the sudo side will stop working if you restart  the graphical session  without sudo re-login though
[10:14] <xnox> right, so that's all good.
[10:14] <ogra_> but thats a limitation of the design ... sadly
[10:14] <xnox> can you restart graphical session?
[10:14] <ogra_> xnox, well, look at the chart, nothng is good
[10:15] <xnox> hm.
[10:15] <ogra_> dbus-daemo goes into zombie state right after start (assumingly waiting for the hud to show up)
[10:15] <ogra_> and after about 30secs the session startup moves on (indicators start etc)
[10:16] <ogra_> we need to get rid of that hang on startup, but i have no idea where it comes from
[10:16] <pete-woods> ogra_: can you try (to humour me) this change? (https://code.launchpad.net/~pete-woods/hud/fix-hud-activation/+merge/188090)
[10:17] <pete-woods> probably it's as easy as anything to just manually apply it to the device
[10:17] <ogra_> yeah, just need to make it writable ... one sec
[10:20] <ogra_> pete-woods, hmm, isnt that code the wrong way round ?
[10:20] <ogra_> i would assume you want to source the file before exporting the var you read from it
[10:21] <pete-woods> ogra_: that fix worked for me on the desktop, feel free to try it the other way around, though
[10:22] <jodh> pete-woods: that won't work due to what ogra just said, but also because you set the var in the pre-start, but it won't apply to the exec
[10:22] <jodh> pete-woods: you'd need to 'initctl set-env' the variable in pre-start for it to apply in exec, or change exec to a script, source and then exec hud-service.
[10:22] <ogra_> yeah, nothing changes, boot still takes as long (i dont have bootchart on this install, but there is no 20sec speedup for sure)
[10:23] <ogra_> jodh, well, the point is that dbus already does that on startup
[10:23] <ogra_> jodh, theoretically the var should be available to the job
[10:23] <ogra_> via the upstart env
[10:24] <jodh> ogra_: still reading the scroll back, but that fix is entirely incorrect
[10:24] <ogra_> right
[10:24] <pete-woods> jodh, ogra_: my testing for that was commenting out the pre-start script, hud doesn't start, uncommenting, hud starts
[10:26] <pete-woods> never mind though, I'm just glad ogra_'s bootchart shows the problem
[10:26] <davmor2> ogra_: phablet-flash failed it seems to of wiped my phone but not put anything on.  Is there some magic incantation to make it run from the fastboot page?
[10:26] <ogra_> pete-woods, http://paste.ubuntu.com/6187560/ something like that would probably work
[10:27] <davmor2> ogra_: http://paste.ubuntu.com/6187575/
[10:27] <pete-woods> ogra_: did that help with your boot?
[10:28] <pete-woods> (i.e. your fixed version)
[10:28] <ogra_> pete-woods, nope ... and i dont see anything related to hud in the processlist
[10:28] <ogra_> but the above would be syntactically correct (though you have that var in your env already)
[10:31] <mhr3_> ogra_, does the bootchart change in any way if you remove the dbus service file for hud?
[10:32] <mhr3_> then dbus should just throw an error immediately and not wait for anything
[10:36] <ogra_> mhr3_, i dont have bootchart installed anymore ... got to re-setup that stuff again (i do daily image testing too)
[10:37] <ogra_> davmor2, looks like your cable or so
[10:37] <ogra_> davmor2, boot into recovery and start over with -d maguro added
[10:37] <davmor2> thanks
[10:39] <davmor2> ogra_: thanks that looks to be working now
[10:49] <ogra_> mhr3_, no change http://people.canonical.com/~ogra/ubuntu-touch/bootchart-mako-dr20131003-2.png
[10:50] <mhr3_> ogra_, and you removed /usr/share/dbus-1/services/com.canonical.hud.service right?
[10:50] <ogra_> mhr3_, nope
[10:51] <mhr3_> ogra_, what was the change then?
[10:51] <ogra_> mhr3_, adding pete-woods' change
[10:51] <ogra_> to export the dbus session address
[10:51] <mhr3_> ah, ok
[10:51] <mhr3_> so do we have a proper fix yet?
[10:52] <ogra_> no
[10:52]  * ogra_ switches the upstart job to "start on started dbus" and removes the service file 
[10:52] <ogra_> lets see
[10:52] <ogra_> !
[10:53] <mhr3_> that's not really a fix
[10:53] <pete-woods> ogra_: should you make unity8 wait on hud, then?
[10:53] <ogra_> 5sec after the google logo went away i have a shell on screen !!!
[10:53] <pete-woods> wow
[10:53] <ogra_> pete-woods, i thought it does that internally already
[10:54] <pete-woods> ogra: I thought it needs dbus service activation for that, but whatever, there is clearly something wrong with HUD
[10:54] <pete-woods> or hud activation at least
[10:55] <mhr3_> jodh, so any idea why the env var wouldn't be set in the hud job even though the dbus job has set-env --global in its pre-start script?
[10:56] <ogra_> http://people.canonical.com/~ogra/ubuntu-touch/bootchart-mako-dr20131003-3.png
[10:57] <ogra_> onder 1min now
[10:57] <ogra_> *under
[10:57] <ogra_> oh, the total is moot ...
[10:57] <ogra_> but you can see everything just starts a lot earlier
[10:58] <ogra_> ah, well, but no hud
[10:59] <mhr3_> why does ubuntu-download start dbus-daemon?
[11:00] <mhr3_> ubuntu-download-manager
[11:00] <ogra_> dunno
[11:00] <ogra_> but you will notice that the zombie state of the session dbus is gone
[11:00] <ogra_> so my theory is ...
[11:00] <mhr3_> oh wait, that's dbus-daemon running dbus-daemon
[11:01] <ogra_> unity8 tries to fire up the hud service via dbus
[11:01] <ogra_> but hud takes to long to respond
[11:01] <ogra_> which then turns dbus into a pumpkin
[11:01] <ogra_> which in turn makes unity8 simply wait for a timeout (seemingly taking about 20sec)
[11:02] <mhr3_> well hud can't connect to dbus, that's why there's all the waiting
[11:02] <mhr3_> and that's because of the envvar not set
[11:02] <mhr3_> and what pete-woods was asking about
[11:03] <ogra_> the envvar is set
[11:03] <ogra_> in the whole of the session upstart
[11:04] <ogra_> it is exported into the upstart env by dbus when starting
[11:04] <mhr3_> not inside hud-service
[11:04] <pete-woods> ogra_: the reason I think the var isn't set is from basically replacing the hud binary with a bash script that does "env | sort > /tmp/hud/env"
[11:04] <ogra_> inside the upstart session
[11:04] <ogra_> as long as hud service stays in that env all is fine
[11:05] <mhr3_> that's what you would think since upstart itself starts hud, but clearly it's not happening
[11:06] <ogra_> but your current setup runs through dbus services, fires up a scrip in a subshell and that tries to exec the hud service
[11:07] <pete-woods> ogra_: it still results in a "hud start", though, right?
[11:07] <pete-woods> start hud, even
[11:07] <ogra_> pete-woods, yes, but does dbus have access to the session upstart from where you call it ?
[11:08] <ogra_> pete-woods, looking at the script i suspect the var isnt set ...
[11:08] <mhr3_> ogra_, since the script checks for UPSTART_SESSION envvar, yes it does
[11:09] <ogra_> mhr3_, it checks for it and takes a fallback path if it cant use it
[11:09] <didrocks> ogra_: go away! it's off today
[11:09] <ogra_> mhr3_, how do you know it isnt always taking the fallback path ?
[11:09] <didrocks> mhr3_: stop annoying ogra_ ;)
[11:09] <ogra_> didrocks, well, my session boots in google logo +5sec :)
[11:10] <ogra_> instead of google logo + 1min :)
[11:10] <didrocks> ogra_: waow? what's the magic?
[11:10] <didrocks> no no, you won't trap me
[11:10] <mhr3_> ogra_, cause your bootcharts show that upstart launches hud in the end
[11:10] <ogra_> didrocks, disabling the hud :P
[11:10] <didrocks> enjoy your holiday!
[11:10] <didrocks> :)
[11:10] <didrocks> ogra_: really???
[11:10] <ogra_> its not a solution yet
[11:10] <ogra_> but a finally clear identification of the boot delay
[11:11] <ogra_> didrocks, compare http://people.canonical.com/~ogra/ubuntu-touch/bootchart-mako-dr20131003-2.png with http://people.canonical.com/~ogra/ubuntu-touch/bootchart-mako-dr20131003-3.png
[11:13] <ogra_> mhr3_, not in http://people.canonical.com/~ogra/ubuntu-touch/bootchart-mako-dr20131003-3.png
[11:13] <didrocks> ogra_: indeed, impressive
[11:14] <ogra_> mhr3_, where i changed the upstart job to actually start and removed the .service file
[11:14] <ogra_> (seemingly starting the upstart job doesnt start the hud at all though)
[11:14]  * mhr3_ wants ctrl+f to work in bootcharts
[11:15] <mhr3_> ogra_, yea... i see no hud there
[11:15] <ogra_> right
[11:15] <mhr3_> so not sure what point you're trying to make
[11:16] <mhr3_> the only i see that the job wasn't started by anyone
[11:20] <xnox> mhr3_: correct, so hud is dbus activated, by whatever first tries talking to it. and it's dbus-daemon that is launching it....... nothing to do with upstart as upstart doesn't control at all then when to start hud.
[11:20] <pete-woods> but unity8 should be trying to start it
[11:21] <xnox> pete-woods: well then, you should troubleshoot why unity8 is not starting to talk to hud as soon as.
[11:21] <mhr3_> xnox, that's because ogra_ removed the service file, which was calling "start hud"
[11:21] <xnox> sorry, i mean we should be troubleshooting why unity8 doesn't talk to hud.
[11:22] <xnox> mhr3_: hm.
[11:22] <xnox> now i'm confused =)
[11:22] <mhr3_> hud is dbus-activated, and the dbus-daemon activated job calls upstart's "start hud"
[11:23] <mhr3_> however crazy that is... it should work
[11:23] <xnox> sure, but that's like eons too late.
[11:23] <mhr3_> why would it be late? dbus will wait for it
[11:24] <xnox> hud's start on condition should be to started as soon as possible instead.
[11:24]  * ogra_ suspects you need something like a pkla file for policykit 
[11:24] <mhr3_> xnox, why? lazy start ftw
[11:24] <xnox> mhr3_: lazy start wastes time, we are event based and want to boot as soon as possible.
[11:25] <xnox> mhr3_: you can then stop hud, and do lazy resume to save resources.
[11:25] <pete-woods> xnox, mhr3_: whether it's a waste of time or not, it should still work
[11:26] <ogra_> pete-woods, it works, but adds 30sec boot time ... we will switch to Mir the next days, that adds another 20sec to the boot ...
[11:26] <xnox> ogra_: unless the dbus's environment is poluted, in which case "start hud" doesn't something entirely else.
[11:26] <xnox> ogra_: can you change $ start hug in the .service file, to "$ start --no-wait hud" ?
[11:27] <ogra_> pete-woods, this then causes the boot take long enough to only show the UI after powerd already blanked the screen, users think it didnt boot at all and crashed
[11:27] <pete-woods> ogra_: so you're saying that HUD simply takes something like 30 seconds to start?
[11:27] <ogra_> pete-woods, did you see the different bootcharts i posted over the last 30min ?
[11:27] <xnox> .... pete-woods and any "tasks jobs that start on starting hud"
[11:28] <ogra_> pete-woods, hud delays unity startup by 30sec
[11:28] <mhr3_> ogra_, it'd be same if hud was able to actually talk to dbus
[11:28] <ogra_> pete-woods, dropping the hud gets me the UI nearly immediately after the google logo goes away
[11:28] <ogra_> mhr3_, thats not acceptable, why is it taking so long ?
[11:29] <mhr3_> cause it can't connect
[11:29] <mhr3_> and unity8 being stupid and doing blocking wait for it
[11:29] <mhr3_> or libhud... whatever
[11:29] <ogra_> http://paste.ubuntu.com/6187749/
[11:29] <ogra_> see the first two lines
[11:30] <mhr3_> oh wow
[11:30] <ogra_> you call into the system bus i bet
[11:30] <ogra_> not into the session one
[11:30] <pete-woods> hmm, okay, I'm surprised that unity didn't wait like 30 seconds for the HUD timeout
[11:30] <ogra_> the system bus runs under the system upstart sessiion
[11:31] <ogra_> pete-woods, thats what it does !
[11:31] <ogra_> pete-woods, causing a 30sec bootup delay
[11:31] <pete-woods> I thought you said you were getting unity to appear really soon when you diabled HUD?
[11:31] <ogra_> yes
[11:32] <ogra_> well, i didnt disable it ... i added "start on started dbus" to its session upstart job
[11:32] <mhr3_> ogra_, that's session dbus log, right?
[11:32] <ogra_> but it doesnt start ... unity8 doesnt wait either though
[11:32] <ogra_> mhr3_, right
[11:33] <mhr3_> eeh, let's just remove the hud upstart job and leave it on dbus activation
[11:34] <mhr3_> clearly the interaction breaks something
[11:34] <mhr3_> and being to do "stop hud" is not good enough reason to keep it
[11:34] <xnox> ogra_: "start: Unknown job: hud" huh, it looks like dbus-daemon is talking to the wrong upstart.
[11:34] <xnox> ogra_: when doing dbus-activate -> start hud
[11:34] <ogra_> xnox, yeah
[11:35] <xnox> ogra_: hm change it to "env && start hud" and see if UPSTART_SESSION is set?
[11:35] <ogra_> well, i'm just rebooting with some debgging added to the script
[11:35] <ogra_> giv it a few :) reboot takes :)
[11:35] <Laney> Activating service name='com.canonical.hud'
[11:35] <Laney> hud start/running, process 2456
[11:36] <xnox> ogra_: and / or possibly cat the dbus-daemon environ
[11:36] <ogra_> /usr/lib/arm-linux-gnueabihf/hud/dbus-activation-hack.sh
[11:36] <ogra_> bah
[11:36] <ogra_> http://paste.ubuntu.com/6187773/
[11:36] <ogra_> thats the right one
[11:37] <Laney> wtf is that hack
[11:37]  * Laney goes blind
[11:37] <ogra_> Laney, ask ted :)
[11:37] <ogra_> root@ubuntu-phablet:/# sudo -u phablet -i
[11:37] <ogra_> phablet@ubuntu-phablet:~$ env|grep UPSTART
[11:37] <ogra_> UPSTART_SESSION=unix:abstract=/com/ubuntu/upstart-session/32011/1492
[11:38] <ogra_> xnox, that one seems right
[11:38] <Laney> it'll only start if UPSTART_SESSION is set
[11:38] <Laney> get the hud job to dump its env
[11:38] <ogra_> phablet@ubuntu-phablet:~$ env|grep DBUS
[11:38] <ogra_> DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-6mBs0UGGUU
[11:38] <ogra_> Laney, see the pastebin
[11:39] <ogra_> Laney, thats the env of that script
[11:39] <Laney> the hack script or the hud job?
[11:39] <ogra_> hack script
[11:39] <ogra_> session bus address seems fine too
[11:39] <Laney> I don't think that is necessarily the same as upstart will give the job
[11:40] <ogra_> well, upstart should hand over its global env
[11:40] <Laney> hmm but you get unknown job
[11:41] <mhr3_> ogra_, you should revert your image... i don't think unknown job is something you'd get normally
[11:41] <ogra_> right
[11:41] <Laney> I don't see that
[11:41] <Laney> I bet you broke something
[11:41] <ogra_> Laney, that indicates that we dont tolk to the right upstart
[11:41]  * ogra_ re-flashes ... lets see
[11:42] <Laney> all I get is the 10 second delay
[11:42] <Laney> which is nasty, we should just do normal dbus activation until the replacement works propely
[11:42] <ogra_> right
[11:43] <ogra_> Laney, point is that i get zero delay on boot ... UI is up right after the google logo goes away
[11:43] <ogra_> if i disable the hud
[11:43] <ogra_> i fear the dbus activation will still keep a delay for us
[11:44] <Laney> sec, let me try with normal activation
[11:45] <om26er> there are pretty serious problems with the new images
[11:45] <om26er> my phone just hangs, its either unity8 or something.
[11:45] <ogra_> om26er, ?
[11:45] <ogra_> works awesome for me on both arches
[11:45] <Laney> either unity 8 or something, haha
[11:45] <ogra_> i dont think we had such good images ever
[11:46] <Laney> although this google logo is staying on screen for a long time ...
[11:46] <ogra_> Laney, yeah
[11:46] <Laney> oh there we go
[11:46] <Laney> is that something when you enable writable_image?
[11:46] <om26er> ogra_, I can hang my phone in like a few minutes of testing. probably when I try to interact with the OSK
[11:46] <ogra_> Ln"something" ?
[11:46] <ogra_> Laney, ^
[11:46] <Laney> google logo stage (whatever happens then) taking longer
[11:46] <ogra_> om26er, well, i'm using it since a few hours now
[11:47] <ogra_> without any issues
[11:47] <ogra_> Laney, yeah, not much we can do about that
[11:47] <ogra_> Laney, the container startup costs about 10sec ... that delays udev ... so all udev based jobs start later
[11:47] <om26er> ogra_, When i left my home in the morning for uni, I had my phone "halted" for like 10times.. when I got back a newer image came which I just flashed and a few minutes ago I had a similar hang.
[11:48] <om26er> ogra_, I'll come up with exact steps :)
[11:48] <om26er> hopefully
[11:48] <ogra_> :)
[11:48] <ogra_> om26er, oh right, i was talking about the latest stable
[11:48] <om26er> one of the newer bugs is that I tap on an apps icon but the app does not open.. no app would open when I tap on its icon in the dahs
[11:48] <ogra_> which is the last one from tonight ... 78 iirc
[11:48] <jibel> om26er, agreed, I got sevaral crashes with build 78 too, unity8, indicator-sound, media-app, gallery-app
[11:49] <ogra_> weird
[11:49] <pete-woods> orga_: do you think it's worth trying the bootchart with the HUD voice engine disabled? (env HUD_DISABLE_VOICE=1)
[11:49] <jibel> on mako that is
[11:49] <ogra_> i dont have that here with a freshly wiped flash
[11:49] <ogra_> yeah, mako too
[11:50] <ogra_> and the dashboard never looked that good either
[11:50] <om26er> jibel, right now seems the appmanager died or something. none of the apps are opening.
[11:51] <om26er> I should stop using "something" that often as well.
[12:07] <om26er> ogra_, bug 1234670
[12:07] <om26er> sometimes that even results in a complete hang
[12:07] <ogra_> om26er, i cant confirm that as i said above
[12:10] <popey> ditto
[12:11] <ogra_> om26er, was that an upgrade or a freshly flashed install (and did you use --no-backup)
[12:11] <om26er> ogra_, I did:  phablet-flash ubuntu-system --channel saucy-proposed --no-backup
[12:12] <ogra_> thats the same i use here
[12:12] <popey> i freshly flashed one phone, and OTA updated the other and can't reproduce on either
[12:12] <om26er> the issue is not happening under Mir. plus it seems jibel can create something similar as well
[12:12] <ogra_> right, me neither
[12:12] <ogra_> but jibel claimed he can
[12:13] <popey> Hmm. I am seeing something eating a lot of cpu on mine
[12:13] <popey> music app
[12:13] <om26er> popey, try quickly. reboot, unlock, launch calculator, back to dash, before the window fully goes away tap on calculator, repeat
[12:13] <gema> I have an indicator-messages crash for someone to look at, any takers?
[12:13] <popey> ok
[12:14] <jibel> nice, unity8 crashed on boot, rebooting again
[12:15] <ogra_> heh
[12:15] <ogra_> are you guys sure you run 78 ?
[12:15] <popey> root@ubuntu-phablet:/# system-image-cli -i | grep build
[12:15] <popey> current build number: 78
[12:15] <popey> yup ☻
[12:15] <ogra_> yeah, i know you do :)
[12:16] <gema> ogra_: yes, I am
[12:16] <ogra_> i meant jibel and om26er
[12:16] <om26er> ogra_, current build number: 78
[12:16] <ogra_> weird
[12:16] <jibel> root@ubuntu-phablet:/# system-image-cli -i|grep build
[12:16] <jibel> current build number: 78
[12:16] <jibel> ogra_, may I ask you the same question ;)
[12:17] <ogra_> yep, i positively run 78 on both devices
[12:17] <popey> om26er: still can't reproduce
[12:17]  * ogra_ neither ... 
[12:17] <ogra_> on both devices
[12:18]  * jibel 's device is dead -> reflashing
[12:18] <popey> also "before the window fully goes away" is really _hard_
[12:18] <ogra_> yeah
[12:18] <ogra_> how would you do that
[12:18] <om26er> popey, I think you don't really have to acheive that
[12:18] <popey> Either way, can't do it ☻
[12:18] <om26er> race is race. maybe its detecting my finger prints :p
[12:19] <popey> I'll get some new fingers fitted
[12:19] <ogra_> did you install on an iphone ?
[12:19] <ogra_> :)
[12:19]  * popey sets bug to incomplete until someone can reproduce
[12:19] <gema> popey: that's not a good way to deal with race conditions
[12:20] <gema> popey: because it is not incomplete, it is just a bug that's difficult to reproduce
[12:20] <om26er> note: its only happening on SurfaceFlinger.
[12:20] <gema> om26er: any chance you can record a video of it happening?
[12:20] <om26er> gema, Yes, let me do that.
[12:20] <gema> om26er: thanks
[12:21] <ogra_> om26er, if its SF only it might be rather low prio :)
[12:21] <gema> om26er: then attach it and mark the bug as not incomplete again, thx
[12:21] <ogra_> app handling differs between them and SF will not be fully supported anymore soon
[12:22] <ogra_> though i think that app handling change didnt land yet ... lool or didrocks should know though
[12:22] <ogra_> (there are some expected glitches with SF and upstart-app-launch)
[12:24] <lool> ogra_: hmm?
[12:24] <lool> ogra_: right now it should work fine I think
[12:24] <ogra_> yeah, thought so
[12:24]  * ogra_ wasnt sure if it already landed
[12:24] <lool> yeah it hasn't
[12:24] <lool> I think we want to land it just before mir
[12:24] <ogra_> right
[12:25] <ogra_> the above sounded like it could be related
[12:28] <gema> ogra_: who is the person to talk to for my messages indicator?
[12:28] <gema> problems
[12:28] <ogra_> gema, dunno, larsu perhaps
[12:28] <seb128> on a non german reunion day
[12:28] <popey> gema: ok. how do we deal with bugs nobody else can reproduce?
[12:28] <seb128> ogra_, on that note, stop working!
[12:28] <ogra_> seb128, i'm playing :)
[12:29] <gema> popey: a developer looks into them and makes sure all the crash files or whatever has been added to them and tries to fix?
[12:29] <ogra_> seb128, i enjoy a day without spreadsheets
[12:29] <seb128> gema, you can try dednick as well I guess
[12:29] <seb128> ogra_, ;-)
[12:29] <gema> ogra_, seb128 : thanks
[12:29] <popey> gema: have you looked at the crash files on that bug?
[12:29] <gema> popey: no, I haven't
[12:29] <popey> (there are none)
[12:30] <popey> Sorry, happy to change what I'm doing if I'm Doing it Wrong.
[12:30] <mfisch> lool: icon is fixed and after merging with trunk I saw the dh_install issue, thx
[12:30] <gema> popey: it is frustrating to see how race conditions, which are the hardest and most elusive bugs to find and get rid off are being dismissed as non-issues because they cannot be reproduced by you or by balloons or by the bug triager
[12:30] <mfisch> gusch: this fix also passed the testing finally: https://code.launchpad.net/~mfisch/gallery-app/fix-path/+merge/185269
[12:31] <gema> popey: some of those things would benefit from a developer seeing the use case and looking at the code
[12:31] <lool> mfisch: cool, thanks
[12:31] <gema> popey: I am not saying you look into all of them, but at least the ones that look important
[12:32] <popey> ok.
[12:32] <gema> popey: you may be in a different network than om26er and hence not be able to reproduce his bug
[12:32] <gema> popey: or on a better coverage area or..
[12:32] <popey> Sure.
[12:32] <gema> popey: that doesn't mean the bug is incomplete, it's just not reproducible all the time
[12:32] <popey> I don't believe we have time to rummage round in code for race conditions that only one person gets though?
[12:32] <popey> i.e. we have a lorry load of other bugs developers could look at?
[12:33] <gema> popey: if that race makes a critical app to crash or calls to be lost, I'd say it is pretty damn important
[12:33] <popey> ones that have dumps/traces, or are at least repeatable.
[12:33] <gusch> mfisch: wow finally
[12:33] <gema> popey: ok, sounds reasonable, will make a call for everyone to make sure they check for crashes systematically
[12:34] <gema> popey: but at this point, if om26er or jibel find a bug that they think is a bug, it's probably a bug
[12:34] <gema> popey: and if it looks important, someone should look into it
[12:34] <gema> a dev
[12:34] <ogra_> gema, well, if its SF its moot ...
[12:34] <ogra_> *SF only
[12:34] <gema> ogra_: ack, in this case it's moot
[12:34] <gema> ogra_: it's a general point
[12:34] <ogra_> indeed
[12:35] <popey> ( I wasn't arguing that I would flip the status on any bug I can't reproduce btw, only this one )
[12:35] <gema> ogra_: it's juts so that we don't get into the habit of dismissing race conditions because they don't happen to us
[12:35] <gema> ogra_: that's the whole point of a race
[12:35] <popey> gema: don't extrapolate that I do this for every bug based on one ☻
[12:35] <gema> popey: understood
[12:35] <gema> popey: not you, I've seen it happen to me as well
[12:36] <gema> with other bugs and other people
[12:36] <gema> popey: just trying to make a point, if it sticks a bit and you consider it from now on, as well as the other triagers, I am happy
[12:36] <om26er> popey, http://videobin.org/+6xu/8n5.html
[12:37] <popey> gema: you're implying I don't think. Please.
[12:37] <gema> popey: not at all
[12:37] <gema> popey: you do a thorough job
[12:37] <gema> popey: otherwise I wouldn't be bothering having this conversation
[12:37] <popey> I just want these 10 mins of my life back.
[12:38] <gema> me too
[12:38] <popey> om26er: does unity still work when it's in that state?
[12:38] <ogra_> ChickenCutlass, http://people.canonical.com/~ogra/ubuntu-touch/bootchart-mako-dr20131003-2.png and http://people.canonical.com/~ogra/ubuntu-touch/bootchart-mako-dr20131003-3.png ... the second one gets me the UI 5sec after the google logo goes away  (the second one has the HUD disabled)
[12:39] <lool> ogra_, stgraber: If you guys are around, I'd love to test the boot hooks to include them in the image; I guess I'd do a boot time test before and after an upgrade
[12:39] <gema> dednick: ping
[12:39] <lool> ogra_, stgraber: Would you guys have a branch/debdiff?
[12:39] <om26er> popey, yes, Unity is working fine. I have another video coming where system fully hangs. *fully* restarting unity8 from terminal does not work, only a reboot works
[12:39] <ogra_> lool, should be on the landing asks
[12:39] <ogra_> iirc i added it
[12:39] <om26er> that also happens with the same steps
[12:39] <ogra_> lool, row 87
[12:40] <dednick> gema: pong
[12:41] <lool> ogra_: got it in the asks now, thanks
[12:41] <lool> took a while to locate  ;-)
[12:41] <om26er> popey, this http://videobin.org/+6xv/8n6.html (plays in firefox)
[12:41] <ChickenCutlass> ogra_, awesome
[12:41] <gema> dednick: if you could have a look at bug 1234673 and bug 1234680 that'd be excellent
[12:42] <ogra_> ChickenCutlass, maguro  stopwatched: 25sec with SF, 27sec with Mir (but only after disabling the HUD)
[12:42] <popey> om26er: can you get some logs off it when that happens? maybe unity8 log?
[12:42] <ogra_> ChickenCutlass, thats from vibration to having the UI on screen
[12:42] <ChickenCutlass> ogra_, that is good
[12:42] <ChickenCutlass> ogra_, I would take that
[12:42] <ogra_> ChickenCutlass, well, HUD needs fixing, but yeah :)
[12:43] <ChickenCutlass> ogra_, is there a bug filed for the HUD
[12:44] <ogra_> ChickenCutlass, not sure, but mhr3_ and pete-woods are obviously digging into it
[12:44] <ChickenCutlass> ok
[12:45] <popey> 066637
[12:45] <popey> ignore that ☻
[12:45] <ChickenCutlass> lol
[12:45] <ogra_> heh, happz 2fa
[12:45] <ogra_> *happy
[12:45] <dednick> gema: larsu would be your contact for indicator-messages, although I have a feeling the crash bug may have been fixed recently. I think he's working on the icon problem.
[12:46] <gema> dednick: ack, thanks
[12:46] <om26er> popey, is /home/phablet/.cache/upstart/unity8.log the right place for those logs ?
[12:46] <gema> larsu: ^
[12:47] <ogra_> gema, vacation in germany today, dont expect an answer from him
[12:47] <popey> om26er: looks good
[12:47]  * ogra_ isnt here either
[12:47] <gema> ogra_: oh, true, thanks for the heads up :D
[12:48] <pete-woods> ogra_: are you able to try out the "env HUD_DISABLE_VOICE=1" change to hud.conf with bootchart to get some more objective speed measures?
[12:56] <AskUbuntu> How can i interact with phone hardware and other mobile api's? | http://askubuntu.com/q/353144
[12:59] <ogra_> pete-woods, just setting up the device after a new flash ... i'll try that soon
[13:00] <pmcgowan> ogra_, pete-woods whats the bug number for slow hud at boot?
[13:01] <pmcgowan> also what the heck is it doing?
[13:01] <mhr3_> ogra_, is that a simple way to get bootchart to work on the phone? apparently apt-get install bootchart isn't enough
[13:01] <ogra_> not answering properly to a dbus call i think
[13:01] <mhr3_> s/that/there/
[13:01] <pete-woods> pmcgowan: wish I knew what was going wrong
[13:01] <ogra_> mhr3_, http://paste.ubuntu.com/6183389/ replace the upstart job of it with that
[13:01] <pmcgowan> ah
[13:01] <pmcgowan> pete-woods, can we have a bug to track this?
[13:02] <mhr3_> ogra_, thx
[13:03] <ogra_> i guess we should fix the bootchart package at some point :)
[13:05] <mhr3_> ogra_, would be nice :)
[13:08] <om26er> is video playback working for anyone on the latest image ?
[13:08] <om26er> popey, is it for you ?
[13:08] <xnox> ogra_: can I land https://code.launchpad.net/~stgraber/ubuntu/saucy/lxc-android-config/upstart-fixes/+merge/187589 ?
[13:09] <xnox> (i'll merge it, but will not upload at the moment)
[13:09] <ogra_> xnox, that landed already
[13:09] <pete-woods> pmcgowan: https://bugs.launchpad.net/hud/+bug/1234700
[13:10] <ogra_> root@ubuntu-phablet:/# grep pre-stop /etc/init/lxc-android-config.conf
[13:10] <ogra_> pre-stop exec lxc-stop -n android -k
[13:10] <ogra_> xnox, ^^^
[13:10] <xnox> ogra_: ah, well then.
[13:10] <xnox> i'll clean up lp.
[13:10] <ogra_> sorry, my fault
[13:11] <ogra_> i thought the merge would close the MP ... seems it didnt
[13:11] <xnox> ogra_: did you push it back to lp:ubuntu/* branch?
[13:11] <mhr3_> ogra_, here's my bootchart when upstart and dbus actually work - http://people.canonical.com/~mhr3/ubuntu-phablet-saucy-20131003-1.png
[13:12] <davmor2> music playback when the phone is asleep wow
[13:12] <davmor2> it's the little things :)
[13:13] <popey> davmor2: and headphones ☻
[13:13] <mhr3_> ogra_, that makes me realize that my boot is super fast compared to yours :)
[13:13] <davmor2> popey: bluetooth headphones connect too don't know if they work yet they didn't with 75
[13:13] <didrocks> ogra_: *holidays*
[13:13] <didrocks> ogra_: *holidays*
[13:13] <didrocks> ogra_: *holidays*
[13:13] <popey> O_O!
[13:13] <didrocks> this guy, working on his national holidays ;)
[13:14] <popey> yeah, go and buy GTAV and lose a day or two of your life instead ㋛
[13:14] <seb128> didrocks, he's playing he said ;-)
[13:14] <davmor2> didrocks: but ogra_ is french right
[13:14] <davmor2> didrocks: he only pretneds to be german
[13:14] <seb128> didrocks, opened https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1234703 btw, not sure if that's an issue on the system image or settings ... likely the service
[13:15] <ogra_> xnox, no, i was expecting UDD would take care
[13:16] <xnox> ogra_: nah, udd commit a different revision number, and launchpad code only closes merge proposals for matching commit id.
[13:16] <dmanuelalonso> I need help to install in Nexus 7 3G 32GB
[13:16] <xnox> (revision id)
[13:17] <ogra_> mhr3_, yeah, it is and your hud looks a lot saner, what did yoou do ?
[13:17] <davmor2> ogra_: if it is a German holiday are you just swapping days till the release is out?
[13:17] <ogra_> mhr3_, note that i use mako here though
[13:17] <mhr3_> ogra_, nothing, it just works on maguro
[13:17] <ogra_> davmor2, i'm doing the fun stuff today that doesnt involve spreadsheets ;)
[13:17] <didrocks> davmor2: I know other french people pretending to be germa
[13:17] <ogra_> mhr3_, is that image 78 ?
[13:17]  * didrocks looks at seb128
[13:18] <didrocks> seb128: already known, but thanks for opening it!
[13:18] <mhr3_> ogra_, dunno, it's pending cdimage from this morning
[13:18] <didrocks> seb128: already confirmed it's the service :p
[13:18] <ogra_> mhr3_, please dont use cdimage ever when testing something
[13:18] <mhr3_> ogra_, i'm developing, not testing :P
[13:18] <ogra_> mhr3_, it is completely unsupported
[13:18] <seb128> didrocks, thanks ;-)
[13:18] <didrocks> seb128: thanks for opening the bug, I got lazy :p
[13:19] <ogra_> mhr3_, you dont test your code against the autopilot tests before committing to trunk ?
[13:19] <ogra_> mhr3_, if you do any kind of measuring or testing, dont do it against cdimage, it is completely unsupported now
[13:19] <davmor2> didrocks: I've heard this from mvo :)
[13:20] <mfisch> gusch: autolanding failed again
[13:20] <mfisch> this is ridiculous
[13:20] <ogra_> mhr3_, and it will definitely get you different results by design
[13:22] <karni> mzanetti: Somewhere I saw you guys plan to hand out Ubuntu with preinstalled VM's on pendrives to folks at Qt dev days? Could you tell me a little more about it?
[13:22] <didrocks> davmor2: see, 2 sources! it's true then :)
[13:23] <ogra_> mhr3_, btw, a fixed bootchart is uploaded now ... shouldnt need the upstart job hackery anymore
[13:23] <dmanuelalonso> help me please
[13:23] <dmanuelalonso> I speak a little english
[13:24] <mhr3_> ogra_, yet hud working vs not working won't be cdimg vs systemimg issue
[13:24] <dmanuelalonso> I want install ubuntu touch in my tablet nexus 7 3G 32 GB
[13:24] <mhr3_> ogra_, awesome, thx
[13:24] <ogra_> mhr3_, could be, if the hud does stuff in dirs that arent writable for examlpe
[13:24] <dmanuelalonso> is this script ?  ----> phablet-flash ubuntu-system --no-backup -d grouper
[13:25] <gusch> mfisch: surprise - the tests for gallery are really flaky - I have no idea why :(
[13:25] <seb128> mhr3_, hey, do you still have your screenshot being blank issue?
[13:25] <ogra_> mhr3_, strace on a proper readonly image might be intresting ;)
[13:25] <mhr3_> ogra_, let's not forget that you can get the same thing on desktop as well
[13:25] <davmor2> dmanuelalonso: I didn't think the 3g version of the n7 was also called grouper I could be wrong
[13:26] <mhr3_> ogra_, (hud not working)
[13:26] <ogra_> mhr3_, oh, it fails the same way there ?
[13:26] <ogra_> k
[13:26] <mhr3_> sometimes
[13:26] <mhr3_> not as often
[13:26] <ogra_> does it also force the unity timeout ?
[13:26] <ogra_> or does unity7 simply not have that
[13:26] <mhr3_> no, unity7 is not waiting for it
[13:26] <ogra_> ah
[13:27] <ogra_> then users wont notice it that heavily
[13:27] <mhr3_> seb128, yes
[13:27] <mhr3_> seb128, i added info about it to some compiz bug
[13:27] <mhr3_> seb128, seems suspend+resume related
[13:27] <seb128> mhr3_, likely https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1234178 then
[13:28] <seb128> mhr3_, switching to a vt and back to xorg should workaround it
[13:28] <mhr3_> yey!
[13:28] <seb128> mhr3_, we should get the intel fix in saucy, just as fyi
[13:28] <mhr3_> it does
[13:28] <mhr3_> seb128, great
[13:28] <mhr3_> thx
[13:28] <seb128> mhr3_, do you have the compiz bug? so those guys don't waste more time debugging it
[13:28] <seb128> mhr3_, yw
[13:28] <mhr3_> let me try to find it
[13:29] <mhr3_> seb128, https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1192160
[13:29] <seb128> mhr3_, thanks
[13:30] <mhr3_> i guess that will also fix skype desktop sharing?
[13:30] <mhr3_> as it was just showing black screen
[13:30] <gatox> sil2100, hi, have you seen this bug?? https://bugs.launchpad.net/click-update-manager/+bug/1234379 do you know what might be going on?? this is not failing locally.... maybe where it's being executed there isn't the correct autopilot version..... do you know who to ask about this?
[13:30] <seb128> mhr3_, likely yes
[13:31] <sil2100> gatox: hi! Let me see, maybe we're missing a dependency? It's always hard to check, but I'll actually use out test environment to check what's missing
[13:32] <gatox> sil2100, as far as i can see...... it's seems to have some missing parts of autopilot or something
[13:39] <mhall119> this is taking up a lot of my CPU on my Nexus 7:
[13:39] <mhall119> /system/bin/brcm_patchram_plus --enable_hci -
[13:39] <mhall119> -scopcm=0,2,0,0,0,0,0,0,0,0 --baudrate 3000000 --use_baudrate_for_download --pat
[13:39] <mhall119> chram /etc/firmware/bcm4330.hcd --no2bytes --enable_lpm --tosleep=50000 /dev/tty
[13:40] <mhall119> anybody know what's going on?
[13:40] <mfisch> fginther: are autolanding jobs restartable?
[13:41] <mfisch> fginther: after flaky tests fail
[13:41] <ogra_> mhall119, bluetooth ... talk to cyphermox
[13:41] <dobey> mhall119: upstart-property-watcher is doing that on mine
[13:42] <ogra_> dobey, that was supposed to be fixed in 78
[13:42] <cyphermox> mhall119: this is what makes bluetooth useable at all
[13:42] <cyphermox> not something we really control so much though, so I'm not sure why it would use much CPU
[13:42] <mhall119> cyphermox: well it seems to be making everything else unusable...
[13:43] <cyphermox> mhall119: something else on the device, in the kernel or whatever must be blocking IO
[13:43] <dobey> ogra_: i see 78 in the updater, just installing it now.
[13:43] <ogra_> good
[13:43] <cyphermox> mhall119: it consistently does that after reboot?
[13:44] <fginther> mfisch, just re-approve the MP
[13:44] <mhall119> cyphermox: on recent images it seems to, on my nexus7
[13:44] <cyphermox> mhall119: ok
[13:44] <cyphermox> I'll update my nexus 7 and check
[13:44] <fginther> mfisch, it will get retriggered automatically
[13:45] <cyphermox> but if dobey says there is a cpu hog with upstart-property-watcher, perhaps something got broken with the properties
[13:45] <ogra_> cyphermox, that was  a hybris bug, fixed in 78
[13:46] <cyphermox> ogra_: well, that could easily break brcm_patchram and mtp as well...
[13:46] <dobey> cyphermox: it's fixed now in 78
[13:46] <ogra_> cyphermox, indeed
[13:46] <cyphermox> since they all use the properties in some way
[13:46] <ogra_> well, thats not getprop/setprop stuff i think
[13:46] <dobey> at least, i just installed 78, and it's not doing it now
[13:46] <ogra_> but the new upstart event handler
[13:47] <cyphermox> ogra_: to help the handler, it has to do something with teh property service, no? :)
[13:48] <ogra_> yes, but the property service should be fine in itself ... just the upstart bit of it not
[13:48] <gatox> sil2100, when the tests are fixed..... is the build being uploaded somewhere?? because i want to install the .deb manually to be sure the icon is being shown, and it's failing to build it locally
[13:48] <ogra_> (nothing uses that yet)
[13:49] <cyphermox> ogra_: I agree
[13:49] <cyphermox> however,
[13:49] <ogra_> it eats CPU though
[13:50] <ogra_> with the breakage
[13:50] <cyphermox> it could be that the upstart bridge blocks the other apps from accessing properties?
[13:50] <ogra_> moght be
[13:50] <ogra_> well, its moot anyway ... it is fixed :)
[13:50] <cyphermox> yeah, probably fixed..
[13:50] <ogra_> ??
[13:51] <cyphermox> I can't reproduce the CPU issues or MTP issues here on my mako, with image 78
[13:51] <ogra_> cyphermox, http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4523/ broken ...
[13:52] <ogra_> cyphermox, vs http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4527/ ... fixed
[13:52] <AskUbuntu> install ubuntu in mobile on windows phone | http://askubuntu.com/q/353170
[13:52] <awe_> cyphermox, ogra_, just reported: https://bugs.launchpad.net/ubuntu/+source/mtp/+bug/1234732
[13:52] <ogra_> awe_, it doesnt prevent them :)
[13:52] <awe_> was just about to add a comment, as I finally was able to get it to work via setprop and the override file
[13:52] <sergiusens> jodh, hey, did you get a chance to look at the upstart-local-bridge issue?
[13:52] <ogra_> awe_, it causes disconnects though
[13:53] <awe_> ogra_, it does prevent
[13:53] <ogra_> awe_, on image 78 ?
[13:53] <ogra_> not for me
[13:53] <awe_> No, last stable...
[13:53] <awe_> #70
[13:53] <ogra_> it causes a reconnect if the property changes
[13:53] <pete-woods> pmcgowan, ogra_: there's a more complete bug report about the weird dbus issues we've been seeing here (https://bugs.launchpad.net/url-dispatcher/+bug/1234731)
[13:53] <ogra_> last stable is 78 :)
[13:53] <awe_> just quit working yesterday afternoon
[13:53] <ogra_> awe_, mako or maguro ?
[13:54] <ogra_> i saw some weird behavior on maguro here but it just went away when i wanted to research it
[13:54] <cyphermox> awe_: if that's the case, seeing as you have a pretty clear bug description, I can only conclude that the cause is not mtp
[13:55] <awe_> really?  don't quite follow your logic
[13:55] <awe_> also...turns out the override did finally work, just updating the bug now
[13:55] <cyphermox> that changes everything
[13:56] <cyphermox> awe_: what image are you on?
[13:56] <dmanuelalonso> Does anyone have ubuntu-touch on the Nexus 7 3G?
[13:56] <popey> dmanuelalonso: i think most of our Nexus 7's are wifi only
[13:57] <cyphermox> awe_: nevermidn I see it in the bug
[13:57] <awe_> cyphermox, it's in the bug
[13:57] <awe_> ;)
[13:57] <stgraber> lool: still need some help?
[13:57] <josepht> dmanuelalonso: there's been some chatter on the ubuntu-phone mailing list about getting touch working on the N7 3g
[13:57] <cyphermox> awe_: try 78...
[13:57] <ogra_> cyphermox, mtp behavior definitely got works after stgraber's upstart fixes ...
[13:57] <cyphermox> that's the best I can offer right now. there is no change in MTP, but there was this hybris change for the upstart property thing
[13:57] <ogra_> i assume we need to look into that again
[13:58] <cyphermox> ogra_: we already have those
[13:58] <cyphermox> gah
[13:58] <ogra_> cyphermox, have what ?
[13:58] <cyphermox> mtp is fine.
[13:58] <cyphermox> something else got broken
[13:58] <ogra_> cyphermox, its not ...
[13:58] <popey> ogra_: is there a way to tell which bit of the stack has gone rogue when the display locks up?
[13:58] <awe_> cyphermox, did you release a fix to mtp between 70 and 78?
[13:58] <cyphermox> awe_: I did not
[13:58] <ogra_> cyphermox, adb disconnects on start of mtp and i get the gvfs errors (3-5) on shutdown
[13:58] <cyphermox> but MTP hasn't changed either since much before #70
[13:59] <ogra_> cyphermox, the upstart job changed
[13:59] <awe_> I used to get tons of dialogs on my desktop whenever rebooting
[13:59] <cyphermox> ogra_: not recently enough to matter, that's what I'm saying
[13:59] <awe_> anyways, the bugs been reported.  If you can't reproduce, then it just stays in new state
[13:59] <ogra_> cyphermox, whiich brought all the odd behavior back
[13:59] <awe_> sergiusens asked me to enter the bug
[13:59] <stgraber> lool: when I wrote that code, I tested with 3 basic upstart jobs under /etc/init/boot-hooks, one that's simply "start on boot-hooks WHEN=new-version", another that's simply "start on boot-hooks WHEN=every-boot" and one that was along the line of "start on boot-hooks WHEN=new-version OLD_BUILD=x NEW_BUILD=y and dbus", each would just echo "<name of the file> $WHEN $OLD_BUILD $NEW_BUILD" so I could check which ran from /var/log/upstart/
[14:00] <awe_> I'll continue to test now, as I'd rather spent my time on mobile disconnect scenarios
[14:00] <cyphermox> ogra_: so your saying stgraber's changes broke MTP?
[14:01] <dobey> is there a way to get the daily builds of things on the device, without adding a PPA and updating via apt-get?
[14:01] <stgraber> ogra_: what changes? IIRC all I did was fix hung jobs in upstart, so if that broke mtp, we've got another problem :)
[14:02] <cyphermox> stgraber: nah. the jobs look correct, and behave correctly for me
[14:02] <stgraber> ogra_: and FWIW when I tested those, I certainly still had mtp startup fine here
[14:02] <ogra_> stgraber, we definitely have an out of sync problem
[14:03] <sergiusens> cyphermox, I don't think stgraber's recent change to boot hooks is the cause
[14:03] <awe_> cyphermox, how to I go about gaining the ability to tweak priorities for ofono (Ubuntu) bugs?
[14:03] <ogra_> stgraber, mtp-server  goes away  but the gadget device is still in mtp mode ... on shutdown my desktop is scattered with mtp errors from gvfs
[14:03] <lool> stgraber: do we block the rest of the boot until the hooks are done in some way?
[14:04] <ogra_> stgraber, ot is nothing your change caused though
[14:04] <ogra_> but it exposes it again
[14:04] <cyphermox> awe_: ask someone to give you access -- joining bugcontrol or something
[14:04] <stgraber> lool: nope
[14:04] <sergiusens> stgraber, awe_ cyphermox ogra_ I asked awe to put the bug in MTP since we really don't want that system job triggering reconfiguration of the bus; the proper solution is to move that setup to where it belongs; in the vendors desired default bus setup
[14:04] <stgraber> lool: unless the hook also says "and starting <something>"
[14:05] <cyphermox> sergiusens: that's fine, but that won't fix the problem, you'd still have a device with mtp enabled for the gadget on shutdown, and no mtp-server running, so a dialog on the host
[14:05] <ogra_> right
[14:05] <cyphermox> sergiusens: changing the property on boot and on shutdown is perhaps not optimal but it does work
[14:05] <sergiusens> cyphermox, so that's a different bug
[14:06] <ogra_> that part wont be fixable without some redesign
[14:06] <cyphermox> and it's the only place where it happens, it doesn't happen when mtp gets started
[14:06] <cyphermox> I mean, when the binary server gets started
[14:06] <ogra_> sergiusens, not so sure ... if the connection goes wild because of gvfs madly reconnecting adb might be affected
[14:06] <sergiusens> ogra_, cyphermox I think that's a nautilus problem fwiw
[14:06] <ogra_> nah
[14:06] <ogra_> nautilus is top level
[14:06] <ogra_> gvfs is the issue
[14:06] <cyphermox> sergiusens: I fully agree with you
[14:07] <sergiusens> ogra_, cyphermox if I don't want mtp in my system I should be able to setprop it to adb only
[14:07] <ogra_> but it behaves properly on other phones
[14:07] <cyphermox> gvfs-mtp thing doesn't know how to handle this case
[14:07] <ogra_> right
[14:07] <ogra_> but its a case we made up
[14:07] <ogra_> android doesnt expose it
[14:07] <cyphermox> sergiusens: yes, you should -- but you won't ever be able to do that until we have a proper property service and settings panel that lets you change this
[14:08] <ogra_> we need to get the property change in sync with the server
[14:08] <cyphermox> meh, not really
[14:08] <cyphermox> there's a property service so we can just not start the server when mtp isn't enabled, that's no big deal
[14:09] <ogra_> how will you unset the property if the server goes down then ?
[14:10] <cyphermox> wrong way around
[14:10] <ogra_> well, thats what causes the bug
[14:10] <cyphermox> I'll bring down the server when the property gets unset
[14:10] <cyphermox> no
[14:10] <ogra_> that wont hekp anything
[14:10] <cyphermox> of course it will
[14:11] <cyphermox> mtp-server is useless and not connected to anything if the property is unset
[14:11] <ogra_> the property gets unset about 20sec after the server went down on shtdown
[14:11] <cyphermox> yes
[14:11] <ogra_> since it is managed by a system job ... that isnt connected to the session job
[14:11] <cyphermox> wrong way around, like I said
[14:11]  * cking observes init consuming heap quickly when doing mp4 playback on Samsung Galaxy  Nexus
[14:12] <ogra_> cyphermox, seriously, you try to make fun out of me now, right ?
[14:12] <cyphermox> ogra_: this will be fixed by using the property bridge.
[14:12] <ogra_> we discussed that several times now
[14:12] <cyphermox> ogra_: I can even probably fix it now
[14:12] <cyphermox> ogra_: yes, we discussed it, and I'm saying the property needs to be removed *before* the server is brought down, always
[14:12]  * ogra_ doubts that, unless you can make the session job talk to the system job
[14:13] <cyphermox> ogra_:    session jobs can watch for system events.
[14:13] <ogra_> yes, but that cant happen in the current design
[14:13] <ogra_> right
[14:13] <ogra_> but what you need is a system job that watches for a session one
[14:13] <cyphermox> why?
[14:13] <ogra_> because thats where the property is unset
[14:13] <cyphermox> the property isn't changed by the session job
[14:14] <ogra_> yes
[14:14] <ogra_> thats what i'm saying since 20min
[14:14] <cyphermox> no. look at the job. it doesn't change the property
[14:14] <ogra_> the server dies with the session ... the property only gets unset once the system job gets iots stop event
[14:14] <ogra_> several seconds after the session stopped
[14:14] <cyphermox> it also couldn't, because the job doesn't run as root
[14:15]  * ogra_ sighs
[14:15] <ogra_> i give up
[14:17] <cyphermox> ogra_: I wrote the jobs, I know what I'm doing. it doesn't explain the issue people are seeing, but if there's still something wrong with the shutdown, it's either something we need to change in the stop on clause for the system job, or something to fix in gvfs.
[14:17] <ogra_> gvfs works fine with all other mobiles you attach in mtp mode
[14:17] <ogra_> because they never have the property set while there is no server
[14:18] <cyphermox> agree.
[14:18] <ogra_> we need to achieve the same
[14:18] <cyphermox> yes
[14:18] <ogra_> and with the two upstart jobs that run several seconds apart we wont be able to
[14:18] <cyphermox> and I'll start to look into that as soon as i find some docs about the upstart property thingy
[14:19] <cyphermox> yes, we will. let me handle it
[14:19] <rsalveti> sergiusens: ^
[14:19] <rsalveti> I know sergiusens was investigating the property system feedback in upstart yesterday, guess we still have one issue of not getting all the events
[14:20] <rsalveti> but will try with the next image again, which should also bring a fix for lxc-android-config
[14:20] <cyphermox> rsalveti: ack
[14:20] <ogra_> getting events from the system wont help ... can we set and get props with it ?
[14:20] <cyphermox> ogra_: no need
[14:21] <cyphermox> rsalveti: I'll check now to make sure here
[14:21] <ogra_> cyphermox, then explain to me how you stop the system job before the session
[14:21] <ogra_> without mad hackery
[14:21] <ogra_> since the system job is the only one capable to set/get the property
[14:22] <sergiusens> ogra_, you can get from session
[14:22] <cyphermox> ogra_: shortly, something like stop on :sys:<property>_changed or whatever the signal will be called
[14:22] <rsalveti> can't you just sync that in the upstart jobs?
[14:22] <ogra_> sergiusens, but not set ... which is what we need to do
[14:22] <cyphermox> ogra_: the event will fire as soon as the property gets changed, during the stopping of mtp-server-bootup, but before it is stopped.
[14:22] <ogra_> rsalveti, the system job cant watch the session job apparently
[14:22] <rsalveti> you can do the other way around "on stopping server" setprop
[14:22] <rsalveti> oh
[14:22] <sergiusens> speaking of which, jodh did you have a chance to look in the upstart-local-bridge?
[14:22] <cwayne> thostr_, ping
[14:22] <ogra_> cyphermox, again ... the property doesnt get change3d by killing the server in the session
[14:23] <ogra_> rsalveti, you can do it for session watching system ... yoou cant do it the other way round
[14:23] <ogra_> afaik
[14:23] <cyphermox> ogra_: no, it does not. but it does when the system job is brought down
[14:23] <sergiusens> ogra_, cyphermox rsalveti not sure if you consider this hackery but we can use upstarte-file-bridge as a middleman
[14:24] <cyphermox> sergiusens: interesting
[14:24] <ogra_> sergiusens, less hackery than calling "mtp-fo-bar stop" from another job
[14:24] <ogra_> or some such
[14:24] <gema> seb128: the time picker doesn't seem to want to pick time today on image 78
[14:24] <gema> seb128: do you know about it?
[14:24] <gema> (running on mir now)
[14:24] <ogra_> cyphermox, *when exactly* is the system job brought down ?
[14:25] <cyphermox> ogra_: right now, far too late
[14:25] <ogra_> cyphermox, is it brought down if i stop mtp-server in a terminal-app session ?
[14:25] <ogra_> thats my point
[14:25] <cyphermox> no, it's not
[14:25] <sergiusens> just do stop on FILE event=delete on the system job
[14:25] <cyphermox> ogra_: irrelevant
[14:26] <seb128> gema, no, in which way it "doesn't seem to want to"?
[14:27] <seb128> gema, e.g what do you do and what is happening?
[14:27] <gema> seb128: I go to manual time, then try to change the hour of the day with the picker, then I click set. And it goes back to the previous screen without changing the time
[14:27] <seb128> gema, how do you check that the time didn't change?
[14:27] <jodh> sergiusens: no - I thought the issue with lxc removing the socket may have explained the behaviour you were seeing?
[14:27] <gema> seb128: both on the indicator and on the previous settings screen
[14:28] <gema> seb128: they are consistent with automatic time
[14:28] <rsalveti> jodh: how to easily get the logs of everything that the watcher is pushing to upstart?
[14:28] <seb128> gema, wfm, but my device is rw atm ...
[14:28] <rsalveti> and the ones the local-bridge will trigger as well
[14:28] <seb128> gema, does selecting a tz works?
[14:28] <gema> seb128: trying now
[14:28] <sergiusens> jodh, not really, that explains the problem of sync, but the jobs are in sync as is, if it weren't you'd get connection denied from the android side
[14:29] <sergiusens> jodh, the problem I'm seeing (and thankfully rsalveti is now too), is that the events are triggered and reported on the android side, but not picked up by the bridge
[14:29] <gema> seb128: yes it does, it changed the time preference to automatic again
[14:30] <gema> seb128: and now the time picker works again
[14:30] <gema> seb128: I am going to reboot and try again
[14:30] <jodh> sergiusens: ok, if that's the case even after the lxc fix, please can you raise a bug so I can investigate?
[14:30] <jodh> rsalveti: we could do with more debug on both sides I think.
[14:30] <seb128> gema, let me know how it goes
[14:30] <sergiusens> jodh, sure
[14:31] <gema> seb128: ack
[14:32] <rsalveti> yeah
[14:32] <mfisch> cwayne: image 79 also fixes our category ordering in the home scope
[14:32] <rsalveti> seems it's fine from the android side at least, you can check that now with logcat
[14:32] <rsalveti> we got debugs for everything in there by default now
[14:35] <lool> stgraber: Would it make sense to block boot until upgrade hooks are done, as to avoid the session starting while e.g. some system-wide stuff is being converted?
[14:36] <ogra_> lool, uuuh, without the ability for any user feedback while we do that ?
[14:36] <lool> ogra_: hooks shouldn'
[14:36] <lool> t take long anyway
[14:37] <gema> seb128: definitely something weird going on, after picking the tz and making the time automatic, (and verifying my wifi is on), the time won't reset to actual time
[14:37] <ogra_> depende what people start to abuse them for :)
[14:37] <ogra_> (but once people do that we might also have a splash)
[14:37] <cwayne> mfisch, ok, we definitely need to wait for 79 then
[14:38] <davmor2> seb128: ref bug 1234733 I can dig into some more but currently I'm on something else so it might not be till tomorrow and I only have maguro.
[14:38] <mfisch> cwayne: yep
[14:38] <mfisch> cwayne: what happened with that album art/gsettings stuff?
[14:40] <stgraber> lool: no, because the definition of "boot" will change from one package to another, if you're going to do a change before dbus runs, your job will have to include "and starting dbus" (same for any service)
[14:41] <davmor2> ogra_: wow grouper has sound again
[14:41] <ogra_> sorry, not my fault
[14:41] <ogra_> :)
[14:41] <lool> stgraber: ok
[14:41] <cwayne> mfisch, i could never get it to work again
[14:41] <davmor2> ogra_: well don't try fixing it
[14:43] <mfisch> cwayne: okay well we have the 1 bug about last.fm not trying, lets file another to get local album art enabled
[14:43] <cwayne> mfisch, sure.  i have a MR for it
[14:49] <davmor2> cwayne, mfisch: fetching album art worked for me on 78 this morning till my ofono got broken
[14:50] <mfisch> davmor2: it does not work if you don't have 3g, like me
[14:50] <cwayne> davmor2, right, im trying to make it so it can find local metadata
[14:50] <davmor2> mfisch: nope but if I have a connection it does
[14:50] <cwayne> davmor2, i got it to work once last night, but could neber get it reliably
[14:50] <mfisch> davmor2: all I know is that no matter what I do to enable wifi it's never ever worked for me
[14:51] <cwayne> davmor2, any idea whos on the mediascanner team?
[14:52] <user82> does anyone think ubuntu touch is faster with c++ apps? http://appglimpse.com/blog/touchmarks-i-smart-phone-touch-screen-latencies/
[14:56] <rsalveti> om26er: can you also attach the video used in bug 1234722?
[14:56] <rsalveti> or a similar sample
[14:56] <rsalveti> om26er: same for bug 1234726
[15:00] <gema> rsalveti: any chance we could timestamp all the logs that end up in /home/phablet/.cache ?
[15:00] <gema> rsalveti: it'd make post mortems so much easier
[15:02] <rsalveti> gema: you mean !Jan  1  1970? :-)
[15:02] <rsalveti> just noticed it
[15:02] <gema> rsalveti: current date, whichever on the phone
[15:02] <gema> :)
[15:02] <rsalveti> gema: right, will take a look at it
[15:02] <gema> rsalveti: thanks
[15:02] <rsalveti> gema: is that device specific?
[15:03] <rsalveti> just saw it on mako
[15:03] <gema> rsalveti: I am on mako as well
[15:04] <cyphermox> rsalveti: awe_: so as far are you're concerned do you think we'd be ok landing NM to fix the auto reconnection stuff now? and keep working on Attached states?
[15:05] <rsalveti> I'm fine with it
[15:06] <awe_> cyphermox, well did you see my routing bug?  Something still is borked on the NM side.  I will work on the attach bug next
[15:06] <cyphermox> awe_: I think it's safe, not causing regressions, but you could still be disconnected if Atached changed
[15:06] <cyphermox> awe_: link?
[15:06] <awe_> did you read your mail this morning?  ;)-
[15:13] <om26er> rsalveti, ok
[15:15] <mpt_> dednick, https://wiki.ubuntu.com/StatusBar#Handling_overflow
[15:16] <dednick> mpt: thanks
[15:29] <cyphermox> awe_: re dbus; let me know if you find that it was for org.ofono.ConnectionManager. If that interface somehow shows like it's being regularly removed and re-added, then I'll go GetProperties on it every time I create the dbus proxy
[15:29] <cyphermox> still, only once for the proxy, and then watching the property changes :)
[15:30] <awe_> cyphermox, I don't think so
[15:31] <cyphermox> I know, but just making sure ;)
[15:31] <cyphermox> I would be sad to find out I'm the one who doesn't know how to write dbus code ;)
[15:31] <awe_> my guess is that before the modem comes up, some process ( telepathy-ofono or indicator ), just peppers ofono with GetProperties method calls...
[15:31] <awe_> cyphermox, whomever is making the method calls
[15:31] <awe_> should call GetProperties once
[15:31] <cyphermox> awe_: agree
[15:31] <awe_> and then monitor the changed prop signal
[15:31] <awe_> k
[15:32] <cyphermox> and afaik, I am; but who knows if something is broke
[15:34] <cwayne> didrocks, do we have an ETA on image 79?
[15:35] <didrocks> cwayne: the image will start building in some minutes
[15:35] <cwayne> didrocks, perfect, thank you
[15:35] <cwayne> mfisch, ^
[15:35] <didrocks> yw
[15:35] <mfisch> perfect
[16:00] <cwayne> ogra_, ping
[16:00] <popey> cwayne: .de is on public holiday today
[16:01] <cwayne> gr
[16:01]  * cwayne believes if you're on IRC, you're fair game to be pinged
[16:03] <seb128> cwayne, yeah, it is, you are probably going to get a pong tomorrow
[16:05] <sergiusens> doanac, added comments to https://code.launchpad.net/~doanac/phablet-tools/autopilot-config/+merge/189112
[16:05] <doanac> sergiusens: good idea. i'll make that change
[16:09] <doanac> sergiusens: NOTE: argparse made their usage mutually-exclusive. However, I think your suggestion is better style
[16:14] <sergiusens> doanac, well I'm ok with it being mutually exclusive :-)
[16:14] <doanac> sergiusens: i think your idea is cleaner
[16:15] <sergiusens> doanac, it moves the option logic into argparse
[16:16] <doanac> sergiusens: re-pushed
[16:16] <sergiusens> doanac, thanks
[16:26] <elopio> sil2100: ping. Do you know why is the package click-update-manager-autopilot not on the repos?
[16:27] <elopio> sil2100: nevermind, it is.
[16:29] <davmor2> elopio: look just to your left and you'll spot it honest ;)
[16:32] <Chocanto> Hey everyone !
[16:33] <Chocanto> Does someone here had problem to center vertically an item ?
[16:35] <lool> dbarth_: we're landing webcred stack, I hope that's ok
[16:41] <sergiusens> doanac, added comments to https://code.launchpad.net/~doanac/phablet-tools/phablet-config-developer-mode/+merge/188416
[16:44] <lool> xnox: heya, I have a bugfix for readling on empty path from you near the top of landing plan, apparently related to emulator; is this something you're about to upload?
[16:45] <lool> xnox: apparently that's https://code.launchpad.net/~xnox/ubuntu/saucy/initramfs-tools-ubuntu-touch/emulator/+merge/188398
[16:46] <lool> xnox: ok, landing this now
[16:48] <xnox> lool: it's a very safe bugfix.
[16:48] <xnox> lool: the branch name has become unrelated.
[16:49] <dbarth_> lool: we've re-tested it manually a few days ago again, and we have a first AP package that checks it starts and runs fine
[16:49] <dbarth_> lool: so, yes, go ahead
[16:50] <per> hi how do i make a phonecall?
[16:50]  * popey flashes 79
[16:50] <Guest20515> i have put in my simcard, but cant press the green dail button in the keypad
[16:51] <lool> xnox: Yes, it seemed trivial indeed
[16:51] <lool> xnox: I've merged it and uploaded it
[16:51] <lool> xnox: then we need android build
[16:51] <lool> xnox: what's the best way to test this before building a new image?  I'd like to deploy updated android initrd locally and try rebooting
[16:51] <xnox> lool: wait for dbus fix, which should fix the boot delays.
[16:51] <lool> dbarth_: great thanks
[16:52] <xnox> it's also trivial bug fix which I am about to upload.
[16:52] <lool> dbus fix.... interesting.... but scary
[16:52] <lool> now I'm going to blame all the dbus issues ever on this thing
[16:52] <gema> tedg: I have dbus.log still, but it happened quite a while ago and I have restarted since, would it still contain the info you need or does it get rewritten on reboot?
[16:52] <lool> xnox: do you have a landing slot for this one?
[16:53] <lool> xnox: happy to set one up real quick, would love to read a bug / MP
[16:53] <xnox> lool: no idea. it's the thing we were fighting all day today between ogra, jodh, myself and tedg
[16:53] <xnox> bug #1234731
[16:53] <xnox> literarly we will make dbus-session to fork instead of run in foreground.
[16:53] <xnox> s/session/daemon/
[16:54] <tedg> gema, Perhaps, we can grep it
[16:54] <lool> xnox: right, that's what I was seeing
[16:54] <lool> url-dispatcher getting connection error
[16:54] <lool> tedg, xnox, jodh: Thanks for tracking this down, it was annoying
[16:54] <jdstrand> ogra_: ok, I am unable to reproduce. 25 runs on grouper and 50 on mako and apparmor_parser is loading from the cache successfully. I think something must have changed on your reboot-- ie, the md5sums files in /var/lib/dpkg that click-apparmor is looking at. I can't explain why they changed, but the click-apparmor upstart job output supports this. if you have the problem again, please file a bug with steps to reproduce
[16:54] <xnox> lool: uploaded into -proposed, should appear with a diff in the queue soon.
[16:55] <gema> tedg: ok, attaching, it'd be useful to have logs with timestamps, btw, I spoke to rsalveti about it before
[16:56] <gema> tedg: I have added the file
[16:56] <tedg> gema, I think that's a jodh thing
[16:57] <gema> jodh: can we have upstart logs with timestamps, please?
[16:58] <jdstrand> ah, that would have been helpful for me too :)
[16:58] <jdstrand> jodh: ^
[16:59] <seb128> Saviq, if you reproduce that indicator-messages segfault, can you get us a valgrind with debug symbols?
[16:59] <seb128> charles, ^
[16:59] <seb128> tedg, ^
[16:59] <jono> bfiller, I filed https://bugs.launchpad.net/phone-app/+bug/1234794 - it looks like the touchpad works on some calls, but not voicemail
[16:59] <Saviq> seb128, no segfault here!
[16:59] <seb128> Saviq, oh, so you get the blue icon bug but no segfault?
[16:59] <Saviq> seb128, yes
[16:59] <seb128> Saviq, is that on fresh boot or after receiving some messages and clearing the menu off?
[17:00] <tedg> I was going to try to recreate, but I have to remember the phone number of my phone :-)
[17:00] <rsalveti> gema: yup, found the issue, checking how to fix it
[17:01] <gema> rsalveti: excellent thanks
[17:01] <Saviq> seb128, fresh - no stuff was ever in there
[17:02] <josepht> is it possible to expose my mako connected to my laptop to a LXC running on my laptop?
[17:02] <gema> stgraber: ^
[17:04] <dobey> is there any way at all to actually lock the screen?
[17:05] <stgraber> josepht: I think so, add "lxc.cgroup.devices.allow = c 189:* rwm" to your container's config, reboot it, then unplug your device, plug it again and it should work
[17:05] <stgraber> josepht: (I haven't tested but that's usually how things work with udev and raw usb device, so that should work fine)
[17:06] <stgraber> alternatively, if you know what entry it's under /dev/usb, you can do lxc-device add -n <container> /dev/usb/... (not persistent though and the path may change depending on the usb port you're using)
[17:20] <josepht> stgraber: no luck with either approach
[17:23] <josepht> stgraber: nm, had to restart adb as root
[17:24] <cwayne> jhodapp|lunch, ping when you're back from lunch
[17:30] <popey> ----------  1 phablet whoopsie  11M Oct  3 17:30 _usr_bin_unity8.32011.crash
[17:30] <popey> ☹
[17:47] <jhodapp|lunch> cwayne, back in 5 mins
[17:48] <jodh> gema: there is a feature request for this (1154207), but it won't be landing for 13.10. Advice for now: get your app to produce the timestamps or use syslog.
[17:52] <xnox> bug 1154207
[17:56] <jhodapp> cwayne, back
[17:57] <popey> ogra_: lool: fyi 79 seems good to me on mako
[17:57] <cwayne> jhodapp, heya!  i had some questions about mediascanner, specifically album art, and saw your name at the top of mediaartcache.cpp :)
[17:58] <jhodapp> cwayne, my name might be there, but I didn't write a single line of code :)
[17:58] <jhodapp> cwayne, but what are your questions?
[17:59] <cwayne> jhodapp, if i have an album's cover art saved in /home/phablet/.cache/media-art/album-(md5 of artist)-(md5 of album).jpg, theoeretically it should 'just work' right?
[17:59] <cwayne> just work as in show the album art in unity
[17:59] <jhodapp> mhr3_, do you know the answer to cwayne's question? ^
[18:00] <jhodapp> cwayne, I do know there are some bugs being worked on surrounding that type of thing
[18:00] <jhodapp> cwayne, so you may be correct, it might just not quite be working yet
[18:01] <mhr3_> cwayne, sdk branch that would make it "just work" wasn't merged yet
[18:02] <mhr3_> cwayne, but otherwise, no
[18:02] <cwayne> mhr3_, what about enabling the grl-local-metadata plugin?
[18:02] <cwayne> it looks there as well i know
[18:02] <mhr3_> oh wait.. this is about music, sorry
[18:02] <mhr3_> thought you're talking about videos
[18:03] <cwayne> nope, music cover art :)
[18:03] <mhr3_> theoretically if you get grilo to know about the art it should work
[18:03] <cwayne> mhr3_, hm, i tried to enable the local-metadata plugin and dropped that file there, but i couldn't get it to work
[18:03] <mhr3_> then again mediascanner might be picky about which plugins it uses though
[18:04] <mhr3_> cwayne, try stopping mediascanner, rm its db and start it again
[18:05] <cwayne> mhr3_, tried that
[18:05] <cwayne> mhr3_, i enabled the plguin by setting the gsettings key com.canonical.mediascanner metadata-sources
[18:06] <mhr3_> hm, didn't even know it has such a thing :)
[18:06]  * mhr3_ not too familiar with mediascanner
[18:06] <cwayne> mhr3_, i have been looking all over the place to fix this :P
[18:06] <mhr3_> cwayne, so the lastfm plugin isn't working for you?
[18:07] <cwayne> mhr3_, the issue is we're doing a demo, and the phones don't have sim cards
[18:07] <cwayne> so there's no network we can rely on on first boot
[18:07] <cwayne> and enabling wifi and rebooting doesn't seem to fix it, so we'd like to be certain it works locally
[18:07] <mhr3_> cwayne, you could just embed the art into the mp3s
[18:07] <mhr3_> surely you'll find an app that can do that
[18:08] <cwayne> mhr3_, i think it already is in the id3 tag
[18:08] <mhr3_> then it should just work
[18:08] <cwayne> mhr3_, should, yes :)
[18:08] <cwayne> yeah if i play it locally on my machine in like vlc it picks up the album art from the id3
[18:09] <cwayne> mhr3_, maybe it needs to be set differently somehow?
[18:10] <mhr3_> cwayne, dunno really, it should pick up embedded art
[18:11] <cwayne> mhr3_, do you know what tag it should use?
[18:11] <cwayne> this one seems to use FRONT_COVER Image:
[18:11] <mhr3_> cwayne, what you could try is to edit the mediascanner db by hand, then you could set the path to the albumart straight away
[18:12] <mhr3_> cwayne, you can open it with https://code.google.com/p/luke/downloads/detail?name=lukeall-1.0.1.jar&can=2&q=
[18:13] <cwayne> mhr3_, hm, i could try that, let me try to tag it differently
[18:13] <cwayne> mhr3_, i saw this int he mediascanner.log: mediascanner-service[1651]: ERROR error/property: Unexpected value type GstSample in GStreamer tag for "cover" field
[18:13] <mhr3_> can't guarantee that it can actually edit the db, but it should
[18:14] <mhr3_> cwayne, sorry need to catch train, bbl
[18:14] <mhr3_> already missed the one an hour ago :P
[18:20] <rsalveti> gema: plars: how are you guys rebooting the phone in the lab?
[18:20] <rsalveti> adb reboot or just reboot?
[18:24] <lenios> does anybody know if (full disk) encryption is planned in a future version?
[18:24] <plars> rsalveti: reboot
[18:24] <plars> rsalveti: adb shell reboot I believe
[18:24] <rsalveti> plars: right, that's why the clock is always wrong when booting the device
[18:25] <rsalveti> plars: hwclock-save gets called during shutdown
[18:25] <rsalveti> saving the timestamp to the hardware clock
[18:25] <rsalveti> adb reboot breaks that logic
[18:26] <rsalveti> so if you want sane timestamps at ~/.cache or ~/.config, we need to change that to do the proper reboot
[18:26] <rsalveti> or change the hwclock-set logic
[18:26] <plars> rsalveti: I don't do adb reboot
[18:26] <plars> rsalveti: adb *shell* reboot
[18:27] <plars> so we should be ok wrt that right?
[18:27] <rsalveti> plars: right, sorry, my brain is used with adb reboot :-)
[18:27] <rsalveti> plars: in theory yes
[18:27] <plars> rsalveti: heh
[18:27] <rsalveti> plars: checking now, flashing 78 again
[18:28] <rsalveti> noticed that reboot too a while to actually happen in mako
[18:28] <rsalveti> something might still be broken in the shutdown logic
[18:29] <rsalveti> plars: is there log or similar in the dashboard where I could check the time it's currently taking for a reboot to take place?
[18:29] <rsalveti> after adb shell reboot
[18:32] <plars> rsalveti: hmm, don't think so
[18:32] <plars> rsalveti: just messing with it locally, I've seen a few times where I could swear I go into a shell and had typed reboot already, but several minutes later, it's still up
[18:32] <plars> rsalveti: when I type reboot again it goes down though
[18:33] <plars> rsalveti: need to try it again... also with mir it seems to take a little longer before I have a UI, but I don't have any exact timings
[18:33] <rsalveti> plars: right, it seems adb gets restarted as well
[18:34] <rsalveti> run adb shell reboot; adb shell
[18:34] <rsalveti> it'll work right after
[18:48] <alecu> lool, ping
[18:50] <alecu> we've found a server side bug that prevents installing apps when the u1 user has never logged into sca
[18:50] <alecu> this happens only on image 79
[18:51] <alecu> the server side bug is this: https://bugs.launchpad.net/software-center-agent/+bug/1234872
[19:01] <rsalveti> plars: gema: worked fine with adb shell reboot:
[19:01] <rsalveti> rsalveti@evatp:~$ adb wait-for-device shell dmesg | grep rtc-pm8xxx
[19:01] <rsalveti> [    1.924797] rtc-pm8xxx rtc-pm8xxx: rtc core: registered pm8xxx_rtc as rtc0
[19:01] <rsalveti> [    2.298794] rtc-pm8xxx rtc-pm8xxx: setting system clock to 1970-10-02 18:00:32 UTC (23738432)
[19:01] <rsalveti> got on-line
[19:02] <rsalveti> date was then correct
[19:02] <rsalveti> adb shell reboot
[19:02] <rsalveti> rsalveti@evatp:~$ adb wait-for-device shell dmesg | grep rtc-pm8xxx
[19:02] <rsalveti> [    1.933160] rtc-pm8xxx rtc-pm8xxx: rtc core: registered pm8xxx_rtc as rtc0
[19:02] <rsalveti> [    2.341339] rtc-pm8xxx rtc-pm8xxx: setting system clock to 2013-10-03 19:00:56 UTC (1380826856)
[19:02] <rsalveti> so yeah, as long we're using adb shell reboot for everything, we're fine
[19:02] <rsalveti> but let me also fix the adb shutdown here
[19:02] <rsalveti> keeps respawing
[19:04] <RyDeR_> anyone know what version i need to download for the nexus 4?
[19:12] <cyphermox> awe_: I'm looking at the commit log for NM since I also want to update to a new minor version ...
[19:13] <cyphermox> awe_: I wonder if the routing issue you found could be caused by http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-0-9-8&id=764f0e21d2175f578b41f8197116c882799ae4d3
[19:13] <cyphermox> I mean, fixed by
[19:13] <cyphermox> I'll prepare a package with the full updates, so we can test this
[19:13] <awe_> cyphermox, sounds promising
[19:13] <awe_> cyphermox, ack
[19:14] <awe_> by the way, got distracted by davmor2's crash bug...  attached comes next
[19:14] <cyphermox> np
[19:14] <awe_> that said, found the crash bug
[19:14] <awe_> ;)
[19:14] <cyphermox> there's enough stuff to review in the new NM minor, just to check that it's all bugfix, to keep me busy for the afternoon
[19:17] <cyphermox> awe_: btw this will be https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1234887
[19:17] <cyphermox> 0.9.8.6 was also released but it pretty much only adds support for BlueZ 5, which we don't use yet
[19:17] <awe_> cyphermox, wow...that's a boatload of fixes
[19:17] <cyphermox> yeah
[19:18] <awe_> cyphermox, I think we should get a bunch of folks to test
[19:19] <cyphermox> yes
[19:23] <rsalveti> cyphermox: should be safe, but a medium/high risk update
[19:30] <kgunn> ricmm: ping
[19:31] <kgunn> ricmm: got thomi on a hangout...we'd like to talk powerd/wakelock stuff wrt autopilot
[19:42] <Nickbertus> hey, i am interrested in ubuntu touch for my nexus 7. am i able to install all *.deb on my tablet?
[19:49] <ricmm> kgunn: sorry, missed that ping
[19:49] <ricmm> thomi: kgunn anything you guys still need my input on?
[19:55] <mfisch> When I click on a scope result, instead of opening the browser on top, I get shown the app I was just using.
[19:55] <mfisch> For example, open the dialer, go back to scopes. Click on something. Dialer opens again and browser is opened as well but is not shown
[19:55] <mfisch> cwayne: ^
[19:57] <mfisch> cwayne: can you repro that?
[19:57] <thomi> ricmm: is there a way to prevent powerd form blanking the screen as the phablet user?
[19:57] <mfisch> thomi: you need to be root
[19:57] <mfisch> thomi: sudo powerd-cli active will do it though
[19:58] <thomi> yeah, but then I need to enter a password, and I can't do that from autopilot :-/
[19:58] <thomi> ahh well
[19:58] <popey> powerd-cli display on &
[19:58] <ricmm> mfisch: cant he register as a client?
[19:58] <popey> that works doesn't it?
[19:58] <ricmm> mfisch: and thus need to ack the power down state before its executed
[19:58] <mfisch> popey: as root it works
[19:58] <popey> ah
[19:58] <ricmm> I thought that was the whole point of the client API
[19:59] <mfisch> ricmm: sure but even that's on the system bus
[19:59] <cwayne> mfisch, need to reinstall, h/o
[19:59] <mfisch> ricmm: the ack has a timeout
[19:59] <mfisch> you cant block by not-acking
[19:59] <ricmm> ah, a timeout
[19:59] <ricmm> thomi: question, riht now you dont really do anything special to prevent sleep under SF
[19:59] <mfisch> mhr3_: hey do you know that the More Suggestions isn't shown if you boot the phone w/o wifi setup?
[19:59] <mfisch> mhr3_: is that a filed issues?
[19:59] <ricmm> thomi: why do you need to under Mir? on my phone gallery-app suite didnt sleep because it kept getting input
[20:00] <ricmm> powerd will reset the timeout as long as input keeps flowing
[20:00] <mfisch> yep
[20:00] <mfisch> you could change the timeout value to something like 1 hour but all that gsettings stuff changed
[20:00] <thomi> right, but the unity8 test suite needs to stop and start unity8 often, and that usually takes longer than the timeout
[20:01] <mhr3_> mfisch, "do you know you can't get data from internet when not connected to wifi?" yes, i'm aware of that :P
[20:01] <cwayne> mhr3_, hey, so i verified that my mp3 does have the cover image embedded, still not getting the album art in the music scope
[20:01] <cwayne> any logs i should look for?
[20:02] <mhr3_> cwayne, none that i know of that would be useful
[20:02] <ricmm> thomi: mfisch this is why we need a clear distinction between dev/user modes, heh
[20:02] <mfisch> mhr3_: sure, but after I connect to wifi, you should load it
[20:02] <ricmm> if such a split was in place we could provide a wakelock interface for clients to completely block suspend
[20:02] <mhr3_> mfisch, unimplemeted
[20:02] <mhr3_> yet
[20:02] <mfisch> mhr3_: sure, so I filed it: https://bugs.launchpad.net/unity-lens-applications/+bug/1234913
[20:02] <thomi> ricmm: well, I'm asking the CI guys to run 'powerd-cli active' as root, so we'll see if that solves naything
[20:02] <mfisch> mhr3_: I know we wont get that anytime soon
[20:03] <thomi> if we do get a way to do it as the phablet user, that would be great
[20:03] <mhr3_> mfisch, all you need to do is really do a search and get rid of it
[20:03] <mfisch> mhr3_: interesting work-around, thanks
[20:03] <mhr3_> mfisch, no need for reboot
[20:03] <mfisch> maybe I should get a better sim card and not have this issue ;)
[20:03] <mfisch> trying to save the company some money
[20:03] <ricmm> thomi: well thats the thing, we dont really want the normal user to be able to hold the phone awake
[20:03] <mhr3_> heh
[20:04] <ricmm> thomi: im sure CI can run it, I forget we actually control these phones
[20:04] <ricmm> ;)
[20:04] <ricmm> thomi: about the -fullscreen issue... can we get rid of that in unity8-autopilot?
[20:04] <cwayne> mhr3_, well crap, so what should i try then? differeny mp3 maybe?
[20:04] <mhr3_> cwayne, or edit the db
[20:04] <ricmm> thomi: for running on device I mean
[20:04] <cwayne> mhr3_, well it'd be nice to get a real fix too :)
[20:05] <mhr3_> cwayne, sorry no people who know mediascanner properly are around
[20:05] <cwayne> mhr3_, fair enough, wasn't sure if maybe it was a unity problem as well
[20:06] <mhr3_> cwayne, unlikely
[20:06] <thomi> ricmm: sure - it's not needed then?
[20:07] <ricmm> thomi: I dont even know what it does, but we dont use it to run the real unity8 on the phone
[20:07] <thomi> veebers: that's something for you ^^^
[20:07] <thomi> veebers: unless you're busy, in which case I can do it
[20:08] <veebers> thomi: I can check it out, just reading backlog to see what _it_ is :-)
[20:08] <cwayne> mhr3_, sorry do you happen to have that link again for the program to edit the db?
[20:08] <thomi> veebers: on the device, don't pass -fullscreen to unity8
[20:08] <thomi> veebers: also, while you're in there, perhaps you can fix this as well? http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/4539/unity8-autopilot/449681/
[20:08] <mhr3_> cwayne, https://code.google.com/p/luke/downloads/detail?name=lukeall-1.0.1.jar&can=2&q=
[20:09] <thomi> veebers: that looks to me like we're passing a number or something to launch_test_application
[20:09] <veebers> thomi: ah I see. Yeah that's a quick change in the test code. I'll get my phone reassembled and try it out
[20:09] <veebers> thomi: yes that one is on my list of todo too
[20:10] <thomi> awesome
[20:10] <cwayne> mhr3_, thank you
[20:13] <mfisch> cwayne: is this the Home Scope -> Home bug?  https://bugs.launchpad.net/sevilerow/+bug/1223635
[20:14] <cwayne> mfisch, no
[20:14] <cwayne> i dont know what that one is
[20:14] <mfisch> alecu: installing apps is working for me in #79, is it fixed on the server?
[20:14] <mfisch> cwayne: I think thats a translation bug
[20:15] <alecu> mfisch: have you published any click package?
[20:15] <mfisch> alecu: no, not to the store
[20:15] <alecu> mfisch: well, you might have logged in at least one in https://myapps.developer.ubuntu.com/dev/ or some related site
[20:16] <mfisch> alecu: yes, I've signed in to that and tried to publish an app a couple years ago
[20:16] <alecu> mfisch: can you try removing your u1 account from your device, and logging in with a brand new account?
[20:16] <mfisch> alecu: sure
[20:16] <alecu> mfisch: I think that with a brand new account you will find that it breaks.
[20:19] <lool> alecu: Ok, what's the fix?
[20:19] <mfisch> alecu: I'm happy to help test when you need someone
[20:20] <karni> Question - why do we use grid units (gu) if below 1gu we advise use of density independent pixels (dp)?
[20:20] <karni> Are our dip's similar to what is dip on Android?
[20:21] <alecu> lool: the fix is being worked on by the servers guys (beuno's team)
[20:21] <lool> ok
[20:21] <alecu> lool: the workaround is to log in at least once into https://myapps.developer.ubuntu.com/dev/
[20:22] <alecu> (using any browser, can even be in a different phone or computer)
[20:22] <beuno> it should be an hour or two until it hits production, I hope
[20:22] <alecu> mfisch: great, thanks. I'll let you know when the fix lands on the servers
[20:24] <lool> alecu: ok thanks
[20:24] <lool> beuno: great
[20:25] <karni> Shall I take my gu/dp/dip question to ubuntu-phone instead? :)
[20:26] <cwayne> mhr3_, hm, any idea how to use that? i get an error if i do java -jar lukeall_1.0.1.jar
[20:26] <mhr3_> cwayne, eh? works fine here if i do that
[20:27] <mhr3_> $ java -version
[20:27] <mhr3_> java version "1.7.0_17"
[20:27] <mhr3_> Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
[20:27] <mhr3_> Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
[20:27] <mhr3_> cwayne, hope you're not running it on the phone :)
[20:27] <mhr3_> swing wouldn't have mir backend yet
[20:28] <cwayne> noo im not
[20:28] <mhr3_> cwayne, what's the error?
[20:28] <cwayne> mhr3_, nm, updated my java and now it's working
[20:29] <mhr3_> cool
[20:35] <mhr3_> tedg, the race you found with upstart isn't going to fix the hud issue though, is it?
[20:35] <tedg> mhr3_, I believe it will
[20:35] <mhr3_> tedg, wasn't your issue about being activated too early
[20:36] <mhr3_> basically before dbus?
[20:36] <tedg> mhr3_, Well, before dbus was ready.
[20:36] <mhr3_> tedg, but there's no way that could happen with hud, cause it's dbus activated in the first place
[20:37] <tedg> mhr3_, Hmm, good point.
[20:38] <tedg> Hopefully we'll get a crash file for HUD here soon...
[20:38] <mhr3_> tedg, can you remind me why we're doing that massive hack anyway? let's just do normal dbus activation for hud
[20:38] <mhr3_> not the upstart over dbus craziness
[20:39] <mhr3_> and yes, i'm aware that it should work... but apparently it doesn't
[20:39] <tedg> mhr3_, Well, the hack was supposed to be temporary until upstart dbus activation got added back.  But then it worked well enough that feature got delayed.
[20:39] <mhr3_> but it doesn't work well enough
[20:39] <tedg> I don't think the issue is related to that though.
[20:40] <mhr3_> i believe it is
[20:40] <tedg> Why?
[20:40] <mhr3_> the upstart job doesn't have the dbus env var set
[20:40] <mhr3_> for reasons unknown
[20:40] <mhr3_> let me restate - *sometimes* it doesn't have it
[20:41] <tedg> Seems to me that's the bug...
[20:41] <tedg> But we should be able to see that once we get a crash variable.
[20:41] <tedg> crash file
[20:41] <tedg> Which we haven't gotten.
[20:42] <mhr3_> tedg, apparently ogra_ sees it on the device quite regularly
[20:42] <mhr3_> ask him :)
[20:44] <mhr3_> tedg, hm, any idea what this is
[20:44] <mhr3_> $ stop hud
[20:44] <mhr3_> stop: Unknown instance:
[20:44] <mhr3_> oh it wasn't running
[20:46] <shann> hi
[20:47] <shann> I think port Ubuntu touch for my device Archos 50 Platinium
[20:47] <shann> But i try to understand guide
[20:50] <shann> I need to buid android driver from http://phablet.ubuntu.com/gitweb and build image
[20:50] <shann> and finally flash device with build image (recovery, data, boot)
[20:52] <tedg> mhr3_, I'm curious if in those situations whether we're getting more than one dbus session bus.
[20:53] <tedg> mhr3_, I think for instance QDBus will start one if it doesn't have.
[20:53] <mhr3_> yea, perhaps
[20:53] <mhr3_> tedg, http://people.canonical.com/~ogra/ubuntu-touch/bootchart-mako.png
[20:54] <tedg> I wish bootchart made SVGs
[20:54] <tedg> So then you could search them.
[20:54] <mhr3_> tedg, the odd thing there is that hud is running for quite a while... shouldn't it realize that it can't connect much quicker?
[20:55] <mhr3_> 6seconds and on mako... hm
[20:55] <tedg> 6 sec?
[20:55] <tedg> Looks like 1 to me.
[20:56] <seb128> tedg, the small lines are 1s, the thick ones 5s
[20:56] <tedg> oh
[20:56] <seb128> tedg, hud-service is running for like 6s on that chart
[20:57] <tedg> So this bootchart is for 65s ?
[20:58] <tedg> Ah, found the key at the top... it is.
[20:58] <seb128> yes
[20:58] <cwayne> sergiusens, how often is phablet-tools released in saucy?
[20:58] <seb128> tedg, you guys call scale units "key"? (just curious)
[20:59] <sergiusens> cwayne, as soon as you do the paperwork
[20:59] <sergiusens> cwayne, so we try and `bundle a bunch of fixes together
[20:59] <sergiusens> cwayne, on #ubuntu-ci-eng
[20:59] <tedg> seb128, No, that's probably a scale.  A key would be more like a small table in the corner describing the colors or something like that.
[20:59] <seb128> tedg, ok ;-)
[21:01] <mhr3_> seb128, don't teach tedg english! :)
[21:01] <seb128> mhr3_, can I teach him french? ;-)
[21:01] <tedg> Does dbus-daemon create multiple processes?
[21:02] <mhr3_> tedg, from the bootchart i'd say yes, but no idea why :)
[21:02] <tedg> There seems to be at least three.
[21:03] <shann> y aurait-il des personnes qui parle francais sur ce canal
[21:03] <seb128> tedg, mhr3_: those charts have dbus-daemon being a zombie, I don't get why
[21:03] <seb128> shann, on dirait que oui ;-)
[21:03] <mhr3_> seb128, yes, that is a mystery :)
[21:03] <seb128> tedg, mhr3_: (grey is the color for zombie)
[21:03] <shann> si oui, et si cela est possible de m'expliquer la marche à suivre pour porter ubuntu touch sur un smartphone
[21:03] <tedg> I'll write it off as HUD being attacked by zombies
[21:03]  * tedg writes libshotgun
[21:04] <mhr3_> lol
[21:04] <mfisch> there's no way zombies could figure out dbus
[21:04] <seb128> shann, https://wiki.ubuntu.com/Touch/Porting
[21:04] <shann> seb128, en effet j'ai un peut de mal à comprendre le wiki en anglais
[21:05] <seb128> shann, je ne suis pas sûr qu'il y ait assez de francophone sur le channel pour répondre aux questions techniques :/
[21:06] <shann> mes questions ne sont pas directement technique mais plutôt générale
[21:06] <tedg> Really odd that there are two ssh-agents there as well.
[21:06] <tedg> Looks like one is started before Upstart and one by Upstart
[21:07] <shann> de ce que j'ai compris, il faut que je créer le répertoire kernel et device pour mon smartphone
[21:07] <seb128> tedg, not sure, maybe it's a fork of the same process...
[21:08] <seb128> tedg, the data file from bootchart has more details on the pid etc that the image, if you want to check out the details
[21:08] <tedg> seb128, Yeah, I think we might have to go down that route if today's dbus fix doesn't help things.
[21:09] <mhr3_> it won't
[21:09] <mhr3_> :P
[21:09] <seb128> don't worry, mhr3_ is on it
[21:09] <mhr3_> well.. not with hud anyway
[21:09] <shann> seb128: ce qui m'embrouille c'est que d'un côté sur le wiki de cyanogenmod  il explique comment 'porter' celui-ci sur un smartphone, et d'un autre Ubuntu touch ne contient que le nécessaire.
[21:09] <seb128> he's going to blame desrt in a few minutes
[21:09] <tedg> Hopefully we can cut our session buses from 4 to 1 :-)
[21:09] <seb128> mhr3_, right? ;-)
[21:09] <mhr3_> seb128, of course, everything is desrt's fault :)
[21:10] <mhr3_> seb128, he was supposed to make systemd work on ubuntu, no? ;)
[21:10] <tedg> What I really want is a crash file, but I didn't realize we don't have any arm retracers running.
[21:10] <seb128> shann, je ne connais pas les détails des ports, et la plupart des personnes ici de parlent pas français ...
[21:10] <mhall119> nice work on the click package update app
[21:10] <mhall119> whomever wrote it
[21:10] <mhr3_> tedg, but, but, we need to use those multicore cpus for something
[21:11]  * tedg puts mhr3_ on rewriting dbus daemon in Go
[21:11] <shann> je vais essayer de lire et relire les docs en espérant bien comprendre ce qui est dit.
[21:11] <mhr3_> sounds like fun :)
[21:12] <mhr3_> although i'm not sure if i could look at go code for more than 10minutes at a time :)
[21:12] <cyphermox> rsalveti: I agree, medium risk, but still it needs a lot of careful testing -- lots of small bugfixes, and this will affect everyone, not just touch :)
[21:12] <cwayne> mhr3_, weird, i dont even see a field for cover art in the lucene dbs
[21:12] <mhr3_> cwayne, add it :)
[21:12] <mhr3_> cwayne, guess that's why it doesn't work
[21:14] <mhr3_> cwayne, http://imgur.com/3qBGDP6
[21:16] <cwayne> mhr3_, nm i found it eventually, was just a bit confused
[21:17] <mhr3_> cwayne, you need to replace the first one (highest res)
[21:18] <mhr3_> one the first is read by grilo
[21:18] <cwayne> mhr3_, can i just plant a file:// url int here?
[21:18] <mhr3_> cwayne, sure
[21:21] <rsalveti> cyphermox: yeah
[21:27] <mhall119> system-image-cli is giving me this:
[21:27] <mhall119> The next online UDS has been announced!  Once again there will be a track dedicated to Application Development.  New this cycle is a track dedicated to Design as well.
[21:27] <mhall119> bad paste
[21:27] <mhall119> [systemimage] Oct 03 21:27:01 2013 (6316) Group download reactor done (err/cancel)
[21:27] <mhall119> ^^ that
[21:28] <mhall119> huh, finally finished
[21:46] <tinti> does anybody know where can I get ubuntu touch nexus 7 kernel?
[21:49] <Tassadar> tinti: http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_kernel_asus_grouper.git;a=summary
[21:49] <Tassadar> branch phablet-10.1
[21:49] <sergiusens> tinti, just pull-lp-source it
[21:49] <tinti> Tassadar: thank you so much
[21:50] <tinti> can I use git?
[21:50] <sergiusens> timchen119, for what Tassadar gave you yes
[21:51] <sergiusens> although prefer the phablet-saucy branch
[21:51] <tinti> thank you guys :)
[21:51] <Tassadar> sergiusens: there isn't one
[21:52] <sergiusens> Tassadar, right..
[21:54] <tinti> btw I have rebuild the kernel using Cyanogenmod and I am facing some issues to make the GUI recognize the touch screen
[21:54] <tinti> I checked with evtest and it works fine but I get the pointer in the main screen and the touch does not works any idea?
[21:56] <alecu> The app installation issue on image 79 has been fixed on the server, so everybody should be able to install click apps again. Please ping me if you find any related issues.
[21:56] <Tassadar> tinti: you've tried to use CM kernel with Ubuntu Touch?
[21:56] <Tassadar> that's not gonna work, ubuntu needs some changes in kernel
[21:56] <tinti> yes
[21:57] <alecu> mfisch: perhaps you want to test that ^
[21:57]  * tinti I suspect but did not find the kernel :)
[21:57] <alecu> mfisch: to test it, flash image 79, delete your u1 account in system settings, and then create a new u1 account from scratch on the device and try installing some app.
[21:57] <mfisch> alecu: testing now
[21:59] <mfisch> alecu: Just installed an app using a new account
[21:59] <mfisch> alecu: playing word chain now
[22:00] <alecu> yay!
[22:00] <alecu> mfisch: thanks! :-)
[22:00] <mfisch> alecu: np
[22:02] <AskUbuntu> why doesn't the phone find any carriers under cellular? | http://askubuntu.com/q/353373