[20:55:21] meeting? [20:55:39] its time i think [20:55:50] hwoarang: yngwin ayoy lxnay reavertm spatz ssuominen tampakrap ping! [20:56:00] here [20:56:15] I see no problem in the current way :) [20:56:22] re: that mail [20:56:45] and i'm here [20:57:02] im here [20:57:06] here [20:57:14] ssuominen: well we did decide to ask the -dev community thus the mail [20:57:32] whassup [20:57:35] btw i am NOT logging this server, someone else please take care of it [20:58:07] i am [20:58:26] great [20:58:37] where's the lead? :P [20:58:47] slacking [20:59:10] playing eve online i guess [20:59:27] yngwin: ping pong [20:59:41] lol [20:59:44] -*- reavertm undecided whether to attend no-kde meeting [20:59:56] i still wonder how one whole month passed since our last meeting [20:59:57] ok, fasten your seatbelts [21:00:18] :) [21:00:19] anyone missing? [21:00:23] carlo :P [21:00:27] pessa [21:00:28] abcd [21:00:48] abcd won't join [21:00:50] they both announced [21:00:51] same for pesa [21:00:54] and carlo [21:00:54] yeah i know [21:00:57] as usual [21:00:59] :P [21:01:06] ok [21:01:15] 1: eclass status update [21:01:51] qt4-r2.eclass is in portage now [21:01:52] afaik only one ebuild is using it [21:01:58] we can start using it [21:02:15] of course [21:02:22] should we port the old ebuilds ? :S [21:02:22] I can create a list of ebuilds inheriting qt4 and we could work on them [21:02:33] btw, it would be great to have it under some version control [21:02:39] i suppose we should announce official policy that all new qt4 ebuilds must use this [21:02:48] ayoy: what? [21:02:52] ah the list [21:02:54] a checklist [21:02:58] ayoy: can be put as a wiki page on gitorious [21:03:00] that has history [21:03:06] or a txt on gitorious :) [21:03:08] and uses markdown syntax [21:03:24] I'd prefer git, but as you like [21:03:31] +1 for simple text file [21:03:33] we could have a script, someone run a cron to autoupdate in repo [21:03:53] oh i like that :P [21:03:59] indeed [21:04:04] i'll do it! soon, i promise :D [21:04:10] -*- hwoarang assigned [21:04:12] before next meeting :p [21:04:15] YES! [21:04:16] :D [21:04:17] wired: after you start an ML discussion :P [21:04:24] oh lord [21:04:24] ayoy: i wrote the email [21:04:29] one hour ago [21:04:30] oh, sorry :D [21:04:30] :D [21:04:32] ok, on topic [21:04:33] the mail is fine btw [21:04:42] should we add eapi-3 support now? [21:05:01] i dont quite understand that part [21:05:03] hey, excuse my ignorance [21:05:05] how exactly? [21:05:11] where can I look for any info on EAPI-3? [21:05:21] make it compatible with prefix, basically [21:05:40] http://archives.gentoo.org/gentoo-dev/msg_2a62689c71f95e4de5699a330b8b5524.xml for info [21:05:46] thanks a lot [21:05:53] yngwin: we might ask @prefix team to do that [21:06:00] patch the eclass and send the patches [21:06:07] yes, or abcd [21:06:08] good idea [21:06:24] we have 0 experience with prefix [21:06:30] I have minimal [21:06:34] ok, let's forward that to @prefix and abcd [21:06:37] i guess abcd can handle it as he did with the kde ebuilds [21:06:46] thats nice [21:07:01] the guide for qt4-r2 [21:07:05] I updated it a bit [21:07:11] it's on my devspace atm [21:07:18] can we put it on gitorius as well? [21:07:19] hwoarang: did you have time to take a look? [21:07:22] yes, i said i would look it over [21:07:28] ayoy: no not yet :S [21:07:47] jcan we put it in qting-edge/Documentation ? [21:07:48] maybe adding it to gitorious might be better [21:08:01] that would make colaboration easier [21:08:04] true [21:08:10] hwoarang: by gitorious you mean the wiki or git? [21:08:15] git [21:08:18] the pure xml file [21:08:18] okay [21:08:20] yeah [21:08:22] good for me [21:08:23] git++ [21:08:25] git preserves the markup [21:08:43] ok. anything else on point 1? [21:08:46] no [21:08:52] as i said i have an svn hook in my home server that checks out the content in a gorg installation [21:09:09] if you are interested... [21:09:12] 2. split vs. monolithic discussion [21:09:13] its svn dude, fix it! [21:09:19] ontopic plz [21:09:40] yngwin: i wrote the email today (\o/) [21:09:49] good :) [21:09:50] a few devs read it, so i'll send it [21:09:50] -*- hwoarang prepares the flaming gun [21:10:27] great, i'll hit send after the meeting [21:10:29] i think we should talk to zmedico and get his ideas, as at this point it is mostly a portage problem [21:10:35] however [21:10:38] i have to point out that [21:10:47] in latest 2.2 portage, output is MUCH better [21:11:01] but not on stable portage [21:11:01] i need to check that then [21:11:05] http://dev.gentoo.org/~wired/qt.fail [21:11:25] thats trying to upgrade only qt-core to 4.9999 [21:12:04] why print tuples? that's still confusing [21:12:14] --> scarabeus (~scarab@net-2-2.jaw.cz) has joined #gentoo-meetings [21:12:18] that's better, but we should check the stable portage's output [21:12:22] ok that is improving [21:12:29] its far better [21:12:30] i am running stable [21:12:36] but i need some time to reproduce it [21:12:45] i still think we need the new dep type [21:12:47] last point in my email [21:12:49] but it's hardmasked portage [21:13:03] yngwin: zmedico sometimes backport patches to ~arch portage [21:13:09] i agree with that point, wired [21:13:12] the email i'll send: http://dpaste.com/134673/ [21:13:14] what dep type? [21:13:31] maybe we should just discuss this between qt@ and portage@ ? [21:13:31] dd a new dependency in portage. this is my personal favorite. this dependency type would define what version packages should be *if* they are installed. this way qt-core would tell portage that all the other qt-modules must be =${PV} - if they're installed. making portage aware of this dependency would also allow for much better output. [21:13:36] +add [21:13:53] yngwin: that sounds reasonable. [21:14:17] ok, let's do that then [21:14:24] any objections? [21:14:40] moving on then [21:14:44] wait [21:14:50] yes? [21:15:02] you want the same email sent @ {portage,qt}@g.o? [21:15:13] yes [21:15:18] or you want me to remove qt monolithic parts? [21:15:31] and keep discussion around portage? [21:15:47] sounds a bit better for me to remove that part [21:15:48] keep discussion around current splits and portage [21:15:55] ok [21:15:57] see if we can improve that [21:16:02] will do [21:16:07] if not, we can discuss monolithic again [21:16:08] soon :D [21:16:18] let's move on then [21:16:24] you should add the the most problematic use case is a USE flag enabled for some qt modules but not all [21:16:30] but what you wrote is a good start [21:16:46] great, i'll just remove the monolithic option then [21:17:12] the most common problem nowadays is missing modules in p.keywords [21:17:17] I think that's the most common problem users have [21:17:21] aka mixed systems [21:17:21] spatz: the USE flag mess was generally solved after we removed <=4.5.2 [21:17:28] only late upgrades see that now [21:17:34] mixing has never been supported [21:17:42] true [21:17:46] useflags can still be a problem for first install on non-desktop profile [21:17:46] tell that to users [21:17:50] it will happen every time we mess with it [21:18:12] spatz: if we change defaults, yeah [21:18:25] I think you should at least note it [21:18:32] ok, can we move to point 3? [21:18:36] its a different issue, but ok [21:18:40] lets go [21:18:55] einfo overload: can we cut down on this more? [21:19:00] last time we talked about a link [21:19:18] wired autodepclean should help here and zmedico seemss to be convinced to implement it [21:19:22] i want to ask maintainers of apps to keep this in mind and see if we can cut down on einfo [21:19:23] do you guys want that? [21:19:47] i do [21:19:57] the huge einfo on qt modules? [21:20:08] yngwin: how are the apps affected by that? [21:20:11] you can explain more in a faq, keep einfo simple [21:20:20] -*- reavertm notes that nobody reads einfos [21:20:22] hwoarang: i mean if app ebuilds add their own einfo [21:20:27] btw, the link to plugins howto is not needed at all imho [21:20:30] ok [21:20:54] i agree with the einfo reducing [21:21:10] reavertm: thats because there is too much [21:21:22] thats why we try to get back to the essentials here [21:21:44] ok then [21:21:57] i think we're clear on this point [21:22:16] -*- reavertm thinks portage should have sth like 'suggested deps' as in debian [21:22:18] which leads to 4: documentation/faq [21:22:34] most pkg_poinst inst einfos could be dropped then [21:22:39] After upgrading Qt, apps and libraries using it may stop working. If that happens to you, you should recompile stuff that uses Qt. Visit for details. [21:22:51] let's write that faq, so we can refer to it in einfo and on irc/forums [21:22:51] wired: awesome! [21:23:07] wired: yes something like that [21:23:27] ok apart from the extended einfo stuff, what else should we put on faq [21:23:41] this is something we should discuss on ML I guess [21:23:43] stuff like the blocks ppl get [21:23:45] link would contain that script that re-emerges everything that uses Qt or something [21:23:47] just post ideas [21:23:58] ML discussion wont help [21:24:04] what useflags are commonly needed for desktop users [21:24:12] hwoarang: not a discussion, ideas [21:24:25] those things that come up frequently on irc/forums [21:24:26] hwoarang: we won't make up anything good right now [21:24:43] i'll start a page on gitorious [21:24:44] people are often enabling qt3support per package in package.use causing problems [21:24:50] (forums) [21:24:56] yeah [21:25:02] hmm [21:25:14] KDE should depend on qt-qt3support [21:25:25] it does [21:25:27] afaik [21:25:31] mhm [21:25:33] anyway, off topic [21:25:35] there shouldn't be an issue now that we have the default USE issue gone [21:25:55] reso;invalid "read portage output"? [21:26:00] those are details we can write as we go [21:26:23] ok [21:26:24] oh well [21:26:25] lets go [21:26:26] once we have a decent text, i can put it in guidexml [21:26:37] cool [21:26:48] 5: remaining qt3 packages [21:27:07] -*- wired gets his BFG out [21:27:21] we should review whats left in the tree [21:27:26] the list is pretty big [21:27:37] yes, we need to start moving on that [21:27:48] now that ssuominen has cleaned out most kde3 :) [21:28:04] ssuominen: don't lose your momentum, keep going with qt3! [21:28:05] heh [21:28:45] so please all, if you have some time, check for pkgs depending on qt3 and add bugs to the tracker [21:28:52] there are two options imho [21:28:55] --> Battousai (~bryan@maduin.southcape.org) has joined #gentoo-meetings [21:29:01] 1) if there is no Qt4 , remove the package in 30days [21:29:11] 2) if there is a Qt4 version, bump it [21:29:19] 30days time frame and that would be all [21:29:27] i can start working on this [21:29:51] i think that sounds reasonable [21:30:01] by masking packages that depend on Qt4 [21:30:05] *Qt3 [21:30:06] :p [21:30:11] heh [21:30:34] wouldn't it be nicer to users if the new version would be stabilized before the qt3 version was removed, if a qt4 version exists (and the qt3 version is stable)? [21:30:43] --> tjfontaine (tjfontaine@tjfontaine.chair.oftc.net) has joined #gentoo-meetings [21:30:43] I can pretty much tell out of memory all =kdelibs-3* from tinderbox's list, it will be all ready in early january, koffice just went stable on amd64 [21:30:45] that would be 3) [21:30:47] yes, absolutely [21:30:48] thats why i said 30days [21:30:48] -*- reavertm did that with kadu [21:30:52] enough time to stable packges [21:31:04] but if you mask them now users get angry [21:31:15] so? [21:31:16] what [21:31:30] wait a Qt4 version before we mask Qt3 version [21:31:35] ?? [21:31:46] well, maybe we should wait masking qt:3 for a little while yet [21:31:51] Is there any real rush on removing qt-3? For kdelibs there is several good reasons, like it's not building at all with new autoconf/open security bugs/etc. [21:32:02] yngwin: that's my point... [21:32:02] yes [21:32:05] it is ugly [21:32:07] if a qt4 version exists then bump it and bring it to the same status as the qt3 version before removing it, that's my suggestion [21:32:09] hwoarang: :D [21:32:27] spatz: i [21:32:29] yes [21:32:30] I think we should give the first half of 2010 time for qt-3 removal, at least. [21:32:36] but what if there is no Qt4 version [21:32:38] keep it in portage, it doesn't hurt [21:32:40] that'll give us time to bump stuff [21:32:40] masking is the only choice [21:32:41] ssuominen: it's unmaintained and unsupported, and who knows what secuity bugs there are [21:32:55] until we get the replacements we want, that is [21:33:03] give some warning before masking, wait a little for a newer version [21:33:07] it's all in my mail from 5 months ago [21:33:14] spatz: Qt4 is 2 years old [21:33:20] how long we should wait? [21:33:21] hwoarang: 4 [21:33:31] :) [21:33:33] well, I am counting from 4.4.2 :P [21:33:42] pff ;] [21:33:53] upstreams had plenty of time to port their packages [21:33:56] I know it's not a good argument; but gtk+:1.2 is also in tree, some games@ are using it, and they still work fine [21:34:01] now that kde is maturing more stuff will get ported [21:34:01] well, let's see if there are any big apps we would inconvenience [21:34:01] they wont do it in the following 3 months [21:34:15] lets move on! [21:34:44] i'll write up a policy and submit it to qt@ for approval before sending to dev ML, ok? [21:34:52] wonderful :) [21:34:56] +1 [21:34:57] ok [21:35:05] 6: open bugs [21:35:17] as you can see, i went through our list today [21:35:23] and -desktop plz, don't forget -desktop [21:35:28] http://bugs.gentoo.org/buglist.cgi?cmdtype=runnamed&namedcmd=qt [21:35:41] http://gitorious.org/gentoo-qt/pages/PriorityBugs are in my opnion the most important ones [21:36:09] if you want to add to that, please do [21:36:25] ok [21:36:25] the CC/CXX bug was closed today, wasn't it? [21:36:29] yes [21:36:31] yes it was [21:36:36] does somebody uses exceptions? [21:36:36] I was gonna remove it from the list ;) [21:36:40] any feedback on that? [21:36:42] do it [21:37:00] if it is really fixed [21:37:05] done [21:37:15] should be checked if it works with cross-distcc [21:37:20] works for me, no one reports failures from 2 months now [21:37:23] *for [21:37:30] ok [21:37:35] yngwin: I checked it for amd64/x86 [21:37:47] lets keep that shortlist up to date, so ppl will know where to start working [21:38:16] exceptions needs some discussion [21:38:22] also, try to fix or at least move forward a couple of bugs from that list [21:38:28] rb_libtorrent's tests failed for me too on amd64@ but I could still seed/and download torrents [21:38:34] do we or do we not want this [21:38:34] so i've stabled it [21:38:39] it is more that 3 months on qting-edge [21:38:49] if it works, we need to patch the eclass and move on [21:39:03] ssuominen: Qt unit tests failures might be unrelated when run as portage user [21:39:09] ssuominen: it [21:39:18] 's about access to X server most of the times [21:39:30] i dont want to get into specific bugs here now [21:39:32] I can take a look at this [21:39:37] yngwin: yup, sorry [21:39:41] ok [21:39:51] we can do that afterwards or in bugzilla [21:39:58] just keep it in mind in the next few weeks [21:40:12] (we're running out of time) [21:40:13] noted [21:40:16] 7? [21:40:20] yes [21:40:52] i was thinking a script like betelgeuse's rss feed but specific for qt herd would be helpful [21:41:04] what script [21:41:05] or something like gnome and X have now [21:41:09] :) [21:41:12] any link? [21:41:29] http://gentoo.petteriraty.eu/ [21:41:43] right [21:41:44] a script that checks keywords is easy, i can do that and generate a pretty colored html [21:42:05] yngwin: as I said in the mail, each one of us maintain his ebuilds [21:42:06] or something like http://dev.gentoo.org/~eva/gnome/gnome-2.28.0.html [21:42:14] why should the whole Qt herd bothered? [21:42:22] hwoarang: that's right, but it's just in case [21:42:40] because i dont care about stable and often forget [21:42:41] one of us can have 200 ebuilds on his mind one day [21:42:50] ok [21:42:57] wired: can you come up with a similar script? [21:42:58] we can create the script to keep track of qt stuff, however I don't think we should bother any further [21:43:05] yes, i will [21:43:10] thanks [21:43:10] together with the other script [21:43:13] =] [21:43:19] if we can automate it, and just have a page, then anyone can look and see right away what could be bumped [21:43:34] and file bugs in times of boredom :) [21:43:37] bumped? [21:43:39] yes [21:43:45] stabled [21:43:47] ah [21:43:53] better :P [21:44:03] stablereqs [21:44:04] 8? [21:44:07] yup [21:44:13] wired: can you extend it to include kde too plz? [21:44:19] lol [21:44:22] :D [21:44:24] rotfl [21:44:34] 8 [21:44:44] sure, I'll put the important stuff in changable vars [21:44:48] should be simple to adjust such a script for kde [21:45:01] I already did this once for kde3 [21:45:02] boring too :) [21:45:29] so no new arguments? [21:45:42] also, should we have someone responsible for chasing after lagging stablereqs? [21:46:07] concerning ChangeLogs, I like them, but don't care [21:46:13] just someone who goes through the list say once a month [21:46:19] WE ARE STILL ON 7 [21:46:27] sure [21:46:33] and do what? ping archs only? [21:46:52] more like, check if stablereqs need to be files [21:46:59] but yes, maybe also ping arches [21:47:08] filed* [21:47:11] count on me for that [21:47:19] ok [21:47:41] now 8 [21:47:51] changelogs in overlay [21:48:03] -*- wired still in favor of getting rid of them [21:48:06] you all still want them gone, because you are lazy? [21:48:15] we all know what everybody thinks, but is there something to add? [21:48:21] no bc they are useless [21:48:29] its not lazyness [21:48:44] its one less thing to worry about when you're masschanging/bumping stuff [21:48:50] heh [21:48:53] echangelog is so CVS :P [21:49:05] exactly [21:49:07] the one thing useful with it is when moving to tree [21:49:13] ok, well, if i'm the only one opposingit, i will no longer veto [21:49:29] thanks [21:49:46] just make sure then that all relevant info is in commit messages [21:49:56] great [21:50:07] sure [21:50:11] i dont want the either [21:50:12] who volunteers to run find & rm [21:50:18]