[21:02:41] <yngwin> !herd qt
[21:02:41] <willikins> (qt) abcd, ayoy, hwoarang, spatz, tampakrap, wired, yngwin
[21:02:44] <ayoy> hai
[21:02:48] <yngwin> who is present?
[21:02:58] * tampakrap 
[21:03:11] * hwoarang 
[21:03:38] <yngwin> abcd said he couldnt make it, and wired said he would be late
[21:04:03] <hwoarang> right
[21:04:17] <yngwin> spatz: u here?
[21:04:44] <yngwin> ok, let's start, agenda is at http://gitorious.org/gentoo-qt/pages/Meeting20100318
[21:04:57] <wired> im here
[21:04:57] <yngwin> 1. raster useflag
[21:05:02] <yngwin> great
[21:05:38] <hwoarang> ok
[21:05:40] <yngwin> so what do we think about enabling raster by default?
[21:05:52] * hwoarang objects
[21:05:53] *** Joins: spatz_ (~spatz@gentoo/developer/spatz)
[21:06:02] *** Quits: spatz (~spatz@gentoo/developer/spatz) (Ping timeout: 276 seconds)
[21:06:02] *** spatz_ is now known as spatz
[21:06:24] * tampakrap approves
[21:06:31] *** Joins: pontecorvo (~solshark@93-183-243-88-dynamic.retail.datagroup.ua)
[21:06:52] <wired> do we have feedback on raster+kde?
[21:06:52] <yngwin> i would propose we keep it in testing on 4.7 and enable it by default when that goes into the tree
[21:06:52] *** Joins: ohnobinki (~ohnobinki@ohnobinki-1-pt.tunnel.tserv9.chi1.ipv6.he.net)
[21:06:58] <hwoarang> my blog and forums
[21:06:58] <tampakrap> running kde 4.4.1, a bunch of kde/qt apps with raster enabled no problems
[21:07:20] <spatz> crap, we started already? :(
[21:07:23] <spatz> I had connection issues
[21:07:26] <hwoarang> spatz: just a minute ago
[21:07:29] <wired> tampakrap: great. hwoarang a summary of your blog comments and forums?
[21:07:32] <yngwin> glad you could join us :)
[21:07:40] <hwoarang> the summary is that we cant be sure
[21:07:56] <hwoarang> i dont care about kde apps
[21:08:19] <hwoarang> however raster is responsible for some fonts distorsion
[21:08:23] <wired> +1 for yngwin's recommendation then. we can decide when 4.7 is about to go in tree
[21:08:27] <hwoarang> and/or rendering issues
[21:08:35] <hwoarang> like we have it now
[21:08:35] <wired> until then, lets test it in -edge
[21:08:42] <hwoarang> +raster on live until 4.7 final is out
[21:08:53] <wired> yes
[21:08:57] <yngwin> that will be 2-3 months
[21:09:05] <wired> should be enough for testing i guess
[21:09:18] <wired> we should include +raster to alphas and betas as wel
[21:09:20] <wired> l
[21:09:23] <yngwin> ok, anyone opposed to that?
[21:09:30] <ayoy> no :)
[21:09:38] <hwoarang> ;)
[21:09:51] <yngwin> ok, so we enable raster by default on >4.6.9999
[21:10:02] <hwoarang> sure
[21:10:16] <yngwin> good
[21:10:19] <yngwin> 2. review open bugs
[21:10:21] <hwoarang> hold on
[21:10:30] <hwoarang> wired: said about alphas and betas
[21:10:40] <hwoarang> i propose to not bother about TP for now
[21:10:42] <hwoarang> not even ship it
[21:10:44] <wired> TP
[21:10:50] <wired> i guess i can comment on that
[21:10:52] <yngwin> tp is broken, right?
[21:10:55] <wired> it just wont build split
[21:10:57] <wired> period
[21:10:58] <wired> :p
[21:11:17] <hwoarang> since +stable-branch works, it means that _alpha will be  better
[21:11:21] <yngwin> ok, we skip this one then, and wait for next pre-release
[21:11:21] <hwoarang> so screw TP
[21:11:26] <wired> i dont know what they did
[21:11:33] <wired> but even if you try to ./configure manually
[21:11:39] <wired> and remove modules
[21:11:43] <wired> it still builds whatever it wants
[21:11:48] <hwoarang> thats nice
[21:11:50] <wired> so forget about it
[21:12:15] <hwoarang> ok moving on
[21:12:16] <hwoarang> 2.
[21:12:24] <yngwin> a. bug 304971 (qt-core stores machine-specific information in /usr/share/qt4/mkspecs)
[21:12:26] <willikins> yngwin: 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:12:32] <ayoy> yeah
[21:12:38] <ayoy> I wanted to bite this
[21:12:43] * hwoarang steps aside and listens
[21:12:44] <yngwin> good
[21:12:53] <ayoy> but when I looked at qt4-build_src_prepare() I cried :(
[21:13:13] <hwoarang> with all the sed crap?
[21:13:17] <ayoy> yeah
[21:13:41] <ayoy> I hope that we can move it out of mkspecs directory anyway
[21:14:02] <ayoy> and just set the env values where needed on the fly
[21:14:05] <ayoy> during building
[21:14:13] <yngwin> that would be ideal
[21:14:15] <ayoy> however, I can test it for amd64 and x86, and that's it
[21:14:31] <ayoy> and we have there lots of stuff for different arches
[21:14:51] <hwoarang> ayoy: dont worry about other arches
[21:14:51] <ayoy> I guess I'll branch qting-edge and work there for some time
[21:14:57] <hwoarang> most of them wil be dropped for 4.7
[21:14:59] *** Joins: mrpouet (~quassel@gentoo/developer/mrpouet)
[21:15:07] <ayoy> oh!
[21:15:12] <yngwin> what?
[21:15:16] <mrpouet> ?
[21:15:16] <wired> lol
[21:15:30] <hwoarang> yngwin: at least ppc and hppa have issues
[21:15:33] <ayoy> will Nokia stop supporting them?
[21:15:43] <hwoarang> only arm is actively maintained by nokia
[21:15:54] <hwoarang> plus the two big arches
[21:16:08] <ayoy> good
[21:16:14] <yngwin> i dont think we need to drop keywords
[21:16:22] <hwoarang> we can be sure now since i doubt that anyone beyong amd64/x86 is testing Qt4.7 on gentoo
[21:16:24] <yngwin> unless there are specific problems
[21:16:27] <ayoy> sure, we can just wait for bugs
[21:16:34] <hwoarang> so ayoy can work on qt4-build-edge eclass without branching it
[21:16:53] <ayoy> I'd better branch it anyway :P
[21:17:00] <hwoarang> yngwin: we wont be we wont be able to fix arch-specific issues when they appear
[21:17:08] <ayoy> then once I have something I'll present it on the ml
[21:17:17] <ayoy> or in a merge request, wow :)
[21:17:23] <wired> hahah
[21:17:23] <hwoarang> ok
[21:17:26] <wired> :D
[21:17:32] <tampakrap> lol
[21:17:35] <yngwin> hwoarang: not in overlay, but we can have arches test the in tree ebuilds/eclass
[21:17:51] <hwoarang> sure
[21:18:40] <yngwin> most of the problems are in webkit
[21:19:05] <wired> are we done with this bug?
[21:19:11] <ayoy> kinda :)
[21:19:19] <wired> great. speaking of webkit
[21:19:22] <yngwin> ok, ayoy will work on this
[21:19:27] <wired> bug 292337
[21:19:29] <ohnobinki> :-)
[21:19:31] <willikins> wired: https://bugs.gentoo.org/292337 "x11-libs/qt-webkit-4.5.3 requires dbus or not?"; Gentoo Linux, Applications; REOP; tot-to@tot-to.com:qt@g.o
[21:19:34] <wired> i tested this
[21:19:38] <wired> (altho i havent commented)
[21:19:40] <wired> (yet)
[21:19:43] <yngwin> and?
[21:19:48] <wired> webkit does not need dbus
[21:19:55] <wired> arora works fine without qt-dbus around
[21:19:59] <yngwin> ok, so we can make it optional
[21:20:38] <hwoarang> fine
[21:20:51] <yngwin> ok, what about bug 300594
[21:20:53] <willikins> yngwin: https://bugs.gentoo.org/300594 "QMAKESPEC for amd64: linux-g++-64 or linux-g++?"; Gentoo Linux, Applications; NEW; pva@g.o:qt@g.o
[21:21:29] <ayoy> well, the thing is that Qt's configure would select linux-g++-64 when ran by hand
[21:21:43] <ayoy> we can follow it
[21:21:55] <ayoy> however Debian and Ubuntu don't
[21:22:08] <ayoy> and they set linux-g++ as default
[21:22:31] <ayoy> pva states that setting -64 would break multilib-portage
[21:22:46] <ayoy> but I doubt, because it will be easily fixable in eqmake4
[21:22:52] <hwoarang> whats the pros and cons
[21:22:54] <hwoarang> i dont understand
[21:23:24] <ayoy> hwoarang: that's really good question!
[21:23:34] <yngwin> debian guys usually know what they're doing
[21:23:38] <ayoy> because it doesn't matter from portage's point of view
[21:23:57] <yngwin> we have g++ now, right?
[21:23:58] <ayoy> portage overrides C(XX)FLAGS anyway
[21:24:00] <ayoy> yes
[21:24:06] <ayoy> I think we can stick to it
[21:24:08] <yngwin> so i'd say we keep that
[21:24:11] <ayoy> less troubles for us
[21:24:15] <ayoy> cool
[21:24:21] <hwoarang> i cant comment on the bug cause I am missing the whole point
[21:24:24] <hwoarang> ayoy: can you?
[21:24:30] <ayoy> sure :)
[21:24:32] <hwoarang> ok
[21:25:15] <yngwin> ok, next?
[21:25:36] <yngwin> b. regressions 4.6.1→4.6.2
[21:25:53] <hwoarang> only one
[21:25:56] <hwoarang> the qt-creator
[21:26:05] <hwoarang> bug 308563
[21:26:08] <willikins> hwoarang: https://bugs.gentoo.org/308563 "qt-creator-1.[2-3].1 very slow sto start and closing"; Gentoo Linux, Development; NEW; maialovic@gmail.com:qt@g.o
[21:26:17] <hwoarang> which might be unrelated to Qt
[21:26:21] <yngwin> wasnt that solved with the rss useflag?
[21:26:53] <hwoarang> thats kinda different
[21:26:58] <hwoarang> the delay is huge
[21:27:00] <hwoarang> 2-3 minutes
[21:27:05] <hwoarang> comment #1: For me it's worse: it takes minutes and then crashes.
Thanks for the hint on downgrading: with 4.6.1 it's fine.

