[07:22] <kvalo> morning
[07:59] <smspillaz> kvalo: morning!
[08:01] <kvalo> smspillaz: morning. how was australia day yesterdat?
[08:01] <kvalo> yesterday even
[08:09] <didrocks> good morning
[08:11] <smspillaz> kvalo: I didn't really get up to much suprisingly, and I missed the fireworks -_-
[08:11] <smspillaz> didrocks: morning!
[08:11] <didrocks> hey smspillaz! how are you?
[08:11] <smspillaz> didrocks: I have fixed the "wrong window positions bug", now working on the gconf bug
[08:11] <smspillaz> didrocks: feeling awesome as usual
[08:11] <kvalo> didrocks: morning
[08:11] <MacSlow> hey everybody!
[08:11] <didrocks> smspillaz: awesome!
[08:12] <kvalo> smspillaz: oh, missing fireworks sucks
[08:12] <kvalo> MacSlow: guten morgen
[08:12] <didrocks> smspillaz: I don't see that one in your email, am I stilll awake?
[08:12] <didrocks> even still*
[08:12] <didrocks> hey kvalo, MacSlow!
[08:12] <smspillaz> kvalo: yeah, I messed up the time (thought it was 9pm instead of 8pm)
[08:12] <MacSlow> kvalo, hyvää huomenta
[08:12] <MacSlow> :)
[08:12] <smspillaz> didrocks: I think I commented on your bug report with the patch
[08:13] <MacSlow> salut didrocks
[08:13] <kvalo> MacSlow: oh wow!
[08:13] <didrocks> smspillaz: excellent then, will get to it as well :)
[08:13] <smspillaz> guton morgen hyvaa huomenta bonjour bonjourno etc etc
[08:13] <MacSlow> kvalo, google translate... *cough* :)
[08:13] <smspillaz> *guten
[08:13] <MacSlow> kvalo, I would have no idea how to correctly pronouce that though :)
[08:13] <kvalo> MacSlow: next challenge, pronounce it correctly ;)
[08:14] <kvalo> MacSlow: about funny words, does "saippukauppias" sound funny to you?
[08:15] <smspillaz> didrocks: I was thinking though for bug 688816, we might need a new plugin to handle that case (since it needs to load before the place plugin)
[08:15] <MacSlow> kvalo, it certainly looks funny
[08:15] <didrocks> smspillaz: I can handle that one later, not for alpha2 though
[08:15] <didrocks> smspillaz: as you fix the wrong window position at start, it's fine :)
[08:16] <smspillaz> didrocks: ah ok, it would be like a ~100 line plugin
[08:16] <kvalo> MacSlow: I think I need to list you some funny words and we can go through them over beer
[08:16] <didrocks> smspillaz: yeah, I'll do it, I think I got what is needed
[08:16] <smspillaz> I could do that in like 10 minutes, although I'm wondering if that's the case then how much sense would it make a compiz-plugins-unity package ?
[08:16] <didrocks> smspillaz: before the place plugin in any case? to avoid jumping again?
[08:17] <smspillaz> didrocks: yeah, so basically a plugin before place which hooks CompWindow::place on any window that has a special property set
[08:17] <didrocks> smspillaz: right, but at least, it will be a nice exercice for me :)
[08:17] <smspillaz> didrocks: I'll forward the email I sent to Jason
[08:17] <didrocks> smspillaz: excellent, thanks!
[08:18] <didrocks> I'm just ensure about the "another plugin just for that", maybe, we should find another way, or having a plugin that handle all those special cases
[08:18] <smspillaz> argh, I keep on forgetting to back up evolution before reinstalling
[08:19] <smspillaz> didrocks: I would have opted to do it in the unity plugin, but that isn't possible since the unity plugin needs to load after place
[08:19] <smspillaz> didrocks: and you can make this plugin smart actually and not make it do anything unless the window has this property set
[08:19] <didrocks> smspillaz: yeah, because you need to override the place action in that case :)
[08:20] <smspillaz> didrocks: indeed, well loading before it will make place actually place the window and then we just shift it to the right if it overlaps the launcher area
[08:20] <didrocks> smspillaz: ok, can you just forward me the email? I'll get that done next week
[08:20] <smspillaz> didrocks: sure, although if I have time to I might do it so that we can get it in by the time we do the upload
[08:21] <didrocks> smspillaz: no, I will do the upload today and no more new feature then (freeze) for alpha2
[08:21] <smspillaz> fair enough
[08:21] <didrocks> smspillaz: so, I just need the gconf crash bug fixed :)
[08:21] <smspillaz> didrocks: yeah, good point
[08:21] <smspillaz> didrocks: give me some other stuff to fix in case I have time on my hands
[08:21] <didrocks> smspillaz: also, if you don't let the other try to do it, you won't get anyone helping you in the future :)
[08:22] <smspillaz> didrocks: this is true :p
[08:22] <didrocks> smspillaz: sure, finishing triaging my emails first, still 200+ to go :)
[08:22] <smspillaz> (and besides, someone is doing work *for* me, what a perfect opportunity :P!)
[08:23] <didrocks> :)
[08:23] <smspillaz> didrocks: so after gconf, I think I will fix 661049 and maybe I will check if our workaround to do 685968 is still working
[08:24] <smspillaz> also I should look into why the decorations of unfocused windows are going away with u-w-d
[08:24] <didrocks> smspillaz: I've done 661049
[08:25] <didrocks> smspillaz: look at the status :)
[08:25] <smspillaz> oh? so double clicking works?
[08:25] <smspillaz> \o/
[08:25] <didrocks> yeah ;)
[08:25] <smspillaz> nice
[08:25] <didrocks> still need merging, but will be done today
[08:25] <smspillaz> awesome
[08:25] <smspillaz> and that's using the PanelTitlebarGrabAreaView is it ?
[08:25] <didrocks> 685968 is currently fixing by Jason
[08:25] <didrocks> smspillaz: right
[08:26] <smspillaz> didrocks: there's a feature in compiz we can turn on to fix 685968
[08:26] <didrocks> smspillaz: just the double click signal in nux is broken, so it's a workaround
[08:26] <smspillaz> didrocks: yeah I noticed
[08:26] <didrocks> that's why you didn't want to do it before :)
[08:26] <smspillaz> well it gets broken by my method of using PanelTitlebarGrabAreaView
[08:26] <didrocks> no, even without the MouseDown
[08:26] <smspillaz> didrocks: ah weird
[08:27] <didrocks> yeah, I was first thinking of a conflict, but it isn't
[08:27] <smspillaz> yeah since I do nasty things in that code like *cough* force ungrab the pointer
[08:27] <didrocks> right, but I tried to remove all the grab thing
[08:28] <didrocks> but it's really an issue nux and jay didn't have the time
[08:28] <didrocks> hence the workaround to emulate double-click myself right now
[08:30] <smspillaz> cool
[08:31] <smspillaz> didrocks: ah ok, seems though I don't have this email I sent to jaon because I forgot to backup evolution *cough*. I'll ask Jason to foward it
[08:32] <didrocks> smspillaz: ok, no worry :)
[08:32] <didrocks> smspillaz: backup are good!
[08:32] <smspillaz> the server backs up for me :)
[08:32] <didrocks> smspillaz: and even with insane mailbox, evolution is working fine
[08:32] <didrocks> (like 1h to backup my 4 Gio of emails)
[08:33] <didrocks> GiB in english :)
[08:33] <smspillaz> how do you even process that much email in a day :/
[08:33] <didrocks> well, it's just "picking the right ones" that enables to see what bugs are important
[08:33] <smspillaz> didrocks: the gconf crash is bug 691561 right ?
[08:34] <didrocks> smspillaz: btw, I don't see a comment in the wrong window position
[08:34] <didrocks> smspillaz: right
[08:34] <smspillaz> maybe launchpad failed on me again, I'll email it
[08:34] <didrocks> smspillaz: you attach something to bug #707853
[08:34] <didrocks> which is the "geometry restore"
[08:34] <didrocks> but not the "wrong position"
[08:34] <smspillaz> ah right
[08:34] <smspillaz> I think they are the same bug
[08:35] <smspillaz> (I only tested with minimal plugins though, I might be wrong)
[08:35] <didrocks> smspillaz: ok, I'll tell you
[08:36] <didrocks> smspillaz: btw, just so that you know, Jason and I found why the launcher became so slow for me after your launcher change
[08:36] <didrocks> and it seems to be the same issue than alt + tab beeing slow :)
[08:37] <didrocks> in fact, you go through all window xid and redecorates them
[08:37] <didrocks> this seems to be insanely expensiveeeeeeee there :)
[08:43] <smspillaz> ahh right?
[08:43] <smspillaz> that's interesting
[08:44] <smspillaz> file a bug I'll look into that
[08:44] <smspillaz> (and yes, redecorating windows is insanely expensive, good fine)
[08:44] <smspillaz> (good find)
[08:44] <didrocks> smspillaz: urgh, ABI break?
[08:45] <didrocks> smspillaz: what the "fix window jumping" is doing exactly?
[08:45] <ion> smspillaz: “implement improved borders & shadows (phase 1): DONE” – improved in which way? :-) I’m still unable to try Unity out myself due to nux crashing on fglrx. I do hope that means reducing the borders to zero pixels. That’s what OSX does and it looks great. :-)
[08:46] <smspillaz> ion: exactly
[08:46] <ion> Awesome
[08:46] <smspillaz> ion: there is now a small area outside of windows to resize in
[08:46] <smspillaz> didrocks: there was one recently, yes
[08:47] <didrocks> smspillaz: I don't get that bug btw, how to trigger it?
[08:47] <smspillaz> didrocks: also, fix window jumping is when you grab on chromium  and then grab it again and it jumps a bit
[08:47] <didrocks> smspillaz: remember than any ABI break is ubuntu not being installable for 6 hours
[08:47] <smspillaz> didrocks: heh
[08:47] <didrocks> smspillaz: can that slip by just after alpha2?
[08:47] <didrocks> smspillaz: like, I took the two other patchss?
[08:47] <smspillaz> didrocks: it really annoyed me, it would be good to include
[08:48] <didrocks> trying to reproduce
[08:48] <ion> smspillaz: A fully transparent area that becomes opaque on hover?
[08:48] <smspillaz> ion: no, it is always transparent (but your mouse cursor changes)
[08:48] <ion> Alright, sounds great.
[08:48] <didrocks> smspillaz: I can't reproduce it on chromium
[08:48] <didrocks> smspillaz: just that you ensure ABI break is expensive
[08:49] <smspillaz> didrocks: well, I'm not really sure if the ABI was really broken by that update, I just bumped the core ABI just to be safe
[08:49] <didrocks> urgh :/
[08:49] <smspillaz> though if we can get away with not bumping it, then that's probably a good thing
[08:49] <smspillaz> I did add some new globals though
[08:49] <didrocks> I think I'll give you some classroom about ABI breakage one day  :)
[08:49] <smspillaz> good plan :p
[08:49] <didrocks> did you change an existing struct?
[08:50] <smspillaz> don't think so
[08:50] <didrocks> and nothing in existing methods?
[08:50] <smspillaz> negative
[08:50] <didrocks> ok, let's try without the breakage
[08:50] <smspillaz> sure
[08:51] <smspillaz> urgh, can't seem to reproduce this gconf bug
[08:51] <smspillaz> let me try it from your packages I guess
[08:52] <smspillaz> hi njpatel
[08:52] <njpatel> hey smspillaz
[08:53] <smspillaz> I love it when my keyboard layout gets switched to Afghanistan
[08:53] <didrocks> smspillaz: our package, without the patch
[08:53] <didrocks> smspillaz: and ensure you are using the gconf backend
[08:54] <smspillaz> right
[08:55] <ion> smspillaz: Every time keyboard-configuration gets updated it seems to revert the debconf values to defaults which happen to be af-something. I haven’t got around to filing a bug (if one doesn’t already exist).
[08:55] <smspillaz> ion: yeah, I think a bug has been reported already
[11:28] <didrocks> smspillaz: ok, so for your compiz backtrace
[11:28] <smspillaz> didrocks: so is there a way that I can get a backtrace from the .crash?
[11:28] <didrocks> smspillaz: rm all *compiz* in /var/crash
[11:28] <didrocks> smspillaz: because I think it's an old one
[11:28] <smspillaz> ok
[11:28] <didrocks> so just ensure we get a fresh one first :)
[11:29] <didrocks> you recompiled the packaged, right?
[11:29] <didrocks> package*
[11:29] <smspillaz> oh, right
[11:29] <smspillaz> it didn't crash
[11:29] <smspillaz> yeah I recompiled the package without the workaround
[11:29] <smspillaz> weird
[11:29] <smspillaz> I'll try rming my config
[11:29] <didrocks> ok, but it crashed you just told me?
[11:29] <didrocks> yeah, I'm almost sure you are using the ini backend :)
[11:31] <smspillaz> doesn't say I am
[11:31] <smspillaz> and weird, even after I rm that stuff unity doesn't show up
[11:31] <didrocks> are you in the right session?
[11:31] <didrocks> env | grep GDMSESSION
[11:31] <didrocks> and env | grep COMP
[11:33] <smspillaz> nothing in both of them, weird
[11:33] <smspillaz> oh, well, then again, sshing in doesn't help that
[11:34]  * smspillaz opens a terminal
[11:34] <didrocks> smspillaz: right, those variables are handled by gnome-session, you need a process son of gnome-session
[11:34] <didrocks> or spawned by it, at least
[11:35] <smspillaz> yeah
[11:35] <smspillaz> didrocks: what's the name of the package to right click in nautilus and open a terminal there?
[11:36] <didrocks> smspillaz: I think it's nautilus-action or something like that… I'm not using it TBH :)
[11:37] <didrocks> smspillaz: first, look if the gnome-session process has the right env variable in
[11:37] <didrocks> if it's ok, you can just export the same in your ssh window I guess
[11:37] <spikeb> nautilus-open-terminal - nautilus plugin for opening terminals in arbitrary local paths
[11:38] <didrocks> thanks spikeb :)
[11:38] <smspillaz> that makes my life<PHONE_NUMBER>56372537483 times easier
[11:39] <didrocks> smspillaz: I tend, when compiz is started, to Ctrl + alt + T to open one at start :)
[11:39] <smspillaz> there's that too
[11:40] <smspillaz> didrocks: GDMSESSION=gnome
[11:40] <smspillaz> didrocks: COMPIZ_CONFIG_PROFILE=ubuntu
[11:40] <smspillaz> is that right?
[11:40] <didrocks> excellent :)
[11:40] <smspillaz> and compiz is working here ....
[11:41] <smspillaz> even with that patch uncommented
[11:41] <didrocks> weird… is it at session start?
[11:41] <smspillaz> yes
[11:41] <smspillaz> (also, maybe the unity plugin isn't working right now because of the abi break, that might explain it)
[11:41] <didrocks> you remember that it was utterly failing for everyone, we didn't invented that and you had it as well :)
[11:42] <smspillaz> yeah, I know
[11:42] <smspillaz> but ISTR that it crashed
[11:42] <smspillaz> we skipped lunch over it remember?
[11:42] <smspillaz> (also, that day was _awful_ since the damn airconditioning system was destroying my lips)
[11:42] <ogra> you had that only one day ?
[11:43] <ogra> lucky you
[11:45] <smspillaz> it was every day
[11:45] <smspillaz> but wednesday was the worst
[11:46] <ogra> heh, you should have come to the arm room ....air was so dry that we could produce blue sparks with the static electricity in th air (which is indeed helpful in a room full of bare non grounded boards)
[11:46] <didrocks> well, Friday was horrible for me as well :)
[11:46] <spikeb> haha ogra, did you guys end up frying anything?
[11:47] <ogra> persia made fun out of running around and randomly touching people
[11:47] <ogra> i think Gruemaster fried something
[11:47] <spikeb> ouch
[11:47] <ogra> luckily a cheap and easily replaceable board
[11:52] <didrocks> smspillaz: btw, did you try to log twice as told on the bug report?
[11:52] <smspillaz> what do you mean ?
[11:52] <didrocks> *shrugh* we already discussed that extensively and it's on the bug report :/
[11:52] <didrocks> like, the crash only happens when you log twice with the same profile
[11:53] <didrocks> not on profile change (on the gconf copy)
[11:53] <smspillaz> log or log in
[11:53] <didrocks> log in
[11:53] <smspillaz> didrocks: right :)
[11:54] <smspillaz> didrocks: so interestingy enough I haven't hit the crash yet, but uncommenting that patch makes unity not load it seems
[11:54] <smspillaz> are we enabling dbus by default?
[11:54] <didrocks> smspillaz: dbus isn't enabled by default
[11:55] <didrocks> smspillaz: unity --reset to reset to the distribution default
[11:55] <smspillaz> didrocks: ok
[11:55] <smspillaz> didrocks: that was 000_workaround_gconfbackend_hang.patch right ?
[11:55] <didrocks> smspillaz: right
[11:55] <smspillaz> (also had to disable move_checks_to_compiz.patch since it depended on it
[11:55] <didrocks> hum, that's why it doesn't crash
[11:56] <didrocks> we don't load the ccp plugin :)
[11:56] <didrocks> adapt move_checks_to_compiz.patch rather to still load the ccp plugin without any arg
[11:56] <didrocks> (I still think that this patch should be upstream btw, there is no need to "do nothing and screw the user" if you just compiz --replace)
[11:57] <smspillaz> ideally ccp should be integrated into core
[11:57] <didrocks> agreed
[11:58] <didrocks> smspillaz: so that's why you don't have any crash I think
[11:58] <smspillaz> and we should remove command line loading
[11:58] <smspillaz> didrocks: but I get window borders
[11:58] <didrocks> smspillaz: readd it in adapating it
[11:58] <smspillaz> and compositing
[11:58] <didrocks> weird
[11:58] <didrocks> you shouldn't :)
[11:58] <smspillaz> so it is clearly loading that plugin
[11:59] <smspillaz> I think though people wanted it to be kept a plugin because we might experiment with other settings systems
[11:59] <smspillaz> or for debugging purposes, etc
[11:59] <didrocks> well, first, let's get one right and see after… :)
[12:00] <didrocks> for debugging purpose you still compiz <manual list>
[12:00] <didrocks> the patch doesn't prevent that
[12:00] <smspillaz> didrocks: yeah, although it gives favor to a specific plugin. hardcoded
[12:01] <smspillaz> didrocks: there is a COMPIZ_DEFAULT_PLUGINS a build-time for a reason you know :)
[12:01] <didrocks> smspillaz: the plugin that loads all the other
[12:01] <smspillaz> oh, but that doesn't work if ccp aint loaded, duh
[12:01] <didrocks> right
[12:01] <didrocks> so really it's just illogical
[12:01] <smspillaz> didrocks: I think that compiz should read the default values in the metadata then
[12:02] <smspillaz> maybe COMPIZ_DEFAULT_PLUGINS is just setting the value, not the default value
[12:02] <didrocks> it's setting the value, but those values need to be read by ccp
[12:02] <smspillaz> if that doesn't work I need to fix it :)
[12:03] <smspillaz> didrocks: the defaults still work if ccp isn't loaded
[12:03] <didrocks> no it doesn't
[12:03] <didrocks> I remember explicitely to try it
[12:03] <smspillaz> didrocks: for example, alt-button1 is a default value for the move plugin, and that works if you just compiz --replace move
[12:03] <smspillaz> so what's happening is that we're not reading the default value
[12:03] <smspillaz> and that is indeed abug
[12:03] <didrocks> right, but not if you compiz --replace
[12:03] <didrocks> you were speaking about default like COMPIZ_DEFAULT_PLUGINS
[12:03] <smspillaz> didrocks: it should read the default values for the core plugin though
[12:03] <smspillaz> didrocks: exactly
[12:04] <didrocks> well, I'll let you try to reproduce the crash, on unity right now :)
[12:05] <smspillaz> didrocks: yeah
[12:06] <smspillaz> didrocks: what's that magical bzr command you did to fix patches not applying ?
[12:06] <smspillaz> didrocks: if I comment out 000_workaround_gconfblahblah 060_move_checks_to_compiz doesnt apply
[12:06] <smspillaz> ISTR you had a magic thing to fix that
[12:06] <didrocks> smspillaz: so, bzr bd-do
[12:06] <didrocks> quilt push -f 060_move_checks_to_compiz
[12:07] <didrocks> do you have a reject?
[12:07] <smspillaz> yes
[12:08] <didrocks> ok, so fix it
[12:08] <didrocks> editing the file (not the rejected one, the original)
[12:08] <didrocks> to readd the ccp plugin
[12:08] <didrocks> then quilt refresh
[12:08] <didrocks> exit 0
[12:08] <didrocks> bzr bd…
[12:09] <didrocks> if you want to generate the debug symbols, you need to install a package, one sec
[12:09] <didrocks> smspillaz: install pkg-create-dbgsym, it will generate the -dbgsym
[12:16] <smspillaz> kompiling
[12:41] <smspillaz> didrocks: so weirdly enough, if I don't have any of those patches applied, unity doesn't get loaded :/
[12:41] <smspillaz> so 000_fix_gconf_backend_init_hang is what makes unity load for me
[12:41] <smspillaz> otherwise it doesn't load
[12:42] <didrocks> do you have 060_move_checks_to_compiz still?
[12:42] <didrocks> again, without 060_move_checks_to_compiz ccp doesn't load, and so no settings at all
[12:42] <smspillaz> didrocks: I dropped 060_move_checks_to_compiz and implemented it myself in the source
[12:43] <smspillaz> doing the same with 000_fix_gconfbackend_init_hang
[12:43] <didrocks> smspillaz: how implemented in the source?
[12:43] <smspillaz> didrocks: exactly the same way as the patch
[12:43] <didrocks> you are building the package isn't it?
[12:43] <smspillaz> yes
[12:43] <smspillaz> so I just changed the source is build-area
[12:43] <smspillaz> are you allowed to do that?
[12:43] <didrocks> and then?
[12:43] <smspillaz> bzr bd
[12:43] <didrocks> no
[12:44] <smspillaz> ok, that explains a bit :)
[12:44] <didrocks> why didn't you follow what I told you?
[12:44] <didrocks> :/
[12:44] <smspillaz> It didn't work
[12:44] <smspillaz> just got more reject errors
[12:44] <didrocks> ask rather, it's working, I've done that for years…
[12:44] <didrocks> well, reject is because other patch is depending on this one I guess
[12:44] <didrocks> just update then one by one
[12:44] <smspillaz> indeed
[12:44] <smspillaz> aand how do I do that exactly ;-)
[12:44] <didrocks> and think the pain I have at every update :)
[12:44] <didrocks> read above?
[12:45] <didrocks> quilt push -f <the patch>
[12:45] <smspillaz> well the pain is created by this bizzare packaging system :)
[12:45] <didrocks> no, the pain is made by upstream not accepting sensible patches :)
[12:45] <smspillaz> though, I'm glad you're there to help us :)
[12:45] <didrocks> so
[12:45] <didrocks> bzr bd-do
[12:45] <didrocks> quilt push -fa
[12:45] <smspillaz> -f or -fa ?
[12:45] <didrocks> -fa is easier, it will try to push all the patches it can
[12:46] <didrocks> then, you have a reject, isn't it?
[12:46] <smspillaz> right, you missed that earlier :)
[12:46]  * smspillaz was doing -f
[12:46] <didrocks> smspillaz: no, I told you quilt push -f <rejected_path>
[12:46] <didrocks> which is the same in that case
[12:46] <didrocks> just easier to -fa
[12:46] <smspillaz> right
[12:47] <didrocks> ok, so now fix that in the source
[12:47] <didrocks> (the rejection)
[12:47] <didrocks> as you have the .rej, it should be easy
[12:47] <didrocks> then, quilt refresh to refresh the patch
[12:47] <didrocks> then quilt -fa to try to push more patch
[12:47] <smspillaz> what do you mean "fix it in the source"
[12:47] <smspillaz> since you said going into build-area is wrong
[12:48] <didrocks> smspillaz: look at my next sentence
[12:48] <didrocks> 13:47:34  didrocks | then, quilt refresh to refresh the patch
[12:48] <didrocks> it will bring back your change to the patch in debian/patches/<foo>
[12:48] <smspillaz> ah right :)
[12:48] <didrocks> only the debian/ directory is kept on exit 0
[12:49] <didrocks> so, just keep quilt push -fa ; fix ; quilt refresh ; until there is no more patch to refresh
[12:49] <didrocks> then exit 0
[12:49] <didrocks> and bzr bd
[12:51] <smspillaz> so what exactly does "fix" entail though :)
[12:51] <smspillaz> just "quilt refresh" ?
[12:51] <didrocks> do you know about patch? :)
[12:52] <didrocks> if it was only quilt refresh, it would be automated :)
[12:52] <smspillaz> what, just patch -p0 060_move_checks_to_compiz ?
[12:52] <didrocks> no ;)
[12:52] <didrocks> whenn, quilt is doing that
[12:52] <didrocks> well*
[12:52] <didrocks> (-p1 in fact, but that's not the matter)
[12:52] <didrocks> so, when you have a rejection, it means it can't apply a part of the patch
[12:53] <didrocks> because of the context is different
[12:53] <didrocks> ok?
[12:53] <smspillaz> right
[12:53] <didrocks> so, you need to reapply that part of the patch (it's called a junk or something like that manually IIRC) manually
[12:53] <didrocks> for that, if you have a reject on foo.cpp
[12:53] <smspillaz> to what exactly
[12:53] <didrocks> you have foo.cpp.rej
[12:54] <smspillaz> since build-area is something that you shouldnttouch[tm]
[12:54] <didrocks> so, you need to look at the changes and reintroduce them to foo.cpp
[12:54] <smspillaz> but the foo.cpp in where?
[12:54] <didrocks> *shrugh*
[12:54] <didrocks> in the build-area
[12:54] <didrocks> then, quilt refresh
[12:54] <smspillaz> ............................................................
[12:54] <didrocks> 13:48:22  didrocks | it will bring back your change to the patch in debian/patches/<foo>
[12:54] <smspillaz> ahh right
[12:55] <smspillaz> that's possibly the most confusing thing I've used in a looooonnnnggg time
[12:55] <didrocks> quit refresh is basically a diff -Nrup > debian/patches/…
[12:55] <didrocks> so just trust me and follow the guide:
[12:56] <didrocks> bzr bd-do; repeat: quilt push -fa ; <fix in the source> ; quilt refresh; until all patches applies again; exit 0
[12:56] <didrocks> and bzr bd
[12:57] <smspillaz> ok :)
[12:57] <didrocks> that's one of the 3 patch systems we are using if you want more info, look there: https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[12:57]  * smspillaz wishes things could be a simple as arch linux
[12:58] <didrocks> well, I admit that using bzr make it a little more difficult in that case until we can use source 3 for everything :)
[12:58] <smspillaz> didrocks: quilt-push -fa says no patches in series - I need to go into /debian right ?
[12:59] <didrocks> oh right, sorry, you need to export QUILT_PATCHES=debian/patches
[12:59] <smspillaz> :)
[12:59] <didrocks> well, I have that for such a long in my bashrc :)
[12:59] <smspillaz> huzzah it worked!
[12:59]  * smspillaz hugs didrocks
[12:59] <didrocks> good luck now! ;-)
[13:00] <didrocks> and meanwhile… nux is still building :)
[13:00] <smspillaz> lol
[13:02] <smspillaz> aand it still refuses to build
[13:02] <didrocks> hum?
[13:02] <didrocks> do you have a reject at build only?
[13:02] <smspillaz> yes
[13:02] <didrocks> like quilt push -fa works until the last patch.
[13:02] <smspillaz> yep
[13:02] <didrocks> but not while building??
[13:02] <didrocks> yeah, I got that too sometimes
[13:03] <didrocks> I really don't know why
[13:03] <smspillaz> solution?
[13:03] <didrocks> the way to fix is:
[13:03] <didrocks> - note the patch which is failing
[13:03] <didrocks> bzr bd-do
[13:03] <didrocks> quilt push <name of the patch failing>
[13:03] <didrocks> (you should have shell completion btw)
[13:03] <smspillaz> I do
[13:03] <didrocks> -> no reject normally
[13:03] <didrocks> quilt refresh
[13:03] <didrocks> exit 0
[13:03] <didrocks> bzr bd
[13:03]  * smspillaz adds QUILT_PATCHES=debian/patches to bashrc
[13:03] <didrocks> :)
[13:05] <didrocks> did it work?
[13:05] <smspillaz> IT WORKS
[13:05]  * smspillaz HUGS DIDROCKS MOAR
[13:06]  * didrocks hugs smspillaz, sorry about that one, I'm not sure why quilt can applies cleanly some patches with quilt push and not at build time sometimes…
[13:06] <smspillaz> lets hope I get the crash this time :p
[13:06] <didrocks> seems he can shift the patch context in some time :)
[13:06] <smspillaz> meh, its quilt's problem not yours :)
[13:06] <didrocks> yeah, let's hope it crashed!
[13:06] <didrocks> right, I should investigate though
[13:07] <smspillaz> btw, if you're not busy, I can help you write this plugin to do the soft struts
[13:07] <smspillaz> while kompiz kompiles
[13:07] <didrocks> smspillaz: well, let's focus on the gconf crash, I'm doing the unity release right now
[13:07] <didrocks> smspillaz: and then, yes, if you are still awake, we can work on the plugin together :)
[13:07] <smspillaz> sure np
[13:08] <smspillaz> didrocks: hmm, I have a dentist appt at 10h tomorrow, ah, screw it, all nighter it is
[13:08] <didrocks> smspillaz: hum, you should get some rest stil :)
[13:08] <didrocks> still*
[13:08]  * smspillaz cranks up ipod volume
[13:09] <didrocks> :)
[13:09] <smspillaz> strangely though I've been maintaining a normal sleep schedule (eg not going to bed at 4am) recently. that's probably a bad thing
[13:10] <didrocks> smspillaz: or a good one?  :)
[13:10]  * smspillaz blames the Dallas time difference
[13:11] <smspillaz> didrocks: eh, I pretty much have the house to my self for a while, don't really need to care about other people's sleep schedules
[13:11] <didrocks> hehe, right :)
[13:12] <smspillaz> still no crash :/
[13:13] <smspillaz> didrocks: could you check if you still get it ?
[13:15] <didrocks> smspillaz: did you try to log twice?
[13:15] <smspillaz> hmm, I'll try that
[13:15] <smspillaz> forgot about that :)
[13:15] <smspillaz> do I have to do it in fairly rapid succession ?
[13:16] <didrocks> smspillaz: not really
[13:16] <smspillaz> still not getting it
[13:16]  * smspillaz double checks that patch is gone
[13:17] <didrocks> did you install the new packages? :)
[13:17] <smspillaz> yes
[13:20] <smspillaz> didrocks: any ideas?
[13:21] <smspillaz> the only thing I can think of is that gconf is using the ini backend, though that's unlikely
[13:24] <smspillaz> didrocks: what's that lp repo again?
[13:24] <didrocks> smspillaz: let me finish the unity release first
[13:25] <didrocks> smspillaz: you don't have debug output about which backend is used?
[13:25] <smspillaz> sure
[13:25] <smspillaz> hrm it says gconf here
[13:33] <didrocks> smspillaz: what says gconf? I was thinking our new startup order was telling nothing
[13:33] <didrocks> smspillaz: oh oh, I have another patch that can maybe help gconf to start
[13:34] <didrocks> smspillaz: try removing 080_migrate_gconf_from_alpha1.patch
[13:34] <didrocks> this one can maybe avoid the race as well
[13:34] <smspillaz> right
[13:34] <smspillaz> yes I recall removing this one made it worse
[13:35] <didrocks> yeah
[13:35] <didrocks> try that :)
[13:35] <smspillaz> I sure hope it isn't a race condition
[13:35]  * smspillaz does not want to debug a race condition right now
[13:35] <smspillaz> *grabs coffee*
[13:48] <smspillaz> AHAH it crashed!
[13:48] <smspillaz> wait, no it didn't crash, there was just an ABI mismatch :/
[13:51] <smspillaz> urgh, ok, still not crashing
[13:56] <smspillaz> didrocks: I guess I'll have to send you some patches for you to test then
[13:56] <smspillaz> didrocks: could you grab me that backtrace which we saw during the sprint ?
[13:57] <didrocks> smspillaz: isn't it on the bug report?
[13:57] <smspillaz> nope
[13:57] <didrocks> do you have the bug # handy?
[13:58] <smspillaz> this is bug 691561 right ?
[13:59]  * smspillaz rebuilds nux and unity + friends from git
[14:06] <didrocks> smspillaz: why not using the package? :)
[14:07] <smspillaz> didrocks: has it been pushed?
[14:07] <didrocks> smspillaz: it is building right
[14:13]  * smspillaz rebuilds everything
[14:13] <smspillaz> its gonna be a LONNNG night
[14:13]  * smspillaz looks into some other bugs in the meantime
[14:13]  * spikeb gets ready to rock n roll all night
[14:16] <smspillaz> seb128: are you still getting bug 687960 ?
[14:16] <smspillaz> since I'm not
[14:17] <seb128> smspillaz, no, seems to be fixed in the current version
[14:18] <spikeb> yes!
[14:18] <smspillaz> seb128: cool, can you close this bug?
[14:18] <seb128> smspillaz, ok
[14:22] <didrocks> smspillaz: ok, back, all is ready now
[14:22] <didrocks> smspillaz: I'm trying to rebuild with the patch
[14:22] <smspillaz> ok
[14:24] <didrocks> smspillaz: ok, done the quilt dance (was fast, just one conflict) :)
[14:24] <didrocks> building now
[14:25] <didrocks> smspillaz: there is a stack in the bug!
[14:25] <didrocks> smspillaz: do you really read bug reports?
[14:25] <didrocks> apport-retrace report (91.2 KiB, text/plain)
[14:29] <smspillaz> ah right
[14:29] <smspillaz> I was looking for Stacktrace.txt
[14:30] <smspillaz> didrocks: in the meantime I'm looking into bug 682781
[14:30] <didrocks> smspillaz: well, please focus on the gconf bug first
[14:30] <didrocks> smspillaz: you have the stack now :)
[14:31] <smspillaz> didrocks: that bt isn't for the gconf bug
[14:31] <smspillaz>  #0  0x000000000043b860 in CompWindow::id() ()
[14:31] <smspillaz>  No symbol table info available.
[14:31] <smspillaz>  #1  0x00007f94bc80391d in UnityScreen::getWindowPaintList (this=<value optimized out>) at /build/buildd/unity-3.2.6/src/unity.cpp:246
[14:31] <didrocks> smspillaz: well, it's the crash at start when removing my workaround
[14:31] <smspillaz>          pl = @0x12b8d50
[14:31] <smspillaz> that was for something else, which was fixed
[14:31] <smspillaz>          xwns = @0x7fff5f672120
[14:31] <didrocks> ok
[14:31] <didrocks> not sure why my workaround fixed it
[14:31] <smspillaz> didrocks: I'm pretty sure the crash *we* got was in dbus or something
[14:32] <didrocks> smspillaz: right
[14:32] <didrocks> smspillaz: so, if this one is fix, set it as fix released please
[14:32] <smspillaz> yep
[14:32] <didrocks> compiz still building without my first workaround
[14:32] <smspillaz> didrocks: could you test again with your workaround disabled? and if it doesn't work send me the bt :p
[14:32] <smspillaz> sup DBO
[14:33] <DBO> hey sam
[14:33] <smspillaz> DBO: can you forward the thing I mailed to you to didrocks
[14:33] <didrocks> hey DBO
[14:33] <DBO> which thing
[14:33] <smspillaz> DBO: the one about soft struts
[14:33] <DBO> ya
[14:35] <DBO> done
[14:35] <smspillaz> thx
[14:35] <DBO> smspillaz, I am going to be disabling the redecorating of windows on scale for now
[14:36] <DBO> its very very costly
[14:36] <DBO> and causes the animation to skip
[14:36] <smspillaz> really?
[14:36] <smspillaz> it ... shouldn't
[14:36] <smspillaz> works perfectly fine here (even on intel)
[14:38] <DBO> it is very expensive here and confirmed by many users to be
[14:38] <smspillaz> I can see why it might be somewhat expensive
[14:38] <smspillaz> (need to resize frame windows and stuff)
[14:38] <smspillaz> maybe I'll look into a better solution for this
[14:39] <smspillaz> DBO: when did this start happening? maybe there was an xserver update that slowed things down </randomguess>
[14:40] <DBO> as soon as it was committed
[14:40] <smspillaz> ok, that's very strange then
[14:41] <smspillaz> as I get no slowdown whatsoever
[14:42] <didrocks> DBO: received, thanks :)
[14:42] <DBO> np
[14:42] <didrocks> smspillaz: taking until 3-4s here
[14:42] <smspillaz> DBO: maybe in unity we can not set a strut on the panel and disable decoration /painting/ *cough*reallyuglyfuglyzomghack*cough*
[14:42] <didrocks> smspillaz: and that's what is doing the alt + tab slow
[14:42] <smspillaz> nah, alt-tab is a different issue
[14:43] <DBO> smspillaz, also is there a way to convince the scale plugin to maybe *not* use the left 64px
[14:43] <didrocks> smspillaz: I told you that this morning (my morning :))
[14:43] <smspillaz> DBO: *cough* set the strut *cough*
[14:43] <hggdh> is it a known issue that when returning to Classic Desktop from Unity all panel applets fail with "<whatever> has quit unexpectedly"?
[14:43] <didrocks> smspillaz: well, I definitively confirm that it's way way quicker if I have no window undecorated
[14:43] <didrocks> like less than a second with any window undecorated, several seconds with 4-5 window undecorated
[14:43] <smspillaz> its pretty well instant here
[14:43] <DBO> smspillaz, the problem with that is it becomes a race
[14:43] <didrocks> hggdh: yeah, it's knowing and fixed by the new compiz release for alpha2
[14:44] <didrocks> smspillaz: unfortunately, I don't have your hardware it seems :)
[14:44] <DBO> there is no way for me to set the strut from X and have it get back to compiz before the scale plugin does its layout
[14:44] <smspillaz> DBO: yeah
[14:44] <hggdh> didrocks: merci
[14:44] <smspillaz> DBO: welcome to the land of how much X sucks at doing what we actually want it to do
[14:44] <didrocks> hggdh: yw :)
[14:44] <DBO> smspillaz, so uhm, I have this crazy idea
[14:45] <smspillaz> don't
[14:45] <DBO> why cant we just let a plugin slice off a bit of the workarea
[14:45] <smspillaz> wont work
[14:45] <DBO> why not?
[14:45] <smspillaz> because I'd have to add a WrapableInterface and PluginClassHandler to CompOutput which means a mandatory API change for every single plugin
[14:46] <DBO> screen->claimWorkAreaSlice (CompRect);
[14:46] <smspillaz> not doing that
[14:46] <DBO> why not?
[14:46] <smspillaz> hack
[14:46] <smspillaz> you do realize how many times maniac103 would kill me if I introduced that right?
[14:47] <DBO> yeah but is it any nastier than what is required for soft struts?
[14:47] <smspillaz> DBO: yes
[14:47] <smspillaz> DBO: it is supporting unofficial specs in core - no can do
[14:48] <DBO> uhg
[14:48] <DBO> so how do we do soft struts in a way that scale pays attention
[14:48] <smspillaz> DBO: disto patching!
[14:48] <smspillaz> *distro
[14:48] <smspillaz> :)
[14:48] <DBO> okay so I guess I get to do it any way I want then
[14:48]  * DBO goes to do it the simplest way possible
[14:48] <smspillaz> don't break the API downstream
[14:49] <DBO> why not?
[14:49] <smspillaz> didrocks will kill you
[14:49] <didrocks> I won't :)
[14:49] <DBO> didrocks, will you kill me if the Ubuntu plugin only works on Ubuntu?
[14:49] <smspillaz> (dude! you were supposed to back me up on that!)
[14:49] <didrocks> DBO: that's fine for me :) we have already a lot of distro patch that upstream doesn't want, so it's ok :)
[14:49] <didrocks> (even distro patch written by upstream ;))
[14:49] <DBO> good deal
[14:49] <smspillaz> (they don't break the API though)
[14:50] <DBO> this doesn't break the API
[14:50] <DBO> it just adds to it
[14:50] <didrocks> they are still a burden to maintain, you learnt that!
[14:50] <DBO> we had the same thing with mutter, there are things we just have to do
[14:50] <smspillaz> DBO: you should just patch the scale and expo plugins to take into account soft struts
[14:50] <smspillaz> done!
[14:50] <DBO> thats a more complex patch
[14:50] <didrocks> DBO: so, ntw, are you disabling the redecoration for alpha2
[14:50] <didrocks> btw*
[14:50] <DBO> didrocks, depends when that happens I guess
[14:51] <didrocks> DBO: for monday
[14:51] <DBO> smspillaz, my patch is like 10 lines, yours is a lot more
[14:51] <DBO> didrocks, yes
[14:51] <didrocks> DBO: great, thanks :)
[14:51] <smspillaz> DBO: I know that, but at least it doesn't introduce an API difference between the  ubuntu compiz and the upstream compiz
[14:51] <didrocks> smspillaz: FYI I'll probably to the same in the alt + tab plugin
[14:51] <smspillaz> didrocks: there's no such code in the alt-tab plugin
[14:51] <dbarth_> seb128, didrocks: klattimer can't land the full i-datetime today unfortunately
[14:51] <smspillaz> didrocks: like I said before, alt-tab is a different issue
[14:51] <didrocks> smspillaz: well, there is something related to the size of the window in any case
[14:52] <dbarth_> seb128, didrocks: but we're trying to have a part of it that lands
[14:52] <klattimer> dude you're going to make me feel full of shame and cry :(
[14:52] <smspillaz> didrocks: turn off mipmapping
[14:52] <DBO> smspillaz, yes but we care about maintenance costs more than maintaining plugin compatibility with upstream
[14:52] <didrocks> smspillaz: can we do that by default?
[14:52] <dbarth_> seb128, didrocks: at least on trunk and with dailies
[14:52] <smspillaz> didrocks: sure
[14:52] <didrocks> smspillaz: hum, ok, will do then, (we will only have icons then? no window preview, isn't it?
[14:53] <didrocks> dbarth_: got it, thanks for the notice
[14:53] <dbarth_> klattimer: i need to warn platform about what they still need to block on
[14:53] <smspillaz> DBO: the problem is that this method also introduces an ABI break between upstream and downstream, and that really sucks
[14:53] <DBO> smspillaz, I mean basically what you have said to me is "upstream cant solve this problem, you must, but please solve it in a much more complex manner than normally required"
[14:53] <klattimer> dbarth_: I was only joking :)
[14:53] <seb128> dbarth_, klattimer: why not? it means we still have the 10.10 code for alpha2 and no rollout during that cycle yet?
[14:53] <klattimer> seb128: yeah essentially
[14:53] <seb128> that's an issue
[14:53] <didrocks> smspillaz: btw, speaking of ABI break between upstream and downstream, didn't you introduce one in metacity? :)
[14:53] <seb128> how come that's the one source not getting weekly rollout?
[14:53] <didrocks> DBO: helping you there ^^
[14:53] <didrocks> :)
[14:53] <smspillaz> DBO: plus, adamw and the opensuse people are doing to kil me
[14:53] <dbarth_> seb128, didrocks: trying hard to have sometihng stable by tomorrow or monday, so requesting some flexibility for getting the last bits in alpha-2 ;)
[14:54] <smspillaz> didrocks: yes, but you don't develop plugins for metacity :)
[14:54] <DBO> smspillaz, nah, they'll take the patch too
[14:54] <didrocks> smspillaz: you can
[14:54] <smspillaz> DBO: adamw has indicated to be "kill your distro patches or else"
[14:54] <smspillaz> *to me
[14:54] <klattimer> seb128: I've had to learn ecal/ical api's and start implementing them in the indicator
[14:54] <klattimer> it's not easy as the documentation isn't very clear and existing examples are even less clear
[14:54] <didrocks> smspillaz: as you can have another *ccp* upstream and so don't enable it by default :)
[14:54] <DBO> smspillaz, well thats really his problem :)
[14:55] <spikeb> klattimer, write some documentation while you learn ;)
[14:55] <smspillaz> DBO: if it is really that much of a problem, I will write the patches myself :/
[14:55] <DBO> smspillaz, I dont see the functional difference really between the two
[14:56] <DBO> either way it doesn't work is intended
[14:56] <DBO> as
[14:56] <didrocks> ok, restarting to make compiz crash
[14:56] <seb128> klattimer, well still you should be able to do incremental rollout during the cycle and not block on having it to land at once no?
[14:57] <smspillaz> DBO: one introduces new API in core for the sake of handling a corner case that only happens in one plugin which breaks some other plugins in one distro (X doesn't do what we want), the other makes those plugins directly handle the case
[14:57] <klattimer> seb128: well this is a single feature
[14:57] <klattimer> and has been causing crashes and breaking other indicators
[14:57] <klattimer> especially the sound indicator
[14:57] <seb128> ok
[14:57] <DBO> smspillaz, if you want to do it your way you are free to
[14:57] <smspillaz> awesome :)
[14:57] <seb128> klattimer, do you need help on tracking those crashes?
[14:58] <seb128> klattimer, is it close to be working once those crash issues are solved?
[14:58] <klattimer> seb128: mterry helped me out yesterday and got me past one hurdle
[14:58] <smspillaz> DBO: the thing is that I don't want this to be a case "Well we let one API break slip, another one can't hurt"
[14:58] <smspillaz> all the way until we have a fork
[14:58] <seb128> klattimer, like do we aim at next week or what sort of timeframe?
[14:58] <klattimer> but in the mean time I'm trying to figure out whether it's my code or not that's at fault
[14:58] <klattimer> i'm hoping either tomorrow or monday
[14:58] <seb128> ok
[14:58] <DBO> smspillaz, I am glad you care so much about that :)
[14:58] <seb128> klattimer, thanks for the update
[14:59] <klattimer> np
[14:59] <seb128> klattimer, don't hesitate pinging mterry if you need help debugging something
[14:59] <smspillaz> DBO: compiz == my baby
[14:59] <klattimer> yeah
[14:59] <klattimer> he's pretty good :)
[15:06] <didrocks> smspillaz: I really can reproduce the hang quite easily
[15:06] <didrocks> seb128: I confirm, it's really a hang for me :)
[15:06] <smspillaz> didrocks: by just uncommenting that patch line ?
[15:06] <didrocks> smspillaz: right
[15:06] <smspillaz> didrocks: maybe there is something on your system ?
[15:06] <smspillaz> since I don't get it
[15:06] <didrocks> smspillaz: let me push the branch somewhere
[15:06] <smspillaz> at all
[15:06] <didrocks> smspillaz: well, not just mine, every got it…
[15:07] <smspillaz> didrocks: are you sure it was this particular one though ?
[15:07] <didrocks> seb128: what happened when you removed the patch?
[15:07] <didrocks> (just a rhetoric question as we have already discussed that hundreds of time…)
[15:08] <seb128> didrocks, you are sure it hangs?
[15:08] <seb128> didrocks, or is apport blocking it because it's trying to collect the .crash?
[15:09] <didrocks> seb128: I wanted for 30s, maybe I should wait more
[15:09] <didrocks> waited*
[15:09] <didrocks> trying waiting more
[15:09] <seb128> didrocks, ps ax | grep apport?
[15:09] <didrocks> but in any case, when you removed the patch, people were complaining, isn't it?
[15:09] <seb128> to see if it's running
[15:09] <didrocks> it's running
[15:09] <seb128> didrocks, well people were getting a crash
[15:10] <seb128> not a hang
[15:10] <didrocks> at least, there were getting something
[15:10] <seb128> ok, I guess it's apport taking ages and keeping the process blocked
[15:10] <didrocks> so not *just* my system…
[15:10] <seb128> no
[15:10] <didrocks> getting tired of having to justify every bug…
[15:10] <seb128> didrocks, right, as said everybody seemed to get a crash
[15:10] <seb128> nobody mentioned a hang
[15:10] <didrocks> smspillaz: do you believe me now? ^
[15:11] <seb128> but maybe the hang is just you having apport on and a slow box
[15:11] <didrocks> seb128: yeah, I'll try to wait a little bit more
[15:11] <didrocks> trying that right away…
[15:11] <smspillaz> didrocks: I believe you since I have seen it with my own eyes, but I just can't reproduce the crash myself
[15:11] <seb128> smspillaz, you should get a box with a standard natty install
[15:12] <smspillaz> seb128: I just reinstalled natty today
[15:12] <seb128> smspillaz, not sure what you are doing but you mix versions and it makes getting issues harder for you
[15:12] <smspillaz> the only things I've installed are the compiz packages from launchpad :)
[15:12] <seb128> smspillaz, well you seem to try to do local builds
[15:12]  * evilvish wonders how many "thank you" notes smspillaz might get for fixing the window resize bug ;)
[15:13] <smspillaz> seb128: I have no local builds installed
[15:14] <smspillaz> with stock natty and compiz packaged from launchpad, I cannot reproduce this at all
[15:14] <smspillaz> I have cc-b-gconf from the launchpad packages too
[15:15] <seb128> smspillaz, well a stock install using a compiz without the workaround should give you a crash
[15:16] <smspillaz> seb128: hm ok, and you can confirm this?
[15:17] <seb128> smspillaz, I didn't try with today's compiz but last time we tried to drop the workaround everyone was getting a crash on start in the default session
[15:17] <seb128> not in the classic session though
[15:17] <smspillaz> I know :)
[15:17] <smspillaz> but are you sure this happened with stock natty?
[15:17] <seb128> yes
[15:17] <smspillaz> can you check again?
[15:18] <smspillaz> because I'm not getting it :)
[15:18] <seb128> where did you get your compiz build without the workaround?
[15:18] <smspillaz> seb128: lp:~compiz/compiz/ubuntu
[15:18] <smspillaz> and then I removed the workaround from debian/patches/series
[15:19] <seb128> smspillaz, ok, I will try in a bit, I'm waiting to get the new compiz first
[15:19] <smspillaz>  sure
[15:19] <smspillaz> I'll keep going with this other bug
[15:21] <didrocks> definitively a hang here (waited for 3 minutes)
[15:21] <didrocks> I see 3 compiz process btw
[15:22] <didrocks> process/thread
[15:22] <seb128> didrocks, try to sudo stop apport?
[15:22] <smspillaz> I feel your pain (sort of, can't reproduce this bug yet)
[15:22] <seb128> didrocks, btw could you upload the "broken" compiz in a ppa like yours?
[15:22] <didrocks> seb128: that was my suggestion :)
[15:22] <didrocks> stopping apport, but nothing in /var/crash/
[15:23] <smspillaz> oh wow
[15:23] <didrocks> seb128: do you want the one with the new ABI?
[15:23] <seb128> didrocks, yes
[15:23] <smspillaz> so fixing this flash crash, actually fixed the majority of my issues with the 2D mode compiz \o/
[15:23] <didrocks> ok, doing
[15:24] <seb128> didrocks, the new stack is available in natty so once unity is published I will try to upgrade and then use your ppa to see if it hangs or crash
[15:24] <seb128> well if it hangs or crashes there
[15:24] <didrocks> seb128: thanks :)
[15:24] <didrocks> seb128: ok, uploaded, will ping you once published
[15:25]  * smspillaz will pull an all nighter
[15:25] <didrocks> (that's when you double-check you didn't dput ubuntu :))
[15:26] <didrocks> smspillaz: did you kept 080_migrate_gconf_from_alpha1.patch for your tests?
[15:26] <seb128> didrocks, don't tell me I did dput some GNOME3 to natty yesterday
[15:26] <smspillaz> I tried it with it commented out and included
[15:26] <seb128> didrocks, but I got lucky those were new revisions for versions not in natty so they got rejected on missing tarball
[15:27] <didrocks> seb128: oh, that was what you were talking about yesterday on -devel :)
[15:27] <didrocks> ahah, lucky yeah :)
[15:27] <seb128> yeah
[15:28] <didrocks> smspillaz: ok, I'm wondering if this can be the cause as I see several threads
[15:28] <didrocks> smspillaz: I'm trying to comment it as well and install
[15:28] <seb128> didrocks, did you try to send it a sig11 when it's hanging?
[15:28] <seb128> that should give you a .crash
[15:28] <didrocks> seb128: no .crash, which was weird
[15:28] <didrocks> seb128: so, I wrap it on gdb
[15:29] <didrocks> and ctrl + C once hanged
[15:29] <seb128> you sig11-ed it?
[15:29] <didrocks> it didn't react to sig11
[15:29] <seb128> weird, I'm quite sure it's crashing and apport hangs it
[15:30] <seb128> didrocks, do you have any segfault in /var/log/syslog?
[15:30] <didrocks> so, I have some kind of weird backtrace…  but almost with only missing symbols
[15:30] <seb128> or dmesg?
[15:30] <didrocks> seb128: not recently (I have some from this morning)
[15:30] <didrocks> it's like it's ignoring the segv
[15:31] <seb128> didrocks, do you have a .apport-ignore.xml?
[15:31] <seb128> in your user dir
[15:31] <didrocks> seb128: no, I don't, and I get other compiz crash triggered with apport
[15:31] <seb128> weird
[15:31] <didrocks> yeah :/
[15:31] <didrocks> let's see with the version in the ppa
[15:32] <didrocks> and I'm rebuilding without the run python script
[15:45] <didrocks> ok, retrying with that
[15:47] <dbarth_> today is landing day
[15:47]  * dbarth_ does more of the Thursday dance
[15:47] <dbarth_> lamalex: hiya; do you have presents for the ubuntu gods today?
[15:48] <dbarth_> tedg: more offerings for the gods?
[15:50] <tedg> dbarth_, Yeah, I went through kamstrup's questions on the reviews.
[15:50] <tedg> dbarth_, I think I've fixed everything now.
[15:51] <AnAnt> Hello
[15:52] <dbarth_> tedg: super, go appmenu, go!
[15:56] <didrocks> seb128: smspillaz: can't get anything better than that: http://paste.ubuntu.com/559061/
[15:56] <AnAnt> may someone comment on LP 701132 , LP 700971 ?
[15:57] <seb128> didrocks, install libglib2.0-0-dbg
[15:57] <didrocks> seb128: it is installed :/
[15:57] <seb128> dpkg -l | grep libglib?
[15:57] <didrocks> ii  libglib2.0-0                          2.27.92-0ubuntu1                           The GLib library of C routines
[15:57] <didrocks> ii  libglib2.0-0-dbg                      2.27.92-0ubuntu1                           The GLib libraries and debugging symbols
[15:57] <didrocks> and same for glibmm dbgsym
[15:58] <didrocks> I check on purpose it was the same version…
[15:58] <didrocks> ii  libglibmm-2.4-1c2a                    <IP_ADDRESS>-0ubuntu1                         C++ wrapper for the GLib toolkit (shared libraries)
[15:58] <didrocks> ii  libglibmm-2.4-1c2a-dbgsym             <IP_ADDRESS>-0ubuntu1                         debug symbols for package libglibmm-2.4-1c2a
[15:58] <seb128> didrocks, try the dbgsym instead
[15:58] <didrocks> seb128: that was my first try, same thing…
[15:58] <seb128> weird
[15:58] <didrocks> then, I decided to install the dbg
[15:58] <seb128> I need to check what  happened there
[15:59] <didrocks> seb128: no libglib in the dbg
[15:59] <didrocks> oh sorry, /usr/lib/debug/lib/libglib-2.0.so.0.2792.0
[16:00] <didrocks> so yeah, it match the patch (why no usr btw is it intended?)
[16:00] <smspillaz> didrocks: so you can reproduce the bug ?
[16:01] <didrocks> hum, for plymouth, before /usr is mounted I guess
[16:01] <didrocks> smspillaz: yeah, nothing changed :)
[16:01] <didrocks> smspillaz: with the workaround, or 2 patches remove, same backtrace
[16:01] <didrocks> smspillaz: 3 threads in compiz process
[16:01] <smspillaz> same as the one in the bug report ?
[16:01] <didrocks> and it's again for me
[16:02] <didrocks> smspillaz: no, look above ^
[16:02] <didrocks> http://paste.ubuntu.com/559061/
[16:02] <smspillaz> ah ok, missed that
[16:02] <smspillaz> didrocks: valgrind ?
[16:03] <smspillaz> maybe I'll have to look into running the main loop asap, right now we wait a bit before running it
[16:03] <didrocks> smspillaz: do you have the default settings btw?
[16:03] <smspillaz> yes
[16:05] <smspillaz> AHAHA I got the stacking bug with compiz 0.9
[16:05] <smspillaz> err
[16:05] <smspillaz> 0.8
[16:25] <lamalex> dbarth_, working on it, what time is upload?
[16:50]  * smspillaz -> bed
[17:23] <kenvandine> tedg, when can i expect releases to start hitting me?
[17:24] <tedg> kenvandine, Well, I'm trying to figure that out... kamstrup did reviews and I fixed the stuff, but I need him to check off on them.
[17:24]  * kenvandine will be leaving soon for a bit
[17:24]  * tedg too
[17:31] <jcastro> anyone getting a "Stuff and Doodads" icon on their launcher after today's unity update?
[17:36] <didrocks> jcastro: hum, this is old from maverick, I don't get it though
[17:36] <didrocks> jcastro: did you unity --reset recently?
[17:36] <jcastro> yep
[17:36] <didrocks> weird, I just have the two unkown icons for the placs
[17:36] <didrocks> places*
[17:37] <jcastro> yeah, I get those for like, my plugged in USB keys
[17:37] <jcastro> they work, just the icon is broken
[17:37]  * kenvandine runs out for about 1.5 hours
[17:37] <didrocks> jcastro: they work?
[17:38] <didrocks> oh ok, USB keys, yes
[17:38] <jcastro> right
[17:38] <jcastro> Stuff and Doodads just sits there, however it appears  to be in like "notification" mode or whatever where it sticks out halfway when the rest of the launcher is hidden
[18:11] <ronoc> kenvandine, https://launchpad.net/indicator-sound/third/0.5.7
[18:12] <ronoc> mpt, are you in the office tmrw ?
[18:12] <mpt> ronoc, yep
[18:12] <ronoc> good stuff
[18:13] <ronoc> mpt fancy sitting down for an hour to go through bugs ?
[18:13] <mpt> sure
[18:13] <ronoc> if not it can wait until next week
[18:13] <ronoc> just the design ones
[18:13] <mpt> Next week would be a bit better
[18:14] <ronoc> okay me too actually
[18:14] <mpt> since I'm trying to get this other project done by the end of this week
[18:14] <ronoc> grand
[18:14] <ronoc> lets pencil it in tmrw
[18:48] <lamalex> something has all of my memory
[18:48] <lamalex> but htop wont tell me what
[18:49] <lamalex> compiz is at the top with 4.5%
[18:49] <lamalex> something is wrong here
[19:06] <lamalex> UGH unityshell.h is not includable
[19:19] <kenvandine> ronoc, on it
[19:19] <ronoc> kenvandine, schweet
[19:20] <ronoc> borrowing an njpatel ism
[19:21] <ronoc> kenvandine, gonna grab some food
[19:23] <kenvandine> :)
[19:23] <kenvandine> tedg, any love for me?
[19:39] <tedg> kenvandine, Just starting, sorry.
[19:39] <kenvandine> no worries
[19:39] <kenvandine> i still haven't figured out wtf is up with the libappindicator packaging
[20:28] <tedg> kenvandine, One down, though I forgot to update the shlibs: https://code.launchpad.net/~dbusmenu-team/dbusmenu/ubuntu/+merge/47721
[20:35] <mterry> New unity/compiz acting badly for me here.  Not accepting clicks or hovers, but doesn't seem to have crashed either
[20:35] <mterry> Anyone else seen that?
[20:37] <mterry> ah, this is a resurgence of the 'only can interact with unity during an alt-tab' bug
[21:39] <jcastro> DBO: ping
[21:40] <DBO> pong
[21:40] <jcastro> DBO: is this still up to date/accurate? https://wiki.ubuntu.com/Unity/InstallationGuideFromSource
[21:41] <DBO> all the compiz stuff is no longer required
[21:41] <DBO> other than that, yes
[21:41] <jcastro> ok so I can safely remove that from the wiki page?
[21:42] <jcastro> actually, just cut out the parts that don't make sense, they're mixed in together
[21:42] <jcastro> so it's not obvious to me
[21:45] <DBO> okay
[21:45] <jcastro> thank you sit
[21:45] <jcastro> I mean sir ...
[21:48] <DBO> https://wiki.ubuntu.com/Unity/InstallationGuideFromSource#preview
[21:48] <DBO> there you go jcastro
[21:48] <DBO> all done
[21:49] <jcastro> thanks!
[23:28] <RAOF> Is there somewhere with Unity's mulit-monitor design published?


