[07:07] <MacSlow> greetings everybody
[07:11] <mzanetti> good morning
[07:14] <MacSlow> mzanetti, mahlzeit
[07:15] <mzanetti> MacSlow: :)
[07:28] <tsdgeos> MacSlow: your branch now fails in CI for a different reason than the crash
[07:37] <MacSlow> tsdgeos, arg
[07:38] <MacSlow> tsdgeos, I'll look into it once I'm through with all the emails
[07:38] <jamesh> Anyone mind doing a quick review of a Unity branch to optionally remove the ratings from movie previews? https://code.launchpad.net/~jamesh/unity/bug-1178046/+merge/163260
[07:38] <jamesh> This is to help us get some of the scope previews to match what design wants
[09:44] <nayfennarkotix> My unity suggestion; You should alter unity tweak tool, instead of changing the entire OS unity tweaks on the spot, make a little box appear that shows the change, than make it so you can enable the change. Please do this. Unity tweaks freeze low grade laptops easily. This gets very annoying very quick.
[09:45] <Mirv> Saviq: remembered the shell-interfaces again. the real solution is to just remove the .install file (add back if adding another binary package to build from the source)
[09:45] <Mirv> pushed that
[09:46] <nayfennarkotix> It would use alot less memory usage though to do this. All I have for my personal computer is a crappy 170$ acer and wont be getting a new one for a good month sadly. Lots of crashes, I understand it's hardware, but my low grade stuff can also give you good ideas to make things faster right?
[09:47] <nayfennarkotix> Plus everything you just said to me was so vastly confusing it's not even funny.
[09:50] <nayfennarkotix> Plus i'm not the only one in this situation remember. I got linux for, compiz, unity, VLC, and amarok, protection (Main root issue of why I left windows, their shit)
[09:54] <Saviq> Mirv, thanks!
[10:00] <Saviq> popey, ping
[10:00] <popey> Saviq: pong
[11:31] <tsdgeos> sergiusens: ping
[11:43] <tsdgeos> Saviq: https://codereview.qt-project.org/#change,55959
[11:45] <tsdgeos> greyback: ↑↑
[11:45] <Saviq> tsdgeos, awesome!
[11:46] <greyback> tsdgeos: aha, nice
[11:56] <mhr3> sil2100, what's up with ap tests? are they really using 1.3 now, or not really or what's going on there?
[11:57] <mhr3> sil2100, i mean utah
[11:57] <sil2100> mhr3: they should be using 1.3, but we're having some UTAH issues again - so for instance the Head AP test just failed because of UTAH
[11:58] <sil2100> mhr3: I already informed the QA team about that
[11:58] <sil2100> mhr3: waiting for some update, but it seems again UTAH notices 'failure' too soon and aborts
[11:59] <mhr3> sil2100, hm, so how come that for example 100scopes tests were ok for ati even though we don't have the ap test changes that veebers did
[12:00] <sil2100> mhr3: I'll double check, but I think the 100scopes stack uses the experimental PPA which does not have AP 1.3 in it
[12:01] <sil2100> mhr3: AP 1.3 is in daily-build-next right now
[12:01] <mhr3> sil2100, ok, that would explain it
[12:14] <sergiusens> tsdgeos: pong
[12:42] <sil2100> mhr3: do we have the final ACK from JohnLea ?
[12:45] <sil2100> robru: ping
[12:49] <JohnLea> sil2100; mhr3 is coming into the office at 16:00 today and me and him are going to spend 2 hours doing a end to end review.  Will send an email as soon as this is complete
[12:53] <tsdgeos_> sergiusens: https://launchpad.net/~phablet-team/+archive/ppa/+build/4566060 is waiting because doesn't know about libhudclient-2, sahll we add the daily-build-next ppa there or?
[12:57] <sergiusens> tsdgeos: yes, I removed it a while back due to a problem in the PPA which should be fixed now
[13:00] <tsdgeos> cool
[13:00] <MacSlow> tsdgeos, btw regarding the failed test for the notification-renderer... tried it locally... no issue at all... working fine. Anyway... the last failure is pretty odd... checking for the wrong return-value of an "action-id"... as if something changed the ordering, which of course didn't happen.
[13:00] <sergiusens> tsdgeos: should be building soon
[13:01] <tsdgeos> sergiusens: awesome
[13:01] <mzanetti> tsdgeos: https://code.launchpad.net/~mzanetti/unity/phablet-autopilot-1.3/+merge/163524
[13:02] <MacSlow> tsdgeos, and right now my custom test-build on jenkins failed because "xinit: connection to X server lost"
[13:03] <tsdgeos> MacSlow: weird
[13:03] <MacSlow> mzanetti, tsdgeos: is there something I need to change in the build-job setup?
[13:04] <mzanetti> MacSlow: huh?
[13:04] <MacSlow> mzanetti, some flag/option to set or unset?
[13:05] <mzanetti> MacSlow: no... don't think so... this is some weird bug somewhere in xcb
[13:05] <MacSlow> mzanetti, i'll try a restart of the job
[13:09] <sil2100> JohnLea: thanks for the info! Will be waiting for that e-mail ;)
[13:10] <tsdgeos> MacSlow: mzanetti: can you guys pull from launchpad?
[13:10] <tsdgeos> i'm getting
[13:10] <tsdgeos> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[13:10] <MacSlow> tsdgeos, about 10 minutes ago I could
[13:10] <MacSlow> tsdgeos, didn't try it just now
[13:10] <mzanetti> tsdgeos: seems to work here
[13:11] <MacSlow> tsdgeos, just tried again... still works for me too
[13:11] <tsdgeos> :/
[13:11]  * tsdgeos reboots
[13:12] <mzanetti> sil2100: the generic-mediumtests job is now updated to execute autopilot 1.3 on raring. feel free to reenable apps autopilot tests ;)
[13:12] <sil2100> mzanetti: \o/ Awesome ;)
[13:23] <tsdgeos> works now
[13:40] <sil2100> fginther: hello! It seems there is some new/old bug with UTAH in the generic jobs again...
[13:40] <nic-doffay> Branch if anyone is interested! https://code.launchpad.net/~unity-team/unity/infographics-with-lightdm
[13:41] <sil2100> fginther: the symptoms are similar, already informed jcollado
[13:41] <sil2100> fginther: he said he'll send an e-mail about it to you and me, but not sure
[13:41] <nic-doffay> https://code.launchpad.net/~unity-team/unity/infographics-with-lightdm/+merge/163308 review here
[13:41] <fginther> sil2100, I saw the other thread. Do we need to debug it as it runs?
[14:32] <vesar> Hi, I'm trying to compile the latest build and facing issues with some cmake paths. The build fails and I get something like this: https://pastebin.canonical.com/90873/
[14:33] <greyback> vesar: sorry if stupid question, but is libqt5network5 installed?
[14:33] <tsdgeos_> vesar: grumble grumble canonical.com
[14:33] <tsdgeos_> need to find the dongle for 2factor
[14:34] <greyback> vesar: the required file is in qtbase5-dev
[14:34] <vesar> greyback, they should be both installed
[14:35] <vesar> Has anybody else seen smth similar. Any pointers how to fix. In that error message it complains about Qt5NetworkConfig.cmake file. First I had similar issues with Qt5Core and Qt5Qml also.
[14:36] <greyback> vesar: I'd "bzr clean-tree --ignore" first, to remove any cmake cache files first
[14:36] <greyback> vesar: or by hand, delete CMakeCache and CMakeFiles, then re-run cmake.
[14:38] <vesar> greyback, ok that first did the trick. Damn it's easy when you know what to do.
[14:38] <vesar> greyback, thank you again!
[14:39] <greyback> vesar: I suspect it's due to the fact you upgraded Qt today. When that happens, cmake's cache can get confused
[14:39] <greyback> your're welcome
[14:40] <Saviq> tsdgeos_, need a second pair of eyes again (possible moc not knowing C++ issue :/)
[14:40] <Saviq> tsdgeos_, lp:~saviq/+junk/unity-apis-notifications
[14:41] <Saviq> tsdgeos_, http://pastebin.ubuntu.com/5661408/
[14:43] <tsdgeos_> Saviq: looking
[14:45] <tsdgeos_> Saviq: well your problem is, you are defining a slot, you need to provide an implementation
[14:45] <tsdgeos_> you aren't
[14:45] <Saviq> tsdgeos_, d'oh
[14:45] <tsdgeos_> i see that you don't want to
[14:45] <tsdgeos_> since it's an "interface"
[14:46] <tsdgeos_> but you need to
[14:46] <tsdgeos_> or make it pure virtual
[14:48] <Saviq> tsdgeos_, thanks for the second pair of eyes :)
[14:48] <tsdgeos_> no worries
[15:09] <nic-doffay> Anyone have an idea how I can get a debugging log on the phone?
[15:12] <Cimi> nic-doffay, maybe through qtcreator?
[15:12] <Cimi> nic-doffay, try asking sdk guys
[15:13] <nic-doffay> Cimi, I'd rather avoid that method, but if it is the easiest then I guess I'll bite the bullet,
[15:13] <nic-doffay> Cimi, what chan are they mostly in?
[15:13] <Cimi> nic-doffay, #sdk in our server
[15:13] <nic-doffay> Cimi, cheers
[15:14] <tsdgeos_> #ubuntu-touch works too
[15:14] <tsdgeos_> and you may get help from the rest of the world
[15:15] <Cimi> I have problems in running unity on the phone
[15:15] <Cimi> with ./run_on_device, trunk
[15:15] <Cimi> http://paste.ubuntu.com/5661512/
[15:15] <Cimi> incompatible qt?
[15:17] <mzanetti> FYI: enabling mediumtests in CI again
[15:18] <mzanetti> in case I mess up some ci builds might fail. I'll stick around until we know its working
[15:18] <mzanetti> ping me in case of breakages
[15:18] <Cimi> tsdgeos_, ideas? ^
[15:19] <tsdgeos_> yes
[15:19] <tsdgeos_> dist-upgrade
[15:19] <tsdgeos_> or update && dist-upgrade
[15:19] <tsdgeos_> greyback: https://bugreports.qt-project.org/browse/QTBUG-27997
[15:19] <tsdgeos_> do you have "the other example" at hand?
[15:20] <greyback> tsdgeos_: with a scrollbar? Let me look...
[15:25] <greyback> tsdgeos_: no luck,  I can't find it, sorry
[15:27] <fginther> sil2100, ping
[15:28] <paulliu> tsdgeos_: https://code.launchpad.net/~paulliu/unity/phablet-fake-peoplepreviewdata/+merge/161514
[15:28] <fginther> sil2100, is this the job you had problems with, or are there more? https://jenkins.qa.ubuntu.com/job/ps-generic-autopilot-release-testing/348/
[15:29] <sil2100> fginther: pong, looking
[15:29] <fginther> sil2100, I think I found it - 343
[15:30] <sil2100> fginther: yes, 343 is the one, the others might be broken since I had to abort one build, so maybe that's that one?
[15:31] <sil2100> Ok, I need to drive back home, will be back in around 1.5h
[15:31] <fginther> sil2100, ack
[15:32] <tsdgeos_> greyback: ok, i'll try to recreate myself
[15:32] <tsdgeos_> paulliu: ok, having a look
[15:36] <Cimi> tsdgeos_, shall run_on_device call dist-upgrade too if detects upgrades for qt libs?
[15:38] <tsdgeos_> Cimi: not sure how we can detect that
[15:38] <Cimi> tsdgeos_, or better, could call apt-get install on the list of dependencies of qml-phone-shell
[15:38] <tsdgeos_> it does
[15:38] <tsdgeos_> on -s
[15:38] <Cimi> tsdgeos_, nope
[15:38] <Cimi> tsdgeos_, I did -s
[15:39] <tsdgeos_> ok, true
[15:39] <Cimi> tsdgeos_, didn't upgrade qtdeclarative5
[15:39] <tsdgeos_> it does build-dep
[15:39] <tsdgeos_> it'd say it's a bug in qt packaging for not forcing == versions for all the .debs
[15:39] <tsdgeos_> Mirv: ? ↑↑↑ ?
[15:40] <tsdgeos_> paulliu: you're not testing anything yet, is that right?
[15:41] <Cimi> tsdgeos_, how do I reproduce the bug?
[15:41] <paulliu> tsdgeos_: I have a branch that based on this branch. It uses this fake-plugin. But not really using the data inside.
[15:41] <Cimi> tsdgeos_, I managed to upgrade the phone etc etc
[15:42] <tsdgeos_> paulliu: you're planning to?
[15:42] <nic-doffay> Saviq, the infographics look great on the phone, but it appears that onComplete executes before the qmlscene becomes visible... Any idea what's going on here?
[15:42] <paulliu> tsdgeos_: write tests for DashPeople first. I'm not sure how to use the fake plugin's data right now. But to test DashPeople, this is needed.
[15:43] <paulliu> tsdgeos_: Because inside DashPeople.qml, there is PeoplePreviewData.
[15:43] <Saviq> nic-doffay, sure, you can't rely on onComplete to check that something was rendererd
[15:43] <Saviq> nic-doffay, it's only after creation of the component
[15:43] <Saviq> nic-doffay, so on initial start we'll have to think of something
[15:44] <Saviq> nic-doffay, but later onScreenOn with a small delay or something should be fine
[15:46] <tsdgeos_> paulliu: i understand that there is a PeoplePreviewData inside  DashPeople.qml, but this branch is not testing anything yet, no? I mean there's no "make blabla" that will run any test
[15:46] <nic-doffay> Saviq, what would set onScreenOn out of interest?
[15:46] <tsdgeos_> Cimi: it's on the MR "If i bring up the dash bar and once it's open click on a different lens but instead of clicking i do a small horizontal drag, sometimes the bad closes automatically instead of waiting for the timeout."
[15:47] <Saviq> nic-doffay, check what does the Greeter look for when it locks itself
[15:47] <paulliu> tsdgeos_: no, not testing anything yet.
[15:47] <Cimi> tsdgeos_, seems to work for me
[15:48] <nic-doffay> Saviq, will do, thanks.
[15:48] <mzanetti> ok. all tests are back in jenkins.
[15:49] <Saviq> nic-doffay, it seems to be just a PowerKey press for now
[15:50] <tsdgeos_> paulliu: i'd prefer to wait to merge for it when it actually tests something, is that ok for you?
[15:50] <paulliu> tsdgeos_: ok.. But that will be a large diff.
[15:50] <tsdgeos_> well, it will be this diff + a qml test, no?
[15:51] <paulliu> tsdgeos_: yes, that's it.
[15:51] <tsdgeos_> i'll take that :-)
[15:51] <paulliu> ok
[17:12] <racarr_> unity segfault (in an sse memcpy in bind_texture_from_pixmap in r600_dri) when I hook an external display
[17:12] <racarr_> 27th inch imac with r600
[17:12] <racarr_> is it definitely max texture size? Is there an easy way to figure out?
[17:13] <racarr_> Ok it's not max texture size as my max texture size is 16384
[17:42] <racarr_> Interesting resolution: It only works on one of my two mini display port outputs
[17:45] <sil2100_> fginther: any news related to the UTAH/jenkins failures?
[17:46] <sil2100_> Ah, I just see Javier's e-mail
[17:53] <chiluk`> when unity or compiz crashes where does it log the errors, and where does it stick the core.
[17:55] <robru> sil2100_, good morning!
[17:56] <chiluk`> Daviey ^^ do you know who would know?
[17:56] <sil2100_> robru: morrrning
[17:57] <sil2100> robru: just wanted to poke you about the status update of your stacks regarding autopilot 1.3 mostly
[17:57] <sil2100> robru: how's it going?
[17:58] <fginther> sil2100_, I'm going to work on implementing Javier's suggestions today. At the moment, I don't have any more insight into the failure on 343
[17:58] <robru> sil2100, well I am still waiting for vrruiz to fix up the webapps tests, which still don't run for me
[17:59] <sil2100> So we're still blocked?
[17:59] <robru> sil2100, yeah, basically no progress since the last time you asked me. you should bug him about it ;-)
[18:00] <sil2100> grrr :)
[18:01] <sil2100> Where iiss heee?
[18:01] <robru> sil2100, #webapps usually
[18:02] <robru> sil2100, can you give me more details about the 1.3 update? what kinds of changes are necessary for the port? is it just that pointing_device/mouse switch, or is there more to it?
[18:03] <chiluk> sil2100 robru, do you know where unity/compiz log errors and leave cores?
[18:04] <chiluk> would ubuntu-bug or sosreport pick them up?
[18:06] <robru> chiluk, no idea, sorry
[18:06] <chiluk> thanks anyway.
[18:08] <sil2100> chiluk: once something dies and the error dialog pops up, usually you can find everything in /var/crash
[18:09] <sil2100> chiluk: you can unpack that with apport-unpack
[18:09] <sil2100> robru: well, depends on what the test-application looks like, usually it's also needed to remove the *Mixin* class
[18:10] <sil2100> robru: there are also some changes related to bamf/application control
[18:10] <sil2100> robru: but mostly it's just creating scenarios for pointing_device
[18:10] <robru> sil2100, is this documented anywhere? I need to see examples.
[18:11] <robru> sil2100, it would be sufficient if I could just see diffs of existing autopilot tests that have been ported into the desired state.
[18:13] <sil2100> robru: I don't think there's much documentation, it's still very fresh - best check the diff for the gallery-app and/or unity
[18:14] <sil2100> robru: maybe unity best, as I suppose webapps would have some unity-related thingies
[18:32] <sil2100> kenvandine: ping
[18:45] <kenvandine> sil2100, pong
[18:46] <kenvandine> sil2100, https://code.launchpad.net/~ken-vandine/cupstream2distro-config/disable_phone_app/+merge/163568
[18:47] <sil2100> Yaaay
[18:47] <sil2100> kenvandine: thanks, approving!
[18:48] <kenvandine> thank you :)
[18:48] <kenvandine> i'll redeploy it
[19:33] <sil2100> fginther: I noticed that it happened once again, this time for raring
[19:35] <fginther> sil2100, thanks, I'll take a look
[19:36] <fginther> sil2100, run 350?
[19:36] <fginther> ati?
[19:37] <sil2100> fginther: yes...
[19:37]  * sil2100 starts cursing utah
[19:38] <fginther> sil2100, utah timed out after 2 hours and killed the run. there were too many test failures which slowed down the run
[19:39] <sil2100> Ah, could it be that the screensaver bug again?
[19:39] <fginther> sil2100, I suspect it is. The other two machines look sane
[19:39] <sil2100> fginther: ah, indeed, since artifacts are there, see it now
[19:40] <fginther> sil2100, is it worth increasing the timeout? Or is this just a case of we need to fix the screensaver issue?
[19:40] <sil2100> fginther: thanks, I missed it since I assumed it to be the same issue as previously
[19:40] <sil2100> fginther: I think I need to look into that screensaver issue again
[19:40] <sil2100> I mean, one way of fixing it would be disabling the screensaver in jenkins
[19:41] <sil2100> Globally
[19:41] <fginther> sil2100, if you send me the details I can add it to the setup scripts
[19:41] <sil2100> fginther: excellent, give me a moment ;)
[19:45] <sil2100> fginther: if you can add:
[19:45] <sil2100> gsettings set org.gnome.desktop.lockdown disable-lock-screen true
[19:45] <sil2100> To be executed before starting the autopilot tests, it would certainly help until we get to the bottom of it
[19:45] <sil2100> This disables the screen locking
[19:46] <fginther> sil2100, would it also help to setup the timeout value to an hour or two in case that value is getting mangled by a test?
[19:47] <sil2100> fginther: what do you mean by 'mangled by a test'?
[19:48] <fginther> sil2100, I mean 'if disable-lock-screen gets accidentally modified to false during a test'
[19:52] <fginther> sil2100, I just thought setting the timeout to a really high value would give us a failsafe to prevent screen locking
[19:52] <robru> sil2100, hey, excuse my ignorance. when we're talking about these utah troubles, does that include this? http://10.97.0.1:8080/view/cu2d/view/Head/view/WebApps/job/cu2d-webapp-head-1.1prepare-unity-webapps-amazon/13/console
[19:53] <sil2100> fginther: hm, for sure I would like some log message at least if that happens, since I wonder if my AP-code supports that well
[19:53] <sil2100> robru: let me look
[19:53] <sil2100> robru: uh, this looks like something different ;)
[19:53] <fginther> sil2100, I'll do the disable for now. If it doesn't work, we can revisit it
[19:54] <sil2100> robru: do you love jenkins-utah bits as well?
[19:54] <robru> sil2100, I guess I'm not very familiar with what is referred to as "utah" but yeah, webapps stack has been struggling with jenkins just being totally broken
[19:54] <sil2100> fginther: ok, I'll mark it down to remember, big thanks!
[19:54] <sil2100> robru: maybe try, just in case, to re-run the stack again with the 'foo' component
[19:55] <robru> sil2100, well, it's been run several times.
[19:55] <sil2100> robru: and the same issue every time?
[19:55] <robru> well it's hard to say, because the logs are so utterly polluted with that LD_PRELOAD message
[19:55] <robru> sil2100, there's a chance we're still dealing with that bootstrapping issue, where it can't find rules.mk.
[19:57] <sil2100> robru: it looks like a problem with the chroot to me
[19:57] <sil2100> I mean, with the system
[19:57] <robru> sil2100, yeah, that much is clear ;-)
[19:57] <robru> sil2100, but I have no idea how to even begin troubleshooting this... it's a total mess
[19:58] <sil2100> robru: maybe fginther could take a look, but I'm afraid he's a very very busy person with all those jenkins issues ;)
[19:58] <robru> sil2100, do you know if webapps is the only stack that's getting these errors?
[19:58] <sil2100> robru: I didn't see it in any of my stacks, I also didn't see it in the apps stack, so I guess it might be webapps specific - are you sure you're not having any special hooks in the webapps stack config?
[19:59] <robru> sil2100, well there are some hooks to enable some PPAs to try and work around that bootstrapping issue, but I have no idea why they would cause this level of corruption. like it doesn't even get as far as building the package before it explodes. dunno how my config could cause that
[20:00] <sil2100> robru: it looks ok to me...
[20:00] <sil2100> robru: maybe try poking fginther a bit later about this, I'm sure he'll have more insight
[20:01] <fginther> robru, let me try to catch up with the confo and I'll get back to you
[20:01] <robru> sil2100, are you sure fginther is the right guy? I think the CI side of things is working (as fginther made that work last week). this is really the daily-release side that is broken and fginther doesn't do much with that
[20:01] <fginther> s/confo/convo/
[20:02] <robru> I've been trying to ping didrocks about this but I guess he is on holiday or something
[20:02] <fginther> robru, is it a script/job issue? have you asked jibel?
[20:02] <robru> fginther, check the URL I linked above; all kinds of crazy errors spewing all over the logs. makes no sense to me
[20:02] <robru> haven't pinged anybody really, figured it was some kind of horrible systemwide issue that everybody would just know about
[20:07] <fginther> robru, I don't know what's going on here either. cyphermox asked me about this last Friday. I would think jibel and didrocks are your best bet. I have seen the libeatmydata.so errors while updating my systems from quantal->raring and raring->saucy, but only before the reboot
[20:08] <robru> fginther, so the server needs to be rebooted?
[20:08] <fginther> robru, my gut tells me this is a kernel/library mismatch, but I have no real proof :-)
[20:09] <robru> fginther, well that's more info than I have. so who has the power to reboot this server?
[20:11] <sil2100> See you tomorrow guys!
[20:57] <kgunn> mhall119: ping
[21:01] <mhall119> kgunn: pong
[21:01] <kgunn> mhall119: hey just wondering, how do i go about editing
[21:01] <kgunn> http://unity.ubuntu.com/getinvolved/development/unitynext/
[21:01] <kgunn> i know you "gave me access"
[21:02] <kgunn> but its not as simple as an edit link appearing
[21:02] <mhall119> kgunn: go to /wp-admin/ first to log in
[21:02] <mhall119> then you should get the WP toolbar at the top of pages to edit them
[21:02] <mhall119> (you may need to refresh the page to get an uncached copy)
[21:03]  * kgunn gives it a shot