[21:27:15] <yngwin> ok
[21:27:21] <yngwin> is this reported upstream?
[21:27:29] <spatz> maybe it's a matter of rebuilding?
[21:27:44] <hwoarang> i dont know yet
[21:27:46] <hwoarang> there is this bug
[21:27:46] <hwoarang> For me it's worse: it takes minutes and then crashes.
Thanks for the hint on downgrading: with 4.6.1 it's fine.

[21:27:49] <hwoarang> sorry
[21:27:52] <hwoarang> http://bugreports.qt.nokia.com/browse/QTCREATORBUG-315
[21:28:20] <hwoarang> i need to work on this bug asking for rss/doc use flag status etc
[21:28:29] <yngwin> ok last comment there is hopeful
[21:28:45] <hwoarang> but some ppl are still using 4.6.1
[21:28:50] <yngwin> anyway, this is a reason to keep 4.6.1 around a little longer
[21:29:09] <hwoarang> yes plz
[21:29:23] <yngwin> ok, so keep 4.6.1 until this bug is solved
[21:29:43] <hwoarang> thanks
[21:29:53] <yngwin> any other bugs we need to look at?
[21:30:38] <hwoarang> we have some rendering related bugs
[21:31:04] <yngwin> does someone want to look at bug 295342?
[21:31:07] <willikins> yngwin: https://bugs.gentoo.org/295342 "x11-libs/qt-sql-4.6.0 can use libiodbc instead of unixODBC"; Gentoo Linux, Library; NEW; galtgendo@o2.pl:qt@g.o
[21:31:24] <yngwin> it looks quite simple
[21:31:52] <hwoarang> any benefit? i am not familiar with this
[21:32:01] <yngwin> me neither
[21:32:24] <hwoarang> It's a fallback if there's no unixODBC.

