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

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

[Ben de Groot (yngwin)]

yngwin      09/12/18 01:31:48

  Added:                qt-project-meeting-20091712.txt
  Log:
  Add meeting logs, meeting links in project page, tampakrap's new status

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

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

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