[22:04:25] !herd qt [22:04:26] (qt) abcd, ayoy, chiiph, hwoarang, spatz, tampakrap, wired [22:04:29] lets begin [22:04:46] * ABCD is here [22:04:49] rollcall [22:04:51] ayoy and chiiph won't make it [22:04:59] * pesa here [22:05:58] hwoarang, spatz? [22:06:03] * hwoarang * [22:06:27] spatz probably dc'd. tampakrap you back? [22:06:45] * reavertm rants that QtWebkit sucks and crashes [22:07:14] oh well [22:07:19] i'm back [22:07:22] great [22:07:25] agenda -> http://gitorious.org/gentoo-qt/pages/Meeting20100902 [22:07:36] 1. qt4-r2.eclass [22:07:43] reavertm: hope it'll get better with qt-webkit 2.0 [22:07:49] just wanted to update you people [22:08:01] we now have pretty repoman check for deprecated eclasses [22:08:09] yay [22:08:23] this will probably help get this long list ( http://dev.gentoo.org/~wired/checks/qt4.eclass.html ) down [22:08:56] inherit.deprecated 4 app-emulation/virtualbox-ose/virtualbox-ose-3.1.8.ebuild: please migrate from 'qt4' to 'qt4-r2' on line: 7 app-emulation/virtualbox-ose/virtualbox-ose-3.2.6.ebuild: please migrate from 'qt4' to 'qt4-r2' on line: 7 app-emulation/virtualbox-ose/virtualbox-ose-3.2.8.ebuild: please migrate from 'qt4' to 'qt4-r2' on line: 7 [22:09:01] app-emulatio/virtualbox-ose/virtualbox-ose-9999.exbuild: please migrate from 'qt4' to 'qt4-r2' on line: 7 [22:09:11] thats what happens on repoman -v full [22:09:13] :) [22:09:30] nice [22:09:53] thanks for implementing that check wired [22:09:54] 2. Qt 4.7.0 [22:10:00] pesa: you're welcome [22:10:14] pesa: it's used for other eclasses too ;) [22:10:28] yeah, i had a look at the portage patch ;) [22:11:02] ;) [22:11:13] *** Quits: spatz (~spatz@gentoo/developer/spatz) (Ping timeout: 272 seconds) [22:11:17] one more thing before 2. [22:11:24] I think its time we fixed ebuilds ourselves [22:11:25] is there anything we can do about those warnings? [22:11:32] are there open bugs or smth? [22:11:47] *** Joins: [Enrico] (~chiccoroc@gentoo/contributor/Enrico) [22:11:59] what do you guys think? [22:12:20] well [22:12:21] we can [22:12:48] maybe ping their maintainers for an ack [22:12:48] if there aren't open bugs about the remaining ones, we can open them and attach patches [22:12:53] we should send an email though just to let them know that we are gonna touch their ebuilds [22:13:04] tampakrap: i don't think its worth opening bugs [22:13:18] if there is no response for a long time let's use hwoarang's QA hat and force him commit them :) [22:13:35] devs should be using repoman, maybe wait for one more month for them to respond then start fixing them ourselves [22:14:12] if anyone feels like doing that ofcourse :) [22:14:35] ok, so summary: we can fix them ourselves if we notify the maintainers first [22:14:44] this is almost a 6-7 month issue [22:14:49] we should act instead of waiting [22:14:51] i insist, let's open bugs [22:15:38] tampakrap: why not just fix em? we won't be changing the ebuild end result anyway... [22:15:43] anyway, i don't think there is any real hurry to port ebuilds to qt4-r2... [22:16:07] old eclass does not cause any problems afaik [22:16:17] *** Joins: spatz (~spatz@gentoo/developer/spatz) [22:16:17] pesa: no one is really watching the old one tho... any changes we do in -r2 stay there [22:16:26] the eqmake4 is different between these two eclasses [22:16:28] isnt it? [22:16:32] it is [22:17:07] the important thing is that new ebuilds or new versions switch to qt4-r2 [22:17:21] we cant ensure that [22:17:21] and we have the repoman check for that [22:17:32] the repoman message is a warnign not a fatal error [22:17:34] pesa: well its not fatal [22:17:38] so ppl can still ignore it [22:17:45] heh ok [22:17:59] does anyone else feel we should open bugs for this? [22:18:05] ppl can even break the tree if they want to [22:18:44] a bug would be a nicer way to say that "look here is the patch commit it or i will" [22:18:54] i agree with tampakrap [22:19:13] touching others' ebuilds is evil imho [22:19:16] its more paperwork for an internal ebuild patch [22:19:28] i favor "ping the guy then commit" [22:19:51] that's fine too [22:19:57] but i guess bugs would be nice for devs who don't respond any other way [22:20:00] tampakrap: i did fix some ebuilds in the past [22:20:07] they didnt even notice it [22:20:09] :) [22:20:10] lol [22:20:14] :P [22:20:15] the bug can remain open forever [22:20:25] i don't say open bugs and wait [22:20:32] if you plan to open bugs then you should open a tracker ( if there is not one already ) [22:20:35] i say open bug, ping, commit and mention bug # [22:20:38] for proof [22:20:41] yeah [22:20:43] ah [22:20:47] i think there is [22:20:50] the commit message on gentoo-commits is a proof [22:20:52] yeah i agree with that [22:20:59] but if you can get in touch with the dev [22:21:03] through irc [22:21:07] the bug is really not necessary :) [22:21:13] ok guys [22:21:16] great [22:21:18] lets move on [22:21:18] we have 4 servers for bugzie [22:21:18] yes, definitely [22:21:22] make them look useful [22:21:27] lol [22:21:28] lol [22:21:33] 2. Qt 4.7.0 [22:21:40] we have _rc1 in edge [22:21:43] about it: [22:21:49] a few of us are already using it, works fine [22:21:55] i tested kde 4.5.1, all my kde and qt apps [22:21:58] they work fine [22:22:01] thanks tampakrap [22:22:08] sweet [22:22:11] i didn't test 4.4.5 and i don't think i will in the near future [22:22:20] before i finish my exams at least [22:22:25] there are some minor regressions here and there but nothing serious for the moment [22:22:34] here's the question [22:22:39] well, is kde 4.5.1 entering the tree? [22:22:44] yes [22:22:50] ok so 4.4.5 isn't an issue [22:22:58] 4.4.5 is current stable [22:23:04] and 4.5.x won't get stable [22:23:17] yes, so? [22:23:32] i'd say not to add rc to tree yet, not before testing kde 4.4.5 [22:23:44] we dont care for 4.4.5 [22:23:46] when is the release btw? [22:23:46] mmm [22:23:48] hwoarang asked flameeyes to test 4.7.0_rc1 in the tinderbox, flameeyes requested we move 4.7.0_rc1 to the tree (masked ofc). do we want to test with _rc1 or should we wait for final release, keep it masked for a couple of days and try with that? [22:24:03] 4.4.5 is stable. ppl are not supposed to mix branches [22:24:04] i'd vote for the second [22:24:05] tampakrap: nokia doesn't give release dates [22:24:07] i'd say wait for 4.7.0 final [22:24:12] i vote for final [22:24:14] ;) [22:24:24] it shouldn't take long anyway [22:24:30] tampakrap: nokia works like 3d realms "when it's done", only difference is they actually release [22:24:33] ;p [22:24:36] 3-4 weeks imho [22:24:44] probably less [22:25:09] ok [22:25:11] ok great [22:25:13] hwoarang: we should care about 4.4.5 since 4.5 won't get stable and qt-4.7 is [22:25:35] so whoever adds final qt 4.7.0 to tree, remember to mask it [22:25:56] are you going to skip the whole 4.5.x series? [22:25:56] * lu_zero finished testing 4.7.0_rc1 opengl and openvg both look broken on mesa... [22:26:03] yes [22:26:11] O_O [22:26:20] 3. gles and openvg in Qt [22:26:40] wired: wait [22:26:50] what? [22:26:50] tampakrap: no because 4.4.5 was never made to work with 4.7 [22:27:15] 4.4.5 is stable, current stable qt is 4.6.2 and in the near future 4.6.3 will be [22:27:19] then don't stabilize it before 4.6 hits stable [22:27:24] yep [22:27:25] i dont think we will stabilize 4.7.0 [22:27:26] there's no way we're stabilizing 4.7.0 [22:27:27] or 4.7.1 [22:27:30] i mean [22:27:38] nokia already announced they're skipping issues for .1 [22:27:39] tampakrap: again [22:27:41] to make a release [22:27:42] ;p [22:27:45] kde != qt [22:27:52] oh [22:27:55] i didn't know that [22:28:00] :) [22:28:01] lol [22:28:04] well we care about kde [22:28:06] let's move on please [22:28:07] you want to hold back the stabilization of Qt because kde doesnt work? [22:28:27] we can't break stable systems that badly :s [22:28:28] hwoarang: we would imo [22:28:38] kde is the major qt consumer [22:28:41] indeed [22:28:41] lets be realistic :) [22:28:45] do you stabilize things that break systems? [22:28:47] the current stable kde [22:29:00] if current stable kde doesn't work with a qt stable target [22:29:08] that qt stable target will be delayed [22:29:09] wired: we wont stabilize 4.7.0 [22:29:15] i just said that [22:29:17] the delay is acceptable [22:29:22] it is two months from now [22:29:25] the discussion is useless, we are talking about the far future and we are in the middle of a meeting [22:29:28] please move on [22:29:29] why are you repeating me? :P [22:29:30] btw i might be able to test 4.7 with kde 4.4.5 next week [22:29:31] i doubt that 4.4.5 will be on tree after 2 months [22:29:39] it will [22:29:51] ok [22:29:51] for the next 6 months [22:29:54] it doesn't matter [22:29:57] we can talk about this later [22:30:28] bottom line. we care about kde, we won't break stable, we'll discuss 4.7 stabilization when the time comes [22:30:53] 3. gles and openvg in Qt [22:30:57] lu_zero: ^^ [22:31:02] hi [22:31:44] Qt apparently/should support various flavors of opengl and it's new 2d companion lib called openvg [22:32:28] I say apparently/should since I'm testing right now and the results aren't exactly nice (at least with the 4.7) [22:32:55] so I'd like to know your opinion about: [22:33:04] - support egl in qt [22:33:04] well, alternative graphicssystems are experimental [22:33:10] except raster [22:33:26] - support opengl es2 in qt [22:33:33] - support openvg in qt [22:33:47] egl is a requirement for es2 and openvg [22:33:55] fyi i added egl use flag back to 4.7 like 4.7.9999 ebuilds. It works now ( it didnt work back in _beta1 ) [22:34:05] opengl subsystem has worked for me in the past. it was ugly but worked - ie apps ran [22:34:16] hwoarang: it build nicely [22:34:43] wired: es2 seems to have a X visual mismatch we could ask upstream about it [22:34:49] wired: i had frequent crashes with the opengl one [22:35:05] i didn't keep it long enough to experience crashes ;p [22:35:36] raster is the only one which is well supported [22:35:44] lu_zero: what have you tested so far? [22:35:57] ./configure -help -> http://gentoo.pastebin.com/1jKXdGDL [22:36:08] qtconfig -graphicssystem {openvg opengl} [22:36:17] openvg <- no widget rendered [22:36:43] opengl (es2) <- X visual mismatch <- exits [22:36:44] :( [22:37:01] have you tried opengl2? [22:37:06] still I need to check what happens with the other implementation I accessed [22:37:14] desktop you mean? [22:37:21] no [22:37:28] qtconfig -graphicssystem opengl2 [22:37:49] hmm -openvg is enabled by default now [22:37:52] let me see [22:37:54] we should make a useflag for it [22:38:01] of course [22:38:20] wired: I made a split for it [22:38:26] wow opengl2 works [22:38:48] (barely) lags a bit on resize [22:39:18] opengl2 segfaults here :s [22:39:46] oh wait [22:40:11] i had a typo in the command and it failed to tell me [22:40:19] Unable to find an X11 visual which matches EGL config 3 [22:40:19] Unable to find an X11 visual which matches EGL config 3 [22:40:19] Segmentation fault [22:40:26] that is ^^ [22:40:30] window opened here, empty [22:40:47] well, it's a mess :( [22:41:00] http://www.imagebin.org/112427 [22:41:01] not usable i think [22:41:27] which mesa version are you using? [22:41:39] 7.8.2 [22:42:14] * wired same [22:42:37] uhm [22:42:40] w/ 9999 libdrm and radeon driver [22:43:47] * lu_zero uses 9999 mesa + libdrm and radeon [22:43:59] yeah i wonder why i don't have 9999 mesa [22:44:06] * wired keywords it [22:44:07] lol [22:44:38] so what do we need to decide? [22:45:02] i guess we should add openvg use [22:45:02] * lu_zero checked es1 <- wrong lib [22:45:11] use or split? [22:45:31] lu_zero: its a module like qt-opengl? [22:45:37] yes [22:45:56] is there a QtOpenVG.so? [22:46:07] s/opengl/openvg/g s/OpenGL/OpenVG/ all over and you have it [22:46:09] yes [22:46:24] ok, split then [22:46:27] +1 [22:46:45] what about the gles? [22:47:02] useflags for es1 and es2 ? [22:47:03] *** Joins: DrEeevil (~quassel@gentoo/developer/bonsaikitten) [22:47:03] for gles just pass -opengl es2 [22:47:26] ah uhm [22:47:38] is gles1 relevant? [22:47:56] shouldn't [22:47:57] *** Quits: bonsaikitten (~quassel@gentoo/developer/bonsaikitten) (Write error: Broken pipe) [22:48:08] might work better for certain devices [22:49:02] well, adding support at the ebuild level is trivial, but i'm afraid nobody will test it [22:49:06] we could add opengl-es1 and opengl-es2 use flags (or shorter ones) with descriptive use descriptions [22:50:07] *** Joins: mschiff_ (~mschiff@d000130.adsl.hansenet.de) [22:50:11] pesa: testing on mesa is easy [22:50:26] testing on embedded system well I'll test on the efika implementation for sure [22:51:01] lu_zero: any point in doing any of the above for 4.6? [22:51:07] *** Quits: mschiff (~mschiff@d000130.adsl.hansenet.de) (Ping timeout: 272 seconds) [22:51:28] btw, can you confirm that gles{1,2} and opengl are mutually exclusive? [22:51:42] i mean in qt [22:52:03] well [22:52:14] pesa: http://www.imagebin.org/112429 [22:52:38] wired: I can test it as well not sure which is the status in 4.6 we should ask upstream [22:52:48] surely openvg behaves the very same way [22:52:55] yeah ok, but isn't there a way to enable both through some hacks? [22:53:00] hadn't tested opengl that much [22:53:06] *** Parts: [Enrico] (~chiccoroc@gentoo/contributor/Enrico) [22:53:14] pesa: using the eselect approach [22:54:06] mm [22:55:03] eselect-qtgl? :) [22:55:19] i recommend we do our testing work in qting-edge ( lu_zero you could push your split ebuild ) and someone could work on eselect [22:55:54] wired: do I have access to the tree? [22:56:20] lu_zero: tampakrap will take care of that [22:56:35] lu_zero: you need a gitorious account [22:56:35] then the whole team can pitch in [22:56:42] ah its gitorious forgot [22:57:04] lu_zero: what hwoarang said [22:57:14] who is going to implement the eselect thing? [22:57:29] btw do we all agree to follow that approach? [22:57:34] that is easy [22:57:46] pesa: it sounds like the best way [22:58:05] if doable [22:58:17] dunno really [22:58:23] i dont know shit about eselect [22:58:25] pesa: wanna look into it? [22:58:29] ^_^ [22:58:43] well, to be honest i'm not interested at all :P [22:58:56] hwoarang: I have one =) [22:59:29] I'd got to the useflag route and introduce first es2 and desktop as alternative [22:59:31] the simplest solution is having opengl and gles to exclude each other [22:59:34] lu_zero: gimme your username [22:59:38] lu_zero [22:59:49] ofcourse [23:00:30] useflag approach is definately simpler [23:00:34] indeed [23:01:02] we can always add eselect support later [23:01:04] i think 'opengl' should enable desktop, overridable by es1 and es2 [23:01:12] +1 [23:01:29] * wired wishes we had eapi4 [23:01:58] what happens with USE="-opengl gles"? [23:02:17] no opengl, ewarn? [23:03:34] eselect between opengles and opengl? [23:03:47] yep [23:03:50] we already said thats an option but noone stepped up to implement it ;p [23:03:54] you're insane [23:03:57] (and wrong) [23:04:11] those are not complementary - ES is subset of opengl [23:04:16] wired: I'd just add es2 and es1 [23:04:32] USE=es2 emerge qt-opengl [23:04:36] USE=es1 emerge qt-opengl [23:04:41] USE="" emerge qt-opengl [23:04:43] ah [23:04:45] if you want [23:04:48] so "" == desktop [23:04:51] yes [23:04:53] great [23:04:58] +1 [23:05:09] right now we have it automagic [23:05:10] ah right [23:05:19] i like it [23:05:20] sorry for my silly question [23:05:35] how about install desktop (full opengl) always and es1/2 optional with use flags [23:05:47] reavertm: thats what we just said :) [23:05:56] i though we had opengl in qt-gui's IUSE too [23:06:02] you have to pick one [23:06:07] (unless you want to support gentoo on...symbian :P) [23:06:14] pesa: we have egl [23:06:23] that's yet another thing [23:06:31] pesa: if you add one you get circulars [23:06:32] :) [23:06:37] between qt-gui and qt-opengl [23:06:47] ok [23:06:51] you could do that and add qt-opengl on PDEPEND [23:06:57] pointless imho [23:06:59] so the deps would be something like es1? ( qt-foo[egl] ) [23:07:11] lu_zero: yes [23:07:21] ok [23:07:25] lets wrap this up [23:08:01] lu_zero will do all this (:p) in qting-edge -> es1 and es2 useflags, qt-openvg [23:08:16] and add egl useflag to qt-gui [23:08:24] already done [23:08:25] i thought hwoarang did that [23:08:50] and on opengl [23:09:10] team: should we ask lu_zero to join the team? ^_^ ;) [23:09:20] *** Quits: pesa (~Pesa@host169-125-dynamic.52-82-r.retail.telecomitalia.it) (Quit: Konversation terminated!) [23:09:29] *** Joins: pesa (~Pesa@host169-125-dynamic.52-82-r.retail.telecomitalia.it) [23:09:29] and kick who? [23:09:53] why kick anyone, we're a happy family :D [23:10:31] wired: I can help but I'm not exactly a C++ guy ^^; [23:10:37] and we are? [23:10:43] :P [23:10:52] I hope =) [23:10:55] heheh [23:11:18] well, if you wanna join, you're welcome to :) [23:11:30] I'll help on this part for sure [23:11:36] you already have access to qting-edge [23:11:40] ^^ ;) [23:11:45] ok [23:11:51] * lu_zero will start adding stuff [23:11:54] great [23:11:56] any rule I should know? [23:12:35] nothing special [23:12:38] no [23:12:50] oh [23:12:54] lu_zero: we don't use changelogs [23:12:55] :) [23:13:09] git ftw [23:13:17] but you'd figure it out yourself anyway [23:13:27] lets move on [23:13:46] 4. bugz [23:13:59] anyone had any revelations on the qt-svg issue? [23:13:59] ok [23:14:11] no [23:14:28] ok, just asking since noone closed it ;) I'll close it after the meeting [23:14:39] bug #329533 [23:14:39] yes please [23:14:42] wired: https://bugs.gentoo.org/329533 "x11-libs/qt-core-4.6.3 - qmake generates incorrect Makefile with CONFIG+=debug"; Gentoo Linux, Applications; NEW; egorov_egor@bk.ru:qt@g.o [23:15:21] pesa: you had your fun there :P [23:16:22] :) [23:16:41] this bug is tough... if you look at it the gentoo way, he's wrong. if you look at it the app developer way, he's right [23:16:55] indeed [23:17:40] how about the opposite of his patch [23:17:49] he proposed a solution (i'd call it hack), but it's too invasive and fragile for my taste [23:18:00] wired: ? [23:18:21] pesa: QMAKE_DONT_IGNORE_PREDEFINED_CFLAGS [23:18:33] ^^^^ [23:19:06] bah [23:19:08] no [23:19:18] it doesn't make much sense imho [23:19:23] are you sure we are on the same page? [23:19:42] we could leave the current state as is [23:19:45] uhm [23:19:46] but [23:19:53] if you want debug support just adjust the CFLAGS yourseklf [23:19:53] qmake.conf won't allow that? [23:20:03] and allow people like him to override the behavior by setting QMAKE_DONT_IGNORE_PREDEFINED_CFLAGS=1 [23:21:18] how are qt devs going to know about that var? [23:21:54] meh [23:22:05] ok, other idea [23:22:05] i still propose the same as comment #24 [23:22:36] ah [23:22:55] building with USE=debug but without debug symbols is odd anyway [23:23:02] yes [23:23:07] that looks ok to me [23:23:47]