[gentoo-commits] gentoo commit in xml/htdocs/proj/en/desktop/qt/logs: qt-project-meeting-20100902.txt

[Alex Alexander (wired)]

wired       10/09/02 21:40:06

  Added:                qt-project-meeting-20100902.txt
  Log:
  20100902 entry and log

Revision  Changes    Path
1.1                  xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100902.txt

file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100902.txt?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100902.txt?rev=1.1&content-type=text/plain

Index: qt-project-meeting-20100902.txt
===================================================================
[22:04:25] <wired> !herd qt
[22:04:26] <willikins> (qt) abcd, ayoy, chiiph, hwoarang, spatz, tampakrap, wired
[22:04:29] <wired> lets begin
[22:04:46] * ABCD is here
[22:04:49] <wired> rollcall
[22:04:51] <wired> ayoy and chiiph won't make it
[22:04:59] * pesa here
[22:05:58] <wired> hwoarang, spatz?
[22:06:03] * hwoarang *
[22:06:27] <wired> spatz probably dc'd. tampakrap you back?
[22:06:45] * reavertm rants that QtWebkit sucks and crashes
[22:07:14] <wired> oh well
[22:07:19] <tampakrap> i'm back
[22:07:22] <wired> great
[22:07:25] <wired> agenda -> http://gitorious.org/gentoo-qt/pages/Meeting20100902
[22:07:36] <wired> 1. qt4-r2.eclass
[22:07:43] <pesa> reavertm: hope it'll get better with qt-webkit 2.0
[22:07:49] <wired> just wanted to update you people
[22:08:01] <wired> we now have pretty repoman check for deprecated eclasses
[22:08:09] <pesa> yay
[22:08:23] <wired> this will probably help get this long list ( http://dev.gentoo.org/~wired/checks/qt4.eclass.html ) down
[22:08:56] <wired> inherit.deprecated            4 app-emulation/virtualbox-ose/virtualbox-ose-3.1.8.ebuild: please migrate from 'qt4' to 'qt4-r2' on line: 7 app-emulation/virtualbox-ose/virtualbox-ose-3.2.6.ebuild: please migrate from 'qt4' to 'qt4-r2' on line: 7 app-emulation/virtualbox-ose/virtualbox-ose-3.2.8.ebuild: please migrate from 'qt4' to 'qt4-r2' on line: 7
[22:09:01] <wired>  app-emulatio/virtualbox-ose/virtualbox-ose-9999.exbuild: please migrate from 'qt4' to 'qt4-r2' on line: 7
[22:09:11] <wired> thats what happens on repoman -v full
[22:09:13] <wired> :)
[22:09:30] <pesa> nice
[22:09:53] <pesa> thanks for implementing that check wired
[22:09:54] <wired> 2. Qt 4.7.0
[22:10:00] <wired> pesa: you're welcome
[22:10:14] <wired> pesa: it's used for other eclasses too ;)
[22:10:28] <pesa> yeah, i had a look at the portage patch ;)
[22:11:02] <wired> ;)
[22:11:13] *** Quits: spatz (~spatz@gentoo/developer/spatz) (Ping timeout: 272 seconds)
[22:11:17] <wired> one more thing before 2.
[22:11:24] <wired> I think its time we fixed ebuilds ourselves
[22:11:25] <tampakrap> is there anything we can do about those warnings?
[22:11:32] <tampakrap> are there open bugs or smth?
[22:11:47] *** Joins: [Enrico] (~chiccoroc@gentoo/contributor/Enrico)
[22:11:59] <wired> what do you guys think?
[22:12:20] <hwoarang> well
[22:12:21] <hwoarang> we can
[22:12:48] <wired> maybe ping their maintainers for an ack
[22:12:48] <tampakrap> if there aren't open bugs about the remaining ones, we can open them and attach patches
[22:12:53] <hwoarang> we should send an email though just to let them know that we are gonna touch their ebuilds
[22:13:04] <wired> tampakrap: i don't think its worth opening bugs
[22:13:18] <tampakrap> if there is no response for a long time let's use hwoarang's QA hat and force him commit them :)
[22:13:35] <wired> devs should be using repoman, maybe wait for one more month for them to respond then start fixing them ourselves
[22:14:12] <wired> if anyone feels like doing that ofcourse :)
[22:14:35] <wired> ok, so summary: we can fix them ourselves if we notify the maintainers first
[22:14:44] <hwoarang> this is almost a 6-7 month issue
[22:14:49] <hwoarang> we should act instead of waiting
[22:14:51] <tampakrap> i insist, let's open bugs
[22:15:38] <wired> tampakrap: why not just fix em? we won't be changing the ebuild end result anyway...
[22:15:43] <pesa> anyway, i don't think there is any real hurry to port ebuilds to qt4-r2...
[22:16:07] <pesa> old eclass does not cause any problems afaik
[22:16:17] *** Joins: spatz (~spatz@gentoo/developer/spatz)
[22:16:17] <wired> pesa: no one is really watching the old one tho... any changes we do in -r2 stay there
[22:16:26] <hwoarang> the eqmake4 is different between these two eclasses
[22:16:28] <hwoarang> isnt it?
[22:16:32] <pesa> it is
[22:17:07] <pesa> the important thing is that new ebuilds or new versions switch to qt4-r2
[22:17:21] <hwoarang> we cant ensure that
[22:17:21] <pesa> and we have the repoman check for that
[22:17:32] <hwoarang> the repoman message is a warnign not a fatal error
[22:17:34] <wired> pesa: well its not fatal
[22:17:38] <hwoarang> so ppl can still ignore it
[22:17:45] <pesa> heh ok
[22:17:59] <wired> does anyone else feel we should open bugs for this?
[22:18:05] <pesa> ppl can even break the tree if they want to
[22:18:44] <tampakrap> a bug would be a nicer way to say that "look here is the patch commit it or i will"
[22:18:54] <pesa> i agree with tampakrap
[22:19:13] <tampakrap> touching others' ebuilds is evil imho
[22:19:16] <wired> its more paperwork for an internal ebuild patch
[22:19:28] <wired> i favor "ping the guy then commit"
[22:19:51] <pesa> that's fine too
[22:19:57] <wired> but i guess bugs would be nice for devs who don't respond any other way
[22:20:00] <hwoarang> tampakrap: i did fix some ebuilds in the past
[22:20:07] <hwoarang> they didnt even notice it
[22:20:09] <hwoarang> :)
[22:20:10] <wired> lol
[22:20:14] <pesa> :P
[22:20:15] <hwoarang> the bug can remain open forever
[22:20:25] <tampakrap> i don't say open bugs and wait
[22:20:32] <hwoarang> if you plan to open bugs then you should open a tracker ( if there is not one already )
[22:20:35] <tampakrap> i say open bug, ping, commit and mention bug #
[22:20:38] <tampakrap> for proof
[22:20:41] <pesa> yeah
[22:20:43] <wired> ah
[22:20:47] <tampakrap> i think there is
[22:20:50] <hwoarang> the commit message on gentoo-commits is a proof
[22:20:52] <wired> yeah i agree with that
[22:20:59] <wired> but if you can get in touch with the dev
[22:21:03] <wired> through irc
[22:21:07] <wired> the bug is really not necessary :)
[22:21:13] <tampakrap> ok guys
[22:21:16] <wired> great
[22:21:18] <wired> lets move on
[22:21:18] <tampakrap> we have 4 servers for bugzie
[22:21:18] <pesa> yes, definitely
[22:21:22] <tampakrap> make them look useful
[22:21:27] <pesa> lol
[22:21:28] <wired> lol
[22:21:33] <wired> 2. Qt 4.7.0
[22:21:40] <wired> we have _rc1 in edge
[22:21:43] <tampakrap> about it:
[22:21:49] <wired> a few of us are already using it, works fine
[22:21:55] <tampakrap> i tested kde 4.5.1, all my kde and qt apps
[22:21:58] <tampakrap> they work fine
[22:22:01] <wired> thanks tampakrap 
[22:22:08] <pesa> sweet
[22:22:11] <tampakrap> i didn't test 4.4.5 and i don't think i will in the near future
[22:22:20] <tampakrap> before i finish my exams at least
[22:22:25] <wired> there are some minor regressions here and there but nothing serious for the moment
[22:22:34] <wired> here's the question
[22:22:39] <pesa> well, is kde 4.5.1 entering the tree?
[22:22:44] <tampakrap> yes
[22:22:50] <pesa> ok so 4.4.5 isn't an issue
[22:22:58] <tampakrap> 4.4.5 is current stable
[22:23:04] <tampakrap> and 4.5.x won't get stable
[22:23:17] <pesa> yes, so?
[22:23:32] <tampakrap> i'd say not to add rc to tree yet, not before testing kde 4.4.5
[22:23:44] <hwoarang> we dont care for 4.4.5
[22:23:46] <tampakrap> when is the release btw?
[22:23:46] <pesa> mmm
[22:23:48] <wired> hwoarang asked flameeyes to test 4.7.0_rc1 in the tinderbox, flameeyes requested we move 4.7.0_rc1 to the tree (masked ofc). do we want to test with _rc1 or should we wait for final release, keep it masked for a couple of days and try with that?
[22:24:03] <hwoarang> 4.4.5 is stable. ppl are not supposed to mix branches
[22:24:04] <tampakrap> i'd vote for the second
[22:24:05] <wired> tampakrap: nokia doesn't give release dates
[22:24:07] <pesa> i'd say wait for 4.7.0 final
[22:24:12] <wired> i vote for final
[22:24:14] <wired> ;)
[22:24:24] <pesa> it shouldn't take long anyway
[22:24:30] <wired> tampakrap: nokia works like 3d realms "when it's done", only difference is they actually release
[22:24:33] <wired> ;p
[22:24:36] <pesa> 3-4 weeks imho
[22:24:44] <pesa> probably less
[22:25:09] <hwoarang> ok
[22:25:11] <wired> ok great
[22:25:13] <tampakrap> hwoarang: we should care about 4.4.5 since 4.5 won't get stable and qt-4.7 is
[22:25:35] <wired> so whoever adds final qt 4.7.0 to tree, remember to mask it
[22:25:56] <pesa> are you going to skip the whole 4.5.x series?
[22:25:56] * lu_zero finished testing 4.7.0_rc1 opengl and openvg both look broken on mesa...
[22:26:03] <tampakrap> yes
[22:26:11] <pesa> O_O
[22:26:20] <wired> 3. gles and openvg in Qt
[22:26:40] <hwoarang> wired: wait
[22:26:50] <wired> what?
[22:26:50] <hwoarang> tampakrap: no because 4.4.5 was never made to work with 4.7
[22:27:15] <hwoarang> 4.4.5 is stable, current stable qt is 4.6.2 and in the near future 4.6.3 will be
[22:27:19] <tampakrap> then don't stabilize it before 4.6 hits stable
[22:27:24] <pesa> yep
[22:27:25] <hwoarang> i dont think we will stabilize 4.7.0
[22:27:26] <wired> there's no way we're stabilizing 4.7.0
[22:27:27] <hwoarang> or 4.7.1
[22:27:30] <wired> i mean
[22:27:38] <wired> nokia already announced they're skipping issues for .1
[22:27:39] <hwoarang> tampakrap: again
[22:27:41] <wired> to make a release
[22:27:42] <wired> ;p
[22:27:45] <hwoarang> kde != qt
[22:27:52] <tampakrap> oh
[22:27:55] <tampakrap> i didn't know that
[22:28:00] <pesa> :)
[22:28:01] <wired> lol
[22:28:04] <wired> well we care about kde
[22:28:06] <tampakrap> let's move on please
[22:28:07] <hwoarang> you want to hold back the stabilization of Qt because kde doesnt work?
[22:28:27] <pesa> we can't break stable systems that badly :s
[22:28:28] <wired> hwoarang: we would imo
[22:28:38] <wired> kde is the major qt consumer
[22:28:41] <pesa> indeed
[22:28:41] <wired> lets be realistic :)
[22:28:45] <tampakrap> do you stabilize things that break systems?
[22:28:47] <hwoarang> the current stable kde
[22:29:00] <wired> if current stable kde doesn't work with a qt stable target
[22:29:08] <wired> that qt stable target will be delayed
[22:29:09] <hwoarang> wired: we wont stabilize 4.7.0
[22:29:15] <wired> i just said that
[22:29:17] <hwoarang> the delay is acceptable
[22:29:22] <hwoarang> it is two months from now
[22:29:25] <tampakrap> the discussion is useless, we are talking about the far future and we are in the middle of a meeting
[22:29:28] <tampakrap> please move on
[22:29:29] <wired> why are you repeating me? :P
[22:29:30] <pesa> btw i might be able to test 4.7 with kde 4.4.5 next week
[22:29:31] <hwoarang> i doubt that 4.4.5 will be on tree after 2 months
[22:29:39] <tampakrap> it will
[22:29:51] <wired> ok
[22:29:51] <tampakrap> for the next 6 months
[22:29:54] <wired> it doesn't matter
[22:29:57] <wired> we can talk about this later
[22:30:28] <wired> bottom line. we care about kde, we won't break stable, we'll discuss 4.7 stabilization when the time comes
[22:30:53] <wired> 3. gles and openvg in Qt
[22:30:57] <wired> lu_zero: ^^
[22:31:02] <lu_zero> hi
[22:31:44] <lu_zero> Qt apparently/should support various flavors of opengl and it's new 2d companion lib called openvg
[22:32:28] <lu_zero> I say apparently/should since I'm testing right now and the results aren't exactly nice (at least with the 4.7)
[22:32:55] <lu_zero> so I'd like to know your opinion about:
[22:33:04] <lu_zero> - support egl in qt
[22:33:04] <pesa> well, alternative graphicssystems are experimental
[22:33:10] <pesa> except raster
[22:33:26] <lu_zero> - support opengl es2 in qt
[22:33:33] <lu_zero> - support openvg in qt
[22:33:47] <lu_zero> egl is a requirement for es2 and openvg
[22:33:55] <hwoarang> fyi i added egl use flag back to 4.7 like 4.7.9999 ebuilds. It works now ( it didnt work back in _beta1 )
[22:34:05] <wired> opengl subsystem has worked for me in the past. it was ugly but worked - ie apps ran
[22:34:16] <lu_zero> hwoarang: it build nicely
[22:34:43] <lu_zero> wired: es2 seems to have a X visual mismatch we could ask upstream about it
[22:34:49] <pesa> wired: i had frequent crashes with the opengl one
[22:35:05] <wired> i didn't keep it long enough to experience crashes ;p
[22:35:36] <pesa> raster is the only one which is well supported
[22:35:44] <wired> lu_zero: what have you tested so far?
[22:35:57] <pesa> ./configure -help -> http://gentoo.pastebin.com/1jKXdGDL
[22:36:08] <lu_zero> qtconfig -graphicssystem {openvg opengl}
[22:36:17] <lu_zero> openvg <- no widget rendered
[22:36:43] <lu_zero> opengl (es2) <- X visual mismatch <- exits 
[22:36:44] <pesa> :(
[22:37:01] <pesa> have you tried opengl2?
[22:37:06] <lu_zero> still I need to check what happens with the other implementation I accessed
[22:37:14] <lu_zero> desktop you mean?
[22:37:21] <pesa> no
[22:37:28] <pesa> qtconfig -graphicssystem opengl2
[22:37:49] <wired> hmm -openvg is enabled by default now
[22:37:52] <lu_zero> let me see
[22:37:54] <wired> we should make a useflag for it
[22:38:01] <pesa> of course
[22:38:20] <lu_zero> wired: I made a split for it
[22:38:26] <wired> wow opengl2 works
[22:38:48] <wired> (barely) lags a bit on resize
[22:39:18] <pesa> opengl2 segfaults here :s
[22:39:46] <wired> oh wait
[22:40:11] <wired> i had a typo in the command and it failed to tell me
[22:40:19] <lu_zero> Unable to find an X11 visual which matches EGL config 3
[22:40:19] <lu_zero> Unable to find an X11 visual which matches EGL config 3
[22:40:19] <lu_zero> Segmentation fault
[22:40:26] <lu_zero> that is ^^
[22:40:30] <wired> window opened here, empty
[22:40:47] <pesa> well, it's a mess :(
[22:41:00] <wired> http://www.imagebin.org/112427
[22:41:01] <pesa> not usable i think
[22:41:27] <lu_zero> which mesa version are you using?
[22:41:39] <pesa> 7.8.2
[22:42:14] * wired same
[22:42:37] <lu_zero> uhm
[22:42:40] <wired> w/ 9999 libdrm and radeon driver
[22:43:47] * lu_zero uses 9999 mesa + libdrm and radeon
[22:43:59] <wired> yeah i wonder why i don't have 9999 mesa
[22:44:06] * wired keywords it
[22:44:07] <pesa> lol
[22:44:38] <pesa> so what do we need to decide?
[22:45:02] <wired> i guess we should add openvg use
[22:45:02] * lu_zero checked es1 <- wrong lib 
[22:45:11] <lu_zero> use or split?
[22:45:31] <wired> lu_zero: its a module like qt-opengl? 
[22:45:37] <lu_zero> yes
[22:45:56] <pesa> is there a QtOpenVG.so?
[22:46:07] <lu_zero> s/opengl/openvg/g s/OpenGL/OpenVG/ all over and you have it
[22:46:09] <lu_zero> yes
[22:46:24] <pesa> ok, split then
[22:46:27] <wired> +1
[22:46:45] <lu_zero> what about the gles?
[22:47:02] <lu_zero> useflags for es1 and es2 ?
[22:47:03] *** Joins: DrEeevil (~quassel@gentoo/developer/bonsaikitten)
[22:47:03] <pesa> for gles just pass -opengl es2
[22:47:26] <pesa> ah uhm
[22:47:38] <pesa> is gles1 relevant?
[22:47:56] <lu_zero> shouldn't
[22:47:57] *** Quits: bonsaikitten (~quassel@gentoo/developer/bonsaikitten) (Write error: Broken pipe)
[22:48:08] <lu_zero> might work better for certain devices
[22:49:02] <pesa> well, adding support at the ebuild level is trivial, but i'm afraid nobody will test it
[22:49:06] <wired> we could add opengl-es1 and opengl-es2 use flags (or shorter ones) with descriptive use descriptions
[22:50:07] *** Joins: mschiff_ (~mschiff@×××××××××××××××××××××.de)
[22:50:11] <lu_zero> pesa: testing on mesa is easy
[22:50:26] <lu_zero> testing on embedded system well I'll test on the efika implementation for sure
[22:51:01] <wired> lu_zero: any point in doing any of the above for 4.6?
[22:51:07] *** Quits: mschiff (~mschiff@×××××××××××××××××××××.de) (Ping timeout: 272 seconds)
[22:51:28] <pesa> btw, can you confirm that gles{1,2} and opengl are mutually exclusive?
[22:51:42] <pesa> i mean in qt
[22:52:03] <wired> well
[22:52:14] <wired> pesa: http://www.imagebin.org/112429
[22:52:38] <lu_zero> wired: I can test it as well not sure which is the status in 4.6 we should ask upstream
[22:52:48] <lu_zero> surely openvg behaves the very same way
[22:52:55] <pesa> yeah ok, but isn't there a way to enable both through some hacks?
[22:53:00] <lu_zero> hadn't tested opengl that much
[22:53:06] *** Parts: [Enrico] (~chiccoroc@gentoo/contributor/Enrico)
[22:53:14] <lu_zero> pesa: using the eselect approach
[22:54:06] <pesa> mm
[22:55:03] <pesa> eselect-qtgl? :)
[22:55:19] <wired> i recommend we do our testing work in qting-edge ( lu_zero you could push your split ebuild ) and someone could work on eselect
[22:55:54] <lu_zero> wired: do I have access to the tree?
[22:56:20] <wired> lu_zero: tampakrap will take care of that
[22:56:35] <hwoarang> lu_zero:  you need a gitorious account
[22:56:35] <wired> then the whole team can pitch in
[22:56:42] <wired> ah its gitorious forgot
[22:57:04] <wired> lu_zero: what hwoarang said
[22:57:14] <pesa> who is going to implement the eselect thing?
[22:57:29] <pesa> btw do we all agree to follow that approach?
[22:57:34] <tampakrap> that is easy
[22:57:46] <wired> pesa: it sounds like the best way
[22:58:05] <wired> if doable
[22:58:17] <pesa> dunno really
[22:58:23] <hwoarang> i dont know shit about eselect
[22:58:25] <wired> pesa: wanna look into it?
[22:58:29] <wired> ^_^
[22:58:43] <pesa> well, to be honest i'm not interested at all :P
[22:58:56] <lu_zero> hwoarang: I have one =)
[22:59:29] <lu_zero> I'd got to the useflag route and introduce first es2 and desktop as alternative
[22:59:31] <pesa> the simplest solution is having opengl and gles to exclude each other
[22:59:34] <wired> lu_zero: gimme your username
[22:59:38] <lu_zero> lu_zero
[22:59:49] <wired> ofcourse
[23:00:30] <wired> useflag approach is definately simpler
[23:00:34] <pesa> indeed
[23:01:02] <pesa> we can always add eselect support later
[23:01:04] <wired> i think 'opengl' should enable desktop, overridable by es1 and es2
[23:01:12] <pesa> +1
[23:01:29] * wired wishes we had eapi4
[23:01:58] <pesa> what happens with USE="-opengl gles"?
[23:02:17] <wired> no opengl, ewarn?
[23:03:34] <reavertm> eselect between opengles and opengl?
[23:03:47] <pesa> yep
[23:03:50] <wired> we already said thats an option but noone stepped up to implement it ;p
[23:03:54] <reavertm> you're insane
[23:03:57] <reavertm> (and wrong)
[23:04:11] <reavertm> those are not complementary - ES is subset of opengl
[23:04:16] <lu_zero> wired: I'd just add es2 and es1
[23:04:32] <lu_zero> USE=es2 emerge qt-opengl 
[23:04:36] <lu_zero> USE=es1 emerge qt-opengl 
[23:04:41] <lu_zero> USE="" emerge qt-opengl 
[23:04:43] <wired> ah
[23:04:45] <lu_zero> if you want
[23:04:48] <wired> so "" == desktop
[23:04:51] <lu_zero> yes
[23:04:53] <wired> great
[23:04:58] <wired> +1
[23:05:09] <lu_zero> right now we have it automagic
[23:05:10] <pesa> ah right
[23:05:19] <wired> i like it
[23:05:20] <pesa> sorry for my silly question
[23:05:35] <reavertm> how about install desktop (full opengl) always and es1/2 optional with use flags
[23:05:47] <wired> reavertm: thats what we just said :)
[23:05:56] <pesa> i though we had opengl in qt-gui's IUSE too
[23:06:02] <lu_zero> you have to pick one
[23:06:07] <reavertm> (unless you want to support gentoo on...symbian :P)
[23:06:14] <lu_zero> pesa: we have egl
[23:06:23] <lu_zero> that's yet another thing
[23:06:31] <hwoarang> pesa: if you add one you get circulars
[23:06:32] <hwoarang> :)
[23:06:37] <hwoarang> between qt-gui and qt-opengl
[23:06:47] <pesa> ok
[23:06:51] <hwoarang> you could do that and add qt-opengl on PDEPEND
[23:06:57] <hwoarang> pointless imho
[23:06:59] <lu_zero> so the deps would be something like es1? ( qt-foo[egl] )
[23:07:11] <pesa> lu_zero: yes
[23:07:21] <wired> ok
[23:07:25] <wired> lets wrap this up
[23:08:01] <wired> lu_zero will do all this (:p) in qting-edge -> es1 and es2 useflags, qt-openvg
[23:08:16] <pesa> and add egl useflag to qt-gui
[23:08:24] <hwoarang> already done
[23:08:25] <wired> i thought hwoarang did that
[23:08:50] <hwoarang> and on opengl
[23:09:10] <wired> team: should we ask lu_zero to join the team? ^_^ ;)
[23:09:20] *** Quits: pesa (~Pesa@××××××××××××××××××××××××××××××××××××××××××××××××.it) (Quit: Konversation terminated!)
[23:09:29] *** Joins: pesa (~Pesa@××××××××××××××××××××××××××××××××××××××××××××××××.it)
[23:09:29] <tampakrap> and kick who?
[23:09:53] <wired> why kick anyone, we're a happy family :D
[23:10:31] <lu_zero> wired: I can help but I'm not exactly a C++ guy ^^;
[23:10:37] <wired> and we are?
[23:10:43] <wired> :P
[23:10:52] <lu_zero> I hope =)
[23:10:55] <wired> heheh
[23:11:18] <wired> well, if you wanna join, you're welcome to :)
[23:11:30] <lu_zero> I'll help on this part for sure
[23:11:36] <wired> you already have access to qting-edge
[23:11:40] <wired> ^^ ;)
[23:11:45] <lu_zero> ok
[23:11:51] * lu_zero will start adding stuff
[23:11:54] <wired> great
[23:11:56] <lu_zero> any rule I should know?
[23:12:35] <wired> nothing special
[23:12:38] <hwoarang> no
[23:12:50] <wired> oh
[23:12:54] <wired> lu_zero: we don't use changelogs
[23:12:55] <wired> :)
[23:13:09] <hwoarang> git ftw
[23:13:17] <wired> but you'd figure it out yourself anyway
[23:13:27] <wired> lets move on
[23:13:46] <wired> 4. bugz
[23:13:59] <wired> anyone had any revelations on the qt-svg issue?
[23:13:59] <lu_zero> ok
[23:14:11] <pesa> no
[23:14:28] <wired> ok, just asking since noone closed it ;) I'll close it after the meeting
[23:14:39] <wired> bug #329533
[23:14:39] <pesa> yes please
[23:14:42] <willikins> wired: https://bugs.gentoo.org/329533 "x11-libs/qt-core-4.6.3 - qmake generates incorrect Makefile with CONFIG+=debug"; Gentoo Linux, Applications; NEW; egorov_egor@××.ru:qt@g.o
[23:15:21] <wired> pesa: you had your fun there :P
[23:16:22] <pesa> :)
[23:16:41] <wired> this bug is tough... if you look at it the gentoo way, he's wrong. if you look at it the app developer way, he's right
[23:16:55] <pesa> indeed
[23:17:40] <wired> how about the opposite of his patch
[23:17:49] <pesa> he proposed a solution (i'd call it hack), but it's too invasive and fragile for my taste
[23:18:00] <pesa> wired: ?
[23:18:21] <wired> pesa: QMAKE_DONT_IGNORE_PREDEFINED_CFLAGS
[23:18:33] <wired>             ^^^^
[23:19:06] <pesa> bah
[23:19:08] <hwoarang> no
[23:19:18] <pesa> it doesn't make much sense imho
[23:19:23] <wired> are you sure we are on the same page?
[23:19:42] <wired> we could leave the current state as is
[23:19:45] <lu_zero> uhm
[23:19:46] <lu_zero> but
[23:19:53] <hwoarang> if you want debug support just adjust the CFLAGS yourseklf
[23:19:53] <lu_zero> qmake.conf won't allow that?
[23:20:03] <wired> and allow people like him to override the behavior by setting QMAKE_DONT_IGNORE_PREDEFINED_CFLAGS=1
[23:21:18] <pesa> how are qt devs going to know about that var?
[23:21:54] <wired> meh
[23:22:05] <wired> ok, other idea
[23:22:05] <pesa> i still propose the same as comment #24
[23:22:36] <wired> ah
[23:22:55] <pesa> building with USE=debug but without debug symbols is odd anyway
[23:23:02] <wired> yes
[23:23:07] <wired> that looks ok to me
[23:23:47] <hwoarang> ok
[23:24:03] <wired> great
[23:24:21] <hwoarang> assigned to me and pessa. A patch for the eclass will appear shortly
[23:24:30] <wired> alright
[23:24:30] <pesa> :)
[23:24:31] <wired> thanks
[23:24:41] <wired> next bug 304971
[23:24:43] <willikins> wired: https://bugs.gentoo.org/304971 "qt-core stores machine-specific information in /usr/share/qt4/mkspecs"; Gentoo Linux, Library; ASSI; ohnobinki@××××××××××××××.net:qt@g.o
[23:25:13] <wired> pesa: did you test the #9 approach?
[23:26:03] <pesa> nope
[23:26:33] <wired> I think I'll give it a try
[23:26:41] <wired> unless someone has a better idea
[23:27:26] <wired> guess not
[23:27:31] <wired> bug 333391
[23:27:32] <willikins> wired: https://bugs.gentoo.org/333391 "Qt 4.6.3 is built without STL support"; Gentoo Linux, Ebuilds; NEW; xzekecomax@×××××.com:qt@g.o
[23:27:39] <pesa> ah yeah
[23:27:50] <pesa> anyone with gcc 4.5.x?
[23:27:59] <hwoarang> i do
[23:28:07] <hwoarang> *me
[23:28:07] <pesa> can you reproduce?
[23:28:08] <wired> me 2
[23:28:48] <hwoarang> any simple test case?
[23:28:59] <pesa> qt's ./configure output
[23:29:01] <pesa> i guess
[23:29:08] <hwoarang> ok hold on
[23:29:10] <pesa> btw the reported didn't provide build.log
[23:29:15] <pesa> reporter
[23:29:23] <wired> comawhite... ;p
[23:30:10] <tampakrap> he is in #-kde should i ping him?
[23:30:16] <pesa> i'm tempted to close as NEEDINFO :|
[23:30:26] <pesa> tampakrap: yes please
[23:30:33] <wired> 23:29:50 -!- #gentoo-meetings You're not channel operator
[23:30:35] <wired> @#$@#%@% :p
[23:31:08] <tampakrap> let's go on until he replies
[23:31:17] <wired> one sec
[23:31:21] <tampakrap> if he doesn't, well, dunno, close it :P
[23:31:53] <pesa> maybe he has broken STL headers
[23:31:58] <wired> configure says its enabled here
[23:32:20] <pesa> fine, i'd like to see his :|
[23:33:00] <wired> STL support ............ yes
[23:33:12] <wired> i don't see any weird warnings/errors
[23:33:19] <pesa> yeah indeed
[23:33:25] <hwoarang> same here
[23:33:36] <pesa> well let's move on
[23:33:38] <wired> ok needinfo
[23:33:40] <wired> :D
[23:33:51] <pesa> nothing to discuss here anyway
[23:33:54] <wired> bug #331071
[23:33:56] <willikins> wired: https://bugs.gentoo.org/331071 "[PATCH] x11-libs/qt-gui-4.6.3: Slow font rendering in Konsole on nvidia + related off-by-one error"; Gentoo Linux, Ebuilds; NEW; wbrana@×××××.com:qt@g.o
[23:35:01] <pesa> do you want to apply the patch?
[23:35:10] <hwoarang> afaik upstream rejected it
[23:35:17] <wired> ^^
[23:35:27] <pesa> indeed
[23:35:38] <pesa> i don't care about nvidia blob
[23:36:02] <pesa> but if the patch helps and doesn't cause any regressions...
[23:36:02] <wired> well
[23:36:14] <wired> one of the guys in the qt bug says he has intel
[23:36:40] <pesa> uhm
[23:37:10] <wired> another says ati
[23:37:43] <wired> how about adding the patch in qting-edge to give it some testing?
[23:38:08] <wired> i wouldn't mind adding it even if nokia rejected it *if* we are certain it doesn't break anything
[23:38:18] <pesa> ok
[23:39:11] <wired> alrighty
[23:39:38] <wired> pesa wanna add it or should I? :)
[23:40:26] <pesa> i'll leave it to you :)
[23:40:32] <wired> heh, ok
[23:40:33] <wired> 5. Status of Live ebuilds
[23:40:34] <hwoarang> are you sure tha this patch doesnt have side effects?
[23:40:40] <pesa> thanks
[23:40:50] <wired> hwoarang: we just said we'll test in overlay
[23:40:54] <wired> you're terrible at multitasking
[23:41:31] <wired> about live ebuilds, nothing to discuss really, just make sure you keep http://gitorious.org/gentoo-qt/pages/Qt4%20live%20ebuilds up to date
[23:41:56] <wired> lets not talk about this any longer, we are already near the 2h mark
[23:42:18] <wired> 6. Drop keywords from Qt-4.7
[23:42:29] <wired> Slow arches like ppc,ppc64,ia64,sparc prevent full stabilizations of Qt. Do we want to stop providing stable Qt for these arches?
[23:42:41] <wired> let me get your attention on this one
[23:42:42] <wired> !herd qt
[23:42:45] <willikins> (qt) abcd, ayoy, chiiph, hwoarang, spatz, tampakrap, wired
[23:42:46] <tampakrap> on behalf of kde, no problem
[23:43:00] <tampakrap> it will be easier for us too
[23:43:13] <tampakrap> but we (qt) should talk to them first
[23:43:57] <hwoarang> plz drop them
[23:44:05] <hwoarang> if they need their keywords let them rekeyword
[23:44:16] <hwoarang> or just keep them on ~
[23:44:16] <pesa> well, ppc is not that slow after all
[23:44:21] <wired> imo we could begin with the really slow ones
[23:44:24] <wired> ppc64, ia64
[23:44:38] <tampakrap> we said to stop stable, not to drop them completely
[23:44:42] <wired> notify them, if they don't reply / don't care, we stop caring as well
[23:44:59] <wired> yes we are talking about stable
[23:45:16] <pesa> alpha and sparc are slow too
[23:45:24] <wired> indeed
[23:45:30] <pesa> and have issues
[23:45:32] <wired> those 4 are probably the worst
[23:45:41] <pesa> not well supported upstream too
[23:45:54] <wired> I can write an email addressed to these 4
[23:46:03] <pesa> ppc64 has 4.6.2 stable actually
[23:46:11] <tampakrap> CC gentoo-desktop plz
[23:46:13] <hwoarang> this is quite new
[23:46:17] <hwoarang> the bug is there for months
[23:46:26] <wired> well ppc64 has a tradition for being uber slow
[23:46:33] <pesa> true
[23:47:24] <wired> so, we all agree on alpha, ia64, ppc64 and sparc as our first victims?
[23:47:59] <wired> if yes, I'll send an email to those arches (and -desktop) and ask them what they think
[23:48:39] <wired> if they promise to do better from now on we can spare them this time ;)
[23:49:26] <wired> this is a meeting you're supposed to say yes or no
[23:49:27] <wired> ;p
[23:49:42] * wired sighs
[23:49:42] <tampakrap> we already said yes
[23:49:59] <hwoarang> what can I say
[23:50:10] <tampakrap> you can say yes
[23:50:10] <wired> implied yes is not a yes
[23:50:16] <wired> pft
[23:50:21] <wired> okie dokie then
[23:50:31] <wired> 7. Stabilize Qt-4.6.3
[23:50:40] <tampakrap> yes on that one too
[23:50:58] <tampakrap> but we should take care of issue 6 first
[23:51:05] <pesa> yep
[23:51:10] <wired> this could follow 6 nicely
[23:51:17] <wired> ;p
[23:51:44] * alexxy came back :)
[23:51:48] <wired> lmao
[23:51:52] <pesa> :O
[23:52:03] <wired> ok we'll hold 7 until we have results on 6
[23:52:09] <wired> one more item
[23:52:10] <wired> extra
[23:52:22] <wired> 8. pesa
[23:52:27] <pesa> :O
[23:52:29] <pesa> wtf
[23:52:41] <wired> are you becoming a dev or what!?! :D
[23:52:51] <tampakrap> pesa: who is your mentor?
[23:52:56] <pesa> ah lol
[23:53:03] <pesa> it was supposed to be flameeyes
[23:53:09] <tampakrap> ok it's me now
[23:53:10] <wired> we can do it for him if you want
[23:53:14] <wired> heh
[23:53:16] <tampakrap> send me your quizes
[23:53:20] <tampakrap> now
[23:53:21] <wired> cc me
[23:53:37] <pesa> you are quite convincing :P
[23:53:46] <tampakrap> yes
[23:53:46] <hwoarang> how is 7. related to 6.?
[23:53:54] <wired> hwoarang: damn it man
[23:53:54] <wired> ;p
[23:54:40] <hwoarang> how does the 4.7.X keywords affect the 4.6.3 stabilization?
[23:55:31] <wired> um, we never talked about 4.7 keywords, we talked about stable 
[23:56:06] <hwoarang> 6. was Qt-4.7 keywords
[23:56:11] <hwoarang> 7. was 4.6.3 stabilization
[23:56:24] <wired> yeah well the title was wrong :P
[23:56:45] <wired> "Slow arches like ppc,ppc64,ia64,sparc prevent full stabilizations of Qt. Do we want to stop providing stable Qt for these arches?
[23:56:46] <hwoarang> ok then why should we hold 7 until we have results on 6?
[23:56:57] <wired> thats what we discussed
[23:56:58] <hwoarang> do we need 4.6.3 stabled on half of the arches?
[23:57:19] <wired> you want to completely drop keywords from these arches?
[23:57:24] <wired> i don't like that idea
[23:57:32] <pesa> uh? no
[23:57:37] <hwoarang> i said about 4.7
[23:57:43] <hwoarang> how is that related to 4.6.3
[23:57:57] <pesa> we can keep ~keywords
[23:58:07] <wired> ...
[23:58:09] <pesa> even on 4.7
[23:58:12] <wired> did you read anything
[23:58:19] <pesa> lol
[23:58:37] <hwoarang> ok then do what you think since i obviously dont understand
[23:58:52] * wired sighs
[23:58:53] <tampakrap> hwoarang is right
[23:59:10] <alexxy> tampakrap: what issue was related for /me? 
[23:59:14] <tampakrap> 4.6.3 can be stabilized in all archs that 4.5.3 is
[23:59:26] <hwoarang> 4.6.2 is stable on slow arches
[23:59:57] <wired> not in alpha ia64 and sparc
[00:00:05] <hwoarang> we said
[00:00:17] <hwoarang> that we will keep ~ on these arches on 4.7
[00:00:27] <hwoarang> and I ask. How is that related to 4.6.3
[00:00:46] <wired> we also said that we'll contact those arches about their interest in stabling Qt swiftly
[00:01:12] <wired> if they say they don't care we can skip them on 4.6.3 as well and make that stabilization faster
[00:01:39] <hwoarang> what did we said the last line?
[00:01:48] <hwoarang> cause I cant find it on backlog
[00:01:55] <hwoarang> *when
[00:02:55] <wired> http://dpaste.com/238049/
[00:03:10] <wired> if you guys wanna try stabling 4.6.3 anywhere i don't mind, but it'll take some time ;p
[00:04:02] <wired> so. pesa, don't forget the quizzes
[00:04:03] <hwoarang> wired: if we dont
[00:04:10] <hwoarang> we must keep 4.6.2 around
[00:04:12] <hwoarang> like forever
[00:04:32] <hwoarang> we already have 4.5.3 stable for everybody, 4.6.2 in half of them
[00:04:40] <hwoarang> and then 4.6.3 to even less arches
[00:04:49] <pesa> wired: :)
[00:05:01] <hwoarang> we should *try* to stabilize 4.6.3 and drop everything else
[00:05:27] <wired> hwoarang: ok. we'll talk about this again after i send out the email - then we'll know if the arches are planning to speed up
[00:05:41] <pesa> i answered the first set of quizzes more than one year ago
[00:05:47] <pesa> i'm reviewing them
[00:05:59] <pesa> there are some new questions :S
[00:06:06] <hwoarang> wired: well I will open the bug and CC them
[00:06:06] <wired> im sure you can handle them
[00:06:10] <tampakrap> the quiz has changed since then
[00:06:16] <hwoarang> i want <4.6.2 out of the tree
[00:06:16] <pesa> heh yes
[00:06:23] <hwoarang> <=
[00:07:05] <wired> hwoarang: let me mail them first, then open the bug :)
[00:07:16] <hwoarang> ok
[00:07:20] <wired> great
[00:07:34] <wired> 2 full hours, nice
[00:07:48] <wired> /meeting end
[00:07:52] <wired> thanks guys
[00:08:48] <wired> this was probably one of the longest Qt meetings ever
[00:08:48] <wired> ;p
[00:12:09] <pesa> thank you all
[00:13:33] <lu_zero> =)