[01:03] <LLStarks> meh. i'm missing my window bar with thunderbird 15 in gnome-shell.
[01:06] <robru> bah, latest quantal, my screen is powering down after 10 minutes, regardless of what settings I choose in the Brightness and Lock settings.
[01:08] <robru> bug 944062 I guess, except totem instead of vlc, and ati instead of intel
[01:08] <ubot2`> Launchpad bug 944062 in vlc "display power management utilities turn screen off after 10 minutes even when VLC is playing video " [Undecided,Invalid] https://launchpad.net/bugs/944062
[01:35] <k36> hi
[01:36] <k36> can anyone help me with desktop sharing
[03:46] <pitti> Bonjour
[03:46] <pitti> robert_ancell: hey Robert, how are you?
[03:46] <robert_ancell> pitti, hey good
[03:46] <pitti> robert_ancell: I hope we didn't step on each other's toes with the glib upgrade?
[03:46] <robert_ancell> pitti, I updated the gvfs package btw, but can't build until the new glib turns up
[03:47] <robert_ancell> pitti, nope, that's why I file the bugs so others can take over / use what I've done
[03:47] <pitti> robert_ancell: I'll sync the new glib into quantal-proposed now, OK?
[03:47] <robert_ancell> yes please
[03:47] <pitti> https://buildd.debian.org/status/package.php?p=glib2.0&suite=experimental has some test failures on some arches, but looks good enough
[03:57] <pitti> robert_ancell: btw, I have a few changes staged in lp:ubuntu/gvfs
[03:57] <pitti> robert_ancell: I didn't upload yet because of the freeze
[03:57] <robert_ancell> pitti, I took the -ubuntu6 changes are there more?
[03:57] <pitti> yes, but ubuntu6 is uploaded (in unapproved)
[03:57] <pitti> the branch has UNRELEASED ones
[04:05] <pitti> robert_ancell: https://launchpad.net/ubuntu/+source/glib2.0/2.33.12-1 is building, FYI
[04:10] <robert_ancell> pitti, how are you supposed to know that there might be unreleased changes in lp:ubuntu/gvfs? There is no tag in debian/control
[04:14] <robert_ancell> RAOF, should we be shipping intel-gpu-tools 1.3?
[04:14] <pitti> robert_ancell: it's the standard ubuntu:gvfs branch; I thought some time ago we wanted to use this as part of the "move to UDD" prototypes?
[04:14] <pitti> robert_ancell: we can certainly go back to a custom branch, but we had gvfs in sync for some time (and I certainly will commit the autopkgtest stuff to Debian as well)
[04:15] <robert_ancell> pitti, yeah, but I keep forgetting and there's nothing to let you know that those changes exist
[04:15] <RAOF> robert_ancell: Yes; I believe tjaalton's on it, or is at least annoyed by upstream adding stupid files.
[04:15] <robert_ancell> so I'm sure others will make the same mistake
[04:15] <pitti> robert_ancell: but no worries, if you upload a  new version, I'll just merge my changes to the next one; the package importer will sort that out and generate a MP for that
[04:16] <robert_ancell> pitti, ok, also feel free to take the changes yourself if you do the update. It's bug 1046139
[04:16] <ubot2`> Launchpad bug 1046139 in gvfs "Update to 1.13.8" [Wishlist,Triaged] https://launchpad.net/bugs/1046139
[04:17] <pitti> robert_ancell: do you prefer setting up a ~ubuntu-desktop branch for gvfs again?
[04:17] <tjaalton> robert_ancell: 1.13 is in git, could upload it post-beta2
[04:17] <robert_ancell> pitti, actually, I'm just using apt-get source myself at the moment as that seems to be the most reliable method
[04:17] <robert_ancell> so I don't mind
[04:18] <robert_ancell> tjaalton, ok cool, just noticed it in http://people.canonical.com/~platform/desktop/desktop.html and was checking if you guys knew about it
[04:20] <tjaalton> yeah, it has features I need for debugging, so would be nice to have
[04:22] <robert_ancell> tjaalton, I opened a tracking bug on it
[04:22] <robert_ancell> bug 1046145
[04:22] <ubot2`> Launchpad bug 1046145 in intel-gpu-tools "Update to 1.3" [Wishlist,Triaged] https://launchpad.net/bugs/1046145
[04:24] <pitti> robert_ancell: for https://bugs.launchpad.net/bake/+bug/1032062, I'm fine with making the series part of the library name, and avoid separate series arguments
[04:24] <ubot2`> Ubuntu bug 1032062 in bake "No way to specify .gir namespace version" [Medium,Triaged]
[04:24] <robert_ancell> pitti, ok cool
[04:24] <pitti> robert_ancell: but right now you'd end up with UMockDev-1.0-0.gir
[04:25] <pitti> robert_ancell: i. e. there is no way to drop the soname suffix from the .gir (and .pc, etc.)
[04:27] <robert_ancell> pitti, shouldn't it be UMockDev-1-0 instead? i.e. do you need a two level version number for the series? (it looks odd how we have libsoup2.4-dev for example)
[04:27] <robert_ancell> pitti, or do you plan on making UMockDev 1.0, 1.1, 1.2 etc that are parallel installable?
[04:28] <pitti> if 1.0 is the series, I mean, not the version
[04:28] <pitti> like Gtk-2.0.typelib vs. Gtk-3.0.typelib
[04:29] <robert_ancell> pitti, right, so in the Gtk-2.0.typelib example the series is 2 and the version is 0 really. i.e. you can have multiple series installed but not more than one version in a particular series
[04:29] <pitti> you can't even import a typelib which is named Foo-1.0-2.typelib
[04:30] <robert_ancell> pitti, in your UMockDev case you might want an "unversioned" GIR. i.e. UMockDev-1.0.gir (i.e. no version number)
[04:30] <robert_ancell> pitti, yeah, they impose a strict versioning scheme
[04:31] <pitti> robert_ancell: correct; as pretty much in all other projects
[04:31] <pitti> we don't want the soname in the typelib or pkg-config file name
[04:31] <robert_ancell> pitti, so I see it the other way around. It's not a soname but the "version of this library". The soname is derived from the version not the other way around
[04:32] <pitti> how do you do that? derive the soname, I mean?
[04:32] <pitti> because in general you can't
[04:32] <pitti> it's just a social agreement that within a series, GTK never breaks ABI
[04:32] <robert_ancell> pitti, so bake by default just uses the library version as the soname
[04:32] <tjaalton> robert_ancell: thanks
[04:33] <robert_ancell> pitti, and the idea is that you only increase the version number when you make incompatible changes
[04:34] <pitti> how do you ever relase a new version without ABI changes then?
[04:34] <pitti> the tarball woudl be exactly the same then?
[04:35] <robert_ancell> pitti, the library version is separate to the project version
[04:35] <pitti> ah, ok
[04:37] <robert_ancell> pitti, so in the case of GIR we need a camel case name anyway. So you should provide that, i.e. library.foo.girname = UMockDev
[04:38] <pitti> ah, there is a .girname? I didn't know that
[04:38] <robert_ancell> then we can use the library name -> UMockDev-1.0 where the 1 comes from the library.foo.version and the .0 is added to keep GIR happy
[04:38] <pitti> robert_ancell: I used libraries|umockdev|namespace = UMockDev
[04:38] <robert_ancell> pitti, we don't have one yet I don't think but in general you should be able to override the defaults that bake picks
[04:39] <robert_ancell> I think you've shown in this case Bake really can't pick a good name
[04:39] <robert_ancell> yeah, that should do it
[04:39] <pitti> robert_ancell: isn't |namespace what you mean with "girname"?
[04:39] <pitti> so perhaps what I want is
[04:39] <robert_ancell> pitti, yes, probably. I can't remember the exact variable names at the moment
[04:39] <pitti> libraries|umockdev|version = ''
[04:39] <pitti> libraries|umockdev|namespace = UMockDev-1.0
[04:40] <pitti> hm, I guess that would put the wrong name into the .gir
[04:40] <robert_ancell> pitti, no I think you want:
[04:40] <robert_ancell> libraries|umockdev|version = 1
[04:40] <robert_ancell> libraries|umockdev|namespace = UMockDev
[04:40] <robert_ancell> sorry, correction:
[04:40] <robert_ancell> libraries|umockdev-1.0|version = 0
[04:41] <robert_ancell> libraries|umockdev-1.0|namespace = UMockDev
[04:41] <robert_ancell> That should make libumockdev-1.0.so.0 and UMockDev-0.0.typelib
[04:42] <robert_ancell> though the convention is to call it something like umockdev-1.0 I think it would be clearer if we stuck to umockdev1 but either should work just as well
[04:44] <pitti> hm, why does my old recipe not work any more..
[04:44] <pitti> No package 'assertions' found (from vala)
[04:47] <pitti> robert_ancell: so, for umockdev I actually don't want to support multiple series, i. e. it should be libumockdev.so.0; so I guess I'll just settle to UMockDev-0.gir for now, it doesn't matter that much
[04:48] <pitti> except that the name would change with soname bumps, but I guess that's not too bad
[04:48] <pitti> it seems to break the versioning convention for all other .girs, though
[04:53] <robert_ancell> pitti, shouldn't it do that? i.e. UMockDev-1.0.typelib won't be compatible with libumockdev.so.2?
[04:54] <pitti> I guess that's a grey area for gir versioning :/
[04:54] <pitti> in general, the .typelib woudl be rebuilt against the new .so, so it will work
[04:54] <pitti> you just need strict dependencies between a gir-.. and the corresponding lib... package (but that's a good idea anyway)
[05:22] <didrocks> good morning
[05:22] <micahg> hi didrocks
[05:22] <didrocks> hey micahg
[05:23] <pitti> bonjour didrocks! comment vas-tu et tes vacances?
[05:23] <micahg> didrocks: is session-migration something that's backportable to precise (in -backports)?
[05:24] <didrocks> pitti: guten morgen! ça va très bien! the holidays were really great, sunny, refreshing, some nice landscapes and slow 3G connexion. Everything to be relaxed :)
[05:24] <didrocks> pitti: how was work for you? quiet, nothing to scarying for feature freeze? :)
[05:25] <didrocks> micahg: sure, it can be backported if someone wants to do it
[05:25] <pitti> didrocks: sonne bien!
[05:25] <micahg> didrocks: I mean as a no change backport :), will the quantal version break apps using it on precise
[05:26] <pitti> didrocks: I tried to stay away from teh FF madness; j'ai écrit les tests pour gvfs
[05:26] <didrocks> micahg: I think it can be a no change backport, someone needs to check, but I see nothing preventing that
[05:26] <micahg> didrocks: ok, will run some tests then, thanks!
[05:26] <didrocks> micahg: yw :)
[05:26] <didrocks> pitti: héhé, je pense que c'était la bonne stratégie (de rester loin de la folie de la FF)
[05:29] <didrocks> ok, let's read the bazillon backlogs email now :)
[05:38] <Mirv> certainly there was no hurry at all, everything landed on time for Feature Freeze and no panic was involved... noooot :)
[05:40] <didrocks> Mirv: as usual, isn't it? everything's on time :)
[05:42] <smspillaz> didrocks: !!!!!
[05:42] <smspillaz> how goes ?
[05:42] <didrocks> smspillaz: I'm good, thanks! (well less good when I see the numbers of emails I have to read :p), yourself?
[05:43] <smspillaz> okay okay, a little sick but that doesn't stop me :P
[05:44] <didrocks> oh? cold?
[06:11] <jasoncwarner_> didrocks is back :)
[06:11] <didrocks> hey jasoncwarner_!
[06:11] <jasoncwarner_> hey didrocks , how was the holiday?
[06:12] <didrocks> jasoncwarner_: they were excellent! nice weather, a lot of walk/visit of historical parts of France, and bad 3G connexion -> everything to really enjoy them, offline :)
[06:13] <didrocks> now checking the bazillon of backlog emails
[06:13] <jasoncwarner_> historical sites in france? Like "this is the place the germans took us over" and "this is the place where the english took us over"? ;)
[06:13] <didrocks> seems some people worked during my vacations :-)
[06:13] <jasoncwarner_> j/k ;)
[06:13] <didrocks> jasoncwarner_: tsssss :p
[06:14] <jasoncwarner_> didrocks: I can imagine you have many emails and many mailing lists to catch up on!
[06:14] <didrocks> jasoncwarner_: no, I was rather near the alps and in the south ;)
[06:14] <didrocks> yeah, I like that you noticed that I'm back thanks to emails answer :)
[06:30] <pitti> hey jasoncwarner_
[06:41] <jasoncwarner_> hey pitti :)
[07:25] <pitti> mvo: finally reviewed https://code.launchpad.net/~mvo/aptdaemon/support-change-credentials-on-add-repo/+merge/112098; sorry for the delay!
[07:27] <e11bits> Anyone knows why seahorse is asking for a passphrase everytime I log in? And it creates a new login_x entry every time. see http://tinyurl.com/bnnxqpd
[07:28] <e11bits> The problem might be, that my home directory is located on a network drive under AFS?!
[07:30] <didrocks> ogra_: come on, did they really uploaded the "foo" change for arch I staged?
[07:34] <didrocks> ok, logging out and back in soonish, if my upgrade worked… :)
[07:42] <pitti> and so the "failing glib tests fail the build" indeed discovered a big-endian specific bug
[07:47] <didrocks> sil2100: if I change some keys on g-c-c, I see no change on unity/compiz (like alt + F2), is it only me?
[07:51] <sil2100> didrocks: strange, for me it works
[07:51] <sil2100> didrocks: on a guest session I just tested that
[07:51] <sil2100> (since my main session is such a mess that I try not to test anything on it)
[07:52] <didrocks> hum, interesting, let me try a guest session
[07:52] <mvo> pitti: cool, thanks a bunch, I will address the points next
[07:53] <pitti> mvo: sorry for being annoying :)
[07:53] <mvo> pitti: just the contrary, I'm very thankful for a careful review
[07:54] <didrocks> sil2100: doesn't work here. Are you sure you are changing unity settings?
[07:54] <mvo> pitti: it means the end result will be (much) better which is great
[07:54] <didrocks> sil2100: like, shorcut: systems -> run a command -> change to alt + F3
[07:54] <didrocks> and try alt + F3, still alt + F2 works for me
[07:55] <didrocks> also, it's written "disable" first instead of alt + F2, so the integrated keys are not prepopulated
[07:55] <didrocks> smspillaz: ^
[07:55] <sil2100> didrocks: one moment
[07:55] <pitti> Où est Monsieur Bacher aujourd'hui?
[07:57] <didrocks> sleeping! slacker :)
[07:57] <smspillaz> didrocks: file a bug, tag it gsettings
[07:57] <didrocks> smspillaz: getting it to be confirmed first :)
[07:57] <smspillaz> I don't usually have a long term memory of irc
[07:57] <smspillaz> :)
[07:57] <didrocks> sure :)
[07:58] <didrocks> just a little bit puzzled because this was explicitely on what I asked the integration team to test before uploading :)
[07:58] <didrocks> jasoncwarner_: FYI ^
[07:59] <sil2100> hm
[07:59] <smspillaz> better to deal with small things like this after uploading rather than go through the whole FFe process tbh
[07:59] <sil2100> Ok, changing unity keybinding really doesn't work
[07:59] <didrocks> smspillaz: well, I don't agree, if we don't want to break ubuntu, we need to be sure we won't
[07:59] <didrocks> ok, I'm opening a bug
[08:00] <jasoncwarner_> smspillaz: acceptance criteria says otherwise. we are explicit: do not break ubuntu. Ubuntu is no longer for testing. that has to be done before it comes to distro otherwise it will get kicked back. We are pretty clear on this.
[08:00] <didrocks> sil2100: all is disabled, so I guess "TESTING THE MIGRATION:" in bug #1035261 wasn't done?
[08:00] <ubot2> Launchpad bug 1035261 in compiz "Port compiz to gsettings and consequently remove unity-2d" [High,Confirmed] https://launchpad.net/bugs/1035261
[08:00] <didrocks> sil2100: because it's all the compiz keys shortcuts which are broken
[08:01] <smspillaz> didrocks: can you check if changing the key in dconf-editor works the way you'd expect ?
[08:01] <didrocks> smspillaz: it changes the key in dconf-editor
[08:01] <sil2100> didrocks: wait, this I remember was being tested
[08:01] <didrocks> but only the integrated one
[08:01] <pitti> well, to be fair the current unity already has some regressions, so we didn't really do that "revert on regressions" here
[08:02] <didrocks> sil2100: well, seems not, I have all compiz/unity keys "disabled"
[08:02] <jasoncwarner_> pitti: you're right, we made some exceptions and I kinda regret that now... :/
[08:02] <smspillaz> didrocks: what happens if you change the key directly in dconf-editor
[08:02] <sil2100> didrocks: now this is strage, since I remember even seb128 doing tests with the migrations
[08:02] <didrocks> smspillaz: same thing
[08:02] <pitti> jasoncwarner_: well, to be fair some corner case bugs just are not found pre-upload
[08:03] <sil2100> didrocks: we didn't check unity keybindings probably, but migrations were tested
[08:03] <didrocks> yeah, but this one was explicit on a bug :)
[08:03] <jasoncwarner_> pitti: I'm quite ok with those, it's the obvious ones ;)
[08:03] <pitti> compiz still goes mad in some cases, but as long as it works well enough to not block everyone's work, it's probably bearable for some time
[08:03] <sil2100> Mirv: right? ^
[08:03] <smspillaz> didrocks: hmmm is it just that one or are there other keys too ?
[08:03] <pitti> *cough* resizing with alt and mouse drag *cough*
[08:04] <smspillaz> pitti: that was fixed yesterday :)
[08:04] <didrocks> smspillaz: I tested 4 compiz/unity keys
[08:04] <didrocks> the ones part of the integration
[08:04] <pitti> smspillaz: nice!
[08:04] <smspillaz> didrocks: okay, hang on a minute then
[08:04] <sil2100> didrocks: did the migration script run for you at all?
[08:04] <pitti> smspillaz: I'm still getting the weird gsettings and auto-raise mess; sometimes it happens at startup, sometimes not; race conditions FTW
[08:05] <smspillaz> pitti: I haven't really had time to look at that sorry
[08:05] <sil2100> didrocks: how old is your .local/share/gsettings-data-convert file?
[08:05] <smspillaz> pitti: been busy writing tests for an existing fix and I'm also quite sick and have 5 uni assignments due this week
[08:05] <pitti> smspillaz: no worries; I tried to find a pattern there, but it's not an obvious one
[08:05] <smspillaz> :)
[08:05] <sil2100> Maybe gsettings-data-convert saw .local/share/gsettings-data-convert already existing and didn't do the conversion at all?
[08:05] <pitti> smspillaz: uh, get well soon then!
[08:05] <didrocks> sil2100: I upgraded this morning
[08:05] <didrocks> sil2100: I didn't run the convert before
[08:06] <sil2100> didrocks: but you were testing migrations with me a while ago, so you probably had the gsettings-data-convert leftover since then
[08:06] <didrocks> sil2100: but you don't have "disabled" in a guest session as well?
[08:06] <didrocks> sil2100: look at g-c-c, the conversions are working, but they are not reflected in the integrated keys
[08:06] <smspillaz> oh okay hang on
[08:07] <didrocks> so the conversions per says, works, what doesn't work is that they are not copied to the "integrated" keys
[08:07] <sil2100> hm hm
[08:07] <didrocks> which are additional gsettings keys
[08:07] <smspillaz> is the issue here that we convert the old gconf keys to the gnome keys and that doesn't get updated in the integrated keys ?
[08:07] <sil2100> smspillaz: ^
[08:07] <sil2100> Mirv: ^
[08:07] <didrocks> smspillaz: exactly
[08:07] <smspillaz> right that makes a little more sense
[08:07] <didrocks> smspillaz: same in a guest session
[08:07] <didrocks> the profiles keys are correct
[08:07] <smspillaz> sil2100: didrocks: can we make the migration script copy the compiz values to the integrated keys ?
[08:07] <didrocks> but not copied to the integrated keys
[08:07] <didrocks> smspillaz: that won't solve the guest session issue
[08:08] <smspillaz> didrocks: why not ?
[08:08] <didrocks> it's a fresh profile, there is no migration
[08:08] <didrocks> so having keys in one profile
[08:08] <didrocks> and starting it
[08:08] <didrocks> should copy the keys to the integration scheme
[08:08] <smspillaz> and what, updating anything in org.compiz.integrated doesn't get updated in the relevant compiz keys ?
[08:08] <sil2100> smspillaz: you would have to consult Mirv probably, as he was the one working on compiz
[08:08] <didrocks> sil2100: yeah, seems that's the second bug I notice :/
[08:08] <didrocks> smspillaz: ^
[08:08] <smspillaz> didrocks: it seems to me in that case, there are two bugs
[08:09] <didrocks> smspillaz: agreed
[08:09]  * sil2100 doesn't have much knowledge about the org.compiz.integrated mechanism
[08:09] <sil2100> Mirv: ^^
[08:09] <smspillaz> didrocks: the first is that for anything in org.compiz.integrated, we aren't copying from the relevant gnome gconf value to the org.compiz.integrated keys
[08:09] <didrocks> I wonder how testing those would work as it was an explicit test case I've written before my holidays to avoid getting this regression
[08:09] <smspillaz> didrocks: and the second is that the defaults for org.compiz.integrated are not the same as thye used to be in gnome
[08:09] <didrocks> smspillaz: agreed
[08:09] <didrocks> hum
[08:09] <didrocks> defaults
[08:10] <didrocks> define the set of defaults twice is suboptimal
[08:10] <didrocks> the integrated thing is a compiz implementation detail
[08:10] <smspillaz> didrocks: right, its going to look at the values for org.compiz.integrated first
[08:10] <didrocks> compiz should handle it if there is no value
[08:10] <didrocks> not setting the same default twice
[08:10] <smspillaz> didrocks: gsettings doesn't have a concept of "no value"
[08:10] <didrocks> so, how to fix it?
[08:10] <Mirv> sil2100: mostly seb was testing those, and then I tested when seb told me how to test migrations manually
[08:10] <smspillaz> didrocks: change the default value in org.compiz.integrated
[08:10] <smspillaz> that's all
[08:11] <smspillaz> didrocks: can you split your bugs into two ?
[08:12] <didrocks> smspillaz: I don't like duplicating those twice
[08:12] <smspillaz> didrocks: the other solutions are very nontrivial
[08:12] <didrocks> smspillaz: what for the gnome ubuntu session and people starting another session at first?
[08:12] <didrocks> smspillaz: which are showing invalid keys then
[08:12] <didrocks> copying the default values is really a hack :/
[08:13] <pitti> là, un seb128!
[08:13] <smspillaz> didrocks: I don't think this is really an issue with org.compiz.integrated . The default values for both sessions are going to be the same
[08:13] <didrocks> smspillaz: as long as we control the session right
[08:13] <smspillaz> didrocks: the real quesiton is, we want it to prefer whatever is in the integrated keys right
[08:13] <didrocks> smspillaz: not nice to the gnome classic session if they choose something else
[08:14] <didrocks> seems again a bad hackish workaround for a structural issue
[08:14] <seb128> pitti, salut, ca va ?
[08:14] <smspillaz> didrocks: yeah but gsettings doesn't really have a mechanism for "determining if a value is empty"
[08:14] <smspillaz> a key is either at its default state or in another state
[08:14] <didrocks> yeah, I'm just a little bit not thrilled and wonder how this was tested beforehand
[08:14] <pitti> seb128: je vais bien, merci! seems my cold is mostly gone now
[08:15] <didrocks> sil2100: what to set the default keys for those as well and handling the new migration then? please ^
[08:15] <didrocks> salut seb128!
[08:15] <smspillaz> didrocks: right now that doesn't really matter. I'll get a merge up to change the defaults
[08:16] <didrocks> smspillaz: thanks
[08:16] <didrocks> smspillaz: and the second bug, why changing the .integrated keys doesn't change the profile ones?
[08:16] <didrocks> any idea on that?
[08:16] <seb128> pitti, great ;-)
[08:17] <seb128> didrocks, salut, wb, already in full action I can see :p
[08:17] <didrocks> seb128: heh, indeed, none stop! Thanks :)
[08:18] <sil2100> didrocks: sorry about that, when I got back and was testing migrations, I only tested if unity settings are migrated, and if changing keybindings in g-c-c works - didn't really pay attention to the fact that unity keybindings are different than others, so I just tested non-unity ones
[08:18] <smspillaz> didrocks: hang on, so are you saying that updating any of the keys in org.compiz.integrated doesn't update the profile ones ?
[08:19] <sil2100> smspillaz: it seems changing unity keybindings in g-c-c doesn't reflect in them being changed at all
[08:19] <Mirv> the tests I run were gsettings-data-convert manually for the compiz keys, and eventually after a couple of fixes it seemed smooth. but I didn't have an idea that it might not be the complete picture
[08:19] <didrocks> sil2100: that's why I wrote "launcher" in the test case
[08:19] <didrocks> well, let's move on
[08:20] <didrocks> sil2100: bug #1046190 is for you, I tried to be clear
[08:20] <ubot2> Launchpad bug 1046190 in unity "Migration to gsettings doesn't migrate compiz/unity configurable keys to g-c-c and those keys doesn't work" [High,Triaged] https://launchpad.net/bugs/1046190
[08:20] <didrocks> please split it between you and Mirv :)
[08:20] <didrocks> now the other bug for smspillaz :)
[08:20] <didrocks> smspillaz: seems so
[08:20] <didrocks> smspillaz: this is bug #2
[08:20] <smspillaz> okay so just to be clear, I'm updating the default values in org.compiz.integrated - correct ?
[08:21] <didrocks> smspillaz: yeah, but some values are distro-patched no? you don't want them upstream?
[08:21] <smspillaz> I'm pretty sure none of the values in that schema are distro patched
[08:21] <didrocks> ok, we need the unity HUD one as well
[08:22] <didrocks> which is in the unity source
[08:22] <didrocks> so yeah, that will fix the first point of bug #1046190
[08:22] <ubot2> Launchpad bug 1046190 in unity "Migration to gsettings doesn't migrate compiz/unity configurable keys to g-c-c and those keys doesn't work" [High,Triaged] https://launchpad.net/bugs/1046190
[08:22] <didrocks> the second is on sil2100/Mirv's hand for the migration
[08:22] <didrocks> and then, let's discuss about the second bug: changing a key in the schema doesn't change the handling in compiz
[08:29] <didrocks> smspillaz: bug #1046199 FYI
[08:29] <ubot2> Launchpad bug 1046199 in unity-distro-priority "Changing a key to org.compiz.integrated schema doesn't impact the current profile" [Undecided,Fix committed] https://launchpad.net/bugs/1046199
[08:31] <smspillaz> didrocks: I can't confirm that
[08:31] <didrocks> hum
[08:31] <didrocks> sil2100: can you try ^
[08:31] <smspillaz> didrocks: is integration enabled on your profile ?>
[08:31] <smspillaz> I just changed panel-main-menu and it works fine
[08:32] <didrocks> smspillaz: how do I have now compiz showing which backend is used?
[08:32] <didrocks> I don't have it in .xsession-errors
[08:32] <smspillaz> didrocks: ccsm will tell you which backend its using
[08:32] <smspillaz> compizconfig - Info: Backend     : gsettings
[08:32] <smspillaz> compizconfig - Info: Integration : true
[08:32] <smspillaz> compizconfig - Info: Profile     : unity
[08:33] <didrocks> smspillaz: gsettings
[08:33] <didrocks> so
[08:33] <didrocks> org.compiz.integrated
[08:33] <didrocks> panel-run-dialog
[08:34] <didrocks>  ['<Alt>F3']
[08:34] <didrocks> still Alt F2 here
[08:34] <sil2100> didrocks: when I log into a guest session, my 'System' keybindings are not all Disabled
[08:34] <sil2100> I actually have 2 keys set there
[08:35] <didrocks> sil2100: which ones?
[08:35] <sil2100> didrocks: but I can confirm the second bug
[08:35] <didrocks> sil2100: ah, but is Systems translated?
[08:35] <didrocks> like, I have here:
[08:35] <sil2100> didrocks: I have logout and lock screen
[08:35] <didrocks> Systems (which is the compiz untranslated one as it's new strings)
[08:35] <didrocks> and Systèmes
[08:35] <didrocks> which is translated
[08:35] <sil2100> Ah, hm, wait
[08:35] <didrocks> and have logout and lock screen
[08:36] <didrocks> but that's not linked to compiz/unity integrated keys at all
[08:36] <smspillaz> didrocks: alt-f3 works fine here
[08:36] <smspillaz> I can confirm that show-hud doesn't work though
[08:36] <smspillaz> but it isn't being marked as integrated anyways
[08:37] <didrocks> can we get anyone else confirming it works/doesn't work? ^
[08:37] <smspillaz> didrocks: does it say integration: true when you start ccsm ?
[08:37] <didrocks> compizconfig - Info: Integration : true
[08:37] <didrocks> yep
[08:40] <didrocks> gsettings set org.compiz.integrated panel-run-dialog "['<Alt>F3']"
[08:41] <thumper> hi didrocks, seb128
[08:41] <didrocks> sil2100: seb128: do you have to use alt+F2 or Alt + F3 to show the run a command panel? ^
[08:41] <didrocks> (after running that)
[08:41] <didrocks> hey thumper :)
[08:41] <thumper> didrocks: how was your break?
[08:41] <seb128> thumper, hey, how are you?
[08:41] <sil2100> didrocks: one moment!
[08:42] <thumper> seb128: relieved that you managed to land everything into Q
[08:43] <thumper> seb128: now looking to mop up the bugs I guess
[08:43] <didrocks> thumper: was excellent! frightened by reading omgubuntu and seeing all the change landing after FF in quantal, but the poor 3G connexion enabled me to follow that from very far :)
[08:43] <sil2100> didrocks: negative
[08:43] <didrocks> thumper: how was it for yourself? feeling like sprinting a marathon?
[08:43] <didrocks> sil2100: negative, like doesn't work? the key doesn't change?
[08:43] <thumper> didrocks: feeling more like a headless chicken
[08:44] <sil2100> didrocks: it doesn't work... Alt+F3 does nothing
[08:44] <thumper> do you fellas know anything about getting quantal VMs working?
[08:44] <sil2100> didrocks: it still reacts only to Alt+f2
[08:44] <thumper> I don't want to damage my new laptop by having quantal as the default
[08:44] <thumper> I'd like precise for now :)
[08:44] <thumper> and it is big and powerful enough to run multiple VMs
[08:45] <thumper> so I'd like to be able to take advantage of snapshotting and blowing away broken ones
[08:45] <didrocks> smspillaz: sil2100 confirms ^
[08:45] <sil2100> thumper: is quantal runable on VMs right now btw.? ;)
[08:45] <thumper> currently using virtual box
[08:45] <thumper> sil2100: I have quantal in VB
[08:45] <seb128> sil2100, it is but slow on some stuff
[08:45] <sil2100> thumper: hello btw.!
[08:45] <thumper> sil2100: but can't get it into full screen mode
[08:45] <seb128> especially animations
[08:45] <thumper> stuck as 1024x768 with black borders
[08:45] <thumper> animations are slowish
[08:46] <sil2100> seb128: hm, good that it works at all, since I remember not having quantal working on VB at all
[08:46] <thumper> and mouse jumps around
[08:46] <sil2100> Ok, now that sucks
[08:46] <thumper> but I think the mouse issue isn't us, but virtualbox
[08:46] <sil2100> thumper: with the guest installed?
[08:46] <smspillaz> didrocks: sil2100: hmm, I am running lp:compiz
[08:46] <thumper> tried to install guest bits
[08:46] <smspillaz> sil2100: are you able to confirm this happens on lp:compiz ?
[08:46] <thumper> but I think their guest bits won't work with the 3.5 kernel
[08:46] <didrocks> sil2100: can you work with smspillaz on that one? bug #1046199 FYI
[08:46] <ubot2> Launchpad bug 1046199 in unity-distro-priority "Changing a key to org.compiz.integrated schema doesn't impact the current profile" [Undecided,Fix committed] https://launchpad.net/bugs/1046199
[08:46] <didrocks> sil2100: those two bugs are the ones I notice for gsettings
[08:47]  * didrocks goes back catching up on emails
[08:47] <sil2100> didrocks: aye!
[08:47] <didrocks> thanks :)
[08:48] <sil2100> smspillaz: I'll try compiz from staging and see how it goes
[08:49] <thumper> bugger
[08:49] <Mirv> hmm, I can change Launchers -> "Launch terminal" to ctrl+alt+u and it changes. however, this is under the translated launchers submenu, while there is untranslated "Launchers" (in English) as well which has Launch terminal and HUD, and those don't work
[08:49] <thumper> still have issues with gm45 intel driver on quantal
[08:49] <thumper> infinite loop in the kernel driver when opening the dash the first time
[08:50] <Mirv> on 0.9.8.0, upgrading to staging now
[08:51] <smspillaz> thumper: I believe this is fixed by disabling coverview for those drivers
[08:51] <didrocks> Mirv: the untranslated are the compiz ones
[08:51] <thumper> smspillaz: seriously?
[08:52] <thumper> smspillaz: what are they doing that is so weird?
[08:52] <smspillaz> thumper: broken glsl support
[08:53] <smspillaz> something like that
[08:53] <thumper> well last week, it was fine perhaps one time in three
[08:53] <thumper> now I can't get unity to stay up at all
[08:53] <thumper> always have to restart lightdm
[08:55] <thumper> smspillaz: ok, must be something more stupid than that
[08:55] <thumper> smspillaz: when I first log in, compiz crashes somewhere, restarts and crashes again
[08:55] <thumper> smspillaz: if I then gdb compiz from vt1
[08:55] <thumper> smspillaz: it doesn't crash
[08:56] <thumper> solution: always run through gdb
[08:56] <smspillaz> yeah I don't know what it is
[08:56] <smspillaz> haven't had time to look into it
[08:56] <thumper> the question is why have issues when not in gdb?
[08:57] <thumper> screams of timing / threading sync issues
[08:57] <thumper> or something...
[08:58] <lifeless> does valgrind fix it too ?
[08:59] <Mirv> in compiz .convert files under [org.compiz.integrated] there is "exec = /apps/metacity/global_keybindings/run_command_terminal". should that be "run-command-terminal = ..."?
[09:00] <Mirv> the source for that is /usr/share/gnome-control-center/keybindings/50-compiz-launchers.xml, since I copied the .convert keys directly from the xml files
[09:00] <thumper> lifeless: not tried
[09:03] <smspillaz> Mirv: exec is correct
[09:03] <smspillaz> ahhhh
[09:03] <smspillaz> hang on
[09:03] <smspillaz> no, run-command-terminal in org.compiz.integrated is correct
[09:03] <smspillaz> exec is the command to run
[09:04] <smspillaz> I know, poorly descriptive name, blame the old code and my sed script
[09:06] <thumper> hmm... seems to be running under llvmpipe on the virtualbox quantal image
[09:06] <lifeless> thumper: I would give valgrind a go
[09:06] <didrocks> smspillaz: so HUD, and those are not integrated, right?
[09:07] <thumper> lifeless: looking for uninitialized reads?
[09:07] <chrisccoulson> gah, how difficult can it be to just downgrade compiz a few versions?
[09:07] <chrisccoulson> we really make it difficult
[09:08] <chrisccoulson> seems i need to uninstall pretty much my entire desktop
[09:09] <Mirv> smspillaz: ok so fixing that in both the .xml and .convert files should fix something at lesat
[09:09] <seb128> chrisccoulson, why do you want to downgrade?
[09:09] <seb128> chrisccoulson, well, the transition to gsettings and gles makes it difficult yes...
[09:09] <chrisccoulson> seb128, https://bugzilla.mozilla.org/show_bug.cgi?id=788170 (and various other painting issues in firefox since the compiz changes)
[09:09] <seb128> chrisccoulson, hey btw, how are you? got a stable internet with the new cable?
[09:09] <ubot2> Mozilla bug 788170 in Widget: Gtk "Doorhangers have a bar at the top" [Normal,New: ]
[09:10] <Mirv> is the second "Launch terminal" coming from /usr/share/gnome-control-center/keybindings/01-launchers.xml (gnome-control-center-data)?
[09:10] <chrisccoulson> seb128, yeah, i'm not too bad thanks. how are you?
[09:10] <chrisccoulson> my connections seems stable atm, but then, it hasn't rained for a few days ;)
[09:10] <seb128> chrisccoulson, I'm good thanks
[09:11] <seb128> chrisccoulson, could be bug #1042211
[09:11] <ubot2> Launchpad bug 1042211 in mesa "[quantal] [regression] [i915] Corrupted display, desktop and menus don't repaint correctly using Mesa 9.0 (8.0.4 works)" [Critical,Incomplete] https://launchpad.net/bugs/1042211
[09:11] <didrocks> Mirv: I think compiz should rather use that one than the .integrated one. smspillaz ?
[09:11] <seb128> chrisccoulson, apw wrote
  the damage i am seeing could easily be compiz as some of
