=== duflu_ is now known as duflu [02:17] 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? === bremnes_ is now known as bremnes === nik90_ is now known as nik90 === awafaa_ is now known as awafaa === chihchun_afk is now known as chihchun === verterok` is now known as verterok [05:54] I have a QString, how can I convert it to a std::string, and its encoding is utf-8? === chihchun is now known as chihchun_afk === pitti` is now known as pitti === chihchun_afk is now known as chihchun [08:44] le huh, did we now drop the calculator from the standard install? [08:45] we shouldn't have. [08:46] 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] so nevermind, probably pilot error [08:46] \o/ [08:47] i. e. it's not in "click list" any more nor in the dash [08:47] you guys working hard on RTM, should i install it on my n7 instead of devel? [08:47] n7? do we support that even? (certainly not in RTM) [08:48] nexus7 [08:48] n7 2013 is supported [08:48] i mean i didnt receive any updates lately on devel version [09:00] 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] *promotion [09:01] so best stick to devel version? [09:01] 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] normally i see a lot of touch updates passing by, but i didnt for a time now [09:02] 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] think worldwide there's a lot of devel version testers [09:03] we cant make devel point to an empty channel [09:03] and a minimal requirement for a promotion is "it boots on all supported devices" [09:03] i see [09:04] 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] any news from bq and meizu yet? [09:09] http://www.gsmarena.com/meizu_mx4_with_ubuntu_touch_makes_an_appearance-news-9866.php [09:11] lotuspsychje: much of that meizu news comes from a random blog in italy it seems [09:11] not from meizu or canonical [09:11] so take that with a grain of salt ☻ [09:11] popey: yes i know still not official :p [09:11] its taking like ages :p [09:12] Making Phone OS's that could be used by millions is hard. [09:12] dvs doing a great job for sure on touch, easy stable and secure.. [09:13] devs [09:14] popey: the main problem is unsecure apps that users cant miss [09:14] there's many problems to solve, that may be one. [09:45] rhuddie: hey Richard! there: https://launchpad.net/ubuntu/+source/autopkgtest/3.7.1git2 [09:45] rhuddie: with full reboot support on touch :) [09:46] Good morning all; happy World Kindness Day! :-D [09:46] rhuddie: note that you need to call /tmp/autopkgtest-reboot (I updated the documentation accordingly) [09:46] pitti, that sounds excellent, thank you! [09:46] 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] pitti, I'll give it a try shortly. thanks :) === ara is now known as Guest56698 [10:44] Chipaca, hey [10:44] seb128: hi [10:44] Chipaca, replying here to the depends thing [10:44] seb128: listening [10:45] Chipaca, what is using -dbus or glib? [10:45] is that pyxdg? [10:45] 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] seb128: the helper itself uses them [10:46] how did it build before? just by luck/because something else was pulling those in? [10:46] seb128: and the package does depend on them [10:47] 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] ) [10:47] ok, so those are not really build-depends [10:47] e.g it would still be fine without them? [10:47] yes [10:48] 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] oh [10:49] Chipaca, sorry, segfaulted xchat-gnome [10:49] heh [10:49] 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] seb128: (i think that's all you missed) [10:49] Chipaca, ok, makes sense to me, thanks [10:50] Chipaca, approved [10:50] seb128: tks [10:51] seb128: do you know if anybody else is putting u-s-s on the train any time soon? [10:52] Chipaca, we almost have daily landings, so yeah no worry about that [10:52] Chipaca, silo 003 [10:52] waiting for the thaw [10:52] (and i see you have 014 too) [10:52] (for testing) [10:52] yeah, 014 was for testing this (for help with reproducing & understanding a bug) [10:53] and was against rtm [10:53] but then i thought this should be there all the time anyway, hence this === Zic_ is now known as Zic === daker__ is now known as daker === justCarakas1 is now known as justcarakas_ === chihchun is now known as chihchun_afk [11:30] mvo_: hello, are you active? [11:31] * didrocks systemctl enable mvo_.service :) [11:32] bzoltan: well, sort of, need tea, otherwise active [11:34] mvo_: Just a quick question. Do we have vivid click chroots? If not then when it is scheduled? [11:34] 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] bzoltan: its directly generated from these two packages so if you want to adjust the framework, you can just do it via the metapkg === chihchun_afk is now known as chihchun [11:37] mvo_: ohh, I am silly to ask that late. It is available for ten days... One more question :) [11:39] 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] 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] Hmm, System Settings launches so slowly now that the phone locks before it’s done [11:42] g 141 [11:42] er, ignore me.. [11:43] mvo_: that would be the best [11:44] mvo_: but do you think it is safe to automatically release the trunk of the lp:click? [11:44] mvo_: or is it holly trunk like the UITK trunk? :) [11:44] bzoltan: we use lp:click/devel for the development, once it lands in trunk its usually released [11:44] (or I messed up lallaalala) [11:45] mvo_: Okey, so it is a holly trunk... [11:45] 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] mpt, not here [11:45] under 3 secomds [11:46] mvo_: for the UITK project I do it since the beginning [11:46] bzoltan: cool, thats even easier then :) [11:47] ogra_, took about 6 minutes here :-/ [11:47] I thought it was stuck [11:48] wow [11:49] 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] :) === greyback__ is now known as greyback === MacSlow is now known as MacSlow|lunch === dandrader is now known as dandrader|afk === alan_g is now known as alan_g|lunch === dandrader|afk is now known as dandrader === MacSlow|lunch is now known as MacSlow [13:33] seb128, is the contents of indicator-messages controlled by unity8 or something? [13:34] mpt, the UI elements are [13:34] or ubuntu-settings-components === justcarakas_ is now known as justcarakas === alan_g|lunch is now known as alan_g [14:04] kenvandine, So I modified the autopilot test in u-s-s, how do I run it? [14:06] zsombi: please join #ubuntu-uds-appdev-1 [14:06] tedg, hang on, in a meeting [14:07] kenvandine, Tell those people I'm more important! ;-) [14:10] $ autopilot3 run ubuntu_system_settings.tests [14:10] jgdx, In which directory? [14:10] add modules for more specific runs (autopilot3 run ubuntu_system_settings.tests.test_cellular.CellularTestCase.test_change_carrier) [14:10] tedg, tests/autopilot [14:10] tedg, tests/autopilot [14:11] K, cool. Seems I'm missing packages. [14:11] It seems to be calling /usr/bin/system-settings [14:13] tedg, it needs to be installed, to find your plugin changes [14:13] Oh [14:14] not so much for the tests [14:14] but the plugins that get loaded will be from /usr/share [14:14] and it's going to run /usr/bin/system-settings [14:14] but it'll run the autopilot tests from your checkout if you are in the right directory [14:15] Okay, so let me build packages. [14:18] I do $ sudo make install && ln -s /usr/local/bin/… /usr/bin/… [14:18] scores 10 on the dirt-o-meter === JMulholland_ is now known as JMulholland [14:20] Oh, my. Yes. We should purge that suggestion from the IRC logs. :-) [14:21] jgdx, you better make install DESTDIR, easier to make sure you don't corrupt your system install [14:24] but if my system is not corrupted, how will I learn [14:25] you mean "learn how the installer works" ? [14:26] lol [14:26] that's how we ensure ubiquity gets regular testing!: [14:27] :) [14:28] Noskcaj, ubuntu is surprisingly resilient. You can throw a lot of stupidity at it before it buckles. [14:29] Noskcaj, tab failure, sorry [14:37] pitti: still having problems w/adt-run on device: http://paste.ubuntu.com/8988046/ [14:37] pitti: notice line 110 [14:38] pitti: that *ought* to be a valid option, but apt on the device is complaining. [14:39] 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] 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] but yeah, that looks really odd; it's an -o, after all [14:40] pitti: yeah! :) [14:41] barry: do you get the same error if you run that command with phablet-shell? [14:41] barry: (you can try and install aspell-doc or something similarly trivial) [14:41] pitti: let me try that [14:42] 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] pitti: apt | 1.0.9.2ubuntu2.is.1.0.4ubuntu7 | ubuntu-rtm/14.09 | source, amd64, armhf, i386 [14:45] pitti: i'm not exactly sure what that version number means ;) [14:47] $ 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] barry: ^ hm, working fine here [14:47] and I have 1.0.9.2ubuntu2.is.1.0.4ubuntu7 [14:47] barry: I figure 1.0.9 broke something and they quickly reverted it [14:48] barry: I'll try to reproduce with an adt-run line like your's [14:48] yep, that command works fine for me too [14:48] pitti: ^^ [14:49] pitti: i can provide .dsc and .debs if you want to try to reproduce exactly. also fwiw, host is on vivid [14:49] barry: host> same here; do we have any other desktop release? :-) [14:50] pitti: there's this rumored 'devel' release :) [14:50] barry: yeah, but I've heard it's really hard to tell the difference [14:51] Setting up testpkg (1) ... [14:51] barry: hm, so doesn't reproduce with my little local test package [14:52] 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] pitti: what does `system-image-cli --info` say in phab-shell? [14:52] barry: http://paste.ubuntu.com/8988270/ [14:54] 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] barry: let me create an emulator with stable; may be easier than destroying your device [14:55] Creating "rtm" from ubuntu-touch/ubuntu-rtm/14.09 revision 6 [14:55] barry: ^ that sounds like it would match? [14:55] pitti: it does [14:56] * barry hopes that -proposed wouldn't put his device on phaser overload [14:56] barry: I've never ran stable on any of my devices :) [14:56] pitti: it does seem quaint :) [14:56] but then again I don't use it for "production" either, I just destroy the installs too quickly :/ [14:58] I just upgraded to image #159 on krillin, and wifi won’t connect, is that a known issue? [14:59] 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] barry: and even then, the error messages should look totally different [15:00] pitti: correct. 0000 [15:00] kenvandine, I just relaunched System Settings: 2 minutes 34 seconds. So, what should I provide? [15:00] . o O { security! half of the company uses that :) } [15:00] the "give me adb, dammit!" passcode [15:01] mpt, ok, grab a couple of log files [15:01] ~/.cache/upstart/unity8.log [15:01] ~/.cache/upstart/dbus.log [15:01] barry: still works in rtm-proposed emulator, trying rtm now [15:02] ~/.cache/upstart/application-legacy-ubuntu-system-settings.log [15:02] you can just pastebin those [15:02] barry: oh, I found some more differences; I used -B, you didn't; will also try with that [15:03] 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] barry: oh, specifying a .deb on the CLI does *not* install it [15:04] 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] 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] barry: ok, I tried without -B on rtm (#6), and it still works [15:05] 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] kenvandine, forgive me, I’ve forgotten how to copy files from the phone [15:06] 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] barry: so I suggest I'll try with your .deb/.dsc? [15:06] 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] pitti: yep, let me upload them [15:07] barry: conversely, do you get the error with -B? [15:08] pitti: p.c.c:~barry/pitti/* [15:08] barry: 404 [15:09] kenvandine, and clicking on the phone in Nautilus does nothing at all :-/ [15:09] mpt, sorry... use adb [15:09] (I guess that’s a separate bug) [15:09] adb pull /home/phablet/.cache/upstart/unity8.log . [15:09] barry: ooh, I looked in http://people.canonical.com/~barry/, nevermind [15:09] adb pull /home/phablet/.cache/upstart/dbus.log . [15:09] pitti: chmod'd [15:09] adb pull /home/phablet/.cache/upstart/application-legacy-ubuntu-system-settings.log . [15:09] barry: (i. e. I looked in public_html); I'll scp them [15:09] pitti: oops, yeah [15:10] kenvandine, the last of those doesn’t exist [15:10] adb pull /home/phablet/.cache/upstart/application-legacy-ubuntu-system-settings-.log . [15:10] sorry, i typo'd it [15:11] * kenvandine blames tedg for the annoying trailing - there :) [15:11] barry: orig.tar.gz, s'il vous plaît ? [15:11] barry: (and debian.tar.gz) [15:12] kenvandine, Patches welcome ;-) [15:12] tedg, it's more fun to blame you :) [15:12] * tedg lies, he doesn't really want patches from kenvandine ;-) [15:12] pitti: uploaded [15:15] barry: hah! [15:16] kenvandine, thanks, I reported bug 1392349 with those three files [15:16] bug 1392349 in ubuntu-system-settings (Ubuntu) "System Settings takes minutes to launch" [Undecided,New] https://launchpad.net/bugs/1392349 [15:18] mpt, thx [15:18] 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] pmcgowan, i attached that info to bug 1337200 [15:18] bug 1337200 in ubuntu-system-settings (Ubuntu) "High CPU due to excessive device changed signals from upower" [High,Incomplete] https://launchpad.net/bugs/1337200 [15:18] pitti, ^^ the upower info [15:18] pitti: i am the Breakor Of Things [15:18] pitti: do tell! [15:19] barry: sorry, no, davmor2 is that already; at most you can be his depoty [15:19] deputy [15:19] * barry is the Assistant Breakor Of Things [15:19] barry: and I re-confirmed it on rtm-proposed now [15:19] pitti: a bug in apt? [15:19] barry: drilling down now [15:20] ack [15:20] pitti: but once the obvious bugs are out of the way it only leaves the obscure thems the rules [15:30] barry: meeting now, will continue after that [15:31] pitti: thanks [15:35] kenvandine, how'd you fix otto the last time around? [15:36] besides kicking it [15:36] poked the qa folks === dandrader is now known as dandrader|lunch === alan_g is now known as alan_g|tea [15:52] 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] jgdx, kenvandine, What is "klass.dbus_con" and how can there be only one? === alan_g|tea is now known as alan_g === dandrader is now known as dandrader|bbl [16:07] mpt, are you sure you're on rtm proposed r6? [16:07] rtm proposed is currently at r159? [16:09] kenvandine, oh, my mistake. I reflashed on Tuesday. I’m on r214. [16:09] hmmm... still doesn't sound right :) [16:11] adb shell system-image-cli -i [16:11] mpt, ^^ [16:12] kenvandine: stable is r6 i think [16:12] barry, yeah, but what's r214 [16:12] kenvandine: proposed i think [16:12] i'm on 159 for rtm proposed [16:13] ah. then idk :) [16:13] http://paste.ubuntu.com/8989429/ [16:13] so wondering what channel mpt is on [16:14] kenvandine, channel: ubuntu-touch/ubuntu-rtm/14.09-proposed-customized [16:15] i have no idea what's in that channel :) [16:15] barry, is there a way for me to see what package versions are in a channel? [16:16] 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] kenvandine: i don't think there's a manifest on s-i.u.c [16:17] jgdx, I did that, but I don't know what variable has the session bus, or where it goes. [16:17] "version_detail": "ubuntu=20141111,device=20141106-572f18d,custom=20141110-423-19,version=214" [16:18] so i guess 20141111 is what's important there [16:19] thats a cwayne test channel [16:19] for testing custom tarballs [16:19] tedg, spawn_server returns the connection object. [16:19] yeap [16:21] tedg, are you trying to mock the gactions? [16:22] tedg, jgdx said it's hard to mock gactions... you should fix that [16:23] (hard for me, not necessarily hard for others) [16:26] kenvandine, I'm trying :-) [16:27] jgdx, Yeah, I have it "written" now I'm trying to get it to run ;-) [16:28] kenvandine, should I not be using that channel? [16:29] (I don’t remember having a definite answer to “Which channel should I be testing”) [16:29] mpt, most of use use 14.09-proposed [16:29] mpt, that's not causing your bug though (or i doubt it) [16:29] just hard for me to know what versions of packages you have [16:30] mpt, i still don't see anything in your log that screams out to me as an issue [16:30] kenvandine, should I flash 14.09-proposed and retest? [16:30] mpt, is your device plugged in while you are starting it? [16:30] mpt, not yet [16:30] but yes you should switch channels [16:31] kenvandine, starting the device, or starting System Settings? [16:31] starting settings [16:31] (I don’t remember, and yes, respectively) [16:31] can you reboot your device and start settings without it being plugged in? [16:31] ok, bbi5m [16:33] * mpt waits for the Dash to finish loading first [16:34] kenvandine, 5 seconds [16:34] 4 seconds, 5 seconds [16:35] i'm thinking you might have been suffering from bug 1337200 [16:35] bug 1337200 in ubuntu-system-settings (Ubuntu) "High CPU due to excessive device changed signals from upower" [High,Incomplete] https://launchpad.net/bugs/1337200 [16:35] your dbus.log has tons of these [16:35] (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] kenvandine, jgdx, how do I know if the autopilot tests pass? Because they don't fail? [16:36] which i see spamming the log when upower is DOS'ing dbus [16:36] i have no idea how to figure out what causes those warnings [16:36] tedg, ^^ any suggestions? [16:36] tedg, it'll say OK [16:36] i think [16:37] if there are failures it gives you stats on pass/total [16:38] Ah, there we go. dbus-test-runner was timing out. [16:38] if i tail dbus.log while dbus-daemon is chewing cpu... i see these warnings constantly [16:38] makes me think it's a warning from something listening to upower [16:39] and mpt's dbus.log is just full of those warnings [16:39] I think the only people listening to upower are system settings and indicator-power. [16:39] yes [16:40] and upower in rtm seems to DOS dbus [16:40] which causes system-settings to hang [16:40] I think that upower just passes events, so it's more the battery provider. [16:40] yes [16:40] and i confirmed there are lots of change events [16:40] File a bug on the kernel :-) [16:41] but... those don't seem to get emitted on vivid [16:41] with upower 0.99 === chihchun is now known as chihchun_afk [16:41] which is less noisy [16:41] Perhaps that's the fix, or different HW? [16:41] kenvandine: your udevadm log just had 4 events every 10 s, that's not exactly "excessive"? [16:41] we saw it on mako and krillin in the past [16:41] pitti, that was just over a minute [16:42] 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] i ran the same thing on my mako on vivid and had none of the power_supply change events [16:42] kenvandine: but I take it you did that during a time when system-settings was spinning 100%? [16:42] pitti, no... it wasn't [16:42] oh [16:42] that was just idle [16:42] well, then it doesn't say anything [16:43] and the system was sleeping [16:43] why change events when nothing changed? [16:43] pitti, i think what happens is settings is connected to those signals, and it sleeps [16:43] kenvandine: well, because that was the theory -- lots of batter change events which are propagated through upower to system-settings [16:43] after a while when the app resumes [16:44] it gets all the signals [16:44] so if you leave it plugged in for 8 hours sleeping [16:44] and resume the app [16:44] it gets flooded [16:45] pitti, so i'm thinking the problem is it's constantly sending those changed events, when nothing changed [16:45] ok; we'd still need the udevadm log to confirm that then [16:46] i. e. whether it's the android battery driver or upower going crazy after suspend [16:47] pitti, i was thinking it was all the dbus signals being sent to the subscriber when the subscriber resumes [16:47] not necessarily when upower wakes [16:47] just the fact that they happened while settings was suspended [16:47] pitti, so on vivid, none of the only change events i see is on battery [16:47] not on ac, usb and wireless [16:48] kenvandine, pitti I added the upower output but just saw your comment [16:48] need to let it sit a while again [16:49] kenvandine: ah, you figure that dbus-daemon or whatever queues up the signals for subscribers, and flushes them [16:49] ... once they resume [16:49] so that they don't lose signals [16:49] right [16:49] that would actually make sense [16:49] 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] right [16:49] well [16:49] and the fact that these change events keep happening when there isn't a real change [16:49] makes them queue up pretty fast [16:50] 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 === chihchun_afk is now known as chihchun [16:50] we see quite some noise of upower, dbus and indicator-power in smoke testing [16:50] yeah [16:50] pitti, i fear trying to do that will lead to lots of bugs [16:50] but so far it wasn't clear at all what's triggering those [16:50] we have this "systemsettle" test ... where we check if the system goes back above 95% idle state [16:50] pitti, the situation is much better in vivid with upower 0.99 [16:50] ogra_: yeah, I know [16:50] and these three usually are the noisy ones in the top ouotput in this test [16:51] oh, right, i told you already [16:51] ogra_: yeah, 5 change events from various sources (even AC!) every 10 s does pile up [16:51] yup [16:51] so AC change events are indeed a bit pointless [16:51] it seems the android drivers just send out change events every 10 s no matter what [16:51] well, there must be a way to quieten them [16:51] pitti, so in 0.99 those just aren't being forwarded right? [16:52] (on the driver side) [16:52] kenvandine: hm, that's surprising, as the data flow didn't really chagne; the particular signal changed, though [16:52] in 0.99 i only see the battery change [16:52] every 10s [16:52] ogra_: yeah [16:52] ogra_: it seems rather simplistic [16:52] the changelog said something about quieting those signals [16:52] as if the AC change wouldn't generate a proper interrupt or so which would then trigger a change event [16:52] like upower is smarter about it [16:52] battery events need to happen regularly, I get that [16:53] right [16:53] so 0.99 is perfect :) [16:53] kenvandine: ah, so it might receive the uevents for AC, but see that the status didn't change and thus use that? [16:53] kenvandine: ... to determine to not send another signal? [16:53] could be [16:53] right [16:53] it doesn't solve the fundamental problem of signals queueing up during suspended apps, though? [16:53] i think that somethign like that was in the 0.99 changelog [16:53] not really [16:54] but... it's usually not like this ;) [16:54] as the battery level does change a lot all the time, so what works for AC doesn't work for battery [16:54] 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] - Remove DeviceChanged and Changed signals (PropertiesChanged [16:55] signals are sent instead) (Bastien Nocera) [16:55] pitti, ^^ [16:55] so the PropertyChanged signal is probably smart enough to not happen when there is no change [16:55] kenvandine: ah, and I guess that implicitly provides the "property didn't really change" filtering [16:55] right [16:55] kenvandine: so upower itself would still wake up 4 times every 10 s [16:55]