[11:56] <pavlushka> Hello even Unit193 !
[11:57] <Unit193> '193' is actually an odd number.
[12:31] <pavlushka> Unit193: So how are you man?
[13:54] <yano> lol
[16:14] <yano> http://alertfranklincounty.org/
[16:14] <jenni> [ Alert Franklin County > Home ] - https://bit.ly/1XntYNF
[18:54] <dzho> good thing there's only one Franklin County
[18:54] <dzho> https://en.wikipedia.org/wiki/Franklin_County
[18:54] <jenni> [ Franklin County - Wikipedia, the free encyclopedia ] - https://bit.ly/1UibzOL
[18:55] <dzho> this is where authorities at the state and federal level really screwed the pooch with regard to geographic domain names
[18:56] <dzho> that sort of stuff would have been quite natural to have under the state 2nd level geographic domain names


[13:41] <unix_> hi
[13:41] <unix_> magyarul, english, deutsch?
[13:41] <unix_> on smartos
[13:41] <unix_> "customer_metadata": {
[13:42] <unix_>     "user-script": "echo 'IPV6_DEFAULTGW=2001:4178:6:1416::1' >> /etc/sysconfig/network-scripts/ifcfg-net0"
[13:42] <unix_>   }
[13:42] <unix_> warum nicht funktioniert?
[13:42] <unix_> host: smartos
[13:43] <unix_> vm: centos
[13:53] <unix_> [   46.241951] cloud-init[1401]: 2021-03-04 13:53:21,339 - util.py[WARNING]: Failed running /var/lib/cloud/scripts/per-boot/01_smartos_vendor_data.sh [127]
[13:54] <unix_> [   46.249815] cloud-init[1401]: 2021-03-04 13:53:21,348 - cc_scripts_per_boot.py[WARNING]: Failed to run module scripts-per-boot (per-boot in /var/lib/cloud/scripts/per-boot)
[13:54] <unix_> [   46.254142] cloud-init[1401]: 2021-03-04 13:53:21,352 - util.py[WARNING]: Running module scripts-per-boot (<module 'cloudinit.config.cc_scripts_per_boot' from '/usr/lib/python3.6/site-packages/cloudinit/config/cc_scripts_per_boot.py'>) failed
[14:08] <unix_> problem solved.
[14:41] <Odd_Bloke> Glad to hear you solved it. :)
[14:45] <unix_> :D
[15:04] <Odd_Bloke> falcojr: https://github.com/canonical/cloud-init/pull/829 is ready for review; it's missing some testing docs, but is otherwise complete, I think.
[15:04] <Odd_Bloke> rharper: ^ is touching cloudinit.net, so of course your input would be great. :)
[15:09] <rharper> Odd_Bloke: sure
[15:32] <unix_> little problem is that you add the gateway every time you reboot
[15:32] <unix_> I only want to add it once
[15:36] <unix_> currently only works in this form:
[15:36] <unix_>   "customer_metadata": {
[15:36] <unix_>     "user-script": "echo BOOTPROTO=none > /etc/sysconfig/network-scripts/ifcfg-net0 && echo DEVICE=net0 >> /etc/sysconfig/network-scripts/ifcfg-net0  && echo HWADDR=92:9c:47:10:af:6b >> /etc/sysconfig/network-scripts/ifcfg-net0 && echo IPV6ADDR=2001:4178:6:1416:62:116:187:84/64 >> /etc/sysconfig/network-scripts/ifcfg-net0 && echo IPV6INIT=yes >> /etc/sysconfig/network-scripts/ifcfg-net0 && echo ONBOOT=yes >> /etc/sysconfig/network-scripts/ifcfg-net0
[15:36] <unix_>  && echo TYPE=Ethernet >> /etc/sysconfig/network-scripts/ifcfg-net0 && echo USERCTL=no >> /etc/sysconfig/network-scripts/ifcfg-net0 && echo IPV6_DEFAULTGW=2001:4178:6:1416::1 >> /etc/sysconfig/network-scripts/ifcfg-net0 && ifdown net0 && ifup net0"
[15:37] <unix_> which is ugly but it works
[15:38] <Odd_Bloke> unix_: I'm not sure I understand what you mean by "add the gateway every time you reboot"?  If it weren't added on every boot, it wouldn't be used, right?
[15:39] <unix_> the first
[15:39] <unix_> "user-script": "echo 'IPV6_DEFAULTGW=2001:4178:6:1416::1' >> /etc/sysconfig/network-scripts/ifcfg-net0"
[15:39] <unix_> enter each time you restart..
[15:40] <unix_> then it looks like this:
[15:40] <unix_> IPV6_DEFAULTGW=2001:4178:6:1416::1
[15:40] <unix_> IPV6_DEFAULTGW=2001:4178:6:1416::1
[15:40] <unix_> IPV6_DEFAULTGW=2001:4178:6:1416::1
[15:40] <unix_> etc
[15:42] <unix_> version 2 already works fine, don't add it more than once, just too long
[15:42] <unix_> there is definitely an easier method
[15:43] <Odd_Bloke> unix_: Aha, I think I understand: per-boot scripts are designed to run every boot; if you only want to configure that once per instance, then doing so in a per-instance script would perhaps be more appropriate?
[15:44] <unix_> what is the difference between user-script and user-data?
[15:45] <unix_> and bootcmd/runcmd?
[15:56] <Odd_Bloke> unix_: It looks like user-script is SmartOS-specific configuration, a shell script which is executed by cloud-init by default.
[15:57] <Odd_Bloke> bootcmd/runcmd would have to be specified as user-data, and the difference is when in the boot process they run; roughly: bootcmd runs early, runcmd runs late.
[16:01] <chillysurfer> question on cloud-init releases... when the upstream team creates a new release what effectively happens to the git repo? there's a git tag with just the version itself (e.g. `20.4.1`), and then there is an ubuntu/* tag for the release to ubuntu?
[16:02] <chillysurfer> but ignoring the ubuntu/* tag, the version tag release (standalone) is the indication in the git repo of a release?
[16:07] <unix_> thx!
[16:23] <xscori> Hi! Have a q. about writing shh public key to a different location than the usual user's home dir. sshd_config in the system is looking for keys at /etc/ssh/keys/
[16:23] <xscori> How can I tell cloud-init to use that location instead of inserting them into ~/.ssh/ ?
[16:23] <xscori> ssh*
[16:26] <stevenm> hey, so being new to cloud-init.   Do most prepared images with cloud-init support... use the information given on the first boot and then never look again?
[16:26] <stevenm> it's like a pseudo iso that's mounted right?
[16:51] <meena> stevenm: unless something so significant in the hardware changes that the cloud decides to change your servers id, the most significant work happens on the first boot
[16:51] <meena> there are modules that run on every boot, tho
[16:52] <stevenm> well in this circumstance I would be the cloud myself (proxmox)
[16:53]  * meena has never built a cloud with proxmox
[16:53] <stevenm> so I guess we'd set cloud-init options/files/etc against a VM.. boot it... then err 10 mins later?  unset them all
[16:53] <stevenm> then in theory if it (the VM) ever tries to look at cloud-init data again (e.g. on reboot) it'd find nothing
[16:54] <meena> the data is cached on disk
[16:54] <meena> we fall back to the cache (if that's been merged lol)
[16:54] <stevenm> whose disk? within the VM's own disks?
[16:54] <meena> yes
[16:55] <meena> you give the VMs disks they can write to?
[16:55] <stevenm> oh i got the impression cloud-init could be used as a one time thing... e.g. setting an IP on first boot
[16:55] <stevenm> but you're saying the IP on subsequent boots would re-check what it's mean to be according to cloud-init?
[16:56] <meena> it does that, but there are scenarios where we might need to look at the data again
[16:56] <meena> like when someone forces a re-run
[16:56] <stevenm> i.e. the user of that VM forces their VM to re-check cloud-init data?
[16:57] <stevenm> defo unsetting it then lol
[16:57] <stevenm> we just want to use this little 'cloud-init' thing to make sure customer VM's are accessible on their choice of network on first boot *only* - the rest they can configure themselves
[16:57] <meena> there are good reasons to do that sometimes, tho i prefer to just blow away the VM and get a new one
[16:57] <stevenm> other minor things are admittedly unavoidable like default users/pass's etc... but we're aiming for minimum effort
[16:58] <meena> disk resize
[16:58] <stevenm> you mean filesystem resize?
[16:58] <meena> yeah
[16:59] <stevenm> well that'll be up to the VM in question I guess
[16:59] <meena> usually, you build images with the smallest size possible, you put it into the VM and then not it and cloud-init resizes the file systems
[17:00] <stevenm> "not it" ?
[17:00] <meena> Boot it
[17:00] <stevenm> ah yeah
[17:01] <stevenm> i mean I guess something things (cloud-init or not) might do that anyway
[17:01] <stevenm> e.g. like when you the raspberry-pi OS image on a microSD... on first boot it'll grow
[17:02] <meena> i recently learned freebsd does that on its own on first boot, so i should build my images with /first-boot touched and see who gets there first
[17:44] <Odd_Bloke> chillysurfer: Correct, those tags indicate the release commit.  They should be signed and annotated, though I'm seeing that perhaps not all of them are currently.
[17:46] <Odd_Bloke> xscori: cloud-init doesn't handle non-default SSH key locations currently, unfortunately: it's complicated, and getting it wrong can have substantial security impacts.  So your best bet is to use `write_files` or `runcmd` to arrange things as they should be.
[17:47] <Odd_Bloke> stevenm: cloud-init runs at every boot of cloud instances, to detect whether or not this is a new instance (as well as to perform any per-boot configuration supplied by the user).  If it detects it is a new instance, it will re-run any per-instance actions, including network configuration.
[17:48] <Odd_Bloke> (If it doesn't run at every boot, then instances launched from images captured from instances will not behave correctly: they won't apply per-instance configuration despite the fact this is a new instance.)
[17:49] <Odd_Bloke> By default, though, cloud-init will not reconfigure networking on every boot.  There are exceptions to this: e.g. EC2 Classic (i.e. pre-VPC) instances get a new MAC address at every boot, so configuration written for the previous MAC address will not apply on subsequent boots.
[17:50] <Odd_Bloke> It's worth noting that if you unset the metadata in the cloud, cloud-init may detect future boots as new boots.
[17:51] <Odd_Bloke> stevenm: https://cloudinit.readthedocs.io/en/latest/topics/boot.html#first-boot-determination breaks down this behaviour in more detail.


[03:13] <astroo-> Firefox 23 lands with a new logo and mixed content blocking  http://arstechnica.com/information-technology/2013/08/firefox-23-lands-with-a-new-logo-and-mixed-content-blocking/
[03:17] <astroo-> http://arstechnica.com/security/2013/08/how-do-you-stop-https-defeating-breach-attacks-let-us-count-the-ways/
[03:24] <astroo-> ciao pessoal
[20:36] <astroo-> ola pessoal
[20:58] <optimusprimem> astroo-, olá
[21:00] <astroo-> ola


[13:28] <xu-help91w> Hi I have a problem with my latest version of Xubuntu, it does not recognize the wired network, any solution?
[14:04] <Aquza> Hello together, since i update to xubuntu 20.04 i have problems with engrampa archive manager. For example i download a zip and i wanan open it over the thunar or the browser it crashs. So zip and tar files are only possible to open via the terminal.
[14:04] <Aquza> Is it a known issue?
[14:05] <wunderwungiel> Hello
[14:05] <wunderwungiel> Is anyone online?