[09:11] <seb128>  it is aligned well with the places it puts things
  bacground a solid colour, menus appear and return to men
[09:11] <seb128> u background
[09:12] <seb128> août 31 15:52:57 <tjaalton>     libgl1-mesa-glx, -dri should be enough
[09:12] <seb128> août 31 16:07:29 <apw>  needs -glapi as well for reference
[09:12] <seb128> août 31 16:08:43 <apw>  tjaalton, ok confirmed, downgrading those mesa packages fixes it here
[09:12] <seb128>  
[09:12] <seb128> chrisccoulson, ^ in case that's useful to you
[09:12] <chrisccoulson> seb128, ah, thanks
[09:15] <lifeless> thumper: also for whether it magically fixes it
[09:15] <lifeless> thumper: its less likely to do that than gdb
[09:17] <davidcalle> pitti, hello
[09:17] <pitti> hey davidcalle
[09:18] <davidcalle> pitti, how are you?
[09:18] <pitti> quite fine, thanks! yourself?
[09:19] <pitti> Laney, seb128: anything else for glib? the previous version uncovered a big-endian specific problem (-> ppc FTBFS), so I need another upload now
[09:19] <davidcalle> pitti, I'm good
[09:19] <seb128> pitti, not from me
[09:19] <Laney> hey, nothing here
[09:19] <davidcalle> pitti, I think I've spotted a pygobject regression with the new version in proposed
[09:20] <davidcalle> pitti, affecting libgdata gi overrides
[09:20] <pitti> d'accord, Je vais télécharger maintenant
[09:20] <seb128> pitti, ton français devient bon ! ;-)
[09:21] <pitti> davidcalle: oh? we have made some changes to allow overrides to be in different directories; that should actually make stuff work better; do you have some details?
[09:21] <pitti> seb128: merci! :-)
[09:22] <pitti> seb128: btw, I saw "télécharger" for "download" in my French desktop; is there a different word for "upload"? dictionary says both are the same
[09:22] <davidcalle> pitti, http://paste.ubuntu.com/1186998/
[09:23] <seb128> pitti, I think some people use "téléverser"
[09:23] <seb128> it feels weird though
[09:23] <seb128> it's not used a lot
[09:24] <davidcalle> seb128, a lot of things feel weird on the french desktop :)
[09:24] <pitti> seb128: isn't "vérser" like "pour" or "pay"?
[09:24] <pitti> "remote pouring", yummy
[09:24] <xnox> seb128: any pointers about bug 1046094 ?
[09:24] <ubot2> Launchpad bug 1046094 in ubiquity "Install RELEASE visible in the title bar. Missing API call to set unity menubar name?!" [Medium,Confirmed] https://launchpad.net/bugs/1046094
[09:25] <pitti> davidcalle: ah, so it does find the override?
[09:25] <pitti> davidcalle: can you confirm it's the new pygobject, and not g-i or glib in quantal-proposed?
[09:27] <seb128> pitti, yeah, verser is used for "pour" or "pay", it has a connotation of "transfert some content", which can be liquid, money or bytes ;-)
[09:27] <davidcalle> pitti, it imports the override, yes. Let me check
[09:30] <davidcalle> pitti, you are right, it's glib, I've reverted it to the previous version and everything works.
[09:34] <pitti> davidcalle: it's apparently due to http://git.gnome.org/browse/glib/commit/?id=7518f7a674723ded4cbb32d
[09:34] <pitti> so, deliberate
[09:39] <davidcalle> pitti, ok, looking at libgdata to see if that can be worked around.
[09:41] <jhernandez> xnox: IIRC, I think the title is being set in the frontends, using a function from misc
[09:41] <jhernandez> ;)
[09:41] <seb128> xnox, I don't understand that question
[09:41] <xnox> jhernandez: the titlebar on the window is correct. the title in the top left "unity" corner is wrong.
[09:41] <seb128> xnox, what is in the .desktop?
[09:41] <xnox> Name=Install RELEASE
[09:42] <seb128> xnox, there you go
[09:42] <xnox> how can I change it post-exec? =)
[09:42] <seb128> shouldn't RELEASE be replaced at build time in ubiquity by the actual release?
[09:42] <xnox> no
[09:42] <seb128> why not?
[09:42] <jhernandez> xnox: ok. sorry, I can't deal with it right now
[09:42] <xnox> because the same gtk ubiquity is used for: Ubuntu, Xubuntu, Ubuntu Studio.
[09:43] <xnox> so we want to set it per image. during cd building we change the shortcut name, as far as I can see.
[09:43] <xnox> Lubuntu as well.
[09:43] <xnox> and casper/wubi uses that for something as well....
[09:44] <xnox> seb128: is there no way to access that bit & change it? in bamf?
[09:44] <xnox> seb128: i am confused. it actually is fine now
[09:44] <xnox> with latest daily
[09:44] <xnox> well beta-1
[09:44] <seb128> xnox, is the .desktop still saying "Install RELEASE"?
[09:45] <xnox> no....
[09:45] <xnox> hmmm...
[09:45] <seb128> xnox, see :p
[09:46] <chrisccoulson> nice. little over a minute to download an ISO :)
[09:46]  * xnox goes to scratch my head why the heck it didn't work with dailies.....
[09:46] <seb128> chrisccoulson, it takes over a minute to copy an iso on my disk :p
[09:46] <pitti> chrisccoulson: is your shiny new line stable now?
[09:46] <chrisccoulson> pitti, i won't find out until it rains. but, i hope so :)
[09:47] <pitti> yeah, even with my current DSL speed, rsyncing an iso is a pain due to the ridiculous load that it causes due to the IO
[09:47] <seb128> chrisccoulson, btw did you try downgrading mesa? did it fix your issue?
[09:48] <chrisccoulson> seb128, yeah, i tried downgrading mesa. it didn't fix it :(
[09:48] <seb128> :-(
[09:48] <chrisccoulson> so now i'm in dependency hell to try and downgrade compiz
[09:48] <chrisccoulson> which is pretty much impossible
[09:48] <seb128> you need to downgrade the compiz, unity, bamf, etc stack
[09:48] <chrisccoulson> we make it really hard to bisect issues like this by splitting our shell across bazillions of source packages :(
[09:49] <seb128> it's not true, unity is self contained
[09:49] <seb128> the issue is that we migrated the keybindings to gsettings
[09:49] <seb128> which impact on control center, setting daemon, etc as well
[09:49] <chrisccoulson> i'm starting to wonder if it might be easier to start on precise, and upgrade bits from there
[09:50] <seb128> chrisccoulson, what will it tell you if downgraded compiz works?
[09:50] <chrisccoulson> it will tell me that something in compiz (or any of the other packages i have to downgrade) broke it, i guess
[09:51] <seb128> chrisccoulson, well, you can probably get the same info by trying under gnome-shell or gnome classic
[09:51] <seb128> if something is broken in compiz somebody will need to debug current compiz anyway
[09:51] <chrisccoulson> seb128, yeah, the guy who reported the upstream bug already tried that. the issue only happens in a unity session
[09:51] <seb128> does it happen in a gnome-classic with compiz?
[09:51] <seb128> or only unity?
[09:52] <chrisccoulson> good question
[09:52] <chrisccoulson> i'll try that in a moment
[09:56] <seb128> chrisccoulson, are you able to reproduce the issue? is that specific to f17?
[09:56] <chrisccoulson> seb128, yeah, it's quite trivially reproducible in all versions
[09:56] <chrisccoulson> 1 second, brb
[10:05] <chrisccoulson> hmmm, gnome classic is quite broken here :/
[10:05] <Oranger> I see that the upstream version of the banshee package is 2.50 but the ubuntu version is 2.4.1 , is it because this package have not to be upated or nobody still did it ?
[10:05] <chrisccoulson> i get compiz loaded, but it seems like it has no plugins
[10:07] <thumper> any chance someone is going to look at https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1045779 ?
[10:07] <ubot2> Launchpad bug 1045779 in virtualbox "virtualbox video driver doesn't load on quantal guests" [Undecided,Confirmed]
[10:07] <thumper> is this something we can fix, or is it virtualbox folks?
[10:07]  * thumper dumps and runs
[10:08] <Mirv> smspillaz: https://code.launchpad.net/~compiz-team/compiz/compiz.fix_1046199.2/+merge/122833 <- with these changes on top of yours, the compiz's Launch terminal becomes functional and also the show-hud default (Alt) is actually shown
[10:13] <didrocks> sil2100: do you think you can get both the migration and the compiz not integrated keys fixed by EOW?
[10:13] <didrocks> should be a couple of hours work…
[10:13] <seb128> chrisccoulson, I can't confirm that bug on my quantal ... how often is it supposed to happen?
[10:14] <chrisccoulson> seb128, it happens almost every time I start firefox for me (only the first time you open a doorhanger panel though)
[10:14] <seb128> I got a bug once on 25 tries
[10:14] <seb128> chrisccoulson, is that only those tooltips?
[10:15] <chrisccoulson> seb128, well, there is that. but i keep occasionally seeing random refresh issues too
[10:15] <seb128> chrisccoulson, if so is that really worth the efforts needed to debug it? it seems a pretty minor cosmetic 1 time glitch
[10:15] <seb128> hum
[10:15] <seb128> refresh issues are more annoying
[10:26] <davidcalle> pitti, after checking, this new glib breaks libgdata completely (Gdata services can't be created anymore), I'm filing a bug against libgdata, but could patching glib by reverting this commit be considered or not?
[10:27] <pitti> davidcalle: we must have a very very good reason to do so
[10:27] <pitti> we really do not want to change the upstream ABI, that's a disaster waiting to happen
[10:28] <pitti> davidcalle: but that has only been in glib for one release in quantal; curious that it is already used in libgdata
[10:31] <seb128> pitti, libgdata didn't get updated for over a month so I doubt it
[10:31] <seb128> pitti, it seems like glib has an incompatible change somewhere rather?
[10:32] <davidcalle> pitti, seb128, you are right. So, it's probably not this commit.
[10:32] <pitti> it was added in http://git.gnome.org/browse/glib/commit/?id=541c985 (August 6) and reverted in http://git.gnome.org/browse/glib/commit/?id=7518f7a67 (Aug 21)
[10:33] <seb128> https://launchpad.net/ubuntu/+source/libgdata
[10:33] <seb128> 0.13.1-0ubuntu2 	release (main) 	2012-07-30
[10:33] <pitti> hmm
[10:33] <seb128> so it's something else
[10:48] <sil2100> didrocks: yes
[10:51] <didrocks> thanks :)
[11:30] <smspillaz> Mirv: okay, good to hear
[12:57] <davidcalle> pitti, do you want a bug filed on this morning glib? Currently it breaks functionnalities in Shotwell (export to Picasa), Google Docs scope of the files lens, and maybe gnome-documents (Google Docs search) but I need a regular user to confirm, not sure if my setup is correct.
[12:57] <pitti> davidcalle: sure
[12:57] <pitti> thanks
[12:57] <davidcalle> (And Photos lens Picasa search)
[12:57] <davidcalle> Ok
[13:22] <Oranger> Sorry to break this very awesome silent but do all paquets contained in this page http://people.canonical.com/~platform/desktop/gnome.html must have to be updated ?
[13:22] <Oranger> *packets
[13:23] <Laney> (Just replied to that in #-motu)
[13:23] <Laney> Oranger: no need to cross post
[13:24] <Oranger> Laney: Hum, sorry I wasn't sure of the team releated to this
[13:24] <Laney> it's OK, this probably would have been a more appropriate channel anyway
[13:26] <Oranger> Laney: Ok thanks, because i see packet like banshee who apparently need to be updated but the upstream release in the debian branch is experimental
[13:27] <Laney> banshee is bug #1041245
[13:27] <ubot2> Launchpad bug 1041245 in banshee "[FFe] Banshee 2.5.0 ... 2.6.0" [Undecided,New] https://launchpad.net/bugs/1041245
[13:28] <Laney> I can't remember what the tag is to make versions show that
[13:28] <dobey> dpm: ping; can you approve my mail to ubuntu-translators?
[13:30] <Oranger> Laney: Ok so if I understand, banshee don't have to be updated before banshee leading up to 2.6.0 ?
[13:30] <dpm> dobey, approved, but the subject has left me wondering why you're trying to sell replica watches...
[13:31] <dobey> thanks
[13:31] <Laney> Oranger: That's a request from hyperair to update banshee to the beta in Quantal
[13:31] <Laney> then presumably to the other intermediate releases before the stable
[13:32] <Oranger> Laney: Ok thanks, because (like you can see) i'm new so I try to understand how it work
[13:33] <Laney> no worries
[13:33] <Oranger> Laney: And how can I help the ubuntu-desktop team just to start ?
[13:34]  * hyperair grumbles at the release team to ack the FFe
[13:34] <Laney> the release team is waiting for you to answer a question ;-)
[13:35] <Laney> Oranger: Well, it depends on what you want to do
[13:35] <hyperair> wat? there's a question?
[13:35] <Laney> if you like development then a good way to start is to find a bug that personally annoys you and see that it gets fixed
[13:35] <hyperair> whoop de doo.
[13:36] <Laney> otherwise there's translation, documentation, triage, support, …
[13:36] <smartboyhw> Or tetsing:)
[13:36] <smartboyhw> *Testing
[13:36] <Oranger> Laney: Ok, so i can try to fix a bug without any permissions or anything else ?
[13:36] <Laney> permissions just let you do things without asking others
[13:36] <Oranger> smartboyhw: I tried but my pc i too slow for testing in a virtual environment :p
[13:36] <Laney> lack of them shouldn't stop you doing work
[13:37] <smartboyhw> Oranger: Oh alright. I think documentation is the best. Support also
[13:37] <Oranger> Laney: Ok thanks :)
[13:37] <Oranger> smartboyhw: I'll try to fix bugs first and I'll see after ^^'
[13:37] <smartboyhw> ^^
[13:42] <mterry> tedg, you want to roll a new release of libpam-freerdp?
[13:42] <tedg> mterry, Yeah, I will.  Taking care of a sick kiddo this morning, so probably this afternoon.  Turns out 2 year olds hate packaging... kids these days.
[13:43] <mterry> tedg, oh noes, poor guy
[13:43] <mterry> or gal
[13:48] <tedg> mterry, Yeah, he's not too bad off really.  But his school requires him to stay home one day if he had a fever the previous day.  Makes sense, but if you met him today, you wouldn't be too worried.
[13:49] <mterry> tedg, oh weird.  I thought for stuff like that, you were contagious pre-symptoms instead of post-symptoms
[13:49] <tedg> mterry, You're confusing science with school policy ;-)
[13:49] <mterry> tedg, I guess it's hard to require them to stay home the day before a fever  :)
[13:51] <tedg> mterry, Heh, that too.  It's kinda to encourage parents to not send their kids to school sick, which I appreciate.  Just at this age fevers happen for all kinds of things (teething, etc.)
[14:14] <tedg> mterry, So we need this revision for our test suite, can we distro patch this in?  http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk/revision/1540
[14:14] <tedg> I don't think it's worth a full upstream release for just that.
[14:14] <mterry> tedg, sure, post Beta
[14:14] <tedg> of course
[14:14] <tedg> Cool, thanks
[14:22] <smspillaz> MCR1: hey are you planning to re-propose your branch that removes the VERSION cruft and fixes some of the build ?
[14:22] <smspillaz> (eg, removes the need for ccsm_wrapper etc)
[14:30] <seb128> pitti, hey, I assigned you bug #1046319, let me know if you prefer for somebody else to take on it though
[14:30] <ubot2> Launchpad bug 1046319 in glib2.0 "glib 2.33.12 crashes libgdata" [High,New] https://launchpad.net/bugs/1046319
[14:43] <MCR1> smspillaz: Sure, but Daniel said that "make install" produces errors with this branch and also asked me to split it into different parts, like you did already before...
[14:44] <MCR1> smspillaz: So my plan was to first get the other 2 new branches merged, before the VERSION fix.
[14:44] <MCR1> ...to make the diff smaller there...
[14:45] <MCR1> smspillaz: Just Jenkins does not like my plans ;)
[14:46] <smspillaz> MCR1: right, we will need to update the packaging
[14:47] <smspillaz> MCR1: could you make a merge proposal based on the changed from my branch ?
[14:47] <smspillaz> *changes
[14:47] <smspillaz> eg, the VERSION stuff + the fix for ccsm not installing + my branch
[14:47] <smspillaz> MCR1: btw, I like the replacing #define with constants, good idea
[14:47] <MCR1> smspillaz: I have to start with newbie stuff ;)
[14:48] <smspillaz> its a good change
[14:49] <smspillaz> MCR1: you probably noticed but we now have CI running on every branch too
[14:49] <MCR1> smspillaz: The branch is still there, I will re-set it to "Needs Review"
[14:49] <MCR1> CI ?
[14:50] <smspillaz> MCR1: great :)
[14:50] <smspillaz> MCR1: continuous integration
[14:51] <smspillaz> MCR1: it means we have a build bout that now automatically checks if things build, package correctly, test correctly, memory leak analysis, coverage reports per branch etc
[14:51] <smspillaz> *bot
[14:51] <MCR1> smspillaz: The other 2 new branches would need to get merged first, then I would rebase the minor-fixes branch, so it would just deal with the VERSION stuff
[14:51] <smspillaz> MCR1: +1
[14:51] <MCR1> smspillaz: Cool.
[14:51] <MCR1> I don't mind additional testing when it works (not like Jenkins lately ;))
[14:52] <MCR1> I could not set more than one prerequisite, that is why I changed the status to WIP
[14:52] <smspillaz> right
[14:54] <MCR1> My C++ advanced to professional books say #defines are evil C language and might have multiple problems I will not all list here, hope those books are correct
[15:55] <sabdfl> Sweetshark, new build of lo with built-in menus is a big improvement - thanks :)
[16:34] <mterry> seb128, I uploaded gcovr to quantal universe, if you have time to do a NEW review after it lands (ubuntu-release approved FFe)
[16:34] <mterry> seb128, (this is a tool the QA team uses)
[16:36] <seb128> mterry, ok
[16:37] <mterry> It's real small
[16:44] <seb128> mterry, since when size matters? :p
[16:44] <mterry> seb128, says the man that complained about larger wallpapers
[16:44] <dobey> hrmm. mterry and seb128, i have an interesting problem that maybe one or both of you could help provide an answer to
[16:45] <seb128> mterry, yeah, wth with that extra 1MB!
[16:45] <seb128> mterry, hum, is libfcitx-gclient0 something you know about?
[16:46] <seb128> mterry, I wanted to know where to reassign https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1046409
[16:46] <ubot2> seb128: Error: <Bugtracker.plugin.Launchpad instance at 0x9212c2c> bug 1046409 not found
[16:46] <seb128> dobey, hey, what's up?
[16:46] <mterry> seb128, no?  not a name I know
[16:47] <seb128> mterry, ok, I though it was maybe something thinclienty
[16:47] <seb128> mterry, the citx part of the name misleaded me
[16:47] <dobey> mterry, seb128: right now, we have some pieces of data that we ship in the various ubuntuone related projects, in duplicate. and some interesting dependencies where we don't duplicate. in an effort to move all that to a single place, and get rid of ubuntuone-installer going forward, i've created a project for our shared data and started moving some of it there. however, this is a new source which will need a free exception a
[16:47] <seb128> mterry, it's fcitx-libs, found it
[16:47] <seb128> fcitx
[16:48] <seb128> which is input method :p
[16:48] <seb128> dobey, IRC cut after "new source which will need a free exception a"
[16:49] <dobey> seb128: "need a free exception and MIR.  and some of the files will conflict with existing packages until  we get them all updated. so i'm wondering what the best way to  go about getting this in, and dealing with the file conflicts, is"
[16:49] <dobey> and i totally mistyped freeze there obviously
[16:50] <seb128> dobey, you need a FFe and MIR yes, open a bug listing what packages need a change
[16:51] <dobey> seb128: so list the packages that conflict in the bug as well?
[16:51] <mterry> dobey, MIR should be real simple, assuming all this stuff was already in main.  It would just need to be a packaging check
[16:52] <seb128> dobey, the best way to deal with the conflict is to make your new u1-data use a Replaces: u1 (<<), Breaks u1 (<<)
[16:52] <seb128> dobey, yeah, use a Replaces,Breaks on each binary it overwrite a file from
[16:53] <seb128> dobey, they you need all those stuff uploaded to quantal-proposed together
[16:53] <seb128> and then copied to quantal once built
[16:54] <dobey> seb128: ok; so get it in universe, and do the MIR and upload the fixed packages that do conflict to -proposed at the same time? or wait until it's approved for main?
[16:55] <seb128> dobey, wait until it's approved for main, but sounds like it should be trivial if it's a data package, mterry can help you to fastrack it
[16:56] <dobey> yeah, it should be trivial. i'm more worried about the conflicts issue, than the MIR itself :)
[16:57] <dobey> just want to minimize the window of opportunity for people to upgrade and then have all of ubuntuone disappear because of it
[17:00] <dupondje> gnome-shell is broken currently?
[17:00] <dupondje> GTls errors
[17:07] <seb128> dupondje, could be the quantal-proposed glib
[17:07] <seb128> dobey, well, that's why we use quantal-proposed as a staging, users should not have it enabled, and we copy everything at once
[17:07] <seb128> dobey, so normal users shouldn't have any "window of opportunity for people to upgrade and then have all of ubuntuone disappear"
[17:08] <dobey> seb128: right. that's understood. just want to make sure i get it right.
[17:09] <dobey> seb128: well, there will be some window still; as the -client-data package would be in universe at least; but yeah, it shouldn't show up in the default install until the other packages are fixed as well to depend on it instead
[17:10] <seb128> dobey, well, get the client-data MIR acked and the package proposed before the upload
[17:11] <dobey> seb128: yep. will get it done as soon as i can. working on this stuff now :)
[17:12] <dobey> seb128: thanks :)
[17:12] <seb128> dobey, yw
[17:12] <dupondje> http://paste.ubuntu.com/1187559/
[17:13] <dupondje> seems like its caused by glib indeed?
[17:13] <seb128> dupondje, https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1046319 I guess
[17:13] <ubot2> Launchpad bug 1046319 in glib2.0 "glib 2.33.12 crashes libgdata" [High,New]
[17:17] <tkamppeter> hi, I got a Google+ invitation from slangasek, about the Panda board. Who is supposed to have a Panda board and do I need to sign up to Google+ to participate in slangasek's meeting?
[17:17] <dupondje> seb128: guess it will be fixed asap :)
[17:18] <seb128> dupondje, I'm mentioning it on #gtk+
[17:22] <dupondje> aha packaging issue ;)
[17:23] <seb128> dupondje, not really
[17:24] <seb128> dupondje, out of sync issue, would have happened the same way with jhbuild or anything, you need to update one before the other one
[17:25] <dupondje> well if we had a depend/break on the correct versions?
[17:25] <dupondje> so glib doesn't get updated before the  correct version of glib-net is in repo's
[17:25] <dupondje> but well, not a big deal :)
[17:25] <seb128> dupondje, right, if they had mentioned the issue in the NEWS
[17:26] <dupondje> true :)
[17:50] <davidcalle> seb128, ping?
[17:50] <seb128> davidcalle, hey
[17:51] <davidcalle> seb128, I see you have changed the glib bug to glib-networking. For the record, the bug is present only when upgrading glib to 2.33.12.
[17:51] <seb128> davidcalle, yeah, it's due to a version mismatch between glib and glib-networking
[17:52] <seb128> davidcalle, they both need to be on .10 or .12
[17:52] <davidcalle> Oh I see
[17:52] <seb128> davidcalle, I'm about to uploaded glib-networking .12
[17:53] <davidcalle> seb128, cool!
[17:55] <dupondje> good service ;)
[18:17] <didrocks> good night everyone :)
[18:59] <davidcalle> seb128, that's fixed indeed, thanks!
[19:00] <seb128> davidcalle, yw, thanks for testing!
[19:00] <seb128> pitti, ^ it might be worth doing another glib upload with a Breaks on glib-networking << 2.33.12
[19:07] <MCR1> sil2100: Hi :) Is there some lock on Compiz/Unity or do you know why things do not land ?
[19:09] <MCR1> smspillaz: Ugly reading that Phoronix article :P - They should have made the benchmark before the GLES merge not immediately afterwards...
[19:11] <MCR1> smspillaz: https://code.launchpad.net/~mc-return/compiz/compiz.merge-replace-defines/+merge/122865 should be ready so far...
[19:13] <MCR1> smspillaz: I've left out converting stuff like ABI_VERSION and may have missed some - also for now I did replace just the #defines of short, int and string types...
[19:24] <sil2100> MCR1: erm, we have a compiz issue right now
[19:24] <sil2100> MCR1: which broke unity merges
[19:24] <MCR1> sil2100: oh
[19:25] <MCR1> sil2100: thx 4 the info - hope it is solved soon ;)
[19:25]  * MCR1 hopes that he has nothing to do with it...
[19:40] <ricotz> seb128, hi, i wouldnt say another glib upload is needed since it is only the combination of devel releases of glib 2.33.12 and glib-networking 2.33.10 which broke due a symbol removal
[19:41] <seb128> ricotz, well, slangasek had a good point, what prevents user to update glib without glib-networking?
[19:42] <mterry> seb128, do you mind if I add a patch for testing on top of your fix for gnome-settings-daemon in quantal-proposed?
[19:42] <dupondje> seb128: my gnome-shell is working again also :) thx
[19:42] <mterry> (didn't know if you wanted to test your fix in isolation or if that was just because of beta freeze)
[19:43] <ricotz> seb128, right, but these things happen all the time
[19:43] <seb128> mterry, go for it
[19:43] <ricotz> seb128, but yeah, to a sane upgrade path it would be needed, but inside a devel cycle it seems overkill
[19:43] <seb128> ricotz, they should not though, and I don't think "all the time" is true
[19:44] <ricotz> seb128, ok, happens to "git" releases afaics
[19:44] <seb128> dupondje, yw, I should have kept it broken a bit longer to let some people try unity ;-)
[19:45] <seb128> ricotz, yeah, there is a reason why we don't do git releases ;-)
[19:45] <dupondje> I use unity @ work, gnome-shell @ home :)
[19:45] <dupondje> good combo
[19:45] <seb128> mterry, it's because of the beta freeze, I noticed they accept quantal-proposed uploads so I figured I would upload there ;-)
[19:45] <seb128> dupondje, ;-)
[19:45] <ricotz> seb128, right ;), gstreamer 0.11.94 will do similar things
[19:46] <seb128> ricotz, I'm glad we didn't go for gstreamer0.11 this cycle :p
[19:46] <mterry> seb128, I uploaded a fix for that g-s-d crasher, but since I can't reproduce, I'd like confirmation.  I don't suppose you could reproduce?
[19:46] <seb128> GNOME has somewhat lost track of reality with stable releases
[19:46] <ricotz> seb128, but adding breaks everytime such things happen will clutter debian/control needlessly
[19:47] <seb128> mterry, no, but psivaa on #ubuntu-release can
[19:48] <ricotz> seb128, and will introduce a debian-difference since it isnt valid for debian
[19:48] <mterry> seb128, ah you mentioned that, right!
[19:48] <mterry> seb128, thanks
[19:48] <seb128> ricotz, you can drop the Breaks a week later, they are just to avoid buggy updates
[19:48] <seb128> mterry, yw
[19:48] <ricotz> seb128, alright ;)
[19:49] <seb128> ricotz, well, I don't plan to keep those transitional things longer than the transition, it's just that without those we have a 1 to 3 days timeframe where people just bug their installs with partial upgrades otherwise
[19:49] <ricotz> seb128, right
[19:49] <ricotz> seb128, did you look into the webkit amd64 failure?
[19:50] <seb128> ricotz, I tried but I'm out of ideas on what it could be, out of a toolchain limitation
[19:50] <ricotz> i was told fedora patched binutils to fix it
[19:51] <seb128> ricotz, I guess http://pkgs.fedoraproject.org/cgit/binutils.git/commit/?id=de3f00e4ec3c63b3328db9caad0d7ddec94a8afa ?
[19:52] <ricotz> i dont know what the specific patch is
[19:52] <seb128> ricotz, I opened https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1043507 about that patch but slangasek pointed it's supposed to be a 32bit fix and our version is supposed to have it
[19:52] <ubot2> Launchpad bug 1043507 in binutils "webkit build fails on binutils limitation" [Medium,New]
[19:52] <ricotz> but it seems to be a toolchain problem
[19:52] <seb128> could be http://pkgs.fedoraproject.org/cgit/binutils.git/commit/?id=45e2b47aa734f19aa70da7b15ae523767a527572
[19:54] <ricotz> i see, just wanted to pass you that hint, i wasnt looking into it
[19:55] <seb128> ricotz, thanks
[19:55] <seb128> ricotz, I've been trying to look into it but not that much into details, enough to open a bug and ping some people though ;-)
[19:58] <ricotz> ;)
[20:46] <seb128> mterry, still around?
[20:52] <seb128> mterry, being picky but
[20:52] <seb128> gcovr/__init__.py: UNKNOWN
[20:52] <seb128>   [Copyright: 2008 Sandia Corporation]
[20:52] <seb128> where
[20:52] <seb128> "Files: *
[20:52] <seb128> Copyright: 2008 William Hart <wehart@sandia.gov>
[20:52] <seb128>            2008 John Siirola <jdsiiro@sandia.gov>
[20:52] <seb128> "
[20:53] <seb128> mterry, not a NEW blocker but would be nice to fix by adding "Sandia Corporation" to the copyright in the next upload
[21:01] <mterry> seb128, hi
[21:01] <mterry> seb128, fair, though that file doesn't really have any copyrightable material in it  :)
[21:02] <seb128> mterry, scripts/gcovr does though :p
[21:02] <seb128> # Copyright (c) 2008 Sandia Corporation.
[21:03] <mterry> seb128, OK, you got me  :)
[21:03] <seb128> ;-)
[21:03] <seb128> mterry, honestly, you should know better than trying to play that game with me :p
[21:03] <seb128> mterry, NEWed ;-)
[21:03] <mterry> heh
[21:04] <mterry> seb128, thanks!
[21:04] <seb128> yw
[21:58] <robert_ancell> TheMuso, are you doing the atk1.0, at-spi2-atk, at-spi2-core updates?
[21:59] <robert_ancell> and mousetweaks
[22:00] <TheMuso> robert_ancell: Yes.
[22:00] <TheMuso> Hav just been catching up on email after eing off last week, and other bits.
[22:01] <robert_ancell> TheMuso, ok, if they take more than a day I'd like to open tracking bugs on them so they show up on http://people.canonical.com/~platform/desktop/desktop.html as being in progress
[22:02] <TheMuso> I should have all but at-spi2-atk done today. At-spi2-atk requires a change in unity that hasn't even been merged upstream yet, but a branch has been proposed.
[22:03] <robert_ancell> TheMuso, is there a bug open already?
[22:03] <TheMuso> Yes.
[22:04] <TheMuso> For unity if thats what you mean.
[22:04] <robert_ancell> TheMuso, what's the number?
[22:05] <TheMuso> sec.
[22:06] <TheMuso> robert_ancell: Bug https://code.launchpad.net/bugs/1023542
[22:06] <ubot2> Launchpad bug 1023542 in unity "[a11y] Unity and unity-panel a11y initialization need to be ported to atk-bridge library" [Undecided,In progress]
[22:06] <robert_ancell> TheMuso, if you don't mind I'll just open all the tracking bugs - it will be easier.
[22:06] <TheMuso> If you must.
[23:05] <thumper> jasoncwarner_: you around?
[23:06] <jasoncwarner_> thumper: yo