[21:01:14] !herd qt [21:01:14] (qt) abcd, ayoy, chiiph, hwoarang, spatz, tampakrap, wired [21:01:34] who's here? [21:01:41] * ABCD is [21:02:01] *** Joins: pesa (~Pesa@host12-190-dynamic.16-79-r.retail.telecomitalia.it) [21:02:03] * ayoy is [21:02:08] i'm here [21:02:13] I'm here [21:02:16] * hwoarang around [21:02:19] nice [21:02:23] ABCD: ? [21:02:31] tampakrap told me he won't be here [21:02:35] ok [21:02:35] who's here? [21:02:35] * ABCD is [21:02:45] perfect [21:02:55] http://gitorious.org/gentoo-qt/pages/Meeting20100624 [21:02:58] who is logging [21:03:02] i am ofc [21:03:05] =] [21:03:22] * wired over 3 mil freenode log lines :p [21:03:32] ok lets start [21:03:35] so [21:03:39] wired^^ lead=chairman [21:03:40] 1. qt4-42 [21:03:44] 1. qt4-r2 [21:03:47] meh today [21:04:01] ok we still have 130 ebuilds using the old eclass [21:04:10] :( [21:04:13] I am working on a repoman check [21:04:17] indeed we do [21:04:31] i have it ready actually [21:04:32] we can do like Arferer and ping everyone everyday [21:04:40] wont work [21:04:49] http://paste.pocoo.org/show/229453/ [21:04:51] i can claim my QA membership and fix them myself [21:05:01] without asking [21:05:02] this is my repoman patch [21:05:12] (results) [21:05:15] nice [21:05:17] wired: excellent [21:05:26] i made it generic [21:05:38] great [21:05:38] so other people will be able to mark eclasses as deprecated and have repoman warn ppl [21:05:49] great job [21:05:58] i recommend [21:06:06] leaving this warning for July [21:06:14] then making repoman fail instead of warn [21:06:27] more like August [21:07:01] one *extra* month should be enough imo, then in August we make it fail and actively help ppl migrate whats left [21:07:08] can i see the code? [21:07:14] can we add the deadline on eclass? [21:07:15] ofc ppl can still repoman --force, but anyway [21:07:20] @DEADLINE: bla bla [21:07:27] so repoman can display that as well? [21:07:45] *** Joins: pesa__ (~Pesa@host23-189-dynamic.245-95-r.retail.telecomitalia.it) [21:07:53] hmm i'd rather not bloat it (yes, you'll see the code after i make some final changes and create a patch/bug) [21:08:04] ok [21:08:14] in any case\ [21:08:19] people wont remember they have 1month to fix it [21:08:24] even as a warning this will be annoying [21:08:33] bug/patch + announcment [21:08:36] and after 1 month they can still commit with --force [21:08:38] ok [21:08:49] in emergencies :p [21:09:17] ok, anyone want to add anything to 1.? [21:09:27] nope [21:09:47] * wired waits 1 minute [21:10:16] alright then. 2. bugZ! [21:10:28] bug #301476 [21:10:31] wired: https://bugs.gentoo.org/301476 "QSvgWidget produce segfaults : x11-libs/qt-svg"; Gentoo Linux, Library; ASSI; antonmx@gmail.com:qt@g.o [21:10:46] oh my... [21:10:56] *** Quits: pesa (~Pesa@host12-190-dynamic.16-79-r.retail.telecomitalia.it) (Ping timeout: 276 seconds) [21:11:06] :) [21:11:09] we're still nowhere with this [21:11:22] indeed [21:11:36] a nice idea was thrown on the table, a 1-2 hour hack session to try and kill this [21:11:41] *** Joins: pesa (~Pesa@host244-190-dynamic.245-95-r.retail.telecomitalia.it) [21:11:45] anyone feel like it? [21:11:51] i do [21:11:52] 21:11:17 (wired) a nice idea was thrown on the table, a 1-2 hour hack session to try and kill this [21:11:55] pesa^ [21:11:55] *** Quits: pesa__ (~Pesa@host23-189-dynamic.245-95-r.retail.telecomitalia.it) (Disconnected by services) [21:11:58] i wonder if it is doable though [21:12:07] hwoarang: the session or the bug? [21:12:07] my usual network problems :s [21:12:10] the bug [21:12:23] hm, there must be some hack :D [21:12:33] tbh i haven't looked at it at all after our last talk [21:12:46] I've just tested it on my box, and nothing special [21:12:47] wired: ok for me [21:12:49] fails from time to time [21:13:00] you guys want a weekday or in the weekend? [21:13:03] =] [21:13:06] i kinda did. Seems like there there is a symbol collision for QWidgetPrivate class [21:13:40] hwoarang: how do you know this? [21:13:54] because I've investigated Qt libs on Debian with nm [21:14:09] and QtSvg also defines QWidgetPrivate there [21:14:16] i cant reproduce it anymore with latest qt-svg-4.7.9999 [21:14:23] o_0 [21:14:31] hwoarang@Mystical ~/svg-issue $ ./a.out [21:14:31] hwoarang@Mystical ~/svg-issue $ [21:14:40] run it like 10 times [21:14:44] or 50 [21:14:44] yeah :) [21:15:19] well, nm output means that QWidgetPrivate is needed by libQtSvg, it doesn't mean that it's actually defined there [21:15:34] i run it 100 times. It failed 4 [21:15:34] the symbol should be resolved at runtime by ld.so [21:15:36] :) that explains a lot [21:16:05] and it is correctly resolved as far as I could test [21:16:30] correctly? all the time? [21:17:02] it seemed so when i tried [21:17:12] can you paste a test case with nm ? [21:17:30] hwoarang: it's not valid actually [21:17:33] nm doesn't help us [21:17:42] what about valgrid [21:17:47] *valgrind [21:17:57] there's a debug flag for the dynamic linker, i dont remember which now [21:18:13] hwoarang: unfortunately i cannot reproduce at all under valgrind [21:18:16] hwoarang: for the record, 'nm -D /usr/lib/qt4/libQtSvg.so' [21:18:31] it seems a hacking session would really help [21:18:38] yep [21:18:43] ok so [21:18:44] when :) [21:18:45] yeah, and we'll learn something from that for sure [21:18:47] so, lets not turn the meeting into that. when do you guys want to? [21:18:53] weekday plz [21:18:57] ok [21:18:59] monday? [21:19:03] same time? [21:19:11] it depends on when [21:19:15] a bit later cause i have soccer training [21:19:24] otherwise on thusday [21:19:25] later would be nice for me too [21:19:25] i meant this monday [21:19:26] 19 UTC? [21:19:32] more like 20 [21:19:46] 20UTC monday: fine here [21:19:50] okay with me [21:19:58] wired: thats 23:00 for us right? [21:20:01] yeah [21:20:03] ok [21:20:05] may be I'll learn something from the session... i don't think I'll be of much use though... but, yes, any time monday is ok with me... [21:20:09] pesa? [21:20:13] ok [21:20:14] fine by me [21:20:16] great [21:20:20] it's 22 here i guess [21:20:26] pesa: right [21:20:31] ok thats done [21:20:37] i should change the topic on #gentoo-qt so we wont forget [21:20:40] i'll send you all a reminder email [21:20:46] and add it to google calendar [21:20:47] =] [21:20:50] good :) [21:20:59] right [21:21:00] next bug [21:21:03] bug #304971 [21:21:04] wired: https://bugs.gentoo.org/304971 "qt-core stores machine-specific information in /usr/share/qt4/mkspecs"; Gentoo Linux, Library; ASSI; ohnobinki@ohnopublishing.net:qt@g.o [21:21:10] next two [21:21:17] thy're related [21:21:20] *they [21:21:20] what are we gonna do with these [21:21:21] yes [21:21:24] 304971, shouldn't it be fixed now? [21:21:24] right [21:21:27] bug #312689 [21:21:30] wired: https://bugs.gentoo.org/312689 "x11-libs/qt-core forces additional CFLAGS and CXXFLAGS for dev-python/PyQt4"; Gentoo Linux, Development; NEW; Martin.vGagern@gmx.net:qt@g.o [21:21:38] ayoy: is it? [21:21:46] no idea :/ [21:21:51] uh? [21:21:51] those changes I made to qt4-build [21:21:58] should fix the issue [21:22:00] in portage? [21:22:09] * hwoarang confused [21:22:15] me too [21:22:17] good question [21:22:29] I haven't committed anything to the tree [21:22:35] please do :p [21:22:43] but I made changes to qt4-build and placed it in qting-edge branch [21:22:43] yes please [21:22:50] then I ported the changes to qt4-build-edge [21:22:58] for testing with .9999 Qt [21:23:01] ayoy: your eclass changes work fine iirc [21:23:08] I tested it with 4.6.2 as well [21:23:17] cool, then I'll commit the changes to portage [21:23:18] we should push them and finally close the bug :p [21:23:20] and we're done [21:23:20] at least 312689 must be fixed [21:23:23] yeah [21:23:40] 304971 is more general though [21:23:55] i dont see how can we fix QMAKE_LIBDIR_QT [21:23:58] it's about "machine-specific info" [21:24:22] i wonder if we can fix it on qt4-r2 + eqmake4 [21:24:22] hwoarang: i dunno if it's even doable [21:24:27] to pase this on eqmake4 [21:24:32] and erase it from mkspecs [21:24:37] yes [21:24:44] but what about developers? [21:24:54] that use pure qmake ? [21:25:00] heh [21:25:03] mmmm [21:25:16] sneaky [21:25:17] they shouldn't be forced to specify LIBDIR [21:25:27] indeed [21:25:30] they'll hate us [21:25:36] no way [21:25:48] I think, 1st let's keep the system healthy [21:26:01] then we can think of formalities, like machine-specific info in share dir [21:26:10] we cannot diverge too much from upstream [21:26:21] ayoy: how that would work [21:26:28] QMAKE_LIBDIR_QT ins not diverging [21:26:30] *is [21:26:44] this looks more like something that upstream should have to change, not us [21:26:47] I mean, what we need to change, we should change [21:26:56] it's a normal process of SW integration [21:27:19] silly question but why anybody would want /usr/lib32/qt4 on 64bit system [21:27:19] but we dont _need_ to change that [21:27:33] do we? [21:27:38] so what's the problem with it at all? [21:27:43] * ayoy is confused now :( [21:27:43] multilib is screwed anyway [21:27:55] their handling of headers is flawed IMHO [21:27:56] QMAKE_LIBDIR_QT is set in such a way that compiling 32-bit Qt apps is [21:27:56] hard. [21:28:06] comment #1 [21:28:19] compiling 32-bit Qt apps?why? [21:28:21] mmm [21:28:25] hwoarang++ [21:28:32] i dont follow [21:28:45] anyway [21:28:46] multilib portage maybe [21:28:56] furthermore, isnt that what the emul-qt* libs are supposed to do ? [21:29:04] thats the... stupid way [21:29:10] the problem is not gentoo-specific [21:29:22] well [21:29:27] i hardly see a problem here [21:29:28] isn't it exactly multilib-specific? [21:29:33] yeah [21:29:37] more like a "feature request" [21:29:38] you compile Qt on 64-bit, you have lib64 [21:29:52] quite sane :) [21:29:52] so you want a Qt compiled in 64bit to compile 32bit apps [21:29:58] are you stupid or something? [21:29:59] :) [21:30:13] I'd like to hear from someone that needs it [21:30:23] if any :p [21:30:25] i guess debian has the same problems...? [21:30:30] and if he does, he for sure knows what he does [21:30:32] or other distros [21:30:41] and he knows how to change QMAKE_LIBDIR_QT to suit him [21:30:48] that's my point of view... [21:30:49] i mean that the issue should be fixed upstream [21:30:51] ok i will ask for clarification why anybody would want a non-default QMAKE_LIBDIR_QT [21:31:17] pesa: even upstream wont be able to fix it :) [21:31:28] there is no point in using 64bit qmake to build 32bit apps [21:31:39] alright, lets see if we can find any real valid reasons to talk about this again [21:31:41] build Qt in your home dir and develop you app there [21:32:15] great [21:32:27] any other bugs you'd like to talk about not in the agenda? [21:32:50] not really :P [21:32:55] i'd like to talk about Nokia Qt SDK [21:33:05] oh [21:33:14] pesa: is that the "windows installer" like app? [21:33:18] and all that new stuff [21:33:34] it's a lot of things actually [21:34:01] the SDK includes qt-4.6.3, qt-creator, madde, qt-simulator, qt-mobility, ... anything else? [21:34:19] like a metapackage :P [21:34:28] yes [21:35:02] pesa: is there a source code for that? [21:35:03] pesa: go on [21:35:09] but maybe it's more than than, maybe it installs some stuff to glue everything together [21:35:24] pesa: are you planning to have a look? [21:35:31] yes definitely [21:35:38] great [21:35:41] my question is how should we handle it? [21:35:49] what do you suggest [21:35:49] I wouldn't say that there are sources for the SDK [21:35:56] ayoy: yes [21:36:00] no sources as I can see [21:36:05] everything is at gitorious [21:36:07] instead, it's a set of apps and libs put together to ease up working with it [21:36:12] probably installed to /opt [21:36:26] pesa: but separate, ain't it? [21:36:32] yes [21:36:32] I mean, no Nokia Qt SDK repo :) [21:36:40] pesa: couldn't we just put the binary in /obt/bin ? [21:36:41] ayoy: afaik, it installs it in your home dir... [21:36:43] :p [21:36:47] chiiph: lool [21:36:53] awesome :P [21:37:02] lol [21:37:04] i don't mean we should provide an ebuild for it, but something which is equivalent [21:37:11] ayoy: I downloaded it a while ago, when the beta came out, and that really freaked me out... [21:37:13] something == a set of ebuilds [21:37:14] http://qt.nokia.com/downloads/sdk-linux-x11-64bit-cpp -> binary [21:37:21] pesa: right [21:37:29] we can use a metapackage that pulls them together [21:37:29] :) [21:37:37] ah I see [21:37:44] we already have qt/qt-creator/qt-mobility [21:37:46] but then we shouldn't call it Nokia Qt SDK [21:37:48] we dont have an ebuild for e.g. qt-simulator [21:38:20] only qt-sdk? [21:38:34] gentoo-qt-sdk(TM) :D [21:38:35] is qt-mobility in? hmm.. I wonder how much time has passed since I've sync'ed everything... [21:38:51] chiiph: qting-edge only [21:39:08] it still needs some work [21:39:17] and 1.0.1 was released [21:39:18] we can have both [21:39:20] qt-sdk [21:39:22] qt-sdk-bin [21:39:28] hwoarang: sure [21:39:32] who wants to work on it? [21:39:52] pesa: which packages are missing? [21:39:54] qt-simulator? [21:39:55] ah there's another potential issue: i think the nokia sdk has an arm cross-compiler [21:40:06] how should we handle that? [21:40:07] true [21:40:19] :/ [21:40:29] can we instruct the meta-ebuild to emerge one using crossdev? [21:40:31] you see, this is something developers install themselves... [21:40:39] especially if it wants to install in $HOME :) [21:40:50] ayoy: that's why i asked, im not sure how to proceed [21:40:53] pesa: this is not the same [21:40:57] is there a real reason to discuss this sdk? I mean... [21:40:58] I mean crossdev [21:41:13] I think we should provide everything separatedly [21:41:20] IMHO, I see two options [21:41:25] and everyone manage their setup [21:41:27] either we install it to /opt [21:41:31] or leave it alone [21:41:32] chiiph: separate whould be fine IMHO [21:41:33] the binary? [21:41:54] the binary SDK i guess [21:41:58] (concerning this magnificient Nokia Qt SDK) [21:42:01] :) [21:42:04] separate ebuilds will require a lot of work and they wont make much sense as separate package [21:42:19] who would want symbian packags installed on a gentoo system [21:42:27] a Qt developer. So use the whole SDK suite [21:42:32] think of Maemo [21:42:33] hwoarang: but a meta package for _everything_ will be too much [21:42:55] or this arm compiler is for Symbian?.... [21:42:58] hwoarang: besides, we can reflect that with useflag deps... [21:43:04] chiiph: thats what i am sayng. I think a qt-sdk-bin would be better [21:43:13] ayoy: for maemo i think [21:43:20] chiiph: nobody would want them installed in his system [21:43:24] yeah, that's what I thought [21:43:33] if I was a developer i would created a ~/qt-develop folder on my home [21:43:37] and do the stuff in there [21:43:42] no spamming my system with crap [21:43:44] you still need windows to develop for symbian [21:43:45] hwoarang: yes, but wouldn't it be a contradiction to have a binary but not the separate modules? [21:43:45] that's what I'm saying all the time! [21:44:05] the binary comes with all the modules embedded [21:44:19] why do you want the modules separated since they only make sense when you have the actual binary [21:44:42] well, qt-creator makes a lot of sense on its own :) [21:44:49] that one yes [21:44:56] why? can't I develop with these modules with vim+console? [21:44:57] now i assume the binary is just an installed [21:45:07] that will fuck up the whole Qt/qt-creator installation :) [21:45:08] lets package whatever we don't have available already and leave the binary [21:45:10] *installer [21:45:20] hwoarang: basically you should be right [21:45:26] gosh [21:45:53] are we approaching a consensus? [21:46:00] do we? :P [21:46:08] we can discuss the matter later [21:46:15] no hurry [21:46:17] wired++ [21:46:49] i'm fine with wired's proposal [21:47:02] ok [21:47:11] if anyone comes up with a reason we should make an ebuild for the binary [21:47:15] we can talk about it again :) [21:47:17] wired: and what about the arm cross-compiler? [21:47:42] crossdev [21:47:51] pesa: if we can make an ebuild for it, it might be worth it [21:47:57] but that needs more research [21:48:00] indeed [21:48:08] I can dig into it, probably [21:48:14] instruct the user to do it [21:48:20] I'm doing something around this stuff at work [21:48:20] via an elog message on pkg_postinst [21:48:27] crossdev is the other solution, but theirs might be... eg more optimized for maemo [21:48:29] but there we're still using scratchbox [21:48:46] wired: it is exactly like that [21:48:59] then an ebuild would be nice [21:49:02] if possible [21:49:06] or at least Nokia has put their fingers on it [21:49:11] :) [21:49:14] errr [21:49:20] shall we use another repo for that? [21:49:27] I don't think so [21:49:33] nah, its nokia stuff [21:49:37] Qt stuff ;p [21:49:41] ;) [21:49:51] no i mean so we wont work directly on qting-edge [21:50:02] an when we do have a working set of ebuilds we can push them on qting-edge [21:50:15] well if you have something totally broken [21:50:17] well, it's an overlay [21:50:18] mask it or use a branch [21:50:20] qting-edge is still kind of a playground, isn't it? [21:50:22] yeah [21:50:23] hwoarang: but there are a couple of ebuilds already in qting-edge... [21:50:30] ok [21:50:38] if users unmask broken ebuilds in an overlay [21:50:41] what can we do? ;) [21:50:42] * hwoarang has to read the git branch manual again [21:50:44] heh :) [21:50:49] ok, i'll finish my ebuild for qt-mobility for now :) [21:50:59] great [21:51:07] pesa: could you please stop working on qt-mobility and do your quizessssSS??? [21:51:09]