[02:17] <sarnold> the SDK provides a large weather scope when selecting "C++ scope with http/json" but that default doesn't compile / build / run for me regardless of which devices / kits I try to use. Is it supposed to work?
[05:54] <liuxg>  I have a QString, how can I convert it to a std::string, and its encoding is utf-8?
[08:44] <pitti> le huh, did we now drop the calculator from the standard install?
[08:45] <popey> we shouldn't have.
[08:46] <pitti> ah right, it's still in /usr/share/click/preinstalled/, so I figure installing/removing a local calculator click somehow made that invisible
[08:46] <pitti> so nevermind, probably pilot error
[08:46] <popey> \o/
[08:47] <pitti> i. e. it's not in "click list" any more nor in the dash
[08:47] <lotuspsychje> you guys working hard on RTM, should i install it on my n7 instead of devel?
[08:47] <pitti> n7? do we support that even? (certainly not in RTM)
[08:48] <lotuspsychje> nexus7
[08:48] <popey> n7 2013 is supported
[08:48] <lotuspsychje> i mean i didnt receive any updates lately on devel version
[09:00] <ogra_> lotuspsychje, devel still points to utopic ... it can only be switched once there is the first image in the vivid channel ... which means we need a paromotion in vivid for which we dont have spare Qa resources
[09:00] <ogra_> *promotion
[09:01] <lotuspsychje> so best stick to devel version?
[09:01] <ogra_> i wonder if i wouldnt be possible to create some community around devel promotions ... if you find enough testers to cover all supported devices ...
[09:02] <lotuspsychje> normally i see a lot of touch updates passing by, but i didnt for a time now
[09:02] <ogra_> yes, as i said, only if vivid has been promoted once you will see updates in devel (because then devel can be linked to vivid)
[09:03] <lotuspsychje> think worldwide there's a lot of devel version testers
[09:03] <ogra_> we cant make devel point to an empty channel
[09:03] <ogra_> and a minimal requirement for a promotion is "it boots on all supported devices"
[09:03] <lotuspsychje> i see
[09:04] <ogra_> nobody in the QA team has spare cycles to do such testing ... but ... if someone would organize a community testing that covers this minimal use case we could promote without QA involvement
[09:06] <lotuspsychje> any news from bq and meizu yet?
[09:09] <lotuspsychje> http://www.gsmarena.com/meizu_mx4_with_ubuntu_touch_makes_an_appearance-news-9866.php
[09:11] <popey> lotuspsychje: much of that meizu news comes from a random blog in italy it seems
[09:11] <popey> not from meizu or canonical
[09:11] <popey> so take that with a grain of salt ☻
[09:11] <lotuspsychje> popey: yes i know still not official :p
[09:11] <lotuspsychje> its taking like ages :p
[09:12] <popey> Making Phone OS's that could be used by millions is hard.
[09:12] <lotuspsychje> dvs doing a great job for sure on touch, easy stable and secure..
[09:13] <lotuspsychje> devs
[09:14] <lotuspsychje> popey: the main problem is unsecure apps that users cant miss
[09:14] <popey> there's many problems to solve, that may be one.
[09:45] <pitti> rhuddie: hey Richard! there: https://launchpad.net/ubuntu/+source/autopkgtest/3.7.1git2
[09:45] <pitti> rhuddie: with full reboot support on touch :)
[09:46] <JamesTait> Good morning all; happy World Kindness Day! :-D
[09:46] <pitti> rhuddie: note that you need to call /tmp/autopkgtest-reboot (I updated the documentation accordingly)
[09:46] <rhuddie> pitti, that sounds excellent, thank you!
[09:46] <pitti> rhuddie: so you can get the deb from https://launchpad.net/ubuntu/+source/autopkgtest/3.7.1git2/+build/6566246/+files/autopkgtest_3.7.1git2_all.deb or wait until it's in vivid
[09:47] <rhuddie> pitti, I'll give it a try shortly. thanks :)
[10:44] <seb128> Chipaca, hey
[10:44] <Chipaca> seb128: hi
[10:44] <seb128> Chipaca, replying here to the depends thing
[10:44] <Chipaca> seb128: listening
[10:45] <seb128> Chipaca, what is using -dbus or glib?
[10:45] <seb128> is that pyxdg?
[10:45] <seb128> in which case that package should have a depends on those (it doesn't atm and that would be a bug we should fix)
[10:46] <Chipaca> seb128: the helper itself uses them
[10:46] <seb128> how did it build before? just by luck/because something else was pulling those in?
[10:46] <Chipaca> seb128: and the package does depend on them
[10:47] <Chipaca> seb128: because the tests don't exercise the bit that uses it (because that would require a working dbus, with a working (mock?) system image service
[10:47] <Chipaca> )
[10:47] <seb128> ok, so those are not really build-depends
[10:47] <seb128> e.g it would still be fine without them?
[10:47] <Chipaca> yes
[10:48] <Chipaca> seb128: but it would be surprising to have a build fail if we refactor code, adding no new imports, and the tests pass but it stops building
[10:48] <Chipaca> oh
[10:49] <seb128> Chipaca, sorry, segfaulted xchat-gnome
[10:49] <Chipaca> heh
[10:49] <Chipaca> seb128: but it would be surprising to have a build fail if we refactor code, adding no new imports, and the tests pass but it stops building
[10:49] <Chipaca> seb128: (i think that's all you missed)
[10:49] <seb128> Chipaca, ok, makes sense to me, thanks
[10:50] <seb128> Chipaca, approved
[10:50] <Chipaca> seb128: tks
[10:51] <Chipaca> seb128: do you know if anybody else is putting u-s-s on the train any time soon?
[10:52] <seb128> Chipaca, we almost have daily landings, so yeah no worry about that
[10:52] <ogra_> Chipaca, silo 003
[10:52] <ogra_> waiting for the thaw
[10:52] <ogra_> (and i see you have 014 too)
[10:52] <ogra_> (for testing)
[10:52] <Chipaca> yeah, 014 was for testing this (for help with reproducing & understanding a bug)
[10:53] <Chipaca> and was against rtm
[10:53] <Chipaca> but then i thought this should be there all the time anyway, hence this
[11:30] <bzoltan> mvo_: hello, are you active?
[11:31]  * didrocks systemctl enable mvo_.service :)
[11:32] <mvo_> bzoltan: well, sort of, need tea, otherwise active
[11:34] <bzoltan> mvo_: Just a quick question. Do we have vivid click chroots? If not then when it is scheduled?
[11:34] <mvo_> bzoltan: yes, see https://launchpad.net/ubuntu/+source/click/0.4.34.2 "add ubuntu-sdk-15.04 based on ubuntu-sdk-libs/ubuntu-sdk-libs-dev"
[11:35] <mvo_> bzoltan: its directly generated from these two packages so if you want to adjust the framework, you can just do it via the metapkg
[11:37] <bzoltan> mvo_: ohh, I am silly to ask that late. It is available for ten days... One more question :)
[11:39] <bzoltan> mvo_:  what is the best way to backport the click to Utopic and LTS? I see that the phablet-tools PPA is not up to date. Colin gave me once a guide how to copy and rebuild for other series from the archive... I do not find it.
[11:42] <mvo_> bzoltan: as long as there are no new dependencies it should be really as simple as apt-get source click ; change debian/changelog with appropriate version e.g. 0.4.34~trusty1, upload to ppa. I wonder if you could even setup a auto-build-recipe for the ppa based on the lp:click branch to get this uploaded automatically
[11:42] <mpt> Hmm, System Settings launches so slowly now that the phone locks before it’s done
[11:42] <Stskeeps> g 141
[11:42] <Stskeeps> er, ignore me..
[11:43] <bzoltan> mvo_: that would be the best
[11:44] <bzoltan> mvo_:  but do you think it is safe to automatically release the trunk of the lp:click?
[11:44] <bzoltan> mvo_:  or is it holly trunk like the UITK trunk? :)
[11:44] <mvo_> bzoltan: we use lp:click/devel for the development, once it lands in trunk its usually released
[11:44] <mvo_> (or I messed up lallaalala)
[11:45] <bzoltan> mvo_:  Okey, so it is a holly trunk...
[11:45] <mvo_> bzoltan: https://help.launchpad.net/Packaging/SourceBuilds/GettingStarted <- best to try it in a tmp ppa and if its good thats probably the easiest way for you to get always-in-sync packages
[11:45] <ogra_> mpt, not here
[11:45] <ogra_> under 3 secomds
[11:46] <bzoltan> mvo_:  for the UITK project I do it since the beginning
[11:46] <mvo_> bzoltan: cool, thats even easier then :)
[11:47] <mpt> ogra_, took about 6 minutes here :-/
[11:47] <mpt> I thought it was stuck
[11:48] <ogra_> wow
[11:49] <bzoltan> mvo_:  yay \o/ I did not know I can create packaging recipe for projects I am not in charge. But I can -> https://code.launchpad.net/~ubuntu-sdk-team/+recipe/click-daily
[11:50] <mvo_> :)
[13:33] <mpt> seb128, is the contents of indicator-messages controlled by unity8 or something?
[13:34] <seb128> mpt, the UI elements are
[13:34] <seb128> or ubuntu-settings-components
[14:04] <tedg> kenvandine, So I modified the autopilot test in u-s-s, how do I run it?
[14:06] <mhall119> zsombi: please join #ubuntu-uds-appdev-1
[14:06] <kenvandine> tedg, hang on, in a meeting
[14:07] <tedg> kenvandine, Tell those people I'm more important! ;-)
[14:10] <jgdx> $ autopilot3 run ubuntu_system_settings.tests
[14:10] <tedg> jgdx, In which directory?
[14:10] <jgdx> add modules for more specific runs (autopilot3 run ubuntu_system_settings.tests.test_cellular.CellularTestCase.test_change_carrier)
[14:10] <jgdx> tedg, tests/autopilot
[14:10] <kenvandine> tedg, tests/autopilot
[14:11] <tedg> K, cool. Seems I'm missing packages.
[14:11] <tedg> It seems to be calling /usr/bin/system-settings
[14:13] <kenvandine> tedg, it needs to be installed, to find your plugin changes
[14:13] <tedg> Oh
[14:14] <kenvandine> not so much for the tests
[14:14] <kenvandine> but the plugins that get loaded will be from /usr/share
[14:14] <kenvandine> and it's going to run /usr/bin/system-settings
[14:14] <kenvandine> but it'll run the autopilot tests from your checkout if you are in the right directory
[14:15] <tedg> Okay, so let me build packages.
[14:18] <jgdx> I do $ sudo make install && ln -s /usr/local/bin/…  /usr/bin/…
[14:18] <jgdx> scores 10 on the dirt-o-meter
[14:20] <tedg> Oh, my. Yes. We should purge that suggestion from the IRC logs. :-)
[14:21] <seb128> jgdx, you better make install DESTDIR, easier to make sure you don't corrupt your system install
[14:24] <jgdx> but if my system is not corrupted, how will I learn
[14:25] <ogra_> you mean "learn how the installer works" ?
[14:26] <seb128> lol
[14:26] <seb128> that's how we ensure ubiquity gets regular testing!:
[14:27] <ogra_> :)
[14:28] <jgdx> Noskcaj, ubuntu is surprisingly resilient. You can throw a lot of stupidity at it before it buckles.
[14:29] <jgdx> Noskcaj, tab failure, sorry
[14:37] <barry> pitti: still having problems w/adt-run on device: http://paste.ubuntu.com/8988046/
[14:37] <barry> pitti: notice line 110
[14:38] <barry> pitti: that *ought* to be a valid option, but apt on the device is complaining.
[14:39] <pitti> barry: OOI, is that somethign at adt-run does by itself somehow, or part of your test? (the pastebin doesn't have the command line you ran)
[14:39] <barry> pitti: here's the command: adt-run -d -o /tmp/out system-image-common_3.0-0ubuntu1_all.deb system-image-dbus_3.0-0ubuntu1_all.deb system-image-cli_3.0-0ubuntu1_all.deb system-image_3.0-0ubuntu1.dsc --- ssh -s adb
[14:40] <pitti> but yeah, that looks really odd; it's an -o, after all
[14:40] <barry> pitti: yeah! :)
[14:41] <pitti> barry: do you get the same error if you run that command with phablet-shell?
[14:41] <pitti> barry: (you can try and install aspell-doc or something similarly trivial)
[14:41] <barry> pitti: let me try that
[14:42] <pitti> barry: at least I've never seen that before; maybe this is an option which RTM's apt just doesn't know about yet, but that's both unlikely and also doesn't quite match the error message
[14:45] <barry> pitti:  apt | 1.0.9.2ubuntu2.is.1.0.4ubuntu7 | ubuntu-rtm/14.09 | source, amd64, armhf, i386
[14:45] <barry> pitti: i'm not exactly sure what that version number means ;)
[14:47] <pitti> $ sudo apt-get --quiet -o Debug::pkgProblemResolver=true -o APT::Get::force-yes=true -o APT::Get::Assume-Yes=true --reinstall install aspell-doc
[14:47] <pitti> barry: ^ hm, working fine here
[14:47] <pitti> and I have 1.0.9.2ubuntu2.is.1.0.4ubuntu7
[14:47] <pitti> barry: I figure 1.0.9 broke something and they quickly reverted it
[14:48] <pitti> barry: I'll try to reproduce with an adt-run line like your's
[14:48] <barry> yep, that command works fine for me too
[14:48] <barry> pitti: ^^
[14:49] <barry> pitti: i can provide .dsc and .debs if you want to try to reproduce exactly.  also fwiw, host is on vivid
[14:49] <pitti> barry: host> same here; do we have any other desktop release? :-)
[14:50] <barry> pitti: there's this rumored 'devel' release :)
[14:50] <pitti> barry: yeah, but I've heard it's really hard to tell the difference
[14:51] <pitti> Setting up testpkg (1) ...
[14:51] <pitti> barry: hm, so doesn't reproduce with my little local test package
[14:52] <pitti> barry: the error certainly doesn't look pacakge specific, but just to rule that out, maybe put your files on people.c.c?
[14:52] <barry> pitti: what does `system-image-cli --info` say in phab-shell?
[14:52] <pitti> barry: http://paste.ubuntu.com/8988270/
[14:54] <barry> pitti: looks like my device is on stable build 6.  let me try swapping it over to -proposed.  maybe there's something about the stable channel that's out of whack
[14:55] <pitti> barry: let me create an emulator with stable; may be easier than destroying your device
[14:55] <pitti> Creating "rtm" from ubuntu-touch/ubuntu-rtm/14.09 revision 6
[14:55] <pitti> barry: ^ that sounds like it would match?
[14:55] <barry> pitti: it does
[14:56]  * barry hopes that -proposed wouldn't put his device on phaser overload
[14:56] <pitti> barry: I've never ran stable on any of my devices :)
[14:56] <barry> pitti: it does seem quaint :)
[14:56] <pitti> but then again I don't use it for "production" either, I just destroy the installs too quickly :/
[14:58] <oSoMoN> I just upgraded to image #159 on krillin, and wifi won’t connect, is that a known issue? 
[14:59] <pitti> barry: just to rule that out, you didn't specify a sudo password; I take it you use "0000" as I don't see anything in the log that woudl complain about not having root privs, right?
[14:59] <pitti> barry: and even then, the error messages should look totally different
[15:00] <barry> pitti: correct.  0000
[15:00] <mpt> kenvandine, I just relaunched System Settings: 2 minutes 34 seconds. So, what should I provide?
[15:00] <pitti> . o O { security! half of the company uses that :) }
[15:00] <pitti> the "give me adb, dammit!" passcode
[15:01] <kenvandine> mpt, ok, grab a couple of log files
[15:01] <kenvandine> ~/.cache/upstart/unity8.log
[15:01] <kenvandine> ~/.cache/upstart/dbus.log
[15:01] <pitti> barry: still works in rtm-proposed emulator, trying rtm now
[15:02] <kenvandine> ~/.cache/upstart/application-legacy-ubuntu-system-settings.log
[15:02] <kenvandine> you can just pastebin those
[15:02] <pitti> barry: oh, I found some more differences; I used -B, you didn't; will also try with that
[15:03] <barry> pitti: right, because i did *not* want the -dev.deb installed (that isn't installed on normal images, but it's built and listed in the .changes file)
[15:03] <pitti> barry: oh, specifying a .deb on the CLI does *not* install it
[15:04] <pitti> barry: it merely means that it will be included in the local apt-ftparchive, so that any test dependencies will be satisfied from that
[15:05] <barry> pitti: really?  hmm.  so is there a way to install just a very specific set of .debs or is it really "everything in the .changes file"?
[15:05] <pitti> barry: ok, I tried without -B on rtm (#6), and it still works
[15:05] <pitti> barry: as I said -- supplying a .changes or number of .debs merely "registers" those binaries -- they only get installed as part of debian/tests/control's Depends:
[15:06] <mpt> kenvandine, forgive me, I’ve forgotten how to copy files from the phone
[15:06] <pitti> barry: due to not specifying -B it now installs all the build deps, but that's already way past the point where it fails for you
[15:06] <pitti> barry: so I suggest I'll try with your .deb/.dsc?
[15:06] <barry> pitti: oh, yes, of course, that makes sense.  my d/t/control file says: Depends: system-image-common, system-image-cli, system-image-dbus, ubuntu-download-manager, dbus, dbus-x11, python3-psutil, python3-xdg
[15:07] <barry> pitti: yep, let me upload them
[15:07] <pitti> barry: conversely, do you get the error with -B?
[15:08] <barry> pitti: p.c.c:~barry/pitti/*
[15:08] <pitti> barry: 404
[15:09] <mpt> kenvandine, and clicking on the phone in Nautilus does nothing at all :-/
[15:09] <kenvandine> mpt, sorry... use adb
[15:09] <mpt> (I guess that’s a separate bug)
[15:09] <kenvandine> adb pull /home/phablet/.cache/upstart/unity8.log .
[15:09] <pitti> barry: ooh, I looked in http://people.canonical.com/~barry/, nevermind
[15:09] <kenvandine> adb pull /home/phablet/.cache/upstart/dbus.log .
[15:09] <barry> pitti: chmod'd
[15:09] <kenvandine> adb pull /home/phablet/.cache/upstart/application-legacy-ubuntu-system-settings.log .
[15:09] <pitti> barry: (i. e. I looked in public_html); I'll scp them
[15:09] <barry> pitti: oops, yeah
[15:10] <mpt> kenvandine, the last of those doesn’t exist
[15:10] <kenvandine> adb pull /home/phablet/.cache/upstart/application-legacy-ubuntu-system-settings-.log .
[15:10] <kenvandine> sorry, i typo'd it
[15:11]  * kenvandine blames tedg for the annoying trailing - there :)
[15:11] <pitti> barry: orig.tar.gz, s'il vous plaît ?
[15:11] <pitti> barry: (and debian.tar.gz)
[15:12] <tedg> kenvandine, Patches welcome ;-)
[15:12] <kenvandine> tedg, it's more fun to blame you :)
[15:12]  * tedg lies, he doesn't really want patches from kenvandine ;-)
[15:12] <barry> pitti: uploaded
[15:15] <pitti> barry: hah!
[15:16] <mpt> kenvandine, thanks, I reported bug 1392349 with those three files
[15:18] <kenvandine> mpt, thx
[15:18] <pitti> barry: so on the one hand I'm glad that I can reproduce; on the other, dear world: please stop finding bugs which are more and more obscure!
[15:18] <kenvandine> pmcgowan, i attached that info to bug 1337200
[15:18] <kenvandine> pitti, ^^ the upower info
[15:18] <barry> pitti: i am the Breakor Of Things
[15:18] <barry> pitti: do tell!
[15:19] <pitti> barry: sorry, no, davmor2 is that already; at most you can be his depoty
[15:19] <pitti> deputy
[15:19]  * barry is the Assistant Breakor Of Things
[15:19] <pitti> barry: and I re-confirmed it on rtm-proposed now
[15:19] <barry> pitti: a bug in apt?
[15:19] <pitti> barry: drilling down now
[15:20] <barry> ack
[15:20] <davmor2> pitti: but once the obvious bugs are out of the way it only leaves the obscure thems the rules
[15:30] <pitti> barry: meeting now, will continue after that
[15:31] <barry> pitti: thanks
[15:35] <jgdx> kenvandine, how'd you fix otto the last time around?
[15:36] <jgdx> besides kicking it
[15:36] <kenvandine> poked the qa folks
[15:52] <tedg> jgdx, kenvandine, I'm confused, I can't figure out how to get a base class to use both the system and the session bus.
[15:53] <tedg> jgdx, kenvandine, What is "klass.dbus_con" and how can there be only one?
[16:07] <kenvandine> mpt, are you sure you're on rtm proposed r6?
[16:07] <kenvandine> rtm proposed is currently at r159?
[16:09] <mpt> kenvandine, oh, my mistake. I reflashed on Tuesday. I’m on r214.
[16:09] <kenvandine> hmmm... still doesn't sound right :)
[16:11] <kenvandine> adb shell system-image-cli -i
[16:11] <kenvandine> mpt,  ^^
[16:12] <barry> kenvandine: stable is r6 i think
[16:12] <kenvandine> barry, yeah, but what's r214
[16:12] <barry> kenvandine: proposed i think
[16:12] <kenvandine> i'm on 159 for rtm proposed
[16:13] <barry> ah. then idk :)
[16:13] <kenvandine> http://paste.ubuntu.com/8989429/
[16:13] <kenvandine> so wondering what channel mpt is on
[16:14] <mpt> kenvandine, channel: ubuntu-touch/ubuntu-rtm/14.09-proposed-customized
[16:15] <kenvandine> i have no idea what's in that channel :)
[16:15] <kenvandine> barry, is there a way for me to see what package versions are in a channel?
[16:16] <jgdx> tedg, that should be possible with two spawn_server calls, right? One where system=True and the other where it's not set at all.
[16:17] <barry> kenvandine: i don't think there's a manifest on s-i.u.c
[16:17] <tedg> jgdx, I did that, but I don't know what variable has the session bus, or where it goes.
[16:17] <kenvandine>         "version_detail": "ubuntu=20141111,device=20141106-572f18d,custom=20141110-423-19,version=214"
[16:18] <kenvandine> so i guess 20141111 is what's important there
[16:19] <ogra_> thats a cwayne test channel
[16:19] <ogra_> for testing custom tarballs
[16:19] <jgdx> tedg, spawn_server returns the connection object.
[16:19] <cwayne> yeap
[16:21] <jgdx> tedg, are you trying to mock the gactions?
[16:22] <kenvandine> tedg, jgdx said it's hard to mock gactions... you should fix that
[16:23] <jgdx> (hard for me, not necessarily hard for others)
[16:26] <tedg> kenvandine, I'm trying :-)
[16:27] <tedg> jgdx, Yeah, I have it "written" now I'm trying to get it to run ;-)
[16:28] <mpt> kenvandine, should I not be using that channel?
[16:29] <mpt> (I don’t remember having a definite answer to “Which channel should I be testing”)
[16:29] <kenvandine> mpt, most of use use 14.09-proposed
[16:29] <kenvandine> mpt, that's not causing your bug though (or i doubt it)
[16:29] <kenvandine> just hard for me to know what versions of packages you have
[16:30] <kenvandine> mpt, i still don't see anything in your log that screams out to me as an issue
[16:30] <mpt> kenvandine, should I flash 14.09-proposed and retest?
[16:30] <kenvandine> mpt, is your device plugged in while you are starting it?
[16:30] <kenvandine> mpt, not yet
[16:30] <kenvandine> but yes you should switch channels
[16:31] <mpt> kenvandine, starting the device, or starting System Settings?
[16:31] <kenvandine> starting settings
[16:31] <mpt> (I don’t remember, and yes, respectively)
[16:31] <kenvandine> can you reboot your device and start settings without it being plugged in?
[16:31] <mpt> ok, bbi5m
[16:33]  * mpt waits for the Dash to finish loading first
[16:34] <mpt> kenvandine, 5 seconds
[16:34] <mpt> 4 seconds, 5 seconds
[16:35] <kenvandine> i'm thinking you might have been suffering from bug 1337200
[16:35] <kenvandine> your dbus.log has tons of these
[16:35] <kenvandine> (process:2235): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.41.5/./gobject/gsignal.c:3101: signal id '33' is invalid for instance '0x19cf178'
[16:36] <tedg> kenvandine, jgdx, how do I know if the autopilot tests pass? Because they don't fail?
[16:36] <kenvandine> which i see spamming the log when upower is DOS'ing dbus
[16:36] <kenvandine> i have no idea how to figure out what causes those warnings
[16:36] <kenvandine> tedg, ^^ any suggestions?
[16:36] <kenvandine> tedg, it'll say OK
[16:36] <kenvandine> i think
[16:37] <kenvandine> if there are failures it gives you stats on pass/total
[16:38] <tedg> Ah, there we go. dbus-test-runner was timing out.
[16:38] <kenvandine> if i tail dbus.log while dbus-daemon is chewing cpu... i see these warnings constantly
[16:38] <kenvandine> makes me think it's a warning from something listening to upower
[16:39] <kenvandine> and mpt's dbus.log is just full of those warnings
[16:39] <tedg> I think the only people listening to upower are system settings and indicator-power.
[16:39] <kenvandine> yes
[16:40] <kenvandine> and upower in rtm seems to DOS dbus
[16:40] <kenvandine> which causes system-settings to hang
[16:40] <tedg> I think that upower just passes events, so it's more the battery provider.
[16:40] <kenvandine> yes
[16:40] <kenvandine> and i confirmed there are lots of change events
[16:40] <tedg> File a bug on the kernel :-)
[16:41] <kenvandine> but... those don't seem to get emitted on vivid
[16:41] <kenvandine> with upower 0.99
[16:41] <kenvandine> which is less noisy
[16:41] <tedg> Perhaps that's the fix, or different HW?
[16:41] <pitti> kenvandine: your udevadm log just had 4 events every 10 s, that's not exactly "excessive"?
[16:41] <kenvandine> we saw it on mako and krillin in the past
[16:41] <kenvandine> pitti, that was just over a minute
[16:42] <pitti> initially I thought that the battery driver would send a gazillion events, but at least not in the udevadm log that kenvandine attached to the bug
[16:42] <kenvandine> i ran the same thing on my mako on vivid and had none of the power_supply change events
[16:42] <pitti> kenvandine: but I take it you did that during a time when system-settings was spinning 100%?
[16:42] <kenvandine> pitti, no... it wasn't
[16:42] <pitti> oh
[16:42] <kenvandine> that was just idle
[16:42] <pitti> well, then it doesn't say anything
[16:43] <kenvandine> and the system was sleeping
[16:43] <kenvandine> why change events when nothing changed?
[16:43] <kenvandine> pitti, i think what happens is settings is connected to those signals, and it sleeps
[16:43] <pitti> kenvandine: well, because that was the theory -- lots of batter change events which are propagated through upower to system-settings
[16:43] <kenvandine> after a while when the app resumes
[16:44] <kenvandine> it gets all the signals
[16:44] <kenvandine> so if you leave it plugged in for 8 hours sleeping
[16:44] <kenvandine> and resume the app
[16:44] <kenvandine> it gets flooded
[16:45] <kenvandine> pitti, so i'm thinking the problem is it's constantly sending those changed events, when nothing changed
[16:45] <pitti> ok; we'd still need the udevadm log to confirm that then
[16:46] <pitti> i. e. whether it's the android battery driver or upower going crazy after suspend
[16:47] <kenvandine> pitti, i was thinking it was all the dbus signals being sent to the subscriber when the subscriber resumes
[16:47] <kenvandine> not necessarily when upower wakes
[16:47] <kenvandine> just the fact that they happened while settings was suspended
[16:47] <kenvandine> pitti, so on vivid, none of the only change events i see is on battery
[16:47] <kenvandine> not on ac, usb and wireless
[16:48] <pmcgowan> kenvandine, pitti I added the upower output but just saw your comment
[16:48] <pmcgowan> need to let it sit a while again
[16:49] <pitti> kenvandine: ah, you figure that dbus-daemon or whatever queues up the signals for subscribers, and flushes them
[16:49] <pitti> ... once they resume
[16:49] <pitti> so that they don't lose signals
[16:49] <pmcgowan> right
[16:49] <pitti> that would actually make sense
[16:49] <kenvandine> pitti, am i making sense?  i don't think it's upower going crazy after suspend, just that upower is constantly emitting these signals while settings is suspended
[16:49] <kenvandine> right
[16:49] <ogra_> well
[16:49] <kenvandine> and the fact that these change events keep happening when there isn't a real change
[16:49] <kenvandine> makes them queue up pretty fast
[16:50] <pitti> kenvandine: right; so an app which is subscribing to a signal would need to unsubscribe before it gets suspended, otherwise it's going to get all that flooding
[16:50] <ogra_> we see quite some noise of upower, dbus and indicator-power in smoke testing
[16:50] <pitti> yeah
[16:50] <kenvandine> pitti, i fear trying to do that will lead to lots of bugs
[16:50] <pitti> but so far it wasn't clear at all what's triggering those
[16:50] <ogra_> we have this "systemsettle" test ... where we check if the system goes back above 95% idle state
[16:50] <kenvandine> pitti, the situation is much better in vivid with upower 0.99
[16:50] <pitti> ogra_: yeah, I know
[16:50] <ogra_> and these three usually are the noisy ones in the top ouotput in this test
[16:51] <ogra_> oh, right, i told you already
[16:51] <pitti> ogra_: yeah, 5 change events from various sources (even AC!) every 10 s does pile up
[16:51] <ogra_> yup
[16:51] <pitti> so AC change events are indeed a bit pointless
[16:51] <pitti> it seems the android drivers just send out change events every 10 s no matter what
[16:51] <ogra_> well, there must be a way to quieten them
[16:51] <kenvandine> pitti, so in 0.99 those just aren't being forwarded right?
[16:52] <ogra_> (on the driver side)
[16:52] <pitti> kenvandine: hm, that's surprising, as the data flow didn't really chagne; the particular signal changed, though
[16:52] <kenvandine> in 0.99 i only see the battery change
[16:52] <kenvandine> every 10s
[16:52] <pitti> ogra_: yeah
[16:52] <pitti> ogra_: it seems rather simplistic
[16:52] <kenvandine> the changelog said something about quieting those signals
[16:52] <pitti> as if the AC change wouldn't generate a proper interrupt or so which would then trigger a change event
[16:52] <kenvandine> like upower is smarter about it
[16:52] <pitti> battery events need to happen regularly, I get that
[16:53] <kenvandine> right
[16:53] <kenvandine> so 0.99 is perfect :)
[16:53] <pitti> kenvandine: ah, so it might receive the uevents for AC, but see that the status didn't change and thus use that?
[16:53] <pitti> kenvandine: ... to determine to not send another signal?
[16:53] <pitti> could be
[16:53] <kenvandine> right
[16:53] <pitti> it doesn't solve the fundamental problem of signals queueing up during suspended apps, though?
[16:53] <kenvandine> i think that somethign like that was in the 0.99 changelog
[16:53] <kenvandine> not really
[16:54] <kenvandine> but... it's usually not like this ;)
[16:54] <pitti> as the battery level does change a lot all the time, so what works for AC doesn't work for battery
[16:54] <tedg> kenvandine, Okay, this works now. Do you have a way to run Jenkins on the rtm branch? It doesn't merge cleanly with trunk :-/
[16:55] <kenvandine>  - Remove DeviceChanged and Changed signals (PropertiesChanged
[16:55] <kenvandine>    signals are sent instead) (Bastien Nocera)
[16:55] <kenvandine> pitti, ^^
[16:55] <kenvandine> so the PropertyChanged signal is probably smart enough to not happen when there is no change
[16:55] <pitti> kenvandine: ah, and I guess that implicitly provides the "property didn't really change" filtering
[16:55] <kenvandine> right
[16:55] <pitti> kenvandine: so upower itself would still wake up 4 times every 10 s
[16:55] <kenvandine> and removing that is part of the API change
[16:55] <pitti> but it doesn't propagate that
[16:56] <kenvandine> so backporting that to rtm is not likely :/
[16:56] <pitti> so that doesn't solve the system-settings spinning, but it helps ogra's load tess
[16:56] <pitti> tests
[16:56] <ogra_> yeah
[16:56] <ogra_> well, it is plars load tests ... i'm, only whining about them all the time :)
[16:56] <pitti> so, oh well, we have the transition done, we could in theory land it in RTM :)
[16:57] <ogra_> hahahaha
[16:57] <kenvandine> pitti, it really makes a huge difference :)
[16:57] <pitti> (still doesn't fix bug 1337200 of course)
[16:57] <ogra_> put it on the bug wishlist
[16:57] <pitti> at least not with the current theory
[16:57] <kenvandine> how many packages are affected by the transition?
[16:57] <ogra_> but i doubt olli will easily be convinced to replace the whole stack :)
[16:57] <pitti> kenvandine: distro-wide: looots (bug 1330037)
[16:58] <kenvandine> pitti, it makes the bug practically go away
[16:58] <pitti> kenvandine: on touch however, about 4 packages (upower, powerd, indicator-power, system-settings)
[16:59] <kenvandine> right, so for rtm it's a pretty controlled set
[16:59] <pitti> kenvandine: hm, that's surprising; I'd expect the time of pegging CPU to be reduced to 1/4, but not go away
[16:59] <kenvandine> on vivid waking settings isn't even noticable
[17:00] <kenvandine> there could be more chatter than that while sleeping for longer, not sure
[17:00] <kenvandine> oh... and what happens when it's fully charged?
[17:00] <kenvandine> the change doesn't get emitted
[17:00] <kenvandine> only when the level changes
[17:06] <pitti> kenvandine, pmcgowan: I sent a summary to the bug
[17:08] <pmcgowan> pitti, kenvandine maybe a stupid question but why is the phone not suspending on AC
[17:08] <pmcgowan> I can see if its plugged into my pc but not when on the wall wart
[17:09] <ogra_> pmcgowan, adb keeps it up
[17:09] <pmcgowan> ogra_, on a wall charger?
[17:09] <pmcgowan> it shouldnt right
[17:09] <ogra_> ah, no, that shouldnt
[17:09] <pmcgowan> I need to try that again, that was the original bug
[17:10] <ogra_> but i think thats behavior we inherit from android
[17:21] <pitti> barry: ok, back from meeting and discussions from above and with elopio :)
[17:21] <pitti> barry: and I think I got the problem
[17:21] <barry> pitti: pebkac? ;)
[17:22] <pitti> barry: yes, (but my k and c)
[17:22] <barry> :D
[17:24] <pitti> barry: the fix is really embarassing: http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=9b87f225c
[17:24] <pitti> barry: the fun thing is that it works just fine when calling it with that space on the shell (i. e. -o 'Debug::pkgProblemResolver=true ' -o ...)
[17:25] <barry> pitti: omg.  i looked at that code several times and didn't notice it
[17:25] <pitti> barry: so if you want to hot-fix that inline in your /usr/bin/adt-run
[17:25] <barry> pitti: yep, i'll do that and give it another run... but after lunch
[17:25] <pitti> barry: I'm not sure why it only happens with those three debs and not with e. g. aspell-doc and language-pack-touch-de
[17:25] <kenvandine> pmcgowan, i'll prepare a branch of settings that disconnects from those signals when it gets suspended
[17:25] <barry> pitti: what about doing ' '.join([...]) instead?
[17:25] <pitti> barry: that will forever remain a mystery of apt; but I tested it wit sytem-image now, and the tests are running happily
[17:25] <kenvandine> gotta figure out how to know when we are getting suspended
[17:26] <pitti> barry: nah, I don't want to introduce extra shells and quoting issues
[17:26] <pmcgowan> kenvandine, there is a signal
[17:26] <barry> pitti: no worries.  anyway, thanks for digging in and finding this
[17:26] <pitti> barry: whenever possible I run commands as argv vector
[17:26] <kenvandine> pmcgowan, do you know what i provides that signal?
[17:26] <pitti> barry: the last test fails, FYI
[17:26] <pitti> PermissionError: [Errno 13] Permission denied: '/etc/system-image/tmp3fq6s05m'
[17:26] <pitti> barry: but I'll leave that to you :)
[17:27] <kenvandine> pmcgowan, and ideally prior art, something else that does this already
[17:27] <pitti> barry: http://paste.ubuntu.com/8990395/
[17:27] <pitti> barry: but I guess you should run it without -d
[17:27] <barry> pitti: right, the tests are still in flux.  need to figure out reboot and post-reboot verification
[17:28] <pitti> barry: want/need that in vivid, or is local fixing ok for you right now?
[17:29] <barry> pitti: long term: vivid, but for now i can do a local fix
[17:33] <pmcgowan> kenvandine, hmm cant seem to find the api
[17:34] <pitti> barry: yeah, I'll most certainly do another upload this week, was just wondering how urgent it is
[17:47] <ogra_> oh neat ... copy/paste worked for me for the first time !
[19:37] <Riku-san> ok, so I just installed ubuntu-touch/trusty-customized on my grouper
[19:37] <Riku-san> it's pretty stable
[19:37] <Riku-san> but either the wifi or the browser isn't working right
[19:38] <Riku-san> (I have WiFi that I need to sign in to after I connect)
[19:39] <Riku-san> well, it was stable
[19:39] <Riku-san> it just locked up because the USB cable came unplgugged
[19:41] <Riku-san> the interface likes to lock up, but it still goes in and out of suspend
[19:44] <Riku-san> nvm seems to be stable and wifi working after a reboot
[19:45] <Riku-san> new question: how do I go into desktop mode? on the device
[19:45] <popey> two things, 1) we no longer support grouper, 2) there is no desktop mode (yet)
[19:47] <Riku-san> popey: why do you no longer support grouper? other than the fact it's 2 years old
[19:47] <Riku-san> it would seem like it would have the best support since there's official linux support from nvidia
[19:48] <popey> We're focussed on other faster / newer devices - Nexus 4, Nexus 7 2013
[19:48] <Riku-san> why isn't it seeing my bluetooth keyboard?
[19:48] <Riku-san> in settings it says 'Connect a headset:'
[19:49] <Riku-san> but it won't see my keyboard?
[19:49] <popey> we currently only support audio devices - headsets / speakers
[19:49] <Riku-san> how is this supposed to be better than the scrapped ubuntu mobile?
[19:50] <ogra_> it is a phone OS
[19:50] <Riku-san> I have a 3.5mm port for audio, keyboards are more useful
[19:50] <ogra_> dont expect it to be anything else yet
[19:50] <Riku-san> how can I MAKE it support my keyboard?
[19:50] <Riku-san> I was pointed here as a solution to an xorg bug in ubuntu mobile
[19:51] <ogra_> who pointed you ?
[19:51] <Riku-san> people from #ubuntu and #ubuntu-arm
[19:51] <Riku-san> because 'ubuntu mobile is no longer supported'
[19:51] <ogra_> well, they definitely pointed you wrong
[19:51] <ogra_> right+
[19:51] <ogra_> ubuntu mobile was never supported
[19:51] <Riku-san> their solution was use touch instead
[19:51] <ogra_> it was a testbed for building the underlying bits of ubuntu touch (minus the UI)
[19:52] <ogra_> in preparation to build a phone OS
[19:52] <Riku-san> this is a terrible portable computer if I'm stuck with a touch keyboard tbh
[19:52] <ogra_> which will *later* also become a teblet and desktop OS
[19:52] <Riku-san> but ofc the device I just spent money on is no longer supported
[19:52] <ogra_> and replace the current ubuntu
[19:52] <Riku-san> replace desktop ubuntu with THIS?
[19:52] <ogra_> yes
[19:52] <ogra_> in two-three years
[19:53] <ogra_> first we need a stable phone OS to build on
[19:53] <Riku-san> great I have two-three years before I have to switch to debian if it's gonna go windows 8
[19:53] <ogra_> huh ?
[19:53] <ogra_> why would it
[19:53] <ogra_> the desktop wont be much different to todays ubuntu desktop
[19:53] <Riku-san> hmm
[19:54] <Riku-san> well I don't use unity in the first place so it may not affect me
[19:54] <ogra_> right, you will likely use one of the flavours ... not sure they will follow suit
[19:54] <Riku-san> I just use Ubuntu Server for everything
[19:54] <ogra_> (though if they are clever they will )
[19:55] <Riku-san> because it still fits on a CD
[19:55] <ogra_> the new thing will fit on less
[19:55] <ogra_> what we are building is way way smaller
[19:55] <ogra_> and has unbrekable upgrades
[19:56] <Riku-san> is their a technical way to make my keyboard work?
[19:56] <ogra_> for sure ... its just bluetooth after all
[19:56] <Riku-san> it worked on ubuntu mobile, why does it no longer work on a newer release?
[19:56] <ogra_> just look up how to connect a kbd via commandline
[19:56] <ogra_> oh, you mean its not BT ?
[19:57] <Riku-san> annnd it locked up trying to show the onscreen keyboard
[19:57] <Riku-san> it is bluetooth
[19:57] <Riku-san> I know how to use OTG
[19:57] <ogra_> well, OTG is likely disabled in your touch kernel now
[19:57] <Riku-san> how is this useful?
[19:57] <ogra_> (i dont think we enabled it)
[19:57] <Riku-san> it's lacking features that android has...
[19:58] <ogra_> it serves fine as day to day phone OS
[19:58] <ogra_> and will go on sale on phones soon
[19:58] <Riku-san> if I wanted a day to day phone OS I would be running android...
[19:58] <ogra_> preinstalled
[19:58] <ogra_> well, but that is what it is
[19:58] <Riku-san> and locked up before I could even unlock it
[19:59] <ogra_> yes, the tegra android driver is brioken
[19:59] <ogra_> which is the main reason we dropped support for ti
[19:59] <ogra_> *it
[19:59] <ogra_> it wont run Mir or wayland ...
[19:59] <kenvandine> tedg, if i want to do something when settings suspends, can i just connect to SIGSTOP ?
[20:00] <ogra_> kenvandine, iirc Mit sends you a nice signal you can liten to
[20:00] <Riku-san> I have a modified image with the proprietary nvidia drivers, how can I flash it?
[20:00] <ogra_> *listen
[20:00] <ogra_> you mean you jave added newer android drivers to the android container ?
[20:00] <Riku-san> I added the files into the tar.xz
[20:00] <kenvandine> ogra_, so it's mir... thanks
[20:01] <Riku-san> they patched into lib and etc
[20:01] <kenvandine> std::signal would be nice :)
[20:01] <Riku-san> I pulled them from the latest TegraForLinux package for the T30L on the nvidia site
[20:01] <ogra_> that cant work
[20:01] <ogra_> you need android drivers
[20:01] <Riku-san> they're armhf drivers... for linux
[20:02] <ogra_> right
[20:02] <Riku-san> why do I need android drivers?
[20:02] <Riku-san> I'm not running android
[20:02] <ogra_> and touch uses a container in which the android HAL runs
[20:02] <ogra_> which uses android drivers
[20:02] <ogra_> linked against bionic ... not libc
[20:02] <Riku-san> this is why I miss mobile
[20:03] <Riku-san> how can I build a newer image of mobile myself?
[20:03] <ogra_> mobile (as i said before) was a testbed to get the unerlaying architecture working
[20:03] <Riku-san> and it's (at least from what I can see) a normal armhf system
[20:03] <ogra_> you could simply take the old mobile and upgrade it
[20:04] <Riku-san> I have successfully run JRE 8 and a minecraft server on it
[20:04] <ogra_> but afaiik the tegra4linux drivers do not run with newer xorg
[20:04] <Riku-san> I learned that the hard way
[20:04] <Riku-san> it made my touch act up more
[20:04] <Riku-san> (touch input)
[20:04] <ogra_> they wont even be used in touch
[20:04] <ogra_> no matter how much you try :)
[20:04] <Riku-san> how would I go about upgrading the old image?
[20:04] <ogra_> apt
[20:05] <Riku-san> yes that's how I soft bricked my device
[20:05] <ogra_> but it will break the graphics stack
[20:05] <Riku-san> because that happened
[20:05] <ogra_> right
[20:05] <Riku-san> it also broke wifi so it became next to worthless and I had to reflash
[20:10] <dobey> ogra_: i don't think Riku-san is running ubuntu-touch, but is trying to get touch screen working in armhf ubuntu desktop
[20:10] <dobey> at least, that was my understanding
[20:11] <ogra_> my undertsanding was that it started with desktop ... then was switched to touch ... then the l4t drivers were put on top
[20:11] <ogra_> which ... well ... is pointless since they are a no-op
[20:15] <tedg> kenvandine, No, you need to get the lifecycle event from Mir, once you've got the SIGSTOP it's too late.
[20:15] <kenvandine> tedg, so is it something in mir_toolkit/mir_client_library.h
[20:15] <tedg> kenvandine, I don't know, I think there should be a QML event on the application object.
[20:16] <tedg> kenvandine, You need to know to save work, etc.
[20:16] <kenvandine> yeah, i need it in cpp
[20:16] <tedg> kenvandine, Once you've got SIGSTOP, you can be killed without notice.
[20:16] <tedg> Oh, I figured QML was better :-)
[20:17] <kenvandine> usually :)
[20:17] <kenvandine> i see a mir_lifecycle_state_will_suspend state
[20:17] <kenvandine> but not sure what to connect to to get that :)
[20:21] <ogra_> kenvandine, watch the app log while putting it in bg
[20:21] <ogra_> iirc it prints the signal name
[20:21]  * kenvandine tries
[20:21] <kenvandine> i think it's MirConnection with mir_connection_set_lifecycle_event_callback
[20:27] <greyback_> kenvandine: right now I've wired up the lifecycle event from Mir to QML's Qt.application.active property
[20:27] <kenvandine> greyback_, from cpp should i use mir_connection_set_lifecycle_event_callback ?
[20:28] <greyback_> kenvandine: it's already used in qtubuntu, not sure if the callback supports multiple callees, might do thougg
[20:28] <kenvandine> greyback_, so here's what i need to do
[20:28] <kenvandine> in system-settings, i need to see the app is suspending and disconnect from upower dbus signals
[20:28] <kenvandine> and on resume connect again
[20:29] <kenvandine> to prevent getting DOS'd on resume with signals queued while suspended
[20:30] <greyback_> kenvandine: in C++, connect to the https://qt-project.org/doc/qt-5/qguiapplication.html#applicationStateChanged signal and act on the Active/Inactive states
[20:30] <greyback_> is that enough?
[20:30] <kenvandine> that's easier than mir :)
[20:30] <kenvandine> yes... thanks
[20:30] <greyback_> cool
[20:31] <kenvandine> i tried just using std::signal, but that wasn't good for SIGSTOP
[20:31] <greyback_> nah, you can't interrupt that
[20:32]  * greyback_ sees Qt::ApplicationState has a Suspended state, that might be better to use in future
[20:32] <ogra_> i think that is what apps print in their logs actually
[20:32] <ogra_> (and the respective status like "suspended")
[20:33] <greyback_> hmm, posible
[20:33] <ogra_> and i think there is even a way to get that info in QML
[20:34] <kenvandine> there is
[20:34] <greyback_> yep, Qt.application.active
[20:35] <greyback_> or Qt.application.state (active deprecated)
[21:22] <jgdx> kenvandine, seems fginther solved the otto issues and I got a pass just now.
[21:23] <kenvandine> jgdx, WOOT!
[21:26] <kenvandine> pmcgowan, pitti: system-settings only connects to device-added and device-removed, not device-changed
[21:27] <kenvandine> anyway, i have a branch that disconnects and connects
[21:28] <kenvandine> so maybe with upower 0.9 upower is sending those as added/removed?
[21:28] <kenvandine> dunno
[21:28] <kenvandine> i'm looking forward to CI builds
[21:28] <jgdx> <3<3
[21:28] <kenvandine> oh crap...
[21:29] <kenvandine> CI build will be against vivid
[21:30] <kenvandine> guess i need a silo
[21:37] <kenvandine> jhodapp, has there been any movement on media-hub being able to fetch additional items?  like panpipe needs to fetch songs from pandora to stream while the app is suspended?
[21:38] <jhodapp> kenvandine, it can do that if it's just a simple web stream
[21:38] <jhodapp> kenvandine, just call open_uri
[21:41] <kenvandine> jhodapp, we need to get additional uri's
[21:41] <kenvandine> each song is a separate uri, and we can't fetch them far in advance
[21:41] <jhodapp> kenvandine, describe the scenario a bit
[21:41] <kenvandine> so we give play one
[21:42] <jhodapp> kenvandine, oh I see, so you need background playlists essentially
[21:42] <kenvandine> yes
[21:42] <jhodapp> that's not in yet
[21:42] <jhodapp> it's mostly coded, but needs more love
[21:42] <kenvandine> i was just wondering if you had an idea when?
[21:42] <jhodapp> but it should be coming up soon, maybe in a sprint or two
[21:42] <kenvandine> the panpipe guy has been asking me
[21:42] <kenvandine> and panpipe isn't very useful without it :/
[21:43] <jhodapp> kenvandine, I've been thinking about it, I'll make sure it gets on our backlog in the next sprint or two
[21:43] <jhodapp> I'd like to see it
[21:43] <kenvandine> thx
[21:43] <kenvandine> i really miss pandora :)
[21:43] <jhodapp> so would the music-app guys
[21:43] <jhodapp> kenvandine, me too! I want a pandora client like Pithos (though better)
[21:43] <jhodapp> it'd be awesome if it were integrated into our music-app
[21:43] <kenvandine> panpipe is getting some love now, but he isn't super motivated to finish it until we can do this
[21:43] <kenvandine> yeah
[21:44] <jhodapp> is panpipe a pandora client?
[21:44] <kenvandine> but we have something at least as good as pithos already :)
[21:44] <kenvandine> yes
[21:44] <jhodapp> nice!
[21:44] <jhodapp> so this is probably the one major thing that you are missing
[21:44] <kenvandine> it is
[21:44] <kenvandine> try it out though :)
[21:44] <kenvandine> it works... just can't let it suspend :)
[21:44] <jhodapp> it probably works as an unconfined app no?
[21:44] <kenvandine> no
[21:45] <kenvandine> unconfined still suspends
[21:45] <jhodapp> well not through suspend of course
[21:45] <jhodapp> but I meant in the background
[21:45] <kenvandine> it works confined
[21:45] <kenvandine> just not background
[21:45] <jhodapp> right
[21:45] <kenvandine> playback works until it runs out of songs
[21:45] <kenvandine> which i think right now it only fetches 1
[21:45] <kenvandine> it could fetch multiple, but we don't want to abuse the api
[21:46] <jhodapp> yep, expected
[21:46] <kenvandine> they want you to fetch additional songs as needed
[21:46] <jhodapp> kenvandine, yeah, I'll bring that up a week from Monday when we have our next sprint planning meeting
[21:46] <jhodapp> kenvandine, we'll get this on the list
[21:46] <kenvandine> anyway, when we an have background playlists... this thing should get polished up quickly
[21:47] <jhodapp> fantastic, I use Pandora a lot too
[21:47] <jhodapp> kenvandine, does it support paid subscription?
[21:47] <kenvandine> i used to listen to it on my phone all day...
[21:47] <kenvandine> i miss it
[21:47] <kenvandine> yeah
[21:47] <jhodapp> we'll get it
[21:47] <kenvandine> not really any different actually
[21:47] <jhodapp> different URIs right?
[21:47] <kenvandine> just no adds, the free account the adds get put in
[21:48] <kenvandine> i think we use the api the same way
[21:48] <jhodapp> it should have higher fidelity too
[21:48] <kenvandine> they just give us different uri depending on the login
[21:48] <kenvandine> i have a paid account
[21:48] <jhodapp> exactly
[21:48] <jhodapp> me too
[21:48] <jhodapp> ok trying that app right now
[21:48] <kenvandine> but i rarely use it now... because of media-hub... cough cough
[21:48] <ogra_> write a scope
[21:49] <jhodapp> kenvandine, haha, no comment
[21:51] <jhodapp> kenvandine, is it using media-hub right now?
[21:51] <kenvandine> yes
[21:51] <jhodapp> nice!
[21:51] <jhodapp> :)
[21:51] <kenvandine> you've talked to him about it on g+ :-D
[21:51] <jhodapp> oh haha, I can't remember anything these days...must be getting old
[21:51] <kenvandine> micah losli
[21:52] <jhodapp> right, rings a bell now
[21:52] <kenvandine> in the car i set my phone to never sleep so i can listen :)
[21:52] <kenvandine> works great, as long as you focus panpipe before the song ends
[21:53] <kenvandine> or even after... it'll catch up :)
[22:21] <pmcgowan> kenvandine, maybe a bug in upower sends more than the events you requested as those are all change events flooding us
[22:22] <pmcgowan> kenvandine, but we must get changes for the battery graph no?
[22:37] <kenvandine> pmcgowan, that's different
[22:37] <kenvandine> it's not the graph
[22:38] <kenvandine> it's the EntryComponent in the main grid
[22:38] <kenvandine> not the battery panel itself
[22:39] <kenvandine> pmcgowan, you can try it out in rtm silo 16
[22:40] <Riku-san> ogra_: I'm not running the image with the l4t drivers
[22:41] <Riku-san> however if someone could tell me how to update the ubuntu-mobile image to 14.04 or above that would help
[22:42] <Riku-san> ie take the new version of ubuntu armhf and make it into a .img that I can flash with fastboot
[22:44] <ogra_> why would you expect that to be any different to an apt upgraded install (note it wont)
[22:45] <Riku-san> maybe because I could install working drivers beforehand?
[22:45] <Riku-san> instead of after it's got no gui and no network
[22:45] <ogra_> there are no working drivers in l4t that work with the xorg in 14.04 (or later)
[22:46] <Riku-san> 'do-release-upgrade' didn't even successfully upgrade, just break the gui and wifi
[22:46] <Riku-san> well they don't work properly in 13.04 either
[22:47] <ogra_> yes, i didnt say anything about do-release-upgrade at any time
[22:47] <Riku-san> then how should I go about doing it?
[22:47] <ogra_> the debian way
[22:47] <Riku-san> which is?
[22:47] <ogra_> hack yur sources.lits to the next version and use appt
[22:47] <ogra_> *apt
[22:47] <Riku-san> oh, I see
[22:47] <ogra_> but this is far beyond the topic of this channel
[22:48] <Riku-san> I had my sources.list on the debian repos because raring is dead
[22:48] <ogra_> err
[22:48] <ogra_> did you installl any package from there ?
[22:48] <Riku-san> I installed a lot of things
[22:48] <dobey> ...
[22:48] <popey> wow
[22:48]  * ogra_ gives up 
[22:48] <popey> thats a bad idea
[22:48] <Riku-san> openssh server, libreoffice, byobu
[22:49] <Riku-san> poper: why is that a bad idea?
[22:49] <popey> raring isn't dead, it's just not where you expected it to be
[22:49] <Riku-san> *popey
[22:49] <Riku-san> oh
[22:49] <popey> debian != ubuntu
[22:49] <Riku-san> debian packages = run on ubuntu
[22:49] <ogra_> no
[22:49] <ogra_> not at all
[22:49] <popey> no
[22:49] <Riku-san> it didn't cause me any problems
[22:49] <Riku-san> they all ran fine
[22:49] <popey> that doesn't make it right, or guaranteed to work
[22:50] <popey> anyway, raring is in the same place as all EOL releases
[22:50] <popey> http://old-releases.ubuntu.com/ubuntu/dists/
[22:50] <popey> however, this plan seems somewhat fraught.
[22:50] <Riku-san> at least it's better than ubuntu touch...

[22:50] <ogra_> heh, yeah

[22:51] <ogra_> and pretty unfounded
[22:51] <ogra_> since based on totally wrong data :)
[22:51] <popey> so your choices are a broken unsupported ubuntu mobile or a broken unsupported ubuntu touch.
[22:51] <Riku-san> If I wanted a day to day phone os, I'd be running Android 4.4.4 with it's 1 billions apps
[22:51] <Riku-san> however, I want a desktop OS
[22:51] <popey> ok then
[22:51] <popey> I want a pony.
[22:51] <ogra_> so use android on your grouper ...
[22:52] <ogra_> thats the best you can do with it
[22:52] <popey> +1
[22:52] <dobey> install android and a vnc client
[22:52] <Riku-san> nobody said I wanted a day to day phone os
[22:52] <ogra_> neither of the ubuntu options will make yoou happy
[22:52] <Riku-san> dobey: that requires me to use my terrible laptop
[22:52] <dobey> if you don't want a tablet, buy something not a tablet
[22:52] <Riku-san> I want a tablet...
[22:52] <ogra_> there will be breakage everywhere no matter which of the options you chose
[22:52] <dobey> then install the tablet OS
[22:53] <Riku-san> not an android tablet
[22:53] <dobey> buy a different tablet then
[22:53] <dobey> or buy nvidia and release proper open source drivers that work on current platforms
[22:53] <Riku-san> find me a solution that doesn't involve spending money
[22:53] <Riku-san> or don't
[22:55] <ogra_> take the old release, upgrade to 14.04 using apt, use the fbdev xrog driver unaccelerated with lubuntu-desktop ... learn how to set up bluetooth keyboards via commandline, learn how to fix wlan drivers ...
[22:55] <popey> or ubuntu mate ☻
[22:55] <ogra_> yeah
[22:55] <Riku-san> bluetooth already works fine on ubuntu mobile
[22:55] <popey> but lubuntu might be leaner
[22:55] <popey> use that then!
[22:55] <popey> super, problem solved.
[22:55] <ogra_> yep, and didnt cost a cent :)
[22:55] <Riku-san> umm yeah unity on there uses 548 MB of the 976 MB of RAM
[22:56] <ogra_> uses 80MB here
[22:56] <Riku-san> but it general terms unity = bad
[22:57] <popey> Other desktops are available.
[22:57] <Riku-san> I know
[22:59] <dobey> use twm then
[22:59] <ogra_> wmx !
[22:59] <ogra_> oh,, damn ... wmx isnt in the archive anymore :(
[22:59] <ogra_> wm2 then
[23:00] <Riku-san> well that looks touch friendly...
[23:00] <dobey> you're trying to run libreoffice on a nexus 7, and you're worried about "touch friendly" ?
[23:01] <Riku-san> hmm although it would look really cool
[23:02] <popey> until you actually wanted to use it.
[23:02] <Riku-san> exactly!
[23:04] <Riku-san> wait, but unaccelerated graphics?
[23:04] <Riku-san> aww
[23:04] <Riku-san> the goal is here is actually to play minecraft
[23:04] <dobey> install android, install minecraft for android
[23:05] <Riku-san> dobey: not a solution
[23:05] <Riku-san> minecraft 1.8
[23:05] <Riku-san> not pocket edition
[23:05] <Riku-san> and don't say use a laptop
[23:05] <dobey> of course not
[23:05] <Tassadar> don't play minecraft)
[23:06] <dobey> find a pick axe, go find some rocks, start hammering away, and then in about 50 years, exhange all the gold you found for money, and buy a laptop
[23:06] <Riku-san> really there's nothing wrong with the ubuntu-mobile image except that touch stops working right mainly when using the unity dash or firefox
[23:06] <Riku-san> I have a laptop already
[23:06] <Riku-san> but it plays minecrtaft at 10 FPS and the battery lasts less than 20 minutes
[23:07] <dobey> you think running a java app on a nexus 7 is going to somehow do better?
[23:10] <Tassadar> hint: it's not
[23:11] <dobey> openjdk + minecraft 1.0 + nexus 7 == frozen
[23:11] <Riku-san> java 8 hardfloat + minecraft 1.8 + nexus 7 + UNITY == really laggy
[23:11] <Riku-san> java 8 hardfloat + minecraft 1.8 + nexus 7 - UNITY  == potentially playable
[23:12] <Riku-san> the difference is 500 MB of RAM
[23:13] <sarnold> Riku-san: maybe add some more swap? eventually most of unity would be paged out, right?
[23:13] <Riku-san> hmm maybe
[23:13] <Riku-san> but how?
[23:14] <sarnold> dd if=/dev/zero of=/something bs=10240 count=80000    -- or something similar, that ought to make an 800 megabyte file full of zeros -- then mkswap on the file, swapon with the file, check /proc/swaps to see that it worked
[23:16] <vars> hello!!!
[23:52] <Riku-san> btw what do I change the sources.list to?
[23:52] <popey> whats the goal?
[23:53] <Riku-san> do the sketchy update
[23:53] <popey> from what to what?
[23:53] <Riku-san> I was told to change them to the ones for 14.04 or something
[23:53] <Riku-san> from ubuntu-mobile 13.04
[23:54] <popey> this sounds unwise to me.
[23:54] <popey> but hey ho.
[23:54] <wolflarson> poooooooooooppey!!!!!!!!!!!11
[23:55] <popey> ʰᵉᶫᶫᵒ ʷᵒᶫᶠᶫᵃʳˢᵒᶰ
[23:56] <wolflarson> ubuntu touch is slow at times
[23:56] <wolflarson> can you fix?
[23:56] <wolflarson> do you think you can rewrite the whole thing really quick?
[23:57] <popey> sure thing.
[23:57] <wolflarson> thanks
[23:57] <ogra_> what ?
[23:57] <ogra_> the slowness is a feature !
[23:57] <wolflarson> oh ... now you tell me!?
[23:58] <popey> pay us extra and we'll slow it down some more
[23:58]  * wolflarson starts pulling out fistfulls of cash