[00:05] <mspencer> When I'm in the dash and press Alt+F2, the dash goes away but the command lens doesn't come up. However, when I'm in the dash and press Alt, the HUD comes up. Is the dash going away a feature or a bug?
[00:06] <mspencer> This has been reported as LP #1019457, I just wanted to check that this a bug and not a feature before I work on fixing it.
[00:06] <ubot2> Launchpad bug 1019457 in unity (Ubuntu) "The Dash closes when trying to switch to the Command lens (Alt+F2)" [Low,In progress] https://launchpad.net/bugs/1019457
[00:45] <bschaefer> mspencer, it is a bug
[00:45] <bschaefer> if it wasn't a bug, super+a should close the dash, but it switches to the applications lens
[01:11] <TheMuso> p/c
[03:40] <robert_ancell> RAOF, do you know much about udev tagging?
[03:40] <robert_ancell> in particular around video devices
[04:15] <RAOF> robert_ancell: Not particularly; what are you after?
[04:15] <robert_ancell> RAOF, just trying to understand how display devices are tagged for multi-seat
[04:15] <robert_ancell> RAOF, and trying to browse the current tags on my devices
[04:19] <RAOF> I believe that's up to some special udev rules; I don't believe we allocate things to seats at the moment.
[04:21] <robert_ancell> RAOF, but where are the current tags stored?
[04:21] <robert_ancell> are there any tags by default?
[04:22] <RAOF> In the udev db? You can get at that with “mdadm info --export-db”
[04:22] <RAOF> As I understand it, all udev tags are added by udev rules; there's nothing built in.
[04:22] <robert_ancell> yeah, that's as I understand it too
[04:23] <robert_ancell> RAOF, "mdadm - manage MD devices aka Linux Software RAID" - is that right?
[04:24] <RAOF> Ahem. Sorry, *udevadm*
[04:24] <robert_ancell> ah, that's what I wanted. I was struggling to work out how to use udevadm
[04:26] <robert_ancell> RAOF, one last question - is there a standard way of telling what is a "video" device?
[04:28] <RAOF> Not as far as I know; you could probably check for the SUBSYSTEM=graphics, though.
[04:46] <pitti> Good morning
[04:47] <sarnold> pitti: isn't it still unreasonably early for you? :)
[04:49] <pitti> hehe
[04:55] <pitti> 16866 martin    20   0 1172m 439m  45m D 185,2 11,7   7:53.46 firefox
[04:55] <pitti> eek, firefox taking 2 CPUs without doing anything?
[06:04] <didrocks> good morning
[06:18] <pitti> bonjour didrocks!
[06:18] <pitti> err
[06:18] <pitti> bonjour didrocks !
[06:18] <didrocks> :-)
[06:18] <didrocks> guten morgen pitti!
[06:18]  * pitti still didn't get used to the weird French punctuation
[06:18] <didrocks> how are you?
[06:18] <pitti> mir gehts gut, danke!
[06:18] <didrocks> pitti: c'est facile, à chaque fois qu'il y a 2 éléments, comme ; : ! tu rajoutes une espace devant
[06:19] <didrocks> , n'a qu'un élement -> pas d'espace
[06:21] <pitti> like, you put a space in front of all punctuation except "." and "," or so?
[06:24] <didrocks> yeah, mostly
[06:25] <pitti> so, that's the part I need to get used to, as it looks weird in my eyes
[06:29] <didrocks> s/weird/the right way/ :-)
[06:29] <pitti> noooon!
[07:33] <chrisccoulson> good morning desktoppers
[07:33] <chrisccoulson> RAOF, you around?
[07:35] <pitti> hey chrisccoulson, how are you?
[07:35] <chrisccoulson> hi pitti. i'm not too bad thanks, how are you?
[07:36] <pitti> chrisccoulson: quite fine, thanks!
[07:36] <pitti> chrisccoulson: "not too bad" -> not ubuflu, I hope?
[07:36] <chrisccoulson> oh, no, i had that at the start of UDS ;)
[07:36] <chrisccoulson> just a bit tired
[08:18] <RAOF> chrisccoulson: Yo!
[08:35] <chrisccoulson> hi RAOF. did you say last week at UDS that you had a machine with ATI graphics (using the proprietary driver)?
[08:35] <didrocks> chrisccoulson: oh, small question, do you know if there is an option to disable the popup appearing when you press n to go to next unread message if there is none but in the next folder?
[08:36] <chrisccoulson> didrocks, i'm not sure about that. i don't think i've ever seen it because i never get my unread count to zero ;)
[08:36] <didrocks> chrisccoulson: heh :p ok, I'll dig in the options
[08:38] <larsu> good morning :)
[08:42] <didrocks> hey larsu! how are you?
[08:43] <larsu> didrocks, feel good from the gym :) And you?
[08:44] <didrocks> larsu: I'm fine, thanks! just finished the morning catching up (2h45), and now, can start really working :)
[08:44] <larsu> didrocks, dude, you get up too early :P
[08:45] <didrocks> larsu: won't beat pitti though :)
[08:45] <larsu> noone beats the pitti
[08:45] <pitti> hey larsu
[08:45] <larsu> good morning pitti, how are you?
[08:45] <pitti> well, you all beat me with staying longer in the evening :)
[08:45] <pitti> larsu: quite fine, thanks! almost lunch break :-D
[08:45] <larsu> lol
[08:45] <didrocks> pitti: heh, in some way :)
[08:45] <pitti> nah, I actually have breakfast around 8 or so, a civil time
[08:46] <pitti> can't eat at 6 yet
[08:46]  * didrocks dig and find https://code.launchpad.net/~didrocks/+junk/hudson-infrastructure.dx will be useful again!
[08:47] <didrocks> heh, same here. Getting my breakfast while reading blogs at 8:30
[08:48]  * duflu wonders if "breakfast" is another word for first pot of coffee
[08:48] <pitti> to me, it's "one pot of cereals"
[08:48] <didrocks> duflu: mostly, yeah ;)
[08:51] <chrisccoulson> ooh, i've not made any coffee yet
[09:00] <RAOF> chrisccoulson: I do, but it's currently in the process of getting a ubiquity bug filed from it because ubiquity doesn't see its windows partition.
[09:04] <xnox> RAOF: is that using raring or quantal? with or without windows recovery partitions? Full disk layout would be nice to have.
[09:05] <RAOF> xnox: I last did it with Quantal; I'll check with raring soon. What logs are you after?
[09:07] <Laney> desrt: sure. do you have a failure case there?
[09:07] <xnox> RAOF: no, don't use raring yet. I am after `ubuntu-bug ubiquity` which will pull in syslog, /var/log/partman & /var/log/installer/*
[09:08] <RAOF> xnox: Cool. Will do sometime in the next couple of days.
[09:10] <chrisccoulson> RAOF, when you get some time, could you please try a firefox nightly on it and tell me if you see https://bugzilla.mozilla.org/show_bug.cgi?id=798157 ?
[09:10] <ubot2> Mozilla bug 798157 in Widget: Gtk "awesome bar dropdown background color is missing and looks wrong" [Normal,New]
[09:52] <chrisccoulson> g'ah, PPA's all out of space again
[09:52] <seb128> chrisccoulson, hey, how are you?
[09:52] <chrisccoulson> hi seb128. i'm good thanks, and you?
[09:53] <seb128> good as well, thank you
[09:54] <dpm> hey all, good morning
[09:55] <dpm> are there any online accounts experts around? I'm getting this message upon login, and I'm not sure what to do: http://ubuntuone.com/7ErPvE13rCjoEdeigijaZC - basically, it opens up the old online accounts dialog when I click on "Open online accounts..."
[09:56] <seb128> dpm, hey, how are you?
[09:56] <seb128> dpm, seems like an evolution issue...
[09:57] <dpm> morning seb128, I'm good, thanks :) you?
[09:57] <seb128> dpm, good as well, thanks ;-)
[09:58] <dpm> any ideas on how to find out what it could be? I haven't got evo installed here, so I'm guessing it might be something to do with e-d-s?
[10:03] <seb128> dpm, yeah, the gnome-online-account stuff are in eds
[10:04] <seb128> dpm, try asking on irc.gimp.org #evolution?
[10:05] <dpm> gosh, I haven't been in that channel for years and years. This will bring back some memories ;)
[10:06] <seb128> ;-)
[10:23] <conscioususer> desrt: ping
[10:24] <larsu> conscioususer, desrt is probably not awake yet :)
[10:24] <conscioususer> larsu: that's fine, you are :P
[10:24] <larsu> true :)
[10:25] <conscioususer> larsu: had one more gapplication question, do you have some mins?
[10:25] <larsu> conscioususer, sure
[10:27] <conscioususer> larsu: according to what desrt said to me yesterday, I'm supposed to diassamble the command line and activate actions on the gtkapp as appropriate
[10:28] <conscioususer> larsu: Example 19 in developer.gnome.org/gio/unstable/GApplication.html seems to do that, but looks a little weird
[10:29] <conscioususer> larsu: it seems to assume I only want to consider command-line parameters if the app is already running, which is not always the case
[10:30] <larsu> conscioususer, right, that example is indeed a bit strange
[10:31] <conscioususer> larsu: what should I do if want a parameter to be considered also when the app starts?
[10:32] <larsu> conscioususer, exactly the same thing, but only exit the process when g_application_register returns false (which means that there's already  an instance running)
[10:33] <larsu> you need to set up your actions before that, though :)
[10:33] <larsu> but activating actions works the same in the local process as it does over the bus
[10:34] <conscioususer> larsu: but that means I'll be calling register() regardless of circumstances, right?
[10:34] <conscioususer> larsu: this feels a little redundant, as run() starts by calling register()
[10:35] <conscioususer> larsu: no errors happen, but still it feels a little dirty :P
[10:38] <larsu> conscioususer, I agree. And now I'm trying to think of a reason why you need to call register at all :)
[10:38] <larsu> oh, you need a bus connection to the main instance before you can activate actions
[10:39] <conscioususer> larsu: yeah, I learned this through an error message :)
[10:39] <larsu> heh
[10:41] <conscioususer> larsu: well, register *does* seem to be prepared for being called multiple times...
[10:41] <larsu> conscioususer, yeah, but you need to call it at least once before you can find out if you're a launcher or the primary instance
[10:42] <conscioususer> larsu: yes
[10:43] <conscioususer> larsu: I'm remembering now, I think that's how I ended up using activate instead of run
[10:44] <conscioususer> larsu: I thought calling run was redundant wrt to register
[10:45] <conscioususer> larsu: but only calling activate does not make the main loop start running, so I put Gtk.main in there... yeah, that's how the snowball grew
[10:45] <larsu> conscioususer, ah, makes sense :)
[10:45] <conscioususer> larsu: so I guess calling run even if you already called register is the right way
[10:45] <larsu> conscioususer, GApplication really does too much, it should have been two classes really
[10:45] <larsu> conscioususer, yep, that's what I'd advise you to do
[10:46] <conscioususer> larsu: right, so I will :)
[10:48] <conscioususer> larsu: thanks! ready to go back to coding :)
[10:48] <larsu> conscioususer, another - maybe a slightly cleaner - route would be to subclass GtkApplication and override local_command_line, which gives you total control over registration and startup / activate
[10:49] <larsu> (but then you *have to* call startup and activate yourself)
[10:50] <conscioususer> larsu: ah yes, this seems possible
[10:51]  * larsu hopes not to confuse conscioususer too much after finding a solution :)
[10:52] <conscioususer> larsu: in fact, this *does* seem to make sense rather than feeling like a workaround... the docs say to override local_command_line if you intend to handle the command line locally... which is exactly what I'm trying to do here
[10:52] <conscioususer> larsu: um, sorta
[10:52] <larsu> conscioususer, yeah, I got the idea when reading that piece of the docs :)
[10:53] <larsu> conscioususer, don't know how easy it is to subclass gobjects in python
[10:53] <larsu> but you're the expert there I guess ;)
[10:53] <conscioususer> larsu: straightforward, actually
[10:54] <conscioususer> larsu: unless it's different for this case somehow, I'll only need to add a method called do_local_command_line in my class
[10:54] <conscioususer> larsu: hopefully it's not different
[10:55] <larsu> conscioususer, should be the same as for all gobject classes ... introspection ftw!
[11:01] <conscioususer> larsu: the overriding works as expected, but I'm getting some weird decoding errors
[11:01] <didrocks> hey pitti, can you pump my build score? ;) I need it to make some experiment (not the i386 yet, I'm interested in the "in between state"): https://launchpad.net/~didrocks/+archive/ppa/+build/3966038
[11:02] <larsu> conscioususer, decoding of what?
[11:02] <conscioususer> larsu: good question :P
[11:02] <larsu> haha
[11:02] <conscioususer> larsu: will paste a minimal example, hold on
[11:03] <larsu> thanks
[11:06] <conscioususer> larsu: http://www.pasteshare.co.uk/p/3tx/
[11:07] <larsu> conscioususer, TypeError: super() takes at least 1 argument (0 given)
[11:07] <conscioususer> try python 3 :)
[11:08] <larsu> conscioususer, oh! thanks
[11:08]  * larsu is a python-newb
[11:09] <conscioususer> larsu: I forgot a "return True" at the end of do_local_command_line
[11:09] <conscioususer> larsu: but the error happens anyway
[11:11] <conscioususer> larsu: I suspect this is not properly introspected
[11:12] <larsu> conscioususer, good thing we have pitti in this channel :)
[11:12] <larsu> pitti, know anything about unicode decode errors when trying to subclass GtkApplication from python3?
[11:12] <larsu> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe0 in position 0: invalid continuation byte
[11:13] <larsu> but I get all kinds of different unicode errors, not only this one
[11:15] <conscioususer> larsu: in the C api, the first argument receives a char ***arguments and an int *exit_status... the fact that the introspected version seems to also expect two parameters instead of moving exit_status to a return value should raise a red flag
[11:16] <pitti> didrocks: bumped
[11:16] <larsu> conscioususer, yes, but there's already a return value - or does pygi return multiple values in these cases?
[11:17] <didrocks> pitti: thanks a lot! :)
[11:17] <pitti> larsu: no, I haven't heard about UnicodeDecodeErrors in that case
[11:17] <conscioususer> larsu: it does return multiple values
[11:17] <larsu> pitti, problem happens only when overriding GApplicationClass::local_command_line, which takes a gchar ***, maybe pygi can't cope with that?
[11:17] <pitti> chrisccoulson: yes, presumably missing (out) annotation
[11:18] <pitti> ***arguments is probably (inout)
[11:18] <larsu> ah, let me check
[11:18] <pitti> yeah, that doesn't look healthy
[11:18] <pitti>           <parameter name="arguments" transfer-ownership="none">
[11:18] <pitti>             <type name="utf8" c:type="gchar***"/>
[11:18] <pitti>           </parameter>
[11:18] <pitti> this is bogus
[11:18] <larsu> yep
[11:19] <larsu> conscioususer, man, your stumbling on bugs everywhere!
[11:19] <pitti> is this inout, or out?
[11:19] <larsu> pitti, inout
[11:20] <pitti> so it probably needs something like (inout) (array zero-terminated=1) (element-type=utf8)
[11:21] <conscioususer> larsu: the price I'm paying for trying the latest stuff, I guess :P
[11:21] <pitti> so if you want to file a bug about that on bugzilla.gnome.org, please subscribe me
[11:22] <larsu> pitti, hm, all annotations seem to be missing for GApplication vfuncs
[11:22] <larsu> pitti, I'll subscribe you, thanks!
[11:22] <pitti> yeah, you might be the first to try through GI :(
[11:23] <larsu> well, someone has to start
[11:23] <larsu> ;)
[11:23] <conscioususer> so I'm supposing this goes too deep to allow a workaround?
[11:23] <conscioususer> guess i'll go back to using register(), then run()
[11:24] <pitti> there is no workaround, except for not using the API at all
[11:25] <larsu> conscioususer, yep :( we need to fix the annotations in gio
[11:25] <pitti> but annotation fixes are backportable to stables, and GNOME 3.6.2 is due next week
[11:25] <larsu> really? Awesome
[11:25] <pitti> I already fixed a bunch recently which I'm looking forward to getting released
[11:25] <conscioususer> awesome
[11:25] <conscioususer> indeed
[11:26] <conscioususer> pitti: btw, can you confirm me one thing? is GLib.threads_init still needed in PyGI apps?
[11:26] <pitti> conscioususer: yes, for pygobject/python
[11:26] <pitti> glib itself doesn't need it any more
[11:26] <pitti> https://bugzilla.gnome.org/show_bug.cgi?id=686914
[11:26] <ubot2> Gnome bug 686914 in gobject "pygobject still requires GObject.threads_init()" [Minor,Unconfirmed]
[11:27] <pitti> if someone has a bright idea how to detect/call it automatically, I'm all ears
[11:27] <conscioususer> pitti: yeah, that's why I asked... I read in the docs g_thread_init was deprecated, but then got errors when I removed from my PyGI code
[11:28] <conscioususer> pitti: nice to have an official confirmation :)
[11:31] <larsu> conscioususer, https://bugzilla.gnome.org/show_bug.cgi?id=687912
[11:31] <ubot2> Gnome bug 687912 in gapplication "GApplication vfuncs are missing introspection annotations" [Normal,Unconfirmed]
[11:31] <larsu> pitti, ^^ (I've already subscribed you)
[11:32] <pitti> thanks
[11:32] <conscioususer> nice :)
[11:46] <xnox> what's the progress on shipping only gtk2 on the cd?
[11:46] <xnox> libreoffice & nm the biggest culprits?
[11:46] <ogra_> do you mean gtk3 ?
[11:47] <xnox> ogra_: yeah =)
[11:47] <ogra_> :)
[11:47] <xnox> what's the progress on shipping only _gtk3_ on the cd?
[11:52] <didrocks> pitti: ok, I got the information I needed, can you bump the score on https://launchpad.net/~didrocks/+archive/ppa/+build/3966040 now please?
[11:52] <pitti> didrocks: fini
[11:56] <didrocks> pitti: merci :)
[12:42] <desrt> Laney: ya.  webkit builds.
[12:45] <Laney> desrt: ah, yeah, same case then. are you trying to build 1.10 on precise or do you now see it with 1.8?
[12:45] <Laney> if you have the error to hand a bug with it in would be appreciated
[12:46] <desrt> 1.11.1
[12:46] <Laney> k
[12:46] <desrt> it's the same "argument list too long" message when trying to link
[12:46] <Laney> yeah I just don't have it
[12:47] <Laney> would be useful for the SRU paperwork
[12:47] <Laney> never mind, can acquire it
[12:49] <desrt> fwiw, i just installed the quantal 'make' package on my precise system and everything is good now
[12:49] <Sweetsha1k> seb128: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1017125/comments/50 <- boost patch available, can you take that up?
[12:49] <ubot2> Launchpad bug 1017125 in boost1.49 (Ubuntu) "boost::unordered_multimap<>::erase(iterator, iterator) broken on quantal" [High,Confirmed]
[12:50] <seb128> Sweetsha1k, I can, what about pinging doko just to have somebody who has a clue about that stack to comment?
[12:50] <Sweetsha1k> seb128: doko is subscribed to the bug ... but prolly drowning in blueprints/UDS-postprocessing.
[12:51] <seb128> Sweetshark, try IRC ping on #ubuntu-devel?
[12:52] <Sweetshark> seb128: just did on #distro
[12:52] <seb128> Sweetshark, danke
[12:52] <Sweetshark> seb128: de rien ;)
[13:04] <jbicha> seb128: could you sync clutter-gtk from experimental?
[13:05] <seb128> jbicha, sure, clutter-gtk is not in the desktop set? we should probably get it there
[13:09] <jbicha> seb128: neither is cogl, clutter-1.0, or clutter-gst; they were in precise though
[13:10] <jbicha> and if we're going to add stuff: indicator-session, system-config-printer, yelp-tools, yelp-xsl
[13:21] <seb128> hum
[13:21] <seb128> jbicha, not sure about indicator-session, the unity set is different from the desktop one
[13:21] <seb128> but the other ones should be in the desktop set
[13:21] <seb128> it's annoying that we don't have a good way to deal with sets
[13:21] <seb128> out of "ping Laney or cjwatson"
[13:21] <Laney> not me, colin runs that script
[13:22] <Laney> the auto sets are pretty opaque to me I'm afraid :(
[13:22] <pitti> desrt: oh, seems your WI to add gcov support to g-common is retroactively done :) http://git.gnome.org/browse/gnome-common/commit/?id=493d55921
[13:22] <desrt> free workitem checkoff!
[13:22] <seb128> jbicha, can you ping cjwatson about those?
[13:23] <Laney> I was told last time that email is preferred for this
[13:23] <jbicha> you mean the other indicators shouldn't be in the desktop set?
[13:23] <desrt> pitti: btw: i've seen absolutely zero fallout from the new interface restrictions
[13:24] <pitti> desrt: great to hear
[13:24] <desrt> looks like pygobject was really the only one....
[13:24] <seb128> jbicha, they are? so yeah feel free to ask for indicator-session ... there were talks,dholbach suggested that we should do an indicators set so ted,lars,charles, etc could have upload rights for those
[13:24] <seb128> jbicha, we don't want to get them uploads to the full desktop though
[13:24] <pitti> desrt: that was the bit which allows you to drop half of the gtype.c code?
[13:24] <desrt> pitti: a good chunk of it
[13:25] <seb128> jbicha, so we might get indicators off in their own set some day
[13:25] <pitti> desrt: great
[13:25] <desrt> pitti: there is this bizarre state machine in gtype.c to track "how initialised" an object is
[13:25] <desrt> in order that we can know what we need to do when adding an interface to it past a certain point
[13:25] <desrt> we can drop that now
[13:25] <pitti> desrt: hehe -- if (get_initialization() >= 0.63482) { ... } ?
[13:25] <desrt> which gets us one step closer to my final goal: dropping the recursive mutex
[13:26] <desrt> pitti: http://git.gnome.org/browse/glib/tree/gobject/gtype.c#n207
[13:26] <desrt> there is a lot of bookkeeping required to handle that enum in a threadsafe way
[13:27] <desrt> particularly since you can't take the "just hold a big lock" approach when calling back into user callbacks (like class_init)
[13:28] <desrt> eventually the initstate and refcount will be replaced with a single "is initialised" boolean
[13:33] <ricotz> pitti, desrt, hi, will the current stable pygobject branch (and quantal) get patch to work with this interface restriction?
[13:34] <pitti> ricotz: no
[13:34] <pitti> this is not really an easy patch
[13:34] <ricotz> pitti, ok
[13:34] <pitti> ricotz: well, at least not right now; I'd like to see it out in the wild for some time
[13:34] <desrt> pitti: it looked easy to me
[13:34] <desrt> :)
[13:34] <jbicha> seb128: I'm going to merge mutter from Debian; they bumped the library name so I'll have to rebuild gnome-shell again
[13:34] <pitti> well, not the kind of easy I'd lightheartedly throw into a stable branch
[13:35] <desrt> but ya... a bit premature for an SRU until we know for sure that we have no new issues
[13:35] <pitti> 706 tests is one thing; beasts like software-center or sugar are another story..
[13:35] <seb128> jbicha, ok, can you do both today? that's the remaining bits for cogl it seems
[13:35] <pitti> we've been bitten by too many corner cases
[13:35] <ricotz> pitti, alright, i will need to do some patching then, i guess
[13:35] <desrt> crikey
[13:35] <desrt> my jhbuild statusboard this morning is a sea of green!
[13:35] <pitti> ricotz: why?
[13:35] <desrt> ....until you scroll down
[13:36] <ricotz> pitti, for the (crazy) git snapshots ;)
[13:36] <pitti> ricotz: I'll land the new pygobject in raring as soon as we'll get the new glib
[13:36] <pitti> ricotz: but glib+pygobject master branches also work well
[13:36] <seb128> pitti, that's likely to be a while ... is that an issue?
[13:36] <ricotz> pitti, yeah, i am uploading to the quantal ppa pocket too
[13:37] <pitti> seb128: not for me; I'm trying to keep pygobject 3.7.x working on glib 2.34
[13:37] <larsu> desrt, using gactionmap from vala is a bit of a pain - vala reports errors for interface methods that aren't implemented (query vs get_*)
[13:37] <seb128> pitti, ok
[13:37]  * desrt notes that it might be interesting to try to vendorpatch the class init thing into the old raring package just to get the increased exposure, without waiting for glib
[13:37] <pitti> ricotz: so you want to put a new glib there, but not a new pygobject?
[13:37] <desrt> larsu: query/get are not gactionmap methods
[13:37] <desrt> larsu: i guess you mean gactiongroup, though?
[13:37] <pitti> desrt: well, glib 2.34.2 will get out next week; I think that's good enough
[13:37] <larsu> desrt, sorry, gactiongroup
[13:37] <desrt> pitti: seb won't take it
[13:37] <ricotz> pitti, currently i reverted the "interface" patch, and yeah, i want to avoid putting more packages in there
[13:37] <pitti> desrt: I just need the fixed annotations
[13:38] <desrt> larsu: ya..... i did _query because _get_* was a pain
[13:38] <desrt> larsu: oops for vala users, i guess
[13:38] <larsu> desrt, I'm just ranting anyway, feel free to ignore ;)
[13:38] <pitti> desrt: why wouldn't we take 2.34.2?
[13:38] <desrt> pitti: seb wants to wait until after i'm back from vacation
[13:38] <pitti> desrt: I thought that was for 2.35
[13:38] <desrt> oh.  right.
[13:38] <desrt> sorry.
[13:38] <pitti> *phew* :)
[13:39]  * desrt wonders why you care
[13:39] <desrt> did you backport the poll boxing?
[13:39] <ricotz> pitti, or new pygobject is backwards compat with the quantal builds, which would be nice
[13:39] <pitti> desrt: no, for the fixed annotations in GIOChannel and the like
[13:39] <desrt> ah
[13:40] <pitti> desrt: pygobject 3.7.x doesn't work with glib <= 2.34.2 any more
[13:40] <pitti> err, <= 2.34.1
[13:40] <desrt> progress!
[13:40] <pitti> I threw out two metric tons of static bindings
[13:40] <pitti> and fixed glib instead
[13:40] <desrt> i'm a bit confused by how all of that works
[13:40] <desrt> because we don't have go-i in glib
[13:40] <desrt> is it the case that we have to fix glib, install it, run go-i against that, and then pygobject is happy?
[13:40] <pitti> desrt: well, annotaitons in glib -> g-i reads them from glib -> new 1.34.2 g-i release -> profit!
[13:41] <pitti> desrt: x-actly
[13:41] <desrt> clear as mud
[13:41] <ricotz> hehe
[13:41] <pitti> a pain to update/test, but yay circular build depends otherwise
[13:41] <ricotz> glib should build the introspection itself
[13:41] <pitti> ricotz: but how?
[13:42] <pitti> well, g-i could be merged into glib
[13:42] <desrt> a year or so from now i'm looking forward to a very very nasty argument with colin on the topic of merging g-i
[13:42] <ricotz> just consume the g-i into it
[13:42] <pitti> but with two separate projects that wouldn't work
[13:42] <ricotz> ;)
[13:42] <desrt> he already tried to introduce the circular build-depend once
[13:43] <desrt> it's one of those situations in which we have a suboptimal status quo but nobody is sure about the proper way forward
[13:43]  * ricotz meant to merge the whole g-i source in glib
[13:43] <desrt> doesn't help that i keep hearing talk about incompatible changes to the file format
[13:43] <desrt> ricotz: ya.  me too.
[13:43] <desrt> i bet that comes up in a year or so
[13:44] <ricotz> seems just logical
[13:44] <ricotz> to happen
[13:45] <pitti> $ make check-code-coverage
[13:45] <pitti> make: *** No rule to make target `check-code-coverage'.  Stop.
[13:45] <pitti> ok, not quite as easy as gnome-common makes me believe
[13:45] <pitti> oh, @GNOME_CODE_COVERAGE_RULES@
[13:46] <desrt> me loves those macros
[13:46] <desrt> "@GSETTIGS_RULES@"
[13:46] <desrt> "yes... i'm rather fond of it myself... but no need to yell..."
[13:47] <pitti> wow
[13:47] <pitti> file:///home/martin/upstream/pygobject/pygobject-3.7.2-coverage/index.html
[13:47] <pitti> ♩ it's a kind of maaa-giiiic! ♪ ♫
[13:48] <desrt> pitti: the part that it prints out that URL has always seemed to me like it should have a *ding!* sound
[13:49] <pitti> desrt: or a moan or a cheer depending on the percentage
[13:49]  * pitti wonders if that is really working for python -- how can my tests have just 72% coverage?
[13:49] <pitti> (I mean coverage for the _test_ code, not the tested code)
[13:49] <desrt> hahahaha
[13:50] <pitti> ah, it's only testing the .c files even
[13:51] <pitti> but anyway, c'est bon; je l'aime!
[14:12] <mspencer> When I'm in the dash and press Alt+F2, the dash goes away but the command lens doesn't come up. However, when I'm in the dash and press Alt, the HUD comes up. Is the dash going away correct or is it a bug?
[14:12] <mspencer> This has been reported as LP #1019457, I just wanted to check that this is incorrect and not supposed to work this way before I work on fixing it.
[14:12] <ubot2> Launchpad bug 1019457 in unity (Ubuntu) "The Dash closes when trying to switch to the Command lens (Alt+F2)" [Low,In progress] https://launchpad.net/bugs/1019457
[14:48] <jbicha> seb128: can you accept mutter? and then I need to push gnome-shell one more time
[14:50] <Laney> bah, PPA wait time is quite annoying lately
[14:51] <chrisccoulson> Laney, PPA's running out of space is even more annoying ;)
[14:51] <Laney> I suppose that happens after you've already waited several hours for a build
[14:51] <Laney> so yeah ...
[14:51] <dobey> jbicha: what is the difference between the -gnome .desktop file you're proposing to add to ubuntuone-control-panel, and the one that's already there, exactly? Only difference I see is that one has OnlyShowIn=GNOME, and you added NotShowIn=GNOME to the existing one; other than that, they appear to be exactly the same
[14:53] <seb128> jbicha, done
[14:56] <jbicha> dobey: oops, I pushed an update so it does the right thing now
[14:59] <dobey> jbicha: can you perhaps also rename the new file to ubuntuone-control-panel-qt-gnome.desktop.in? There's no need for it to be called "ubuntuone-installer" really; the existing file is only that way to avoid breaking existing config with unity and such.
[15:03] <jbicha> attente: are you running quantal or raring?
[15:03] <attente> jbicha: quantal
[15:05] <jbicha> ok, at some point, we're going to need the universal access/disable scrollbar patch redone for gnome-control-center 3.6 since GNOME has overhauled the Universal Access panel
[15:06] <attente> sure
[15:07] <jbicha> but you'd need gnome-settings-daemon 3.6 and probably ibus 1.4.99 to build g-c-c 3.6; you can find those in https://launchpad.net/~ubuntu-desktop/+archive/ppa
[15:08] <jbicha> GNOME's dropped all but one HighContrast theme
[15:09] <seb128> jbicha, well that patch is trivial
[15:09] <seb128> jbicha, it's just setting a gsettings key when setting an a11y theme
[15:11] <jbicha> seb128: oh ok
[16:15] <desrt> pitti: hey
[16:15] <desrt> pitti: pygobject-python2 has a depend on really really new autoconf
[16:15] <desrt> like, one that's not even in precise
[16:17] <desrt> pitti: it also appears to depend on lcov with the default arguments to ./configure now...
[16:18] <desrt> pitti: dropping the autoconf version dependency from .69 to .68 doesn't appear to break anything here
[16:40] <Laney> i wish webkit supported parallel building :(
[16:41] <chrisccoulson> it doesn't support that?
[16:41] <chrisccoulson> man, that sucks!
[16:48] <Laney> :-)
[19:42] <Sweetshark> seb128: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1064962/comments/100 <- meh
[19:42] <ubot2> Launchpad bug 1064962 in indicator-appmenu (Ubuntu Quantal) "[SRU] Global menubar items do not work when opening a document directly from nautilus with no LibreOffice instance running" [High,Confirmed]
[20:47] <desrt> jbicha: i think that g-c-c a11y scrollbar patch should drop
[20:47] <desrt> i talked about it with Cimi
[20:47] <desrt> the correct place for that highcontrast logic is in overlay scrollbars themselves
[20:58] <jbicha> desrt: ok
[21:58] <xnox-n7> hmm I am running raring and I cannot login into neither unity 3d nor into gnome-fallback sessions....
[21:58] <xnox-n7> anybody knows what's up?
[22:06] <stgraber> xnox-n7: usual suspects, look for the permissions of ~/.Xauthority and if they look fine, then look at ~/.xsession_errors
[22:06] <stgraber> (I had Xauthority change ownership a few times on my systems, never tracked the source but it gives you something matching your symptoms)
[22:07] <xnox-n7> stgraber: well currently the permissions are 600 & errors has "can't register GNU Pth with Libgcrypt"
[22:08] <xnox-n7> nothing spectacular =/
[22:08] <xnox-n7> lightdm cycles back to itself upon login =(
[22:11] <xnox-n7> created a fresh account getting loads of errors from compiz
[22:12] <stgraber> xnox-n7: your description seems to match http://ubuntuforums.org/showthread.php?p=12344405 but I wouldn't recommend using that fix ;)
[22:13] <xnox-n7> lol =)
[22:13] <xnox-n7> cd
[22:13] <xnox-n7> wrong window
[22:20] <xnox-n7> i smell kernel regress. since my dual-screen monitors are not detected, opengl fails to load....
[22:25] <stgraber> xnox-n7: well, raring's kernel is still quantal's isn't it?
[22:26] <stgraber> at least it's on my machine, last updated this morning
[22:26] <xnox-n7> stgraber: yeah... I am now pointing fingers at cogl
[22:27] <stgraber> xnox-n7: when trying the fallback session, did you choose Gnome Classic or Gnome Fallback? the former will still use compiz so could fail because of some opengl weirdness
[22:27] <xnox-n7> stgraber: do you see any SRUs about unity/deps that are not in raring?
[22:27] <xnox-n7> stgraber: i've tried both with & without effects. as they are known from the lightdm selection menu
[22:28] <stgraber> the report was clean yesterday, slangasek copied everything that was missing
[22:28]  * xnox-n7 is trying proposed =)
[22:28] <stgraber> cogl seems to still be stuck in -proposed so that can't be it
[22:29] <xnox-n7> *sigh* so much for stable all the time.
[22:29] <stgraber> I just applied the updates on my laptop and am not seeing anything that looks dangerous... so pretty unsure what broke your machine...
[22:30] <xnox-n7> I rebooted
[22:30] <stgraber> did you try a good old "startx"? it might get you more information on what's failing at session open time
[22:30] <xnox-n7> it was fine until that.
[22:33] <xnox-n7> Loading extension GLX'n xinit: connection to X server lost
[22:33] <xnox-n7> s/'n/\n/
[22:34] <xnox-n7> GLX error: Can not get required symbols
[22:34] <stgraber> oh, fun. Are you using intel or some weird binary drivers?
[22:40] <xnox-n7> intel / sandybridge
[22:42] <stgraber> could be some permission problem with /dev/dri/card0
[22:43] <xnox-n7> interesting let me try that
[22:43] <TheMuso> But symbols to me at least means ABI breakage...
[22:44] <xnox-n7> i hate sandybridge
[22:54] <xnox-n7> bug 1076787
[22:54] <ubot2> Launchpad bug 1076787 in xorg (Ubuntu) "GLX error: Can not get required symbols" [Undecided,New] https://launchpad.net/bugs/1076787
[22:54]  * xnox-n7 will have a cup of tea and go to sleep
[23:05] <xnox-n7> i guess I have some progress as I can login into no-effects session with a new user account.
[23:05] <xnox-n7> but not with my normal one
[23:05] <xnox-n7> so permissions?!
[23:05] <xnox-n7> *sigh*
[23:07] <Sarvatt> xnox-n7: sudo apt-get purge fglrx
[23:09] <xnox-n7> stgraber: moving .gnupg out the way solved it.....
[23:09] <xnox-n7> wtf!
[23:18] <xnox-n7> use-agent option in gpg.conf
[23:18] <xnox-n7> brakes my session.
[23:18] <TheMuso> Awesome.
[23:19] <xnox-n7> Awesome, sure. but *why* ?
[23:21] <TheMuso> Oh I don't know, I just have a tendency to use sarcasm when such things occur. :)
[23:23] <xnox> TheMuso: yeah.....
[23:23] <xnox> =))))
[23:23] <xnox> thanks stgraber & TheMuso for moral support and finding the solution
[23:23] <Sarvatt> xnox: wonder how long your session has been busted regardless because you have fglrx install making it so you can't use accelerated 3D on that intel :P
[23:26] <xnox> hmmm... let me purge that and check if I get 3D accel back =))))
[23:26] <xnox> Sarvatt: oh.... I caused that!
[23:27]  * xnox needs to upload a revert, I think....
[23:27] <xnox> to pyopencl
[23:28] <xnox> Sarvatt: so what should pyopencl depend on?
[23:29] <Sarvatt> sounds like fglrx needs to be split up so you don't switch to fglrx libGL instead of mesa's installing that but I'm not sure what's going on there
[23:34] <xnox> Sarvatt: purged & rebooted I have 3D acceleration again!
[23:37]  * xnox it's times like this when I want to start smoking again....