[20:59:26] hai [21:01:58] is it that time again? [21:02:27] it seems so [21:03:10] *** Joins: spatz (~spatz@gentoo/developer/spatz) [21:04:04] qt meeting :D [21:04:24] yeah, let's meet ;) [21:04:33] *** Joins: yngwin (~yngwin@gentoo/developer/yngwin) [21:04:41] *** Joins: jmrk_ (~jmrk@dslb-088-064-088-198.pools.arcor-ip.net) [21:04:54] so who's here? [21:05:07] * ayoy is here [21:05:11] * ABCD is here [21:05:31] * yngwin [21:06:08] so yngwin and hwoarang too [21:06:11] * reavertm just watching men at work [21:06:20] where's wired and tampakrap? [21:06:23] im here [21:06:25] !herd qt [21:06:27] (qt) abcd, ayoy, hwoarang, spatz, tampakrap, wired, yngwin [21:06:30] *** Joins: far_jump (~wizard@pool-71-252-110-24.washdc.east.verizon.net) [21:06:43] tampakrap is absent as announced [21:07:08] so just wired and pesa [21:07:16] ah, pesa, right [21:07:32] *** Joins: Vtester (~loukas@ppp079166118025.dsl.hol.gr) [21:07:34] agenda is at http://gitorious.org/gentoo-qt/pages/Meeting20100218 [21:08:31] *** scarabeus sets mode: +o yngwin [21:08:38] ok, others will show up later i hope [21:08:39] sweet [21:08:46] let's get started [21:09:01] *** Quits: Vtester (~loukas@ppp079166118025.dsl.hol.gr) (Client Quit) [21:09:02] oioi [21:09:09] when did it get to 9pm [21:09:12] stupid time :P [21:09:14] *** yngwin changes topic to 'Gentoo Qt team meeting now |' [21:09:16] date -u [21:09:16] im here :) [21:09:27] *** yngwin changes topic to 'Gentoo Qt team meeting now | agenda: http://gitorious.org/gentoo-qt/pages/Meeting20100218' [21:09:35] *** Joins: Vtester (~loukas@ppp079166118025.dsl.hol.gr) [21:09:43] nice [21:09:45] wired: you logging? [21:09:48] yeap [21:09:58] good, let's get started [21:10:01] 1. raster on by default? [21:10:11] i hear kde is still a bit glitchy [21:10:14] w/ raster [21:10:25] works fine here, but reavertm reported glitches [21:10:28] is this about turning it on by default in the tree or the overlay? [21:10:30] I haven't tried it in a while [21:10:35] spatz: tree [21:10:49] not glitches, crashes [21:10:51] I would say to wait for 4.7 [21:10:57] but quite infrequent [21:11:08] i haven't tested it so i can't have a personal preference, but after talking with reavertm, maybe 4.7 is a better target [21:11:10] ok, i agree with hwoarang [21:11:12] works great on three machines I've checked, but they're all nvidia so I don't know if it's representative [21:11:15] still it seems like we should wait [21:11:28] *** Quits: Vtester (~loukas@ppp079166118025.dsl.hol.gr) (Read error: Connection reset by peer) [21:11:31] maybe turn it on by default for all the overlay ebuilds [21:11:37] seems we agree, let's wait and re-evaluate when 4.7 is released [21:11:49] breaking the overlay would be interesting [21:11:50] is there warning still present on live ebuilds? [21:11:50] :p [21:11:55] you know, kde guys tend to abuse every api they put their hands on, so... [21:12:01] i dont mind playing around with live ebuilds [21:12:11] there should be no warning about raster, just useflag description [21:12:21] as long as we use a warning message to let users know about this [21:12:38] in live ebuilds? we could do that [21:12:48] if we agree to enable that use flag by default, i would like to use a way to inform the users [21:12:56] otherwise they might not notice it [21:12:56] *** Joins: ssuominen (~ssuominen@gentoo/developer/ssuominen) [21:13:04] oh they'll notice [21:13:09] i wouldnt [21:13:16] since i blindly build the live packages every day [21:13:31] you wouldn't notice a sudden 12ebuild USE change?... [21:13:33] yes, i agree we should inform them, also because we want feedback [21:13:43] ^ [21:13:54] only qt-gui would change [21:14:03] whatever [21:14:03] :) [21:14:09] spatz: right, i was thinking exceptions-style :P [21:14:17] maybe an einfo "Raster is turned on by default in live ebuilds, please let us know if you have any problems" [21:14:18] *** Joins: Vtester (~loukas@ppp079166118025.dsl.hol.gr) [21:14:23] sure ! [21:14:28] yngwin: sounds good [21:14:32] ok [21:14:55] i'm planning to start using live trunk now until we have 4.7 pre-release [21:15:03] scary! [21:15:11] yngwin: I would suggest an elog instead of an einfo :) [21:15:12] its been a while since i last used a trunk version [21:15:14] 4.7 went into feature freeze today [21:15:22] ABCD: yes, that's better [21:15:24] but i now have chroots so i can do that toot :) [21:15:25] too* [21:15:40] we should redistribute the live packages again at some point [21:15:48] i doubt that all of them get tested [21:16:07] hmm, how would you redistribute em? [21:16:10] they probably aren't but they are live ebuilds [21:16:20] even if they occasionally break i don't see any harm done [21:16:27] yngwin: i mean that you should take the 4.9999 one, me the 4.6.9999 etc [21:16:36] ah ok [21:16:56] hwoarang: we can do this over mail like last time [21:17:00] just to make sure that all of them are in a good shape and that we have at least one pc that uses every version [21:17:02] well, i can take on 4.9999 for now, until 4.7 is branched [21:17:23] wired: i think we should write this down since I always forget who maintains what [21:17:38] wiki seems a good place to me [21:17:50] indeed [21:18:03] we will take about this over mail [21:18:03] let's put it in the wiki [21:18:08] or [21:18:15] we can edit the wiki ourselves [21:18:24] ok, shall we move to point 2? [21:18:27] sure [21:18:31] devs testing ebuilds can just add themselves on the wiki [21:18:33] :) [21:18:40] exactly [21:18:43] 2. gentoo-qt irc channel [21:18:43] yes that is better [21:19:06] we spoke about this already, and i think most of us agree to use #gentoo-qt as our devroom [21:19:11] +1 [21:19:12] yes yes yes! [21:19:21] ofc [21:19:21] if anyone drops by we can help them as well [21:19:27] it's so nice over here, so calm and quiet :) [21:19:29] ayoy: you're not funny! :P [21:19:29] but i like how its pure Qt talk [21:19:31] better to direct them to #-kde [21:19:40] or if you prefer [21:19:42] but user support is still prefered to go to -desktop or -kde [21:19:43] pure Qute talk [21:19:43] reavertm: I'm just feeling safe over there :P [21:19:44] :P [21:20:01] :) [21:20:05] yngwin: if this is the case, why are we using this channel? [21:20:08] just for dev talk? [21:20:12] ... [21:20:19] hwoarang: to not make a mess of #-kde [21:20:26] which channel? [21:20:30] this one [21:20:31] but there's no reason to have a million support channels, one is enough [21:20:37] which one [21:20:38] I don't think you can provent mess on -kde [21:20:42] *** Parts: Vtester (~loukas@ppp079166118025.dsl.hol.gr) [21:20:42] pre* [21:20:48] this one is for gentoo meetings, it's more generic [21:20:50] you stated above that you will redirect them on -kde or desktop [21:20:51] de-mess #-kde :) [21:20:54] sorry [21:20:55] the -qt [21:20:58] for dev talk! [21:21:02] ok [21:21:08] #-qt is for dev talk [21:21:13] gotcha [21:21:29] I don't think you need one, there's no gentoo-gtk channel after all [21:21:34] as #-kde can get quite busy [21:21:35] :P [21:21:39] reavertm: we actually use it [21:21:50] reavertm: and we like how quiet it is [21:21:51] :P [21:21:57] we generate more discussion than the gnome team [21:21:59] so why debating his topic? [21:22:02] plus Qt and surroundings is growing [21:22:22] we debate it because it wasnt official before [21:22:31] it has grown this way in recent months [21:23:08] alright [21:23:17] 3. qt:3 removal [21:23:34] the big mask is scheduled for this sunday [21:23:58] it looks like we are mostly on track [21:24:06] except for mythtv [21:24:29] ssuominen, scarabeus: does QA have anything to say about this? [21:25:13] any bug # for mythtv? [21:25:48] yes bug 299222 [21:25:50] yngwin: https://bugs.gentoo.org/299222 "Please mark media-tv/mythtv-0.22-p23069 stable"; Gentoo Linux, Ebuilds; NEW; rich0@g.o:cardoe@g.o [21:26:37] basically someone who knows mythtv should write a news item pointing to instructions on database upgrade issues [21:27:03] i'd like to see gambas bumped without USE="qt3", wpa_supplicant cleaned up (the versions with still USE="qt3" removed) and then there is mythtv... [21:27:03] i doubt that we can sort this out till sunday [21:27:25] and avoid all the use.masking of qt3 flag as unnecessary [21:27:52] ssuominen: we will just mask the qt3 useflag, so that should not generate problems afaik, but mythtv is a bigger issue [21:28:15] if gambas and wpa_supplicant is handled, the use.masking is unnecessary [21:28:30] and kde-sunset users don't get screwed :) [21:28:38] hmm [21:28:59] i was planning on getting some files ready for sunset users anyway [21:30:06] so what's the plan for mythtv? [21:30:28] the maintainer has said he has no time to write a news item [21:30:53] silense [21:30:54] :P [21:31:01] he would even be okay with just marking the new version stable [21:31:51] that would take some time, no? [21:32:20] its just 3 arches [21:32:38] i think it could be done in a week [21:32:55] IF, and thats a big IF, someone can take care of the news item first [21:33:22] well someone has to try new mythtv first, has anyone done that? [21:33:30] yes plenty [21:33:53] so write the news item! :P [21:34:23] i havent and i dont know which instructions are the right ones [21:34:33] ah [21:34:37] i thought _you_ had [21:34:37] all i can do is refer ppl to the comments on the bug [21:34:50] no then it would already be taken care of [21:35:05] right [21:35:13] i know that ppl have, as can be seen in the comments on the bug [21:35:16] so we _must_ take care of it to remove qt3... [21:35:33] "I HIGHLY recommend publishing a HOWTO or a news item regarding the utf8 issues, [21:35:33] unless they no longer exist. Otherwise everybody who just does an emerge -u [21:35:33] world is going to end up with a ruined mythtv database with no easy recovery [21:35:33] path. " [21:36:09] "My understanding is that if you DON'T run the manual database fixes (which will [21:36:09] be required for anybody who has been running stable on gentoo for more than a [21:36:09] year or two), you end up with a mix of text encodings in the database, and that [21:36:09] is pretty-much unrecoverable (without a lot of manual cleanup)." [21:37:48] personally i see two choices: (1) leave qt:3 itself and mythtv unmask for a little longer, or (2) mask all of mythtv until this is sorted [21:38:04] meh [21:38:06] mmm [21:38:17] well we're stalling here [21:38:42] maybe (1) is a better option for our users [21:38:58] i prefer option 1, but then i want someone promising me this will be taken care of within say the next two weeks [21:39:30] !meta mythtv [21:39:32] spatz: Package: media-tv/mythtv Herd: mythtv Maintainer: cardoe@gentoo.org, (Maint-desc: Do not CC me on bugs) [21:39:36] as things stand now, i consider mythtv maintainer-needed and that forces me to go for option 2 [21:40:01] !herd mythtv [21:40:02] spatz: (mythtv) beandog, cardoe, tanderson [21:40:13] maybe beandog or tanderson can do something? [21:40:32] doubtful [21:40:51] beandog is still on pre-current stable [21:41:03] tanderson could in principle [21:41:43] i'll write an email to mythtv herd then and let them make the choice [21:41:52] ok [21:42:01] we could... extend the qt mask for one week, open a forum item and/or bug about it requesting info on the upgrade path [21:42:06] then just mask if noone cares enough [21:42:40] the bug was opened almost two months ago, no one has cared so far [21:42:48] i was hoping for users not devs [21:43:07] yes, the only helpful feedback on the bug is from users [21:43:26] but we could open a forum thread either way [21:44:39] so what's the decision, the masking is postponed in the mean time? [21:44:54] i 'd say so [21:45:19] i'd say we go ahead unless we get positive feedback that mythtv will be fixed soon [21:45:59] they have known this for 6 months now [21:46:38] they=cardoe? [21:46:52] yes, and the other herd members [21:47:05] as you wish [21:47:23] at least tell them ( comment on the bug ) that there is a final deadline till sunday [21:47:25] I don't like screwing users over due to dev incompetence [21:47:35] actually, till tomorrow so the arch team can stabilize it ASAP [21:47:39] i dont see the point of postponing if nobody is committing to fixing the situation [21:47:48] even if the news item is out in 3 mins they won't stabilize it until sunday [21:47:53] it could take another 6 months [21:47:58] i can for amd64 [21:48:04] and we can push the rest archers [21:48:14] if the news item is organized, then i'd be willing to postpone [21:48:39] so let's start a forum thread and ask users for a mini migration guide [21:48:49] ok sounds fine [21:48:55] fine with me [21:49:30] ok, any other qt3 related issues? [21:49:33] no [21:49:40] none I can think of [21:49:49] any bugs open on what ssuominen mentioned, gambas and wca_supplicant? [21:49:53] ssuominen mentioned gamabas and wpa_supp [21:50:04] spatz: there must be [21:50:31] gambas: bug 301376 and bug 302136 [21:50:33] ssuominen: https://bugs.gentoo.org/301376 "dev-util/gambas has optional dep on qt:3"; Gentoo Linux, Ebuilds; NEW; yngwin@g.o:maintainer-needed@g.o [21:50:46] and bug 302136 [21:50:48] yngwin: https://bugs.gentoo.org/302136 "dev-util/gambas-2.19.0 version bump"; Gentoo Linux, Applications; NEW; jer@g.o:maintainer-needed@g.o [21:50:55] thanks willikins [21:50:59] bug 246932 [21:51:01] spatz: https://bugs.gentoo.org/246932 "net-wireless/wpa_supplicant USE="qt3" removal"; Gentoo Linux, Applications; NEW; yagorbunov@mail.ru:mobile@g.o [21:51:10] !herd mobile [21:51:11] hwoarang: (mobile) betelgeuse, cardoe, genstef, peper, steev [21:51:17] ya right [21:51:18] :) [21:51:25] dead herd [21:51:40] i bet we can touch them without even notice it [21:51:41] !meta -v net-wireless/wpa_supplicant [21:51:42] ABCD: Package: net-wireless/wpa_supplicant Herd: mobile Maintainer: gurligebis@gentoo.org [21:51:43] ABCD: (mobile) betelgeuse, cardoe, genstef, peper, steev [21:51:44] i can look at gambas [21:51:46] dont tell betelgeuse that :P [21:52:04] :P [21:52:12] i can ask and take care of wpa_supplicant [21:52:20] yngwin: I started working on gambas once, here's the ebuild: http://paste.pocoo.org/show/180222/ [21:52:32] yngwin: gambas-2.19.0.ebuild [21:52:39] i could also take care of wpa_sup [21:52:39] ok [21:52:41] i use that thing [21:52:42] :p [21:52:48] great [21:52:51] yngwin: I gave up after it started running xdg-utils crap and give me SANDBOX violations [21:53:00] i c [21:53:06] well, i'll have a go [21:53:09] yngwin: patching them out needs eautoreconf, and eautoreconf needs those optional deps present [21:53:19] yngwin: kinda sucks ;p [21:53:45] well, i'll play with it and see [21:53:51] nice [21:54:06] as it's maintainer-needed we can mask it until someone is ready to pick it up [21:54:37] well it's really simple: if nobody here now cares about it, just add treecleaner@ to CC :P [21:54:59] * hwoarang evil! :) [21:55:15] we are waiting just by the corner [21:55:22] ;) [21:55:32] there's also bug 301382 [21:55:34] https://bugs.gentoo.org/301382 "games-board/qgo removal"; Gentoo Linux, Applications; NEW; yngwin@g.o:games@g.o [21:55:44] oh yeah, trunk is qt4 [21:55:45] a qt4 snapshot version is possible there [21:56:07] there is a live ebuild attached but it needs work [21:56:12] i will take care of it [21:56:17] great [21:56:26] mask the current ebuild in the mean time [21:57:11] then what we need is to prepare a package.mask file with all ebuilds that depend on qt:3, so we can drop that in when the time is ready [21:57:26] that couls also be used as package.unmask for sunset users [21:57:33] indeed [21:57:47] we can work on this in overlay [21:57:47] i propose we work on that in the overlay [21:57:52] ha :P [21:57:54] :) [21:57:59] lol [21:58:08] !rdep qt [21:58:09] yngwin: Too many packages have reverse RDEPEND on x11-libs/qt, go to http://tinderbox.dev.gentoo.org/misc/rindex/x11-libs/qt instead. [21:58:16] that is a good start ^ [21:58:38] noted [21:58:38] and then compare it to the bugs in the tracker [21:58:49] so who is going to work on that? [21:59:00] i will [21:59:08] but it wont be my 1st priority [21:59:11] :/ [21:59:15] i will as well [21:59:19] ok [21:59:23] hwoarang: i'll get wpa from you, so you'll have more time [21:59:23] :p [21:59:28] but i was hoping for some more cooperation [21:59:36] fine wired [21:59:49] yngwin: it doesnt matter since i will have some spare time these days [21:59:56] ok [22:00:11] and we'll stay in touch about this in #-qt [22:00:22] sure thing [22:00:29] anything else about qt:3 [22:00:43] *** Joins: pesa (~Pesa@host37-125-dynamic.50-82-r.retail.telecomitalia.it) [22:00:43] ok, then 4 [22:00:47] 4. qt 4.6.x stabilization [22:00:49] hey guys [22:00:52] sorry for the delay [22:00:52] hello there [22:00:56] hi pesa [22:00:56] hey pesa [22:00:57] no prob ! [22:01:03] dont worry about it [22:01:04] :) [22:01:09] we're not done yet, so [22:01:19] there was a car accident :( [22:01:22] oh [22:01:24] :/ [22:01:25] oops [22:01:26] you ok? [22:01:26] i got trapped in the traffic jam [22:01:31] ah [22:01:32] i c [22:01:32] oh, good you're ok [22:01:35] yeah i wasn't involved [22:01:53] :) [22:01:56] alright :) [22:02:03] lets go to 4. [22:02:17] about stabilization: 4.6.1 now, or wait ~2 weeks and go for 4.6.2? [22:02:23] 2 [22:02:28] 2 [22:02:33] i stick to my original proposal, go for .2 [22:02:43] what are the issues with 4.6.1? [22:03:02] apart from bugs on failed linking/compilation of qt-webkit and qt-gui [22:03:08] nothing really [22:03:10] which are probably invalid [22:03:13] ;) [22:03:22] i would expect 4.6.2 to work better with Kde-4.4 [22:03:23] those are binutils bug afaik [22:03:24] than 4.6.1 [22:03:29] no they are valid, but ppc only and being taken care of by toolchain [22:03:48] yeah, I actually meant so [22:03:49] we have .2 around, no serious bugs yet, lets get straight to that [22:03:54] hwoarang: yes but kde 4.4 is not going stable for the next few months [22:03:54] I think we can stabilize march 1st [22:04:02] spatz: +1 [22:04:07] ok [22:04:23] that's soon enough, imo [22:04:27] assuming nothing horrible pops up in the meantime [22:04:32] as always :) [22:04:42] i agree [22:04:46] ok, it seems the consensus is to do 4.6.2 stablereq on march 1st [22:04:48] no problem for me, just wondering what's wrong with .1 [22:04:55] :) [22:04:55] ayoy: its OLD! [22:04:57] :P [22:05:03] moving to 5? [22:05:04] yeaaaah :D [22:05:07] yup [22:05:18] gogo [22:05:18] pesa: i need your opinion for 5 [22:05:19] 5. shall we keep resetting QMAKE_RPATH in eqmake4? [22:05:19] It might cause problems for some apps that need an RPATH. [22:05:29] hwoarang: oh ok :P [22:05:39] do you remember when and why we added that? [22:05:52] since the beginning IIRC [22:05:57] pesa: not really [22:05:58] indeed [22:06:02] it's not present in qt4.eclass [22:06:03] it was there in 2/2/2009 [22:06:11] yyy? [22:06:17] i mean in qt4-edge [22:06:26] the first commit of qt4-edge has it [22:06:30] yeah, I got it :) [22:06:34] but why/who addedit and why [22:06:39] i cant really recall [22:06:42] uhm [22:06:48] maybe it was in your very primary patches [22:06:54] maybe [22:07:05] well, it's okay to remove fishy RPATHs and it's nice that our eclass does it [22:07:06] i remember there were a bug in older qmake [22:07:11] but there are cases when RPATH is needed [22:07:17] and it's valid [22:07:26] and then we have bug 305445 [22:07:28] https://bugs.gentoo.org/305445 "media-gfx/kst-2.0.0_beta2-r1 does not start"; Gentoo Linux, Ebuilds; NEW; marco.dr@tiscali.it:ayoy@g.o [22:07:30] what if you added in the end of qmake command? [22:07:32] ancient qmake did set a wrong RPATH in most cases [22:07:33] *eqmake4 [22:07:37] as ssuominen pointed out, portage takes care of unsafe RPATHs, so we don't need to worry about it [22:07:47] hwoarang: I haven't tried it [22:07:53] though it should fix the problem [22:07:55] spatz: afaik portage complains [22:08:04]