=== jalcine is now known as JackyAlcine_
=== JackyAlcine_ is now known as jalcine
=== jalcine is now known as JackyAlcine_
=== webjadmin is now known as JackyAlcine_
=== JackyAlcine_ is now known as webjadmin
=== webjadmin is now known as jalcine
[02:10] <broder> do i need to have a lightdm greeter installed if i'm doing autologin?
[02:15] <robert_ancell> broder, no, but if you quit your session it will attempt to return to a greeter
[02:16] <broder> robert_ancell: ok, that should be fine. i'm trying very hard to prevent exiting the session
[02:16] <robert_ancell> there's a bug request about making autologin always work, i.e. on session quit it just restarts the session (for kiosks etc)
[02:17] <robert_ancell> it will also attempt to start a greeter if the session doesn't start, and it should exit lightdm if that fails (probably needs testing)
[02:17] <broder> oh, awesome. yeah, that would be useful, but it's not essential for me. do you know the bug number for that?
[02:17] <broder> (autologin always working)
[02:17] <robert_ancell> looking...
[02:18] <robert_ancell> bug 839332
[02:18] <ubot2`> Launchpad bug 839332 in lightdm "Support embedded system by optionally automatically restarting session" [Wishlist,Triaged] https://launchpad.net/bugs/839332
[02:18] <broder> awesome. i'll keep an eye on it. thanks
=== jalcine is now known as JackyAlcine_
=== JackyAlcine_ is now known as jalcine
[05:26] <TheMuso> urm is it just me, or does firefox fail to load after latest updates, I get a segfault.
[05:27] <TheMuso> Deleting ~/.mozilla didn't help either.
[05:27]  * TheMuso removes flash to be sure its not the culpret.
[05:30]  * TheMuso disables a11y to see if that could also be a culpret.
[05:30] <jbicha> TheMuso: firefox works here but LP says it hasn't been updated in 5 days
[05:31] <TheMuso> jbicha: ok, seems something in the a11y stack is causing it to fall over. GRRRRRRR
[05:32] <TheMuso> brb
[05:36] <TheMuso> yep a11y related. Whats more, apport doesn't give me a crash file.
[05:39] <desrt> cjohnston: awake?
[05:39] <desrt> cjohnston: sorry
[05:39] <desrt> cjwatson: awake?
[05:47] <pitti> Good morning
[05:49] <TheMuso> Ok, the bug is in atk.
[05:49]  * TheMuso rebuilds GTK2 to see if that helps...
[05:49] <desrt> pitti: 'morning
[06:20]  * desrt spends entirely too much time chasing memory leaks in libc
[06:21] <desrt> time for bed!
[06:59] <didrocks> good morning
[07:02] <pitti> bonjour didrocks
[07:02] <didrocks> guten morgen pitti, how are you?
[07:03] <pitti> didrocks: I'm great, thanks!
[07:03] <pitti> bah, seb128 once again is three bugs ahead of me
[07:03]  * pitti fixing more
[07:03] <pitti> fierce competition this
[07:10] <pitti> doctor appointment, bbl
[07:14] <didrocks> see you later pitti
[08:03] <pitti> didrocks: what is LIM?
[08:03] <didrocks> pitti: locally integrated menus
[08:03] <didrocks> pitti: having the menu back in the application window
[08:03] <didrocks> (but not exactly as they were)
[08:04] <pitti> didrocks: that sounds like a step backwards
[08:04] <pitti> so all the effort of removing chrome that made natty pretty much perfect is crumbling
[08:04] <didrocks> pitti: it would be an option, but not finding the menus is the #1 on the usability results issue by design
[08:04] <pitti> these days unity needs more real estate than old gnome already
[08:05] <didrocks> I just don't want we integrate that for the sake of it and risking quality
[08:05] <pitti> didrocks: yes, agreed
[08:05] <didrocks> almost everyone on product stategy agrees as well and are not confident
[08:05] <didrocks> that would be nice if we can speak from the same voice in distro too :)
[08:05] <didrocks> pitti: yeah, with always visible launcher, I know :/
[08:08] <didrocks> pitti: just to be clear, the plan is not to take more real eastate, but having the menu wrapper in the application decoration (title bar)
[08:08] <didrocks> everything under one menuitem
=== jbicha is now known as Guest38686
[08:36] <chrisccoulson> hmmm, so, it seems that everything related to display configuration is completely broken on my laptop now :(
[08:36] <chrisccoulson> i got a blank screen after undocking last night, which i could only fix with a reboot. and now i get the same after lid close :(
[08:56] <sil2100> Hi!
[08:56] <sil2100> hm, I've been wondering about something - why is the precise package for libgtk2.0-bin not including the gtk-query-immodules-2.0 binary, even though the manpage for it is still installed?
[08:57] <sil2100> It looks as if someone forgot about it
=== zyga-xchat is now known as zyga
[09:10] <seb128> hey
[09:12] <didrocks> salut seb128, la forme?
[09:12] <seb128> didrocks, lut, bit tired but good otherwise ;-)
[09:12] <seb128> you?
[09:14] <pitti> bonjour seb128
[09:14] <didrocks> I'm fine, thanks :)
[09:16] <seb128> hey pitti, wie gehts?
[09:17] <pitti> seb128: gut, danke! und Dir?
[09:17] <pitti> seb128: fiercely fixing bugs to catch up with you
[09:18] <seb128> pitti, zehr gut, danke!
[09:19] <seb128> pitti, we are catching up with didrocks :p
[09:19]  * didrocks crack the whip on the unity guys :)
[09:19] <seb128> ;-)
[09:19] <didrocks> not fair, all the GNOME uploads I did had no closed bug!
[09:20] <pitti> same for mine :)
[09:24] <seb128> same here
[09:24] <seb128> or mostly
[09:29] <seb128> RAOF, hey
[09:31] <ubuntubhoy> hi, anyone able to help with a netbook sticking at 'checking battery stats' on boot
[09:31] <ubuntubhoy> believe its a lightdm issue
[09:31] <ubuntubhoy> can boot through recovery fine
[09:32] <seb128> ubuntubhoy, hey
[09:32] <ubuntubhoy> hi
[09:32] <seb128> ubuntubhoy, cat /etc/X11/default-display-manager
[09:32] <ubuntubhoy> its set to lightdm
[09:32] <ubuntubhoy> had a look at that last night
[09:32] <seb128> ubuntubhoy, "lightdm"?
[09:32] <seb128> or the full path?
[09:33] <ubuntubhoy> full path
[09:33] <seb128> ubuntubhoy, do you have unity-greeter installed?
[09:33] <ubuntubhoy> yip
[09:34] <seb128> ubuntubhoy, can you pastebin your /var/log/lightdm/lightdm.log?
[09:34] <ubuntubhoy> hold on
[09:34] <ubuntubhoy> set to gdm right now
[09:34] <ubuntubhoy> will swap it back
[09:41] <seb128> bah, yeah another unity bug about "pornview"
[09:41] <seb128> how many of those discussion is that application worth?
[09:41] <seb128> we should just drop it from the archive...
[09:41] <seb128> doh
[09:41] <seb128> and while I read email pitti score 4 bugs which put me 1 behind again :p
[09:42] <seb128> oh, 5 in fact
[09:42] <pitti> seb128: as I said, need to catch up with you :)
[09:42] <pitti> seb128@ubuntu.com has 222 fixes
[09:42] <pitti> martin.pitt@ubuntu.com has 217 fixes
[09:42] <pitti> seb128: so should be on par again?
[09:43] <seb128> pitti, http://reports.qa.ubuntu.com/reports/bug-fixing/canonical-desktop-team-precise-fixes-report.html had 226 and 223
[09:43] <seb128> pitti, but something like that ;-)
[09:43] <pitti> ah, right; seems the full report lags behind a little
[09:43] <dupondje> The battery indicator doesn't seem to work. It always shows 99% here :s
[09:43] <seb128> dupondje, gnome-shell?
[09:43] <dupondje> yep
[09:44] <seb128> dupondje, use a good desktop like unity :p
[09:44] <seb128> or "known issue"
[09:44] <seb128> ;-)
[09:44] <dupondje> héhé :)
[09:44] <seb128> the g-s-d signals changed and nobody fixed our gnome-shell package
[09:44] <seb128> the fix is in 3.4 but since we are on 3.2 still
[09:44] <seb128> talk to jbicha when he's online
[09:44] <dupondje> k :)
[09:44] <dupondje> i'll spam him :)
[09:47] <chrisccoulson> hey seb128, pitti
[09:47] <pitti> hey chrisccoulson, how are you?
[09:47] <seb128> hey chrisccoulson, how are you?
[09:47] <chrisccoulson> yeah, not too bad thanks. how are you?
[09:48] <pitti> I'm quite well
[09:48] <chrisccoulson> seb128, i fixed nautilus-sendto in bzr btw, but i can't upload it ;)
[09:48] <seb128> I'm good thanks
[09:48] <seb128> chrisccoulson, oh, let me sponsor that
[09:48] <chrisccoulson> thanks :)
[09:48] <ubuntubhoy> seb128, pastebin.com/1FEpRJJ1
[09:50] <seb128> ubuntubhoy, what about /var/log/lightdm/x-0.log  ?
[09:51] <ubuntubhoy> pastebin.com/5QWY03RH
[09:51] <chrisccoulson> pitti - do you know how many packages are using ubuntu-defaults-builder to divert /usr/lib/firefox-addons/distribution/distribution.ini?
[09:52] <seb128> ubuntubhoy, oh
[09:52] <seb128> ubuntubhoy, seems a config bug
[09:52] <seb128> ubuntubhoy, what about /etc/lightdm/lightdm.conf ?
[09:53] <ubuntubhoy> greeter-session=inuty-greeter
[09:53] <ubuntubhoy> unity*
[09:53] <seb128> ubuntubhoy, something is weird on your box
[09:53] <ubuntubhoy> user-session=ubuntu
[09:54] <pitti> chrisccoulson: a handful by now, but there can always at most one of them be installed
[09:54] <seb128> ubuntubhoy, Unrecognized option: -background
[09:54] <ubuntubhoy> its has a weird GPU
[09:54] <seb128> ubuntubhoy,
[09:54] <ubuntubhoy> yeah
[09:54] <seb128> ubuntubhoy, that's your xorg log
[09:55] <ubuntubhoy> yeah, I noticed that
[09:55] <chrisccoulson> pitti - i'm going to move the whole firefox install location to /usr/lib/firefox quite soon (I already did it on the nightly builds), as it fixes another problem we have
[09:55] <chrisccoulson> i was just wondering how many packages i'd need to fix :)
[09:56] <seb128> ubuntubhoy, dpkg -l | grep xserver-xorg
[09:57] <ubuntubhoy> pastebin.com/mddqVbHD
[09:59] <seb128> ubuntubhoy, ii  xserver-xorg-core                      3:1.10.9-down1.9.2.901.2+git20101129+server-1.9-branch.65f2ab20-0ubuntu0sarvatt2~natty Xorg X server - core server
[09:59] <seb128> ubuntubhoy, that's your issue
[09:59] <seb128> ubuntubhoy, you got a non ubuntu xserver which doesn't support -background
[10:00] <ubuntubhoy> hmm
[10:00] <seb128> you got it from a ppa or something I guess
[10:00] <ubuntubhoy> will be to do with the stupid Poulsbo GPU in this
[10:00] <ubuntubhoy> seb128, yeah
[10:00] <ubuntubhoy> otherwise I have no graphics at al
[10:00] <seb128> ubuntubhoy, you can probably hack your lightdm.conf to drop the -background option
[10:01] <ubuntubhoy> how so ?
[10:01] <seb128> ubuntubhoy, try "xserver-command = /usr/bin/X :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
[10:01] <seb128> "
[10:01] <ubuntubhoy> in the conf ?
[10:01] <seb128> yes
[10:01] <ubuntubhoy> K
[10:01] <ubuntubhoy> TY for your time
[10:02] <seb128> yw
[10:03] <RAOF> seb128: Yo.  What's up?
[10:03] <seb128> RAOF, hey, did you get any news from cnd on the gtk,xinput issue?
[10:03] <seb128> RAOF, just asking in case, I would like my scrolling back :p
[10:04] <RAOF> I've not got any news from him, but he's aware of the problem, and it seems to be upstream too.
[10:04] <seb128> RAOF, ok
[10:05] <seb128> RAOF, since you are here, second small question, is "-background" an Ubuntu-ish for xorg?
[10:06] <RAOF> I think we still carry a patch to add the pre-upstream background none flag.  Let me check...
[10:06] <seb128> ubuntubhoy, I think that config will not work, lightdm hardcode the flag, open a bug I guess
[10:06] <seb128> on lightdm
[10:06] <RAOF> seb128: -background is upstream, “-nr” is an ubuntuism.
[10:07] <seb128> RAOF, ubuntubhoy got an "interesting" issue, he installed "xserver-xorg-core                      3:1.10.9-down1.9.2.901.2+git20101129+server-1.9-branch.65f2ab20-0ubuntu0sarvatt2~natty" to get his poulsbo video to work
[10:07] <seb128> RAOF, which makes lightdm bail out of "-background unknown option"
[10:07] <seb128> well rather X bails out
[10:07] <RAOF> Yeah, the 1.9 server would be too old.
[10:08] <RAOF> Sucks to have a poulsbo.
[10:08] <seb128> indeed
[10:08] <seb128> RAOF, thanks ;-)
[10:08] <ubuntubhoy> is it possible to remove lightdm & keep ubuntu-desktop ?
[10:08] <seb128> ubuntubhoy, just install gdm and make it default?
[10:08] <ubuntubhoy> tried that
[10:08] <ubuntubhoy> still hangs unless I go through recovery
[10:08] <seb128> ubuntubhoy, you can probably hack gdm.conf to drop the -background
[10:09] <seb128> ubuntubhoy, look to /etc/gdm/gdm.conf
[10:09] <seb128> or /etc/gdm/custom.conf
[10:09] <ubuntubhoy> then the same line as before ?
[10:09] <seb128> likely gdm.conf
[10:09] <seb128> ubuntubhoy, look for -background in it
[10:09] <ubuntubhoy> K
[10:11] <seb128> ubuntubhoy, hum, no, same issue
[10:11] <seb128> it hardcodes -background as well
[10:11] <ubuntubhoy> damn
[10:12] <ubuntubhoy> netbook is daughters, wanted it run as-easy-as for her
[10:12] <seb128> ubuntubhoy, one thing you can try
[10:12] <ubuntubhoy> all ears
[10:12] <seb128> ubuntubhoy, in the lightdm.conf set "xserver-command = Xwrapper" or something
[10:13] <seb128> then create an /usr/binXwrapper which strips -background and call X with the remaining arguments
[10:13] <seb128> or which just ignore the argument and call "X -nolisten tcp"
[10:14] <ubuntubhoy> so
[10:14] <ubuntubhoy> remove the original line in lightdm.conf ?
[10:14] <ubuntubhoy> xserver-command from before
[10:15] <seb128> create a /usr/bin/Xwrapper with i.e
[10:15] <seb128> #!/bin/sh
[10:15] <seb128> exec /usr/bin/X
[10:15] <seb128> and set "xserver-command = Xwrapper"
[10:15] <seb128> in lightdm.conf
[10:15] <seb128> well probably no need of the exec
[10:15] <seb128> something like "/usr/bin/X -nolisten tcp"
[10:16] <ubuntubhoy> will give it a try
[10:16] <seb128> ubuntubhoy, other option is to rebuild lightdm with a small patch to drop that -background
[10:16] <ubuntubhoy> also, I guess I then set default dm to lightdm
[10:16] <seb128> or to find a dm which doesn't use -background
[10:16] <seb128> i.e maybe ldm or something
[10:16] <seb128> seems ldm doesn't do it
[10:16] <seb128> so maybe it's easier
[10:16] <seb128> install ldm as a login screen
[10:17] <seb128> ubuntubhoy, good luck
[10:17] <ubuntubhoy> thanx
[10:17] <ubuntubhoy> will need it :D
[10:17] <seb128> I need to get back to work know, I suggested the ideas I had anyway
[10:18] <ubuntubhoy> thanx again mate
[10:19] <seb128> yw
[10:21]  * Sweetshark wonders about our userbase. I get at least three obvious dupes per day on precise (which is still beta).
[10:22] <Sweetshark> reading ability seems to become a rare skill.
[10:24] <Sweetshark> *grumble* and freaking lp timeouts itself on every second query.
[10:32] <Sweetshark> pitti: although it is fixed upstream already, is it possible for you to quickly create a bug pattern for "crash bibliography" to bug 527938?
[10:32] <ubot2`> Launchpad bug 527938 in df-libreoffice "[upstream] Writer crashes when trying to set up Bibliography Database soffice.bin crashed with SIGABRT in __kernel_vsyscall()" [Medium,Confirmed] https://launchpad.net/bugs/527938
[10:33] <pitti> Sweetshark: hm, many of these bugs are manual reports, not sure what to search for there?
[10:33] <pitti> e. g. bug 948315, I don't see an obvious pattern there
[10:33] <ubot2`> Launchpad bug 948315 in libreoffice "soffice.bin crashed with SIGSEGV (dup-of: 527938)" [Undecided,New] https://launchpad.net/bugs/948315
[10:33] <ubot2`> Launchpad bug 527938 in df-libreoffice "[upstream] Writer crashes when trying to set up Bibliography Database soffice.bin crashed with SIGABRT in __kernel_vsyscall()" [Medium,Confirmed] https://launchpad.net/bugs/527938
[10:34] <pitti> Sweetshark: https://launchpadlibrarian.net/82239479/Stacktrace.txt is a typical client-side crash trace
[10:35] <Sweetshark> pitti: i have no idea how bug patterns work, but cant you just look for the words "crash bibliography" in the title/description?
[10:36] <pitti> Sweetshark: I can, but houw woudl that e. g. help with 948315?
[10:37] <pitti> Sweetshark: also, these titles are entered into the Launchpad page
[10:37] <pitti> Sweetshark: that's after apport runs and searches for bug patterns
[10:37] <pitti> Sweetshark: could we match on libbiblo.so in Stacktrace?
[10:38] <pitti> https://launchpadlibrarian.net/81980649/Stacktrace.txt has libbibli.so
[10:38] <pitti> and I also saw a libbiblx or so
[10:38] <pitti> "libbibl"?
[10:39] <pitti> Sweetshark: ok, seems matching on "program/libbibl.*\.so" should get us very far?
[10:42] <pitti> Sweetshark: ok, added
[10:44] <cjwatson> desrt: what's up?
[10:55] <Sweetshark> pitti: yes, program/libbibl.*\.so is a good pattern
[10:55] <Sweetshark> pitti: thanks a lot!
[10:56] <chrisccoulson> the atk update has killed firefox and thunderbird btw
[10:57] <chrisccoulson> bug 948788
[10:57] <ubot2`> Launchpad bug 948788 in thunderbird "thunderbird crashed on launch" [Undecided,Confirmed] https://launchpad.net/bugs/948788
[10:57] <chrisccoulson> stack overflow on start :(
[11:01] <seb128> chrisccoulson, :-(
[11:01] <seb128> chrisccoulson, only if you have a11y enabled?
[11:01] <chrisccoulson> i haven't tried restarting it yet ;)
[11:01] <chrisccoulson> but we got 3 launchpad bugs in the last hour or so already
[11:02] <seb128> chrisccoulson, there are not so many commits so at least we should be able to easily revert the buggy one
[11:05] <chrisccoulson> yeah, it's only with a11y enabled
[11:09] <chrisccoulson> seb128, oh, i don't even need to test this. it's this commit:
[11:09] <chrisccoulson> http://git.gnome.org/browse/atk/commit/?id=7ebaa51b17fbca385d9d1f3dd026bd4770852d9b
[11:09] <chrisccoulson> the issue is that firefox overloads get_name(), and it's implementation of that calls atk_object_set_name
[11:10] <seb128> chrisccoulson, iz firefox bog!
[11:10] <seb128> why would get() call set()?
[11:11] <chrisccoulson> seb128, it's get() function is fetching the name from one of it's own properties, and syncing the name with atk
[11:12] <seb128> chrisccoulson, that's a firefox bug still no?
[11:12] <seb128> like that commit seems fine to me
[11:12] <seb128> or logically correct at least
[11:13] <chrisccoulson> seb128, not really sure. i'm not sure we can change this in firefox at the moment without breaking it's accessiblity. in any case, that commit is changing semantics of atk_object_set_name. it wouldn't be so bad if applications couldn't overload get_name()
[11:14] <chrisccoulson> but it's calling get_name() inside set_name() ;)
[11:14] <chrisccoulson> which is just as weird
[11:14] <seb128> yeah
[11:14] <seb128> chrisccoulson, I guess just revert it
[11:14] <chrisccoulson> thanks :)
[11:14] <seb128> thank you for figuring it out and for the explanations ;-)
[11:15] <seb128> retracer "fixes" freak me out :p
[11:16] <seb128> we got like a ton of dups today ;-)
[11:17] <seb128> no kudos for slangasek for not fixing bug #948294 either
[11:17] <ubot2`> Launchpad bug 948294 in gconf "package gconf2 3.2.3-3ubuntu1 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 250" [High,Confirmed] https://launchpad.net/bugs/948294
[11:18] <seb128> 10 duplicates closed
[11:21] <chrisccoulson> seb128, reported it to mozilla as well: https://bugzilla.mozilla.org/show_bug.cgi?id=733712
[11:21] <ubot2`> Mozilla bug 733712 in Disability Access APIs "Stack exhaustion crash in getNameCB with atk 2.3.91" [Normal,New: ]
[11:28] <chrisccoulson> ok, a11y off again :)
[11:28] <chrisccoulson> seb128, do you have time to revert it? i would offer, but i can't upload atk anyway ;)
[11:29] <seb128> chrisccoulson, ok
[11:33] <chrisccoulson> seb128, thanks
[11:34] <chrisccoulson> i just noticed that the committer of that atk change has a bugzilla account, so I CC'd him on the mozilla bug ;)
[11:36] <seb128> chrisccoulson, he's API on #ubuntu-unity
[11:36] <seb128> I think
[11:36] <chrisccoulson> seb128, oh, i didn't know his IRC name
[11:36] <chrisccoulson> thanks!
[11:37] <seb128> yw
[11:40] <ubuntubhoy> seb128, managed to get a dirty workaround to get it booting
[11:40] <ubuntubhoy> sudo mv /etc/init/plymouth.conf /etc/init/plyouth.conf.disabled
[11:41] <seb128> oh
[11:41] <seb128> that turns off the background option code I guess
[11:41] <ubuntubhoy> seems the -background was being called by plymouth
[11:41] <ubuntubhoy> yeah
[11:41] <ubuntubhoy> so all's good
[11:41] <ubuntubhoy> can live without plymouth
[11:42] <seb128> ubuntubhoy, no "by plymouth", but "when transition from plymouth by gdm,lightdm"
[11:42] <seb128> so yeah, turning it off will lead to those not adding the option
[11:43] <ubuntubhoy> yeah, your description is correct
[11:43] <seb128> chrisccoulson, https://launchpad.net/ubuntu/+source/atk1.0/2.3.91-0ubuntu2
[11:44] <seb128> chrisccoulson, please test, I didn't do that, I'm not sure how to turn a11y on without restarting my session :p
[11:44] <chrisccoulson> seb128, thanks!
[11:44] <seb128> yw
[11:45] <ubuntubhoy> once again, cheers for your time seb128
[11:45] <seb128> ubuntubhoy, you're welcome, glad you got it working!
[11:46] <ubuntubhoy> as am I - otherwise I was looking at constant grief from my eldest
[11:51] <seb128> chrisccoulson, how do you turn a11y for testing? just as I know if I need it :p
[11:51] <chrisccoulson> seb128, i just turned on the screen reader in the a11y panel
[11:52] <seb128> chrisccoulson, need a session restart?
[11:52] <chrisccoulson> seb128, no, you should be able to test it without a session restart
[11:53] <seb128> chrisccoulson, ok, firefox still run fine for me, dunno why
[11:53] <seb128> chrisccoulson, I will let you test ;-)
[11:53] <chrisccoulson> thanks
=== MacSlow is now known as MacSlow|lunch
=== zyga is now known as zyga-afk
[12:35] <xclaesse> seb128, is it known that the only way to cancel a print job is to go to http://localhost:631 ?
[12:35] <xclaesse> the UI on g-c-c does not work
[12:35] <seb128> xclaesse, no, we don't use the GNOME g-c-c ui for a reason though
[12:35] <xclaesse> the stop button there does nothing
[12:35] <seb128> xclaesse, system-config-printer should work
[12:35] <seb128> xclaesse, I guess it's https://bugzilla.gnome.org/show_bug.cgi?id=669679
[12:35] <ubot2`> Gnome bug 669679 in Printers ""Stop", "Pause" and "Play" buttons don't work correctly" [Major,Unconfirmed]
[12:35] <xclaesse> dunno on unity, but on gnome-shell, I have to start it from terminal...not even an icon in the launchers
[12:36] <seb128> xclaesse, right, that's because on gnome-shell we give the GNOME experience :p
[12:36] <xclaesse> seb128, on fedora (the definition of gnome experience, sigh) they have system-config-printer I get told
[12:37] <xclaesse> and it shows a notification in the message tray too
[12:37] <xclaesse> on ubuntu+gnome-shell I get no notification :(
[12:37] <xclaesse> seb128, ok thanks for the upstream bug, that's already one thing :)
[12:39] <seb128> xclaesse, ?
[12:39] <seb128> xclaesse, system-config-printer got deprecated in favor of the gnome-control-center gnome-settings-daemon ui,notifications
[12:40] <seb128> xclaesse, we got complains in the past for shipping system-config-printer under gnome-shell from GNOME users
[12:40] <xclaesse> yeah, but in f16, if you search for "print" in gnome-shell's overview, it shows an icon for system-config-printer, not in ubuntu
[12:41] <seb128> xclaesse, the .desktop has NotShowIn=KDE;GNOME;
[12:41] <seb128> well I guess we could drop GNOME from there
[12:41] <seb128> the idea was to not duplicate features though
[12:41] <seb128> xclaesse, if we drop it, searching for "printer" will give you 2 results, which as an user is confusing
[12:42] <seb128> xclaesse, "why do you get 2 printing tools" "which one should I used"
[12:42] <xclaesse> yeah, I understand
[12:42] <seb128> xclaesse, I recommend you talk to upstream to get the g-c-c ui fixed
[12:42] <xclaesse> otoh, better show a deprecated but working UI than a new shiny but not working ui... :(
[12:43] <seb128> xclaesse, that's what we do under Unity ;-)
[12:43] <seb128> we could turn off the control center ui under gnome-shell as well
[12:43] <seb128> but we got complain about that in the past
[12:43] <seb128> either were some people are unhappy
[12:43] <xclaesse> seb128, ah, so I just tested on f16, and actually the UI in the g-c-c works there
[12:43] <seb128> the real fix is to make the g-c-c ui work
[12:44] <xclaesse> indeed
[12:45] <seb128> xclaesse, do you have cups-pk-helper installed?
[12:45] <jalcine> sledgehammer would do?
[12:46] <seb128> jalcine, "sledgehammer"?
[12:46] <jalcine> worked for my laptop before it stopped turning on. lol
[12:46] <xclaesse> seb128, yes
[12:46] <seb128> ok, dunno then
[12:48] <jalcine> yeah, this big thing my dad has lying around in the house.
[12:48] <jalcine> uses when nothing else works.
[12:48] <jalcine> it's a miracle worker.
[12:48] <xclaesse> seb128, does unity show an icon when jobs are queued?
[12:49] <xclaesse> like gnome2 did
[12:49] <seb128> xclaesse, yes, we have a indicator-printers
[12:50] <xclaesse> ok
=== zyga-afk is now known as zyga
[12:52] <xclaesse> seb128, anyway, thanks for your answers :)
[12:53] <seb128> xclaesse, yw!
[13:22] <tkamppeter_> pitti, hi
=== tkamppeter_ is now known as tkamppeter
=== jalcine_ is now known as jalcine
[13:30] <pitti> tkamppeter: hallo
[13:34] <tkamppeter> pitti, can you upload cups-filters do Debian and Ubuntu now? I have made a new upstream release and committed it to the Debian BZR to include all test page fixes and a fix for Debian.
[13:35] <pitti> tkamppeter: nice, thanks!
=== MacSlow|lunch is now known as MacSlow
=== kiwinote_ is now known as kiwinote
[13:39] <nessita> hello everyone! quick question about packaging, I need to make one of my binaries packages from ubuntuone-control-panel be transitional. I've done that, but lintian complains with transitional-package-should-be-oldlibs-extra, and I was wondering if I can add fields Section and Priority to a binary package (I've always seen those in source packages only)
[13:40] <pitti> nessita: yes, you can
[13:41] <pitti> and you indeed should in this case
[13:41] <nessita> nice
[13:41] <nessita> pitti: should I add those right after the Package line?
[13:41] <pitti> nessita: yes, that's customary
[13:41] <nessita> thanks!
[13:41] <pitti> nessita: technically the order doesn't matter, but usually you start with Package:, then section/prio, then dependencies, then description
[13:42] <nessita> perfect
[13:43] <pitti> tkamppeter: done
[13:45] <didrocks> tkamppeter: hey, printing is broken for me in precise, what should I check to help debugging?
[13:45] <didrocks> (the same machine was working on oneiric and some weeks ago on precise)
[13:48] <tkamppeter> didrocks, what is exactly broken? Printer not detected? Wrong driver assigned? Test page not coming out? Job not coming out? Please see also the instructions on https://wiki.ubuntu.com/DebuggingPrintingProblems.
[13:48] <tkamppeter> pitti, thanks.
[13:49] <tkamppeter> pitti, I am looking into the Ghostscript bugs and see two trivial-looking ones which one could quickly fix.
[13:49] <tkamppeter> pitti, one is bug 789235
[13:49] <ubot2`> Launchpad bug 789235 in ghostscript "ghostscript-doc should install docs in /usr/share/doc/ghostscript-doc/ instead of/usr/share/doc/ghostscript/ " [Wishlist,New] https://launchpad.net/bugs/789235
[13:49] <didrocks> tkamppeter: the printer is detected
[13:50] <didrocks> tkamppeter: in the cups web interface, I can see: "The PPD version (5.2.7 Simplified) is not compatible with Gutenprint 5.2.8-pre1."
[13:50] <tkamppeter> pitti, there are two possibilities to fix: 1. Let ghostscript-doc depend on ghostscript, perhaps this is the less invasive one; 2. Put Ghostscript docs into /usr/share/doc/ghostscript-doc/ instead of/usr/share/doc/ghostscript/. WDYT, what should be done here?
[13:51] <tkamppeter> didrocks, this is a known problem and fixed in the current CUPS package. Do you have a completely updated system?
[13:52] <tkamppeter> didrocks, CUPS must be 1.5.2-6.
[13:52] <pitti> tkamppeter: why do you need a gs dependendy if you merely move the documentatin?
[13:52] <pitti> tkamppeter: I thought 2. is what this bug asks for?
[13:52] <tkamppeter> pitti, these are two possibilities to solve, I will not apply both, either (1) OR (2).
[13:52] <didrocks> tkamppeter: 1.5.2-6 is installed here and it's the one I'm running
[13:53] <tkamppeter> didrocks, what happens if you run
[13:53] <tkamppeter> sudo apt-get install --reinstall cups
[13:53] <pitti> tkamppeter: the dependency seems absolutely irrelevant here
[13:53] <pitti> tkamppeter: "As ghostscript-doc doesn't depend on ghostscript..." does not make sense
[13:53] <tkamppeter> didrocks, what appears on the screen after "setting up cups"?
[13:54] <didrocks> tkamppeter: let me try
[13:54] <pitti> tkamppeter: the package is ghostscript-doc, so it should install its files into /u/s/d/gs-doc/
[13:54] <tkamppeter> pitti, so the bug is invalid?
[13:54] <pitti> tkamppeter: so 2 seems right
[13:54] <pitti> tkamppeter: no, but 1. won't help; 2. is what the bug is about
[13:55] <tkamppeter> pitti, OK, so I will apply (2).
[13:55] <didrocks> cups start/running, process 21221
[13:55] <didrocks> Updating PPD files for cups ...
[13:55] <didrocks> tkamppeter: ^
[13:56] <didrocks> seems to have restarted the daemon?
[13:56] <seb128> pitti, does https://pastebin.canonical.com/61805/ ring any bell to you?
[13:56] <seb128> pitti, that's what MacSlow gets when he tries to dnd english over german in ls
[13:56] <pitti> seb128: I see that all the time in language-selector, yes; seems mostly harmless, though
[13:56] <seb128> "/usr/lib/python2.7/dist-packages/LanguageSelector/LocaleInfo.py:124: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
[13:56] <seb128>   if lang_name == self._lang[lang]:"
[13:57] <seb128> ok
[13:57] <seb128> pitti, he gets no .pam_environment created though
[13:57] <didrocks> tkamppeter: same error showing if I try to print again after, with the new daemon started
[13:57] <seb128> but probably something else
[13:57] <tkamppeter> didrocks, is there any screen output about PPD updating?
[13:58] <didrocks> tkamppeter: 14:55:51      didrocks | Updating PPD files for cups ...
[13:58] <didrocks> that's it
[13:58] <didrocks> nothing else
[13:58] <didrocks> then the trigger exit
[13:58] <tkamppeter> didrocks, what is the content of your /usr/share/cups/ppd-updaters/ directory?
=== marrusl_ is now known as marrusl
[14:01] <didrocks> tkamppeter: http://paste.ubuntu.com/873030/
[14:01] <didrocks> it contains… stuff :p
=== jalcine is now known as JackyAlcine_
[14:03] <didrocks> I don't have any "PPD for printer $queue updated"
[14:03] <didrocks> (reading the postinst)
[14:04] <pitti> RAOF: I gave you bug 948848, if that's alright with you? I think you know the cli-common stuff best in the desktop team
[14:04] <ubot2`> Launchpad bug 948848 in gnome-desktop-sharp2 "lucid to precise upgrade: libgnomedesktop2.20-cil failed to remove : Can't locate File/Basename.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/share/cli-common/runtimes.d/mono line 12. BEGIN failed--compilation aborted at /usr/share/cli-commo
[14:06] <tkamppeter> didrocks, can you also paste your files /var/cache/cups/ppd-updates and /var/lib/dpkg/info/cups.postinst
=== JackyAlcine_ is now known as jalcine
[14:08] <didrocks> tkamppeter: sure http://paste.ubuntu.com/873042/ and http://paste.ubuntu.com/873043/
[14:08] <didrocks> tkamppeter: the timestamp of ppd-updates is when I --reinstall
[14:15] <pitti> does anyone fancy working on bug 872701?
[14:15] <ubot2`> Launchpad bug 872701 in libxklavier "Keyboard layout doesn't change" [Undecided,Confirmed] https://launchpad.net/bugs/872701
[14:18] <seb128> pitti, like anyone would ever enjoying working on keyboard stuff? ;-)
[14:19] <pitti> well, I wanted to at least ask :)
[14:19]  * pitti grabs
[14:23] <mitya57> pitti: (or anybody else) - can we please drop python-gtkspell from precise?
[14:23] <mitya57> the binary is being built from gnome-python-extras
[14:24] <mitya57> and it was split out because we needed it in main
[14:24] <pitti> there are still some 20 rdepends
[14:24] <mitya57> the binary *is built* from gnome-python-extras
[14:25] <mitya57> standalone source package doesn't make any sense anymore
[14:25] <pitti> oh, I see what you mean
=== jalcine_ is now known as JackyAlcine_
=== JackyAlcine_ is now known as webjadmin
[14:26] <pitti> mitya57: done
=== webjadmin is now known as JackyAlcine
=== JackyAlcine is now known as jalcine_
=== jalcine_ is now known as jalcine
[14:26] <mitya57> excellent!
[14:29] <tkamppeter> didrocks, can you give me the logs of your Oneiric->Precise update which made printing stop for you?
[14:30] <didrocks> tkamppeter: I don't know when it stopped TBH, I'm not printing everyday
[14:31] <didrocks> tkamppeter: and I upgraded like 4 months ago
[14:31] <didrocks> tkamppeter: IIRC, it worked on precise at some point
[14:31] <didrocks> tkamppeter: but right now, it's completely broken, any idea?
[14:34] <pitti> seb128, didrocks: why does gnome-session Recommends: unity? it causes bug 936761
[14:34] <ubot2`> Launchpad bug 936761 in gnome-session "Mythbuntu upgrade from Lucid to Precise pulls in all of unity" [High,Confirmed] https://launchpad.net/bugs/936761
[14:35] <seb128> pitti, it does recommend unity | unity-2d | gnome-shell
[14:35] <pitti> it does sound a bit like a layering violation
[14:35] <seb128> pitti, and because it's useless without any of the required components
[14:35] <didrocks> pitti: it contains the 3 sessions above
[14:35] <seb128> pitti, you want installing gnome-session to give you a working session
[14:36] <seb128> pitti, it wouldn't without that
[14:36] <pitti> ok, so we need to break it further above
[14:36] <pitti> gnome-bluetooth -> gnome-control-center -> gnome-session
[14:36] <pitti> (all recommends)
[14:36] <pitti> didrocks, seb128: would it be enough to have g-c-c recommends: gnome-session-bin?
[14:37] <pitti> or drop it completely? that recommends doesn't seem very useful really
[14:38] <didrocks> I don't care about removing the recommends
[14:38] <seb128> pitti, the reason it's there is that g-c-c uses some of the gnome-session dbus interfaces
[14:38] <seb128> pitti, but yeah, if we need to drop a valid recommends that's the less annoying to drop
[14:38] <pitti> that would be -bin then?
[14:38] <seb128> pitti, right
[14:38] <pitti> seb128: ok, I'll change it to -bin then
[14:39] <pitti> thanks!
[14:39] <seb128> pitti, yw!
[14:39] <didrocks> thanks pitti :)
[14:39] <seb128> pitti, that's g-c-c?
[14:39] <pitti> seb128: yes
[14:39] <seb128> pitti, I probably have an upload to do for it later, feel free to just put in the vcs if you want
[14:39] <pitti> yes, I was going to
[14:39] <pitti> seb128: earning you another bug :)
[14:40] <seb128> lol
[14:40] <pitti> (no worries, j/k)
[14:40] <seb128> pitti, I need to, you scored like anoter 5 bugs with apport! stop writing buggy code just to collect fixes! ;-)
[14:40] <didrocks> the bug counter doesn't take into account [ Martin Pitt ] ?
[14:40] <seb128> didrocks, no
[14:40] <pitti> no, it doesn't
[14:40] <didrocks> oh, I have evil ideas coming :p
[14:41] <pitti> seb128: pushed
[14:41] <seb128> didrocks, like collecting all the fixes from dx is not enough? ;-)
[14:41] <seb128> pitti, danke
[14:41] <pitti> I'm just reviewing http://status.qa.ubuntu.com/reports/kernel-bugs/reports/rls-mgr-p-tracking-bugs.html
[14:42] <didrocks> seb128: no, it seems I didn't secure enough my position when the release is blocked :p
[14:42] <mhr3> didrocks, that's what you get for blocking for so long :P
[14:43] <didrocks> mhr3: that's what you get writing so many regressions! :p
[14:44] <mhr3> didrocks, i'm not the one who's about to be dethroned from being #1
[14:44] <didrocks> mhr3: agreed on that, you are on the good side! ;)
[14:45] <mhr3> didrocks, now i tell you a secret, we introduced all those regression just because of this *evillaugh*
[14:46] <didrocks> mhr3: I don't care, 5.4 is good enough in precise! :p
[14:46]  * didrocks *evillaugh* as well :)
[14:47] <didrocks> mhr3: btw, lazy loading of lenses, and music rhythmbox lens, when do you get tests/approvals? :)
[14:47]  * desrt misses the good old days where g-c-c was gcc
[14:48] <mhr3> didrocks, 1) there's a manual test 2) when you unfreeze :P
[14:48] <didrocks> mhr3: I meant "approval" not "merging" :)
[14:48] <didrocks> mhr3: I was picky on words! ;)
[14:49] <mhr3> didrocks, there's no point in reviewing if it can't be merged
[14:49] <mhr3> j/k
[14:49] <didrocks> mhr3: crack on the whip on your coworkers then to fix the regressions I spotted end of last weeks :p
[14:50] <didrocks> mhr3: ah sooooooo, you are on holidays!
[14:50] <didrocks> got it :)
[14:50] <mhr3> didrocks, i am?
[14:50] <didrocks> how is the swimming pool? ;)
[14:50] <didrocks> mhr3: well, no review, waiting on other to fix their issues, seems like it then :p
[14:50] <didrocks> </kidding>
=== chaoticuk_ is now known as chaoticuk
[14:51] <mhr3> didrocks, and just chatting at the watertank, right? :)
[14:51] <mhr3> but yea, swimming pool is awesome, it's just kind frozen :P
[14:51] <mhr3> like everything i guess
[14:52] <m4n1sh> its cold there? wth
[14:52] <didrocks> mhr3: all is relative, it depends on which kind of drinks you are using :)
[14:53] <desrt> didrocks: how goes unity 5.6?
[14:53] <mhr3> didrocks, oh that's why atlantic doesn't freeze near coast of france? :)
[14:53] <didrocks> mhr3: :p
[14:54] <desrt> ogra_: good afternoon
[14:54] <ogra_> hey
[14:54] <didrocks> desrt: following lyon's weather? it got warmer at the end of last week and snowing on Monday :)
[14:54]  * ogra_ would really like to know why xorg got so crashy recently
[14:54] <jalcine> where can I find a link to HIG?
[14:55] <didrocks> ogra_: ah, for you as well? do you have a lot of writing in the disk when it crashes?
[14:55] <desrt> ogra_: you bought a transformer prime yet? (or know someone who did?)
[14:55] <mhr3> the correlation between weather and unity release is unraveling
[14:55] <desrt> mhr3: i'm still trying to figure out what it all means.  i can't reason from a sample size of 1.
[14:55] <ogra_> desrt, nope, i'm happy with my "old" transformer
[14:55] <ogra_> didrocks, hard to tell, my arm netbook doesnt have any disk indicator
[14:56] <mhr3> desrt, no worries, didrocks can give you detailed history
[14:56] <mhr3> maybe wolframalpha could it too :)
[14:56] <mhr3> could do it*
[14:56] <desrt> alpha: please correlate release dates of unity to weather patterns in southern france
[14:57] <didrocks> desrt: when, before doing a release, we freeze trunk
[14:57] <didrocks> desrt: on last Friday, I was pretty confident we can unfreeze and release
[14:57] <didrocks> but Monday spotted new issues
[14:57] <didrocks> so, we are really frozen :)
[14:58] <ogra_> brrrr
[14:59] <desrt> didrocks: were these issues about the menu disappearing, or something else?
[15:00] <didrocks> desrt: no, issues with pressing alt not showing the appmenu for non gtk3 apps (so gtk2, qt, xul)
[15:01] <didrocks> desrt: and another regression from a yesterday's fix
[15:01] <didrocks> on typing ^o in the dash
[15:03] <mhr3> didrocks, i thought the ^o fix broke ibus
[15:04] <didrocks> mhr3: yeah, it's the regression I'm speaking about, it broke ibus and Ctrl + code
[15:04] <mhr3> ok
[15:04] <mhr3> anyway, back to doing something useful
[15:11] <jbicha> good morning
[15:11] <seb128> hey jbicha, how are you?
[15:12] <jbicha> seb128: doing fine, annoyed at the gnome-keyring thing though ;)
[15:12] <seb128> the "hard to update"?
[15:14] <jbicha> well it works for me here except for 2 bugs we've reported to seahorse but who knows if there's other bugs
[15:15] <jbicha> I wish I had realized what the upstream gnome shell ffe was really asking for and spoken up before it happened
[15:20]  * didrocks really wonders what writes this dconf value on the live :/
[15:20] <seb128> jbicha, can we revert that g-s patch in our 3.4?
[15:21] <jbicha> seb128: I haven't looked at doing that yet, I'm sure it's "possible" but gnome-shell development is so rapid it'd probably be a headache
[15:25] <seb128> hum, k
[15:25] <seb128> need to go out, bbiab
[15:25] <czajkowski> aloha
[15:26] <czajkowski> daft question time, I know there was a bug a while back where the power icon wasnt showing the power draining or when it was plugged in.  I reported it.  Today am back with the issue of display not increasing in brightness when plugged in to power, and the power icon isn't showing it is being drained again, just lost work as it shut down.
[15:27] <didrocks> desrt: if I strings ~/.config/dconf/user, I should see some key that are not on the default right?
[15:27] <didrocks> desrt: there is a key change in the live cd for unity-2d (hide-mode set at 0"
[15:28] <didrocks> which is set even when the user starts in 3d (and didn't ever start 2d, so not the application itself)
[15:28] <didrocks> if I gsettings reset, I get back the default value
[15:28] <didrocks> so obviously, something is wrong with the live user (which is created on the fly)
[15:28] <didrocks> any idea to debug it?
[15:31]  * desrt appears perplexed
[15:31] <desrt> how is the live user's initial dconf database created?
[15:32] <didrocks> that's my question, the user is created on the fly by casper
[15:32] <didrocks> IIRC
[15:32]  * didrocks grep the script if it's still the case
[15:32]  * desrt doesn't know anything about that
[15:32] <desrt> i guess it does some gsettings or dconf writes
[15:32] <didrocks> it was in 10.04, I didn't touch since :)
[15:32] <desrt> maybe it sets the hide mode...
[15:32] <didrocks> desrt: I tried grep -r gsettings -> nothing by a11y
[15:33] <desrt> didrocks: dconf?
[15:33] <desrt> didrocks: strings on ~/.config/dconf/user is kinda lame, btw
[15:33] <desrt> do instead: dconf dump /
[15:34] <didrocks> desrt: ok, adding universe to the live repo and installing dconf binary, one sec
[15:34] <desrt> http://paste.ubuntu.com/873134/
[15:35] <desrt> ^ this is some kind of fail
[15:35] <pitti> cyphermox: good morning
[15:35] <desrt> that's the result of logging into a guest session
[15:36] <pitti> cyphermox: I'm a bit confused about your response to bug 948613
[15:36] <ubot2`> Launchpad bug 948613 in bluez "[FFE] Enable the Source and Gateway audio profiles in bluez by default" [Undecided,Incomplete] https://launchpad.net/bugs/948613
[15:36] <pitti> cyphermox: "i.e. not idle, drawing more power than if it's normally enabled but not paired with anything"
[15:36] <cyphermox> yeah
[15:36] <didrocks> desrt: the live session is even worst
[15:36] <pitti> cyphermox: ITYM "it won't draw more power if not paired"?
[15:36] <cyphermox> well, if you just have bluetooth and never touch it, by default the device is *enabled*, as in not powered off or rfkilled
[15:36] <cyphermox> that has to draw some power
[15:36] <didrocks> desrt: the migration part is because of me btw, sorry ;)
[15:37] <pitti> cyphermox: yes, understood
[15:37] <pitti> cyphermox: I meant if we then enable the "source" option by default, does that make a difference?
[15:37] <cyphermox> so as long as it's not paired it won't be drawing more power, so no
[15:37] <pitti> cyphermox: ah, thanks; I thought so, but thanks for the confirmatino
[15:37] <cyphermox> the Source option only means that gets added to the profiles the device lists as supporting when something tries to pair to it :)
[15:38] <cyphermox> (same for Gateway too)
[15:38] <didrocks> desrt: scripts/casper-bottom/25adduser in capser, it's what adding the user, so normally "clean profile"
[15:39] <pitti> cyphermox: bug updated
[15:39] <pitti> cyphermox: so that sounds rather harmless then
[15:39] <cyphermox> pitti: the trick is just that it's a little confusing because if I enable bluetooth on my phone, it will automatically try to pair with my computer because that profile is enabled, just like it automatically tries to pair with my bluetooth headset if that's on
[15:39] <pitti> cyphermox: yes, same here
[15:39] <pitti> my computer also automatically re-connects with my headset once I switch it on
[15:39] <cyphermox> pitti: yes, the goal is mostly just to avoid people touching these config files for no reason, because that's silly if we can provide it
[15:39] <pitti> which is nice, it didn't use to in oneiric and earlier (that was a bug)
[15:39] <cyphermox> pitti: right
[15:40] <desrt> http://paste.ubuntu.com/873143/
[15:40] <didrocks> desrt: user live session (beta1), without permanent disk: http://paste.ubuntu.com/873144/
[15:40] <didrocks> desrt: see that hide-mode for 2d is at 2
[15:40] <didrocks> and as well super key enabled…
[15:41] <desrt> so a lot of these settings are done by GNOME too
[15:41] <desrt> seems upstream has some issues here..
[15:41] <desrt> not as many, but still some
[15:41] <didrocks> hum, what possibly can be doing this…
[15:41] <desrt> well
[15:42] <didrocks> without any call to gsettings in casper
[15:42] <desrt> in my case, it's apps
[15:42] <didrocks> yeah, not in unity-2d though
[15:42] <desrt> [org/gnome/desktop/wm/preferences]
[15:42] <desrt> num-workspaces=2
[15:42] <desrt> wtf
[15:42] <desrt> as if that makes any sense at all in gnome-shell?
[15:42] <didrocks> (as I'm dumped in 3d sessionà
[15:43] <desrt> tedg: http://paste.ubuntu.com/873134/
[15:43] <desrt> tedg: indicator datetime should be fixed to not do this...
[15:43] <didrocks> nothing in skel…
[15:44] <desrt> didrocks: unity should be fixed too.  it's setting average-bg-color in addition to the favourites stuff
[15:44] <desrt> and uh... it's still in /desktop/ ?!
[15:44] <didrocks> desrt: yeah, I tried to make them moving the schema last cycle, didn't work out
[15:45] <didrocks> for average-bg-color, I guess it's how unity and notify-osd share the value, but not sure. Ask Mirco
[15:45] <desrt> MacSlow: ping
[15:46] <tedg> desrt, ?
[15:46] <didrocks> desrt: but that still doesn't help me to find the culpurit for -2d :p
[15:46] <tedg> desrt, Do what?
[15:46] <desrt> tedg: it's inappropriate to write to gsettings except in response to explicit user interaction
[15:46] <desrt> tedg: the datetime indicator is writing to gsettings as a result of logging in
[15:46] <desrt> this makes login take substantially longer
[15:46] <tedg> desrt, Hmm, yes, that's a bug.
[15:46] <tedg> desrt, Which key is being written?
[15:46] <desrt> tedg: http://paste.ubuntu.com/873134/
[15:47] <tedg> All of them?
[15:47] <desrt> this is the list of everything that is written to dconf logging into a clean guest account
[15:47] <tedg> Oh, my.
[15:47] <desrt> some of those are GNOME bugs
[15:47] <desrt> i'm pursuing that upstream
[15:47] <desrt> but unity and datetime inidcator are also quite guilty
[15:48] <MacSlow> desrt, what's up?
[15:49] <desrt> MacSlow: are you storing average-bg-color in GSettings?
[15:49] <MacSlow> desrt, regarding the "average-bg-color"... yes using gsettings to "share" that value
[15:49] <desrt> MacSlow: GSettings is not an IPC mechanism
[15:50] <desrt> it's a database of user preferences
[15:50] <desrt> please use something else for IPC
[15:50] <desrt> because dconf is very very very slow for that purpose
[15:50] <tedg> desrt, Does g_settings_bind() cause a write?
[15:50] <MacSlow> desrt, true... but for "average-bg-color" it's a bit inbetween
[15:51] <MacSlow> desrt, so you would stick to dbus?!
[15:52] <desrt> tedg: only if the property changes
[15:52] <desrt> MacSlow: i'd probably stick it on a root window property
[15:53] <desrt> MacSlow: but dbus would definitely be a better alternative to dconf
[15:53] <tedg> desrt, Hmm, datetime only calls, g_settings_new, g_settings_get* and g_settings_bind*
[15:53] <Beret> anyone seen Jason?
[15:53] <desrt> tedg: and one of the properties you are binding to are probably changing...
[15:53] <desrt> tedg: or several of them, i guess
[15:54] <didrocks> Beret: which one, Smith or Warner? :)
[15:54] <Beret> warner
[15:54] <desrt> tedg: the default bind behaviour is to set the initial value of the property from the value in gsettings and only write back if it changes after that
[15:54] <Beret> sorry, definitely a redundant question
[15:54] <Beret> err
[15:54] <Beret> ambiguous
[15:54] <tedg> desrt, Hmm, I wonder if we're binding before the defaults get set...
[15:55] <desrt> tedg: gsettings also has no way to tell if a ::notify on the property is spurious
[15:55] <mvo> chrisccoulson: so firefox is segfaulting on me in atk_object_set_name() - anything I can do about that?
[15:55] <tedg> desrt, Well, it wouldn't write unless the value changed, no?
[15:55] <chrisccoulson> mvo - https://bugzilla.mozilla.org/show_bug.cgi?id=733712
[15:55] <ubot2`> Mozilla bug 733712 in Disability Access APIs "Don't call atk_object_set_name" [Critical,New: ]
[15:55] <chrisccoulson> you can upgrade atk :)
[15:56] <mvo> fair enough, thanks!
[15:56] <didrocks> Beret: he's on holidays
[15:56] <mvo> I will wait for seb128 to upgrade atk for me :)
[15:56] <Beret> ah
[15:56] <Beret> didrocks, happen to know until when?
[15:57] <desrt> tedg: a gsettings write is always a write
[15:57] <chrisccoulson> mvo - oh, it's already uploaded. you just need to do apt-get upgrade ;)
[15:57] <desrt> even if the value does not change
[15:57] <didrocks> Beret: as the holiday calendar says, until EOW, so back next week :)
[15:57] <Beret> didrocks, or more importantly, who is his proxy when he's out?
[15:57] <mvo> chrisccoulson: I did that 10s ago
[15:57] <didrocks> Beret: pitti I guess
[15:57] <chrisccoulson> and it's still broken?
[15:57]  * mvo does another one
[15:57] <chrisccoulson> are you using a mirror?
[15:57] <desrt> the reason for that is that you may be writing an explicit value over top of the existing default value with the intent that when the default value changes in the future the new value will remain
[15:57] <Beret> didrocks, thanks :)
[15:57] <didrocks> yw :)
[15:58] <chrisccoulson> mvo - you need this version: https://launchpad.net/ubuntu/+source/atk1.0/2.3.91-0ubuntu2
[15:58] <tedg> desrt, It seems that would make sense for _set() but _bind() is different.
[15:58] <tedg> desrt, Chances are you're not giving the same intention in that case.
[15:58] <mvo> chrisccoulson: many thanks!
[15:59] <tedg> desrt, As it could be expected multiple writes to a property would have no bearing on it.
[15:59] <tedg> What this says to me is that _bind() is broken and unpredictable.
[15:59] <mvo> chrisccoulson: I'm a happy puppy again
[15:59] <tedg> :-/
[15:59] <chrisccoulson> excellent :)
[16:02] <desrt> tedg: i could buy that argument
[16:02] <desrt> tedg: at the same time, though, objects should only emit ::notify when the property has actually changed
[16:02] <desrt> so a workaround for that at the level of gsettingsbind would just be a workaround
[16:02] <desrt> a) it hides the root cause of the problem
[16:02] <desrt> b) workarounds tend to introduce unintended side-effects in weird cases
[16:03] <desrt> tedg: it may very well be that we're dealing with bugs in the widgets that you're binding to
[16:03] <desrt> or the gsettings binding code itself may be faulty
[16:03] <desrt> either way, i'd like to find the root cause
[16:04] <desrt> seb128: do you know if there is some extra logic for guest session logins?
[16:04] <desrt> [org/gnome/desktop/lockdown]
[16:04] <desrt> disable-lock-screen=true
[16:04] <desrt> this, for example, seems to be a guest account 'specialty'
[16:05] <didrocks> desrt: ok, so I'll look on my own then, there is no way to know the process calling a write I guess?
[16:05] <desrt> didrocks: bustle?
[16:06] <tedg> didrocks, https://launchpad.net/bustle-boot-log
[16:07] <didrocks> can try to install that if I unsquasf and resquasf the CD I guess
[16:07] <didrocks> thank desrt, tedg
[16:07] <desrt> for a while i've been considering adding some 'blame' indicator to dconf service
[16:07] <desrt> that on the very first incoming request it does a bit of detective work to determine who is responsible for it being started
[16:08] <desrt> (bus name, pid, process name, key written to, etc)
[16:08] <didrocks> that would be really handy in that case for instance :)
[16:09] <desrt> i think i'll do that now, in fact
[16:09] <desrt> will help me trace down these bugs
[16:09] <desrt> and will help you at the same time
[16:09] <didrocks> desrt: I'm stil unsquashfs in case a grep can help, but yeah, can be handy :)
[16:09] <desrt> didrocks: well, you cna always reinstall your dconf package, logout, login?
[16:10] <didrocks> (anyway, I'll need to create my own live again to ensure the needed bits are in)
[16:10] <desrt> well
[16:10] <didrocks> desrt: not really, as the ubuntu user is only created on first boot
[16:10] <desrt> this will get into the live CD by release, i guess
[16:10] <desrt> hmmmmmm
[16:10] <desrt> okay.  so that's more interesting, then
[16:10] <didrocks> I want to have something as close as possible to the CD
[16:10] <desrt> because i was going to have it only enabled by an environment variable like DCONF_BLAME=1 or something
[16:10] <desrt> but that won't work very well for the live CD
[16:11] <didrocks> yeah
[16:11] <desrt> because you have no place to set it before the first login
[16:11] <didrocks> can a special switch of the package
[16:11] <didrocks> in the build
[16:11] <desrt> the trouble is that it's a substantial amount of extra work to discover the pid and process name
[16:11] <didrocks> and then, I unsquashfs, chroot
[16:11] <didrocks> install the package
[16:11] <desrt> and i don't want this in the usual case
[16:11] <didrocks> create the squash
[16:11] <didrocks> and boom
[16:12] <desrt> is there a way to set environment variables from the kernel commandline?
[16:12] <desrt> (could there be?)
[16:12] <didrocks> that's an interesting question I never asked myself :)
[16:12]  * didrocks googles
[16:12] <desrt> that would be a very helpful debugging tool
[16:13] <desrt> Anything of the form `foo=bar' that is not accepted as a setup function as described above is then interpreted as an environment variable to be set. An example would be to use TERM=vt100 or BOOT_IMAGE=vmlinuz.bak as a boot argument. These environment variables are typically tested for in the initialization scripts to enable or disable a wide range of things.
[16:13] <desrt> hum.
[16:13] <didrocks> yeah, found that as well
[16:14] <desrt> i doubt anything you set here would make it through to the user session, though
[16:14] <ricotz> seb128, jbicha, the gcr 3.3.90 dep of g-s is easily revertable
[16:14] <desrt> let me test that theory :)
[16:14] <didrocks> desrt: probably not though :/
[16:15] <desrt> doesn't make it into the user session
[16:16] <desrt> it seems that upstart strips it out
[16:16] <desrt> according to 'ps e', pid 1 is the only process that has that in its environment
[16:16] <didrocks> no fun, that would have been awesome
[16:16] <desrt> i wonder what systemd does :)
[16:17] <didrocks> http://www.mail-archive.com/upstart-devel@lists.ubuntu.com/msg00303.html
[16:19] <desrt> ya.  not really acceptable.
[16:19] <desrt> a central whitelist of every possible environment variable is an infuriating concept
[16:19] <desrt> if i have access to the kernel commandline then ... uh... it should be assumed that i can do whatever i want :)
[16:20]  * desrt checks what systemd does here
[16:20] <didrocks> kind of simple solution, making a script in rc.d: http://www.mail-archive.com/upstart-devel@lists.ubuntu.com/msg00306.html
[16:21] <didrocks> we want that on every computers, aren't we? :)
[16:21] <desrt> huh.  interesting idea.
[16:21] <desrt> have dconf attempt to open /proc/cmdline
[16:22] <desrt> it's not the *worst* idea i've ever heard....
[16:22] <didrocks> still a workaround
[16:22] <didrocks> but yeah
[16:25] <desrt> so systemd lets the environment through
[16:25] <desrt> all system services end up with it
[16:25] <desrt> that's an improvement
[16:25] <desrt> still doesn't end up in the user's session, though
[16:25] <desrt> i bet pam has something to do with that
[16:26] <didrocks> yeah, there is probably some stripping done
[16:27] <desrt> so for now i think i will take both options
[16:27] <desrt> 1) check the environment for DCONF_BLAME
[16:27] <desrt> 2) failing that, open /proc/cmdline and check there
[16:27] <desrt> that should handle both the case of someone wanting to do some local debugging without a reboot and your livecd case
[16:28] <didrocks> seems fine :)
[16:29] <didrocks> I hope the guilty won't be a gsettings pid as some script can directly call gsettings
[16:29] <desrt> that would be quite obnoxious, indeed
[16:29] <desrt> if that happens, we can step it up a notch and record the parent process as well
[16:30] <didrocks> that's maybe something to take into account
=== jalcine is now known as JackyAlcine_
=== JackyAlcine_ is now known as jalcine
[16:53] <seb128> re
[16:53] <seb128> that channel is crazy, out an hour and I've an hour worth of reading
[16:54] <didrocks> seb128: for once it's not you chatting! :)
[17:00] <seb128> didrocks, desrt: did you figure the gsettings stuff?
[17:00] <seb128> desrt, what about guest session? did you get a reply!
[17:00] <seb128> mvo, stop lagging behind :p workaround otherwise was: stop using a11y
[17:00] <seb128> ricotz, ok
[17:00] <didrocks> seb128: not yet, desrt is going to make a version of dconf with this env variable
[17:00] <seb128> did I forget anyone? ;-)
[17:00] <didrocks> so that we can see what is the offender
[17:01] <didrocks> I unsquashfs the live as well
[17:01] <seb128> desrt, didrocks: speaking about dconf, no tarball for several GNOME release, florian is waiting for his fix to land
[17:01] <didrocks> and grep -r
[17:01] <didrocks> just in case :)
[17:02] <didrocks> seb128: desrt will have one soon with this env variable stuff
[17:07] <seb128> desrt, didrocks: I found it
[17:07] <seb128> unity-2d-5.6.0/debian/unity-2d.gconf-defaults:/desktop/unity-2d/launcher/hide_mode
[17:07] <seb128> combined with
[17:07] <seb128> unity-2d-5.6.0/data/unity-2d.convert:hide-mode = /desktop/unity-2d/launcher/hide_mode
[17:07] <seb128> gconf -> gsetting migration
[17:07] <seb128> with a .gconf-default leftover
[17:08] <seb128> unity-2d-5.6.0/debian/unity-2d.gconf-defaults:/desktop/unity-2d/launcher/hide_mode 2
[17:08] <didrocks> urgh
[17:08] <didrocks> nice catch seb128 :)
[17:08] <seb128> ;-)
[17:09]  * didrocks stops his grep -r on squashfs
[17:09] <didrocks> I guess some question on the "why do you have some values set by default" from desrt also get some answers from that
[17:10]  * didrocks kills gconf in unity-2d
[17:12] <desrt> seb128: i'm going to do a release soon
[17:13] <desrt> complete with blame mode for didrocks :)
[17:13] <seb128> desrt, well he doesn't need it now
[17:13] <desrt> oh
[17:13] <didrocks> blame mode will always been needed anyway :)
[17:13] <seb128> desrt, but I could use it to do the "make sure nothing write a login"
[17:13] <desrt> i need it :)
[17:14] <desrt> seb128: i'm almost done... support is in the service already
[17:14] <desrt> but you have to use d-feet to query it, presently
[17:14] <desrt> so i will add 'dconf blame' to the commandline tool
[17:26] <desrt> cool.  done.
=== zyga is now known as zyga-food
[17:28] <desrt> seb128, didrocks: http://fpaste.org/qKBt/
[17:28] <seb128> desrt, nice!
[17:29] <desrt> just need to boot the kernel with 'DCONF_BLAME=1' on the commandline somewhere
[17:29] <didrocks> great :)
[17:31] <desrt> MacSlow: you are the first victim of dconf-blame :)
[17:32] <MacSlow> desrt, I'll change it... but not today :)
=== chrisccoulson_ is now known as chrisccoulson
[17:41] <chrisccoulson> i'm sure that ruby has been at my coffee
[17:41] <chrisccoulson> she's going crazy!
[17:41] <chrisccoulson> running around pretending to have hiccups
[17:41] <seb128> lol
[17:46] <desrt> MacSlow: you need to fix this ASAP
[17:46] <desrt> http://paste.ubuntu.com/873324/
[17:46] <desrt> guest-Gt2HeR@moonpix:~$ grep average-bg-color blames | wc -l
[17:46] <desrt> 23
[17:46] <desrt> you're writing to dconf 23 times on login
[17:46] <seb128> desrt, I think there is a fix in the queue for a week
[17:46] <desrt> i wouldn't be surprised if you're adding like 1s to the boot
[17:46] <seb128> desrt, talk to didrocks about unfreezing
[17:47] <seb128> https://code.launchpad.net/~gordallott/unity/bghash-only-emit-on-change/+merge/94161
[17:47] <seb128> "Makes bghash only change the gsettings key once per wallpaper change, instead of on every frame it transitions to the next wallpaper."
[17:47] <desrt> okay.  good :)
[17:47] <seb128> desrt, oh, it landed, you don't run the ppa?
[17:47] <desrt> not perfect, but better, at least :p
[17:47] <desrt> seb128: the unity staging PPA?
[17:47] <didrocks> seb128: it did land :p
[17:47] <seb128> desrt, right
[17:47] <didrocks> not my fault
[17:48] <didrocks> not my fault
[17:48] <desrt> i learnt a while ago that i run that PPA if i want to hate myself :)
[17:48] <didrocks> not my fault
[17:48] <seb128> ;-)
[17:48] <didrocks> :)
[17:48] <seb128> desrt, well, it's a double edge sword
[17:48] <didrocks> desrt: come on!
[17:48] <seb128> desrt, you are missing this fix :p
[17:48] <didrocks> desrt: it's done with love ;)
[17:48] <desrt> so we have a problem with gsettings-data-convert
[17:48] <desrt> something about the way you do your default overrides in gconf comes across looking like a user value to gsettings-data-convert
[17:48] <desrt> resulting in writes to dconf
[17:49] <desrt> we probably need to find a way to fix that
[17:49] <seb128> desrt, can you open a bug somewhere?
[17:49] <desrt> seb128: i've opened a bug upstream
[17:49] <seb128> ok, great
[17:49] <seb128> thanks
[17:50]  * desrt wants to get this down to 0 for LTS
[17:50] <desrt> didrocks: you should fix migrate_favorites.py as well
[17:50] <desrt> didrocks: it should not be writing new values to gsettings unless there are old values to read
[17:50] <didrocks> desrt: so, the question is, how would you mark the migration level?
[17:51] <desrt> which is not the case when logging into a fresh guest session...
[17:51] <desrt> didrocks: the gconf migration tool uses a directory in ~
[17:51] <didrocks> desrt: hum, it's not "one shot"
[17:51] <didrocks> like, we had to migrate defaults twice for instance for now
[17:51] <desrt> why?
[17:52] <didrocks> so, that's why there is a version stamped
[17:52] <didrocks> well, in the past, we had first unity (the 10.10 version)
[17:52] <didrocks> then, people wanted that we migrate more
[17:52] <didrocks> (from other docks)
[17:52] <didrocks> so, even people already using 10.10 with unity were migrated
[17:52] <desrt> so that should have been a separate migration script, i guess?
[17:52] <didrocks> and maybe, as the launcher hardcode .desktop file name
[17:52] <didrocks> hum
[17:53] <didrocks> that makes things more complicated, but can work
[17:53] <didrocks> but you will do a "stamp" for every migration script
[17:53] <didrocks> on the file system?
[17:53] <seb128> desrt, didrocks: it's not like 1 write one time would be an issue
[17:53] <desrt> look at ~/.local/share/gsettings-data-convert
[17:53] <desrt> it's a keyfile that marks the conversion tasks that have been run already
[17:54] <didrocks> yeah, but it means that unity will have to read it at every start
[17:54] <desrt> and it's quite fast -- we check only timestamps of the conversion scripts directory and the keyfile in order to know if we're up to date
[17:54] <didrocks> and I thought dconf would be faster than that :)
[17:54] <desrt> which is one check for *every* conversion
[17:54] <didrocks> one check at every boot
[17:54] <desrt> not each
[17:55] <didrocks> to know if you already converted
[17:55] <desrt> at every login, in fact
[17:55] <desrt> but it's strictly one
[17:55] <desrt> not one per module... just one
[17:55] <didrocks> indeed, and why dconf isn't set for storing such data?
[17:56] <desrt> because the first activation of dconf-service is very slow
[17:56] <desrt> and it's something that should not happen when you login
[17:56] <desrt> one less process to start = faster login
[17:56] <didrocks> hum
[17:56] <didrocks> but some other values are still read
[17:57] <didrocks> like the unity launchers
[17:57] <GunnarHj> micahg: ping?
[17:57] <didrocks> so the process start at the same time?
[17:57] <desrt> didrocks: no
[17:57] <didrocks> (well 3 lines of code after)
[17:57] <desrt> didrocks: dconf-service only starts when you do a write
[17:57] <didrocks> desrt: ok, so it's only "slower" on the first login
[17:57] <didrocks> which is already the case TBH with ureadahead profiling your disk
[17:57] <desrt> yes.  i suppose so.
[17:57] <didrocks> or gnome-desktop creating your wallpaper cache
[17:57] <desrt> it's not a disaster
[17:58] <desrt> but strictly speaking, i consider it to be a bug
[17:58] <didrocks> I have nothing against changing the check to another place
[17:58] <didrocks> but it seems just to put some crap on disk somewhere else :)
[17:58] <desrt> as a matter of general principle, you should be able to login to your desktop and see that your dconf database does not exist
[17:58] <didrocks> and handing transition as well ;)
[17:58] <desrt> but you're right
[17:59] <desrt> this feels a lot like throwing garbage over the fence
[17:59] <didrocks> and getting a lot of crappy files in .config though :p
[17:59] <desrt> migration is always a very difficult question
[17:59] <didrocks> I have no strong opinion, but I understand your intend :)
[17:59] <didrocks> intention*
[17:59] <desrt> anyway
[18:00] <desrt> there are far worse offenders in the meantime
[18:00] <didrocks> desrt: I will try to think about it though :)
[18:00] <seb128> yeah, that seems a very low priority one
[18:01]  * didrocks goes dancing, see you tomorrow!
[18:01] <desrt> didrocks: g'night
[18:01] <seb128> 'night didrocks
[18:01] <didrocks> desrt: good afternoon, bonne soirée seb128, te couche pas tard :p
[18:06] <desrt> seb128: tracking bug is here: https://bugzilla.gnome.org/show_bug.cgi?id=671566
[18:06] <ubot2`> Gnome bug 671566 in general "various bits of GNOME are writing to dconf on first login" [Normal,New]
[18:06] <desrt> as far as upstream goes there are 3 main issues to fix and 2 of them are in gnome-shell
[18:07] <desrt> i'll start looking at the gsettings-data-convert one because that's the only one that impacts ubuntu
[18:09] <desrt> seb128: how do i file desktop-wide tracking bugs?
[18:09] <seb128> desrt, you don't?
[18:09] <desrt> i guess i'll file it against dconf-in-ubuntu, then?
[18:10] <seb128> desrt, you file on one component and do "also affect..." for each component to add
[18:10] <seb128> desrt, or you open separate bugs and tag them
[18:10] <seb128> desrt, but yeah, d-conf (Ubuntu) would work
[18:12] <desrt> sigh.
=== zyga-food is now known as zyga
[18:35] <chrisccoulson> wth is going on with this build? https://launchpadlibrarian.net/95774042/buildlog_ubuntu-precise-amd64.thunderbird-trunk_13.0~a1~hg20120306r9572.88331-0ubuntu1~umd2_FAILEDTOBUILD.txt.gz
[18:35] <chrisccoulson> :(
[18:39] <dobey> chrisccoulson: does that control file have a -dbg package? it looks like it's failing to add the header to the object file to point at the debugging symbols file for a -dbg package
[18:40] <chrisccoulson> dobey, yeah, there is a -dbg package
[18:41] <dobey> chrisccoulson: i wonder what objcopy is doing that the kernel thinks is invalid.
[18:44] <desrt> tedg: so this datetime write-on-login stuff is probably somewhat related to the fact that it writes every 30 seconds, in fact
[18:44] <desrt> tedg: as steve discovered at the rally
[18:45] <tedg> desrt, Steve was saying that indicator-power wrote every 30s, and I believe that's been fixed.
[18:45] <desrt> tedg: https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/916498
[18:45] <ubot2`> Launchpad bug 916498 in indicator-datetime "indicator-datetime causes frequent disk wakeups due to dconf write" [High,Triaged]
[18:46] <tedg> desrt, Look at the string :-)  I imagine it's a typo on his part.
[18:46] <desrt> he filed it against indicator datetime...
[18:46] <desrt> so quite a typo :)
[18:47] <desrt> in any case maybe you should close the bug as invalid, then, and open a new one :p
[18:53] <micahg> GunnarHj: pong
[18:55] <desrt> seb128: there's some brokenness with the gconf packaging...
[18:55] <seb128> desrt, recent you mean?
[18:55] <desrt> probably not
[18:55] <desrt> gconf installs an xsession.d script that sets some environment variables according to DESKTOP_SESSION
[18:55] <desrt>   export MANDATORY_PATH=${GCONF_PREFIX}/${DESKTOP_SESSION}.mandatory.path
[18:55] <seb128> desrt, ok, just checking it was multiarched this week and some users hit upgrade issues
[18:55] <desrt>   export DEFAULTS_PATH=${GCONF_PREFIX}/${DESKTOP_SESSION}.default.path
[18:55] <seb128> desrt, in case you were refering to that
[18:55] <desrt> those files do not exist...
[18:56] <seb128> desrt, right
[18:56] <desrt> this is the same issue?
[18:56] <seb128> desrt, I think it was didrock's stuff to allow for specific value for derivatives
[18:56] <desrt> ah
[18:56] <desrt> so we don't use it
[18:56] <seb128> desrt, like UNE was setting stuff in their own dir
[18:56] <seb128> desrt, it's support for people to use if they want
[18:56] <desrt> gotcha
[18:56] <desrt> just making sure
[18:57] <Beret> so
[18:57] <Beret> I have a stupid question
[18:57] <Beret> what is the role of a package maintainer?
[18:57] <jalcine> No question is stupid.
[18:57] <Beret> I submitted a bug to an application
[18:57] <Beret> the result was it was confirmed as a problem and then I was asked to deal with it with the upstream and report back
[18:58] <Beret> which seemed completely odd
[18:58] <jalcine> But, package maintainers are like the people responsible for ensuring that a upstream project's builds downstream are in sync.
[18:58] <Beret> they're not responsible for the application's health in Ubuntu?
[18:58] <Beret> is that not the overall goal?
[18:58] <jbicha> Beret: which bug number?
[18:59] <Beret> #947411
[18:59] <jalcine> They are, per se, but that sounds like a peculiar situation.
[18:59] <Beret> the bug basically makes the app unusable so I thought the response I received was odd
[18:59] <desrt> seb128: so the way you guys do your default settings is tricky...
[18:59] <Beret> I just wanted to know if my expectations were out of line or something was broken
[19:00] <jbicha> if the bug is not specific to Ubuntu's packaging & it affects other distros, then it does need to be reported upstream; you're welcome to do that and if you don't want to, someone else will eventually do it
[19:01] <Beret> ok
[19:02] <Beret> for me that's OK
[19:02] <Beret> if I were an ubuntu user and I got a message like that, I would be put off
[19:02] <Beret> how would I know what upstream is or how to do that?
[19:02] <Beret> anyway, not a discussion for here
[19:02] <Beret> but thanks for the info
[19:04] <jbicha> Beret: it might be appropriate for #ubuntu-bugs, that comment is more or less part of the triage process
[19:05] <Beret> ok
[19:11] <chrisccoulson> dobey, ok, i figured it out in the end :)
[19:12] <dobey> chrisccoulson: what was it?
[19:13] <chrisccoulson> dobey, creating the breakpad symbols that we send to mozilla also adds a .gnu_debuglink section, and we were running that before doing "make install"
[19:13] <dobey> chrisccoulson: ah. so my interpretation of the error was in the right direction :)
[19:23] <micahg> GunnarHj: pon
[19:28] <seb128> desrt, re, was at dinner
[19:28] <seb128> desrt, why?
[19:31] <mvo> glatzor: hi, any chance you could review my auth-conf branch :) ?
[19:31] <mvo> glatzor: or do you have any concerns about the approach?
[19:48] <desrt> seb128: you don't patch schemas
[19:48] <desrt> seb128: rather you install new settings in a different database
[19:48] <desrt> seb128: the gconf API is unable to tell the difference
[19:49] <seb128> desrt, yeah, patching schemas is the suck :p
[19:49] <desrt> seb128: anyway.. i think i have a solution
[19:49] <seb128> desrt, it's not GNOME_ME_HARDER :p
[19:50] <seb128> desrt, btw several people asking this way, is there a "priority" in gschemas overrides?
[19:50] <seb128> desrt, like Ubuntu override the theme but xubuntu wants to override it over Ubuntu
[19:50] <seb128> how do they do that?
[19:50] <desrt> seb128: yes.
[19:50] <desrt> but i don't remember what it is
[19:50] <desrt> iirc the overrides are processed in alphabetical order
[19:50] <desrt> i don't remember if it's first-wins or last-wins, though
[19:51] <seb128> desrt, ok, seems similar to gconf where we just ordered the override by numbers
[19:51] <seb128> like we should do 1_ubuntu ... then they can do 2_xubuntu
[19:53]  * desrt is currently patching the gsettings-data-convert to only read values from the user database
[20:09] <desrt> seb128: bored?
[20:11] <desrt> seb128: if so, a gconf upload with the patches in https://bugzilla.gnome.org/show_bug.cgi?id=671581 to the desktop ppa may be fun
[20:11] <ubot2`> Gnome bug 671581 in gsettings "gsettings-data-convert interacts badly with vendor overrides" [Normal,New]
[20:11] <desrt> that fixes 11 of the dconf writes
[20:13] <desrt> (it seems that the gnome-settings-daemon one is a side-effect of the gsettings-data-convert doing the write)
[20:18] <GunnarHj> micahg: Hello, I'm waiting for you response to my comment at https://code.launchpad.net/~gunnarhj/gnome-settings-daemon/patch43/+merge/91210
[20:18] <GunnarHj> s/you/your/
[20:18] <chrisccoulson> man, i love compiz
[20:19] <desrt> chrisccoulson: me too
[20:19] <desrt> it's very shiny
[20:19] <desrt> it makes me happy
[20:20] <chrisccoulson> desrt, now, i don't know if you're being sarcastic or not
[20:20] <chrisccoulson> j/k ;)
[20:20] <desrt> chrisccoulson: is there ever really a doubt with me? :)
[20:20] <chrisccoulson> heh :)
[20:25] <seb128> hum, I wonder which one of you is an hater over the other one :p
[20:25]  * desrt is always very nice
[20:25] <dobey> uhm
[20:25] <seb128> desrt, gconf uploaded to the ubuntu-desktop ppa btw
[20:25] <dobey> how did ubuntuone-control-panel-qt get on the CD?
[20:25] <desrt> seb128: holy crap that was fast :p
[20:26] <seb128> dobey, I guess something recommends something which recommends a control-panel?
[20:26] <seb128> dobey, deja-dup Recommends ubuntuone-control-panel,
[20:26] <seb128> it's mterry's fault!
[20:27] <mterry> uh oh
[20:27] <dobey> seb128: but that doesn't recommend qt
[20:27] <dobey> oh, it does
[20:27] <seb128> Recommends: ubuntuone-control-panel-gui
[20:27] <dobey> i see
[20:27] <seb128> mterry, hey, btw, nice to see you are still around ;-)
[20:27] <mterry> deja-dup doesn't need the GUI
[20:27] <seb128> mterry, how are you?
[20:28] <desrt> seb128: he's planning to quit?
[20:28] <mterry> seb128, :)  doing yet more animation work for unity-greeter at design's request
[20:28] <mterry> desrt, no  :)
[20:28] <seb128> desrt, I hope not, I just tends to be quiet on IRC
[20:28] <seb128> like I didn't see him talk on this channel for a week, maybe out of around meeting time yesterday
[20:28]  * desrt tries to figure out what the heck is wrong with datetime indicator next
[20:29] <seb128> that's how you see people really working :p
[20:29] <seb128> in opposite to people like me who spend their day on IRC
[20:29] <chrisccoulson> that sounds a bit like me. i hardly ever talk to anyone on IRC now
[20:29] <chrisccoulson> it's like i'm in my own little cave ;)
[20:29] <seb128> to then spend their evening doing the work they didn't do during the day ;-)
[20:29] <mterry> seb128, heh
[20:29] <dobey> seb128, mterry: ok, we'll be back off the CD on the next image i guess. am having nessita remove the recommends and make it a suggests :)
[20:29] <micahg> GunnarHj: I figured a desktopper would have done that by now
[20:30] <mterry> dobey, seb128: are we going back to ubuntuone-installer days?
[20:30] <dobey> mterry: there isn't enough room on the cd for pyqt :(
[20:30] <mterry> dobey, and the gtk version is right out?
[20:30] <dobey> mterry: so afraid so, yeah.
[20:31] <dobey> mterry: yeah, and it's a transitional package now. so upgrades will install the qt version and not get the installer
[20:31] <nessita> seb128, mterry: uploading a new u1cp with recommends switched to suggests very soon
[20:31] <dobey> well, won't get the installer ui. it'll just run the new one
[20:31] <GunnarHj> micahg: I suppose that since you replaced the desktop team with yourself, it disappeared from their list.
[20:31] <chrisccoulson> well, today has been a fun day. i really feel like a beer now
[20:31] <mterry> dobey, hrm.  deja-dup does use the GUI for logging users into U1.  But last cycle I did work to support the case of launching the installer.  Hope that still works
[20:32] <nessita> mterry: I guess you're confusing the control panel UI with the SSO UI
[20:32] <mterry> nessita, oh, might be
[20:32] <nessita> mterry: the sso UI is in the CD, both  gtk and qt versions. Both steady, stable, and working
[20:32] <nessita> :-)
[20:32] <dobey> mterry: it should still work
[20:33] <nessita> mterry: so nothing should change in your user experience, please let me know if you notice something odd, I will help debug further
[20:33] <micahg> GunnarHj: hmm, seems like a bug somewhere
[20:33] <mterry> cool, thanks
[20:35] <micahg> GunnarHj: I guess I'd suggest requesting a second review from -sponsors or -desktop, I disagree with you, but there are plenty of other people who can commit to that branch who might agree with you
[20:35] <GunnarHj> micahg: I can do that, if you like. But do you really mean that you interpret those guidelines differently?
[20:37] <desrt> tedg: https://code.launchpad.net/~desrt/indicator-datetime/gvariantbuilder/+merge/96451
[20:39] <GunnarHj> micahg: It's not really worth fighting for, IMO, but since you pointed at those guidelines, which I actually had read before, your request was a little confusing to me. ;-)
[20:41] <micahg> GunnarHj: yes, I read it differently, but as I said, there could be room for other interpretation
[20:42] <desrt> tedg: i also traced down the source of your gsettings problems
[20:42] <desrt> tedg: basically you shouldn't be calling g_settings_bind() on yourself from your init function
[20:43] <desrt> tedg: the reason for that is because gobject freezes the notify queue during object construction and releases the notifies later
[20:43] <desrt> tedg: so gsettings sees a bunch of property notify signals at that time and does a bunch of writes
[20:43] <tedg> desrt, Yup, but it seems that it should really be smart about that.
[20:43] <tedg> desrt, It seems like a quite obvious way to use bind.
[20:44] <desrt> tedg: i don't think i've ever seen anyone else do it like this, in fact
[20:44] <desrt> setting properties from inside _init is a total fail
[20:44] <desrt> (see my recent blog post for reasons why)
[20:44] <tedg> desrt, Well, that was done by Karl, but I reviewed it.  I think it makes sense.
[20:44] <desrt> tedg: in any case, it looks to me that the indicator never changes the settings
[20:44] <desrt> only the preferences dialog does
[20:45] <desrt> so you could most easily solve the issue by changing them to readonly bindings
[20:45] <GunnarHj> micahg: Ok, I'll ask somebody else, no problem. On another topic, I saw that you are assigned bug 918604. Will you deal with it soon?
[20:45] <ubot2`> Launchpad bug 918604 in ubuntu "[needs-packaging] lightdm-gtk-greeter" [High,Triaged] https://launchpad.net/bugs/918604
[20:45] <desrt> tedg: i guess i have to wonder why you go to the bother of setting up gobject properties if you never use them from outside of the object...
[20:45] <desrt> there are easier ways to use gsettings than shoving everything through a property binding that only exists for the sake of binding to gsettings...
[20:46] <tedg> desrt, Well, again, not me.  I generally avoid properties to avoid GValue :-)
[20:46] <desrt> tedg: a good strategy :)
[20:46] <desrt> tedg: in any case, i'll prepare a merge with the changes to make it readonly
[20:46] <tedg> desrt, Cool, thanks!
[20:47] <desrt> i'm pretty sure that writability doesn't work anyway due to the fact that the object never emits notify signals on its own :)
[20:47] <tedg> I'll put datetime at the bottom of my release list.
[20:49] <mhr3> desrt, is there some known bug in precise with glib's q_sort_with_data?
[20:50] <micahg> GunnarHj: yeah, I meant to finish that last week, I won't be able to get to it until the weekend now though
[20:51] <GunnarHj> micahg: Ok, thanks, then I know. As I'm sure you realize, it's inconvenient that it's not in the archive.
[20:51] <micahg> GunnarHj: it is in the archive, just not buildable from source at the moment
[20:52] <mhr3> desrt, nvm, of course it's me being stupid
[20:52] <desrt> mhr3: the pointer-to-pointer thing?
[20:54] <desrt> tedg: a bit of bzr help, perhaps?
[20:54] <desrt> tedg: i branched indicator-datetime
[20:54] <desrt> i did my first patch for the gvariantbuilder thing and pushed it
[20:54] <desrt> proposed a merge
[20:54] <desrt> uncommited and reverted
[20:55] <desrt> then i did the unrelated patch about the gsettings thing, committed, pushed
[20:55] <desrt> now when i try to do a new proposal it doesn't understand that i am trying to propose the second branch i pushed (even if i explicitly specify it)
[20:55] <desrt> it keeps trying to propose the first, which gives an error about "already proposed"
[20:56] <GunnarHj> micahg: I see. Just as bad in practice, though.
[20:56] <micahg> GunnarHj: we won't release like that with it unbuildable, so I don't see the issue
[20:57] <desrt> tedg: in any case, here's the branch i pushed.  sorry i can't figure out how to propose it: https://code.launchpad.net/~desrt/indicator-datetime/readonly-binding
[21:00] <tedg> desrt, The button that says "Propose for merging" ?  :-)
[21:00] <desrt> tedg: do you know how i can convince bzr to do it?
[21:00] <tedg> desrt, bzr lp-propose-merge
[21:01] <desrt> tedg: read ^^
[21:01] <GunnarHj> micahg: Further development is blocked; isn't that enough of an issue?
[21:01] <tedg> desrt, Ah, okay.
[21:01] <desrt> https://code.launchpad.net/~desrt/indicator-datetime/readonly-binding/+merge/96454
[21:01] <tedg> desrt, Your parent is set to the other branch instead of to trunk
[21:01] <desrt> tedg: weird
[21:02] <desrt> whenever you push to a new place it sets the old default push location as the parent, i guess?
[21:02] <tedg> desrt, Yeah
[21:02] <desrt> i can see the reasonining there
[21:02] <desrt> but obviously not so good in this case
[21:02] <GunnarHj> micahg: Lubuntu has apparently succeeded in making a buildable (possibly quick-and-dirty) source package: https://launchpad.net/~gilir/+archive/lubuntu  Would that possibly something to use as a starting point?
[21:03] <micahg> GunnarHj: I already have 2 buildable versions that need to be merged
[21:03] <tedg> desrt, but what you can do is just add the second branch on the command line: bzr help lp-propose-merge
[21:04] <GunnarHj> micahg: But in that case ... No it's me who don't see the issue. ;-)
[21:04]  * tedg thinks desrt is just doing these patches for more karma
[21:04] <tedg> :-)
[21:04] <GunnarHj> s/No/Now/ (sorry for sloppy typing tonight)
[21:04] <desrt> tedg: i tried specifying the branch explicitly.
[21:04] <desrt> no help
[21:05] <tedg> desrt, You know, if you convince GLib to move to LP you'd earn a ton more karma.
[21:05] <desrt> i probably should have re-cloned instead of reverting to the previous commit
[21:05] <tedg> :-)
[21:05] <desrt> tedg: launchpad karma is worthless
[21:05] <desrt> the real competition is bugzilla points :)
[21:05] <tedg> Yeah, typically that's what I do.  Do you use bazaar shared repos?
[21:05] <tedg> It makes always branching from trunk cheap.
[21:06] <desrt> no.  i don't think that i do.
[21:06]  * desrt just bzr branch lp:whatever
[21:06] <tedg> desrt, If you do "bzr init-repo" one level up it'll use that dir for all of your version cache.  So then it'll find the revisions in there for everything you already have.
[21:06] <desrt> interesting
[21:06]  * jalcine wonders if there's a lp branch called whatever
[21:06] <desrt> that's a feature i've often wanted in git
[21:06] <tedg> desrt, So then I have my dir structure layed out ~/Development/project/branch
[21:07] <desrt> oh
[21:07] <desrt> it only works for one project?
[21:07] <desrt> not like a a sort of global object cache?
[21:07] <tedg> desrt, It can work for all, but then tags start to conflict.
[21:07] <tedg> desrt, Though, those are only warnings.
[21:07] <desrt> ya... you can do the same with git, then :/
[21:07]  * desrt wants like some cache in ~/.cache/gitcache/
[21:08] <desrt> with just ... lots and lots of objects
[21:08] <tedg> Sure, I'm not sure how you handle the tags though, at least in a VCS that has them as annotations on revisions.
[21:08]  * tedg wishes Bazaar had stronger tags
[21:08] <seb128> desrt, bah, you started doing proper merge request, I guess I need to start using git properly to make up for it ;-)
[21:08] <desrt> seb128: i thought you went to bed :p
[21:09] <desrt> seb128: we're down to only 2 things writing to dconf now
[21:09] <mhr3> desrt, no, abs (0.13) < 0.00001 == true :/
[21:09] <seb128> desrt, no, just moved to couch,tv with laptop
[21:09] <desrt> seb128: didrock's favourite migration stuff and macslow's average bg colour stuff
[21:09] <seb128> desrt, is that using unity trunk?
[21:10] <dobey> tedg: "stronger" tags?
[21:10] <desrt> seb128: no...
[21:10] <seb128> desrt, the bg stuff might be fixed for good with trunk
[21:10] <desrt> seb128: it's with the various patches i wrote today aplied
[21:10] <tedg> dobey, Where placing a tag is revisioned.
[21:10] <seb128> desrt, I didn't check but ideally it should only write it when the bg change
[21:10] <desrt> seb128: last i heard is that the background thing reduces 23 writes to 1
[21:10] <desrt> which is still more than zero
[21:10] <seb128> ok
[21:10] <desrt> didrocks i give a free pass because it only happens once on first login
[21:10] <desrt> if unity is doing this every time, ...
[21:11] <dobey> hmm. wonder how i should word a bug against rhythmbox for ffe/uife to get a new version in
[21:11] <seb128> not sure if they counted "change" as "be different from the previous computed one" or "be different than the one which was displayed"
[21:11] <desrt> (i'm even uncomfortable with didrocks, but migration is really hard stuff.... so....)
[21:11] <desrt> seb128: is the change in the unity staging ppa?
[21:11] <seb128> desrt, well first login will also have gsettings migration stuff for most users
[21:11] <seb128> desrt, yes
[21:11] <desrt> okay.  let me test
[21:12] <TheMuso> RAOF, bryceh, do we have the patch to fix this bug? https://bugs.freedesktop.org/show_bug.cgi?id=44079
[21:12] <ubot2`> Freedesktop bug 44079 in Server/Input/Core "XI2 FocusOut events missing parent of focus'd window" [Normal,Resolved: fixed]
[21:12] <desrt> seb128: the gsettings migration stuff won't happen on real first login
[21:13] <desrt> only first login after an upgrade
[21:13] <desrt> and it won't happen for guest accounts, for example
[21:14] <bryceh> TheMuso, checking
[21:14] <seb128> desrt, to be honest I don't care much about "first login"
[21:14] <seb128> desrt, that one is always going to be slow, would it only because readahead etc takes a boot to be in place
[21:15] <desrt> seb128: so the reason i care most about first login is because of smoke testing
[21:15] <desrt> seb128: the QA team is doing a test to see if dconf-service is running after login
[21:15] <desrt> of course that will be tested on 'first login'
[21:16] <desrt> so if we can try a little bit harder to make it clean so we can have it testable, i think it's worth it
[21:16] <seb128> desrt, well they can be a bit smarter, log all the calls and check to "known ones"
[21:16] <seb128> and list any unexpected one
[21:16] <desrt> seb128: that's true.  'dconf blame' will make that quite a lot easier now
[21:16] <bryceh> TheMuso, yes, both are in our xorg-server in precise
[21:17] <TheMuso> bryceh: Thanks muchly.
[21:18] <desrt> seb128: hum.  you were supposed to take both patches from that bug -- not just one
[21:18] <desrt> seb128: also: it looks like you added the patch but forgot to include it in the series
[21:19] <desrt> the first issue is not so important... it just supresses a warning... the second issue is more important... :)
[21:20] <seb128> desrt, crap, I blame slangasek
[21:21] <TheMuso> seb128: Thanks for the atk upload, I narrowed that issue down yesterday when I discovered firefox problems, but got calle daway/side tracked before I could properly test and upload a fix.
[21:21] <seb128> desrt, thanks for noticing it
[21:21] <desrt> he was distracting you? :)
[21:21] <seb128> desrt, no, he forgot to bzr add files in the vcs
[21:21] <seb128> desrt, I had it in the serie but I pointed the issue, he fixed it, I rebase but screwed the rebease
[21:21] <seb128> rebase
[21:21] <desrt> ah
[21:21]  * desrt doesn't say anything about version control systems
[21:22] <desrt> (wait?  did that count?) :)
[21:22] <seb128> TheMuso, no worry, thanks to chrisccoulson
[21:22] <seb128> desrt, ;-)
[21:22] <seb128> desrt, should I take both patches then? I didn't care much about the warning but I can include it
[21:23] <TheMuso> chrisccoulson: Indeed thanks, as above, I discovered that issue yesterday, but got sidetracked.
[21:23] <desrt> seb128: for completeness, yes
[21:23] <seb128> TheMuso, there is a new official tarball with the revert if you want to update
[21:23] <desrt> that's what will go upstream, if it does
[21:23]  * desrt checks the new unity
[21:25] <desrt> so.  it's better
[21:26] <desrt> but still 2 writes on login
[21:26] <desrt> (i tested 5 times... 4 times it had 2 writes, 1 time it had 1)
[21:28] <tedg> desrt, So I'm trying your hud-service and I'm not getting any highlighting of matched strings.
[21:28] <tedg> desrt, Is that a known TODO?
[21:28] <desrt> tedg: correct.
[21:28] <desrt> semi-known
[21:28] <desrt> i knew about it but it fell of my list
[21:29] <desrt> *off
[21:30] <seb128> "hightlight"?
[21:30] <seb128> I didn't even know the hud was doing that :p
[21:30] <desrt> seb128: if i type "open" then the hud shows
[21:30] <desrt> File > <b>Open</b>
[21:30] <dupondje> jbicha: around ?
[21:30] <jbicha> dupondje: aloha :)
[21:30] <desrt> tedg: wanted to talk to you about it, actually
[21:31] <desrt> right now you hilight the entire matched item -- not just the part of it that matched
[21:31] <dupondje> jbicha: seems gnome-shell needs some update, cause the battery indicator is broken ... :)
[21:31] <dupondje> is that on the todo list or ? :)
[21:31] <desrt> i assume that's done for sake of simplicity.... is it something we ever will want to change?
[21:32] <seb128> desrt, yeah, I just never noticed before, I never bothered typing a full word :p
[21:32] <tedg> desrt, Yes, it should be just the matched portion if it's a perfect match and then if it's not, the word.
[21:32] <tedg> desrt, So "fi" will result in "<b>fi</b>le" but "if" will result in "<b>file</b>"
[21:32] <desrt> tedg: k.  i'll keep that in mind for when i dig into the algorithm
[21:33]  * desrt has been trying to hold himself off from the perfomance improvements until the refactor branch is landed
[21:33] <tedg> It's not actually sending actions for me...
[21:33] <desrt> as in it's failing to activate menu items?
[21:34] <tedg> desrt, yes
[21:34] <desrt> olli was seeing that as well
[21:34] <tedg> Oh, that just worked...
[21:34] <tedg> Now it didn't...
[21:34] <desrt> >:(
[21:34] <desrt> tedg: so there's a bit of a weird situation...
[21:35] <desrt> tedg: and i'm not exactly sure of the best way to deal with this
[21:35] <desrt> tedg: the query now supports updating itself if new menu items appear while you're searching which is a change vs. the last version
[21:35] <desrt> tedg: however, this means that the index into the results array has to be invalidated (bceause it may be stale)
[21:35] <desrt> i currently deal with this by ignoring stale indexes
[21:36] <desrt> so if the app sends a 'change' signal in response to getting the focus back (due to the hud window closing) then the index could be stale just as it is being delivered to the hud
[21:36] <tedg> desrt, Don't make the key an index to an array, but make it something that is absolute?
[21:37] <desrt> tedg: ya... this all goes back to that stateful talk we were having earlier
[21:37] <desrt> the only way i could really do that at this point is by having a global hash of HudItem
[21:37] <tedg> desrt, i.e., for dbusmenu the path, server and ID are absolute
[21:37] <desrt> which is maybe the correct solution
[21:37] <desrt> tedg: ya... but invocations are done via hud_item_activate()
[21:37] <tedg> Why isn't the key backend specific.
[21:38] <desrt> tedg: to make it easier to extend
[21:38] <jbicha> dupondje: just added to my to-do list for this weekend since gnome-shell 3.4 in Precise will take longer than I hoped
[21:38] <dupondje> cool :)
[21:39] <dupondje> it looked to cool that my battery stayed at 99% :p
[21:39] <desrt> tedg: i'm starting to like the idea of an item hash
[21:40] <tedg> desrt, At that point it'd probably be easier to just use the memory address of the item.  And then validate it before using it.
[21:40] <tedg> desrt, Then you don't need to invent a hashing algorithm.
[21:41] <desrt> tedg: memory addresses get reused
[21:41] <desrt> rapidly so when gslice is involved
[21:41] <desrt> implementing the hash will be borderline trivial
[21:41] <tedg> Okay, trivial, one hour, go!
[21:41] <tedg> :-)
[21:42] <desrt> i doubt i'll need 15 minutes
[21:42] <desrt> brb :)
[21:42] <jbicha> dupondje: I've been on gnome-shell 3.3.90 the past week or so, so I haven't seen the bug at all for a while
[21:43] <dupondje> packaged version is still 3.2.2.1-0ubuntu1 atm
[21:43] <dupondje> :)
[21:44]  * jbicha points to the GNOME3 PPA :)
=== jalcine is now known as JackyAlcine
=== JackyAlcine is now known as jalcine
[21:56] <desrt> tedg: done :)
[21:56] <desrt> 14 minutes :p
[22:03]  * desrt is suddenly in the mood for a dconf release
[22:18] <seb128> desrt, did you merge propose your update?
[22:21] <desrt> seb128: which update?
[22:26] <seb128> desrt, the fix you just did for the hud?
[22:26] <desrt> seb128: i just pushed it directly
[22:26] <seb128> desrt, where?
[22:27] <desrt> to my branch
[22:27] <seb128> desrt, well, it should go to trunk
[22:27] <desrt> oh.
[22:27] <desrt> my branch got merged
[22:27] <seb128> desrt, tedg send an email saying toi not upload 0.3.92 he rolled waiting on the fix
[22:27] <desrt> how nice
[22:27] <desrt> i don't think i can push to trunk...
[22:28] <seb128> desrt, right, that's why I asked if you did a merge request
[22:28] <seb128> so we can get it in trunk
[22:28] <desrt> okay.  i understand now
[22:28] <seb128> so we can unblock the distro upload
[22:29] <seb128> desrt, thanks ;-
[22:29] <seb128> ;-)
[22:29] <desrt> https://code.launchpad.net/~desrt/indicator-appmenu/hud-rewrite-wip/+merge/96476
[22:29] <seb128> tedg, ^
[22:29] <desrt> i have to do a merge request for every change i make now?  this is gonna get old fast.... :p
[22:30] <seb128> desrt, well you can batch commits and do one merge request ;-)
[22:30] <seb128> desrt, or try to get access to trunk :p
[22:31] <seb128> desrt, well at some point I guess systems will use the same thing didrocks put in place for unity
[22:31] <seb128> desrt, i.e jenkins merging merges approved automatically after running tests and builds
[22:31] <seb128> that's quite nice
[22:32] <seb128> you get stuff build tested and make checked for you and merged if everything is ok ;-)
[22:32] <desrt> i like it
[22:32] <desrt> now i can blame the bot if something screws up
[22:35] <tedg> seb128, Okay, I'll circle back around and do another release, I need to go in a bit though.  Might be in the morning.
[22:35]  * desrt is not 100% that this solves the issue you were seeing
[22:36] <seb128> tedg, I might just upload the tarball you already rolled with that patch tomorrow
[22:36] <seb128> tedg, if you don't get a new one
[22:36] <seb128> tedg, I think the issues are not stoppers, we can fix them tomorrow with another tarball if needed
[22:37] <seb128> tedg, oh, it was not just the hightlight but also actions not working?
[22:37] <dobey> hrmm. does new gtk+ fix the scrolling issue?
[22:37] <seb128> tedg, so yeah, ignore that, let's wait to make that is fixed, tomorrow would be ok though
[22:37] <seb128> dobey, what new gtk? what scrolling issue?
[22:38] <dobey> whatever one i installed today when i did apt-get dist-upgrade
[22:38] <dobey> and my scroll wheel apparently not working any more
[22:38] <RAOF> kenvandine: I presume you're aware that gwibber no longer scrolls correctly?
[22:40] <dobey> RAOF: it would appear that evolution doesn't either. when i move my scroll whweel in evo, the message list scroll bar just jumps all the way to the bottom :(
[22:40] <seb128> dobey, do you use 32 bits?
[22:41] <RAOF> dobey: No, evolution works (on amd64); gwibber's broken in a different way.
[22:41] <RAOF> Actually, the new smooth-scroll evolution is pretty funky.
[22:41] <dobey> seb128: yes
[22:42] <dobey> RAOF: yeah, gwibber was broken before the new gtk for me, i think
[22:42] <seb128> dobey, known issue, cnd is working on it, it's an xserver,input bug
[22:42] <seb128> it's 32b specific
[22:43] <dobey> ok
[22:43] <seb128> dobey, cnd says he's about to upload the fix
[22:44] <dobey> cool. i'll dist-upgrade in a bit and see if it's there
[22:47] <desrt> seb128: did you resubmit the gconf build?
[22:49] <seb128> desrt, yes, https://launchpadlibrarian.net/95838197/gconf_3.2.3-3ubuntu1.2_3.2.3-3ubuntu1.3.diff.gz
[22:49] <seb128> https://launchpad.net/~ubuntu-desktop/+archive/ppa/+packages
[22:49] <seb128> starting in 2 hours though
[22:49] <seb128> builders are busy
[22:49] <desrt> seems to be
[22:50] <desrt> oh well.  no emergency.
[22:50] <seb128> dobey, https://launchpad.net/ubuntu/+source/libxi/2:1.5.99.3-0ubuntu2
[22:50] <seb128> ^ that should fix scroll on 32b
[22:53] <dobey> seb128: cool. i'll test it when it's published
[22:57] <seb128> desrt, help
[22:58] <desrt> hi.
[22:58] <seb128> desrt, git pull --rebase tells me
[22:58] <seb128> refusing to pull with rebase: your working tree is not up-to-date
[22:58] <seb128> I had a commit
[22:58] <desrt> seb128: you have non-checked-in changes
[22:58] <seb128> but trunk changed
[22:58] <seb128> I did commit
[22:58] <desrt> look at 'git status' or 'git diff'
[22:59] <desrt> perhaps not all of your changes got committed (no -a?)
[22:59] <seb128> desrt, ok, git --reset didn't do what I though it would do
[22:59] <seb128> desrt, I had to add "--hard"
[22:59] <seb128> desrt, thanks
[23:00] <seb128> desrt, I had a local change, I though --reset would drop it
[23:00] <seb128> but seems not
[23:01] <desrt> reset --hard for that, indeed
[23:01] <desrt> soft/mixed resets never affect your working tree
[23:02] <seb128> I though it would let me pull with uncommited changes
[23:02] <seb128> bzr let you do that
[23:02] <seb128> it's like "I"ve work in progress I didn't commit but I want to rebase before commiting"
[23:03] <desrt> that's 'git pull'
[23:03] <desrt> the trouble only comes when you have both committed *and* uncommited changes
[23:03] <seb128> I had both
[23:03] <seb128> I had a commit and a work in progress chang
[23:03] <jalcine> desrt: that's where stash comes into play.
[23:03] <desrt> yup.
[23:04] <desrt> git stash
[23:04] <desrt> git pull --rebase
[23:04] <desrt> git stash pop
[23:04] <seb128> urg
[23:04] <seb128> I think that's too much for a day :p
[23:04] <jalcine> best thing since sliced bread.
[23:04] <desrt> :)
[23:04] <seb128> for the record I just hate git :p
[23:04] <seb128> could a vcs be harder to use? ;-)
[23:04] <desrt> jalcine: would be nicer, i think, if attempting to rebase a dirty tree stashed automatically
[23:04] <desrt> seb128: hah.  i had my fair share of bzr annoyance today, thanks :p
[23:05] <desrt> bzr has logic that if i push somewhere and then push to a different place the first place must surely be the 'parent' of the first
[23:05] <desrt> so all future diffs are made against it, for example
[23:05] <seb128> desrt, like I read those commands but I'm unsure why I need to understand why there is pull and a pull --rebase
[23:05] <desrt> seb128: here's why:
[23:05] <seb128> can't they just have a pull fetching what is new and applying it ?
[23:05] <desrt> git pull is basically short for 'git fetch' plus 'git merge'
[23:06] <desrt> so a pull will result in a merge if there are both changes in your tree plus changes upstream at the same time
[23:06] <desrt> which is fine, but a lot of people like the history to look linear
[23:06] <desrt> that's where rebasing comes in -- it modifies history to make it look like your committed your changes on top of the work that appeared later
[23:07] <seb128> so any non pushed commit will be moved on top of what is pulled?
[23:08] <desrt> yes.
[23:08] <seb128> hum, k
[23:08] <seb128> I guess I don't care much about "order of commits"'
[23:08] <desrt> so then 'git pull' is probably always fine for you
[23:08] <desrt> but you may annoy others who care more :)
[23:08] <seb128> but I also get that some people might :-)
[23:08] <seb128> desrt, thanks
[23:08] <seb128> anyway got it sorted
[23:08] <desrt> in the general case git-rebase is insanely powerful
[23:08] <desrt> and this power causes problems with uncommited things in the tree
[23:09] <seb128> yeah, in this case I had a commit I did early that I failed to push without noticing
[23:09] <seb128> (trunk changes while I was doing the change)
[23:09] <seb128> and I did another change I didn't commit yet
[23:09] <seb128> then I noticed the push failed
[23:09] <desrt> for example, you can use rebasing to change the order of history entirely (like completely re-ordering the order of commits, splitting commits up or merging them, etc)
[23:09] <seb128> and I wanted to push that one commit to keep going on the next one
[23:09] <desrt> which could cause problems with this sort of uncommitted state that's assumed to be at the end
[23:10] <seb128> yeah, that's git weirdness to me, the "let's change history" thing ;-)
[23:10] <desrt> read the 'how and why to fake it' paper :)
[23:11] <seb128> desrt, my german side tells me changing history is wrong :p
[23:11] <seb128> things are the way they happened ;-)
[23:11] <desrt> seb128: welll.. there's history and there's public history
[23:11] <seb128> well no connotation to history fact, just to way things should be done ;-)
[23:11] <desrt> changing public history is widely considered to be a huge faux pas
[23:12] <desrt> and most projects have commit hooks that prevent it from happening
[23:12] <desrt> private history that's only on your laptop (or in your own work-in-progress branch) is another story
[23:12] <seb128> desrt, right, I was going to say that it feels like an easy way to corrupt an existing vcs
[23:12] <seb128> or to have somebody doing bad things
[23:13] <desrt> indeed
[23:13] <desrt> that's why git has commit IDs
[23:13] <desrt> they are cryptographic hashes of the entire project history up to this point
[23:13]  * jalcine just figured out where those hashes came from, lol.
[23:13] <seb128> interesting
[23:14] <desrt> if even one character in a commit message changes or a timestamp changes by 1 second, the entire commit ID changes
[23:14] <desrt> anywhere for all history
[23:14] <desrt> because part of what makes up the commit ID is the ID of the commit that came before
[23:14] <desrt> so you get the chaining effect....
[23:15] <seb128> I guess that makes easier to notice any issues ;-)
[23:15] <desrt> ya...
[23:15] <desrt> it's not even a security check, either
[23:15] <desrt> it's how git works at its very essence
[23:15] <desrt> each file is a 'blob' and the ID of the blob is its hash
[23:15] <desrt> all the files that make up a (sub)tree are reffered to by their hash value
[23:16] <desrt> and then the tree making up the commit is referred to from the commit
[23:16] <desrt> in order to find the object to unpack it it has to have the correct hash...
[23:16] <seb128> desrt, what's the english word for corruption close from "tempting"? I'm close I'm sure but it doesn't come back :p
[23:16] <desrt> tampering?
[23:16] <seb128> thanks!
[23:17] <seb128> desrt, I'm sure git makes a lot of sense if you understand how it's technically done ;-)
[23:18] <seb128> which you seem to do :p
[23:18] <desrt> seb128: i think the most important thing to understanding git is understanding what's really going on
[23:18] <desrt> the entire thing is a directed acyclic graph of these objects
[23:18] <seb128> I'm not sure I care enough about vcs to spend time looking at that though ;-)
[23:18] <desrt> you just have to understand each command as being some operation on that graph
[23:18] <desrt> and then it's all insanely logical
[23:18] <desrt> not sure most people care to think that way, of course....
[23:19] <desrt> but if you like to think that way then it's really the greatest possible system
[23:19] <seb128> right, most people probably just learn the command and what they do
[23:19] <seb128> like you don't think about what fs do when you type mv :p
[23:20] <desrt> speak for yourself ;)
[23:20] <desrt> i think what i like about git is that i can do absolutely any concievable operation on it
[23:20] <desrt> and for most of the ones that i want to do there are automated tools to do them for me
[23:20] <desrt> for the others, i can script it or do them manually
[23:21] <desrt> i only have to figure out what my desired operation is in terms of permutations on the graph
[23:21] <desrt> it's truly a hacker's tool :p
[23:23] <seb128> ;-)
[23:25] <jalcine> Created by the hacker of hackers, lol
[23:27] <mdeslaur> seb128: could you take a look at my proposal in bug 938076, and see if it's acceptable and/or too late?
[23:27] <ubot2`> Launchpad bug 938076 in gnome-settings-daemon "Auto-lock on suspend is still needed when encrypting file system" [Wishlist,Confirmed] https://launchpad.net/bugs/938076
[23:27] <seb128> mdeslaur, I was just reading the comments on that bug
[23:27] <mdeslaur> seb128: it never ends :)
[23:28] <seb128> indeed
[23:28] <desrt> who is benjamin kerensa?
[23:29] <desrt> nvm.
[23:29] <seb128> desrt, ?
[23:29] <seb128> mdeslaur, I Cced mpt on the bug
[23:29] <desrt> seb128: he marked one of my bugs as 'Opinion' :p
[23:30] <seb128> mdeslaur, the proposal works for me but I learnt since long that I'm not a designer :p
[23:30] <seb128> desrt, ;-)
[23:30]  * desrt marked it back to 'New' and feels like maybe he should explain
[23:32] <desrt> is there some way to do a grep of all bzr repos in launchpad?
[23:34] <seb128> desrt, like checkouts all repo to grep through, or do you look for a repo?
[23:34] <seb128> desrt, usually http://code.launchpad.net/<project> lists all the vcs for project
[23:35] <seb128> desrt, i.e https://code.launchpad.net/indicator-appmenu
[23:35] <desrt> seb128: i mean *everything* :p
[23:35]  * desrt wants to find out who is using this unity average-bg-color setting
[23:35] <seb128> desrt, oh, unity and notify-osd
[23:35] <seb128> desrt, unity-2d as well
[23:35] <seb128> that's all I'm 99% sure
[23:36] <seb128> it's new from a month or so
[23:36] <seb128> desrt, what they do is "unity write its color so notify-osd can read that value and use the same color without having to recompute the background medium value"
[23:37] <seb128> well and also "so unity doesn't need to do the maths again if the bg didn't change"
[23:37] <desrt> why would it have to do that?
[23:37] <desrt> for the 2d fallback?
[23:37] <seb128> desrt, "that"?
[23:37] <seb128> desrt, notify-osd is a standalone process
[23:37] <desrt> why does notify-osd need to know the median background colour?
[23:37] <seb128> desrt, because its color matches the background
[23:37] <desrt> oh
[23:37] <seb128> same as the dash
[23:37] <desrt> i thought it was black
[23:37] <seb128> it used to
[23:37] <seb128> that's a new feature
[23:37] <desrt> i see....
[23:38] <desrt> ya
[23:38] <desrt> this is definitely an X11 root window property
[23:38] <seb128> desrt, I suggested they did a dbus call for it but macslow prefered the "store in gsettings"
[23:38] <desrt> or should be, i mean
[23:38] <desrt> dbus call would also work, but is slower
[23:38] <desrt> although it's probably easier to write
[23:38] <seb128> yeah, I tend to not think about xproperties
[23:38] <desrt> x properties are not so much fun :p
[23:39] <seb128> it's not something "common" for some reason
[23:39] <seb128> or I didn't cross it enough to have it as a reflex ;-)
[23:39] <desrt> well
[23:39] <desrt> for something that's so closely related to the root window, it sort of fits...
[23:40] <seb128> desrt, https://code.launchpad.net/~macslow/notify-osd/fix.810325-2/+merge/92000
[23:41] <seb128> desrt, https://code.launchpad.net/~macslow/notify-osd/fix.810325/+merge/68537 was the original one where I suggested dbus
[23:41] <desrt> seb128: you did the right thing
[23:41] <desrt> you just gave up too easy :)
[23:41] <seb128> ;-)
[23:42] <desrt> you know... this really really needs to be an X property :p
[23:43]  * desrt is thinking about how the dbus approach would work and likes it only a little more than the gsettings way
[23:43] <seb128> desrt, write a patch, I'm sure they will consider it ;-)
[23:43] <desrt> ya.  i think i will
[23:44] <desrt> that will only leave didrocks left :)
[23:44] <seb128> desrt, my main complain with gsettings btw was your insane "abort on missing schemas" stuff :p
[23:44] <desrt> seb128: i designed gsettings using the git philosophy
[23:44] <seb128> desrt, that's making my life harder every time where I write a patch which used to be "do a gconf call"
[23:44] <desrt> "do everything you can to annoy frenchmen"
[23:44] <seb128> lol
[23:45] <seb128> desrt, you used to be able to get a key and deal with it being null
[23:45] <seb128> now you need to write a schemas
[23:45] <desrt> seb128: you are free to "do a dconf call" equivalently
[23:45] <seb128> which means you need a schemas somewhere even for "upstream_behaviour" hacks
[23:45] <desrt> you make the mistake of assuming that gsettings is something like gconf
[23:45] <desrt> it's not
[23:45] <desrt> dconf is the thing that's like gconf
[23:45] <seb128> desrt, like I wanted to add a setting to tweak the gsd xsettings for appmenu
[23:46] <desrt> ya... we're gonna need to figure out what to do there
[23:46] <seb128> but I stopped because I blocked on the stupid schemas and where to put it
[23:46] <desrt> well, i guess if we get the new gnome-shell into universe then it's a non-issue
[23:47] <desrt> what's the progress there looking like anyway?
[23:47] <seb128> desrt, ricotz said it should be easy to revert the new gcr requirement
[23:47] <seb128> that's the last thing I read about it
[23:47] <seb128> I assume jbicha is still looking at it
[23:47] <seb128> desrt, well it was not only g-s
[23:48] <desrt> non-working gmenumodel + unity?
[23:48] <seb128> desrt, it was also unity users who hate appmenus
[23:48] <desrt> ah
[23:48] <desrt> they can unintsall the appmenu indicator
[23:48] <seb128> desrt, that breaks the hud
[23:48] <desrt> why the fuck is hud-service in the same binary as libappmenu.so?
[23:49] <desrt> i mean... it's bad enough they're in the same source package
[23:49] <desrt> they should _definitely_ be in separate binaries
[23:49] <seb128> desrt, it's not in the archive
[23:49] <desrt> they actually have absolutely nothing to do with each other at all
[23:49] <seb128> so it's not in the same binary :p
[23:49] <seb128> but yeah, you have a point
[23:49] <seb128> desrt, ignore that
[23:49] <desrt> :)
[23:50] <seb128> your version is not in yet, but yeah...
[23:50] <desrt> hopefully it's not too late for a packaging tweak there
[23:50] <seb128> desrt, still I assume there is a case for people with different preferences on the same system
[23:50] <desrt> because people are going to want to be able to uninstall the appmenu indicator
[23:50] <desrt> ya. that's true.
[23:50] <desrt> there's something a bit more infuriating
[23:50] <seb128> desrt, well I was thinking a gsettings key would be a better solution than removing a binary
[23:50] <desrt> the hud will break anyway if you remove the appmenu indicator
[23:51] <desrt> because the registrar lives inside of it
[23:51] <desrt> so hud will work, but only for indicators and gmenumodel
[23:51] <seb128> desrt, changing the xsettings should give you local and unity menus at the same time no?
[23:51] <seb128> with hud still working?
[23:51] <desrt> yes.
[23:51] <seb128> desrt, which was my plan
[23:51] <seb128> was -> is
[23:52] <desrt> aim higher
[23:52] <desrt> we need a generic xsettings override interface
[23:52] <seb128> right
[23:52] <desrt> i'll make a patch for that
[23:52] <seb128> having a command line to set xsettings would be good for debugging as well
[23:52] <desrt> hum
[23:52] <seb128> I hate having to rebuild gsd to try xsettings :p
[23:52] <desrt> now you ask for more :)
[23:52] <seb128> desrt, you told me to aim higher!
[23:53] <desrt> so there are two usecases here
[23:53] <desrt> first is that you want to change the value of some settings using gsettings
[23:53] <desrt> the other is that you want to do temporary tweaks with dbus?
[23:53] <desrt> could it just be all gsettings? :)
[23:54] <seb128> well I guess I would be fine with the first one
[23:54] <seb128> in practice that's the most frequent one
[23:54] <desrt> so i'll just put an a{sv} in GSettings
[23:54] <desrt> a dictionary of the keys you want to change
[23:55] <desrt> i'll even add it to the schema :p
[23:56] <seb128> ;-)
[23:56] <seb128> desrt, anyway that will be for another day for me, time to go to bed!
[23:56] <seb128> 'night
[23:57] <desrt> good night :)