| seb128 | hey unity guys | 09:07 |
|---|---|---|
| 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:08 |
| 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:09 |
| 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:10 |
| didrocks | sil2100: IIRC, we had the case with ccp loaded as well last week, isn't it? | 09:12 |
| 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:13 |
| 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:14 |
| seb128 | ok | 09:15 |
| seb128 | sil2100, that doesn't fix it | 09:15 |
| 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:16 |
| 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:18 |
| 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:20 |
| seb128 | do you want to try downgrading compiz to see if that fixes it? | 09:21 |
| sil2100 | seb128: yes, please, that would give us certainity at least | 09:22 |
| 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:32 |
| seb128 | sil2100, smspillaz, didrocks: it's an issue in libcompizconfig0 | 09:36 |
| 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:37 |
| sil2100 | seb128: I cannot reproduce it here | 09:42 |
| 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:43 |
| 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:44 |
| 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:46 |
| sil2100 | Have to refresh my memory how these things work | 09:47 |
| 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:49 |
| 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:50 |
| MCR1 | duflu: Will you come back to Compiz some day ? I miss your input ! | 09:53 |
| duflu | MCR1: Sorry, I'm busy with a whole new job. Can't do both | 09:54 |
| MCR1 | duflu: I wish you the best and still hope to see you come back some day ;) | 09:55 |
| 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:01 |
| 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:02 |
| MCR1 | Sure, that is (and should be) the right of a free man :) | 10:03 |
| === zequence_ is now known as zequence | ||
| seb128 | sil2100, did you see cjwatson's comment on bug #878052 | 10:24 |
| ubot5 | 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 |
| sil2100 | seb128: oh, thanks for pointing it out! | 10:24 |
| seb128 | yw ;-) | 10:24 |
| 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:26 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| didrocks | seb128: normally mterry, cyphermox and other are watching the MP | 10:34 |
| didrocks | are picking when things mismatch | 10:34 |
| 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:35 |
| seb128 | brb, restarting my session | 10:37 |
| 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:48 |
| seb128 | let me try | 10:51 |
| seb128 | bah | 10:56 |
| seb128 | sil2100, sorry, it started working, can't reproduce even with the newer version | 10:56 |
| 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:57 |
| sil2100 | seb128: hm, maybe, but still it's wondering why gsettings is fine, but the dconf backend was left in a broken state | 10:58 |
| 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:02 |
| sil2100 | seb128: could you just check what are the contents of compizconfig/done_upgrades ? | 11:03 |
| 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:04 |
| === mmrazik is now known as mmrazik|lunch | ||
| BigWhale | I need an expert on Panel and Launcher ... Or someone to tell me how to figure our their sizes. :) | 11:39 |
| 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:40 |
| 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:41 |
| BigWhale | Probably some Gdk call that inspects unity-panel and unity-launcher windows? | 11:42 |
| 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. | 11:43 |
| === mmrazik|lunch is now known as mmrazik | ||
| sil2100 | BigWhale: ok, so, hm, the only way I know to fetch the launcher and/or panel size is through dbus introspection | 12:07 |
| 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:08 |
| sil2100 | You could of course not use that, but simply python-autopilot already has everything set up | 12:09 |
| sil2100 | BigWhale: http://paste.ubuntu.com/5570303/ | 12:10 |
| BigWhale | if you have something ready then sure | 12:10 |
| 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:11 |
| === _salem is now known as salem_ | ||
| 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:15 |
| sil2100 | BigWhale: ah, right, on quantal it's different, let me change it a bit | 12:16 |
| 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:18 |
| 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:20 |
| sil2100 | But as I said, there were some big changes in raring autopilot so now I can't really test it | 12:21 |
| 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:23 |
| sil2100 | BigWhale: yes, we're using dbus for unity introspection for testing in Python, so it's all available there | 12:25 |
| 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:41 |
| sil2100 | BigWhale: no problem! Let us know when you have your thing ready ;) | 12:42 |
| 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:13 |
| 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:16 |
| jibel | there is no test ATM. I agree it's worth writing some since it's moving to a wider usage. | 13:17 |
| 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 | 13:36 |
| 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:31 |
| 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:32 |
| 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:40 |
| 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:41 |
| sil2100 | didrocks: so, I think we'll stick to ~, since indeed the plans for 7.0 haven't been realized yet | 14:48 |
| 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:49 |
| 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:50 |
| mmrazik | didrocks, jibel, fginther: could you please have a look: https://code.launchpad.net/~mrazik/cupstream2distro-config/testing/+merge/150813 | 14:51 |
| sil2100 | didrocks: pushed ;) | 14:57 |
| didrocks | mmrazik: answered. Also, I think what we should do for the template it to have a mustache/jinja-like system | 14:58 |
| 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 | 14:59 |
| didrocks | sil2100: approved! thanks :) | 15:00 |
| sil2100 | didrocks: thanks for the review, and good pointing out the ~ ;) | 15:00 |
| didrocks | yw ;) | 15:01 |
| 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:09 |
| mterry | sil2100, w000! unity-ati is down to 12 test failures | 15:17 |
| smspillaz | MCR1: need to go to bed now though | 15:17 |
| 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:19 |
| 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:21 |
| 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:23 |
| 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:25 |
| cyphermox | mterry: it will be good, I'll run a rebuild of it now | 15:26 |
| 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:40 |
| didrocks | mmrazik: reviewed | 15:41 |
| didrocks | mmrazik: but yeah, this kind of dictionnary approach for feeding everything would be interesting and way more flexible | 15:42 |
| 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:44 |
| * 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:45 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| didrocks | "command {% if FastTrack %} --fasttrack {% endif %}" | 15:51 |
| didrocks | mmrazik: ^ | 15:51 |
| mmrazik | yup | 15:51 |
| 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:52 | |
| 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:54 |
| 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:57 |
| didrocks | yw ;) | 15:58 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| mmrazik | jibel: by runner you mean a (shell) script that will execute the tests? | 17:33 |
| jibel | mmrazik, yes, something that calls python -m unittest tests.name | 17:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| didrocks | mmrazik: https://pypi.python.org/pypi/nose_scenario/ | 17:38 |
| mmrazik | didrocks: not in raring :-/ | 17:39 |
| didrocks | yeah, just checked :/ | 17:39 |
| jibel | mmrazik, of course, pyruntest is fine | 17:41 |
| mmrazik | jibel: I've added this: http://bazaar.launchpad.net/~mrazik/cupstream2distro-config/testing/revision/16 | 17:43 |
| jibel | mmrazik, can you change cd .. by cd $(dirname $0)/.. | 17:47 |
| jibel | and it's all good | 17:47 |
| mmrazik | jibel: fixed | 17:49 |
| mmrazik | in r17 | 17:49 |
| jibel | mmrazik, approved. thanks | 17:51 |
| 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:16 | |
| * 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:17 |
| 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:18 |
| 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:19 |
| 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:20 | |
| 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:21 |
| cyphermox | cool | 18:22 |
| davidcalle | kenvandine, ping | 19:11 |
| sil2100 | ;) | 19:17 |
| === salem_ is now known as _salem | ||
| sil2100 | mterry: I'm now trying to get rid of the 3 remaining ibus failures | 19:52 |
| * mterry hugs sil2100 | 19:52 | |
| 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 | 19:53 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| 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:19 |
| 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:20 |
| 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:21 |
| cyphermox | why do you mean? | 20:22 |
| bregma | I guess he's assuming the variadic list is NULL-terminated | 20:28 |
| bregma | cyphermox, yes, I'd say that change is the right thing to do | 20:31 |
| cyphermox | bregma: aye | 20:45 |
| 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:46 |
| bregma | don't they just get stripped out by the packaging? | 20:49 |
| cyphermox | bregma: nah | 21:18 |
| cyphermox | also, there was a reason for that test actually :) | 21:18 |
| bregma | it's still an invalid test, because there is no guarantee a va_list is convertible to an arithmetic type | 21:20 |
| 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:35 |
| bregma | according to the standard, it's undefined behaviour | 21:36 |
| cyphermox | yeah | 21:43 |
| cyphermox | well the test *might* work but I think it's catching the wrong overloaded function | 21:44 |
| cyphermox | ie. the one with a va_list parameter rather than the one with a string vector | 21:45 |
| * cyphermox is very sad | 21:46 | |
| bregma | cyphermox, let me play with it a bit | 21:48 |
| 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:49 |
| 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:50 |
| 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? | 21:56 |
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!