[07:13] <didrocks> veebers: hey, still around?
[10:24] <Esokrates> howto apply ubuntu settings to compiz compiled from source?
[10:24] <Esokrates>  I have compiled and installed compiz but when I login the only thing I get to see is the wallpaper
[10:24] <Esokrates>  so I change to a VT and start compiz using: env DISPLAY=:0 compiz –replace composite opengl move resize decor compiztoolbox mousepoll wall expo animation switcher unityshell
[11:32] <smspillaz> Esokrates: you need to start compiz like this:
[11:32] <smspillaz> compiz --replace ccp &
[11:33] <smspillaz> the 'ccp' is important, it tells compiz to load the settings management plugin
[11:33] <smspillaz> which pulls in all the other plugins
[11:33] <smspillaz> and applies the stored settings
[11:33] <Esokrates> i remember to have tried this too
[11:33] <Esokrates> have got my mail?
[11:34] <luv> umm, i install unity from source using dpkg-buildpackage and dpkg -i a running compiz --replace works fine for me
[11:35] <luv> but yeah, that's a horrible workflow :-)
[11:35] <Esokrates> compiz --replace just kills compiz and does not start anything
[11:36] <smspillaz> Esokrates: compiz --replace *ccp*
[11:36] <luv> yeah, i believe you its not working for you, sry
[11:36] <luv> i think he has alried tried that too
[11:36] <luv> alreadz
[11:37] <smspillaz> if you're doing it from a vt, you need to do COMPIZ_CONFIG_PROFILE=ubuntu DISPLAY=:0 compiz --replace ccp
[11:37] <smspillaz> (that will make it pick the gsettings profile and the saved ubuntu settings)
[11:37] <Esokrates> smspillaz, oh i did not know that one, i will try that
[11:56] <Esokrates> smspillaz, does not work
[11:57] <Esokrates> smspillaz, i get error like "A handler is already registered for /org/freedesktop ..."
[12:01] <Esokrates> smspillaz, everything runs fine, but i cannot adjust settings
[12:09] <Esokrates> luv, unity has nothing to do with that problem, as it already ran with default compiz before I compiled a patched branch from source
[12:09] <Esokrates> luv (a patched branch of compiz)
[12:23] <smspillaz> Esokrates: deactivate debus
[12:23] <smspillaz> *dbus
[12:23] <smspillaz> in ccsm
[12:23] <smspillaz> that will at least make it shut up
[12:23] <smspillaz> Esokrates: also can you post the full output somewhere?
[12:47] <didrocks> Mirv: sil2100: published last part of daily release documentation! If you have any question that are still pending, do not hesitate to ask me, I'll add them to the FAQ :)
[12:49] <Mirv> ok :)
[12:55] <MCR1> Hi :) Could somebody please reapprove: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1020822-gears-plugin-does-not-build-anymore/+merge/146285
[12:55] <Mirv> and for anyone wondering about where didier's documentation is: https://wiki.ubuntu.com/DailyRelease
[12:55]  * MCR1 forgot to adjust debian/compiz-plugins.install
[12:56] <Mirv> MCR1: done, although click-missed Rejected first... sorry about that
[12:56] <MCR1> Mirv: Thanks a lot. That was fast :)
[12:57] <Mirv> no problem, I trust Brandon and the packaging fix seemed fine :)
[12:57] <MCR1> Mirv: It is fine, don't worry ;)
[13:05] <Esokrates> smspillaz, http://pastebin.com/y47K1Ukk
[13:05] <Esokrates> smspillaz, http://pastebin.com/gHgWQLk9
[13:06] <MCR1> bregma: Hi :) There are a few serious Grid plugin problems with excellent bug reports left unfixed, which imho should really be fixed for 13.04. Would it be okay to add those to: https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-unity-polish , so we won't forget them ?
[13:07] <Esokrates> MCR1, https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1115341
[13:07] <Esokrates> MCR1, https://bugs.launchpad.net/compiz/+bug/1115344
[13:07] <MCR1> Oh, Esokrates - I did not know you are here :) Excellent reports, btw.
[13:08] <Esokrates> MCR1, https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1115350
[13:08] <Esokrates> MCR1, https://bugs.launchpad.net/compiz/+bug/1082001
[13:08] <MCR1> Esokrates: That is how bug reports *should* be written -> the shortest & exact way to reproduce the bug -> should help a lot in fixing those...
[13:09] <MCR1> Esokrates: Yep, I wrote the last one ;)
[13:10] <Esokrates> MCR1, then you also know this one: https://bugs.launchpad.net/compiz/+bug/1115351
[13:10] <MCR1> Esokrates: Yes, because I confirmed it today ;)
[13:12] <Esokrates> smspillaz, both outputs: i started compiz (on a VT) using the commands found in the pastebin and killed compiz using Strg+C
[13:21] <sil2100> didrocks: \o/ Reading it all up now since it's all finished ;)
[14:10] <mterry> fginther, have you seen http://10.97.0.1:8080/job/ps-unity-autopilot-release-testing/label=autopilot-ati/75/console ? looks like a bad log gathering script
[14:18] <fginther> mterry, looking
[14:22] <didrocks> popey: do you experience bug #937118 still?
[14:24] <fginther> mterry, looks like machine filed to install: "UTAHProvisioningException: Machine install timed out."
[14:25] <didrocks> fginther: there were crashes on the indicator tests though (and the nvidia trick to avoid the xorg crash didn't work)
[14:25] <fginther> grrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
[14:25] <didrocks> fginther: btw, do you know if veebers is still looking at those? I thought he would fix/relaunch what's needed during the night when this happened
[14:25] <mterry> fginther, ah yeah.  Right you are on UTAH.  OK, I guess ignore that failure
[14:25] <didrocks> mterry: can you please open a bug against UTAH?
[14:26] <mterry> didrocks, who owns indicators again?
[14:26] <didrocks> mterry: with the date of the day, they want to track failures
[14:26] <mterry> didrocks, k
[14:26] <didrocks> mterry:  cyphermox, can you check with him?
[14:26] <didrocks> I think we need uploading the crash xorg files and ping bryceh
[14:26] <didrocks> and relaunch testing the stack
[14:26] <mterry> didrocks, xorg file doesn't help on nvidia really
[14:27] <didrocks> mterry: there is one on intel though?
[14:27] <didrocks> for the indicator stack
[14:27] <mterry> ah
[14:27] <fginther> didrocks, ps-indicators-autopilot-release-testing/label=autopilot-nvidia had the nouveau driver installed
[14:27] <mterry> cyphermox, you know how to grab the xorg crash file?  It's in the build artifacts
[14:27] <didrocks> fginther: urgh, we test on nvidia blob though?
[14:28] <fginther> didrocks, it is supposed to be nvidia. I wonder if something tragic occurring during provisioning
[14:29] <fginther> didrocks, and AIUI veebers is still looking at these, but he's on holiday now
[14:29] <didrocks> fginther: ah, making sense :)
[14:30] <fginther> didrocks, I'll see what I can dig up on the nouveau instead of nvidia failure
[14:32] <mterry> didrocks, https://bugs.launchpad.net/utah/+bug/1116307
[14:33] <didrocks> thanks mterry
[14:34] <didrocks> cyphermox: are you looking at the indicator stack issue?
[14:35] <cyphermox> mterry: it's in the build artifacts, you mean, already grabbed?
[14:37] <mterry> cyphermox, yeah.  But download it and put it somewhere bryce can see, and poke him about it
[14:37] <mterry> cyphermox, and make sure to get the intel one, since the nvidia one is usually not useful
[14:37] <didrocks> mterry: cyphermox: I'll let you relaunch the 2 stacks, only for checking?
[14:37] <popey> didrocks: sorry, was on the phone (still am) upgraded to raring, not seen the issue since
[14:37] <didrocks> part 5 explains exactly what to run btw :)
[14:38] <didrocks> popey: you're quite lucky, happening a lot here since a few weeks
[14:42] <cyphermox> didrocks: btw I do get that wifi bug too
[14:43] <cyphermox> you can disable wifi with the switch to reset the driver, no?
[14:43] <didrocks> cyphermox: yep
[14:43] <didrocks> not ideal though…
[14:43] <cyphermox> well no
[14:44] <didrocks> #ubuntu-kernel pointed me to https://patchwork.kernel.org/patch/2007911/
[14:44] <didrocks> seems 3.7 is safe, not 3.8
[14:44] <cyphermox> but it's likely an easy enough issue, it seems to be specific to like, RX queue or something
[14:44] <cyphermox> i get a different message
[14:45] <cyphermox> didrocks: see if you get a message like: iwlwifi 0000:03:00.0: fail to flush all tx fifo queues
[14:46] <cyphermox> seems to be the one thing that shows up everytime wifi stops working
[14:46] <didrocks> hum, not really
[14:48] <popey> didrocks: tbh my laptop spends most of its time in a docking station so on wired network these days ⍨
[14:49] <didrocks> popey: yeah, hard to see wifi issues I guess then ;)
[14:49] <didrocks> popey: I'm not the only one, it's already a start…
[14:54] <cyphermox> heh, intel was a compiz crash, nvidia was a xorg crash
[14:54] <fginther> cyphermox, please note that the nvidia test was using the nouveau driver
[14:55] <cyphermox> meh
[14:56] <didrocks> do not hesitate if you need help to relaunch testing the stack
[14:56] <cyphermox> both would be using a free driver. that would mean both crashes are important
[14:56] <didrocks> (even if the FAQ published today is giving the command)
[14:56] <cyphermox> didrocks: so in case of failure you just relaunch?
[14:56] <didrocks> cyphermox: well, log bugs with the crash (retraced locally if possible)
[14:56] <didrocks> and yeah, relaunch but don't rebuild
[14:56] <didrocks> just use the "check with whole ppa" case
[14:57] <cyphermox> tbh I'm kind of running in all kinds of directions at once right now, but let's try to get this done now
[14:57] <didrocks> mterry: can you give cyphermox a hand? I'm still catching up
[14:57] <didrocks> cyphermox: your turn you will be next in that case :p
[14:57] <cyphermox> mterry: wait, I'll look at everything first, see if I can do it on my own
[14:57] <mterry> cyphermox, ok
[14:58] <didrocks> cyphermox: please do paste the command first ;)
[14:59] <didrocks> mterry: oh, did you get the pastebin of deploying a new component from yesterday?
[15:06] <cyphermox> didrocks: mterry: so what's the syntax for the cred file again?
[15:06] <didrocks> cyphermox: you didn't receive my email with them?
[15:06] <cyphermox> ah it's in email ok
[15:06] <didrocks> yep :)
[15:10] <mterry> didrocks, I got the pastebin, thanks
[15:10] <didrocks> great :)
[15:12] <cyphermox> didrocks: so cu2d-run -R indicator-stack -r raring --check-with-whole-ppa would be the right command, yes?
[15:12] <cyphermox> err, wait, not sure about the stack name
[15:13] <didrocks> cyphermox: the stack name is just "indicator", and you are changing the head (we will have raring when s… is opened)
[15:13] <didrocks> cyphermox: so either: cu2d-run -R indicator -r head --check-with-whole-ppa
[15:13] <cyphermox> dah
[15:13] <didrocks> or head is the default
[15:13] <cyphermox> yep yep
[15:13] <didrocks> so you can remove the -r head :)
[15:13] <didrocks> cyphermox: btw indicator*s*
[15:13] <cyphermox> would it make sense to alias head to the current dev release (or the other way around)
[15:13] <didrocks> :)
[15:14] <cyphermox> so that it would be more obvious and you can then just use the release name as expected?
[15:14] <didrocks> cyphermox: yep, please open a bug against cupstream2distro
[15:14] <cyphermox> sure, I'll even propose a patch
[15:14] <didrocks> cyphermox: but normally for the dev release, you don't provide anything
[15:14] <didrocks> great!
[15:14] <didrocks> just cu2d-run -R indicators --check-with-whole-ppa
[15:14] <didrocks> for instance
[15:14] <cyphermox> yeah
[15:14] <didrocks> easiest :)
[15:14] <cyphermox> I'm just thinking that there might be other people one day to work on this
[15:15] <cyphermox> or releasing to multiple releases at once or whatever
[15:15] <didrocks> yep
[15:15] <cyphermox> anyway, just waiting to get the confirmation that I got the necessary perms and I'll run that
[15:15] <sil2100> didrocks: hmmm, btw! Since I noticed thomi's unity fixes for AP got into lp:unity - but I don't see the optimization changes re-introduced in lp:autopilot
[15:16] <didrocks> sil2100: maybe reintroduce it?
[15:16] <sil2100> didrocks: you think I should re-introduce them and just have thomi review and approve?
[15:16] <didrocks> yeah, please do ;)
[15:16] <didrocks> we have enough failures on the current daily release
[15:16] <didrocks> thanks for looking sil2100
[15:16] <didrocks> sil2100: btw, did you try locally?
[15:16] <didrocks> like, this doesn't indeed regress?
[15:16] <didrocks> (if you get both)
[15:17] <sil2100> didrocks: I'll try before pushing it further ;)
[15:17] <didrocks> thanks!
[15:17] <sil2100> np! Let's see now...
[15:20] <cyphermox> didrocks: done
[15:20] <didrocks> cyphermox: so, as you can see the -check job is the only one running right now (with -head master job)
[15:21] <didrocks> let's wait for the results :)
[15:43] <cyphermox> mterry:  I'm merging indicator-bluetooth, are you going to do the bootstrapping too?
[15:44] <mterry> cyphermox, I hadn't thought about it  :)  I can sure, let me know once you merge
[15:44] <cyphermox> oh, I can do it too ;P
[15:48] <cyphermox> mterry: I think it's good now
[15:48] <cyphermox> didrocks: so we add to autolanding and everything?
[15:50] <didrocks> cyphermox: yep, once the boostrap is done, I'll let you add the indicator-bluetooth to the stack
[15:50] <didrocks> bootstrap*
[15:54] <mterry> cyphermox, do you need an approval on the bootstrap merge, or did you just do that directly?
[16:09] <cyphermox> mterry: well, we should be doing MPs if that's what you mean
[16:12] <cyphermox> it's really straightforward though so it's simple enough to approve quickly ;)
[16:15] <didrocks> cyphermox: compiz crashed on ati in the last run it seems
[16:15] <didrocks> cyphermox: mterry: can you retrace this for bregma? Seems we are starting to get regular compiz crashes now
[16:16] <didrocks> as we don't have the dbgsym in the ppa ( :( ), I guess we need manual retracing on i386
[16:17] <mterry> cyphermox, https://code.launchpad.net/~mterry/indicator-bluetooth/bootstrap/+merge/146664
[16:17]  * mterry gets out his i386 virtualbox
[16:19] <didrocks> mterry: I guess you need to apt-get source from the ppa and rebuild with nostrip or with pkg-create-dbgsym installed
[16:19] <mterry> didrocks, yup.  it's a pain  :)
[16:20] <didrocks> mterry: yeah, apparently one day, we'll have the dbgsym in the ppa…
[16:20] <mterry> didrocks, that would be swell
[16:20] <didrocks> basically, if we activate them right now, we won't have them in the distro
[16:20] <didrocks> which is worse :)
[16:20] <didrocks> mterry: if your setup is ready, maybe you can try to retrace the intel one as well, with a little luck, it's the same issue? :)
[16:21] <mterry> I'll see if either of them help
[16:21] <didrocks> thanks :)
[16:21] <mterry> didrocks, that seems like a weird choice to be forced upon us (distro or PPA)
[16:21] <didrocks> bregma: if you can put that one on the priority (top priority) as it seems those crashers are quite frequent and block daily release
[16:21] <mterry> didrocks, I wonder how it's implemented
[16:22] <didrocks> mterry: "a bad dirty hack" told infinity
[16:23] <mterry> didrocks, I don't see the intel crash file?  I do see it for the last ati build
[16:26] <didrocks> mterry: in the previous run: http://jenkins.qa.ubuntu.com/job/ps-indicators-autopilot-release-testing/104/label=autopilot-intel/artifact/results/artifacts/_usr_bin_compiz.1000.crash
[16:26] <mterry> ah
[16:27] <cyphermox> didrocks: yeah I noticed the compiz ati crash
[16:27] <didrocks> cyphermox: mterry is retracing them, I hope we can get those fixed so that we can daily release again
[16:27] <cyphermox> yeah
[16:35] <sil2100> didrocks: didn't run all the tests yes, but only some of them - and it seems to work fine with thomi's changes
[16:36] <didrocks> sil2100: great, please merge then :)
[16:36] <didrocks> thanks ;)
[16:41] <kenvandine> hey mhr3, dee leaks!
[16:41] <kenvandine> :-D
[16:41] <mhr3> kenvandine, in python? yes
[16:41] <kenvandine> sort of :)
[16:41] <mhr3> in c, no :P
[16:41] <kenvandine> so i wrote a new friends-service in vala
[16:41] <kenvandine> which is the master for the model
[16:42] <kenvandine> memory usage is low!
[16:42] <kenvandine> and awesome
[16:42] <mhr3> get_row leaks in vala
[16:42] <mhr3> actually, scratch that, it can be double-freed when using from vala
[16:42] <kenvandine> the service never changes the model, it just loads it from the resource manager and shares it
[16:43] <mhr3> that's all my dee leak knowledge
[16:43] <kenvandine> then the python based dispatcher populates it with data when it refreshes
[16:43] <kenvandine> if we leave the dispatcher running all the time
[16:43] <kenvandine> the service barely grows
[16:43] <kenvandine> but, if we make the dispatcher exit after all threads finish
[16:43] <kenvandine> everytime it gets started again to do a refresh
[16:44] <kenvandine> the service grows a bunch
[16:44] <mhr3> hmmm
[16:44] <kenvandine> mhr3, and the larger the model, the bigger the growth each time
[16:44] <kenvandine> if the model has like 8000 rows in it, each time the dispatcher connects to it the service RSS grows by 40M or so
[16:45] <kenvandine> also, my qml based client causes the same thing
[16:45] <mhr3> i'm not sure that's really a leak
[16:45] <mhr3> it might be just fragmented memory
[16:45] <kenvandine> hmm
[16:46] <mhr3> serializing 8000rows will eat up quite a bit of memory
[16:46] <kenvandine> yeahm but does that happen for each slave that connects?
[16:46] <mhr3> yes
[16:46] <kenvandine> and not freed?
[16:47] <mhr3> it does get freed, but if the allocator puts something on top of those 40mb, it wont return it to the os
[16:47] <kenvandine> oh
[16:47] <mhr3> so you'll see ever increasing rss
[16:48] <mhr3> but maybe there is a real leak, only valgrind/massif data will convince me :)
[16:49] <mhr3> with G_SLICE=always-malloc pls ;)
[16:49] <kenvandine> ok
[16:49] <kenvandine> thx
[16:59] <didrocks> mterry: did you succeed this retracing or compiz is slowly building in the vm? :-)
[17:01] <mterry> didrocks, I had to rebuild because my normal nostrip tricks didn't work on compiz.  Rebuilding with pkg-create-dbgsym
[17:02] <didrocks> mterry: oh really? weird, I was using DEB_BUILD_OPTIONS=debug,nostrip which is working with dh7+
[17:02] <didrocks> but yeah, I fall in love with pkg-create-dbgsym :)
[17:06] <mterry> didrocks, I've been cargo-culting this line: DEB_BUILD_OPTIONS=debug,nostrip,noopt CFLAGS="-g -O0" CFLAGS_APPEND="-O0" debuild -i -I
[17:06] <mterry> didrocks, for some reason I've encountered packages that need each of that at one point
[17:07] <mterry> I'm surprised it didn't work on compiz, I might have done something stupid
[17:11] <didrocks> mterry: right noopt, CFLAGS are normally overriden though? I'm surprise this is needed sometimes
[17:12] <didrocks> mterry: anyway, I'll check with infinity as those dbgsym exists somewhere if there is a dirty way to get them when needed without copying to the distro :)
[17:12] <mterry> didrocks, this could have been from years ago.  ::shrug::  Like I said, I've been cargo-culting that line for a long time
[17:12] <didrocks> a dirty way for an ugly hack ;)
[17:12] <didrocks> heh ;)
[17:14] <mterry> Hrm
[17:14] <mterry> "Can't read pathname for load map: Input/output error."
[17:14] <mterry> didrocks, have you ever seen gdb do that? ^
[17:15]  * mterry googles
[17:18] <didrocks> mterry: weird, and if you specify the debug path manually?
[17:25] <mterry> didrocks, it sees the dbg symbols
[17:25] <mterry> didrocks, but I don't get a stacktrace.  So I assumed that message was important.  Google seems to think it's less important...
[17:25] <didrocks> mterry: googline didn't really help here either, maybe check with doko?
[17:26] <didrocks> yeah, it seems "minor" from what I saw, but if you didn't get a stacktrace… ;)
[17:27] <didrocks> mterry: maybe you want to ask pitti for the correct dbgsym, assuming it's the creation being the cause?
[17:35] <didrocks> fginther: is https://code.launchpad.net/~autopilot/autopilot/reintroduce-thomis-make-faster/+merge/146654 stuck? I don't see the autopilot autolanding job running
[17:35] <didrocks> sil2100: FYI ^
[17:35] <kenvandine> mhr3, http://ubuntuone.com/0AQvy3yDmcQCLz3Ejxn6pE
[17:35] <fginther> didrocks, looking
[17:36] <kenvandine> mhr3, i guess it is the serializing
[17:39] <sil2100> Just hope it won't be a problem that we're re-merging the same diff for the second time
[17:40] <sil2100> Since I remember once compiz doing strange things during a merge once just because of things like this
[17:43] <bregma> didrocks, mterry, can you clarify a place where compiz is crashing in the AP tests so we can try to reproduce manually?
[17:45] <mterry> bregma, around 15:33:34 in this log: http://10.97.0.1:8080/job/ps-indicators-autopilot-release-testing/label=autopilot-ati/105/artifact/results/artifacts/ap_test_debug_log.txt
[17:45] <mterry> bregma, which doesn't seem like anything happened by that log
[17:46] <mterry> bregma, I got the timestamp from the .crash file
[17:48] <mterry> bregma, I'm not sure if that timestamp is after apport finished making the .crash file.  So the crash itself might have happened a bit earlier
[17:48] <bregma> there's an awful lot of noise in that log since every single test is failing at startup due to the broken AP change
[17:48] <mterry> bregma, (the .crash file has a "Date" file inside)
[17:48] <mterry> bregma, yeah
[17:49] <mterry> bregma, let me see for the intel crash the day before
[17:50] <bregma> the .crash file shows a smashed stack (untraceable), which usually means either a bad function pointer, and ABI mismatch, or a data walker
[17:50] <fginther> didrocks, https://code.launchpad.net/~autopilot/autopilot/reintroduce-thomis-make-faster/+merge/146654 running now
[17:50] <didrocks> fginther: thanks, are you warned by mmrazik's script about stuck jobs?
[17:50] <mterry> bregma, http://10.97.0.1:8080/job/ps-indicators-autopilot-release-testing/label=autopilot-intel/104/artifact/results/artifacts/ap_test_debug_log.txt
[17:50] <mterry> bregma, 02:42:50 is the Date on that one
[17:51] <fginther> didrocks, yes, this one had not triggered it yet
[17:51] <didrocks> ok :)
[17:52] <mterry> bregma, all tests before that time look normal, except perhaps the very first one: unity.tests.test_panel.PanelCrossMonitorsTests.test_hovering_indicators_on_multiple_monitors
[17:52] <mterry> bregma, it may have taken that long for apport to process the crash file...
[17:56] <bschaefer> how could we confirm its not an ABI break? Could we just update the abi number and assert thats not the problem?
[17:56] <cyphermox> mterry: you'll fix the issue with your a11y branch?
[17:56] <mterry> cyphermox, oh...  let me see what it is
[17:57] <mterry> cyphermox, that was jenkins being dumb.  I'll set to approved
[17:57] <cyphermox> oh, right
[17:58] <cyphermox> alright :)
[17:58] <cyphermox> err, for bootstrap shouldn't it have been revision 42??
[18:00] <mterry> cyphermox, eh, the other commits didn't have anything for jenkins.  I guess 42 would have been fine too
[18:00] <mterry> or more accurate
[18:01] <mterry> cyphermox, in short yes, but it doesn't happen to matter
[18:34] <cyphermox> indeed, it doesn't really matter for this one
[18:35]  * cyphermox dials down the pedanticnessness