[19:58:46] *** wired changes topic to 'Gentoo meetings | Qt team meeting now: http://gitorious.org/gentoo-qt/pages/Meeting20101118' [19:58:50] !herd qt [19:58:53] (qt) abcd, ayoy, chiiph, spatz, tampakrap, wired [19:58:58] ohai ^^ [19:59:03] hey there [19:59:06] lalala [19:59:48] it's been a while since we last did this ;) [19:59:53] so, lets see who's here [20:00:07] :P [20:00:12] * ayoy here [20:01:30] * pesa is here [20:02:11] alrighty, so we're missing ABCD and spatz [20:03:13] first of all, I'd like to tell you about my quizzes, if I'm allowed to [20:03:24] yes ofcourse, its in the agenda ;) [20:03:31] go ahead [20:03:32] ok then [20:03:40] after our last meeting in september I almost finished them, only 4-5 answers were missing [20:03:58] but then unfortunately I got caught by several things in my real life and never managed to complete them :( [20:04:20] furthermore, as you probably noticed, I have done basically nothing (i.e. no commits on qting-edge) in almost 2 months [20:04:45] so I thought it made little sense to become a dev if I could not do any development [20:05:12] i hope to get a little bit more free time next month [20:05:28] to finally complete mu quizzes [20:05:34] and resume gentoo development [20:05:39] :) [20:05:39] pesa: it takes time... so you should finish them anyway [20:06:07] pesa: plus becoming a dev can give you motivation to work, imo [20:06:10] :) [20:06:14] ayoy++ [20:06:24] mmm i see [20:06:29] also [20:06:31] that's a great thing [20:06:37] you shouldn't worry about dead... periods [20:06:40] we all have em [20:06:56] we sure do :D [20:07:05] * ayoy for example... :| [20:07:07] i've heard inactive devs are retired [20:07:15] how does that work? [20:07:16] well [20:07:27] if you don't do anything at all for a couple of months [20:07:37] gears will start turning towards your retirement [20:08:07] in general though, even a couple of commits a month will keep that off your shoulder [20:08:11] you shouldn't worry about it [20:08:11] but it has to be literally nothing I believe [20:08:17] exactly [20:08:17] ah ok [20:08:24] in the end [20:08:30] as long as I have any bugs on me I'm towards fixing them [20:08:30] we dont want to push people away [20:08:41] that's why I'm not retired yet :P [20:09:04] we just want to make sure noone stays inactive (and out of date) for like a year, then comes back with commit privileges and no knowledge of the current gentoo status [20:09:37] ok now i see the rationale behind that [20:10:14] there are other reasons too, but in general keep in mind, no-one will hunt you down to retire you. [20:10:30] :P [20:10:58] so, no pressure, but get those quizzes done! heheheheh [20:11:10] so i should dedicate my (little) spare time to my quizzes [20:11:16] :) [20:11:27] yeah [20:11:40] i've started them several months ago :P [20:11:48] that's embarassing at best [20:12:11] don't worry about it [20:12:20] feel free to send them over if you want [20:12:36] ok thanks! [20:12:55] :D [20:13:04] next up, qgtkstyle [20:13:21] yeah :S [20:13:40] as most of you probably read, I managed to split that bastard from qt-gui to solve the qt-gui[gtk]-cairo[qt4] fail [20:14:10] the style works pretty well, but 1) it still depends on cairo[-qt4] [20:14:41] 2) qtrackor takes the gtkstyle's existence for granted [20:15:00] and fails to build if its not built within qt-gui [20:15:14] pesa's rationale about the macro sounds solid [20:15:16] well both issues are minor IMHO [20:15:38] as long as no other packages come around checking for gtkstyle, yeah [20:15:39] BUT they might be clues about a bigger problem behind them [20:16:05] i.e. QT_NO_STLYE_GTK seems to be defined even when qgtkstyle is installed [20:16:33] that's cleary a big problem with how we currently handle the splitting [20:16:47] thats true [20:17:14] so we need to improve the qgtkstyle split [20:17:58] ftr i forgot to mention that to build the style i borrowed the main.cpp file from the first, old release of qgtkstyle, before it was integrated to qt-gui [20:18:29] i'd like to know if QT_STLYE_GTK is defined with qt-gui[gtk] [20:18:35] its not [20:19:05] neither QT_STLYE_GTK not QT_NO_STLYE_GTK ? [20:19:05] *nor [20:19:40] only QT_NO_STYLE_GTK is used [20:19:46] *** Joins: hwoarang (~hwoarang@gentoo/developer/hwoarang) [20:19:58] hai hwoarang :) [20:20:05] hey former qtier [20:20:28] * hwoarang takes a seat [20:21:06] i m confused [20:21:07] configure:[ "$CFG_QGTKSTYLE" != "yes" ] && QCONFIG_FLAGS="$QCONFIG_FLAGS QT_NO_STYLE_GTK" [20:21:17] then its used in a few ifdefs [20:21:35] ah yes [20:21:40] i wasn't looking at configure [20:22:20] i was looking at /usr/include/qt4/Qt/qconfig.h [20:23:02] if both macros are not defined, then it defaults to QT_NO_STYLE_GTK [20:23:42] both macros? [20:23:53] both QT_STLYE_GTK and QT_NO_STLYE_GTK [20:24:09] *STYLE [20:24:35] QT_STYLE_GTK is not used anywhere [20:24:45] the only non NO_ occurence i see is this: [20:24:51] tools/configure/configureapp.cpp: dictionary[ "STYLE_GTK" ] = "no"; [20:24:55] tools/configure/configureapp.cpp: if (dictionary["STYLE_GTK"] != "yes") qconfigList += "QT_NO_STYLE_GTK"; [20:26:57] ok so we all agree this needs to be fixed and returning to qt-gui[gtk] is not an options? [20:27:11] yes, definitely [20:27:21] +1 [20:27:25] yes [20:27:28] yup [20:28:02] ok, so if anyone has time, please have a look at it. we can talk about it here or at qt@ for now [20:28:16] I'll definately spend some more time on it [20:28:53] 2. qting-edge [20:29:17] the overlay qt-* ebuilds need updating [20:29:31] what kind of update? [20:29:41] just a quick sync with the 4.7 is sufficient? [20:29:45] they need to get all the fixes from the gentoo-x86 ebuilds [20:30:13] prefix, move some vars from global to pkg_setup [20:30:20] including qgtkstyle i guess [20:30:25] yeap [20:30:38] i had to do that for 4.7.0 when it hit the tree, because we had based it on the live ebuilds [20:30:52] to ensure this doesn't happen again, we need to update the overlay [20:31:05] does 4.6.9999 still make sense btw? [20:31:24] not really I guess... [20:31:26] probably not [20:32:00] so.. who wants to take care of this? [20:32:05] i'll do it [20:32:10] excellent [20:32:11] 4.7.9999 that is [20:32:11] thanks tampakrap [20:32:26] I'd like to help provided that I find time [20:32:29] tampakrap: 4.9999 will need the same fixes [20:32:43] ok, i can't test that [20:32:53] I think I may give a try with 4.9999 [20:33:11] I can easily build-test any version [20:33:14] i can provide the same fixes in both branches, but 4.9999 will be blind commits [20:33:17] on my chroot [20:33:20] +S [20:33:21] ok [20:33:51] oh do we still have stable USE flag? [20:34:12] stable-branch [20:34:15] ayoy: well if you want to help, please do, just tell tampakrap you're fixing 4.9999 (if you do) so he can skip em [20:34:42] wired: sure, but I could start with it at least next week if not next month... [20:34:47] yeah, i wanted to ask about stable-branch and kde-qt branch [20:35:16] stable-branch for master is useless imho [20:35:22] master is 4.9999 [20:35:42] stable-branch is still available on gitorious [20:35:42] last commit is dated Friday July 09 2010 on the stable-branch [20:35:50] but it's outdated [20:35:53] yeah [20:36:01] it's very old [20:36:10] and 4.7? [20:36:17] 4.7 is updated daily [20:36:44] so i propose to drop stable-branch from 4.9999 [20:36:45] so leave stable-branch only in 4.7.9999 for now? [20:36:54] yes imho [20:36:56] ok, so 4.7 has stable-branch, does it have kde-qt branch? [20:37:08] no [20:37:15] only 4.6.9999 has kde-qt [20:37:34] no wait [20:37:45] * wired still waiting for gitorious to load [20:37:51] any idea why they skipped it then? :) [20:38:07] maybe they integrated kde-qt changes into master [20:38:25] seems impossible [20:38:29] i can't find it [20:38:36] wait [20:38:45] it's slooooow [20:39:22] there's a branch [20:39:32] http://qt.gitorious.org/+kde-developers/qt/kde-qt/commits/4.7.0-patched [20:39:33] kde-qt:4.7.0-patched [20:39:37] ;p [20:39:39] wired: heh ;) [20:40:02] damn gitorious ui sux bad [20:40:20] ok, we need that too [20:40:39] i have a feeling that only applies to 4.7.0 [20:40:40] it's older than 4.7.1 though [20:40:42] so its useless [20:41:19] but it seems they do have [20:41:20] ok [20:41:22] 4.7.1-patched as well [20:41:32] http://qt.gitorious.org/+kde-developers/qt/kde-qt/commit/1b3f43c997b00d6b0d435ed8be08596c913a0189 [20:41:36] it fails to show on the browser [20:41:37] ;p [20:41:39] o_O [20:42:14] github also fails on huge commits ;) [20:42:19] we could provide kde-qt in 4.7.1 [20:42:37] assuming the patches are of real importance [20:42:42] imo there's no need though [20:42:52] ok, cool [20:43:12] k [20:43:25] if a 4.7 branch pops up [20:43:32] we can always add it in 4.7.9999 :) [20:44:03] so no kde-qt for now? [20:44:14] no kde-qt for now [20:44:21] ok [20:44:36] 3. jit USE in qt-{core,script,webkit}. [20:44:57] I was going to test that yesterday... [20:45:05] but I wasn't sure to which versions... [20:45:13] the switch is always on atm [20:45:16] i'd say 4.7.1 [20:45:21] +1 [20:45:36] oks, I can take care of that... [20:46:03] but we'll have to check deps, most packages will probably need qt-*[jit] [20:46:04] cool [20:46:12] uh [20:46:18] yes, it'll be +jit in the USE [20:46:21] enable by default maybe? [20:46:24] of course [20:46:35] but it's an implementation detail i think [20:46:45] deps shouldn't be affected [20:47:16] but they wouldn't be if it's by defaults [20:47:22] *default [20:47:41] alrighty [20:47:59] * hwoarang someone highlight me before you reach the end of agenda [20:48:28] hwoarang: we already talked about pesa, if thats what you're waiting for [20:48:31] ;p [20:48:35] no [20:48:52] * hwoarang wants to read the summary though [20:48:58] * pesa points his torch against hwoarang [20:49:25] okie [20:49:35] thx [20:49:46] so chiiph jit is yours :) [20:50:02] yep... [20:50:04] 4. dev USE in qt-gui [20:50:12] bug 328689 [20:50:14] wired: https://bugs.gentoo.org/328689 "[FEATURE REQUEST] x11-libs/qt-gui: dev USE flag"; Gentoo Linux, Ebuilds; NEW; jonelf@canada.com:qt@g.o [20:50:35] I'm thinking whether it's the best option possible [20:50:42] it's not quite straightforward [20:50:47] "dev" useflag [20:50:51] and it's in qt-gui [20:50:54] kinda weird [20:51:11] devel? development? dev-tools? [20:51:16] I thought about maybe extracting designer and linguist into separate packages [20:51:28] yeah [20:51:32] that wouldn't be a bad idea [20:51:33] i agree with ayoy [20:51:42] also [20:51:48] 4.8 will be modular [20:51:48] that would increase the work on further maintenance ofc :P [20:51:51] anyone know why they were included in qt-gui in the first place? [20:51:58] pesa: I wanted to say that too :P [20:52:00] wired: because they need gui [20:52:07] that will bring hell to our packages anyway [20:52:12] yeah... [20:52:16] I can see them not splitting the same way we do [20:52:25] maybe the designer requires private headers [20:52:29] wired: you're just right [20:52:34] they're not gonna do it our way [20:52:41] I've seen some slides at Qt Dev Days [20:52:45] yeah me too [20:52:47] some blog post [20:52:51] * wired opens reader [20:52:52] don't remember them right now, but it's gonna be different [20:52:54] ;] [20:53:14] http://labs.qt.nokia.com/2010/10/26/qt-is-going-modular/ [20:53:14] http://labs.qt.nokia.com/2010/10/26/qt-is-going-modular/ [20:53:17] hah [20:53:19] yeah [20:53:42] still core+gui are together [20:53:43] they're planning to have core+gui together [20:53:45] we should re-discuss when they reach a final decision [20:53:51] definately [20:53:53] sure [20:54:07] we still have around 1 year :) [20:54:22] ok, who wants to tackle the new split then? [20:54:43] I'd like to do this [20:54:56] but I guess I'll send a mail to qt@g.o beforehand [20:54:57] well i don't think i'll have the time :( [20:55:01] with the possible solutions [20:55:12] ok nice ;) [20:55:22] ayoy: yeah, it may be hard or not beneficial to do in the end anyway [20:55:27] ayoy: great, thanks :) [20:55:36] np :) [20:55:43] 5. 4.6.3 stabilization [20:55:46] you have beer ready? [20:56:03] ayoy: a solution can be "wait for 4.8" :P [20:56:06] ;-) [20:56:12] wired: of course ;) [20:56:17] only ppc64 is left, this was pretty fast, perhaps my mail to arches paid off? =] [20:56:29] definitely [20:56:47] 4.5 can already go [20:57:22] yup [20:57:37] and 4.6.2 as soon as ppc64 is done :) [20:58:11] also, while at this, what do you guys think of x11-libs/qt ? [20:58:42] there are people that still think this actually provides qt [20:58:47] :) [20:59:05] we don't even have a 4.6.3 version [20:59:07] it's misleading [20:59:10] im tempted to send it to oblivion [20:59:27] i want it [20:59:31] why? [20:59:51] because users are asking for it, and i usually have to deal with them [21:00:02] users are asking for it because they think its useful [21:00:04] as i am the only one here with full free time [21:00:04] but it's masked [21:00:11] and noone reads the mask notice [21:00:13] does stable portage support sets btw? [21:00:16] no [21:00:22] qt meta was kept in the tree for qt developers [21:00:32] for those you want *ALL* the qt packages [21:00:37] yes, true [21:00:43] good point [21:00:44] but it seems that they are not the ones using it [21:00:45] emerging qt-demo is the same [21:00:48] or complaining about it [21:01:01] pesa: nice catch :D [21:01:06] heh [21:01:13] nice indeed [21:01:28] except declarative maybe [21:01:30] you can easily mask it for removal along with directions on how to fix world file [21:01:52] ah no [21:01:55] even declarative [21:02:02] because assistant requires declarative :P [21:02:09] how about a news item followed by a rm -f ? :P [21:02:16] qt-demo installs examples for eeeeeeeeeverything [21:02:20] sounds cool [21:02:39] hwoarang: probably needed by all qt devs [21:02:41] ;p [21:02:59] yes [21:03:11] but asking them to install qt-demo to act as meta package is stupid ;P [21:03:17] right [21:03:28] i'm a qt dev and i don't use x11-libs/qt anyway [21:03:31] i still doubt we have ANY users using this package for this reason [21:03:36] I understand why we have it [21:03:41] but all complains so far have been [21:03:44] HEY, new Qt IS OUT [21:03:49] BUMP x11-libs/qt! [21:03:53] ;] [21:03:56] i don't think x11-libs/qt is for devs actually [21:04:08] because they know exactly which modules they need [21:04:14] for their stuff [21:04:37] and they install just those [21:04:38] but then most devs want all the modules [21:04:39] just in case [21:04:41] I'd say... [21:04:53] I'd do that :P [21:04:58] i do that too [21:05:28] hmmm [21:05:33] bah [21:05:34] how about this [21:05:38] i don't reallt care [21:05:38] and the deps are pretty much complex so in the end you end up having installed 12/14 packages [21:05:41] *really [21:05:44] not far from meta package [21:05:52] hwoarang: indeed [21:05:59] we kill all current x11-libs/qt ebuilds [21:06:07] we add a versionless one [21:06:11] with versionless deps [21:06:13] o_O [21:06:26] pesa: the deps need refactoring otherwise you end up with all the modules and hey, you have a full modular Qt installed [21:06:28] or maybe one per 4.x [21:06:40] like qt-meta-4 ? [21:06:59] yeah, tracking the latest stable and testing versions [21:07:23] qt-meta-4.6 and qt-meta 4.7 or something [21:07:28] to account for different modules available [21:07:39] uhm [21:07:45] should work [21:08:05] we can even pkgmove x11-libs/qt to x11-libs/qt-meta [21:08:12] that'll fix all those world files out there [21:08:13] :P [21:08:37] and change the description [21:08:43] yes [21:08:49] make it clear it's a meta-package [21:08:49] and stop providing minor version ebuilds [21:09:12] like kde*-meta [21:09:23] unless its needed for some reason, then we can always add a 4.7.3 on top of 4.7 for example [21:09:34] ok sounds good [21:11:12] lets recap. qt->qt-meta, 4.6 (stable) and 4.7 for starters [21:11:29] we can even unmask it them [21:11:32] rest of the team ^^ ? [21:11:36] yes unmask it [21:11:57] well, why not [21:12:35] well, we don't care actually :) [21:12:39] justdoit [21:12:41] great [21:12:41] :P [21:12:46] I'll do this then [21:12:50] stupid bugs will stop [21:12:53] :D [21:13:06] anything else? [21:13:12] hwoarang [21:13:16] hwoarang wanted something [21:13:19] ye [21:13:22] qt-mobility [21:13:26] ah [21:13:28] status/v bump to 1.1.0 / portage [21:13:39] i taked a look some days ago [21:13:43] *took [21:13:46] ehm [21:13:51] it doesn't compile [21:13:53] :( [21:13:55] the latest release? [21:13:56] i don't see a bug for it, why? [21:14:01] wired: bug? [21:14:06] qt-mobility is on qting-edge [21:14:07] 1.1.0 does not compile [21:14:12] and i couldn't figure out why [21:14:26] xm [21:14:31] hwoarang: well, overlay or not, bug for version bump is always useful to gather attention :) [21:14:37] nobody asked for it yet [21:14:43] bump is not my major concern atm [21:14:44] :) [21:14:50] i want to know about the status and future plans [21:14:56] i'll wait for 1.1.1 [21:15:04] if it works i'll bump it [21:15:09] and you can move to the tree [21:15:17] ppl will ask it as meego matures [21:15:30] plug afaik is the recommended API for meego apps [21:15:37] * hwoarang still needs to read the Nokia blog [21:15:53] i can imagine [21:16:24] if there's a pressing need to have it, I could disable the faulty module and try the other ones [21:16:30] pesa: what's the error with mobility? [21:16:33] but I dunno when i'll have time [21:16:36] no pressure [21:16:41] i can take a look too [21:16:42] wired: i don't remember atm [21:17:05]