<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Mar 1, 2015, at 5:47 AM, Stuart Morgan <<a href="mailto:stuart@tase.co.uk" class="">stuart@tase.co.uk</a>> wrote:<div class=""><br class=""><div><blockquote type="cite" class="">We're on the hunt for bugs caused by the switch to QT 5 and this is something <br class=""><div class=""><span style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">you can help us with. So please make sure you're ready for the switch</span></div></blockquote></div><div class=""><br class=""></div><div class="">Could you set expectations for people with things like what you mean by “ready” and should we expect current master to be usable for production or is it a total crap shoot at this point. Also, would you feel master to be solid if you’re on qt4 libraries? How much testing was done before this announcement?</div><div class=""><br class=""></div><div class="">I took the plunge and the build went smoothly enough. For folks on Debian it’s enough to install qt5-default libqt5webkit5-dev qtscript5-dev libqt5sql5-mysql and they’ll cause most of the qt4 packages to be removed due to conflicts. I used apt-show-versions to tell me what other qt4 packages were around and I removed those manually.</div><div class=""><br class=""></div><div class="">A database change was committed in mid February so people coming from builds before that will have a little extra effort should they decide to back off and return to qt4. Nothing too major, the update was to add tables named users, user_permissions, and user_sessions so you can drop those and decrement the schema number and any recordings you made while testing qt5 will be preserved.</div><div class=""><br class=""></div><div class="">The first few times I ran the backend it failed to back up the database. There was no reason given in the backend log nor did the backup script make any effort to give one. When I stepped through it in gdb the backup, and db upgrade, worked OK and continued doing so when I reran outside of gdb. Who knows.</div><div class=""><br class=""></div><div class="">The frontend came up OK and navigated through menus and queued new recordings successfully. I tried to play back a recording but the log filled with endless “QOpenGLContext::swapBuffers() called with non-exposed window, behavior is undefined” messages. There’s context here:<a href="http://pastebin.com/z4RnRC5F" class="">http://pastebin.com/z4RnRC5F</a>. I’m using vaapi with an ivy bridge i7’s built-in video and the recording was an hd mpeg2 atsc recording. I wasn’t able to get anywhere with gdb on the frontend but did stop it while it was spewing messages and took a stack trace FWIW, it’s at <a href="http://pastebin.com/VXrLSMg7" class="">http://pastebin.com/VXrLSMg7</a>.</div><div class=""><br class=""></div><div class="">My first attempt at recording failed due to tuning errors but that might be due to weather issues (I’m on OTA). Subsequently I started recordings for on each of my 5 tuners, some of them using both virtual tuners, for a total of 8 simultaneous. Recording seems to pass the basic stink test.</div><div class=""><br class=""></div><div class="">Losing playback makes this a non-starter so I’m rolling back. If you want anything specific tested in the next 24 hours I can probably accommodate that otherwise it’ll be after the weekend.</div><div class=""><br class=""></div><div class="">- George</div></div></body></html>