[04:28] <pitti> Good morning
[04:48] <darkxst> hey pitti
[07:27] <mlankhor1t> Hello, world!\n
[08:04] <seb128> good morning desktopers!
[08:22] <bigon> pitti: hey, I know this might be a bit OT here, but now that gdm/lightdm/kdm are logind aware (and thus not registering a ck session anymore) shouldn't be the nox11 option be removed from the call to the ck pam module?
[08:24] <pitti> bigon: TBH I don't even remember any more what that does
[08:32] <bigon> pitti: the nox11 prevent the pam module to register a session if a DISPLAY is set
[08:33] <darkxst> bigon, gdm/gnome-shell still work with ck in theory, you just loose a bunch of features
[08:33] <bigon> well in debian since yesterday in unstable, it is compiled with logind support
[08:33] <bigon> and ck-list-session is empty
[08:33] <bigon> that's why I think that the nox11 should be remove
[08:34] <bigon> d
[08:35] <darkxst> bigon, right, if its built with logind, ck can go
[08:36] <bigon> indeed, I'm running a ck-free desktop now
[08:36] <pitti> bigon: I guess in that case we might rather remove ck altogether?
[08:37] <darkxst> pitti, seems about right, its really only need on !linux now
[08:38] <bigon> yes indeed !linux
[08:38] <bigon> and application that really require ck with no support of logind
[08:39] <bigon> so ck should stay
[08:39] <bigon> unfortunately
[08:39] <pitti> ah right
[08:39] <pitti> perhaps only build CK on !linux theN?
[08:39] <bigon> http://codesearch.debian.net/search?q=org.freedesktop.ConsoleKit
[08:40] <bigon> there are other pkg that are using exclusively ck that run on linux too
[08:40] <bigon> but like I said ATM there is no session registred with gdm3 (and logind support enabled)
[08:41] <bigon> I'm wondering if it's also the case with lightdm and such
[08:41] <bigon> that's why I was proposing to let the pam module register the session instead of the DM itself
[08:43] <bigon> I'll open a bug for this in debian BTS
[08:58] <seb128> hum
[08:59] <seb128> didrocks, larsu, pitti: is anyone having issues with the canonical sites (irc, imap server)?
[08:59] <didrocks> seb128: hum, no issue here for now
[08:59] <seb128> hum, k
[08:59] <larsu> seb128: irc works fine. I don't use their imap anymore
[08:59] <seb128> the lag-o-meter on IRC keeps increasing here
[09:00] <larsu> I've had some lag earlier today, but not right now
[09:00] <seb128> k
[09:00] <seb128> oh, just got disconnected, weird
[09:08] <darkxst> hey seb128
[09:08] <darkxst> Bug 1299912
[09:09] <darkxst> (the bots are dead?)
[09:11] <seb128> darkxst, hey
[09:11] <seb128> not sure about the bots
[09:11] <seb128> thanks, that's in the sponsoring queue right?
[09:11] <seb128> I saw the email, but I'm still in backlog from the w.e
[09:12] <seb128> right, it is
[09:12] <darkxst> seb128, trusty part is atleast
[09:12] <darkxst> seems merges against ubuntu-desktop don't show up in the queue?
[09:13] <darkxst> well it is there this time though
[09:15] <seb128> not sure how the sponsoring page is generated
[09:15] <seb128> it might depends of who is set as reviewer
[09:16] <pitti> seb128: IRC works quite fine here; I don't use Canonical email; canonicaladmin also WFM
[09:16] <seb128> pitti, thanks, I'm still in lag-o-meter land on the IRC, go figure
[09:17] <darkxst> seb128, no lag here, from this side of the world ;)
[09:18] <seb128> darkxst, the issues I have are on the Canonical infra, not on the public IRC
[09:18] <darkxst> oh ok
[09:18] <seb128> well I got reconnected and now lag is to 0 again
[09:18] <seb128> let's see if it resolves itself over the day
[09:22] <mlankhorst> mvo: it might theoretically be possible to run without the backported kernel, but it's not a supported path
[09:26] <dpm> hey morgen pitti, I read you had a nice and productive systemd/GNOME sprint :-)
[09:28] <pitti> hey dpm
[09:28] <pitti> dpm: I did, thanks!
[09:28] <pitti> dpm: I haven't gotten around to your mail yet, sorry; last week was full of firefighting
[09:30] <dpm> pitti, no worries, it's nothing urgent atm for MAE, as we're shipping the Simplified Chinese langpack on the phone anyway, but I'm trying to get the wheels moving to have a good i18n story for the phone - thanks!
[10:10] <Sweet5hark> hi there
[10:13] <mlankhorst> does unity do anything with xinput touch events?
[10:38] <darkxst> seb128, ok to bump dep on gnome-settings-daemon-schemas to (< 3.12) in unity-settings-daemon, its causing problems with our PPA's
[10:39] <darkxst> I promise I won't break anything in the updates when they land ;)
[10:39] <seb128> darkxst, what is the version used atm?
[10:41] <seb128> darkxst, we added it because the new version of g-s-d was changing keys in an incompatible way and generating abort reports that were starting ranking high on e.u.c
[10:41] <darkxst> seb128, its currently          gnome-settings-daemon-schemas (>= 3.8),
[10:41] <darkxst>          gnome-settings-daemon-schemas (<< 3.10),
[10:42] <seb128> we need a 3.10 that doesn't drop keys before relaxing that <<
[10:43] <darkxst> seb128, which g-s-d was causing errors?
[10:43] <seb128> 3.10
[10:44] <darkxst> seb128, there are no public 3.10 packages on trusty as yet?
[10:44] <seb128> well, ricotz had some in a ppa
[10:44] <seb128> and that was creating quite some reports on e.u.c
[10:44] <darkxst> oh, right
[10:44] <seb128> that's why I added the <<
[10:44] <darkxst> his packages are probably just git snapshots
[10:45] <darkxst> the packaging I did had reverted all key removals
[10:46] <seb128> could have been https://git.gnome.org/browse/gnome-settings-daemon/commit/data?h=gnome-3-10&id=1709bf58a60b76bce77038bb804991447d215f49
[10:46] <seb128> the issue is that we can't tell yours with the revert and ricotz's one appart :/
[10:47] <seb128> well I guess users running a ppa with git snapshot get what they opted in for then
[10:49] <ricotz> seb128, hi, i dont remember doing a snapshot of g-s-d for quite some cyclesand my ppas doesnt contain one, do you happen to find the offending package?
[10:51] <seb128> ricotz, it was maybe simply a 3.10 version from upstream
[10:51] <seb128> they dropped keys from their schemas there
[10:51] <seb128> e.g https://git.gnome.org/browse/gnome-settings-daemon/commit/data?h=gnome-3-10&id=1709bf58a60b76bce77038bb804991447d215f49
[10:51] <ricotz> seb128, i know, i am curious where the package came from
[10:51] <seb128> I don't remember, one of your ppas
[10:53] <ricotz> i guess it could be gnome3-team/gnome3: gnome-settings-daemon - 3.10.2-0ubuntu1~saucy6
[10:53] <ricotz> darkxst, ^?
[10:58] <darkxst> maybe, that had http://pastebin.com/U69RM6ww
[10:59] <darkxst> which I suppose never made it into u-s-d in the end
[11:00] <darkxst> same patch is likely in our 3.12 packages
[11:05] <darkxst> although the actual key in seb128 link was likely fallout from the ibus update
[11:05] <darkxst> which shouldnt affect u-s-d?
[11:07] <seb128> https://errors.ubuntu.com/problem/d7ee33f4be4368596fc6c3afbfab8604799370a8
[11:07] <seb128> was the issue iirc
[11:07] <seb128> https://errors.ubuntu.com/oops/7e0c117e-c6e9-11e3-9099-fa163e707a72
[11:07] <seb128> gnome-settings-daemon-schemas 3.12.0.1-0ubuntu1~trusty1 [origin: LP-PPA-gnome3-team-gnome3-staging]
[11:09] <seb128> ricotz, ^ they had stuff with "origin: LP-PPA-ricotz-testing" but the g-s-d-s was from the gnome3 ppa it seems
[11:09] <seb128> but it has been some time I don't remember the specifics
[11:12] <ricotz> seb128, yeah, i see, i was assuming that
[11:13] <ricotz> darkxst, this suggests that the problem persists with the latest g-s-d upload then
[11:13] <darkxst> yes its related to the upower port
[11:14]  * ricotz didn't look at those links since it requires some u1 login again
[11:15] <darkxst> ricotz my first link was unrelated
[11:15] <darkxst> I think this is what is the issue
[11:15] <darkxst> https://bugzilla.gnome.org/show_bug.cgi?id=709736
[11:15] <seb128> yes it is
[11:54] <bigon> if I'm correctly looking at lightdm, it both create a logind and ck session when available
[11:55] <bigon> is this correct?
[12:06] <mlankhorst> hm looks like i can produce a lot of xorg-server spew by simply using my touchpad through evdev instead of synaptics
[12:07] <Fudge> darkxst:  glib-2.0 finally came to the party but now something weird that I dont understand with pygobject, just amd64 https://launchpadlibrarian.net/174588843/buildlog_ubuntu-precise-amd64.pygobject_3.8.0-2%7Evinux1_FAILEDTOBUILD.txt.gz
[12:07] <Fudge> if you're busy though, I understand :)
[12:15] <darkxst> Fudge, test_add_watch_no_data (test_iochannel.IOChannel) ... /bin/bash: line 4:  2884 Segmentation fault      PYTHONPATH=..:../tests:${PYTHONPATH:+:$PYTHONPATH} LD_LIBRARY_PATH=./.libs:$LD_LIBRARY_PATH GI_TYPELIB_PATH=.:$GI_TYPELIB_PATH XDG_DATA_DIRS=$XDG_DATA_DIRS:/usr/share MALLOC_PERTURB_=85 MALLOC_CHECK_=3 G_SLICE=debug-blocks TESTS_BUILDDIR=. /usr/bin/python2.7-dbg -Wd ../../tests/runtests.py
[12:32] <Fudge> darkxst:  forgive me if that is a solution as I dont understand how to implement it
[12:35] <darkxst> Fudge, that is the error
[12:35] <darkxst> I have no idea why its crashing!
[12:36] <Fudge> oh right, always something for me, things love to crash :D
[12:36] <darkxst> Fudge try running the tests locally and see if you can get a backtrace!
[12:37] <darkxst> it may just be a missing dep, but can't really say from the log message
[12:39] <Fudge> thank you for taking the time :), I'll try tomorrow
[12:46] <darkxst> bt
[13:16] <bigon> pitti: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747071 << if you care about the ck-ectomie
[13:18] <pitti> bigon: I'm not quite sure how to do that in CK -- the session needs to be registered by a CK client, i. e. PAM-ck or the DM
[13:18] <pitti> bigon: IMHO DMs should use CK on !linux and logind on linux, and we stop supporting CK on linux?
[13:22] <bigon> GDM is not registring the session, looking at lightdm code, this one is still doing so
[13:23] <bigon> not sure about KDM
[13:24] <bigon> if we only want to support ck on !linux then indeed things are way more simple
[13:28] <pitti> bigon: hm, reconsidering -- I think it makes more sense to do that dynamically and ignore the platform
[13:29] <pitti> bigon: i. e. try logind, and if that fails, fall back to registering a CK session
[13:29] <pitti> bigon: that mirrors what e. g. g-settings-daemon is doing, and opens the possibility that the logind API gets a shim (or otherwise implemented) in bsd
[13:30] <bigon> gdm is doing that too
[13:31] <bigon> well gdm is registering a logind session and then falls back to ck
[13:31] <bigon> but not both
[13:31] <pitti> that seems fine?
[13:32] <mlankhorst> ok that XI bug is annoying :P
[16:06] <Sweet5hark> seb128: around?
[17:54] <Sweet5hark> Anyone from bugcontrol here? Could you please nominate bug 1316243 for precise?