[21:09:16] *** Meeting *** [21:09:34] amen [21:09:36] *** End *** [21:09:39] lmao :D [21:09:51] who is logging? [21:09:55] me [21:10:01] ok [21:10:07] Agenda: http://gitorious.org/gentoo-qt/pages/Meeting20100520 [21:10:31] 1. Welcome new members [21:10:36] chiiph is our newest member [21:10:39] welcome chiiph ! [21:10:40] :) [21:10:43] hello there [21:10:46] hello everyone :) [21:10:48] w00t w00t [21:10:52] chiiph o/ [21:10:58] !herd qt [21:11:01] chiiph: (qt) abcd, ayoy, hwoarang, spatz, ssuominen, tampakrap, wired, yngwin [21:11:03] hi chiiph :) [21:11:06] give it some time [21:11:07] he has already access on qting-edge [21:11:48] not that I've done too much there... :) [21:11:49] chiiph: not much to say here. We run meeting every 3rd Thursday of the month [21:11:58] chiiph: feel free to work as you wish on qting-edge [21:12:01] hwoarang: ok... [21:12:05] on which areas will you focus? [21:12:08] changes on eclasses should be emails to qt@gentoo.org [21:12:12] *emailed [21:12:22] chiiph: we are all major slackers with tampakrap as slack lead :D [21:12:34] * hwoarang hugs tampakrap [21:12:35] in every team [21:12:39] ofcourse [21:12:47] only second to his mentor, patrick :P [21:12:51] pesa: I don't have anything specific in mind really... qt is the lib I use the most, so may be... MAY BE... I can help here :) [21:13:21] wired: I'll try to slack my best [21:13:22] we could use more ppl there yes [21:13:24] wired: not my minion :) [21:13:24] chiiph: that's great [21:13:34] bonsaikitten: he's your slack-nion :p [21:13:42] lol [21:13:45] wired: that's nirbheek [21:14:18] heheh [21:14:18] the gentoo slacking list is endless [21:14:29] well, let's get on with this :) [21:14:38] moving on to 2. ? [21:14:41] lets go to 2. [21:14:49] 2, MIgrate ebuilds to qt4-r2 eclass [21:14:50] http://dev.gentoo.org/~wired/checks/qt4.eclass.html [21:14:52] http://bugs.gentoo.org/show_bug.cgi?id=311481 [21:14:58] we're not getting anywhere :P [21:15:09] mail sent to -dev by me [21:15:16] not much activity from the rest of the devs [21:15:30] maybe we should reconsider our policy [21:15:54] we could add/request a repoman check [21:16:07] a warning there might help [21:16:43] have you seen the deprecation warning on python eclass [21:16:56] that too [21:16:59] a red one warning about deprecation in 1-7.2010? [21:17:02] good thinking [21:17:03] looks good to me [21:17:17] force users to file bugs [21:17:21] i'll do it [21:17:26] * hwoarang noted [21:17:28] thanks Alex [21:17:42] any other ideas? [21:17:52] using deprecated eclasses is a global issue... may it's better to think of a repoman check, like wired said... and everyone can benefit [21:17:52] ask the python team? [21:18:01] file mass bugs with a tinderbox? [21:18:14] tampakrap: ask python team for what? [21:18:19] chiiph: we can do both [21:18:20] how they did it? [21:18:31] i bet its hidden somewhere in the eclass [21:18:35] chiiph: perhaps if we do it others will follow [21:18:48] wired: yes, but it's twice the work... [21:18:49] hwoarang: we could stuff it in pkg_setup [21:19:08] or anywhere else for that matter [21:19:11] pkg_setup on qt4.eclass? [21:19:17] yes sure [21:19:19] yes [21:19:23] the python deprecation warning isn't really nice... have you seen the code? [21:19:34] *** Joins: pesa__ (~Pesa@host196-186-dynamic.16-79-r.retail.telecomitalia.it) [21:19:39] chiiph: thats a different case [21:19:43] yes [21:19:53] we only need a clear warning message [21:19:57] sorry guys, i have my usual connection troubles :( [21:19:58] we just want to stop using an eclass, they had to check for functions being called, or variables being set [21:20:05] hi pesa__ :) [21:20:10] pesa__: :) [21:20:23] we need to poke users act on it instead of the maintainers [21:20:26] because maintainers are slow [21:20:28] *** Quits: pesa (~Pesa@host51-153-dynamic.50-82-r.retail.telecomitalia.it) (Disconnected by services) [21:20:32] *** pesa__ is now known as pesa [21:20:33] and I am pretty sure they have forgot about it [21:20:45] *** Quits: yngwin (~yngwin@gentoo/developer/yngwin) (Read error: Operation timed out) [21:21:07] ok, then I guess a simple message in pkg_setup will do, but it'll be great to have... I don't know... like a DEPRECATE="date" var to set this... [21:21:13] *** Joins: yngwin (~yngwin@cable-186-3.zeelandnet.nl) [21:21:14] *** Quits: yngwin (~yngwin@cable-186-3.zeelandnet.nl) (Changing host) [21:21:14] *** Joins: yngwin (~yngwin@gentoo/developer/yngwin) [21:21:41] we could hardcode the date [21:21:47] I'll check out if its easy to add the check in repoman (no idea) and will send the eclass message to qt@ for you people to see before I commit [21:21:59] * hwoarang wonders what will happen when that deadline passes [21:22:21] hwoarang: repoman error on commit [21:22:24] ;) [21:22:31] well [21:22:32] *** Quits: [Enrico] (~chiccoroc@gentoo/contributor/Enrico) (Remote host closed the connection) [21:22:33] what about the ebuilds? [21:22:39] will they die on pkg_setup? [21:22:45] hell no [21:22:54] so nothing will happen [21:22:55] we just won't allow any new qt4.eclass commits [21:23:00] ppl can still use this eclass [21:23:04] ok [21:23:05] fine [21:23:05] :) [21:23:16] after the deadline the eclass will be gone... [21:23:21] NO! [21:23:21] or at least that should be the idea [21:23:27] chiiph: no, that would break things [21:23:38] eclass shall stay to preserve stability [21:23:47] wired: I know... but tell that that isn't the best way to make people migrate? :) [21:24:04] repoman should be enough [21:24:15] provided that developers use repoman for their commits [21:24:17] chiiph: i don't want to break the tree, + we can't remove the eclass for two years (policy) [21:24:17] :p [21:24:18] there is an official rule now about eclass removal [21:24:24] 2 years of inactivity iirc [21:24:30] i'll ask a council member [21:24:44] so [21:24:44] wired: I don't know why I thought it was 10 years... [21:24:49] :D [21:24:53] chiiph: it used to be "never" [21:24:56] then it went to 2 years [21:25:05] lets sum it ip [21:25:07] it was never because of technical issues [21:25:15] 10 is pretty close to never in gentoo's life... [21:25:24] now that info is in var/db old ebulids don't need em any more [21:25:30] i'll take care of this, i'll ask around (already asked in -dev :p) about repoman and prepare a warning for the eclass [21:25:54] wired: afaik idl0r is maintaining repoman but you could also ask on -portage [21:26:01] but again thats fine [21:26:21] great lets move on [21:26:40] I got my asneeded repoman warning in by simply writing a patch, opening a bug to dev-portage@ and it was committed by Zac in only day or two [21:26:41] 3. Elections ? [21:26:52] ssuominen: lovely, thanks for the info [21:27:36] 3. hwoarang is is the only nominee, if anyone wants to nominate anyone (sic), now's their chance [21:27:55] we really need yngwin for this [21:28:03] let's skip this for the end [21:28:08] as we still dont know what are his future plans [21:28:18] yeah, what tampakrap said [21:28:31] lets go for the bugs [21:28:36] ok [21:29:00] bug 312689 [21:29:04] hwoarang: https://bugs.gentoo.org/312689 "x11-libs/qt-core-4.6.2-r1 forces additional CFLAGS and CXXFLAGS for dev-python/PyQt4-4.7.2"; Gentoo Linux, Development; NEW; Martin.vGagern@gmx.net:qt@g.o [21:29:14] we have ayoys patch on qting-edge [21:30:01] ayoy: do you think we should move it to qt4-build eclass and close this bug? [21:30:35] hwoarang: the eclass just works [21:30:49] it was only waiting for someone to test cross-compilation [21:30:58] as I have only amd64 machines :P [21:31:05] so am I [21:31:48] anyway, it should work... [21:32:28] I mean, the patch shouldn't break the compilation at all [21:32:38] it's only about keeping the correct CFLAGS [21:32:44] what do we need to test? [21:32:55] my proposal: move it to tree to get proper testing [21:32:55] i can test crosscompilation to arm [21:33:00] if you want [21:33:05] wired: we need to cross-compile qt from x86 to amd64 e.g. [21:33:09] oh awesome [21:33:13] ayoy: i can cross compile amd64->arm [21:33:17] great [21:33:27] with distcc :p [21:33:32] I'll prepare my qting-edge branch for you [21:33:40] great [21:33:40] move it to tree [21:33:46] or you can just copy the new eclass to the tree [21:33:53] i.e. on your machine [21:33:54] hwoarang: i'll test it first [21:34:04] * hwoarang noted [21:34:06] ayoy: its in a branch in qting-edge? [21:34:13] wired: yes [21:34:18] alrighty [21:34:21] in my todo [21:34:25] cool [21:34:52] moving on [21:35:23] bug 314193 [21:35:25] hwoarang: https://bugs.gentoo.org/314193 "x11-libs/qt-webkit, net-libs/webkit-gtk: multiple vulnerabilities (CVE-2010-0046, CVE-2010-0049, CVE-2010-0050, CVE-2010-0051, CVE-2010-0052, CVE-2010-0054)"; Gentoo Security, Vulnerabilities; ASSI; hanno@g.o:security@g.o [21:35:30] yngwin took care of it ( bug 315523 ) [21:35:33] hwoarang: https://bugs.gentoo.org/315523 "Speedy stabilization of x11-libs/qt-webkit-4.6.2-r1 and 4.5.3-r3"; Gentoo Linux, Ebuilds; NEW; yngwin@g.o:qt@g.o [21:35:46] major arches are ok but the rest of them are bit slow [21:36:36] i guess there is no much to do here [21:36:52] bug 304115 [21:36:55] wired: https://bugs.gentoo.org/304115 "=dev-python/PyQt4-4.7 with USE="-X" tries to link with -lXext"; Gentoo Linux, Applications; RESO, FIXE; orzel@freehackers.org:qt@g.o [21:37:06] pesa: ^ [21:37:09] thats fixed?! [21:37:35] should be [21:37:56] and we are discussing it because...? [21:38:35] kids [21:38:43] bug 307861 [21:38:44] meh [21:38:47] tampakrap: https://bugs.gentoo.org/307861 "x11-libs/qt-webkit-4.6.2: ld crashes at linking libQtWebKit.so.4.6.2"; Gentoo Linux, Library; REOP; urcindalo@gmail.com:qt@g.o [21:38:48] :) [21:40:05] * hwoarang doesnt have a clue [21:40:15] never had that problem [21:40:31] with -ggdb? [21:41:31] ah i thought there was a user having the issue with -ggdb, seems he was wrong [21:42:14] this doesn't seem to be our fault (until proven otherwise, ofcourse). [21:42:21] how about filtering -ggdb [21:42:50] or redirect this bug to toolchain team [21:43:03] that + big ewarn [21:43:27] on qt-webkit module? [21:43:33] "if you can't build this, you probably have -ggdb in your \${CFLAGS}. Please remove it and try again." [21:43:45] "more info @ bug BLAH" [21:44:03] ok but you should check if -ggdb is there and then print the message [21:44:10] sure [21:44:19] so yet another thing for me [21:44:20] ok [21:44:24] good boy [21:44:30] long list this month [21:44:31] =] [21:44:36] last one [21:44:37] bug 301476 [21:44:40] hwoarang: https://bugs.gentoo.org/301476 "QSvgWidget produce segfaults : x11-libs/qt-svg"; Gentoo Linux, Library; NEW; antonmx@gmail.com:qt@g.o [21:44:46] this is interesting [21:44:56] hwoarang: you'll contact toolchain? [21:44:58] pesa: dont hide [21:45:04] wired: i will CC them [21:45:08] k [21:45:21] check profiles/arch/amd64/profile.bashrc [21:45:34] perhaps something like that in the eclass used for x11-libs/qt-* [21:45:48] where BAD_FLAGS is -g -ggdb -g2 -ggdb2 -g3 -ggdb3 [21:45:52] and then warn [21:45:57] just idea :p [21:46:36] -ggdb doesnt cause any problems to the rest of the modules [21:46:37] *** Quits: pesa (~Pesa@host196-186-dynamic.16-79-r.retail.telecomitalia.it) (Ping timeout: 240 seconds) [21:46:49] so i guess we should not filtered it out from the rest of the modules [21:46:59] *** Joins: pesa (~Pesa@host213-117-dynamic.50-82-r.retail.telecomitalia.it) [21:47:07] qt-webkit is just HUGE hense the debug symbols cause huge memory usage [21:47:15] wtf...sorry again [21:47:33] pesa: we are on the svg bug :) [21:47:42] hwoarang: bug 304115 is fixed btw [21:47:44] pesa: https://bugs.gentoo.org/304115 "=dev-python/PyQt4-4.7 with USE="-X" tries to link with -lXext"; Gentoo Linux, Applications; RESO, FIXE; orzel@freehackers.org:qt@g.o [21:47:54] ok i just havent checked :) [21:48:09] ;) [21:48:43] about the svg bug, it seems it's caused by our splitting [21:49:29] or some compile flags added by qt4-build.eclass [21:50:04] * wired checks [21:51:46] in cause you wanna check just use the test example and compile it like this [21:52:19] interesting [21:52:43] g++ -I/usr/include/qt4 -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore -L/usr/lib64/qt4/ -lQtGui -lQtCore -lQtSvg test.cpp [21:52:50] i wonder what we're missing [21:52:56] not specific CFLAGS yet still fails [21:53:24] i really have no idea [21:53:48] wait [21:53:48] wait [21:53:58] this is funny [21:54:05] one time i run it it segfaults [21:54:09] one time it works o_O [21:54:27] you've been lucky i guess [21:54:36] pesa: working == exiting cleanly ? [21:54:46] or opening window? [21:55:05] i have to look at the code [21:55:23] https://bugs.gentoo.org/attachment.cgi?id=230997&action=view [21:55:23] no window [21:55:41] just to exit cleanly [21:55:42] *** Joins: [Enrico] (~chiccoroc@gentoo/contributor/Enrico) [21:55:42] it should just exit cleanly [21:55:45] ok [21:55:52] then its super weird [21:56:02] there's no app.exec() [21:56:04] its like working 50-50 [21:56:15] it'll work 3-4 times then segfault another 3-4 [21:56:18] lol [21:56:28] wired: do you have a backtrace available? [21:56:40] I'd test it right now but I'm on a mac [21:56:43] * ayoy hides... [21:57:10] or I'll test it tomorrow or so [21:57:24] it always fails here [21:57:39] *** glibc detected *** ./svgtest: malloc(): memory corruption: 0x00000000020633f0 *** [21:57:41] not segfault, but abort [21:57:44] http://paste.pocoo.org/show/216315/ [21:57:46] oshi- [21:58:00] that's bad :/ [21:59:01] the patches are supposed to fix the problem [21:59:16] i just cant understand 100% what they do [21:59:43] hwoarang: nope [21:59:44] since monolithic builds don't fail at all we need to find what we do wrong/differently [21:59:46] it removes QSvgWidgetPrivate class [22:00:05] hwoarang: a user reported that the patches introduce weird behaviours [22:00:15] and upstream rejected them [22:00:17] so it's not instantiated and it doesn't create QWidgetPrivate, which aborts with a memory corruption [22:00:47] instead, the QSvgWidgetPrivate members are stored in QSvgWidget class, which is not exactly how it should be done [22:00:58] indeed [22:01:01] it might work, and in this case it's probably fine [22:01:14] ayoy: some time ago i looked at the original qt code and it looked fine [22:02:18] no idea what can be wrong [22:03:30] *** Joins: pesa__ (~Pesa@host158-186-dynamic.16-79-r.retail.telecomitalia.it) [22:03:37] *** Quits: pesa (~Pesa@host213-117-dynamic.50-82-r.retail.telecomitalia.it) (Disconnected by services) [22:03:47] *** pesa__ is now known as pesa [22:04:16] ayoy: is it possible it could be cflag/ldflag related? [22:04:38] well, maybe... [22:04:48] I have to ask someone smart [22:04:51] lol [22:04:52] maybe tomorrow at work :) [22:05:03] we are all smart here m8 [22:05:03] =] [22:05:12] yeah I know :P [22:05:35] hmm i'll try something [22:06:19] anyway, the thing is that QSvgWidget constructor creates QWidgetPrivate, which is provided by another library (QtGui vs QtSvg) [22:06:44] yep [22:06:45] so maybe some ldflag issue [22:07:04] QWidgetPrivate must be private i guess [22:07:12] could it be that the compiler doesn't know its size? [22:07:21] but shouldn't that involve a linking problem at link time? [22:07:24] yeah, that;s interesting [22:07:40] the QSvgWidget is allocated on the stack [22:08:11] thus the compiler must know at compile time its size [22:09:00] but i think it should result in a compilation error then [22:09:05] pesa: thats really interesting, but shouldn't it fail? :P [22:09:21] iirc it should not compile [22:09:48] ok i filtered all cflags/cxxflags/ldflags on qt-svg, no change [22:09:49] why? [22:09:55] it can compile easily [22:10:13] it uses libQtSvg, not qsvgwidget.cpp directly [22:10:31] if libQtSvg compiled fine, then it should work [22:10:34] it needs the header though [22:11:02] it uses it when compiling [22:11:17] ah yes i see what you mean [22:11:37] if it compiles, it should see the header :) [22:11:54] s/should see/must have seen/ [22:12:42] it seems that it just imports the code from libQtGui and compiles it [22:12:50] i.e. it compiles its own QWidget class [22:13:02] try nm -D /usr/lib/qt4/libQtSvg.so [22:13:14] nm -D /usr/lib/qt4/libQtSvg.so | grep QWidget [22:13:20] it exports QWidget symbols :) [22:13:40] so it seems that it has its own copy of QWidget [22:14:14] ah [22:14:16] wtf [22:14:25] that's usually bad [22:14:32] yeah [22:14:38] but now I'm checking it on Debian [22:14:41] there's a symbol collision [22:14:43] and the symbols are there [22:14:50] so not our fault, Qt just works like this :P [22:14:54] hm i could test [22:15:04] building qt-svg together with qt-gui [22:15:14] yep, that would be nice [22:15:29] lets see [22:17:03] building [22:17:25] that needs 4-5 minutes [22:17:51] yngwin: lucky ping? [22:17:55] :P [22:18:15] i propose postponing the election till next meeting [22:18:40] *** Joins: pesa__ (~Pesa@host5-185-dynamic.7-79-r.retail.telecomitalia.it) [22:20:42] *** Quits: pesa (~Pesa@host158-186-dynamic.16-79-r.retail.telecomitalia.it) (Ping timeout: 245 seconds) [22:21:01] *** pesa__ is now known as pesa [22:21:24] wired: well [22:21:57] i was thinking about calling a meeting next week just for the elections [22:22:04] we are alread 1month without a leader [22:22:14] what do you guys think [22:22:15] hwoarang: thats fine by me too, as long as we make sure we're all here [22:22:26] okay for me [22:22:29] and how are we gonna ensure that [22:22:38] crap [22:22:42] it works [22:22:43] lol [22:23:11] :) [22:23:17] pesa: it seems you were right (or really close to the issue) [22:23:30] yep, consistent success [22:23:53] so we have to bundle svg inside gui [22:24:07] or figure out how to trick it into working [22:24:13] excellent [22:24:18] woot [22:24:29] fury wired ~/svgtest [22:24:29] $ for (( i = 1; i <= 1000; i++ )); do ./svgtest; done [22:24:29] fury wired ~/svgtest [22:24:29] $ [22:24:33] :p [22:24:50] it definitely works :P [22:24:51] i think that counts for "working" :p [22:25:03] it might be that qt-svg misses some sources to extract [22:25:08] nah i tried that [22:25:13] hm [22:25:18] bizzare :) [22:25:20] ftr what i did was [22:25:30] s/-no-svg/-svg [22:25:38] and added src/svg, [22:25:46] src/plugins/imageformats/svg [22:25:46] src/plugins/iconengines/svgiconengine [22:25:52] in target dirs [22:26:00] removed qt-svg and rebuilt qt-gui [22:26:10] cool [22:26:37] so what do you guys think [22:26:50] can we figure this out or should we just merge qt-gui and qt-svg? [22:27:22] I'm interested in figuring this out :D [22:27:27] btw, it looks like nobody ever experienced this bug in real applications [22:27:47] or they experienced it but didn't narrow down the issue to qt-svg [22:28:08] the ignored it [22:28:11] *they [22:28:19] I've use qt-svg for more than a year last year, and I've never bumped into this... [22:28:27] the app works just right... [22:28:35] I'm all for figuring out how to properly fix it as well [22:28:43] until qt 4.8, then nokia will do it for us :P [22:28:45] I actually experienced some crashes like this :D [22:28:50] with an app that uses qt-svg [22:28:59] but then it started to work, with QT 4.6.2 or so [22:29:09] this could actually be a reason kde crashes [22:29:10] lol [22:29:15] :) [22:29:17] fuck [22:29:57] how about [22:30:06] we give it a week (together with the elections) [22:30:13] and if we can't figure anything out till then [22:30:15] we merge [22:30:23] yeah [22:30:26] merging means changing all deps? [22:30:29] i have a feeling many kde bugs will go away... [22:30:32] pesa: yeah [22:30:44] pesa: qt-svg deps [22:31:26] so plan B is adding IUSE svg in qt-gui [22:32:01] indeed [22:33:39] alright [22:33:52] we're done for today then [22:34:02] if nothing changes [22:34:07] same time, next thursday [22:34:15] elections + qt-svg issue [22:34:24]