[00:34] <thomi_> sergiusens: sorry, I was AFK - still need an answer to your question?
[00:36] <sergiusens> thomi_, np, sort of yeah, not sure why we need to know the resolution, only thing I found in the ap code was something about multimonitor
[00:36] <thomi_> sergiusens: it's for the touch devices
[00:37] <thomi_> sergiusens: need to know the screen resolution so we can create a touch device with the appropriate properties
[00:37] <sergiusens> thomi_, right
[00:37] <sergiusens> thomi, forgot about that one over the weekend
[00:38] <sergiusens> thomi, my new problem is the emulator; it's a 'generic' device with multiple possibilities wrt to resolution
[00:38] <sergiusens> thomi, I guess that would be fixed once you can query the platform again, right?
[00:39] <thomi> sergiusens: right... I can see that would be a problem
[00:41] <thomi> sergiusens: sounds like  we need a generic platform interrogation service
[00:42] <thomi> so we can tell things like screen resolution, SS support etc.
[00:42] <thomi> something that's a bit more dynamic than the build propertie sfile
[00:43] <sergiusens> thomi, yeah, I know I can get the resolution with an egl call, but not sure you want that directly
[00:43] <thomi> sergiusens: I thought we had a good solution with the platform API & python bindings. The only problem was that nobody was prepared to maintain the python bindings
[00:44] <sergiusens> thomi, yeah, and v2 is coming shortly
[00:44] <sergiusens> thomi, perhaps an autopackage test would solve that
[00:44] <thomi> sergiusens: maybe, but the specific issue I'm referring to was supporting python 3 :)
[00:45] <thomi> but yeah, I'm sure we can get better notificaiton for when something crashes
[00:45] <sergiusens> thomi, what's the biggest problem with migrating to 3?
[00:47] <thomi> sergiusens: nobody was willing to do the work - it was a simple fix, just a few #ifdef's needed here and there...
[00:48] <thomi> sergiusens: as a stop-gap, we dropped the platform-api alltogether, and inserted the hack in autopilot... which I'm not too happy about (can you tell? :P )
[00:48] <sergiusens> thomi, I can tell
[00:48] <itsahemi> do i need to use linux to install this ubuntu on my nexus 7?
[00:48] <thomi> sergiusens: :)
[00:49] <thomi> sergiusens: I'm not really that upset - if someone fixed it properly, I'd owe them a beer or two
[00:49] <sergiusens> thomi, I'm shuffling between things here; but I'll see if I can get something done wrt before the break
[01:58] <lisbeth> Anybody home?
[07:59] <dholbach> good morning
[10:20] <Laney> (how) can I get autopilot to look in the cwd for tests?
[10:21] <Laney> ah, I got it, I needed to be one level up
[10:36] <pitti> right, usualy something like "autopilot run tests" if there is a tests/__init__.py
[10:37] <sil2100> tvoss: hello, I have some questions related to process-cpp release
[10:38] <tvoss> sil2100, sure shoot
[10:38] <sil2100> tvoss: on the landing pipeline I see that as a 'test-case', I should run a build of platform-api with the new process-cpp to have the unit tests ran - but hm, I don't see platform-api deping on the process-cpp libraries?
[10:39] <tvoss> pitti, ^ can you help here?
[10:39] <pitti> sil2100: right, landing platform-api tests is blocked by getting process-cpp in
[10:39] <pitti> sil2100: that's https://code.launchpad.net/~pitti/platform-api/test-backend/+merge/198098
[10:40] <sil2100> tvoss: Ah
[10:40] <pitti> sil2100: but that will fall apart due to this bug in process-cpp (this pretty much completely breaks the package ATM)
[10:40] <pitti> sil2100: so you can run tests from that branch
[10:40] <pitti> sil2100: (merely bzr bd -- -b will build and run tests)
[10:40] <sil2100> pitti: ah, so building this platform-api branch with the latest process-cpp from trunk, yes?
[10:40] <pitti> sil2100: correct; that's why I'm eager to land this (thanks for taking care of it!)
[10:41] <sil2100> pitti: ok, then I'm testing this and releasing - of course process-cpp without this platform-api branch landed is 'safe' to release by itsown, right? :)
[10:41] <sil2100> Just making sure
[10:41] <pitti> sil2100: right, it's a prerequisite
[10:42] <pitti> sil2100: it's been broken for quite a while, so apparently not much other stuff is using libprocess-cpp
[10:42] <sil2100> Awesome then
[10:42] <sil2100> Thanks for the info, moving on then ;)
[10:42] <pitti> sil2100: i. e. adding tests to platform-api is blocked by process-cpp, but not the other way round
[10:42] <pitti> \o/
[10:45] <davmor2> Morning all
[10:51] <sil2100> pitti: ok, so the code compiles fine and tests pass, but it seems that the package fails to build due to symbols file mismatch
[10:52] <pitti> sil2100: oh, which one? I've been building process-cpp quite a lot, worked fine
[10:52] <pitti> (and platform-api, too of course)
[10:53] <sil2100> pitti: the platform-api branch, when using the latest process-cpp from trunk
[10:53] <sil2100> pitti: I get a biiiig symbols diff, mostly with leaked out boost symbols
[10:53] <pitti> sil2100: right, I get the symbols diff, too, but it builds
[10:54] <pitti> (no idea about the symbols; they aren't even demangled)
[10:54] <sil2100> pitti: yes yes, everything else is fine besides these symbols ;) Just making sure it's a known thing
[10:54] <sil2100> But I guess all is fine with process-cpp so I'll publish it
[10:54] <pitti> sil2100: right, I confirm that issue
[10:58] <tvoss> sil2100, pitti process-cpp should not leak symbols, its default visibility is hidden and it even has -fvisibility-inlines-hidden
[11:00] <sil2100> tvoss: hmm... but it seems that somehow it does, as now I see only process-cpp depends on boost here
[11:00] <tvoss> sil2100, can you pastebin the symbols please?
[11:00] <sil2100> tvoss: sure, one moment
[11:01] <sil2100> http://paste.ubuntu.com/6560765/
[11:02] <tvoss> sil2100, that's from platform-api, right?
[11:02] <sil2100> tvoss: right - but from what I see platform-api does not use boost in any moment, besides from process-cpp, right?
[11:03] <tvoss> sil2100, it does, implicitly via the location service
[11:03] <tvoss> sil2100, so symbols are fine
[11:04] <sil2100> tvoss: oh, so these are from location-service? Since I saw platform-api building fine before in the daily-build PPA, without any symbol file diff
[11:06] <sil2100> I wonder why I can't build platform-api now... let me downgrade process-cpp and check if it helps
[11:06] <sil2100> Actually hmmm, process-cpp is not used in platform-api trunk, so it's unrelated
[11:07] <sil2100> And it builds fine in daily-build, so I guess all is ok
[11:20] <Laney> how do I click an option in an ItemSelector with autopilot?
[11:21] <Laney> even better, is there a reference for interacting with the sdk widgets?
[11:23] <timp> Laney: we have autopilot emulators for UITK components. For TabBar, for example it has a function switch_to_next_tab()
[11:24] <timp> Laney: so that approach would "solve" your issue, except that the emulators are not complete yet. We don't have it for the ItemSelector
[11:25] <Laney> timp: aha, I see
[11:25] <Laney> I can poke the backend to change it if needed for now
[11:26] <timp> yeah, the problem with that is when the implementation of the ItemSelector would be changed, your tests will break
[11:26] <timp> but for now it would work, and I don't see another way
[11:26] <Laney> I meant the backend in ubuntu-system-settings
[11:26] <Laney> but what do you mean?
[11:27] <timp> I thought you meant to somehow get the components representing the options in the OptionSelector, but that is quite dependent on the current implementation
[11:27] <Laney> oh right, I have no idea how to do that :-)
[11:28] <Laney> it's controlled by a property so I can change that over dbus
[11:28] <timp> ahh. you change the property that the ItemSelector represents
[11:28] <Laney> yeah
[11:29] <Laney> I'll get into a problem on the next page, but at least I can write a few tests for this stuff
[11:31] <timp> Laney: ok.
[11:31] <timp> Laney: I reported this bug https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1260285
[11:31] <Laney> thanks for the hints
[11:31] <Laney> cool, subscribing
[12:16] <pr0teus> there is whatsapp for ubuntu-touch?
[12:16] <beuno> pr0teus, not at the moment, no
[12:20] <pr0teus> and what is the best hardware to try out ubuntu-touch?
[12:22] <xnox> what is AUTOMOC and how to use it with CMake in Qt5 ?
[12:22] <pr0teus> i have an experia u, but it only has 512mb of ram i'm note sure if i could install ubuntu
[12:22] <xnox> bzoltan or Mirv: maybe you know ? " what is AUTOMOC and how to use it with CMake in Qt5 ?"
[12:23] <bzoltan> xnox: no idea
[12:24] <xnox> Laney: any idea on how AUTOMOC is used in Qt5? I see that ubuntu-system-settings uses that integration?
[12:24] <Mirv> xnox: no idea aside from that the moc is Qt's sort of C++ extension, so automoc would then handle the meta-object compilations automatically I guess
[12:24] <Mirv> on a lower level, I don't know much about how it works
[12:24] <Laney> xnox: no idea, Satoris wrote the cmake stuff for us
[12:25] <xnox> Mirv: right. it's failing for me with "No such file or directory, moc failed..."
[12:25] <Mirv> it allows the usage of slots/signals
[12:26] <Mirv> I haven't seen that, so I don't know what would be the usual fix
[12:47] <ffelgenh> Does anybody know, if there are any plans for 14.04 to implement some kind of switch, if a bigger display
[12:47] <ffelgenh> will be connected to a smartphone (Nexus 4 for example), the operating mode is switching to tablet mode?
[12:49] <timp> ffelgenh: we are already working on making the same app work on phone/tablet/desktop, so apps would adapt to different screens
[12:49] <timp> ffelgenh: I don't know when it will/should be finished
[12:56] <ffelgenh> timp: this adaption will check the resolution or will it check the device type
[12:58] <ffelgenh> timp: because the use case i'm interested in is a phone connected to a bigger display ... checking the device type would'nt be enough
[13:00] <ogra_> ffelgenh, convergence is on the plan for 14.10 ... i doubt we will do much more than "by device type setup" during 14.04
[13:01] <timp> ffelgenh: it is not 100% worked out yet
[13:01] <ogra_> (which for tablets only means that the sidestage is enabled in landscape mode)
[13:01] <timp> I think apps should adapt to different screen resolutions. already you can see in some apps (or UITK examples) that they adapt to changes in window-size on the desktop
[13:01] <timp> but it is currently for the apps to do it correctly
[13:02] <timp> ffelgenh, ogra_ currently, if apps want to support different devices and they ask how that is supported in the UITK, we recommend them to use the screen size
[13:03] <timp> so I'm talking about the apps only
[13:03] <timp> unity and the stages that ogra_ talks about are probably a more complex story
[13:04] <timp> ogra_: so for that you're right, 14.10 :)
[13:09] <ffelgenh> timp, ogra_ thx for explaning those different concepts
[13:28] <dragonkeeper> hi im looking at kernel configs , anyone know what driver is used for the celluar / gps
[13:28] <pitti> tvoss: now that process-cpp is in, I made the necessary changes to the branch and set it to needs-review; it's ready from my POV now (https://code.launchpad.net/~pitti/platform-api/test-backend/+merge/198098)
[13:29] <tvoss> pitti, great, thanks for the update
[13:29]  * tvoss notes that typing struct SpaceVehicle is really cool :)
[14:13] <pitti> tvoss, ricmm: oh, I think the platform-api tests for https://jenkins.qa.ubuntu.com/job/platform-api-trusty-armhf-ci/6/console might fail for a similar reason like what we recently discussed with moving to g++-4.8
[14:13] <pitti> ricmm: I only get garbage for the functions that return floats; -- I guess I need to declare them with this pcs attribute magic?
[14:14] <tvoss> pitti, ricmm is off, but yes, the pcs stuff is required
[14:21] <pitti> tvoss: ack, works fine now; (nice to have tests :) )
[14:22] <tvoss> pitti, indeed :)
[14:30] <barry> dholbach: well, let's see how s-i 2.0.3 goes, now that it's finally gotten promoted ;)
[14:30] <sergiusens> barry, hey,was it you I had to bother when a udd branch got out of sync?
[14:30] <dholbach> barry, I commented on the bug
[14:30] <barry> sergiusens: wgrant perhaps?  not me i think :(
[14:31] <sergiusens> ack, thanks
[14:32] <jdstrand> chrisccoulson: hey, any thought on bug #1260137?
[14:33] <chrisccoulson> jdstrand, yeah, just about to take a look at that
[14:33] <chrisccoulson> jdstrand, we have an #oxide channel now btw
[14:33] <jdstrand> chrisccoulson: great! what do you think it is?
[14:33] <chrisccoulson> that's where me an oSoMoN are :)
[14:34] <chrisccoulson> jdstrand, i wonder if it's related to the fact that we haven't turned off the neon runtime detection
[14:34] <chrisccoulson> (we do turn that off in chromium)
[14:34] <jdstrand> I googled it last night
[14:34] <jdstrand> and saw that chromium had some logic for neon vs armv#
[14:35] <jdstrand> it was a year old though
[14:35] <jdstrand> and also failed the build, not just at runtime
[14:36] <jdstrand> so it seems plausible
[14:37] <jdstrand> rsalveti: curious, have you seen anything related to bug #1260137?
[14:37] <jdstrand> rsalveti: and hi btw :)
[14:38] <jdstrand> chrisccoulson: btw, you probably saw-- I decoupled packaging from uploading to ubuntu
[14:38] <jdstrand> chrisccoulson: (in the work items)
[14:40] <mterry> mzanetti, if the shell wanted to grab a screenshot for internal use and dump it to a file, would it want to use the new screenshotting support or can it just grab its mir surface and do that?
[14:41] <pitti> tvoss: jenkins gave its blessings now \o/ (I pushed another fix to clean up a warning, though)
[14:41] <mzanetti> mterry: what I'm working on is really apps
[14:42] <mzanetti> mterry: so not doing screenshots of unity itself
[14:42] <pitti> tvoss: should ricmm review this branch once he's back, or do you want to do it?
[14:42] <mterry> mzanetti, well, my question is about whatever's on the screen so might include apps
[14:42] <mterry> I assume the shell has that info
[14:42] <pitti> tvoss: (ATM you are set to be the reviewer, but that's mostly just because you replied first)
[14:43] <mzanetti> mterry: hmm... so what I'm doing is to grab the surface of the application (to be used in runningapplicationsgrid)
[14:43] <mzanetti> mterry: but you might want to try QQuickWindow::grabWindow()
[14:43] <tvoss> pitti, let me approve it, ricmm can then give the final top-approve
[14:44] <pitti> tvoss: ack, added a review request from Ricardo
[14:50] <mterry> ogra_, any objection to me adding /var/lib/lightdm to writable-paths?  (it's HOME for the greeter)
[14:56] <pmcgowan> mterry, I dont think hes around
[14:56] <mterry> boo
[14:56] <pmcgowan> maybe ask sergiusens
[14:56] <mterry> sergiusens, ^
[14:57] <sergiusens> mterry, if you are going to push anything, I just asked lool or xnox to review http://people.canonical.com/~sergiusens/lxc-android-config/
[14:58] <sergiusens> mterry, I can add it there, or if you don't mind sponsoring that, I don't have issues with you adding that
[14:58] <mterry> sergiusens, if you wouldn't mind adding:
[14:58] <mterry> /var/lib/lightdm                        auto                    persistent  none        none
[14:58] <mterry> sergiusens, to the writable-paths file...
[14:59] <sergiusens> mterry, will do
[14:59] <mterry> sergiusens, thanks!
[14:59] <sil2100> pitti: ah, forgot to mention - process-cpp is already released
[15:05] <pitti> sil2100: I noticed, thanks! platform-api works fine now in trusty
[15:07] <sergiusens> mterry, it's added
[15:08]  * mterry hugs sergiusens 
[15:09] <sergiusens> mterry, I want that in to see if I can get udd back as well; not using a vcs seems sad :-)
[15:10] <mterry> yeah  :-/
[15:14] <mpt> seb128, tedg, Laney, kenvandine: http://goo.gl/IPzwi0
[15:21] <seb128> mpt, thanks
[15:22] <pmcgowan> seb128, fyi I added a couple of bugs recently where multiple settings panels were opened
[15:23] <seb128> pmcgowan, I saw that, I need to test it, I don't think anything changed recently on our side that could create that
[15:23] <seb128> pmcgowan, I wonder if that's an url-dispatcher issue
[15:23] <pmcgowan> seb128, could be for the one from the pulldown
[15:23] <pmcgowan> I think the online accounts one is just thats its a separate app?
[15:23] <Laney> cno
[15:24] <seb128> tedg, do you have any idea about #1259973 ?
[15:24] <Laney> it's always been the case
[15:24] <seb128> pmcgowan, right, online accounts is a known issue
[15:24] <pmcgowan> vg
[15:24] <Laney> we just push onto the page stack; I don't think we ever got a clear answer as to the correct behaviour there
[15:25] <tedg> seb128, Huh, no.  Does it close in that case?
[15:26] <seb128> oh right
[15:26] <seb128> pmcgowan, what you describe in that bug is not a bug
[15:26] <pmcgowan> seb128, ah so its a feature
[15:26] <seb128> pmcgowan, you have settings open on cellular, you switch to wifi, back bring you where you were
[15:26] <pmcgowan> seb128, it was just not what I expected
[15:27] <seb128> right
[15:27] <pmcgowan> I will yeild to the usability gurus
[15:27] <seb128> as Laney said, we didn't get real clear guidance from design on that
[15:27] <seb128> if you get some we are happy to change the behaviour
[15:27] <seb128> thanks ;-)
[15:27] <pmcgowan> ok will copy the bug task to them
[15:27] <seb128> pmcgowan, oh, btw, in case you didn't notice we got webkitgtk dropping from the touch image recently ;-)
[15:28] <seb128> (gtk is still there, next to clean out)
[15:28] <pmcgowan> seb128, its the little things that make me happy ;)
[15:28] <pmcgowan> now gtk3?
[15:28] <seb128> ;-)
[15:28] <seb128> hehe
[15:28] <seb128> next!
[15:28] <Laney> g haters
[15:42] <barry> dholbach: hi.  we were looking at LP: # 1256229 and stgraber noticed something weird about your recovery log file
[15:42] <barry> dholbach: it claims the date is Wed Nov 20.  stgraber thought maybe your device isn't actually rebooting into recovery
[15:43] <barry> dholbach: no idea why that would be, but you can try to do this manually by issuing `reboot -f recovery`
[15:47] <sergiusens> oSoMoN, hey, popey has some results for notes running on mako that are not 100% pass
[15:47] <dholbach> barry, ok, let me try it
[15:47] <popey> oSoMoN: do you want bugs for these failures?
[15:49] <sergiusens> mterry, hey,lool is asking me if the lightdm persistence be temporary
[15:49] <dholbach> barry, ok, it rebooted, but everything seems to still be the same :/
[15:49] <sergiusens> *could be
[15:50] <lool> sergiusens, mterry: Basically we can make it writable without making it persistent; does it need to be persistent?  this implies backwards / forwards compat "forever"
[15:50] <dholbach> barry, shall I run "system-image-cli -b 0" now?
[15:50] <lool> as in, SD card with userdata might be kept across a reinstall of a newer or older version that the one that created the data
[15:50] <barry> dholbach: yes, then reboot -f recovery again.
[15:51] <dholbach> barry, all right, I'll let you know how it goes
[15:51] <lool> sergiusens: My device is currently semi-broken; I can't always deploy touch on it, and I'm not sure testing system-image level changes under emulator is great; otherwise good to go if at least 2 people booted with this (you + someone)
[15:51] <mterry> sergiusens, lool: well, it is a homedir, so not that different a contract from other homedirs.  For today, it can be temporary, but I have a feature or two I probably will need persistence for.  But can upgrade it when needed.  I was just looking ahead
[15:52] <mterry> Those features aren't finalized yet, so might as well play it safe with temporary
[15:53] <sergiusens> lool, /var/lib/bluetooth keeps track of all the pairings
[15:53] <lool> mterry: maybe it's worth having it persistnet for the desktop touch image?
[15:53] <lool> sergiusens: yeah, I guessed this would be the case; ok
[15:53] <lool> sergiusens: is the format stable in some way?
[15:54] <lool> sergiusens: basically if it never needs to change, it needs to change so that the new format works with old software and we need to add a boot hook to convert it
[15:54] <sergiusens> lool, hmmm; something for cyphermox or awe_
[15:54] <mterry> lool, I think even for desktop, that dir doesn't need to be persistent...  I'm trying to think if we ever store any gsettings for the greeter
[15:55] <sergiusens> lool, not sure if we are upgrading the bluetooth stack at all; but I'm guessing we'd need the same for ofono
[15:55] <sergiusens> lool, I'd say the software itself should know how to manage it's own config upgrades tough
[15:55] <sergiusens> though
[15:55] <awe_> sergiusens, what's the issue?
[15:56] <sergiusens> awe_, if files in /var/lib/bluetooth are stable and what's the case with bluez5
[15:56] <awe_> no bluez 5 for 14.04
[15:56] <sergiusens> awe_, when we do update though, do you know if the file formats change?
[15:57] <awe_> there's a schism between the pulseaudio devs & the bluez/ofono guys
[15:57] <awe_> re: how headset & handsfree are implemented
[15:57] <sergiusens> awe_, if they do, we will need to plan for that (same if stuff in /var/lib/ofono) change
[15:57] <awe_> sergiusens, sure...but that's something we'd tackle when we start working on the new version
[15:58] <awe_> sergiusens, pretty sure there's been no schema change to the ofono settings files
[15:58] <awe_> only additions
[15:58] <sergiusens> lool, well, in any case, /var/lib/bluetooth needs to be persistent
[15:58] <awe_> can't say the same about bluez, as I've never really been hands-obn
[15:58] <awe_> s/obn/on/
[15:59] <sergiusens> awe_, ack; seems fine, if we need config file update mechanisms, we will just need to plan for it
[15:59] <awe_> sergiusens, yea, I thought we had the same issue with /var/lib/ofono/<IMSI> dirs
[15:59] <lool> sergiusens: I'm just underlining the new contract this new software will operate under so that we get a chance to review the format of the data which cross the border  :-)
[16:01] <sergiusens> awe_, we do
[16:01] <sergiusens> lool, well we don't control bluetooth
[16:02] <sergiusens> lool, I don't know where it's going to go; but whenever it's updated some layer of adaptations will need to be pulled in
[16:02] <sergiusens> lool, I feel the android full on source model to be more attractive as days pass :-P
[16:05] <davmor2> rsalveti, awe_ , cyphermox: what did you do to ofono?  sms and 3g are down for me
[16:06] <cyphermox> it's been working.. tbh I avoided touching any of it ;)
[16:06] <davmor2> cyphermox: this is the latest image r62
[16:06] <sergiusens> lool, recap then; should I change lightdm to temporary? Can we keep bluetooth persistent?
[16:07] <cyphermox> bluetooth persistent?
[16:07]  * cyphermox gets highlighted :)
[16:08] <sergiusens> cyphermox, I pinged you like three times and you see the bluetooth highlight :-)
[16:09] <cyphermox> you did?
[16:09] <sergiusens> cyphermox, /var/lib/bluetooth
[16:09] <cyphermox> ahahah
[16:09] <sergiusens> cyphermox, fwiw http://people.canonical.com/~sergiusens/lxc-android-config/
[16:10] <sergiusens> cyphermox, that path needs to be writable for bluetooth to work, I made it persistent since the pairing info was stored there (right?) but lool suggested it be writable but temporary
[16:10] <cyphermox> stuff gets written bu bluez to /var/lib/bluetooth
[16:10] <sergiusens> cyphermox, which means it gets recreated on every boot
[16:10] <cyphermox> yeah, looks right
[16:10] <cyphermox> it probably should be persistent as much as possible to make it easier on bluetooth, like, name cache and the like
[16:11] <sergiusens> cyphermox, which means that if the config file changes inside that path and the software doesn't handle it, we will need to
[16:11] <cyphermox> sergiusens: say that again, you mean when set to be persistent?
[16:12] <sergiusens> cyphermox, we're on bluez4 (right?); it has a bunch of files written to /var/lib/bluetooth; if when we update to bluez5 one of those configs is incompatible, we will need to re marshall the files in there so they are compatible with bluez5
[16:13] <sergiusens> cyphermox, I don't think it's that much of a deal btw if it comes to that
[16:13] <cyphermox> yes probably
[16:13] <davmor2> awe_, rsalveti :ah I guess that ofono crash in /var/crash is not too conducive to a working sms system maybe
[16:13] <cyphermox> but as you say, no big deal
[16:13] <cyphermox> I don't expect the files to be that different anyway, and most likely not different at all
[16:14] <sergiusens> sounds good; now I only need word back from mterry and we can upload :-)
[16:14] <dholbach> barry, still the same :-/
[16:14] <mterry> sergiusens, I am OK with temporary for now, but may need to upgrade to persistent in future
[16:14] <sergiusens> cyphermox, meh, I was going to ask you during the standup to add lxc-android-config to the landing plan :-P
[16:14] <sergiusens> mterry, let me change that then
[16:14] <cyphermox> sure, I can
[16:15] <lool> sergiusens: if it keeps pairing inforation, it ought to be persistent
[16:15] <lool> sergiusens: was just challenging whether we really needed it or not
[16:15] <lool> but seems we do
[16:15] <cyphermox> lool: things will work without it, for the most part
[16:15] <barry> stgraber: ^^.  dholbach, and the date is still nov 20 in recovery's log file?
[16:16] <cyphermox> perhaps except for the persistance of pairable and mode
[16:16] <cyphermox> which is still kind of useful
[16:16] <cyphermox> everything else gets re-discovered
[16:16] <dholbach> barry, yes, still the same
[16:16] <sergiusens> cyphermox, I would need to repair my headset every time though
[16:17] <sergiusens> lool, cyphermox I've updated http://people.canonical.com/~sergiusens/lxc-android-config
[16:17]  * sergiusens wants udd to work again
[16:17] <stgraber> dholbach: when rebooting do you see the upgrade screen (android droid logo with a progres bar)?
[16:17] <barry> dholbach: dang.  and this was with the 2.0.3 debs?  or still 1.9.1?
[16:18] <dholbach> barry, 1.9.1 :-/
[16:18] <dholbach> stgraber, no, just the normal Google logo
[16:19] <awe_> davmor2, completely dead in the water, or intermittent?
[16:19] <cyphermox> sergiusens: lool: mterry: so, ok, I add lxc-android-config to the landing plan?
[16:19] <stgraber> dholbach: ok, so you're not booting into the upgrader at all...
[16:19] <stgraber> dholbach: what device is that?
[16:19] <sergiusens> cyphermox, yes please on my side
[16:19] <dholbach> stgraber, grouper
[16:20] <stgraber> dholbach: ok, one sec
[16:20] <davmor2> awe_: intermittent on a reboot it worked however it soon died I have a crash report in /var/crash that I'm trying to get sent
[16:20] <stgraber> dholbach: grab http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20131212.1/trusty-preinstalled-recovery-armel+grouper.img
[16:20] <stgraber> dholbach: then do "adb shell reboot -f bootloader"
[16:20] <stgraber> dholbach: then "fastboot flash recovery trusty-preinstalled-recovery-armel+grouper.img"
[16:20] <stgraber> dholbach: then "fastboot reboot"
[16:21] <lool> cyphermox: +1 from me for the 3 changes but haven't boot tested it and would want 2 people to boot test it (I assume sergiusens is 1 already)
[16:21] <stgraber> dholbach: and finally "adb shell reboot -f recovery"
[16:21] <stgraber> dholbach: and see if that helps ;)
[16:21] <sergiusens> lool, if it's in the landing plan, the testing is granted for ;-)
[16:21] <lool> hehe
[16:21] <lool> sergiusens: well depends if you land it in lp:ubuntu/lxc-android-config or not  ;-)
[16:22] <dholbach> stgraber, now it boots into recovery :)
[16:22] <sergiusens> lool, oh yeah; but for te UDD side; I talked to wgrant, he showed me the importer error; the changelog had warnings and the importer doesn't handle utf8 (your names) so I removed the changelog warnings
[16:23] <awe_> davmor2, ack
[16:23] <awe_> what device?
[16:23] <stgraber> dholbach: ok, so something was messed up in your recovery partition... not sure what would have corrupted it though
[16:24] <stgraber> dholbach: could be some problem with the NAND chip or a failed recovery partition update, who knows...
[16:24] <barry> dholbach: if that fixes it, please close the bug... and yay!  crossing my fingers for you :)
[16:24] <cyphermox> lool: we do tsting as we publish anyway
[16:25] <cyphermox> lool: I understand that it's something that gets manually uploaded thouhg
[16:25] <cyphermox> sergiusens: how do I test it, just untar that tarball on my device and reboot?
[16:25] <lool> sergiusens: you're basically saying it's my fault that we have non-7bits chars changelogs because I have an UTF-8 name?    :-P
[16:26] <lool> cyphermox: You can switch to writable mode and dpkg -i the package and reboot but you have to unmount the bind-mounted udev rules first
[16:26] <davmor2> awe_: maguro
[16:26] <cyphermox> err
[16:26] <cyphermox> it wasn't a deb was it?
[16:26] <sergiusens> lool, nah, it's the importers fault
[16:27] <sergiusens> lool, that breaks the idea
[16:27] <awe_> davmor2, ok, I'll try and reproduce on my end
[16:27] <cyphermox> oh right, source package
[16:27] <lool> sergiusens: cool I feared I had to pick another name
[16:27] <davmor2> awe_: this is on image r62
[16:27] <awe_> davmor2, is that stable?
[16:27] <davmor2> awe_: no devel-proposed with the new ofono stack
[16:28] <awe_> ok
[16:28] <sergiusens> cyphermox, lool adb shell mount -o remount,rw /;  adb push etc/system-image/writable-paths /etc/system-image/writable-paths; adb shell sync; adb shell reboot
[16:28] <lool> sergiusens, cyphermox: Try to test the actual .deb
[16:29] <lool> I know it shouldn't make a difference, but just in case it does because something change that we have not thought of...
[16:29] <sergiusens> lool, hmm, I thought this one was full of symlinks
[16:30] <lool> symlinks or bind-mounts?
[16:30] <lool> there's one
[16:30] <lool> but ISTR I've installed this successfully in the past
[16:31] <lool> after unmounting one bind-mount
[16:31]  * sergiusens the murder by numbers song from the police came to his mind when looking at the version number
[16:31] <sergiusens> lool, do you recall which one?
[16:31] <davmor2> awe_: oh interesting if I call the maguro from my land line the call works I also get a message that I tried to send earlier and then ofono crashes again
[16:31] <lool> sergiusens: some /lib/udev/.../local rules file
[16:32] <awe_> davmor2, can you file a bug, and also attach the contents of /etc/init/ofono.override?
[16:33] <sergiusens> lool, why is writable paths set as a config file?
[16:34] <sergiusens> cyphermox, push the deb, remount / as above, umount /lib/udev/rules.d/70-android.rules, dpkg -i; reboot
[16:37] <salem_> om26er, ping
[16:37] <om26er> salem_, pong
[16:38] <salem_> om26er, hey, do you know if it is possible to enable ci and autolanding for ofono-qt?
[16:39] <om26er> salem_, yes I think we can ask the CI team. fginther help ?
[16:39] <sergiusens> lool, is this the right way to make it temporary?/var/lib/lightdm                        auto                    temporary   none        none ?
[16:40] <om26er> I can propose a branch
[16:40] <salem_> om26er, ok. cool! we will need that to land the delivery report support in tp-ofono.
[16:41] <salem_> om26er, https://code.launchpad.net/~tiagosh/ofono-qt/statusreport/+merge/198567
[16:43] <om26er> salem_, was ofono-qt previously in lp:phablet-extras/ofono-qt ?
[16:43] <salem_> om26er, hm, let me see
[16:44] <salem_> om26er, it is still there I think.
[16:44] <sergiusens> cyphermox, I just copied over a new set, I had the temporary syntax wrong for lightdm; installing from package was fine from my  side
[16:45] <sergiusens> bfiller, hey; wrt to notes; popey saw some errors on mako when running the click; it's been approved anyways tough
[16:45] <sergiusens> cyphermox, lool package install tested and is fine
[16:49] <om26er> fginther, when you get around, can you please review this https://code.launchpad.net/~om26er/cupstream2distro-config/ofono-qt_CI/+merge/198782
[16:49] <om26er> salem_, ^
[16:50] <fginther> om26er, salem_, I can get...
[16:50] <fginther> om26er, you beat me to it
[16:50] <om26er> :D
[16:51] <aural> Until recently I was interested in getting an ubuntu-based phone, but now I'm concerned about security and open source hardware.
[16:53] <loicm> ogra_: hi, I'm looking at https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1256061
[16:53] <loicm> ogra_: just to be sure, how did you switched to a German locale?
[16:54] <loicm> *switch
[16:55] <bfiller> sergiusens: you mean the autopilot tests?
[16:55] <bfiller> sergiusens: it worked for me, argh.
[16:56] <pete-woods> mterry: hi, just getting back to you about the MIR for unity-voice
[16:57] <pete-woods> with the tests that do run in the pbuilder environment enabled, does that improve the situation enough?
[16:59] <lool> sergiusens: thanks
[17:02] <sergiusens> bfiller, yeah, I tested on maguro and worked fine; it's still going to be in the next builds so you can check the results there once in
[17:02] <mterry> pete-woods, let me refresh my memory
[17:02] <fginther> om26er, a couple things to update, please see my comment
[17:03] <om26er> fginther, fixing
[17:03] <bfiller> sergiusens: so freaking sick of the notes-app and autopilot
[17:04] <mterry> pete-woods, oh sorry, I should have commented on that bug earlier
[17:05] <sergiusens> bfiller, there's not really any dev going on with it either....
[17:05] <mterry> pete-woods, though...  there hasn't been a release to the archive with your tests enabled
[17:05] <dholbach> stgraber, barry: problem solved - thanks a lot!
[17:05] <stgraber> dholbach: np!
[17:05] <om26er> fginther, pushed fix. curious why do we use hooks: '' ?
[17:07] <fginther> om26er, we have to specify something (the empty string) otherwise it gets turned into a None which causes problems when populating the jenkins job template
[17:07] <pete-woods> mterry: yes, I haven't asked for another landing yet. I can do that now if it's important for the MIR, though
[17:07] <om26er> fginther, ok, understood.
[17:08] <fginther> om26er, thanks for the MP. approving
[17:08] <om26er> np
[17:08] <mterry> pete-woods, mm, I can just confirm that trunk works like I'd expect
[17:11] <mterry> pete-woods, when would ENABLE_VOICE_TESTS be enabled?  Like, are those tests ever run?
[17:11] <pete-woods> mterry: they're run when I'm doing development
[17:11] <pete-woods> mterry: see build.sh (which is what I run for my usual dev on it)
[17:11] <balloons> ahayzen, ping
[17:11] <mterry> pete-woods, it's a manual test
[17:11] <mterry> ?
[17:12] <ahayzen> balloons, pong
[17:12] <pete-woods> mterry: no, they're automated, but you have to have a working instance of pulseaudio
[17:12] <pete-woods> and pbuilder doesn't offer that
[17:12] <balloons> ahayzen, so you think you could review https://code.launchpad.net/~nskaggs/music-app/fix-shuffle-test/+merge/198485 in a moment? I had wanted Victor to look at the changes again with shuffle, but we're itching to get the fixes in for the tests :-)
[17:13] <mterry> pete-woods, and you say jenkins doesn't like it either?
[17:13] <ahayzen> balloons, wht were the changes that were being discussed in the last few comments?
[17:13] <pete-woods> mterry: specifically the tests require you to be able to load the pipe-source module, and it simply fails to load in Jenkins
[17:14] <balloons> ahayzen, yes, those changes. I'll push them and have you confirm
[17:14] <balloons> if that's alright
[17:14] <pete-woods> I made an involved attempt to write a jenkins hook to reconfigured pulse in more friendly mode for a chrooted environment
[17:14] <pete-woods> but it never worked
[17:14] <ahayzen> balloons, cool, got the nexus ready :)
[17:14] <pete-woods> I also had one of our test guys look at it
[17:14] <pete-woods> but in the end it was just easier to write autopilot tests
[17:15] <mterry> pete-woods, I wonder if a dep8 test would help
[17:15] <pete-woods> as then you're just in a normal desktop session
[17:15] <mterry> yeah, or autopilot is fine
[17:15] <pete-woods> I'm not familiar with dep8 tests
[17:22] <pete-woods> mterry: awesome, thanks!
[17:25] <Parker__> Hi, can I ask anything ?
[17:28] <Parker__> I develop android apps and want to develop for ubuntu touch , where can I learn the QML APIs ?
[17:28] <ahayzen> balloons, did u say u were gonna push some code for me to test or were we talking about the existing (sorry my WiFi dropped out :/ )
[17:29] <balloons> ahayzen, yes, new source. I made his changes but I'm not sure I like them
[17:29] <balloons> so I'm thinking it over :-)
[17:29] <ahayzen> balloons, ok, let me know when u want me to test stuff :)
[17:31] <balloons> ahayzen, pushing
[17:33] <ahayzen> balloons, cool, i still don't understand totally wht Victor meant cause he said u can check if would not have been that track...but couldn't it randomly be that track?
[17:33] <timp> Parker__: it is all here http://developer.ubuntu.com/apps/create/get-the-sdk/
[17:34] <timp> Parker__: on the left under QML, there are APIs and tutorials
[17:34] <ahayzen> balloons, or does it keep going until it hits a time when they aren't randomly in order (or not random lol)
[17:35] <balloons> ahayzen, Victor's point was a "random" track can't be verified by pushing next without checking to see if the track wasn't the next track already. In other words, if you have song 1, 2, 3 and you are playing 1. Turning on shuffle means track 2 or 3 play. But you can't verify you are shuffling properly until track 3 plays as track 2 is the next track anyway
[17:35] <balloons> ahayzen, so yes it goes until it grabs the track that isn't the next track anyway :-)
[17:35] <ahayzen> balloons, ah ok i get it now thx :)
[17:36] <balloons> ohh pep8 errors for me to fix quickly.. you can run i
[17:36] <balloons> just formatting :-)
[17:36] <ahayzen> balloons, its running at the moment
[17:36] <ogra_> loicm, i just select the languaage via the settings app
[17:36] <ahayzen> balloons, i usually run it 3-5 times to confirm its gd
[17:36] <balloons> ahayzen, ofc
[17:37] <loicm> ogra_: ok, thanks
[17:37] <ahayzen> balloons, takes ~200seconds though :/
[17:37] <balloons> ahayzen, I'll be doing the same here.. full suite now.. though nothing else should be broken, hah!
[17:52] <balloons> ahayzen, how's the runs coming?
[17:52] <ahayzen> balloons, just running through 4th iteration without fail at the moment
[17:52] <ahayzen> balloons, u seen pyflakes failing on the latest one?
[17:52] <balloons> yea, lol.. fixing
[17:53] <ahayzen> balloons, we'll get there eventually :)
[17:53] <balloons> haha.. small stuff.. unneeded variable still there
[17:54] <fginther> om26er, salem_, ofono-qt is ready now
[17:54] <om26er> fginther, thanks
[17:54] <salem_> fginther, awesome, thank you!
[17:55] <salem_> seb128, ping
[17:56] <seb128> salem_, contentless ping warning
[17:56] <salem_> seb128, due to fragmentation, the content is coming.
[17:57] <salem_> seb128, hey, are you in charge of telepathy-mission-control?
[17:57] <seb128> salem_, I don't think we have anyone "in charge", it would be easier for both of us if you just stated your question
[18:00] <salem_> seb128, I need to add a new rule to apparmor in a file in mission-control. I see you were the one who added the file.
[18:01] <seb128> salem_, I'm not, file a bug on launchpad, explaining the issue and with the rule/patch you need and subscribe ubuntu-sponsors
[18:01] <seb128> salem_, I can review/upload it then if it makes sense
[18:01] <balloons> ahayzen, so good from my end, and jenkins is good now too
[18:02] <seb128> salem_, jdstrand added the apparmor profile/is maintaining it, he might be a better pick for questions on the topic though
[18:02] <balloons> have to work on carla's additional test after this
[18:02] <alecu> didrocks: ping about "- the revert on the scope to launch click apps"
[18:02] <didrocks> alecu: hey, yeah?
[18:02] <ahayzen> balloons, just running last test then will approve, nice work :)
[18:02] <alecu> didrocks: is that the click scope? is there something we should be fixing somehow?
[18:03] <salem_> seb128, ok, thanks.
[18:03] <balloons> ahayzen, I like this set of tests much better than before.. Everyone helped
[18:03] <alecu> also, is there a bug for that?
[18:03] <seb128> salem_, yw
[18:03] <didrocks> alecu: sil2100 would know which bug he filed ^
[18:03] <ahayzen> balloons, approved do u want to top-approve?
[18:03] <balloons> ahayzen, go for the top approve if you would
[18:04] <didrocks> alecu: but yeah, use latest image, install the package with this commit -> you can't launch click apps anymore from the scope
[18:04] <ahayzen> balloons, cool
[18:04] <didrocks> alecu: so you need I guess:
[18:04] <didrocks> - the fix for it
[18:04] <didrocks> - an AP tests testing that case
[18:04] <alecu> didrocks: great, I'll ask mmcc to take a look, since I'm on the verge of a paternity leave
[18:05] <didrocks> alecu: sure, no worry! (and enjoy ;))
[18:06] <alecu> :-) thanks!
[18:06] <loicm> hey Saviq, can you please point me to the code retrieving the current time for the top panel in unity?
[18:06] <dobey> what commit?
[18:08] <dobey> meh
[18:08] <alecu> dobey: I don't see any new bug for that, hopefully sil2100 can provide some light
[18:09] <ahayzen> balloons, sorry u beat my to it, damn flaky WiFi. Let my know if u want anymore branches tested on device
[18:09] <dobey> alecu: yeah, i'm totally confused about this :)
[18:09] <balloons> ahayzen, that's it.. if you look, everything will be green on mako ;-) We landed fixes for weather too: http://ci.ubuntu.com/smokeng/trusty/touch/mako/62:20131212.1:20131211.2/5420/
[18:13] <ahayzen> balloons, Victor has commented https://code.launchpad.net/~nskaggs/music-app/fix-shuffle-test/+merge/198485/comments/461032
[18:13] <balloons> ahayzen, I just replied actually, ty
[18:13] <ahayzen> balloons, ah yes :)
[18:14]  * balloons tweak again
[18:19] <ahayzen> vthompson, o/
[18:31] <mterry> seb128, btw, I think the welcome-wizard branch has been ready for re-review for a little bit
[18:31] <seb128> mterry, it's funny you mention it, I was just about to have a look ;-)
[18:32] <seb128> mterry, sorry, I've been quite busy and delayed that one
[18:32] <mterry> seb128, I hear ya
[19:57] <anarchiee> are there anyone to help me flashing ubuntu touch to lg optimus g?
[20:02] <sil2100> alecu: hi!
[20:03] <sil2100> alecu: so, I filled a bug for this issue: https://bugs.launchpad.net/unity-scopes-shell/+bug/1260020 <- is this what you had in mind?
[20:04] <sil2100> alecu: I see a branch related to that, so it's in the works - but I need to check if it also has some integration tests with it
[20:05] <alecu> sil2100: ah, ok. I thought this was a problem on unity-scope-click that my team was supposed to fix
[20:06] <alecu> dobey, mmcc ^
[20:08] <dobey> what the heck is unity-scopes-shell
[20:10] <dobey> though the change in r25 there doesn't make any sense to me, either
[20:13] <dobey> that code just really needs a unit/regression test probably
[20:22] <kibibyte> hi
[20:22] <kibibyte> can i install ubuntu-touch on nexus 7 2013 ?
[20:24] <kibibyte> ??
[20:27] <davmor2> kibibyte: you might be able to port to it I don't know if it is officially supported though
[20:29] <kibibyte> :/
[20:29] <popey> it isn't
[20:29] <kibibyte> is there any risk?
[20:29] <kibibyte> i dont want to brick it
[20:29] <kibibyte> popey why?
[20:29] <popey> https://wiki.ubuntu.com/Touch/Install#Supported_devices_and_codenames
[20:29] <popey> it will not work
[20:30] <kibibyte> hm
[20:30] <kibibyte> i want to remove that crap android
[20:30] <davmor2> kibibyte: the 2012 version is nvidia based the 2013 is qualcom based so completely different hardware
[20:31] <kibibyte> but do they work on it
[20:31] <kibibyte> ?
[20:36] <popey> 20:29:54 < popey> it will not work
[20:42] <lops> good morning guys. when I run my app in a tablet, some elements like listitems with icons seem to misbehave or not show at all but they work fine on the PC. any tips?
[21:07] <jdstrand> tedg: daker noticed what I believe is a critical bug in upstart-app-launch: bug #1260079
[21:08] <jdstrand> tedg: see my comment #4 and #5
[21:12] <daker> jdstrand: thank you!
[21:14] <tedg> jdstrand, Hmm, K.
[21:14] <jdstrand> tedg: btw, do you know what /run/shm/lttng-ust is all about?
[21:15] <jdstrand> /run/shm/lttng-ust*
[21:15] <tedg> jdstrand, Yes! :-)
[21:15] <tedg> jdstrand, Instrumenting for measuring application startup performance.
[21:15] <tedg> jdstrand, Basically if you have the lttng module loaded you can track the tracepoints.
[21:15] <jdstrand> tedg: the apps themselves shouldn't need access to the files correct?
[21:16] <tedg> jdstrand, Yeah, the problem is that I was trying to instrument the "exec" utility.  Which is under confinement for click apps but not desktop ones.
[21:16] <tedg> jdstrand, Guessing I'll have to drop those tracepoints.
[21:17] <jdstrand> tedg: I can add explicit deny rules to apparmor-easyprof-ubuntu. if it is just temporary, we can leave the denials in the logs
[21:17] <jdstrand> I just don't want every app to have the logged denials if we can help it
[21:17] <tedg> jdstrand, Can we remove the denials from the log but still leave it as denied?
[21:17] <jdstrand> yes
[21:17] <jdstrand> that is an explicit deny
[21:17] <tedg> Oh, cool.  That'd be great.
[21:18] <jdstrand> (that is what I meant)
[21:18] <jdstrand> ok, I'll queue that up for the next upload
[21:18] <tedg> I'd love that then I could leave the tracepoints in for the legacy apps.
[21:20] <jdstrand> fyi, bug #1260491 will be fixed in the next upload
[21:26] <jdstrand> tedg: do note in 1260079 that it might be more than just TMPDIR. The app needed access to /home/phablet/.local/share/Qt Project/. That could indicate another var isn't getting setup right, or it might be a bug in qtubuntu. you might want to talk to kalikiana_ if you think it is qtubuntu
[21:27] <jdstrand> ie, it could be a related bug or a totally separate bug
[21:27] <tedg> jdstrand, We're setting it to "%s/confined/%s" so it implies the second %s is wrong.
[21:28] <jdstrand> yeah
[21:28] <jdstrand> there seems to be a memory issue though
[21:28] <jdstrand> cause sometimes it is blank and sometimes it has what appears to be XDG_DATA_HOME
[21:29] <jdstrand> (the second %s)
[21:29] <tedg> Found it.
[21:32] <GhostSamurai> Hello everyone
[21:32] <fishscene> o/
[21:33] <GhostSamurai> I have a question
[21:34] <fishscene> Go for it
[21:34] <GhostSamurai> Lol ok
[21:34] <fishscene> Is Mir running on Nexus 7, Grouper in the Development channel?
[21:35] <GhostSamurai> So im going to start the porting process for my phone. If i get stuck can i come here an ask for feedback?
[21:35] <fishscene> Of course.
[21:36] <GhostSamurai> Awesome
[21:41] <GhostSamurai> Also has anyone started doing this for the GS4? I checked and so far found nothing
[21:41] <GhostSamurai> yea its not even in the WIP section nvm
[21:42] <Wilco87> hi there., I am new at Ubuntu touch and I would love to test it! at this moment I have custom android ROM running and team win boot loader. if I want to go back is my boot loader still there after installing Ubuntu touch, so that I can just flash the custom android back on?
[21:42] <Wilco87> oh yeah my phone is a S3
[21:44] <GhostSamurai> Did you make a full back up?
[21:45] <fishscene> err… nvm. Found the answer to my question, but now I have another one. https://launchpad.net/mir/ On that website, it shows a "Series and milestones" tree with "trusty" and "devel". How do I read that? Is the devel branch leading up to the 0.1.3 trusty milestone?
[21:45] <fishscene> GhostSamurai: Thanks for reminding me. I need to add a backup option to my flashing script
[21:46] <Wilco87> yes got all my files and stuff. the only question, stays my boot loader in tact to flash android back ? :-)
[21:46] <GhostSamurai> No problem fishscene
[21:47] <GhostSamurai> Do you have a locked bootloader?
[21:47] <Wilco87> no I have a custom ROM running flashed it with team win boot loader.
[21:48] <Wilco87> no = yes
[21:49] <GhostSamurai> Yes or no lol?
[21:49] <Wilco87> yes I have it unlocked haha
[21:49] <GhostSamurai> lol
[21:50] <GhostSamurai> Check on https://wiki.ubuntu.com/Touch/Devices for your GS3
[21:50] <GhostSamurai> search XDA
[21:51] <GhostSamurai> If you are worrying about messing up your phone then dont even bother messing with this lol I just have like 5 phones laying around to mess with
[21:52] <Wilco87> lol oke , yes I had found that page
[21:53] <Wilco87> .but it doesn't says if my boot loader stays. only how to flash back with adb
[21:57] <GhostSamurai> Just try an find out for yourself do it and then try to flash your adb backup
[21:58] <GhostSamurai> lol
[22:13] <Saviq> loicm, you literally *just* missed me, the time in the indicator comes direct from indicator-datetime
[22:28] <loicm> alright, thanks Saviq
[22:45] <Saviq> loicm, having looked at it again, it is somewhat weird
[22:45] <Saviq> loicm, we abuse the label coming from the indicator
[22:45] <Saviq> loicm, just to trigger an update in the UI
[22:46] <Saviq> loicm, so whenever the label sent from the indicator changes, we do "new Date()" and indeed use Qt.formatTime / Qt.formatDate on the JS Date object
[22:47] <loicm> Saviq: ok, looking at the code in Qt and trying with different QPA plugins, it seems like the locale has nothing to do with the QPA plugin
[22:50] <Saviq> loicm, but indeed when I did:
[22:50] <Saviq> onTextChanged: console.log("[22:50] <Saviq> loicm, in GreeterContent.qml
[22:51] <Saviq> loicm, I first get:
[22:51] <Saviq> [22:51] <Saviq> and soon after:
[22:51] <Saviq> [22:51] <Saviq> WTH?
[22:51] <loicm> Saviq: yes, WTH...
[22:53] <Saviq> loicm, to be honest I don't even see *why* it would get update
[22:53] <Saviq> d
[22:54] <Saviq> ok well, I think I know why
[22:54] <Saviq> it would get updated
[22:54] <leptone> hello im wondering how this is going to work. how is Canonical going to get revenue from these partners/phone sales? With respect to the GPL how can Canonical be compensated for 'their' software?
[22:55] <Saviq> leptone, same way it's compensated for desktop sales
[22:55] <leptone> what way is that?
[22:55] <xnox> leptone: what GPL has to do with it? GPL explicetely allows one to _sell_ software as long as binaries are sold with source code.
[22:55] <leptone> does system76 pay canonical everytime the sell a computer?
[22:56] <Saviq> loicm, I think I found it...
[22:56] <Saviq> loicm, not qtubuntu after all
[22:56] <leptone> xnox, but i mean couldnt the 'partner' just download the software and install it themselves without pay canonical?
[22:57] <beuno> leptone, Canonical owns the Ubuntu trademark
[22:57] <beuno> so they can, but they can't sell it under the Ubuntu name
[22:57] <xnox> leptone: this is very off-topic, how canonical makes money. In general however, software companies make money by writting software or providing services.
[22:58] <Saviq> loicm, it's indicator-datetime and unity8
[22:58] <xnox> leptone: and it could be anything..... from QA, testing, marketing to anything a partner is willing to pay money for.
[22:59] <Saviq> loicm, http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/Greeter/Clock.qml#L51
[23:00] <leptone> beuno, gotcha
[23:00] <Saviq> loicm, timeLabel.text = rightLabel; breaks the binding
[23:00] <Saviq> loicm, so as soon as that happens, we get the string straight from the indicator
[23:00] <Saviq> loicm, which sends "11:58 PM"
[23:01] <loicm> Saviq: ok, I was going to prove that at least it's not in qtubuntu
[23:01] <loicm> Saviq: but that's great we got it
[23:02] <loicm> loicm: so you take care of it?
[23:02] <loicm> Saviq: ^
[23:02] <Saviq> loicm, in unity8, yes, still needs fixing in the indicator
[23:03] <loicm> kgunn will be happy to know about that
[23:03] <Saviq> loicm, will mark the bug accordingly
[23:03] <loicm> Saviq: alright
[23:03] <kgunn> loicm: yep
[23:03] <loicm> Saviq: then now I guess I can go to bed!
[23:04] <loicm> Saviq: have a good night, thanks for taking a look at it
[23:04] <Saviq> loicm, kgunn, I should always be working after a few beers, seems it's productive!
[23:04] <kgunn> lol
[23:05] <kgunn> enough beers...and the time starts to look right on the panel regardless :)
[23:17] <Saviq> kgunn, ok, so this fixes in greeter: https://code.launchpad.net/~saviq/unity8/fox-clock-formatting/+merge/198843
[23:18] <kgunn> Saviq: much thanks
[23:18] <Saviq> kgunn, needs a test (tomorrow, writing tests over beers is less productive)
[23:18] <kgunn> probably so...
[23:18] <Saviq> kgunn, panel time needs to be fixed in indicator-datetime currently, until unity8 takes it over and ignores what the indicator sends altogether
[23:19] <Saviq> which we should probably do to lift the responsibility of the indicator to update it and wake up unnecessarily
[23:20] <Saviq> well-deserved bedtime o/
[23:20] <Saviq> that's all, folks!
[23:24] <kgunn> \o
[23:40] <Tilax> Hello!
[23:40] <Tilax> Just installed Ubuntu on my gnex for the first time.