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