[06:51] <pitti> Good morning
[06:51] <pitti> Ampelbein: seems someone gave it back, g-keyring should be fine now
[06:51] <pitti> hey jasoncwarner_, happy new year!
[06:52] <jasoncwarner_> hey pitti you as well!
[06:57] <BigWhale> Good Morning.
[06:59] <didrocks> good morning
[06:59] <BigWhale> after ~4 hours of sleep I can't really call it good .. :>
[07:00] <didrocks> :/
[07:00] <BigWhale> that's why I get for staying up late and hacking ...
[07:00] <BigWhale> :>
[07:02] <pitti> bonjour didrocks
[07:05] <didrocks> guten morgen pitti. How are you?
[07:06] <pitti> didrocks: cold in full progress. :/
[07:06] <didrocks> pitti: urgh, take it easy today then!
[07:50] <rickspencer3> didrocks, bonjour
[07:51] <didrocks> bonjour rickspencer3, comment vas-tu?
[07:51] <rickspencer3> ça va bien, et tois?
[07:52] <rickspencer3> en fait, j'ai commencé mon script pour «unity_stress»
[07:53] <rickspencer3> didrocks, so far, the script changes workspaces every .5 seconds n times
[07:53] <rickspencer3> didrocks, what else should I make it do?
[07:54] <didrocks> rickspencer3: trigger expose for applications with multiple windows
[07:54] <rickspencer3> didrocks, that sounds hard ;)
[07:54] <rickspencer3> I'll give it a try though
[07:54] <rickspencer3> like, open a bunch of gedit windows and trigger exposé?
[07:55] <didrocks> rickspencer3: yeah, and then close expose, and trigger it again. You have a keyboard shortcut in ccsm for that, so rather, using that shortcut I woul say
[07:56] <didrocks> would
[07:56] <rickspencer3> ok, I'll look into it
[07:56] <rickspencer3> obviously minimizing windows as well ;)
[07:57] <didrocks> yeah, minimzing/restoring/maximizing
[07:57] <didrocks> we can as well use my little soft for quicklist/progress bars
[08:03] <rickspencer3> hey desktoppers, who in Ubuntu One do I assign bugs to? is there a team?
[08:08] <pitti> rickspencer3: ~ubuntuone-hackers AFAIK
[08:08] <rickspencer3> thanks pitti
[08:33] <smspillaz> rickspencer3: how are you writing this script btw ?
[08:33] <smspillaz> rickspencer3: compiz can expose certain functionality over dbus, might make it easier for you to automate these things
[08:34] <smspillaz> (user driven things, like, initiating expo, scale, etc etc etc)
[08:40] <rickspencer3> hi smspillaz it's a bash script, if that helps
[08:47] <rickspencer3> didrocks, looks like there is a compiz update in the desktop PPA
[08:47] <rickspencer3> should I take it?
[08:47] <rickspencer3> (for Oneiric)
[08:50] <didrocks> rickspencer3: seb128 did it on december, he told me that he didn't see any isssue so far
[08:50] <rickspencer3> ok
[08:50] <didrocks> rickspencer3: so yeah, please, take it and pull the trigger if things go badly :)
[08:50]  * rickspencer3 clicks Install Updates
[08:51]  * didrocks crosses fingers :)
[08:54] <rickspencer3> didrocks, what command in ccsm do I need to use to activate spread by keyboard?
[08:54] <didrocks> rickspencer3: uno momento! :)
[08:54] <rickspencer3> en espanol?
[08:55] <didrocks> rickspencer3: mon espagnole est pire que mon allemand, tu ne veux pas tester :)
[08:56] <rickspencer3> didrocks windows-z spreads everything
[08:56] <rickspencer3> is that good enough?
[08:56] <rickspencer3> or do you need to one app only spread?
[08:56] <didrocks> rickspencer3: yeah, was just looking at that, it's the same code, so for stressing, it's good enough :)
[08:56] <rickspencer3> ok
[08:56] <rickspencer3> thanks man
[08:56] <didrocks> you're really welcome :)
[09:06] <seb128> hey
[09:06] <pitti> bonjour seb128, ca va?
[09:07] <seb128> hey pitti, I'm good, my cold is almost over (at least my nose stopped being blocked during nights)
[09:07] <seb128> how are you?
[09:07] <pitti> cold still in full progress, but bearable in the mornings
[09:09] <seb128> :-(
[09:12] <seb128> pitti, libgda5 got accepted in Debian btw
[09:12] <seb128> efficient NEWing nowadays ;-)
[09:12] <pitti> seb128: I saw, it was really quick!
[09:12] <pitti> seb128: btw, do you have a clue about bug 911622?
[09:12] <ubot2`> Launchpad bug 911622 in gdk-pixbuf "[12.04] GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': Datei oder Verzeichnis nicht gefunden (file not found)" [Undecided,New] https://launchpad.net/bugs/911622
[09:12] <seb128> not off hand, let me have a look
[09:21] <seb128> pitti, ok, I know
[09:23] <chrisccoulson> good morning world
[09:25] <seb128> hey chrisccoulson, how are you?
[09:26] <chrisccoulson> seb128, yeah, good thanks. how are you?
[09:26] <seb128> pitti, hum, no, in fact I don't know, I though it was maybe similar to the gtk3 I fixed yesterday and the postinst call failing when the olddir was empty
[09:26] <seb128> but that has been handled in gdk-pixbuf by using find to list the files
[09:26] <seb128> chrisccoulson, I'm good thanks
[09:31] <chrisccoulson> wow, it's quite amazing that when you search for "chrome" in google this morning, this page ranks higher than google's browser: https://developer.mozilla.org/en/Chrome_Registration
[09:36] <seb128> chrisccoulson, open a bug!
[09:36] <chrisccoulson> seb128, lol
[09:36] <chrisccoulson> seb128, i think it's intentional: http://searchengineland.com/google-chrome-page-will-have-pagerank-reduced-due-to-sponsored-posts-106551 ;)
[09:37] <chrisccoulson> google got caught out violating their own rules with a sponsored post campaign for chrome ;)
[09:37] <chrisccoulson> which is hardly surprising tbh.....
[09:40] <seb128> chrisccoulson, "sponsored post compain"?
[09:40] <chrisccoulson> seb128, paying sites to post bogus content with a link to the chrome website to boost page rankings ;)
[09:41] <seb128> ...
[09:41] <seb128> no comment
[09:41] <chrisccoulson> heh
[09:41] <seb128> I switch to bing, at least it lists chrome first when I type "chrome" :p
[09:41] <chrisccoulson> lol
[09:42] <chrisccoulson> bing must be using a similar algorithm for page rankings as chrome then. perhaps someone should contact microsoft to have them decrease the ranking for the chrome website too ;)
[09:42] <chrisccoulson> **as google
[09:42] <chrisccoulson> d'ohg
[09:42] <seb128> ;-)
[09:55] <smspillaz> rickspencer3: yeah, so it should be possible, if we enable the d-bus plugin by default to trigger those things using d-bus-send
[09:56] <rickspencer3> smspillaz, I'm finding it rather easy with xdotool to do what I want, in fact
[09:57] <smspillaz> sure
[09:57] <smspillaz> xdotool works as well, although using d-bus might make things a little less fragile in case, eg, the keybindings change
[10:11] <pitti> seb128: hm, I have an apport fix for ignoring the __memcpy_sse3 and friends stuff
[10:11] <pitti> seb128: I'll also ignore __kernel_vsyscall() while I'm at it
[10:11] <seb128> pitti, \o/
[10:11] <pitti> seb128: the problem is that committing this will break the existing duplicate db
[10:12] <pitti> as a lot of the current signatures have the old stuff
[10:12] <pitti> so we'll temporarily get non-detected duplicates, but dup detection will have a higher quality in the future
[10:12] <pitti> that's a bit tricky
[10:12] <seb128> well, we will deal with it
[10:12] <pitti> seb128: hopefuly the address signatures will take care of it somewhat
[10:12] <pitti> but we'll see more of these SystemErrors in teh future
[10:13] <pitti> seb128: so there's two options:
[10:13] <pitti> - leave the assertions and dupe the bugs manually
[10:13] <pitti> - ignore the assertion and force the duplication, at the expense of false positives
[10:13] <pitti> I propose we'll roll this out, wait for a few crashes, investigate that duping is really correct in these cases
[10:14] <pitti> and once we get convinced that it's right, automatically dupe for a while
[10:14] <pitti> seb128: unfortunately it's not easy to manually hack the dupe db to just filter out the ignored stuff, as we are lacking the frames after the existing ones
[10:15] <seb128> pitti, you somewhat lost me there, why will we have an increase of those systemerrors?
[10:15] <pitti> seb128: we currently get this assertion if the following happens:
[10:15] <pitti> - a crash has the same address signature as the existing one
[10:15] <pitti> (that's the new way of client-side dupe detection)
[10:16] <pitti> - after retracing the fully symbolic trace has a different signature than the existing bug
[10:16] <pitti> this assumes that fully symbolic traces are "better"
[10:16] <seb128> which is a correct enough assumption ;-)
[10:16] <pitti> i. e. all equal address sigs should also have an equal symbolic sig
[10:16] <pitti> we got the previous SystemErrors because the symbolic sigs had different __strcpy_sse42 vs. __strcpy_sse2 or what not
[10:17] <pitti> which broke above assumption
[10:17] <seb128> yeah, gotcha
[10:17] <pitti> now that we filter them out, we'll break it even harder, until we get crash duplicates with the cleaned up signatures
 - leave the assertions and dupe the bugs manually
[10:17] <pitti> so we could say "if either teh address or the symbolic signature matches, dupe it"
[10:17] <seb128> I would try that for a while and see how it goes and review the buggy cases
[10:17] <pitti> seb128: ok, that was my proposal
[10:18] <seb128> right, I agree with you then ;-)
[10:18] <pitti> and once we get sufficiently convinced that it DTRT, we'll switch over to automatic duping
[10:18] <seb128> sounds good
[10:18] <pitti> this is still in a kind of test drive where I added several asserts that the logic is correct, to avoid false dupes
[10:18] <pitti> seb128: ok, so you have been warned :)
[10:18] <seb128> thanks a lot for the explanations ;-)
[10:18] <pitti> seb128: whenever we get such a crash, we should verify that the retraced and master IDs are really dupes, and dupe them manually, then restart
[10:19] <seb128> ok
[10:19] <seb128> will dupping manually "resolve" the issue?
[10:19] <pitti> for that particular bug, yes
[10:19] <pitti> oh, hang on
[10:19] <seb128> i.e the retracer will know that it matches the signature of the "new" bug which is a duplicate of the old one?
[10:19] <pitti> we also need to kill the "wrong" symbolic signatures from the dupe db
[10:20] <pitti> otherwise we'll keep the wrong ones around forever
[10:20] <seb128> can you made a small utility which replace a signature by the one from another bug?
[10:20] <seb128> like "replace-sig bug1 bug2"
[10:21] <seb128> so we can run that when we hit those buggy cases?
[10:21] <pitti> let me think about this for a bit first
[10:21] <seb128> ok
[10:21] <pitti> we already know which bugs now will have "wrong" sigs
[10:21] <seb128> those which have the symbols you started filtering out?
[10:21] <pitti> let me think about/check what happens if we just remove them
[10:21] <pitti> seb128: right
[10:21] <seb128> ok
[10:24] <pitti> seb128: I'm creating fake lock files while I'm working on this, FYI
[10:24] <pitti> (i. e. stop the retracers)
[10:25] <seb128> pitti, noted
[10:30] <pitti> seb128: ok, I'll just wipe the existing wrong ones from the DB; they'll just get recreated if there's already a matching address sig
[10:30] <seb128> great
[10:30] <pitti> $ cp apport_duplicates.db apport_duplicates.db.__sse_sigs
[10:47] <tjaalton> slomo: is there a plan to get gstreamer-vaapi packaged at some point?
[10:48] <slomo> tjaalton: sure, when someone with time and hardware that supports it does it ;)
[10:49] <tjaalton> slomo: i see the long-term plan is to integrate it with -plugins-bad, but an interim solution would be a separate package until it's merged
[10:49] <tjaalton> or?
[10:49] <tjaalton> i have the hw, might package it then
[10:49] <seb128> chrisccoulson, there?
[10:49] <chrisccoulson> seb128, yeah
[10:50] <slomo> tjaalton: yes
[10:50] <seb128> chrisccoulson, can you help on https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/903973 ?
[10:50] <ubot2`> Launchpad bug 903973 in gnome-settings-daemon "gnome-settings-daemon crashed with signal 5 in _XReply()" [High,Confirmed]
[10:50] <seb128> chrisccoulson, just giving hints on how to debug those
[10:50] <seb128> chrisccoulson, would it help if we disable the libxklavier handler during the unstable cycle for a bit to get the real stacktraces from g-s-d?
[10:51] <seb128> chrisccoulson, rather than getting stuff libxlavier is catching?
[10:54] <tjaalton> slomo: ok, I might spend some cycles on it then
[10:55] <pitti> seb128: retracers back on, let the fun begin :)
[10:55] <chrisccoulson> seb128, it probably wouldn't help in this case, as the call which actually generates the error is the one which is on the stack
[10:56] <seb128> pitti, \o/
[10:57] <seb128> chrisccoulson, how do you see if libxklavier "hijacked" the call or not? I don't remember what you told me by then about libxklavier and how it was "misleading" the stacktraces
[10:58] <chrisccoulson> seb128, the error handler used by libxklavier exists to swallow some errors that occur normally, so if you disable that then they will just be caught by the GDK handler instead (which will abort)
[11:00] <chrisccoulson> in this case though, the call which generates the error is the one which is in the trace (XGetWindowAttributes)
[11:00] <chrisccoulson> called by xklavier :-)
[11:03] <seb128> chrisccoulson, I'm not sure to understand why we had issues with libxklavier then, if it just "traps" error it should have stopped issues, not leaded to confusing stacktraces?
[11:03] <seb128> chrisccoulson, well anyway this one seems a g-s-d keyboard bug then? would you be interested to have a look to it or should I just assign it to the team?
[11:04] <chrisccoulson> i'll have a quick look to see if i can figure out what's going on
[11:05] <seb128> chrisccoulson, thanks
[11:08] <chrisccoulson> ok, XGetWindowAttributes throws a BadMatch error if the specified window isn't actually a window
[11:13] <seb128> chrisccoulson, do you read the source to see that? ;-)
[11:13] <seb128> the manpage states "       XGetWindowAttributes can generate BadDrawable and BadWindow errors."
[11:13] <chrisccoulson> seb128, yeah
[11:14] <chrisccoulson> dixLookupWindow returns that error it finds some resource using the specified ID, but it isn't a window
[11:15] <chrisccoulson> those manpages often don't reflect reality ;)
[11:17] <seb128> I see ;-)
[11:36] <GunnarHj> seb128: FYI an attempt to bring the discussion with upstream about accountsservice's role for language/locale settings forward:
[11:36] <GunnarHj> https://bugs.freedesktop.org/42857#c4
[11:36] <GunnarHj> (pitti and rodrigo_ are on the CC list)
[11:36] <seb128> GunnarHj, hi, great
[11:37] <GunnarHj> seb128: That's basically all that I can come up with, I think. Not sure how to proceed.
[11:37] <seb128> wait for a reply from mathias?
[11:39] <GunnarHj> seb128: Yeah, that's the obvious first step, of course. :)
[12:29] <chrisccoulson> seb128, ok, deferred bug 903973 to RAOF ;)
[12:29] <ubot2`> Launchpad bug 903973 in gnome-settings-daemon "gnome-settings-daemon crashed with signal 5 in _XReply()" [High,Confirmed] https://launchpad.net/bugs/903973
[12:30] <seb128> chrisccoulson, way to go! ;-)
[12:31] <seb128> it's always the xorg guys fault at the end!
[12:32] <chrisccoulson> heh
[12:32] <didrocks> well, they display, it's their fault :)
[12:32] <chrisccoulson> it seems that i've investigated pretty much the exact same problem at some point in the past
[12:32] <seb128> didrocks, exactly!
[12:32] <chrisccoulson> seeing as i reported https://bugs.freedesktop.org/show_bug.cgi?id=23562 ;)
[12:32] <ubot2`> Freedesktop bug 23562 in Protocol/Core "GetProperty can return BadMatch error under certain conditions" [Normal,Resolved: fixed]
[12:33] <seb128> chrisccoulson, I've done "also affect xorg-server" and assigned that one to RAOF
[12:33] <chrisccoulson> thanks
[12:33] <seb128> yw ;-)
[12:33] <seb128> thank you for looking at it
[12:33] <seb128> g-s-d didn't change in precise and the bug started there
[12:34] <seb128> so it might be a new issue somewhere in the xorg stack
[12:34] <nessita> hello everyone!
[12:34] <seb128> hey nessita!
[12:34] <chrisccoulson> xorg didn't change either, the actual bug has been there all along. however, i suspect that something else on the desktop has changed which just exposes the race now
[12:34] <seb128> could be yes
[12:34] <chrisccoulson> something creating and destroying a window very quickly ;)
[12:34] <nessita> hi seb128!
[12:34] <seb128> nessita, show are you?
[12:35] <seb128> chrisccoulson, is there any way to find that something? and what is g-s-d tracking,why?
[12:35] <chrisccoulson> seb128, gsd is tracking all windows for the keyboard-layout-per-window stuff
[12:35] <nessita> seb128: great, thanks. You?
[12:35] <chrisccoulson> (ie, xklavier adds some properties to each top-level window)
[12:36] <seb128> only when that option is activated?
[12:36] <chrisccoulson> seb128, i'm not too sure about that. possibly
[12:36] <seb128> ok, that might explain why some people see it and others not
[12:36] <seb128> I will try to activate it just to see if I get the bug
[12:36] <seb128> nessita, I'm great thanks!
[12:36] <seb128> nessita, I had a cold but it's mostly over ;-)
[12:37] <chrisccoulson> slangasek, do you use more than one keyboard layout? (re, bug 903973)
[12:37] <seb128> nessita, do you come to budapest next week?
[12:37] <ubot2`> Launchpad bug 903973 in gnome-settings-daemon "gnome-settings-daemon crashed with signal 5 in _XReply()" [High,Confirmed] https://launchpad.net/bugs/903973
[12:38] <nessita> seb128: oh, I envy your weather, I guess you have a cold because *is* cold there. We're suffering the heat a lot here. And sadly no, not going to budapest, not this time. I will miss you, though :-/
[12:38] <seb128> nessita, :-( I wil miss you as well
[12:38] <seb128> well it's not real cold this year, we have a weird weather
[12:38] <seb128> cold and dry is good, we have a not-so-cold and rainy weather
[12:38] <chrisccoulson> same here ;)
[12:39] <chrisccoulson> it's just dull and wet here
[12:39] <nessita> ugh
[12:39] <chrisccoulson> same as the rest of the year ;)
[12:39] <seb128> lol
[12:39] <nessita> heh
[12:39] <seb128> seems about right for birmingham :p
[12:39] <nessita> so, if anyone feels like it, I could use a sponsorship for https://code.launchpad.net/~nataliabidart/ubuntu/precise/ubuntuone-control-panel/ubuntuone-control-panel-2.99.1/+merge/87406? I checked the patch pilot calendar and is kinda empty for today, but there is no rush :-)
[12:39] <seb128> nessita, doing it
[12:40] <seb128> nessita, I guess it's empty because dholbach usually fills it but he's not back from holidays yet I think
[12:40] <nessita> seb128: thanks! (link has an extra ? at the end)
[12:40] <nessita> ah, daniel, daniel :-P
[12:40] <seb128> nessita, launchpad seems smart enough to not break on the trailing "?" ;-)
[12:44] <seb128> nessita, uploaded
[12:45] <nessita> seb128: awesome, thanks!
[12:45] <seb128> nessita, yw
[12:45] <nessita> you rock
[12:45] <nessita> :-)
[12:45] <seb128> nessita, you as well ;-)
[12:48] <seb128> pitti, bug #911734, is that an apport bug?
[12:48] <ubot2`> Launchpad bug 911734 in gnome-keyring "package libgcr-3-common 3.2.2-1ubuntu2 failed to install/upgrade: trying to overwrite '/usr/share/gcr-3/ui/gcr-import-dialog.ui', which is also in package libgcr-3-1 3.2.2-0ubuntu1" [Undecided,New] https://launchpad.net/bugs/911734
[12:49] <pitti> hm, I thought I fixed that
[12:49] <seb128> pitti, you fixed the gnome-keyring bug
[12:49] <seb128> but "Package: libgcr-3-common 3.2.2-1ubuntu2"
[12:49] <seb128> though " Unpacking libgcr-3-common (from .../libgcr-3-common_3.2.2-1ubuntu1_all.deb) ..."
[12:49] <seb128>  
[12:49] <seb128> pitti, i.e it picks the newest version and wrongly assume it's a regression
[12:49] <seb128> but the log shows it's 1ubuntu1 which hit the bug
[12:50] <seb128> not sure what get the version wrong
[12:50] <pitti> hmm
[12:50] <seb128> i.e that "the version changed between the time the bug got collected and reported"?
[12:51] <pitti> seb128: that's one plausible explanation
[12:51] <seb128> pitti, I can dup it manually but it seems a buggy retracer case, do you want it reassigned to apport or something?
[12:51] <pitti> I'm not 100% sure which information the apt hook already adds
[12:51] <pitti> seb128: all information is in the bug, so please go ahead and dup, yes
[12:52] <pitti> seb128: right, or we just reassign it to apport, that's even better
[12:52] <seb128> doing that, it's easier that to open a new bug
[12:52] <seb128> and it has the infos needed from a buggy cases
[12:54] <seb128> pitti, done and title updated, bug #911734
[12:54] <ubot2`> Launchpad bug 911734 in apport "installation issues report sometimes the wrong package version" [Undecided,New] https://launchpad.net/bugs/911734
[12:54] <pitti> seb128: thanks
[12:54] <seb128> yw
[13:00] <GunnarHj> pitti: Hi Martin, hope you are fighting your cold successfully.
[13:00] <pitti> hey GunnarHj, happy new year!
[13:00] <GunnarHj> pitti: Happy new year to you as well.
[13:00] <GunnarHj> pitti: Do you possibly have time to take a shot at the a-s MP (bug 866062) and the related l-s MP? I can be available here for instant clarifications...
[13:00] <ubot2`> Launchpad bug 866062 in accountsservice "SetLanguage(): Write ~/.pam_environment instead of ~/.profile" [Medium,In progress] https://launchpad.net/bugs/866062
[13:02] <pitti> GunnarHj: I saw your post to the upstream bug
[13:03] <GunnarHj> pitti: Yeah, that's the forwarding aspect of it. But I really think that we should get the MPs into the archive before that discussion is completed.
[13:04] <pitti> it's really tricky to review, as it contains several things in one huge MP: the new API, the migration, the (still TBD) changed meaning of LANG, and the .bashrc -> .pam_environment bits
[13:05] <pitti> doing just the latter should be rather simple really, and everything else shoudl really be done upstream
[13:06] <pitti> this is now so utterly complex and error prone that it'll get harder and harder to do even more migrations in the future if upstream does something different or sticks to the current approach
[13:08] <GunnarHj> pitti: Well, I realize that it may appear complex at first sight, but there is a rather clear logic if you take a closer look.
[13:09] <GunnarHj> pitti: I did try to adjust the code in accordance with your first review.
[13:09] <pitti> GunnarHj: it's still on my list, but again, this is not something that I can review in an hour or so
[13:10] <pitti> and I'd like to pick it apart into above four parts, so that it's easier to review and understand
[13:12] <GunnarHj> pitti: I can try to split it into more revisions. But please note that the migration part covers both ~/.profile -> ~/.pam_environment and the changed LANG (format -> language) ...
[13:13] <pitti> well, "mentally split" is fine, too
[13:13] <GunnarHj> pitti: What do you mean by that? Expanding the comments?
[13:13] <pitti> but anyway, this requires pretty much a full day of review; in December I was on a different team, and now I have some catching up to do, that's why it took so long, sorry
[13:14] <pitti> GunnarHj: no, I mean it'll take some time to understand the current behaviour, the new one, reviewing the huge changeset, finding error cases, etc.
[13:14] <pitti> and it's again pretty spaghetti-ish
[13:14] <pitti> C code, shell code, more shell scripts, zenity, the $(ls /tmp/) ... rm loop (which might have a security problem), and so on
[13:15] <pitti> and I'm not convinced that we should land the LANG changes now
[13:16] <pitti> it's a rather large change which also impacts KDE, XFCE, etc., multiple window managers, gnome, and what not
[13:18] <GunnarHj> pitti: Hmm.. as regards LANG it's my impression that the way Ubuntu uses it is the 'odd' way. GNOME does it the other way for sure.
[13:18] <pitti> GNOME only handles LANG ATM, it doesn't have a concept of a language/region split so far?
[13:19] <pitti> meh, our g-s-d package is a mess .. 20ish patches without any patch header
[13:19] <GunnarHj> pitti: I think they have: Language -> LANG via /etc/gdm/Xsession and formats -> LC_* via gsettings g-s-d
[13:21] <pitti> ah, indeed
[13:22] <GunnarHj> pitti: So that's one good reason to do the LANG change, considering the move to g-c-c. It also will take care of some cases of incorrect display language.
[13:25] <GunnarHj> pitti: Please let me know if there is anything I can do to clarify the a-s MP. Some level of 'mental split' is hopefully in the changelog...
[13:25] <pitti> GunnarHj: how do you handle existing settings in .bashrc now?
[13:27] <GunnarHj> pitti: I didn't touch .bashrc. Reason: Since possible locale settings there has been made manuelly, it's reasonable to assume that the user has chose to ignore the UI and do it manually.
[13:27] <pitti> GunnarHj: but previous l-s wrote its settings there
[13:27] <pitti> so we need a migration path
[13:27] <pitti> otherwise you could never change the language again any more
[13:27] <GunnarHj> pitti: No, you mean ~/.profile, don't you?
[13:28] <pitti> GunnarHj: ah, yes I do
[13:28] <GunnarHj> pitti: And that's certainly taken care of.
[13:29] <pitti> ah, I see the sed call there
[13:29] <pitti> I think we should only do that if ~/.pam_environment doesn't exist yet
[13:29] <pitti> or rather, doesn't have the locale settings
[13:29] <pitti> i. e. once, not every time
[13:30] <seb128> pitti, g-s-d> we have 16 patches and they are mostly trivial ones?
[13:30] <GunnarHj> pitti: Existence of ~/.pam_environment is exactly the criteria I'm using in the MP.
[13:30] <pitti> seb128: yes, but almost none of them have a description or bug link
[13:30] <seb128> right...
[13:30] <seb128> pitti, well most are ubuntu specific
[13:30] <seb128> pitti, I will add descriptions next time I do an upload for it
[13:31] <GunnarHj> pitti: So migration happens only once, which of course is essential.
[13:33] <pitti> seb128: right, I was more concerned about the bug fixes; would really be nice to get them upstream, etc.
[13:33] <seb128> pitti, I don't think we have any fix coming from Ubuntu not upstreamed
[13:34] <GunnarHj> pitti: Possibly the latter isn't as clear as it could be, since the test for existence of ~/.pam_environment happens in the beginning of user_migration_from_profile().
[13:35] <pitti> GunnarHj: *nod*, sounds fine (we don't want to run the shell script at all if it exists)
[13:35] <GunnarHj> pitti: Right.
[13:36] <pitti> seb128: do you happen to know how to get the g_debug() output from gnome-settings-daemon? --debug doesn't
[13:37] <pitti> IIRC --debug used to work, but not any more
[13:37] <seb128> pitti, it doesn't? did you try to kill g-s-d and run a new one with --no-daemon --debug?.
[13:37] <pitti> yes, I killed it
[13:37] <pitti> --no-daemon doesn't exist
[13:37] <pitti> it does run in the foreground
[13:37] <seb128> let me check
[13:37] <pitti> it just doesn't output anything except warnings
[13:37] <pitti> bug not the g_debug
[13:38] <seb128> hum
[13:38] <pitti> seb128: don't worry, I just asked in case you knew the trick by heart
[13:38] <seb128> well I usually use --debug which worked for me :p
[13:40] <seb128> pitti, oh, I know
[13:41] <seb128> looking...
[13:41] <pitti> gsd_log_default_handler() has debug==1
[13:42] <pitti> so it seems g_log_default_handler eats it
[13:43] <seb128> pitti, yeah, since glib 2.31 there is a G_SOMETHING to set
[13:44] <seb128> I'm trying to find which one...
[13:45] <BigWhale> How would I suppress delete-event on Gtk.Window? I don't want my window deleted just hidden when I click X
[13:46] <seb128> pitti, try G_MESSAGES_DEBUG=all
[13:46] <pitti> seb128: aah, that worked; many thanks!
[13:46] <seb128> pitti,  G_MESSAGES_DEBUG=all g-s-d --debug
[13:46] <seb128> pitti, yw
[13:47] <seb128> took me a while to find it back!
[13:47] <pitti> it's helpfully not mentioned in the g_debug docs
[13:48] <seb128> indeed
[13:48] <seb128> pitti, https://bugzilla.gnome.org/show_bug.cgi?id=661926
[13:48] <ubot2`> Gnome bug 661926 in general "Improve the default logging setup in GLib" [Normal,Resolved: fixed]
[13:49] <seb128> pitti, it's documented in http://developer.gnome.org/glib/2.31/glib-Message-Logging.html#g-log-default-handler
[13:50] <seb128> but yeah, the api for g_debug etc could have a note about it
[13:51] <seb128> chrisccoulson, do you think you could send to GNOME your gsd login speed patches?
[13:51] <seb128> seems you didn't do it?
[13:54] <BigWhale> am I the only one having trouble with hide_on_delete in python? *bursts into tears*
[13:55] <pitti> seb128: ah nice, I can do G_MESSAGES_DEBUG=print-notifications-plugin
[13:55] <seb128> right
[13:55] <seb128> that was the idea, filter on domains
[14:00] <seb128> BigWhale, just put a callback on the signal and return TRUE in the handler?
[14:00] <BigWhale> seb128, yeah I just figured it out
[14:01] <BigWhale> I used return self.hide_on_quit()
[14:16] <dobey> kenvandine: do you even have any "readiness tests" for u1?
[14:17] <kenvandine> dobey, no... i would need you guys to help define that
[14:17] <kenvandine> it would be something like confirming upstream tests pass, etc
[14:17] <kenvandine> and some integration stuff, perhaps
[14:17] <dobey> :-/
[14:22] <dobey> kenvandine: so i had a sort of discussion with jason last night about this; and it seems upload privs for anyone not on platform team, for canonical packages, are basically worthless now :(
[14:23] <kenvandine> :(
[14:24] <dobey> so as you can guess, i am quite unhappy about that
[14:25] <pitti> kenvandine: why's that?
[14:25] <pitti> as long as there are AC, it doesn't matter much who runs them?
[14:25] <kenvandine> pitti, it was really a question of if that person has to be on the platform team or not
[14:25] <kenvandine> u1 has their own uploaders
[14:26] <kenvandine> so they don't want to block on having one of us do it
[14:26] <kenvandine> the whole reason they wanted upload rights
[14:27] <dobey> and we have our own qa team even
[14:28] <kenvandine> pitti, so u1 had assigned distro acceptance to one of their folks
[14:28] <pitti> hm, can we (i. e. you) really do a better job at QA than U1's own QA?
[14:28] <dobey> well, i think it just wasn't clear what was supposed to go in that column
[14:28] <kenvandine> pitti, no... i can't
[14:28] <kenvandine> especially now that i have probably nearly 30 packages on my plate
[14:33] <dobey> pitti: so what do you think?
[14:35] <pitti> dobey: I think it worked quite fine the way it was; I wouldn't change it from my POV
[14:35] <kenvandine> dobey, i'll talk to jason about it
[14:35] <pitti> i. e. U1 doing their own QA (lots of tests, etc.) and uploading
[14:35] <kenvandine> i really think you guys are best to fill that role
[14:36] <dobey> ok, thanks
[14:36] <pitti> dobey: ^ that is, we sohuld of course help you with packaging, and other process-y bits (MIRs, and what not)
[14:36] <pitti> but I don't see that kenvandine now handling all uploads and AC checks would improve anything
[14:36] <dobey> pitti: yes, there are obviously certain cases where we will have to bug DMB/platform/whatever
[14:36] <pitti> yes, absolutely
[14:36] <dobey> but i want to minimize that as much as possible
[14:36] <kenvandine> dobey, of course we are here to help :)
[14:36] <dobey> to let you guys concentrate on the other 3000 packages in ubuntu :)
[14:37] <seb128> speaking of which, do you plan to upload your fix for the libsyncdaemon segfault? ;-)
[14:37] <dobey> seb128: yes; which is why i stayed around late last night to bug jason :)
[14:37] <seb128> great ;-)
[14:38] <kenvandine> dobey, lets get that uploaded!
[14:38] <dobey> kenvandine: yep, am about to
[14:39] <kenvandine> awesome
[14:39] <dobey> just have to edit debian/changelog and upload
[14:40] <kenvandine> did you propose a merge?
[14:40] <dobey> no
[14:40] <kenvandine> ok
[14:41] <dobey> i did bzr merge-upstream last night, then bugged jason, then gtfo the computer :)
[14:50]  * kenvandine just discovered the GI_TYPELIB_PATH env variable, that was way to hard to find
[14:51] <pitti> kenvandine: ah, I could have told you
[14:51] <kenvandine> pitti, yeah... i looked for you to ask last night :)
[14:52] <kenvandine> pitti, i've added python unit tests to gwibber now using GI
[14:52] <kenvandine> so we have test parity for vala/c and python GI
[14:52] <kenvandine> we'll know when the GIR breaks :)
[14:53] <kenvandine> pitti, can GI_TYPELIB_PATH handle multiple paths?
[14:54] <kenvandine> GI_TYPELIB_PATH=../../libgwibber:../../libgwibber-gtk
[14:54] <kenvandine> like that?
[14:54] <pitti> yes, it can
[14:55] <kenvandine> woot!
[14:55] <kenvandine> thx!
[14:55] <pitti> kenvandine: note that you also might need to set LD_LIBRARY_PATH accordingly to use the local .so files
[14:55] <kenvandine> i did
[14:58] <dobey> seb128, kenvandine: ok, as soon as pbuilder finishes happily, i'll dput the new package
[14:58] <kenvandine> dobey, thx
[14:58] <seb128> dobey, thanks
[15:09] <GunnarHj> pitti: Did you leave a-s for today? Just wondering if I should keep standing by. (I'm happy to do so.)
[15:11] <pitti> GunnarHj: probably not, sorry (working on something else, and keep getting pinged)
[15:11] <pitti> I'll probably stop in an hour or two, silly cold
[15:12] <GunnarHj> pitti: Ok. Would it help if we scheduled a time to process it?
[15:12] <pitti> TBH I'd just try to squeeze it in in the next days and answer in the MP
[15:12] <pitti> I got my ubuntu box down to 4 now
[15:12] <pitti> of which 2 are your MPs :)
[15:13] <dobey> seb128, kenvandine: uploaded :)
[15:13] <seb128> \o/
[15:13] <GunnarHj> pitti: Ok, that sounds great. :)  Hope your cold goes away soon.
[15:13] <kenvandine> :-D
[15:15] <dobey> kenvandine: are you incredibly busy? i have a bunch of other packages which i have to make merge proposals for (since i don't have upload privs for them yet). but they are all trivial no-impact changes (new release only, without any source changes)
[15:15] <kenvandine> sure
[15:15] <kenvandine> dobey, create merge proposals and request a review from me
[15:15] <dobey> kenvandine: ok; thanks
[15:21] <seb128> pitti, g-s-d> did you start on login speed? ;-)
[15:21] <pitti> seb128: yes; now that I'm back to development I desperately need to start on my WIs
[15:21] <seb128> \o/
[15:21] <seb128> I should look at my WIs as well
[15:22] <seb128> I've been dealing with desktop updates and merges mostly so far
[15:22] <pitti> yeah, similar here: there's always a couple of urgent issues which get in the way
[15:23] <seb128> pitti, btw you put the bar too high on bugs closing count compared to the rest of the team, you need to let people a change so they try to catch you ;-)
[15:23] <pitti> hehe
[15:23] <seb128> change->chance
[15:23] <pitti> http://reports.qa.ubuntu.com/reports/bug-fixing/precise-fixes-report.html
[15:23] <pitti> oh, nice
[15:24] <dobey> yeah, i need to do my one WI
[15:24] <seb128> dobey, "get a working music store back"? ;-)
[15:24] <pitti> seb128: as soon as unity gets uploads again, didrocks will skyrocket to the top again anyway
[15:24] <seb128> pitti, indeed
[15:24] <didrocks> it's a so easy win :-)
[15:25] <dobey> seb128: no, the only WI i got at UDS was to write a script to analyze some bugs filed against Ubuntu, but without a package
[15:25] <didrocks> meanwhile, /me simulates oneconf server error for the test suite :)
[15:26] <dobey> the music store is something i also have to do, but i don't think there are any work items for it
[15:28] <seb128> pitti, is that ok if I NEW gtkspell3 directly to main? that's basically a new version of gtkspell renamed for gtk3
[15:28] <pitti> seb128: sure
[15:28] <seb128> thanks
[15:31] <chrisccoulson> why-oh-why https://launchpadlibrarian.net/89040628/buildlog_ubuntu-precise-i386.firefox-trunk_12.0~a1~hg20120103r83671-0ubuntu1~umd1_FAILEDTOBUILD.txt.gz :-(
[15:31] <chrisccoulson> hanging tests! grrrrrrr
[15:33] <seb128> chrisccoulson, yeah, those are annoying
[15:34] <seb128> pitti, gnome-keyring hanged in the testsuit on i386 and amd64 yesterday that's why your breaks fixes got duplicates for a while, a retry worked though
[15:34] <seb128> just for info
[15:34] <pitti> seb128: right, saw from backscroll; thanks
[15:34] <seb128> kenvandine, "    - Renamed gtkspell binary libgtkspell-common" do you remember why you did that?
[15:35] <kenvandine> yes
[15:35] <kenvandine> because of the dual build for gtk2 and gtk3
[15:36] <seb128> kenvandine, hum? how is the name revelant? did you move stuff in there?
[15:36] <seb128> that binary is not even installed on my box
[15:36] <kenvandine> humm
[15:36] <seb128> it's empty
[15:36] <seb128> I guess it only has translations that got stripped at build time
[15:37] <seb128> kenvandine, do you mind if I revert the name back to the old one? ;-)
[15:37] <kenvandine> i seem to recall someone rejecting it from NEW because the common files ended up in gtkspell and someone said the binary would be better named libgtkspell-common
[15:37] <kenvandine> something like that
[15:37] <kenvandine> hold on, let me look at it and try to refresh my memory
[15:37] <seb128> kenvandine, Debian packaged upstream vcs as gtkspell3
[15:37] <seb128> kenvandine, which I just synced
[15:38] <seb128> kenvandine, so gtkspell goes back to be mono build of gtk2, I basically want to revert to what it was before your changes
[15:38] <seb128> kenvandine, sounds good?
[15:38] <seb128> kenvandine, then we just need to make libgwibber build with the new lib
[15:38] <seb128> kenvandine, I can look at that if you want
[15:39] <kenvandine> oh cool
[15:39] <kenvandine> did upstream release the gtk3 version?
[15:39] <kenvandine> they merged my patch, but tweaked it to make two separate upstream sources
[15:39] <kenvandine> which seemed silly to me
[15:40] <kenvandine> but last i checked they had a dev snapshot and no release
[15:40] <seb128> kenvandine, they didn't release, debian did a vcs snapshot
[15:40] <seb128> but that works as well
[15:40] <kenvandine> then revert what i did
[15:40] <kenvandine> that is fine
[15:40] <kenvandine> i'll make gwibber work with it
[15:41] <seb128> kenvandine, do you want me to look at rebuilding libgwibber with the new lib?
[15:42] <kenvandine> nah
[15:42] <seb128> ok
[15:42] <kenvandine> i'll do that
[15:42] <seb128> thanks
[15:42] <kenvandine> just get it uploaded and then i'll make it build
[15:42] <kenvandine> i looked at what upstream did there already, it'll be trivial
[15:43] <seb128> kenvandine, the lib is named libgtkspell-3-0, yours was libgtkspell3-0
[15:43] <kenvandine> yeah
[15:43] <kenvandine> and they renamed the .pc file
[15:57] <Sweetshark> pitti: so, I have a basic 3.5.0beta2 package which is still very much incomplete wrt ubuntu patches, but does compile and test on amd64. Id love to release that one to the ppa for oneiric to get some early testing, but I guess it will still break on some platforms like ppc/armel. any hint on how to proceed.
[15:57] <Sweetshark> ?
[16:04] <slangasek> chrisccoulson: 903973> I don't *usually* use more than one keyboard layout, but may have had one configured at the time
[16:09] <seb128> slangasek, the question is: run gnome-control-center, click on layout, what option is selected on the right?
[16:12] <slangasek> seb128: currently, I only have one layout enabled; English (Dvorak alternative international)
[16:12] <slangasek> oh, you said on the right
[16:12] <seb128> yes ;-)
[16:12] <slangasek> "Use the same layout for all windows"?
[16:12] <seb128> ok
[16:12] <slangasek> but - I was playing with my keyboard layout in that timeframe
[16:12] <seb128> so not the "by win" one
[16:12] <slangasek> no
[16:12] <seb128> thanks
[16:12] <seb128> that was the question ;-)
[16:12] <slangasek> but that could have been selected briefly at the time
[16:13] <seb128> we were trying to figure if that could be due to that option
[16:13] <seb128> I will turn it on and see if it starts bugging here
[16:13] <seb128> ups
[16:45] <pitti> Sweetshark: PPAs don't build ppc/armel anyway, so that seems fine?
[16:48] <ogra_> pitti, Sweetshark, the canonical-arm-dev PPA has armel enabled, i can get one of you access in case you want to testbuild for arm at some point
[16:48] <pitti> we can also test-build on the porter machines
[16:48] <ogra_> ah, indeed
[16:50] <pitti> good night everyone! need to rest a bit, silly cold
[16:51] <seb128> 'night pitti
[17:20] <dobey> ugh
[17:21] <dobey> kenvandine: looks like https://code.launchpad.net/~dobey/ubuntu/precise/ubuntuone-dev-tools/release-2-99-0/+merge/86756 never got uploaded :(
[17:21] <dobey> kenvandine: should i get you to do that one, or stick my new release in that same branch?
[17:21] <kenvandine> nope
[17:22] <kenvandine> just stick another new release and we'll do one upload
[17:22] <dobey> ok
[17:27] <didrocks> Ran 46 tests in 474.079s
[17:27] <didrocks> \o/
[17:28] <seb128> didrocks, well done! ;-)
[17:29] <didrocks> ok, I think that all OneConf tests are ok for now. Just 2 bugs to fix (and add tests) and I'll be ok at the rally :)
[17:30] <seb128> great ;-)
[17:30] <seb128> keep something to do for the trip! :p
[17:33] <didrocks> well, I still have a LWN backlog :)
[17:34] <didrocks> but I needed some quiet time to be effective on the remaining ones, and at home was a great opportunity to finish this up :)
[17:34] <seiflotfy> didrocks: any idea how i can fix
[17:34] <seiflotfy> /bin/sed: can't read /usr/lib/i386-linux-gnu/libpangocairo-1.0.la: No such file or directory
[17:34] <seiflotfy> libtool: link: `/usr/lib/i386-linux-gnu/libpangocairo-1.0.la' is not a valid libtool archive
[17:35] <didrocks> seiflotfy: you probably have some .la file in /usr/lib/ and /usr/lib/i386-linux-gnu/. You should look at which and remove them
[17:35] <seiflotfy> yeah but i have a lot of those
[17:36] <seiflotfy> which one is it i have to find
[17:38] <seiflotfy> didrocks: ?
[17:39] <didrocks> seiflotfy: the one which have libpangocairo-1.0 in them
[17:39] <seiflotfy> /usr/lib/i386-linux-gnu/libpangocairo-1.0.so
[17:39] <seiflotfy> /usr/lib/i386-linux-gnu/libpangocairo-1.0.so.0
[17:39] <seiflotfy> /usr/lib/i386-linux-gnu/libpangocairo-1.0.a
[17:39] <seiflotfy> /usr/lib/i386-linux-gnu/libpangocairo-1.0.so.0.2905.0
[17:39] <seiflotfy> ?
[17:39] <seiflotfy> those?
[17:40] <seiflotfy> i have no .la files
[17:40] <seiflotfy> which package provies them
[17:41] <seiflotfy> ok seems i have libpango installed
[17:41] <seiflotfy> but no packages for it
[17:41] <seiflotfy> as in the package is installed but no files from it
[17:41] <seb128> ?
[17:42] <seb128> seiflotfy, grep libpangocairo-1.0.la *.la
[17:42] <seb128> seiflotfy, in /usr/lib and /usr/lib/i386-linux-gnu
[17:42] <seb128> and delete the ones listing it
[17:43] <seiflotfy> seb128: 100% there is nothign
[17:43] <seiflotfy> grep libpangocairo-1.0.la *.la /usr/lib/i386-linux-gnu/
[17:43] <seiflotfy> ?
[17:44] <seb128> grep libpangocairo-1.0.la /usr/lib/*.la /usr/lib/i386-linux-gnu/*.la
[17:45] <seiflotfy> seif@Wumbo:~$ grep libpangocairo-1.0.la /usr/lib/*.la /usr/lib/i386-linux-gnu/*.la
[17:45] <seiflotfy> seif@Wumbo:~$
[17:45] <seiflotfy> seb128: i told you nothing
[17:45] <seb128> grep libpangocairo-1.0.la /usr/local -r
[17:45] <seb128> seiflotfy, well it's likely coming from a local install
[17:45] <seb128> check your /usr/local or /opt or jhbuild dir or whatever you use
[17:46] <seb128> you have a .la somewhere on the disk listing libpangocairo-1.0.la
[17:46] <seb128> 99% of the time it's a local install, i.e /usr/local or /opt, people who use make install
[17:47] <seiflotfy> seb128: ok
[17:48] <seiflotfy> seb128: found a lot though
[17:48] <seb128> seiflotfy, just rm *.la
[17:48] <seb128> they are not useful on linux, we are getting ride of them
[17:49] <seiflotfy> on ubuntu or overall linux
[17:49] <seb128> debian and ubuntu
[17:49] <seb128> but fedora doesn't install those for a long time I think
[17:49] <seb128> dunno about other distros
[17:50] <dobey> some are (or at least, used to be) useful
[17:50] <dobey> but maybe glade/gtkbuilder is better about that now
[17:51] <seb128> dobey, why would glade or gtkbuilder need those?
[17:51] <seiflotfy> seb128: i am freaking out sorry
[17:51] <seiflotfy> but
[17:51] <seiflotfy> i removed the .la files in my local installs
[17:51] <seiflotfy> yet
[17:51] <seiflotfy> /bin/sed: can't read /usr/lib/i386-linux-gnu/libpangocairo-1.0.la: No such file or directory
[17:51] <seiflotfy> libtool: link: `/usr/lib/i386-linux-gnu/libpangocairo-1.0.la' is not a valid libtool archive
[17:52] <seb128> seiflotfy, find / . -name *.la
[17:52] <seb128> you probably forgot somes somewhere
[17:52] <dobey> seb128: glade and gtkbuilder themselves don't really; but back in the day we had problems with evolution, evolution-exchange, and other plugins, where we needed the .la files to pull the -rpath from automatically when building, so that "custom widgets" in glade stuff would work correctly
[17:53] <seb128> dobey, ok, dunno if that's still an issue or not but I bet seiflotfy doesn't need .la for what he tries to build ;-)
[17:54] <dobey> he probably doesn't
[17:54] <dobey> i was just providing counterpoint for the "not useful on linux" argument, which isn't entirely true
[17:55] <dobey> they do make linking slower, but to say they are entirely useless is a bit of an overstatement :)
[17:56] <seb128> well they mostly are, and I think they are not compatible with multiarch
[17:56] <seb128> which is why we are getting ride of them ;-)
[17:57] <seiflotfy> seb128: so i can remove ALL .la files from /usr/lib?
[17:57] <seb128> yes, but that will not help since you grepped those and they don't refer to libpangocairo
[17:57] <dobey> yeah, the multiarch thing does introduce new problems :)
[17:58] <seb128> you need to find which .la list it
[17:58] <dobey> speaking of multiarch
[17:58] <dobey> is there anything special i need to do for our u1 stuff, to make it multiarch?
[17:59] <dobey> the python stuff is fine obviously, but libs and such not so much i guess
[17:59] <seb128> dobey, http://wiki.debian.org/Multiarch/Implementation
[18:00] <didrocks> time for sport here, have a good evening everyone!
[18:00] <seb128> didrocks, 'night
[18:01] <seiflotfy> seb128: what do i do once done?
[18:02] <seb128> seiflotfy, ?
[18:02] <seb128> just find the .la listing libpangocairo and delete it
[18:02] <seiflotfy> i removed all .la files
[18:02] <seb128> then run make again
[18:04] <didrocks> seb128: thanks, you too!
[18:05] <seiflotfy> seb128: does this look right http://imgur.com/W8YbN
[18:05] <seiflotfy> because i have it installed but its not listing any installed packages
[18:06] <seb128> ?
[18:06] <seb128> that seems a bug
[18:07] <seb128> try to run "dpkg -L libpango1.0-0"
[18:07] <seb128> on a command line
[18:07] <seb128> btw the version you are using is not an official Ubuntu one, dunno where you got it
[18:10] <seiflotfy> seb128: http://pastebin.com/KWMwdtbQ
[18:10] <seb128> seiflotfy, that's the content of the package
[18:10] <seb128> seems normal
[18:10] <seb128> what are you looking for?
[18:11] <seiflotfy> i am now trying to build clutter-gtk
[18:11] <seiflotfy> /home/seif/Projects/dawati/source/clutter-gtk/examples/gtk-clutter-viewport.c:41: undefined reference to `g_thread_init'
[18:11] <seiflotfy> collect2: ld returned 1 exit status
[18:11] <seiflotfy> make[2]: *** [gtk-clutter-viewport] Error 1
[18:12] <seb128> ok, better
[18:12] <seiflotfy> seb128: what seems to be the problem here though?
[18:12] <seb128> seiflotfy, drop G_DISABLE_DEPRECATED from your build flag
[18:12] <seb128> or fix clutter-gtk to not use deprecated apis
[18:13] <ricotz> seiflotfy, what clutter-gtk version is this?
[18:14] <seiflotfy> ricotz: trunk i guess
[18:14] <seiflotfy> sorry
[18:14] <seiflotfy> 0.12
[18:15] <ricotz> seiflotfy, i see, 1.1.2 doesnt have a problem
[18:15] <ricotz> 0.12?
[18:15] <seiflotfy> * clutter-gtk-0.12
[18:15] <seiflotfy> ricotz: ^
[18:16] <ricotz> oh, this looks pretty old then
[18:16] <ricotz> seiflotfy, check if you are really on the master branch
[18:17] <seiflotfy> i am building it for dawati
[18:18] <dobey> kenvandine: updated https://code.launchpad.net/~dobey/ubuntu/precise/ubuntuone-dev-tools/release-2-99-0/+merge/86756 though, not entirely sure if i did the changelog right
[18:18] <ricotz> seiflotfy, sorry, i dont know dawati, but the clutter-gtk source seems pretty outdated then
[18:19] <ricotz> seb128, hi, do you mind sponsoring clutter-gtk 1.1.2?
[18:19] <seb128> ricotz, hey, I can do taht
[18:19] <seb128> where is it?
[18:19] <seb128> mterry, \o/
[18:19] <mterry> seb128, what's up?
[18:20] <seb128> mterry, I had bug #904140 on my todolist for today, I can drop it thanks to you ;-)
[18:20] <ubot2`> Launchpad bug 904140 in evince "evince crashed with SIGSEGV in child_setup()" [Medium,Confirmed] https://launchpad.net/bugs/904140
[18:20] <mterry> seb128, heh  :)  yw
[18:20] <ricotz> seb128, one se
[18:20] <ricotz> c
[18:21] <ricotz> seb128, https://launchpad.net/~ricotz/+archive/testing/+build/2985843
[18:21] <seb128> ricotz, thanks
[18:21] <ricotz> seb128, i will create a new source package
[18:22] <seb128> ricotz, why?
[18:22] <seb128> or for what?
[18:22] <seb128> is that still a clutter-gtk topic or did you change topic? ;-)
[18:22] <ricotz> for a proper version
[18:22] <ricotz> seb128, or you can grab it and repack it
[18:22] <seb128> ricotz, oh, I can download that and strip the ~... from the changelog
[18:22] <ricotz> seb128, ok
[18:23] <seb128> ricotz, I need to run debuild to build the .changes anyway
[18:23] <seb128> that's not on the ppa
[18:23] <ricotz> seb128, i would have done that too ;)
[18:34] <ricotz> seb128, sorry, i totally missed the fact the cogl/clutter isnt 1.9.2 :\
[18:35] <seb128> ricotz, lol, I was going to ask
[18:36] <seb128> should we update those?
[18:36] <seb128> you recommended to not do it yet before the holidays
[18:36] <ricotz> seb128, :\, i was hoping to see some 1.9.4 tarballs
[18:38] <kenvandine> dobey, i'll take care of it
[18:40] <dobey> kenvandine: great, thanks; i've also got the other packages proposed with you as reviewer now
[18:41] <kenvandine> ok, i should get to them soonish :)
[18:42] <dobey> cool. mostly not a huge rush, since there's no changes aside from version bumps. but since ubuntuone-dev-tools didn't get uploaded for the last release, it's a higher priority than the rest so please do it first :)
[18:50] <micahg> cyphermox: that evo change looks risky unless the only nss lib that evo uses are in the subdir
[18:57] <cyphermox> micahg: I checked
[18:59]  * micahg wonders if there's a more proper way to access the cert store than evo is doing
[19:06] <dobey> micahg: would be nice if everything just used the keyring for that
[19:15] <chrisccoulson> hmmm, beer-o-clock
[19:18] <BigWhale> The lack of code examples, tutorials and sometimes utterly useless help on stackoverflow is somewhat frustrating time to time ... I wish Canonical could put some effort into this.
[19:42] <dobey> BigWhale: on stackoverflow, or askubuntu?
[19:43] <BigWhale> first
[19:45] <BigWhale> dobey, I didn't find anything on askubuntu
[19:45] <dobey> what sort of questions? and why should canonical spend time going through it to provide such aexamples and tutorials?
[19:46] <dobey> BigWhale: i don't even know hwat you're looking for. but i don't think either of those is probably the right place to have documentation. docs belong in a more organized place
[19:48] <BigWhale> dobey, Well I think it would be great if Canonical could put some effort into basic guidelines, tutorials, documentation and code examples for developers.
[19:49] <dobey> i think we are
[19:49] <BigWhale> or perhaps just organize things a little
[19:51] <BigWhale> My "rant" is more on a global scale ... Not targeted at anyone in particular. I think it would be great to have sort of one-stop place for all the developers
[19:52] <BigWhale> I am displeased with documentation in general with open source ... :>
[19:52] <dobey> like http://developer.ubuntu.com/ ?
[19:53] <BigWhale> ok... wow...
[19:53] <BigWhale> *cue in the awkward moment music*
[19:54] <BigWhale> but! :)
[19:54] <BigWhale> this site didn't come up on any searches in google... :/
[19:55] <dobey> BigWhale: it's the 3rd result for me for "ubuntu developer documentation"
[19:56] <dobey> and i imagine the first two results might have links to it as well
[19:56] <BigWhale> my searches were a bit specific
[19:57] <dobey> example?
[19:57] <dobey> searching for things about specific libraries/languages/etc may very well not get you there
[19:58] <BigWhale> I think that developer.ubuntu.com is quite awesome. Now that I clicked on it a little.
[19:59] <BigWhale> Too bad I didn't notice it sooner.
[19:59] <seb128> chrisccoulson, "beer-o-clock"  ... training for next week? ;-)
[20:00] <BigWhale> dobey, well I was (still am, to be precise) looking for simple working example on how to use cairo to draw in gtk3 windows.
[20:00] <BigWhale> and how to make a gtk3 window transparent :)
[20:01] <dobey> in vala? python? c?
[20:01] <BigWhale> python preferably
[20:02] <dobey> BigWhale: for the transparency, window.set_opacity()
[20:03] <dobey> BigWhale: for cairo, are you trying to draw on a GtkWindow, or on some other widget?
[20:04] <BigWhale> dobey, don't get me wrong, I wasn't trying to criticize or rant, I was merely 'thinking out loud' how nice it would be to have all the developer stuff in one place.
[20:04] <BigWhale> I am happy as a lamb to see developer.ubuntu.com
[20:04] <dobey> well, for ubuntu, i think developer.ubuntu.com is supposed to be that place
[20:04] <BigWhale> set_opacity? now you're just mocking me... :>
[20:05] <dobey> i don't know how extensive the docs are there, though
[20:05] <dobey> for vala, i mostly just use valadoc.org as a reference
[20:05] <BigWhale> set+opacity actually works ...
[20:06] <BigWhale> excuse me ... I'll go and hide now.
[20:06] <dobey> well, it should work, unless you're under a wm that isn't doing compositing
[20:07] <BigWhale> now I just need to figure out on how to make a window transparent and some text in it, not so transparent. :)
[20:08] <BigWhale> I'll just stack couple of windows on top of each other or something like that ..
[20:08] <dobey> but i've been dooing gtk/gnome hacking for like 15 years, so i guess i just expect there to not be docs and know how to go about finding stuff i need more easily :)
[20:09] <dobey> i'm not sure what you're trying to do exactly, but athat sounds like it will probably be a bit more work to do :)
[20:10] <BigWhale> dobey, I want a countdown in 'splash screen' that is a transparent
[20:11] <BigWhale> and for cairo, I was trying to draw on GtkWindow yes
[20:11] <BigWhale> and I got to the point where I connected draw signal
[20:12] <dobey> i think set_opacity() sets a wm hint on the window, which makes the wm apply transparency
[20:12] <BigWhale> but nothing was actually drawn on the windows then :)
[20:12] <dobey> which just does it on everything
[20:12] <BigWhale> then I'll probably have to do it with cairo
[20:12] <dobey> i think you need to embed a drawable in the window, and do everything on it
[20:13] <chrisccoulson> seb128, yeah, i'm making the most of it before i give up drinking for a while :)
[20:14] <dobey> BigWhale: you need a GtkDrawingArea
[20:14] <BigWhale> dobey, as I understand this: http://developer.gnome.org/gtk3/3.0/GtkWidget.html#GtkWidget-draw
[20:15] <BigWhale> I get a cairo surface here and I can draw on it as much as I like.
[20:15] <dobey> you misunderstood :)
[20:15] <BigWhale> ok
[20:16] <dobey> that's not something you should connect() to on a widget, and then attempt to draw on the widget in your callback
[20:17] <dobey> BigWhale: in Python, you can class MyWidget(Gtk.DrawingArea): and override the draw() method though, then just embed MyWidget() in the window
[20:17] <BigWhale> hmm I was looking at some gtk2 example that connected to expose-event signal and I found in some documentation that draw signal is now used instead
[20:18] <dobey> yes, draw replaces expose-event, but you really should only use them internally
[20:18] <dobey> they're more like virtual class methods, than signals that an app developer should connect to
[20:20] <dobey> BigWhale: http://developer.gnome.org/gtk3/stable/GtkDrawingArea.html is really waht you want to use
[20:21] <dobey> BigWhale: and DrawingArea is at least sensible to connect to "draw" as you were trying to do with the window
[20:22] <dobey> but for a window, it's not so sensible :)
[20:23] <BigWhale> cool
[20:23] <BigWhale> thanks for all the info
[20:24] <BigWhale> I'll go and hack some now... :>
[20:28] <kenvandine> dobey, ubuntuone-dev-tools requires python-dirspec >= 3.1
[20:29] <kenvandine> but the latest uploaded is 2.99
[20:30] <dobey> eh? doh
[20:30] <dobey> weird
[20:32] <dobey> kenvandine: ah, must have overlooked that when i copied the control file over from nightlies to do the switch to pure dh. fixed now, sorry :)
[20:32] <kenvandine> no worries
[20:32] <kenvandine> so it didn't really need that?
[20:33] <dobey> no
[21:11] <kenvandine> mterry, i just commented on that deja-dup merge proposal, the tests conflicted on merge
[21:12] <kenvandine> mterry, i would have tried to clean it up myself, but your change was specific there so didn't want to do the wrong thing
[21:16] <mterry> kenvandine, ah, I'll clean and re-comment.  I forgot I updated that test code after
[21:37] <TheMuso> Grrrr I hate havving to use the NVIDIA drivers. NVIDIA really needs to be clubbed with a cluestick so they use XRandr.
[21:37] <TheMuso> nvidia-settings is a poor child's substitute.
[21:37] <TheMuso> Especially since one can only save the monitor config to an xorg.conf file...
[21:37] <TheMuso> At least afaik.
[21:38] <broder> i am still firmly of the belief that the NVControl extension *could* be shoehorned into GnomeRR
[21:38] <TheMuso> But... but... THere is XRandr. All other drivers use it. :)
[21:39] <dobey> "My enemy's enemy is my friend."
[21:40] <TheMuso> I was using Nouveau, and that worked, but afaik it doesn't have deacent PM yet, and Unity was running a little sluggish with my 24" monitor connected.
[21:40] <TheMuso> Oh yeah, and I am displeased with Lenovo for connecting the VGA port, and the monitor ports on the docking station via the NVIDIA GPU only.
[21:41] <broder> ugh, that sucks. the vga port on my lenovo and its docking station do work with the intel card
[21:42] <TheMuso> I could use the DisplayPort on the machine itself, if 1) I wasn't using a docking statino, and 2) I was using the monitor directly, and not via a KVM.
[21:42] <dobey> my laptops mostly all have intel only anyway
[21:43] <dobey> only ones i've ever had, that didn't, had ati cards
[21:43] <TheMuso> Right, well thats the problem with getting a 15" notebook I guess, hybrid GPUs are now the norm.
[21:43] <dobey> but old powerbook g3, ibook that doesn't turn on, and my really old thinkpad x31 aren't really usable machines to work on any more
[21:44] <dobey> i think the problem is more that nvidia is more the norm these days
[21:44] <TheMuso> Yeah that too.
[21:45] <TheMuso> At least Lenovo lets me choose which GPU to use in the BIOS, i.e I can turn off hybrid mode/NVIDIA Optimus.
[21:46] <dobey> i try really hard to avoid buying laptops larger than 8" though
[21:48] <TheMuso> To each their own.