[05:16] <pitti> Laney: sure you can mock upower in autopilot tests; whatever makes sense (i. e. unless you are testing upower itself)
[09:04] <Laney> morning
[09:05] <Laney> hey pitti, thanks - was just wondering if that kind of thing is usually done for those tests, or if it should be testing the whole system
[09:05] <pitti> Laney: usually not; if you try to test too many things at once, tests tend to become flaky and too hard to analyze
[09:05] <Laney> indeed
[09:06] <pitti> Laney: I have this "ladder" picture:
[09:07] <pitti> test the kernel against real hw, test system services like upower against simulated kernel output (like with umockdev), test userspace/session stuff like indicator-*-service against mocked d-bus services (dbusmock), test UIs against session d-bus mocks
[09:08] <pitti> Laney: so if your autopilot test is supposed to check the UI, feel free to mock anything underneath it where the real thing is impractical to set up
[09:09] <pitti> seb128: bonjour, ça va ?
[09:09] <seb128> pitti, salut, oui, et toi ?
[09:10] <pitti> seb128: FYI, I uploaded autopkgtest, but from your POV this is mostly a cosmetical fix
[09:10] <Laney> pitti: neat, I want to do that because we have UIs which respond to the number of batteries and things so it'd be good to test the different scenarios
[09:10] <Laney> hey seb128
[09:10] <seb128> pitti, right, I just saw the emails, thanks! (and yeah, that's orthogonal to the bug)
[09:10] <seb128> hey Laney, how are you?
[09:10] <pitti> seb128: you need to fix the stderr output for gtk, by either updating the test to avoid the deprecation warning, or by redirecting stderr
[09:10] <seb128> pitti, I fixed that yesterday, and wanted to test another change and then it was eod and I didn't manage to upload
[09:10] <pitti> seb128: (the former obviously being better, as we want to fail on unexpected warnings)
[09:11] <pitti> seb128: and gnargh for gcc not respecting the locale :)
[09:11] <pitti> seb128: ah, great
[09:11] <seb128> I'm going to upload in a bit
[09:11]  * seb128 reads http://news.cnet.com/8301-1035_3-57615107-94/ubuntu-touch-os-wins-its-first-smartphone-partner/
[09:11] <pitti> Laney: yes, that's precisely the case where a mock is better; we have tests to ensure that the mock is compatible to the real upower
[09:11] <pitti> seb128: just did that as  well
[09:11] <pitti> seb128: my first thought: "OMG, would you give this man $5M?" :-)
[09:12] <seb128> hahaha
[09:12]  * pitti liked sabdfl better without the beard
[09:12] <xnox> pitti++
[09:12] <Laney> hahaha
[09:12] <Laney> it's trendy these days you know
[09:13] <xnox> Movember is over.
[09:14] <Laney> nah, it's wider than that - see Paxman, Ben Affleck etc
[09:27] <xnox> pitti: my mailer sucks -> for i in `ls /run/user/*/upstart/sessions/*.session`; do (export `cat $i`; initctl restart indicator-session) ; done
[09:27] <xnox> one-liner.
[09:28] <Laney> can't system upstart rebroadcast events to session upstart?
[09:29] <seb128> xnox, pitti, Laney: we should just tell the user to restart the session
[09:29] <seb128> other stuff are not going to work
[09:30] <seb128> e.g nautilus "change background" desktop menu
[09:30] <Laney> yup
[09:36] <xnox> Laney: it rebroadcasts events, but "restarting" something is not an event.
[09:37] <Laney> you could have an event which causes that to happen
[09:37] <xnox> Laney: it's a direct action / changing goals which only controlling init can do via dbus api. I guess we could make restart honour "--global" and do it across all active sessions.
[09:37] <xnox> Laney: there is no "restart on", only start on and stop on.
[09:38] <Laney> exec restart foo
[09:38] <xnox> how is that any better than doing it byhand for each session? =)
[09:39] <xnox> we already have one such restart job though (it's to tell inits to reconnect to system init, upon system init re-exec)
[09:39] <xnox> Laney: i presume you mean add a user-session job task which does: exec restart $JOB_TO_RESTART. And then system init just emits an event for that to happen.
[09:40] <Laney> Some generic thing like that, yeah
[09:40] <xnox> well we can even do $COMMAND_TO_RUN $JOB_TO_RESTART as well.
[09:41] <Laney> Not sure what I think about it philosophically
[09:41] <Laney> the golden rule and all
[09:42] <xnox> it does sound to me as abusing the rules, on the other hand the postinst only need to succeed / check that it emitted the system event successfully, and need not to care if there are any session inits running, or whether they have indicator-session running, if whether that restarted or not. So it would be embracing the event base pagadim.
[09:42] <xnox> not sure if that is taking it too far or not ;-)
[09:43] <xnox> then again on touch, i hope we will stop apps on upgrade via upstart.
[09:47] <seb128> didrocks, sil2100, Mirv: hey, so ubuntu-system-settings trunk has an autopilot packages with some tests now  ... how do we get that plugged into CI?
[09:48] <mpt> ara, cyphermox: For bug 861171, have you decided whether the confirmation of terminating other sessions should require you to authenticate or not?
[09:48] <ubot2> Launchpad bug 861171 in OEM Priority Project precise "Shutdown from greeter does nothing when multiple accounts open" [High,In progress] https://launchpad.net/bugs/861171
[09:49] <sil2100> seb128: I guess for CI-per-merge we would need to poke Francis (or someone else from the QA team that knows his way around) - as for cu2d, we can do that
[09:49] <Mirv> cu2d part via  lp:cupstream2distro-config indeed
[09:49] <sil2100> seb128: but we're not really using cu2d that much for testing as we were in the past
[09:50] <seb128> sil2100, well, I'm not uptodate on those stuff, when are autopilot tests run nowadays and how do we get u-s-s ones added there?
[09:50] <seb128> e.g what do you recommend to do?
[09:50] <Laney> first test that they pass in whatever configuration they will be run in
[09:50] <Laney> ;-)
[09:50] <seb128> wfm
[09:51] <seb128> Laney, are you speaking about your uitk bug with /usr/local?
[09:51] <seb128> I don't think that should block CI enablement
[09:51] <sil2100> seb128: ok, we can add those to cu2d if anything, can do that in a moment
[09:51] <seb128> sil2100, thanks!
[09:52] <seb128> Laney, I hope CI machines don't have stuff sudo make installed in /usr/local :p (not cookie to you for doing that btw, even if it allowed you to find a bug ;-)
[09:52] <Laney> haha
[09:52] <didrocks> sil2100: can you take care of that one please? :)
[09:53] <didrocks> thanks!
[09:53] <Laney> I am not blocking anything
[09:53] <Laney> I'm just saying that it should actually pass before turning it on
[09:53] <Laney> also it was from bisecting evolution to find a bug
[09:53] <Laney> also you only need to have an empty directory there, not even anything installed!
[09:54] <Laney> and lastly the tests fail if you don't have a battery ;-)
[09:55] <seb128> Laney, well, tests pass for Victor (who submitted them) and for me
[09:55] <seb128> Laney, I didn't know about the battery one, seems like one thing to fix indeed
[09:55] <Laney> you're arguing for not trying them out?
[09:56] <seb128> Laney, are they working for you out of that one? or do you have other issues?
[09:56] <seb128> hum
[09:56] <Laney> just that one
[09:56] <seb128> no, I'm not "arguing"
[09:56] <seb128> for me they are passing
[09:56] <seb128> so I didn't understand your "I'm just saying that it should actually pass before turning it on"
[09:56] <Laney> I mean that we should know they pass in the test environment
[09:56] <seb128> oh
[09:56] <Laney> I suppose we'll get that at the first run anyway
[09:56] <seb128> how do we do that?
[09:57] <Laney> but it'll be annoying if it all explodes
[09:57] <seb128> e.g can we connect to the test environment and run them there manually?
[09:57] <Laney> not sure
[09:57] <seb128> sil2100, ^
[09:58] <sil2100> seb128: yes, it can be done
[09:58] <sil2100> seb128: once the stack is redeployed with the config we can do a manual run of the tests there
[09:58] <seb128> sil2100, can anyone do that/how?
[09:59] <Laney> sounds fine
[09:59] <sil2100> seb128: anyone that has cu2d power can do that by going to the AP trusty jobs and firing them manually with stack parameters
[10:00] <seb128> sil2100, ok, I'm not sure I want to look at that today, can you do it for us? ;-)
[10:00] <sil2100> seb128: sure :) I'll do it right after the setup and inform you
[10:00]  * Laney is looking at mocking upower atm to test the battery / no battery case
[10:00] <seb128> ogra_, hey, new webkit in trusty should fix the software-center issues, let me know if it works for you (I want confirmation before SRUing to saucy)
[10:00] <Laney> then soon other things
[10:01] <ogra_> seb128, wil test
[10:01] <seb128> Laney, I'm sure there are upower mocks you can copy from other places (maybe indicator-power?)
[10:01] <Laney> yes, afaik dbusmock already has a template
[10:01] <Laney> using that one
[10:01] <seb128> good
[10:01] <seb128> Laney, https://blueprints.launchpad.net/ubuntu/+spec/client-t-system-settings-testing
[10:02] <seb128>  [seb128] power - use pitti's upower mock to test current charge/status: TODO
[10:02] <Laney> ah
[10:02] <Laney> this isn't that, can leave that for you if you want
[10:02] <seb128> that's what we wrote down back then
[10:02] <seb128> no, that's fine
[10:02] <Laney> it's for the visibility of the battery panel
[10:02] <Laney> still testing the main screen
[10:02] <seb128> I had a feeling we discussed that topic a bit on Oakland, I was looking if the notes had details
[10:02] <seb128> right, please do it
[10:03] <seb128> I doubt I'm going to work on that before holidays
[10:03] <Laney> nod
[10:03] <seb128> so feel free to also steal the other ones from me
[10:03] <seb128> e.g if you are started on that and feel bored next week
[10:03] <seb128> ogra_, thanks
[10:03] <Laney> I'll likely do the ones I'm assigned to first
[10:03] <Laney> but we'll at least have examples of using dbusmock by then
[10:04] <seb128> yep, sounds good
[10:26] <pitti> Laney: python[3]-dbusmock ships a standard upower template, with some convenience functions
[10:26] <pitti> ah, you found out already
[10:26] <Laney> yeah
[10:38] <sil2100> seb128, Laney: I have some test results: http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/920/ - there seems to be 1 test failing per platform
[10:38] <sil2100> The battery plugin one
[10:39] <Laney> nod
[10:39] <Laney> where can I see the run?
[10:40] <Laney> the console output is super verbose
[10:40] <sil2100> Laney: go to nvidia for insantce, you can then click on the specific test that failed
[10:40] <sil2100> Laney: e.g. http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/920/label=autopilot-nvidia/testReport/junit/ubuntu_system_settings.tests.test_plugins/SystemSettingsTestCases/test_battery_plugin/
[10:40] <Laney> k
[10:40] <Laney> fixing that one atm anyway
[10:40] <sil2100> Thanks :)
[10:41] <seb128> those people have no battery :p
[10:42] <seb128> sil2100, thanks for running the tests!
[10:42] <sil2100> seb128: yw!
[10:48] <seb128> sil2100, didrocks: could you review/ack https://code.launchpad.net/~seb128/gnome-control-center-unity/gettext-and-intltool/+merge/196545 ?
[10:49] <didrocks> seb128: I guess you tested it? :)
[10:50] <seb128> didrocks, sure, CI also confirmed the fix
[10:50] <seb128> since it built
[10:50] <seb128> where https://code.launchpad.net/~seb128/gnome-control-center-unity/launcher-minimal-value hit the error
[10:50] <didrocks> approved
[10:50] <seb128> 'ci
[10:50] <didrocks> de rien ;)
[11:09] <seb128> happyaron, hey, could you look at https://launchpad.net/ubuntu/+source/libchewing/0.3.5-3, the autopkgtest added seems to lack build-depends (on pkg-config at least, see https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-libchewing/)
[11:10] <happyaron> seb128: ok, will do
[11:10] <seb128> happyaron, thanks
[11:11] <seb128> happyaron, https://launchpad.net/ubuntu/+source/ibus-chewing/1.4.3-4 as well would be nice
[11:11] <seb128> seems an incompatibility with our ibus version?
[11:12] <happyaron> didn't see incompatibility in Debian (binary works), but will check again in trusty
[11:13] <seb128> well, it fails to build on undefined stuff so I was guessing
[11:13] <happyaron> the failing point looks like "IBUS_INPUT_PURPOSE" related, so it's the 1.5.4 CVE related I think.
[11:14] <happyaron> thinks I need to try all ibus-* to see what happen.
[11:14] <ara> mpt, I don't have a strong opinion, but I prefer your version "B" (need the person's password, but not admin rights)
[11:14] <mpt> ok
[11:15] <ara> mpt, I think that requiring a password will make people read the message
[11:15] <ara> if a password is not required, people won't read and think that it is a normal confirmation for shutdown dialog
[11:17] <mpt> makes sense
[11:19] <mpt> ara, the tradeoff is that a PolicyKit dialog can’t include a button to log out instead (or to switch user account, if the other account(s) belongs to you as well)
[11:19] <Laney> neat, got u-s-s to believe it has a battery
[11:22] <ara> mpt, yeah, I still think having a password is better. what's your opinion?
[11:24] <mpt> agreed
[12:07] <Trevinho> seb128: hey, is there any plan to include cairo 1.14 in trusty? It supports surface_device_{set,get}_scale that is used by gtk-3.10 for hight-dpi screens...?
[12:08] <Trevinho> (and we might reuse it as well)
[12:10] <pesari> hey, I want to set some system-wide defaults for our users (for example gnome-terminal).. is it preferable to set them in /etc/dconf or /usr/share/glib-2.0/schemas ?
[12:11] <pitti> Laney, seb128: do you plan a glib2.0 upload soon?
[12:11] <pitti> if not, I'd do one for bug 1259721
[12:11] <ubot2> Launchpad bug 1259721 in glib2.0 (Ubuntu) "Executing autopilot test suite fails to close when piped to tee" [Medium,In progress] https://launchpad.net/bugs/1259721
[12:11] <pitti> actually no, it's sufficient to just add them in gobject-introspection
[12:13] <Laney> nod
[12:34] <ogra_> seb128, works fine ! thanks a lot
[12:38] <Laney> pitti: what about something like this: http://paste.ubuntu.com/6555832/?
[12:40] <Laney> I would have liked to have been able to just annotate the testcases that explicitly want or don't want a battery somehow but I didn't see a way to do that
[12:40] <Laney> as the setUp() launches u-s-s so you have to do it before that
[12:43] <pitti> Laney: I don't understand -- usually you'd call Add*Battery() in the actual test case, not in setUp() or so
[12:44] <seb128> Trevinho, hey, is there a such release? there was not a few days ago, I pinged #cairo to ask if they still plan to make those changes into a stable release but got no reply
[12:44] <seb128> ogra_, \o/
[12:44] <seb128> ogra_, thanks for testing
[12:44] <seb128> pitti, no plan to upload glib, that's Laney's nowadays ;-)
[12:45] <pitti> Laney: btw, with the recent version this can become easier -- start the mock in setUpClass(), in setUp() or tearDown(), call self.obj_upower.Reset(), and drop the other cleanup and wait()/terminate()
[12:45] <ogra_> np :)
[12:45] <Trevinho> seb128: oh.. I'm not sure about releases... I was checking on the git repo and it was targetted as that release
[12:45] <pitti> Laney: well, if u-s-s doesn't react to adding a battery, that's a bug
[12:45] <Trevinho> seb128: I see tarballs at http://cgit.freedesktop.org/cairo/
[12:45] <pitti> Laney: you mean u-s-s only reads the battery props at startup?
[12:45] <pitti> Laney: running out for some (overdue) lunch, bbl
[12:46] <seb128> Trevinho, where? I only see 1.12 ones there
[12:46] <Trevinho> seb128: yeah, right...
[12:46] <Trevinho> seb128: the minor version confused me
[12:46] <Laney> pitti: Hrm, interesting
[12:46] <seb128> Trevinho, http://lists.cairographics.org/archives/cairo/2013-September/024594.html
[12:46] <seb128> Trevinho, that was the plan but that never happened
[12:46] <Laney> pitti: We ask if there's a battery at startup but don't carry on checking it after that
[12:47] <seb128> Trevinho, but otherwise yes, one of the reason we updated GTK to 3.10 was to have better hdpi support in the LTS
[12:47] <pitti> Laney: that's a bug (and nice that you just wrote a test for it :) )
[12:47] <larsu> haha
[12:48] <Laney> hmmmm
[12:48] <Laney> yeah, I never even thought of that
[12:48] <Laney> interesting
[12:48] <Laney> veeeeeeeeeeeeeeeery interesting
[12:49] <Laney> ok, let's fix that :P
[12:49] <larsu> Laney: you can add/remove batteries during runtime, you know
[12:49] <Laney> I never ever even considered that
[12:49] <Laney> hotplugging batteries? madness!
[12:49] <larsu> ya, it's becoming more unusual (and I don't think it's possible on mobile devices)
[12:49] <pitti> Laney: but in a way, both tests are useful, coldplug and hotplug
[12:50] <pitti> Laney: you might get the hotplugging right and still do something wrong at coldplugging
[12:50] <Laney> right
[12:50] <pitti> Laney: so for the coldplugging case, either do two classes (with/without battery) as you did, or start u-s-s after configuring upower
[12:50]  * pitti hotplugs his laptop battery all the time *shrug*
[12:51] <Laney> I'll make the hotplugging case work and move the battery adding code up into the parent class where you can call it after starting u-s-s
[12:51] <Laney> exciting
[12:51] <Laney> I'd have to unscrew my laptop to take the battery out
[12:51] <Laney> apple :(
[12:51] <larsu> english speakers: "scroll backward" or "scroll backwards"?
[12:51] <pitti> what is u-s-s anyway? ubuntu-system-service? unity-screen-saver?
[12:51] <Laney> system-settings
[12:52] <pitti> Laney: non-replacable battery> cf. "bug" :)
[12:52] <Laney> larsu: backwards sounds better to me, but I'd probably need to see a full sentence
[12:52]  * pitti really lunch now &
[12:52] <Laney> gerrout of here
[12:52] <larsu> Laney: it's just for an action name, so only these two words. I lean towards scroll backwards as well, but it was "backward" before
[12:52] <larsu> Laney: thanks :)
[12:56] <Laney> np1
[12:56] <Laney> !
[14:18] <seb128> Laney, I guess you are going to review https://code.launchpad.net/~attente/ubuntu-system-settings/1252489/+merge/198335 ? (I didn't follow the details of that discussion)
[14:18] <Laney> seb128: Will do in a bit, yeah
[14:18] <Laney> heinously sidetracked atm
[14:18] <seb128> Laney, no hurry, I was just stating that I'm going to let it to you
[14:19] <seb128> I'm doing the review of ken's background-art one
[14:19] <Laney> neat
[14:20] <seb128> kenvandine, I still think that header styling business is going to bite us back at some point, can you open a toolkit wishlist?
[14:27] <kenvandine> seb128, sure
[14:28] <kenvandine> seb128, bill liked the idea of splitting a component out of gallery-app to make it reusable, so i've started on that
[14:29] <seb128> kenvandine, ok, cool
[14:29] <kenvandine> it might make that code cleaner in gallery-app too... it's kind of a mess right now
[14:41] <kenvandine> seb128, bug 1259953
[14:41] <ubot2> Launchpad bug 1259953 in Ubuntu UI Toolkit "Provide overrides for header style properties" [Wishlist,New] https://launchpad.net/bugs/1259953
[14:42] <seb128> kenvandine, thanks
[15:30] <seb128> dobey, hey
[15:30] <seb128> dobey, just for info, https://launchpad.net/ubuntu/+source/webkitgtk/2.3.2-1ubuntu4
[15:30] <seb128> dobey, that should fix the cairo/s-c issues
[15:35] <dobey> seb128: great, thanks
[15:35] <seb128> dobey, yw ;-)
[16:12] <Resisty> Hello, I have an ubuntu 12.04 installation and I'm trying to give it a desktop environment. I started by installing ubuntu-desktop and making a couple changes to lightdm.conf, but when I log in, the menu in the upper right is empty: http://i.imgur.com/JB2ShYv.png Does anybody know how I can start trying to fix this?
[16:57] <Laney> arg
[16:57] <Laney> 'o' != 's'
[17:00] <Laney> finally it works
[17:00] <Laney> pitti: it's sensible to have the upower template emit the DeviceAdded/DeviceRemoved signals, right?
[17:02]  * Laney assumes so and prepares a merge
[20:25] <Sweetshark> oi, discourse.ubuntu.com down?