[21:32:34] <hwoarang> so unixODBC should be the first choice
[21:32:50] <hwoarang> so it is just a matter of a header inclusion?
[21:33:00] * leio idly notes that you guys have no idea about UTC time ;p
[21:33:15] * leio realizes that this might be a Qt meeting, and a KDE meeting is at 20:00 UTC and shuts up
[21:33:21] <wired> leio: :D
[21:33:21] <hwoarang> :
[21:33:23] <hwoarang> :p
[21:33:25] <yngwin> lol
[21:33:29] <wired> leio: at least you realised quickly :D
[21:33:54] <ayoy> :)
[21:33:59] <yngwin> hwoarang: it's another choice, we could make a useflag for it
[21:34:40] <hwoarang> do we need to do that? since it is a fallback it will use it when needed?
[21:34:49] <hwoarang> and if somebody wants it prob it wont have unixODBC 
[21:35:30] <yngwin> well, there is the header inclusion, and probably a dependency that needs to be adjusted
[21:36:05] <hwoarang> true
[21:36:07] <yngwin> i can look into it for 4.7
[21:36:25] <yngwin> ok, let's move on
[21:36:33] <yngwin> what rendering bugs?
[21:36:34] <hwoarang> ok
[21:36:58] <hwoarang> bug 307745 and bug 306603
[21:37:01] <willikins> hwoarang: https://bugs.gentoo.org/307745 "qt4.6.2: taskbar items has a shadow sibling"; Gentoo Linux, Applications; NEW; toralf.foerster@gmx.de:qt@g.o
[21:37:07] <hwoarang> bug 306603
[21:37:10] <willikins> hwoarang: https://bugs.gentoo.org/306603 "x11-libs/qt-gui: Bolden text for missing font styles."; Gentoo Linux, Applications; NEW; voidprayer@gmail.com:qt@g.o
[21:37:12] <yngwin> there is also bug 294031, but that looks to be an upstream issue
[21:37:14] <willikins> yngwin: https://bugs.gentoo.org/294031 ">media-video/vlc-1.0.0, media-video/smplayer-0.6.8, >media-tv/mythtv-0.21 problems with opengl context (cairo-dock)"; Gentoo Linux, Applications; NEW; nebojsa@asnn.org:qt@g.o
[21:37:51] <yngwin> i think all these should be taken upstream, let's see what they say
[21:38:06] <yngwin> any volunteers?
[21:38:30] <hwoarang> i can ask them to take it themselves
[21:39:10] <yngwin> ok
[21:39:49] <hwoarang> moving on?
[21:40:08] <tampakrap> first bug should be reported to plasma first i guess
[21:40:41] <yngwin> yeah good call
[21:40:46] <hwoarang> right
[21:40:58] <yngwin> 3. status of live ebuilds
[21:41:00] <tampakrap> they will guide the user and us if it is a qt bug
[21:41:44] <tampakrap> and second one contains patches that should be reviewed by us and taken upstream
[21:41:44] <yngwin> hwoarang: you wanted to say something about live?
[21:41:53] <tampakrap> that's all sorry for the noise :)
[21:41:58] <yngwin> np
[21:42:05] *** Joins: dagger (~quassel@gentoo/developer/dagger)
[21:42:13] <hwoarang> yngwin: are we on 4?
[21:42:25] <yngwin> [20:40:04] <yngwin> 3. status of live ebuilds
[21:42:32] <hwoarang> ok
[21:42:33] <hwoarang> so
[21:43:02] <hwoarang> a month ago asked you to add your self here http://gitorious.org/gentoo-qt/pages/Qt4%20live%20ebuilds so I would know who maintains what
[21:43:10] <tampakrap> about live ebuilds i want to say first that i have hardware issues i hope they will be fixed next week and i'll start taking care of 4.6.9999[kde-qt] ebuilds again
[21:43:13] <hwoarang> so is it me and Ben only?
[21:43:34] <tampakrap> that's why i didn't add myself yet
[21:44:02] <hwoarang> plus I consider 4.9999 as the most important version
[21:44:16] <hwoarang> because every 4.X is based on that and the ebuilds should be fully working
[21:44:27] <hwoarang> otherwise we spend hours fixing 4.X and 4.9999 packages
[21:44:34] <tampakrap> yes i could upgrade np
[21:44:37] <yngwin> we could probably sync 4.9999 with 4.79999
[21:44:42] <hwoarang> so either we need to actively take care of 4.9999 or drop it
[21:44:50] <wired> i used to test live but i havent even touched it lately
[21:44:50] <hwoarang> yngwin: they are 90% synced
[21:44:55] <hwoarang> we synced them now
[21:45:00] <yngwin> ok
[21:45:03] <hwoarang> before we push 4.7.9999 
[21:45:11] <hwoarang> but they will br b0rked again when Qt moves to 4.8
[21:45:20] <tampakrap> as they should
[21:45:31] <hwoarang> if nobody cares about 4.9999 we can at least mask it
[21:45:46] <ayoy> well, I can try it
[21:45:48] <wired> there is no need to mask live ebuilds, they are expected to fail
[21:45:51] <ayoy> at least I can compile it in chroot
[21:45:55] <ayoy> to verify that it builds
[21:45:56] <hwoarang> wired: failed by upsteram
[21:45:58] <hwoarang> *upstream
[21:46:09] <hwoarang> but we are talking abuot packaging failures now
[21:46:11] <wired> but i might give it a try at some point, no guarantees
[21:46:21] <hwoarang> a build on a chroot is fine
[21:46:22] <tampakrap> live ebuilds shouldn't be masked i agree
[21:46:30] <hwoarang> to verify that the ebuilds are in a sane status
[21:46:46] <hwoarang> again: they should be masked if the packages are b0rked
[21:46:48] <wired> masking live ebuilds is annoying. let it fail and users will open bugz :p
[21:46:54] <hwoarang> i am not talking about upstream failures
[21:47:04] <hwoarang> so 
[21:47:04] <wired> bugs are motivators
[21:47:05] <wired> :)
[21:47:10] <ayoy> :)
[21:47:14] <hwoarang> if they open bugs we wont fix them
[21:47:17] <hwoarang> since we dont use 4.9999
[21:47:23] <yngwin> well, it looks like we have no 4.9999 users, i havent seen any reports about our ebuilds being broken
[21:47:27] <tampakrap> every failure in live ebuilds isn't a reason for masking
[21:47:31] <hwoarang> we should at least let them know that we aint using .49999
[21:47:49] <hwoarang> tampakrap: how are you gonna fix them?
[21:48:05] <wired> yngwin: i guess its hard to use a live library :)
[21:48:08] <tampakrap> live ebuilds are supposed to be broken/experimental
[21:48:16] <hwoarang> no
[21:48:24] <hwoarang> i am expecting 4.7.9999 to be fully working
[21:48:30] <spatz> doesn't Sput use it?
[21:48:35] <yngwin> the code is supposed to be experimental, but the ebuilds should work
[21:48:39] <hwoarang> ^^
[21:48:41] <ayoy> spatz: I was about to suggest him :D
[21:48:45] <hwoarang> Sput is using 4.7.9999 -stable-branch
[21:48:46] <yngwin> Sput is on 4.7.9999 now
[21:48:54] <spatz> move him then :)
[21:48:57] <hwoarang> the ebuilds must be OK
[21:49:06] <hwoarang> no matter what is the status of upstream repo
[21:49:26] <Sput> 4.7.9999 has no regressions with KDE trunk that I've noticed
[21:49:34] <Sput> there's a regression in Quassel which I've fixed earlier today
[21:49:39] <hwoarang> i couldnt build kde-4.4.1 today
[21:49:44] <yngwin> well, i can look into syncing the ebuilds, but i'm not going to test 4.9999, i'm sticking with 4.7.9999
[21:49:48] <hwoarang> because of some QString class definitions errors
[21:50:13] <hwoarang> yngwin: now 4.7 and 4.9999 should be identical
[21:50:20] <hwoarang> however they are not 
[21:50:25] <Sput> there is one binary incompatible change in Qt that affects some KDE programs that thiago has fixed in master at least, not sure if it affects older KDE versions though
[21:50:28] <hwoarang> now it is a good time to sync them once and for all
[21:50:42] <yngwin> yeah, i can fix that for now, but someone else should pick up maintenance
[21:50:45] <Sput> s/master/KDE trunk/
[21:50:56] <hwoarang> yngwin: i will setup a chroot and start building it
[21:51:02] <yngwin> ok
[21:51:09] <Sput> in any case, I can't build assistant-4.7.9999
[21:51:13] <Sput> it fails linking here.
[21:51:17] <hwoarang> -stable-branch?
[21:51:23] <Sput> it also builds some parts of corelib and qtxml
[21:51:25] <Sput> yes
[21:51:30] <hwoarang> afaik nobody uses -stable-branch now
[21:51:31] <hwoarang> :/
[21:51:35] <Sput> but it shouldn't be building corelibs
[21:51:37] <hwoarang> ^^yet another problem
[21:51:42] <tampakrap> i used to
[21:51:43] <Sput> that looks like an ebuild bug
[21:51:47] <hwoarang> prob
[21:51:49] <yngwin> yeah, we should look into that
[21:52:09] <Sput> it then can't link to QtGui because of a missing symbol, no idea where that comes from
[21:52:57] <yngwin> ok, anything else on live?
[21:53:24] <tampakrap> i'll fix my machine and report back on next meeting
[21:53:43] <yngwin> ok
[21:53:46] <yngwin> tnx
[21:53:50] <yngwin> 4. what else needs to go into our faq?
[21:54:03] <yngwin> i dont know if you guys saw what i put in the repo
[21:54:08] <hwoarang> i did
[21:54:11] <tampakrap> yes good work
[21:54:21] <yngwin> :)
[21:54:23] <tampakrap> did you mention it in the project space? i didn't look at it
[21:54:31] <yngwin> not yet
[21:54:36] *** Quits: spatz (~spatz@gentoo/developer/spatz) (Ping timeout: 276 seconds)
[21:54:48] <hwoarang> yngwin: what is this faq for?
[21:54:55] <hwoarang> what is the target group?
[21:54:59] <yngwin> users
[21:55:02] <hwoarang> everybody?
[21:55:02] <tampakrap> for users asking what the faq is going on
[21:55:09] <hwoarang> if so
[21:55:13] <yngwin> like stuff that keeps getting asked on the forums and irc
[21:55:18] <hwoarang> we can add infos about the live pacakges
[21:55:24] <tampakrap> yes nice idea
[21:55:31] <hwoarang> like "Which version of Qt should I pick"
[21:55:33] <yngwin> sure
[21:55:43] <yngwin> do you want to write something up?
[21:55:48] <hwoarang> "Can I downgrade Qt"
[21:55:55] <yngwin> ah thats a good one
[21:55:59] <hwoarang> i might come up with something
[21:56:39] <hwoarang> well qt-qt3support and blockes are the most common
[21:56:42] <hwoarang> so we should be fine
[21:57:00] <tampakrap> ok just add it in project space
[21:57:02] <yngwin> ok, feel free to add stuff
[21:57:07] <tampakrap> btw we have qt.gentoo.org now :)
[21:57:14] <yngwin> yeah nice
[21:57:22] <ayoy> :)
[21:57:37] <hwoarang> are we done?
[21:57:42] <hwoarang> can we drop 4.5.3 btw?
[21:57:45] <yngwin> hm, we need a rst2guidexml
[21:57:54] <tampakrap> why?
[21:57:56] <tampakrap> leave it there
[21:58:00] <yngwin> i'd say keep 4.5.3 around for now
[21:58:18] <hwoarang> ok
[21:58:20] <tampakrap> (i'm talking about rsr2guidexml)
[21:59:30] <tampakrap> are we done?
[21:59:43] <hwoarang> i think so 
[21:59:49] <wired> right on time
[21:59:54] <yngwin> anything else?
[22:00:09] *** Quits: willikins (~rbot@gentoo/bot/Willikins) (Read error: Operation timed out)
[22:00:17] <yngwin> ok, thanks guys
[22:00:20] <ayoy> thanks a lot!
[22:00:22] <yngwin> ====================================