[09:07] hey unity guys [09:08] smspillaz: ping! [09:08] seb128: hello ;) [09:08] is there any issue with the updates from yesterday in raring? [09:08] my compiz is "empty" [09:08] it's running but no plugin seems loaded [09:08] no decoration, no workspace, no unity [09:08] works in a guest session though [09:08] Again? [09:08] Seems like a configuration issue again, shit [09:09] Let me upgrade and take a look [09:09] smspillaz: ^ [09:09] sil2100, is there any debug info I can get while it's broken? [09:10] seb128: could you, just to make sure, fetch .xsession-errors from your main session? Just to make sure it's the same thing [09:10] The same bug [09:10] compiz (core) - Info: Loading plugin: core [09:10] compiz (core) - Info: Starting plugin: core [09:10] compiz (core) - Info: Loading plugin: ccp [09:10] compiz (core) - Info: Starting plugin: ccp [09:10] that's the only compiz output in that log [09:10] hm [09:10] So it's different, since ccp is being loaded [09:12] sil2100: IIRC, we had the case with ccp loaded as well last week, isn't it? [09:13] didrocks: well, last week ccp wasn't loaded, but Sam fixed it that ccp is loaded by default now - but yes, it seems to be the same configuration issue [09:13] Would be best if smspillaz could comment here though [09:13] I'll check if I can reproduce [09:13] it doesn't happen in a guest session for the record [09:14] but I rebooted with my user and it seems consistent with that user [09:14] going to a vt and running "unity" leads to the same output/situation [09:14] seb128: could you try moving .config/compiz-1 somewhere else? [09:14] I first did that because I though compiz was not running [09:14] At your user? [09:15] ok [09:15] sil2100, that doesn't fix it [09:16] running "unity" prints also those lines [09:16] "compizconfig - Info: Backend : gsettings [09:16] compizconfig - Info: Integration : true [09:16] compizconfig - Info: Profile : unity" [09:16] but it's loading none of the plugins still [09:18] seb128: could you fetch the active-plugins variable from gsettings? I think something like: gsettings get org.compiz.core:/org/compiz/profiles/unity/core active-plugins [09:20] ['core', 'composite', 'opengl', 'compiztoolbox', 'decor', 'vpswitch', 'snap', 'mousepoll', 'resize', 'place', 'move', 'wall', 'grid', 'regex', 'imgpng', 'session', 'gnomecompat', 'animation', 'fade', 'unitymtgrabhandles', 'workarounds', 'scale', 'expo', 'ezoom', 'unityshell'] [09:20] sil2100, ^ [09:20] geh [09:20] hm [09:20] seb128: thanks, looking what could have caused this [09:21] do you want to try downgrading compiz to see if that fixes it? [09:22] seb128: yes, please, that would give us certainity at least [09:32] sil2100, downgrading the compiz binaries fix it [09:32] didrocks, smspillaz: ^ [09:32] at least, the config is good [09:32] if we can't fix it promptly, I think we'll have to revert compiz and block the version [09:36] sil2100, smspillaz, didrocks: it's an issue in libcompizconfig0 [09:37] downgrading only that one brings me back a working compiz [09:37] using dpkg -i --force-depends [09:37] to force install it aside the new compiz [09:42] seb128: I cannot reproduce it here [09:43] So it has to be one of those stupid special-case configuration issues, broken during upgrade [09:43] sil2100, well, I can [09:43] I moved my .config/compiz-1 away [09:43] what other config is stored and could have an issue? [09:44] seb128: good question, since gsetting has correct values [09:44] Let me re-start my session to be sure [09:44] could as well be timing issue [09:44] e.g not specific to the config [09:46] smspillaz: Hi :) Congratulations for the xmbc success and top job on the first speed optimizations that have landed in Compiz. Top job !!! [09:46] Still working here, hmmm [09:47] Have to refresh my memory how these things work [09:49] smspillaz: Yes, I have troubles with implementing correct damage handling as I am not sure how to do it... :( Plugins like resize or thumbnail seem to use it, but resize has a completely other structuring and thumbnail still flickers, so I am not sure if it is correctly implemented there... [09:49] Greetings. Is there a way to to get height of Panel and width of Launcher in pixels? [09:50] smspillaz: So I would prefer that you fix the FIXME and I would study your implementation then to understand how it exactly is supposed to work... [09:53] duflu: Will you come back to Compiz some day ? I miss your input ! [09:54] MCR1: Sorry, I'm busy with a whole new job. Can't do both [09:55] duflu: I wish you the best and still hope to see you come back some day ;) [10:01] duflu: Your work for Compiz was awesome and you did a great job on reviving, stabilizing and improving it. Every Compiz user owes you something... Keep on rocking, whatever code you're hacking on currently :) [10:02] MCR1: Thanks. I am trying to rock. But I do value my sanity and personal time so made a conscious decision to only take on one job at a time. And right now that's not Compiz. [10:03] Sure, that is (and should be) the right of a free man :) === zequence_ is now known as zequence [10:24] sil2100, did you see cjwatson's comment on bug #878052 [10:24] bug 878052 in unity-lens-files (Ubuntu Quantal) "Content of hidden folders shown in unity-lens-files" [Undecided,New] https://launchpad.net/bugs/878052 [10:24] seb128: oh, thanks for pointing it out! [10:24] yw ;-) [10:26] it's a bit weird that with the daily landing the version numbers are never rebased on the current tarball [10:26] there are a bunch of stuff on the desktop version page which are flagged "outdated" due to that as well [10:26] didrocks, ^ should we just submit a mr that bump the changelog "upstream version part" for those? [10:30] sil2100, is there any news on the compiz issue? or waiting for smspillaz to be around? I'm concerned it breaks other users as well if it still this way in raring [10:31] seb128: I'm tracking the code, if smspillaz was around it would make things much much faster though ;) [10:31] sil2100, what changed in libcompizconfig recently? [10:31] it something that changed in there last week that broke it apparently [10:32] seb128: it should be aligned in changelog with what is in configure.ac [10:32] and people need to take care of that when bumping [10:32] it's in the FAQ https://wiki.ubuntu.com/DailyRelease/FAQ [10:33] didrocks, ok, I guess nobody does atm [10:33] seb128: there was a change, but that change was actually fixing a similar problem, since the configuration handling in compiz is a bit confusing [10:34] seb128: normally mterry, cyphermox and other are watching the MP [10:34] are picking when things mismatch [10:35] didrocks, maybe those are pre-dating the time everybody was familiar with the system [10:35] didrocks, like unity-lens-files was released mid january [10:37] brb, restarting my session [10:48] seb128: can you still get a broken compiz somehow? [10:48] seb128: could you break your compiz and do a quick `dconf read /org/compiz/profiles/unity/plugins/core/active-plugins` ? [10:48] And `dconf read /org/compiz/current-profile` [10:51] let me try [10:56] bah [10:56] sil2100, sorry, it started working, can't reproduce even with the newer version [10:57] when I tried before it was without restarting my session, I wonder if moving .config/compiz-1 away and restarting the session triggered a dconf update as well [10:58] seb128: hm, maybe, but still it's wondering why gsettings is fine, but the dconf backend was left in a broken state [11:02] I wonder if its again because of the upgrades [11:02] seb128: do you still have the old compiz-1 directory? [11:02] sil2100, yes, I put it back in place and restarted my session, still not buggy [11:03] seb128: could you just check what are the contents of compizconfig/done_upgrades ? [11:04] com.canonical.unity.unity.01.upgrade [11:04] com.canonical.unity.unity.02.upgrade [11:04] com.canonical.unity.unity.03.upgrade === mmrazik is now known as mmrazik|lunch [11:39] I need an expert on Panel and Launcher ... Or someone to tell me how to figure our their sizes. :) [11:40] BigWhale: hi! Where do you want to use the sizes? [11:40] And from where ;) ? [11:40] sil2100, python, pygobject [11:40] (i.e. what language) [11:40] Ah, one moment then [11:41] I'm trying to draw a window on screen with coordinates 0,0 and compiz will push that window away from panel and launcher [11:41] so I need to recalculate width and height of my window to compensate [11:42] Probably some Gdk call that inspects unity-panel and unity-launcher windows? [11:43] BigWhale: give me a minute to finish something up and I'll try looking into this and getting back to you [11:43] sil2100, sure, take your time! Thanks. === mmrazik|lunch is now known as mmrazik [12:07] BigWhale: ok, so, hm, the only way I know to fetch the launcher and/or panel size is through dbus introspection [12:08] sil2100, I use dbus already to check if an instance of Kazam is running, so this shouldn't be a problem. [12:08] BigWhale: I can paste-bin you an example, but it depends on the python-autopilot Ubuntu package [12:09] You could of course not use that, but simply python-autopilot already has everything set up [12:10] BigWhale: http://paste.ubuntu.com/5570303/ [12:10] if you have something ready then sure [12:11] BigWhale: I'm simply using DBusIntrospectionObject from autopilot, it makes writing this faster - but you can actually take a look into the autopilot source and do it yourself === _salem is now known as salem_ [12:15] sil2100, is this supposed to work on Quantal too? [12:15] AttributeError: type object 'Unity' has no attribute 'get_root_instance' [12:15] this is what I am getting. [12:16] BigWhale: ah, right, on quantal it's different, let me change it a bit [12:18] hmm, perhaps I will not need it for quantal anyway [12:18] some other code that I need isn't in quantal [12:20] BigWhale: if you want to try it on quantal, then you can try (not sure if it'll work, since I don't remember now the details) instead of using unity = Unity.get_root_instance() use directly a Unity() object [12:20] i.e. l = Unity().launcher.get_launchers() directly [12:21] But as I said, there were some big changes in raring autopilot so now I can't really test it [12:23] sil2100, well the info about getting the size from dbus is more than enough. I think it is also more convenient than using Gdk/Xlib [12:25] BigWhale: yes, we're using dbus for unity introspection for testing in Python, so it's all available there [12:41] sil2100, I have something that is probably going to work. Thanks for help. I'll be implementing this in a couple of days. :) [12:42] BigWhale: no problem! Let us know when you have your thing ready ;) [13:13] didrocks: there aren't really any tests for the cu2d-update-stack stuff, are there? [13:13] (specifically for this command) [13:13] handling the defaults etc, is worth of writing some tests.. [13:13] mmrazik: hum, I don't think so, jibel? ^ [13:16] didrocks, jibel: we will probably need to split the code and methods into some sort of cu2dutils.py module so we can import and test the methods on their own [13:17] there is no test ATM. I agree it's worth writing some since it's moving to a wider usage. [13:36] didrocks: could you take a look and correct me here? https://code.launchpad.net/~sil2100/unity-lens-files/upstream_bump/+merge/150795 [13:36] ;) [13:36] didrocks: since I wanted to bump the upstream version [14:31] sil2100: do we assume 7.0 is released? [14:31] https://wiki.ubuntu.com/DailyRelease/FAQ FYI [14:31] (what was on my blog posts ;) [14:31] there is the answer :p [14:31] agreed in dropping the last .0 though, if everything still works well :) [14:32] sil2100: but if we think that 7.0 isn't released, you should use ~ [14:32] sil2100: just tell me, if it's released for you, I think we can approve :) [14:40] didrocks: yea, that was the tricky part that I didn't understand - well, it's not released, but how will it be? Will the auto-uploader release it once it's out? [14:41] didrocks: or should we create a tarball for it and upload to LP manually? [14:41] sil2100: no, it's more a feeling as "we are at 7.0 now" [14:41] sil2100: as some people like pre-bumping, some post-bumping :) [14:41] Ok, let's ask mhr3 and pstolowski [14:41] ;) [14:41] I would go for released TBH ;) [14:48] didrocks: so, I think we'll stick to ~, since indeed the plans for 7.0 haven't been realized yet [14:49] didrocks: there are some changes planned that need to happen before 7.0 is ready I think, let's be safe and add ~ ;) [14:49] sil2100: tell me once you pushed that :) [14:49] are you talking unity 7.0? [14:50] bregma: unity-lens-files currently [14:50] ah, OK [14:50] we need to discuss plans for unity 7.0 release, and what that means [14:50] maybe a topic for "UDS" [14:51] didrocks, jibel, fginther: could you please have a look: https://code.launchpad.net/~mrazik/cupstream2distro-config/testing/+merge/150813 [14:57] didrocks: pushed ;) [14:58] mmrazik: answered. Also, I think what we should do for the template it to have a mustache/jinja-like system [14:59] mmrazik: meaning, we don't export everything in a dict a pass one parameter after another, but just pass the dict to the template [15:00] sil2100: approved! thanks :) [15:00] didrocks: thanks for the review, and good pointing out the ~ ;) [15:01] yw ;) [15:09] MCR1: workspacenames.cpp:93-121 - you can split that into a separate method and get the x,y,width,height co-ords of the textbox [15:09] then you can use damageRegion (CompRegion (x,y,w,h)) [15:17] sil2100, w000! unity-ati is down to 12 test failures [15:17] MCR1: need to go to bed now though [15:19] smspillaz: I would prefer to do it in a separate branch... IIRC my main problem when I tried was that damagescreen is called in three classes and I did not know how to best pass the values of the calculated rectangle... [15:19] MCR1: what do you mean by "you didn't know how to best pass the values of the rectangle" [15:21] \o/ [15:21] smspillaz: I would have to look at it again, I do not remember the details... I will take it on once again... [15:21] MCR1: its pretty straightforward [15:21] cScreen->damageRegion (CompRegion (x, y, width, height)) [15:23] but x and y and width and height are calculated in WSNamesScreen::drawText, but I need them in 3 other classes... I do not know how to solve that most elegantly... [15:25] make a new method [15:25] WSNameScreens::getTextPosition or something [15:25] splitting the calculation of the damage rectangle into a seperate method maybe and calling that... but it is needed 3 times, so it would be better to calculate the values and store them, no ? [15:25] *separate [15:25] cyphermox, is ido OK? [15:25] MCR1: *shrug* just have a separate method for calculating the values [15:25] can't be that hard [15:25] ok [15:26] mterry: it will be good, I'll run a rebuild of it now [15:40] didrocks: can you please have a 2nd look: https://code.launchpad.net/~mrazik/cupstream2distro-config/testing/+merge/150813 ? I'd like to continue that direction and refactor cu2d-update-stack so we can reuse e.g. the load defaults logic [15:40] didrocks: when thinking about the failing testcase -- I actually start to think its just too weird use-case and the test should be deleted [15:40] mterry: cyphermox: FYI, I added some new silver bullets in the distro version check, on both the publisher job and the distro version. I had to sneak in and change the .project files for unpublished jobs in between [15:40] mmrazik: agreed on the failing one [15:41] mmrazik: reviewed [15:42] mmrazik: but yeah, this kind of dictionnary approach for feeding everything would be interesting and way more flexible [15:44] didrocks: not quite sure what you mean [15:44] mmrazik: like, in the current template feeding, we have all keys/values pairs hardcoded and sent [15:44] jibel: btw. your POV on https://code.launchpad.net/~mrazik/cupstream2distro-config/testing/+merge/150813 would be appreciated [15:44] mmrazik: I think a mustache/jinja approach would be better [15:45] * mmrazik is not very familiar with mustache/jinja but he is googling [15:45] mmrazik: django? the template system is similar [15:45] mmrazik, looking [15:47] didrocks: I have to look on the templates. But I had an impression its using jinja, isn't it? [15:47] embarassing but I still don't understand what you mean :-/ [15:48] mmrazik: oh, yeah, it's using jinja, I didn't notice :) (proof I didn't wrote it) [15:48] mmrazik: so we can really have something more generic, instead of passing all values one by one [15:48] like template(foo=foo_value, bar=bar_value) [15:48] we can pass a dict [15:48] and in the template have [15:49] baz.foo [15:49] baz.bar [15:49] to avoid hardcoding all values in the script [15:49] didrocks: ack [15:49] didrocks: even though there are few cases where it might be desirable [15:50] e.g. the Fasttrack: True is translated into --fasttrack as a command line option to the autolander [15:50] mmrazik: we can still pass the full dict, then the template is picking only what it need [15:50] didrocks: understood [15:50] mmrazik: you can have {% if %} logic [15:50] like: [15:50] fginther: ^^ [15:50] didrocks: right... got it [15:51] "command {% if FastTrack %} --fasttrack {% endif %}" [15:51] mmrazik: ^ [15:51] yup [15:52] mhm... looks like I"m going to have my 2nd system crash right now. The only window that can get focus right now is my xchat window :) [15:52] * mmrazik will be right back [15:54] mmrazik, didrocks ack on the use of the dict vs individual values [15:54] I like this templating system, but have little experience to really use it well [15:57] fginther: I've quite some experience with it, if you need help, do not hesitate. Not a lot of things we could have used in our daily release template, but I guess it's more worthy on yours [15:57] didrocks, thanks. [15:58] yw ;) === salem_ is now known as _salem === _salem is now known as salem_ [17:33] jibel: by runner you mean a (shell) script that will execute the tests? [17:34] mmrazik, yes, something that calls python -m unittest tests.name [17:35] so we don't have excuses not to run them :) [17:35] jibel: can I depend on something like pyruntest (nosetests have a bug when it comes to scenarios in the tests)? [17:36] the difference between python -m unittest is that it tried to find tests [17:36] while with unittest you need to specify exactly what you need [17:36] so you can just run "pyruntest tests" and it will execute everything [17:36] autopilot does the same [17:37] +pyruntest can generate coverage etc [17:37] * didrocks is pushing for nosetests :) [17:37] didrocks: scenarios are really nice [17:37] didrocks: and nosetests makes some stupid assumptions [17:37] its probably a bug [17:37] mmrazik: oh, really? [17:37] didrocks: the tests I wrote are not going to work with nosetests [17:37] mmrazik: as told on the previous MP, I don't really know the scenarios [17:37] unless it got fixed in raring [17:37] nope.. it fails [17:38] mmrazik: https://pypi.python.org/pypi/nose_scenario/ [17:39] didrocks: not in raring :-/ [17:39] yeah, just checked :/ [17:41] mmrazik, of course, pyruntest is fine [17:43] jibel: I've added this: http://bazaar.launchpad.net/~mrazik/cupstream2distro-config/testing/revision/16 [17:47] mmrazik, can you change cd .. by cd $(dirname $0)/.. [17:47] and it's all good [17:49] jibel: fixed [17:49] in r17 [17:51] mmrazik, approved. thanks [18:16] mterry: no manual publishing of the unity stack? blocked by indicators? or do you prefer making that while I'm asleep so that I don't get stressed? :) [18:16] * sil2100 checks indicators [18:17] * sil2100 sees that build 147 has no failures, but ati and intel failed [18:17] ;/ [18:17] sil2100: there is not only tests! [18:17] sil2100: ido FTBFS [18:17] 148 failed with intel too [18:18] oh, there's a FTBFS somewhere? [18:18] didrocks, eh... I figured we pushed yesterday, there was no rush, might as well let indicators get caught up and do it right [18:18] mterry: yeah, but if something bad happens in the code, we'll have to bisect by 2 days rather than 1 :) [18:18] mterry: but yeah, I think cyphermox is looking after lunch on the armhf failure on ido [18:18] yeah, he said he was on it [18:19] yeah [18:19] didrocks, we're down to only 13 test failures on ati, and 18 on nvidia! [18:19] need to fix that piece of code up to work on arm [18:19] mterry: yeah, that rocks \o/ [18:19] I don't know why this particular thing wouldn't , it's weird [18:19] mterry: I just hope I didn't screw up in the new format of synchronizing and double checking with my new cupstream2distro code :) [18:19] didrocks, sil2100, I'm experimenting with a test failure threshold of 20, with 8 regressions. Let's see if that causes any problems [18:20] so if you see some scripts failing, just blame on me, I'll write a test and fix it :p [18:20] didrocks, heh, OK [18:20] * mterry notes down that all failures are didrock's fault [18:21] hem, s/all/cupstream2distro/ :p [18:21] didrocks, I'm pretty sure I heard all [18:21] tsss ;) [18:21] oh btw [18:21] Ran 61 tests in 2.223s [18:21] mterry: cyphermox ^ [18:21] still more to go on cupstream2distro, but a good start :) [18:21] oh nice [18:22] cool [19:11] kenvandine, ping [19:17] ;) === salem_ is now known as _salem [19:52] mterry: I'm now trying to get rid of the 3 remaining ibus failures [19:52] * mterry hugs sil2100 [19:53] Let's go down to 0 soon! [19:53] \o/ [19:53] For now, I go eat dinner [19:53] See you tomorrow [19:53] sil2100, bye === _salem is now known as salem_ === salem_ is now known as _salem === _salem is now known as salem_ [20:19] bregma: hey [20:19] 'sup [20:19] bregma: can I have your opinion on a small change in xorg-gtest? :) [20:19] http://paste.ubuntu.com/5571551/ [20:19] seems like the if (args) is causing ido to fail to build on armhf [20:20] what error does it give? [20:20] but I don't think it's that necessary to check for whether args is actually set (and that way, fails on arm anyway) [20:20] https://launchpadlibrarian.net/132514701/buildlog_ubuntu-raring-armhf.ido_12.10.3daily13.02.27.1-0ubuntu1_FAILEDTOBUILD.txt.gz [20:20] could do another way, but feels to me like it's probably unnecessary [20:21] ie. Start() with va_list is used by the other implementations of Start() which would create it anyway [20:21] actually, I don;t think they're using varargs right anyway [20:22] why do you mean? [20:28] I guess he's assuming the variadic list is NULL-terminated [20:31] cyphermox, yes, I'd say that change is the right thing to do [20:45] bregma: aye [20:46] I'll upload this, so we can have ido build tomorrow [20:46] continuing to work on cleaning up xorg-gtest to not ship the same files as gtest in parallel [20:49] don't they just get stripped out by the packaging? [21:18] bregma: nah [21:18] also, there was a reason for that test actually :) [21:20] it's still an invalid test, because there is no guarantee a va_list is convertible to an arithmetic type [21:35] bregma: right, but there is a test in the test suite that relies on that if >.< [21:35] then the test is broken ... hardly the first time [21:36] according to the standard, it's undefined behaviour [21:43] yeah [21:44] well the test *might* work but I think it's catching the wrong overloaded function [21:45] ie. the one with a va_list parameter rather than the one with a string vector [21:46] * cyphermox is very sad [21:48] cyphermox, let me play with it a bit [21:49] I'm running a test under sbuild on armhf [21:49] args is just NULL in that case, we can catch for this corner case [21:50] I think any other one will be correctly handled as usual [21:50] what bothers me is why this started to fail in ido just this week [21:56] awesome, cross-checking, it's failing in xorg-gtest on armhf right away, that's good news [21:56] at least I can verify a proper fix immediately without having to rebuild that and ido [21:56] new compiler version? === salem_ is now known as _salem