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

[Alex Alexander (wired)]

wired       10/02/20 00:28:31

  Added:                qt-project-meeting-20091217.txt
                        qt-project-meeting-20100121.txt
                        qt-project-meeting-20100219.txt
  Removed:              qt-project-meeting-20091712.txt
  Log:
  Added Jan and Feb 2010 meeting logs, fixed older log's filename.

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

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

Index: qt-project-meeting-20091217.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@×××××××××××.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@××××××××××××××××.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@×××××××××××××××××××××.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@××××××××××××××××××××××.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 -----------------------------



1.1                  xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100121.txt

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

Index: qt-project-meeting-20100121.txt
===================================================================
[21:01:43] <yngwin> Gentoo Qt Project meeting starting 
[21:03:49] * wired here
[21:03:50] <hwoarang> hi
[21:03:56] * wired setting up i5 :P
[21:03:58] *** Joins: tampakrap (~tuxicity@××××××××××××××××××××××××××.gr)
[21:03:59] <yngwin> ABCD: present?
[21:04:17] <ABCD> yngwin: so long as my network connection doesn't die on my
[21:04:22] <ABCD> s/my/me/
[21:04:23] <yngwin> ok
[21:04:41] <yngwin> <yngwin> herd qt
[21:04:41] <yngwin> <Willikins> (qt) abcd, ayoy, carlo, hwoarang, spatz, tampakrap, wired, yngwin
[21:04:45] <spatz> agenda: http://gitorious.org/gentoo-qt/pages/Meeting20100121
[21:04:46] * wired logging
[21:05:06] <yngwin> ayoy is absent as announced
[21:05:10] <yngwin> welcome tampakrap
[21:05:28] <spatz> so we're all set
[21:05:38] <yngwin> except the usual suspect
[21:05:53] *** Joins: ssuominen (ssuominen@×××.fi)
[21:05:56] <yngwin> ok, please be seated, let's get started
[21:06:00] <yngwin> 1. eclass status update
[21:06:05] <tampakrap> who is the usual suspect?
[21:06:16] <yngwin> carlo
[21:06:36] <tampakrap> ok let's remove him then
[21:07:14] <yngwin> yes, let's discuss that after the rest of the agenda
[21:07:40] <yngwin> anyone want to say anything about qt4-r2.eclass?
[21:07:58] <hwoarang> errr
[21:08:06] <hwoarang> about the EAPI3 thing
[21:08:09] <yngwin> we should be checking our ebuilds and move them over little by little
[21:08:15] <yngwin> yes hwoarang?
[21:08:27] <hwoarang> should we care already?
[21:08:29] <ABCD> it only needs a 2-character change to be EAPI-3 compatible - changing "2)" to "2|3)" in the initial case statement
[21:08:30] * spatz thought that's ABCD's turf
[21:08:37] <hwoarang> eapi3 just approved by councli
[21:09:00] <spatz> it's isn't the old eapi3 that you know, don't know if you're updated
[21:09:08] <yngwin> well, i think it would be nice to have eapi-3 compatibility
[21:09:13] <hwoarang> do i am not 
[21:09:17] <hwoarang> *no
[21:09:22] <yngwin> eapi-3 == prefix
[21:09:29] <hwoarang> xm
[21:09:29] <spatz> it's just prefix stuff + .xz file format
[21:09:35] <hwoarang> ok
[21:09:42] <spatz> the old stuff got bumped to eapi4
[21:09:51] <ABCD> hwoarang: eapi3-compatible is also prefix-compatible, so as a member of the prefix team, I care about it :)
[21:09:57] <yngwin> ABCD: are you sure that is all that is needed for qt4-r2 to be eapi-3 compatible?
[21:10:45] <ABCD> yngwin: yes
[21:10:48] <spatz> it uses EPREFIX
[21:10:51] <yngwin> ok, let's do that then
[21:11:03] <hwoarang> ok
[21:11:05] <yngwin> anything else on point 1?
[21:11:18] <yngwin> then 2. split ebuild problems
[21:11:22] <spatz> so 5 people are doing the same change now :)
[21:11:27] <yngwin> status of discussion with portage team about problems caused by split ebuilds
[21:11:40] <pesa_> ah wait please
[21:11:46] <pesa_> on point 1
[21:11:49] <yngwin> yes?
[21:12:00] <pesa_> please be careful when switching ebuilds to qt4-r2
[21:12:05] <yngwin> of course
[21:12:11] <pesa_> i saw a QA notice yesterday on qt-creator
[21:12:43] <pesa_> var/tmp/portage/dev-util/qt-creator-1.3.1/temp/environment: line 2575: qt4_src_prepare: command not found
[21:12:46] <pesa_> this one
[21:13:00] <hwoarang> i ll fix it
[21:13:11] <pesa_> great thanks
[21:13:23] <spatz> fixed qt4-r2
[21:13:44] <yngwin> ok great
[21:13:49] <ssuominen> I still think qt4-r2 should have inherited qt4 to gain the eqmake4 command so old ebuilds wouldn't have to be touched
[21:14:05] <hwoarang> ssuominen: we discussed this before
[21:14:11] <hwoarang> eqmake4 is not the same as qt4
[21:15:17] <ssuominen> Well I just find the exported functions annoying :)
[21:15:26] *** Joins: _pesa_ (~Pesa@××××××××××××××××××××××××××××××××××××××××××××××××.it)
[21:15:51] *** Quits: hwoarang (~hwoarang@××××××××××××××××××××××××××.gr) (Read error: No route to host)
[21:15:54] *** Joins: ABCD_ (~ABCD@×××××××××××××××××××××××××××××××××××××.net)
[21:15:56] <yngwin> well, we decided to move all ebuilds over to qt4-r2 eventually, so
[21:16:14] *** Joins: hwoarang (~hwoarang@××××××××××××××××××××××××××.gr)
[21:16:31] <yngwin> wired: point 2, did you ever start that discussion with portage team?
[21:16:36] <wired> i did
[21:16:38] <wired> they didn't
[21:16:44] <hwoarang> sorry. network issues
[21:16:44] <yngwin> ah i c
[21:16:57] <wired> i sent that email about a month ago
[21:16:59] <wired> no replies
[21:17:10] <_pesa_> :(
[21:17:11] *** ABCD is now known as Guest80
[21:17:11] *** ABCD_ is now known as ABCD
[21:17:39] <yngwin> ok, i'll see if i can get some answer out of them
[21:17:40] * ABCD is annoyed at his network connection
[21:18:15] <yngwin> anything else about point 2?
[21:19:11] <yngwin> 3. einfo overload
[21:19:14] *** Quits: Guest80 (~ABCD@×××××××××××××××××××××××××××××××××××××.net) (Read error: Connection reset by peer)
[21:19:29] <yngwin> > once the faq is written, we will simplify the qt-core einfo even more.
[21:20:28] <yngwin> ok, i still need to do the faq, so is to be done later
[21:20:29] *** Quits: hwoarang (~hwoarang@××××××××××××××××××××××××××.gr) (Read error: Connection reset by peer)
[21:20:54] <spatz> you can start small and we'll all chip in
[21:20:57] <yngwin> but Qt is now guaranteeing binary compatibility, so i think we will see less of those issues
[21:21:03] <spatz> on gitorious it's easy
[21:21:04] *** Joins: hwoarang (~hwoarang@××××××××××××××××××××××××××.gr)
[21:21:11] <hwoarang> meh
[21:21:18] <yngwin> spatz: i tried the other day, but i couldnt make a new page
[21:21:36] <yngwin> i'll try again after the meeting
[21:21:37] *** Quits: pesa_ (~Pesa@×××××××××××××××××××××××××××××××××××××××××××××××.it) (Ping timeout: 480 seconds)
[21:21:49] <yngwin> otherwise i'll just do it in git
[21:22:27] <yngwin> ah, i was looking at the wrong page. 3 = documentation
[21:23:06] <yngwin> so yes, if i cant (again) make a new page in the gitorious wiki, i'll just put it under /Documentation/ in the overlay
[21:23:25] <yngwin> anything else on this point?
[21:23:47] <hwoarang> i guess not
[21:23:57] <yngwin> 4. remaining qt3 ebuilds
[21:24:07] <yngwin> https://bugs.gentoo.org/283429
[21:24:25] <yngwin> we are making progress, with much thanks to ssuominen as well
[21:24:41] <hwoarang> indeed
[21:24:47] <hwoarang> our work is pretty much done
[21:25:01] <hwoarang> we are either waiting for slacking maintainers or slacking arch members
[21:25:01] <hwoarang> :P
[21:25:15] <yngwin> i am still going through http://tinderbox.dev.gentoo.org/misc/rindex/x11-libs/qt and finding packages that have not been added as blockers to our tracker
[21:27:05] <yngwin> but indeed the biggest issue now is to get those packages stable that still need to be marked stable
[21:27:14] <yngwin> most importantly scribus and mythtv
[21:27:22] <hwoarang> yes
[21:27:30] <hwoarang> should we repoke them?
[21:27:41] <yngwin> i just asked cardoe today about mythtv
[21:27:49] <yngwin> he is waiting for deps to be marked stable
[21:28:06] <yngwin> i asked him to add those as blockers to 299222
[21:28:12] <yngwin> but maybe we could help him
[21:29:23] <yngwin> what are your ideas about how to speed up this process? how can we help arches to get there in time?
[21:29:30] <hwoarang> errr
[21:29:41] <hwoarang> arches are fine
[21:29:43] <hwoarang> sparc isnt
[21:29:58] <hwoarang> i doubt there are many open bugs for amd64 or x86
[21:30:10] <hwoarang> i am trying to get things done for amd64 at least
[21:30:34] <yngwin> someone should make a shortlist of packages where we are waiting for a stabilization
[21:30:49] <hwoarang> ok I will 
[21:31:36] <yngwin> i suggest we will poke arches once a week for the remaining 4 weeks about these bugs
[21:31:38] <tampakrap> i'll help
[21:32:02] *** _pesa_ is now known as pesa_
[21:32:16] <hwoarang> ok then
[21:32:58] <spatz> 5?
[21:33:04] <yngwin> are there any other packages that need special attention?
[21:33:29] <hwoarang> let me see
[21:34:14] <hwoarang> no
[21:34:31] <pesa_> the removal of qt3 USE flag from djvu was reverted...why?
[21:34:46] <yngwin> because the maintainer is stubborn
[21:34:49] *** Quits: ABCD (~ABCD@×××××××××××××××××××××××××××××××××××××.net) (Read error: Connection reset by peer)
[21:35:11] <pesa_> what is he waiting for?!
[21:35:17] <pesa_> :|
[21:35:49] <spatz> stubborn is one way to describe pva :p
[21:36:43] *** Joins: ABCD (~ABCD@×××××××××××××××××××××××××××××××××××××.net)
[21:36:44] <yngwin> he'll just have to put up with it when we mask qt:3
[21:36:57] <ssuominen> yngwin: old qtwvdialer can be dropped btw
[21:36:59] <spatz> he didn't comment on the bug, why did he revert it?
[21:37:02] <yngwin> i cant be bothered to argue with him
[21:37:17] <yngwin> because the qt4 version does not have an nsplugin
[21:37:30] <spatz> ah, I see in the ChangeLog
[21:37:32] <spatz> meh
[21:37:39] <ssuominen> or anyone else (i can't commit the change now)
[21:39:42] <yngwin> ok, any other remark wrt qt3?
[21:40:07] <hwoarang> no :)
[21:40:10] <ssuominen> nothing general
[21:40:11] <yngwin> ah about dropping qt3 useflags
[21:40:23] <yngwin> there are several bugs open
[21:40:26] <ssuominen> hwoarang: but you should search bugzie for "qucs", the snapshot is... bad
[21:40:41] <yngwin> i already went in and did some ninja edits (as in djvu)
[21:41:13] <yngwin> if maintainers dont act on the remaining bugs, we should step in, at some point
[21:41:27] <pesa_> yngwin: may i help by attaching patches in bugzilla for those ones (removing qt3 support)?
[21:41:38] <pesa_> since i can't commit :P
[21:41:40] <yngwin> yes please
[21:42:03] <spatz> not only do you may, but you also should :)
[21:42:15] <spatz> (not sure if that was english)
[21:42:26] <yngwin> :)
[21:42:30] <pesa_> spatz: :D
[21:42:35] <hwoarang> ssuominen: after all it is a snapshot
[21:42:45] <hwoarang> but indeed they don't seem alive
[21:42:54] <tampakrap> why pesa_ can't commit and i can? who made those rules?
[21:43:07] <yngwin> coz you're a dev
[21:43:10] <pesa_> heh
[21:43:39] <pesa_> i don't like doing quizzes ;)
[21:43:48] <yngwin> just get it over with
[21:43:50] * ABCD is very annoyed at his connection to the internet (or lack thereof, as the case may be)
[21:43:51] <spatz> long term investment :)
[21:44:07] <pesa_> indeed, i should definitely find some time 
[21:44:24] <yngwin> i know how you feel, it took me 9 months as well
[21:44:32] <yngwin> but look at me now :p
[21:44:50] <yngwin> ok, let's move on
[21:45:06] <yngwin> 5. open bugs
[21:45:06] <yngwin>     * any long-standing bugs that need fixing?
[21:45:40] <yngwin> i think http://gitorious.org/gentoo-qt/pages/PriorityBugs needs updating
[21:45:46] <hwoarang> we have some
[21:45:48] <spatz> you mean he'll become dutch? that's dangerous
[21:45:56] <yngwin> 239441 qt-webkit hangs on hppa, needs to be taken upstream
[21:46:01] <yngwin> anyone volunteering?
[21:46:13] <pesa_> spatz: lol
[21:46:24] <hwoarang> yngwin: well I can
[21:46:28] <yngwin> tnx
[21:46:34] <hwoarang> also the exceptions bug is still open
[21:46:42] <yngwin> 240185 qt exceptions <- i think we got an answer there
[21:46:43] <hwoarang> I got an official answer from upstream but we stack there
[21:46:47] <hwoarang> yes
[21:47:06] <yngwin> so can we solve this one?
[21:47:13] <pesa_> i think so
[21:47:44] <yngwin> who?
[21:47:56] <hwoarang> who is willing to ?at least gimme a patch since i am totally lost on this bug
[21:48:23] <pesa_> we just have to always enable exceptions, right?
[21:48:31] <hwoarang> yes
[21:48:45] <pesa_> in qt4-build.eclass then
[21:48:45] <wired> on all modules?
[21:48:47] <spatz> just remove the -no-exceptions flag, no?
[21:48:58] <pesa_> wired: yep
[21:49:02] <wired> ok i'll fix it
[21:49:07] <yngwin> great
[21:49:19] <yngwin> 251290 qt-sql/postgresql failure
[21:49:32] <hwoarang> wired: fix the eclas on overlay so we can test the live ebuilds first
[21:49:38] <spatz> just remove lines 414-434...
[21:50:08] <yngwin> 251290 is resolved
[21:50:25] <yngwin> 264631 goldendict: has gcc44.patch, live ebuild to be reviewed and added to overlay
[21:50:31] <yngwin> anyone?
[21:50:32] <hwoarang> i will take this
[21:50:34] *** Quits: ssuominen (ssuominen@×××.fi) (Quit: laters)
[21:50:37] <yngwin> great
[21:51:11] <yngwin> 283148 is resolved
[21:51:20] <yngwin> 292337 does qt-webkit require dbus or not? we need someone on a system without dbus to test this!
[21:51:27] <yngwin> wired was gonna do this
[21:51:36] <wired> s/was/is
[21:51:41] <yngwin> yes
[21:51:42] <wired> gimme a break im building the i5 now :P
[21:51:44] <hwoarang> tampakrap: ->http://bugs.gentoo.org/show_bug.cgi?id=296624
[21:51:52] <yngwin> 297299 Qt 4.6.0 stabilization tracker, wait for 4.6.1 release
[21:51:56] <yngwin> we have 4.6.1 now
[21:52:04] *** Joins: j0hu (~quassel@××××××××××××××××××××××××.de)
[21:52:05] <yngwin> so we need to crack the blocker bugs
[21:52:06] <spatz> when should we remove 4.6.0, btw?
[21:52:18] <yngwin> no rush
[21:52:22] <hwoarang> not yet
[21:52:32] <yngwin> let's say in a week or 2
[21:52:32] <wired> when the next sec vun hits :P
[21:52:40] <hwoarang> any ideas -> http://bugs.gentoo.org/show_bug.cgi?id=300594
[21:52:45] <tampakrap> bug 296624 is mine, you can remove qt team from there if you want but it will take some time to get fixed
[21:53:10] <hwoarang> ok
[21:53:13] <yngwin> hwoarang: you want to make that a priority?
[21:53:21] <hwoarang> the QMAKESPEC bug?
[21:53:46] <yngwin> yes
[21:54:01] <hwoarang> i might want to make a playground branch on qting-edge to test it
[21:54:05] <hwoarang> seems valid to me anyway
[21:54:08] <pesa_> the QMAKESPEC bug needs investigation imho
[21:54:11] <yngwin> ok
[21:54:13] <hwoarang> yes
[21:54:15] <pesa_> it's not easy
[21:54:24] <hwoarang> yngwin: please add it to priority list
[21:54:36] <yngwin> you can do that too ;)
[21:54:53] <pesa_> other packages may break if we add the -64 suffix
[21:55:15] <hwoarang> i thought that linux-g++ is a symlink
[21:55:31] <hwoarang> but anyway, i need some time with it
[21:55:43] <pesa_> it is, if i remember correctly
[21:55:45] <yngwin> ok, any other bugs need attention?
[21:56:07] <hwoarang> no
[21:56:11] <yngwin> ok
[21:56:14] <yngwin> 6. #gentoo-qt revisited
[21:56:40] <hwoarang> the one on OFTC or Freenode
[21:56:42] <hwoarang> ?
[21:56:52] <spatz> the same network as the rest of gentoo, I assume
[21:57:02] <yngwin> especially in the light of the recent wave of fail from failnode, i want to propose to make #gentoo-qt on oftc our official channel
[21:57:21] <hwoarang> this way you force users to use two networks
[21:57:42] <hwoarang> i think they wont follow us and poke us on -kde whenever needed
[21:57:47] <ABCD> I thought we were waiting to see if ircd-seven fixes issues with freenode before abandoning them
[21:58:13] <hwoarang> I propose to stay on -qt on Freenode until they move to the new servers
[21:58:14] <tampakrap> i thought that too
[21:58:23] <yngwin> i'm expecting that the switch will lead to more fail, at least in the beginning
[21:58:26] <hwoarang> just give them a final chance
[21:58:49] <wired> im in favor of staying to freenode until gentoo decides to leave
[21:59:05] <spatz> we shouldn't be different than the rest of gentoo
[21:59:10] <wired> or irc seven succeeds
[21:59:10] <yngwin> ok
[21:59:11] <wired> :)
[21:59:45] <wired> most issues are coming from spamming and attacks
[21:59:46] <yngwin> but we'll have the oftc channel for backup when failnode is having troubles again
[21:59:57] <wired> and irc seven looks like a good upgrade
[21:59:59] <spatz> but why have a separate channel? #-kde isn't really crowded
[22:00:35] <hwoarang> -qt doesnt need to be crowded as well
[22:00:36] <yngwin> not really. usually
[22:00:53] <hwoarang> we used to have qt specific discussions more and more often
[22:00:54] <hwoarang> :)
[22:00:55] <wired> well i think that being in -qt doesn't hurt
[22:00:55] <hwoarang> *use
[22:01:04] <wired> we do use it for some qt specific stuff tho
[22:01:11] <yngwin> exactly
[22:01:15] <wired> and occasionally people do drop by
[22:01:24] <wired> its rare, but they do :)
[22:01:26] <hwoarang> they just don't know it exist
[22:01:27] <yngwin> we had some inter-dev chats about 4.6.1 the other day
[22:02:17] <yngwin> personally i like having the extra channel just for qt
[22:02:39] <hwoarang> ok
[22:02:52] <spatz> the question is whether to make it official or not (get Willikins in there, listing it on the site, etc.)
[22:03:08] <spatz> we can hang out there, no need for meeting to do that :)
[22:03:24] <yngwin> yes
[22:03:46] <yngwin> so what do you guys think about making it official?
[22:04:03] <spatz> I think we're better off with people coming to #-kde for questions, there are more people and a bigger chance for them to get answers
[22:04:36] <wired> i say we hold this one off till the next meeting
[22:04:42] <yngwin> ok
[22:04:53] <tampakrap> we can make it official but not leave from #-kde (talking to qt-only folks)
[22:04:57] <yngwin> let's just have it as a hang-out for qt devs for now
[22:05:02] <hwoarang> qt is a separate project
[22:05:06] <spatz> great
[22:05:09] <hwoarang> so it is good to have its own channel
[22:05:11] <hwoarang> anyway :)
[22:05:13] <spatz> not every project as a separate channel
[22:05:14] <ABCD> do we want to get Willikins in there anyway?
[22:05:15] <yngwin> we will discuss it again next time
[22:05:25] <spatz> getting willikins is nice, yes
[22:05:31] <yngwin> yes indeed
[22:05:33] <spatz> we need to talk to robbat for that?
[22:05:37] <yngwin> yes
[22:05:54] <yngwin> ok last point on agendA
[22:05:58] <yngwin> 7. make raster on by default in live ebuilds
[22:06:07] <yngwin> i say yes
[22:06:15] <spatz> me too
[22:06:26] <wired> i haven't tested it lately so i cant say
[22:06:27] <spatz> just tested it on another with 4.6.1, it's awesome
[22:06:37] <yngwin> hwoarang?
[22:06:48] <wired> from my last tests i'd say no, but its been some time, so whatever you people say :)
[22:07:03] <tampakrap> can we also hold this off until next meeting? i need to test it too
[22:07:13] <hwoarang> my only objection is that some ppl ( as I do ) use qt live for development. I want the latest source available but no extra shiny stuff
[22:07:24] <hwoarang> from this point of view, I say no
[22:07:38] <yngwin> ok, let's leave it for now and discuss it again next time
[22:07:52] <yngwin> anything else?
[22:08:12] <tampakrap> members?
[22:08:18] <hwoarang> ?
[22:08:28] <yngwin> you mean the carlo case
[22:08:31] <spatz> so I'll ask robbat2 on #-dev for Willikins
[22:08:52] <tampakrap> yes
[22:08:54] <hwoarang> yngwin: the carlo case is more than a year old
[22:08:56] <hwoarang> :)
[22:09:08] <hwoarang> no harm to drop him. I bet he doesnt remember he is on Qt anyway :P
[22:09:13] <yngwin> anyone opposed to removing him from the project/herd ?
[22:09:57] <hwoarang> thats a "good to go" i guess
[22:10:14] <yngwin> ok
[22:10:14] <spatz> isn't that rude?
[22:10:17] <pesa_> i guess you tried to contact him and he hasn't answered...
[22:10:40] <hwoarang> spatz: rude?
[22:10:54] <spatz> forcing him out like that
[22:10:54] <yngwin> he has never answered my requests for being at the meeting
[22:10:57] <hwoarang> how come. he is not active for more than a year
[22:11:09] <spatz> oh, didn't realize it was that long
[22:11:16] <yngwin> all devs are required to be at the meeting or let us know they can't make it
[22:12:00] <yngwin> he has never been on one ever since i became member of qt herd
[22:12:23] <pesa_> yes, you're right
[22:12:27] <spatz> ok, so off he goes
[22:12:44] <yngwin> he can always appeal, and we'll reinstate him if he shows up
[22:13:15] <yngwin> ok, anything else before we close?
[22:13:39] <hwoarang> nop
[22:13:51] <tampakrap> can we remove hwoarang too?
[22:14:10] <hwoarang> not yet
[22:14:30] <yngwin> when he's as inactive and non-responsive as carlo, yes
[22:15:03] <yngwin> ok, thank you all
[22:15:06] <yngwin> =============================



1.1                  xml/htdocs/proj/en/desktop/qt/logs/qt-project-meeting-20100219.txt

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

Index: qt-project-meeting-20100219.txt
===================================================================
[20:59:26] <ayoy> hai
[21:01:58] <ABCD> is it that time again?
[21:02:27] <ayoy> it seems so
[21:03:10] *** Joins: spatz (~spatz@gentoo/developer/spatz)
[21:04:04] <spatz> qt meeting :D
[21:04:24] <ayoy> yeah, let's meet ;)
[21:04:33] *** Joins: yngwin (~yngwin@gentoo/developer/yngwin)
[21:04:41] *** Joins: jmrk_ (~jmrk@×××××××××××××××××××××××××××××××××××.net)
[21:04:54] <spatz> so who's here?
[21:05:07] * ayoy is here
[21:05:11] * ABCD is here
[21:05:31] * yngwin 
[21:06:08] <spatz> so yngwin and hwoarang too
[21:06:11] * reavertm just watching men at work
[21:06:20] <spatz> where's wired and tampakrap?
[21:06:23] <hwoarang> im here
[21:06:25] <yngwin> !herd qt
[21:06:27] <willikins> (qt) abcd, ayoy, hwoarang, spatz, tampakrap, wired, yngwin
[21:06:30] *** Joins: far_jump (~wizard@××××××××××××××××××××××××××××××××××××××.net)
[21:06:43] <yngwin> tampakrap is absent as announced
[21:07:08] <yngwin> so just wired and pesa 
[21:07:16] <spatz> ah, pesa, right
[21:07:32] *** Joins: Vtester (~loukas@×××××××××××××××××××××××.gr)
[21:07:34] <yngwin> agenda is at http://gitorious.org/gentoo-qt/pages/Meeting20100218
[21:08:31] *** scarabeus sets mode: +o yngwin
[21:08:38] <yngwin> ok, others will show up later i hope
[21:08:39] <hwoarang> sweet
[21:08:46] <yngwin> let's get started
[21:09:01] *** Quits: Vtester (~loukas@×××××××××××××××××××××××.gr) (Client Quit)
[21:09:02] <wired> oioi
[21:09:09] <wired> when did it get to 9pm
[21:09:12] <wired> stupid time :P
[21:09:14] *** yngwin changes topic to 'Gentoo Qt team meeting now |'
[21:09:16] <spatz> date -u
[21:09:16] <wired> im here :)
[21:09:27] *** yngwin changes topic to 'Gentoo Qt team meeting now | agenda: http://gitorious.org/gentoo-qt/pages/Meeting20100218'
[21:09:35] *** Joins: Vtester (~loukas@×××××××××××××××××××××××.gr)
[21:09:43] <hwoarang> nice
[21:09:45] <yngwin> wired: you logging?
[21:09:48] <wired> yeap
[21:09:58] <yngwin> good, let's get started
[21:10:01] <yngwin> 1. raster on by default?
[21:10:11] <wired> i hear kde is still a bit glitchy
[21:10:14] <wired> w/ raster
[21:10:25] <yngwin> works fine here, but reavertm reported glitches
[21:10:28] <spatz> is this about turning it on by default in the tree or the overlay?
[21:10:30] <ABCD> I haven't tried it in a while
[21:10:35] <yngwin> spatz: tree
[21:10:49] <reavertm> not glitches, crashes
[21:10:51] <hwoarang> I would say to wait for 4.7
[21:10:57] <reavertm> but quite infrequent
[21:11:08] <wired> i haven't tested it so i can't have a personal preference, but after talking with reavertm, maybe 4.7 is a better target
[21:11:10] <yngwin> ok, i agree with hwoarang
[21:11:12] <spatz> works great on three machines I've checked, but they're all nvidia so I don't know if it's representative
[21:11:15] <ayoy> still it seems like we should wait
[21:11:28] *** Quits: Vtester (~loukas@×××××××××××××××××××××××.gr) (Read error: Connection reset by peer)
[21:11:31] <spatz> maybe turn it on by default for all the overlay ebuilds
[21:11:37] <yngwin> seems we agree, let's wait and re-evaluate when 4.7 is released
[21:11:49] <wired> breaking the overlay would be interesting
[21:11:50] <hwoarang> is there warning still present on live ebuilds?
[21:11:50] <wired> :p
[21:11:55] <reavertm> you know, kde guys tend to abuse every api they put their hands on, so...
[21:12:01] <hwoarang> i dont mind playing around with live ebuilds
[21:12:11] <yngwin> there should be no warning about raster, just useflag description
[21:12:21] <hwoarang> as long as we use a warning message to let users know about this 
[21:12:38] <yngwin> in live ebuilds? we could do that
[21:12:48] <hwoarang> if we agree to enable that use flag by default, i would like to use a way to inform the users
[21:12:56] <hwoarang> otherwise they might not notice it
[21:12:56] *** Joins: ssuominen (~ssuominen@gentoo/developer/ssuominen)
[21:13:04] <wired> oh they'll notice
[21:13:09] <hwoarang> i wouldnt
[21:13:16] <hwoarang> since i blindly build the live packages every day
[21:13:31] <wired> you wouldn't notice a sudden 12ebuild USE change?...
[21:13:33] <yngwin> yes, i agree we should inform them, also because we want feedback
[21:13:43] <hwoarang> ^
[21:13:54] <spatz> only qt-gui would change
[21:14:03] <hwoarang> whatever
[21:14:03] <hwoarang> :)
[21:14:09] <wired> spatz: right, i was thinking exceptions-style :P
[21:14:17] <yngwin> maybe an einfo "Raster is turned on by default in live ebuilds, please let us know if you have any problems"
[21:14:18] *** Joins: Vtester (~loukas@×××××××××××××××××××××××.gr)
[21:14:23] <hwoarang> sure !
[21:14:28] <wired> yngwin: sounds good
[21:14:32] <yngwin> ok
[21:14:55] <yngwin> i'm planning to start using live trunk now until we have 4.7 pre-release
[21:15:03] <hwoarang> scary!
[21:15:11] <ABCD> yngwin: I would suggest an elog instead of an einfo :)
[21:15:12] <wired> its been a while since i last used a trunk version
[21:15:14] <yngwin> 4.7 went into feature freeze today
[21:15:22] <yngwin> ABCD: yes, that's better
[21:15:24] <wired> but i now have chroots so i can do that toot :)
[21:15:25] <wired> too*
[21:15:40] <hwoarang> we should redistribute the live packages again at some point
[21:15:48] <hwoarang> i doubt that all of them get tested
[21:16:07] <yngwin> hmm, how would you redistribute em?
[21:16:10] <wired> they probably aren't but they are live ebuilds
[21:16:20] <wired> even if they occasionally break i don't see any harm done
[21:16:27] <hwoarang> yngwin: i mean that you should take the 4.9999 one, me the 4.6.9999 etc
[21:16:36] <yngwin> ah ok
[21:16:56] <wired> hwoarang: we can do this over mail like last time
[21:17:00] <hwoarang> just to make sure that all of them are in a good shape and that we have at least one pc that uses every version
[21:17:02] <yngwin> well, i can take on 4.9999 for now, until 4.7 is branched
[21:17:23] <hwoarang> wired: i think we should write this down since I always forget who maintains what
[21:17:38] <hwoarang> wiki seems a good place to me
[21:17:50] <yngwin> indeed
[21:18:03] <hwoarang> we will take about this over mail 
[21:18:03] <yngwin> let's put it in the wiki
[21:18:08] <hwoarang> or
[21:18:15] <hwoarang> we can edit the wiki ourselves
[21:18:24] <yngwin> ok, shall we move to point 2?
[21:18:27] <hwoarang> sure
[21:18:31] <wired> devs testing ebuilds can just add themselves on the wiki
[21:18:33] <wired> :)
[21:18:40] <yngwin> exactly
[21:18:43] <yngwin> 2. gentoo-qt irc channel
[21:18:43] <hwoarang> yes that is better
[21:19:06] <yngwin> we spoke about this already, and i think most of us agree to use #gentoo-qt as our devroom
[21:19:11] <wired> +1
[21:19:12] <ayoy> yes yes yes!
[21:19:21] <hwoarang> ofc
[21:19:21] <wired> if anyone drops by we can help them as well
[21:19:27] <ayoy> it's so nice over here, so calm and quiet :)
[21:19:29] <reavertm> ayoy: you're not funny! :P
[21:19:29] <wired> but i like how its pure Qt talk
[21:19:31] <spatz> better to direct them to #-kde
[21:19:40] <wired> or if you prefer
[21:19:42] <yngwin> but user support is still prefered to go to -desktop or -kde
[21:19:43] <wired> pure Qute talk
[21:19:43] <ayoy> reavertm: I'm just feeling safe over there :P
[21:19:44] <wired> :P
[21:20:01] <yngwin> :)
[21:20:05] <hwoarang> yngwin: if this is the case, why are we using this channel?
[21:20:08] <hwoarang> just for dev talk?
[21:20:12] <wired> ...
[21:20:19] <spatz> hwoarang: to not make a mess of #-kde
[21:20:26] <yngwin> which channel?
[21:20:30] <hwoarang> this one
[21:20:31] <spatz> but there's no reason to have a million support channels, one is enough
[21:20:37] <hwoarang> which one
[21:20:38] <reavertm> I don't think you can provent mess on -kde
[21:20:42] *** Parts: Vtester (~loukas@×××××××××××××××××××××××.gr)
[21:20:42] <reavertm> pre*
[21:20:48] <yngwin> this one is for gentoo meetings, it's more generic
[21:20:50] <hwoarang> you stated above that you will redirect them on -kde or desktop
[21:20:51] <spatz> de-mess #-kde :)
[21:20:54] <hwoarang> sorry
[21:20:55] <hwoarang> the -qt
[21:20:58] <wired> for dev talk!
[21:21:02] <hwoarang> ok
[21:21:08] <yngwin> #-qt is for dev talk
[21:21:13] <hwoarang> gotcha
[21:21:29] <reavertm> I don't think you need one, there's no gentoo-gtk channel after all
[21:21:34] <yngwin> as #-kde can get quite busy 
[21:21:35] <hwoarang> :P
[21:21:39] <wired> reavertm: we actually use it
[21:21:50] <wired> reavertm: and we like how quiet it is
[21:21:51] <wired> :P
[21:21:57] <yngwin> we generate more discussion than the gnome team
[21:21:59] <reavertm> so why debating his topic?
[21:22:02] <ayoy> plus Qt and surroundings is growing
[21:22:22] <yngwin> we debate it because it wasnt official before
[21:22:31] <yngwin> it has grown this way in recent months
[21:23:08] <yngwin> alright
[21:23:17] <yngwin> 3. qt:3 removal
[21:23:34] <yngwin> the big mask is scheduled for this sunday
[21:23:58] <yngwin> it looks like we are mostly on track
[21:24:06] <yngwin> except for mythtv
[21:24:29] <yngwin> ssuominen, scarabeus: does QA have anything to say about this?
[21:25:13] <hwoarang> any bug # for mythtv?
[21:25:48] <yngwin> yes bug 299222
[21:25:50] <willikins> yngwin: https://bugs.gentoo.org/299222 "Please mark media-tv/mythtv-0.22-p23069 stable"; Gentoo Linux, Ebuilds; NEW; rich0@g.o:cardoe@g.o
[21:26:37] <yngwin> basically someone who knows mythtv should write a news item pointing to instructions on database upgrade issues
[21:27:03] <ssuominen> i'd like to see gambas bumped without USE="qt3", wpa_supplicant cleaned up (the versions with still USE="qt3" removed) and then there is mythtv...
[21:27:03] <hwoarang> i doubt that we can sort this out till sunday
[21:27:25] <ssuominen> and avoid all the use.masking of qt3 flag as unnecessary
[21:27:52] <yngwin> ssuominen: we will just mask the qt3 useflag, so that should not generate problems afaik, but mythtv is a bigger issue
[21:28:15] <ssuominen> if gambas and wpa_supplicant is handled, the use.masking is unnecessary
[21:28:30] <ssuominen> and kde-sunset users don't get screwed :)
[21:28:38] <yngwin> hmm
[21:28:59] <yngwin> i was planning on getting some files ready for sunset users anyway
[21:30:06] <yngwin> so what's the plan for mythtv?
[21:30:28] <yngwin> the maintainer has said he has no time to write a news item
[21:30:53] <hwoarang> silense
[21:30:54] <hwoarang> :P
[21:31:01] <yngwin> he would even be okay with just marking the new version stable
[21:31:51] <wired> that would take some time, no?
[21:32:20] <yngwin> its just 3 arches
[21:32:38] <yngwin> i think it could be done in a week
[21:32:55] <yngwin> IF, and thats a big IF, someone can take care of the news item first
[21:33:22] <wired> well someone has to try new mythtv first, has anyone done that?
[21:33:30] <yngwin> yes plenty
[21:33:53] <wired> so write the news item! :P
[21:34:23] <yngwin> i havent and i dont know which instructions are the right ones
[21:34:33] <wired> ah 
[21:34:37] <wired> i thought _you_ had
[21:34:37] <yngwin> all i can do is refer ppl to the comments on the bug
[21:34:50] <yngwin> no then it would already be taken care of
[21:35:05] <wired> right
[21:35:13] <yngwin> i know that ppl have, as can be seen in the comments on the bug
[21:35:16] <wired> so we _must_ take care of it to remove qt3...
[21:35:33] <yngwin> "I HIGHLY recommend publishing a HOWTO or a news item regarding the utf8 issues,
[21:35:33] <yngwin> unless they no longer exist.  Otherwise everybody who just does an emerge -u
[21:35:33] <yngwin> world is going to end up with a ruined mythtv database with no easy recovery
[21:35:33] <yngwin> path.  "
[21:36:09] <yngwin> "My understanding is that if you DON'T run the manual database fixes (which will
[21:36:09] <yngwin> be required for anybody who has been running stable on gentoo for more than a
[21:36:09] <yngwin> year or two), you end up with a mix of text encodings in the database, and that
[21:36:09] <yngwin> is pretty-much unrecoverable (without a lot of manual cleanup)."
[21:37:48] <yngwin> personally i see two choices: (1) leave qt:3 itself and mythtv unmask for a little longer, or (2) mask all of mythtv until this is sorted
[21:38:04] <hwoarang> meh
[21:38:06] <wired> mmm
[21:38:17] <wired> well we're stalling here
[21:38:42] <wired> maybe (1) is a better option for our users
[21:38:58] <yngwin> i prefer option 1, but then i want someone promising me this will be taken care of within say the next two weeks
[21:39:30] <spatz> !meta mythtv
[21:39:32] <willikins> spatz: Package: media-tv/mythtv Herd: mythtv Maintainer: cardoe@g.o, (Maint-desc: Do not CC me on bugs)
[21:39:36] <yngwin> as things stand now, i consider mythtv maintainer-needed and that forces me to go  for option 2
[21:40:01] <spatz> !herd mythtv
[21:40:02] <willikins> spatz: (mythtv) beandog, cardoe, tanderson
[21:40:13] <spatz> maybe beandog or tanderson can do something?
[21:40:32] <hwoarang> doubtful
[21:40:51] <yngwin> beandog is still on pre-current stable
[21:41:03] <yngwin> tanderson could in principle
[21:41:43] <yngwin> i'll write an email to mythtv herd then and let them make the choice
[21:41:52] <hwoarang> ok
[21:42:01] <wired> we could... extend the qt mask for one week, open a forum item and/or bug about it requesting info on the upgrade path
[21:42:06] <wired> then just mask if noone cares enough
[21:42:40] <yngwin> the bug was opened almost two months ago, no one has cared so far
[21:42:48] <wired> i was hoping for users not devs
[21:43:07] <yngwin> yes, the only helpful feedback on the bug is from users
[21:43:26] <yngwin> but we could open a forum thread either way
[21:44:39] <spatz> so what's the decision, the masking is postponed in the mean time?
[21:44:54] <hwoarang> i 'd say so
[21:45:19] <yngwin> i'd say we go ahead unless we get positive feedback that mythtv will be fixed soon
[21:45:59] <yngwin> they have known this for 6 months now
[21:46:38] <spatz> they=cardoe?
[21:46:52] <yngwin> yes, and the other herd members
[21:47:05] <hwoarang> as you wish
[21:47:23] <hwoarang> at least tell them ( comment on the bug ) that there is a final deadline till sunday
[21:47:25] <spatz> I don't like screwing users over due to dev incompetence
[21:47:35] <hwoarang> actually, till tomorrow so the arch team can stabilize it ASAP
[21:47:39] <yngwin> i dont see the point of postponing if nobody is committing to fixing the situation
[21:47:48] <spatz> even if the news item is out in 3 mins they won't stabilize it until sunday
[21:47:53] <yngwin> it could take another 6 months
[21:47:58] <hwoarang> i can for amd64
[21:48:04] <hwoarang> and we can push the rest archers
[21:48:14] <yngwin> if the news item is organized, then i'd be willing to postpone
[21:48:39] <spatz> so let's start a forum thread and ask users for a mini migration guide
[21:48:49] <hwoarang> ok sounds fine
[21:48:55] <yngwin> fine with me
[21:49:30] <yngwin> ok, any other qt3 related issues?
[21:49:33] <hwoarang> no
[21:49:40] <hwoarang> none I can think of
[21:49:49] <spatz> any bugs open on what ssuominen mentioned, gambas and wca_supplicant?
[21:49:53] <yngwin> ssuominen mentioned gamabas and wpa_supp
[21:50:04] <yngwin> spatz: there must be
[21:50:31] <ssuominen> gambas: bug 301376 and bug 302136
[21:50:33] <willikins> ssuominen: https://bugs.gentoo.org/301376 "dev-util/gambas has optional dep on qt:3"; Gentoo Linux, Ebuilds; NEW; yngwin@g.o:maintainer-needed@g.o
[21:50:46] <yngwin> and bug 302136
[21:50:48] <willikins> yngwin: https://bugs.gentoo.org/302136 "dev-util/gambas-2.19.0 version bump"; Gentoo Linux, Applications; NEW; jer@g.o:maintainer-needed@g.o
[21:50:55] <yngwin> thanks willikins
[21:50:59] <spatz> bug 246932
[21:51:01] <willikins> spatz: https://bugs.gentoo.org/246932 "net-wireless/wpa_supplicant USE="qt3" removal"; Gentoo Linux, Applications; NEW; yagorbunov@××××.ru:mobile@g.o
[21:51:10] <hwoarang> !herd mobile
[21:51:11] <willikins> hwoarang: (mobile) betelgeuse, cardoe, genstef, peper, steev
[21:51:17] <hwoarang> ya right
[21:51:18] <hwoarang> :)
[21:51:25] <hwoarang> dead herd
[21:51:40] <hwoarang> i bet we can touch them without even notice it
[21:51:41] <ABCD> !meta -v net-wireless/wpa_supplicant
[21:51:42] <willikins> ABCD: Package: net-wireless/wpa_supplicant Herd: mobile Maintainer: gurligebis@g.o
[21:51:43] <willikins> ABCD: (mobile) betelgeuse, cardoe, genstef, peper, steev
[21:51:44] <yngwin> i can look at gambas
[21:51:46] <wired> dont tell betelgeuse that :P
[21:52:04] <hwoarang> :P
[21:52:12] <hwoarang> i can ask and take care of wpa_supplicant
[21:52:20] <ssuominen> yngwin: I started working on gambas once, here's the ebuild: http://paste.pocoo.org/show/180222/
[21:52:32] <ssuominen> yngwin: gambas-2.19.0.ebuild
[21:52:39] <wired> i could also take care of wpa_sup
[21:52:39] <yngwin> ok
[21:52:41] <wired> i use that thing
[21:52:42] <wired> :p
[21:52:48] <yngwin> great
[21:52:51] <ssuominen> yngwin: I gave up after it started running xdg-utils crap and give me SANDBOX violations
[21:53:00] <yngwin> i c
[21:53:06] <yngwin> well, i'll have a go
[21:53:09] <ssuominen> yngwin: patching them out needs eautoreconf, and eautoreconf needs those optional deps present
[21:53:19] <ssuominen> yngwin: kinda sucks ;p
[21:53:45] <yngwin> well, i'll play with it and see
[21:53:51] <hwoarang> nice
[21:54:06] <yngwin> as it's maintainer-needed we can mask it until someone is ready to pick it up
[21:54:37] <ssuominen> well it's really simple: if nobody here now cares about it, just add treecleaner@ to CC :P
[21:54:59] * hwoarang evil! :)
[21:55:15] <hwoarang> we are waiting just by the corner
[21:55:22] <ssuominen> ;)
[21:55:32] <yngwin> there's also bug 301382
[21:55:34] <willikins> https://bugs.gentoo.org/301382 "games-board/qgo removal"; Gentoo Linux, Applications; NEW; yngwin@g.o:games@g.o
[21:55:44] <ssuominen> oh yeah, trunk is qt4
[21:55:45] <yngwin> a qt4 snapshot version is possible there
[21:56:07] <yngwin> there is a live ebuild attached but it needs work
[21:56:12] <hwoarang> i will take care of it
[21:56:17] <yngwin> great
[21:56:26] <hwoarang> mask the current ebuild in the mean time
[21:57:11] <yngwin> then what we need is to prepare a package.mask file with all ebuilds that depend on qt:3, so we can drop that in when the time is ready
[21:57:26] <yngwin> that couls also be used as package.unmask for sunset users
[21:57:33] <hwoarang> indeed
[21:57:47] <hwoarang> we can work on this in overlay
[21:57:47] <yngwin> i propose we work on that in the overlay
[21:57:52] <hwoarang> ha :P
[21:57:54] <yngwin> :)
[21:57:59] <wired> lol
[21:58:08] <yngwin> !rdep qt
[21:58:09] <willikins> yngwin: Too many packages have reverse RDEPEND on x11-libs/qt, go to http://tinderbox.dev.gentoo.org/misc/rindex/x11-libs/qt instead.
[21:58:16] <yngwin> that is a good start ^
[21:58:38] <hwoarang> noted
[21:58:38] <yngwin> and then compare it to the bugs in the tracker
[21:58:49] <yngwin> so who is going to work on that?
[21:59:00] <hwoarang> i will
[21:59:08] <hwoarang> but it wont be my 1st priority
[21:59:11] <hwoarang> :/
[21:59:15] <yngwin> i will as well
[21:59:19] <hwoarang> ok
[21:59:23] <wired> hwoarang: i'll get wpa from you, so you'll have more time
[21:59:23] <wired> :p
[21:59:28] <yngwin> but i was hoping for some more cooperation
[21:59:36] <hwoarang> fine wired
[21:59:49] <hwoarang> yngwin: it doesnt matter since i will have some spare time these days
[21:59:56] <yngwin> ok
[22:00:11] <yngwin> and we'll stay in touch about this in #-qt
[22:00:22] <hwoarang> sure thing
[22:00:29] <yngwin> anything else about qt:3
[22:00:43] *** Joins: pesa (~Pesa@×××××××××××××××××××××××××××××××××××××××××××××××.it)
[22:00:43] <yngwin> ok, then 4
[22:00:47] <yngwin> 4. qt 4.6.x stabilization
[22:00:49] <pesa> hey guys
[22:00:52] <pesa> sorry for the delay
[22:00:52] <hwoarang> hello there
[22:00:56] <yngwin> hi pesa
[22:00:56] <wired> hey pesa 
[22:00:57] <hwoarang> no prob !
[22:01:03] <wired> dont worry about it
[22:01:04] <wired> :)
[22:01:09] <yngwin> we're not done yet, so
[22:01:19] <pesa> there was a car accident :(
[22:01:22] <wired> oh
[22:01:24] <ayoy> :/
[22:01:25] <hwoarang> oops
[22:01:26] <wired> you ok?
[22:01:26] <pesa> i got trapped in the traffic jam
[22:01:31] <wired> ah
[22:01:32] <yngwin> i c
[22:01:32] <ayoy> oh, good you're ok
[22:01:35] <pesa> yeah i wasn't involved
[22:01:53] <hwoarang>  :)
[22:01:56] <yngwin> alright :)
[22:02:03] <wired> lets go to 4.
[22:02:17] <yngwin> about stabilization: 4.6.1 now, or wait ~2 weeks and go for 4.6.2?
[22:02:23] <hwoarang> 2
[22:02:28] <spatz> 2
[22:02:33] <wired> i stick to my original proposal, go for .2
[22:02:43] <ayoy> what are the issues with 4.6.1?
[22:03:02] <ayoy> apart from bugs on failed linking/compilation of qt-webkit and qt-gui
[22:03:08] <yngwin> nothing really
[22:03:10] <ayoy> which are probably invalid
[22:03:13] <ayoy> ;)
[22:03:22] <hwoarang> i would expect 4.6.2 to work better with Kde-4.4
[22:03:23] <pesa> those are binutils bug afaik
[22:03:24] <hwoarang> than 4.6.1
[22:03:29] <yngwin> no they are valid, but ppc only and being taken care of by toolchain
[22:03:48] <ayoy> yeah, I actually meant so
[22:03:49] <wired> we have .2 around, no serious bugs yet, lets get straight to that 
[22:03:54] <yngwin> hwoarang: yes but kde 4.4 is not going stable for the next few months
[22:03:54] <spatz> I think we can stabilize march 1st
[22:04:02] <wired> spatz: +1
[22:04:07] <hwoarang> ok
[22:04:23] <spatz> that's soon enough, imo
[22:04:27] <wired>  assuming nothing horrible pops up in the meantime
[22:04:32] <spatz> as always :)
[22:04:42] <hwoarang> i agree
[22:04:46] <yngwin> ok, it seems the consensus is to do 4.6.2 stablereq on march 1st
[22:04:48] <ayoy> no problem for me, just wondering what's wrong with .1
[22:04:55] <ayoy> :)
[22:04:55] <wired> ayoy: its OLD!
[22:04:57] <wired> :P
[22:05:03] <hwoarang> moving to 5?
[22:05:04] <ayoy> yeaaaah :D
[22:05:07] <ayoy> yup
[22:05:18] <wired> gogo
[22:05:18] <hwoarang> pesa: i need your opinion for 5
[22:05:19] <yngwin> 5. shall we keep resetting QMAKE_RPATH in eqmake4?
[22:05:19] <yngwin> It might cause problems for some apps that need an RPATH.
[22:05:29] <pesa> hwoarang: oh ok :P
[22:05:39] <hwoarang> do you remember when and why we added that?
[22:05:52] <pesa> since the beginning IIRC
[22:05:57] <ayoy> pesa: not really
[22:05:58] <hwoarang> indeed
[22:06:02] <ayoy> it's not present in qt4.eclass
[22:06:03] <hwoarang> it was there in 2/2/2009
[22:06:11] <ayoy> yyy?
[22:06:17] <hwoarang> i mean in qt4-edge
[22:06:26] <hwoarang> the first commit of qt4-edge has it
[22:06:30] <ayoy> yeah, I got it :)
[22:06:34] <hwoarang> but why/who addedit and why
[22:06:39] <hwoarang> i cant really recall
[22:06:42] <pesa> uhm
[22:06:48] <hwoarang> maybe it was in your very primary patches
[22:06:54] <pesa> maybe
[22:07:05] <ayoy> well, it's okay to remove fishy RPATHs and it's nice that our eclass does it
[22:07:06] <pesa> i remember there were a bug in older qmake
[22:07:11] <ayoy> but there are cases when RPATH is needed
[22:07:17] <ayoy> and it's valid
[22:07:26] <ayoy> and then we have bug 305445
[22:07:28] <willikins> https://bugs.gentoo.org/305445 "media-gfx/kst-2.0.0_beta2-r1 does not start"; Gentoo Linux, Ebuilds; NEW; marco.dr@×××××××.it:ayoy@g.o
[22:07:30] <hwoarang> what if you added in the end of qmake command?
[22:07:32] <pesa> ancient qmake did set a wrong RPATH in most cases
[22:07:33] <hwoarang> *eqmake4
[22:07:37] <spatz> as ssuominen pointed out, portage takes care of unsafe RPATHs, so we don't need to worry about it
[22:07:47] <ayoy> hwoarang: I haven't tried it
[22:07:53] <ayoy> though it should fix the problem
[22:07:55] <hwoarang> spatz: afaik portage complains 
[22:08:04] <hwoarang> and throughs QA warnings
[22:08:09] <ayoy> my question is what behaviour we want as default?
[22:08:14] <spatz> which is good enough, imo
[22:08:16] <yngwin> can we test it in qt4-edge and drop it there
[22:08:17] <pesa> yeah portage complains and workarounds the problem
[22:08:21] <ayoy> I'd say that in most cases there are no insecure RPATHs
[22:08:36] <pesa> i think ayoy is right
[22:08:39] <ayoy> and if they are, why not add "QMAKE_RPATH=" to eqmake4 then
[22:08:49] <pesa> qmake was fixed to add correct runpaths i think
[22:08:51] <ayoy> or even provide a flag in qt4-r2.eclass
[22:08:58] <hwoarang> flag?
[22:09:04] <pesa> no need for a flag
[22:09:05] <ayoy> that would reset QMAKE_RPATH
[22:09:16] <ayoy> like you write an ebuild, and have insecure rpaths
[22:09:22] <ayoy> you set a flag and have them fixed
[22:09:27] <ayoy> thou it seems like an overkill
[22:09:28] <wired> we could override qt4-r2 for in overlay for testing, without the RPATH override, if all goes well we commit it
[22:09:29] <pesa> just call eqmake4 passing QMAKE_RPATH= from the affected ebuilds
[22:09:40] <ayoy> pesa++
[22:09:47] <hwoarang> well yes
[22:09:51] <spatz> wired: it's ok in qt4.eclass, no reason it won't work in qt4-r2
[22:10:00] <hwoarang> that would be the best since eqmake4 accepts parameters
[22:10:13] <ayoy> spatz++ :)
[22:10:13] <yngwin> ok, so let's drop it
[22:10:15] <spatz> so let's just remove it
[22:10:22] <ayoy> ok, I'm gonna do it
[22:10:30] <hwoarang> lets see how that will go
[22:10:35] <yngwin> alright
[22:10:38] <wired> :)
[22:10:41] <spatz> so 6?
[22:10:43] <pesa> is there a bug for that?
[22:10:44] <ssuominen> good
[22:10:46] <ayoy> yes please
[22:10:46] * ssuominen is happy
[22:10:55] * spatz is happy when ssuominen is happy
[22:11:06] * wired is happy because he's happy!
[22:11:07] <hwoarang> about 6
[22:11:11] <hwoarang> what the heck is that
[22:11:18] <yngwin> 6. Harmattan UI Application Framework (a.k.a. Maemo 6 or MeeGo) ebuilds
[22:11:24] <ayoy> guys, this is a mess
[22:11:32] <pesa> lol
[22:11:37] <yngwin> hwoarang: what we talked about before, the meego ui ebuilds
[22:11:47] <hwoarang> I asked on #meego
[22:11:48] <ayoy> anyhow, that's one of Nokia's proposals for QGraphicsView-based widget framewoerk
[22:11:50] <yngwin> i didnt know ayoy started this
[22:11:50] <hwoarang> there is no repo available
[22:11:53] <hwoarang> so what is that
[22:11:59] <spatz> why is there another overlay for that? looks like only 3 packages
[22:12:04] <ayoy> hwoarang: there is a repo available
[22:12:09] <hwoarang> for meego?
[22:12:11] <ayoy> and I've been working on this for 9 months now...
[22:12:12] <wired> ayoy: so with those ebuilds i can have meego?
[22:12:15] <yngwin> hwoarang: this is on nokia's repo
[22:12:25] <pesa> ayoy: oh nice :)
[22:12:25] <ayoy> wired: yes, but don't call it meego yet
[22:12:32] <ayoy> pesa: kthx :)
[22:12:36] <yngwin> this is their work on maemo 6, the successor of maemo 5 (in n900 now)
[22:12:45] <ayoy> this is the proposed Maemo 6 UI
[22:12:45] <hwoarang> ah
[22:12:47] <ayoy> based on Qt
[22:12:47] <hwoarang> maemo
[22:12:48] <hwoarang> ok
[22:12:51] <yngwin> maemo 6 is set to be marketed as meego 1.0
[22:12:51] <ayoy> and QGraphicsView
[22:12:57] <wired> ayoy: ok, (gj btw) so why isn't that in qting-edge? or in a "meego" overlay in layman? :P
[22:13:14] <hwoarang> yes, why having two overlays
[22:13:15] <ayoy> wired: because I wasn't sure if we want to add this
[22:13:17] <hwoarang> we can use a branch
[22:13:27] <pesa> no need to create yet another overlay imho
[22:13:29] <hwoarang> ofc we will have meego
[22:13:29] <wired> why branch
[22:13:30] <spatz> why wouldn't we want to add this? that's what overlays are for
[22:13:31] <wired> just merge them
[22:13:33] <ayoy> it's not about branching
[22:13:35] <ayoy> sure
[22:13:40] <wired> i don't see any conflicting ebuilds
[22:13:40] <wired> :)
[22:13:43] <hwoarang> wired: because we are gonna do some heavy work on this
[22:13:48] <wired> hwoarang: so?
[22:13:48] <ayoy> I didn't want to "publish" it so quickly
[22:13:54] <yngwin> i was planning to create ebuilds for the meego ui at some point and host them in qting-edge
[22:13:56] <ayoy> but I've asked today at work 
[22:14:07] <ayoy> and I got applause and acceptance :P
[22:14:16] <ayoy> so I'll transfer these ebuilds to qting-edge
[22:14:24] <hwoarang> wired: seems more appropriate to me
[22:14:26] <ayoy> and we're done with it
[22:14:30] <pesa> sweet
[22:14:41] <ayoy> if anyone is interested
[22:14:44] <hwoarang> to work on a separate branch before push it to master branch
[22:14:47] <ayoy> just emerge libdui
[22:14:51] <yngwin> i was thinking we may want a new category for this
[22:14:52] <pesa> do they use a custom build system?
[22:14:57] <ayoy> with demos USE (it's enabled by default)
[22:15:04] <ayoy> and runi widgetsgallery
[22:15:07] <ayoy> *run
[22:15:09] <ayoy> to see the demo :)
[22:15:11] <wired> hwoarang: qting-edge is already an overlay, branching will just make it messy
[22:15:14] <ayoy> pesa: no, it's qmake-based
[22:15:21] <wired> it won't be installed to user systems automatically :P
[22:15:25] <ayoy> yngwin: I was thinking the same
[22:15:25] <pesa> ayoy: i see
[22:15:32] <wired> lets just add it there, we can always mask it if it fails at some point
[22:15:40] <ayoy> yngwin: but for now there are 2 relevant packages only
[22:15:47] <yngwin> ok
[22:15:50] <ayoy> wired: it won't fail :)
[22:15:52] <spatz> it's just 3 packages, let's not get ahead of ourselves :)
[22:16:04] <yngwin> let's talk about the details in #-qt later
[22:16:07] <ayoy> one of them is irrelevant :P
[22:16:12] <ayoy> okay
[22:16:15] <wired> ayoy: im just saying... :)
[22:16:19] <ayoy> I'll commit them to qting-edge
[22:16:23] <yngwin> but we agree these are interesting and we want them in qting-edge
[22:16:27] <hwoarang> ofc
[22:16:58] <ayoy> however, one finding :)
[22:17:10] <wired> excellent
[22:17:11] <wired> :)
[22:17:14] <ayoy> meego, or Maemo 6 might be different
[22:17:15] <ayoy> :)
[22:17:21] <ayoy> as Nokia hasn't decided yet
[22:17:29] <ayoy> and they really have problems with it :)
[22:17:33] <spatz> let's move to 7?
[22:17:36] <ayoy> yup
[22:17:51] <yngwin> yes there will be a lot of work on meego still to come
[22:18:09] <yngwin> anyway
[22:18:14] <hwoarang> guys i have to leave now. you dont need my presence
[22:18:15] <yngwin> 7. other open bugs
[22:18:22] <yngwin> hwoarang: ok, thanks
[22:18:25] <hwoarang> i will read the backlong later about 7 
[22:18:26] <spatz> hwoarang: thanks, cya
[22:18:28] <hwoarang> :)
[22:18:30] <wired> hwoarang: ok, thanks for being here, ctya
[22:18:31] <ayoy> bai hwoarang
[22:18:32] <wired> cya
[22:18:33] * hwoarang laterz
[22:18:45] <pesa> hwoarang: thanks, cya ;)
[22:19:13] <yngwin> http://gitorious.org/gentoo-qt/pages/PriorityBugs
[22:19:41] <wired> bug 292337
[22:19:42] <yngwin> did anybody work on any of these bugs?
[22:19:43] <willikins> wired: https://bugs.gentoo.org/292337 "x11-libs/qt-webkit-4.5.3 requires dbus or not?"; Gentoo Linux, Applications; REOP; tot-to@××××××.com:qt@g.o
[22:19:45] <wired> i can actually test this now
[22:19:49] <wired> i'll do that
[22:19:50] <wired> :)
[22:20:05] <yngwin> ok
[22:21:02] <yngwin> did anybody test goldendict with gcc 4.4?
[22:21:35] <pesa> i didn't
[22:21:41] <yngwin> i guess not
[22:22:10] <pesa> i can do it though
[22:22:32] <yngwin> ayoy: you added the patch
[22:22:39] <pesa> well i can't move to portage :P
[22:22:47] <pesa> but i can review the ebuild
[22:22:59] <yngwin> ok plz do
[22:23:08] <ayoy> yngwin: really?
[22:23:18] <yngwin> 4 months ago it seems
[22:23:38] <yngwin> http://gitorious.org/gentoo-qt/qting-edge/commit/d56cfee40a63b0d827ebc303d55e2b799667c025
[22:23:47] <ayoy> ah true
[22:23:50] <ayoy> I was looking at the bug
[22:23:57] <ayoy> so I tested it
[22:24:02] <ayoy> half a year ago
[22:24:16] <yngwin> ok
[22:24:39] <yngwin> there's also the live ebuild that needs review
[22:25:04] <yngwin> so if pesa can do that, we can finally solve that bug
[22:25:11] <pesa> yeah ok
[22:25:33] <pesa> upstream suggest using a git version with qt >= 4.5.3 anyway
[22:25:39] <pesa> *suggests
[22:25:41] <yngwin> yes
[22:25:48] <yngwin> maybe we could make a snapshot
[22:26:04] <yngwin> i could take a look at that after the qt3 mask
[22:26:25] <pesa> ok, i'll do my reviews meanwhile
[22:26:30] <yngwin> and what about bug 300594
[22:26:32] <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
[22:26:56] <ayoy> yeah, it breaks multilib
[22:27:22] <pesa> native multilib you mean?
[22:27:54] <ayoy> I don't really know what "native" means here
[22:28:05] <pesa> sorry, i'd better read the description :P
[22:28:09] <ayoy> but I guess that it's adding -m64 everywhere to qt mkspecs
[22:29:18] <ayoy> or isn't it just about a libdir?
[22:29:28] <ayoy> i.e. lib vs lib64
[22:29:46] <pesa> i think so
[22:30:42] <ayoy> anyway, we're modifying mkspecs for Qt in qt-core ebuilds
[22:30:54] <ayoy> precisely, QMAKE_CFLAGS and QMAKE_CXXFLAGS
[22:30:55] <ayoy> iirc
[22:31:22] <pesa> so?
[22:31:32] <ayoy> so I don't really know if the bug is relevant
[22:31:50] <yngwin> can somebody just commit himself to finding out what is the correct solution?
[22:31:50] <ayoy> cause mkspecs defaults are somewhat ignored
[22:32:00] <ayoy> by CFLAGS from make.conf
[22:32:12] <ayoy> I can comment on the bug
[22:32:18] <ayoy> anyway, I can think about the solution
[22:32:24] <yngwin> ok
[22:32:33] <pesa> it's a bit of a mess TBH
[22:32:40] <ayoy> tru
[22:33:15] <yngwin> also bug 305001
[22:33:17] <willikins> yngwin: https://bugs.gentoo.org/305001 "x11-libs/qt-core references /usr/X11R6 in mkspecs"; Gentoo Linux, Library; NEW; ohnobinki@××××××××××××××.net:qt@g.o
[22:33:28] <ayoy> oh :)
[22:33:44] <ayoy> this one is pretty straightforward thou
[22:33:57] <ayoy> I guess that the issue is that /usr/X11r^ is deprecated, right?
[22:34:03] <ayoy> */usr/X11R6
[22:34:04] <yngwin> yes
[22:34:06] <pesa> yep
[22:34:16] <ayoy> so just sed it out and be happy
[22:34:27] <pesa> coincidentally i noticed that just the day before the bug was reported :P
[22:34:32] <yngwin> so should be easy to fix, but somebody needs to do it
[22:34:43] <ayoy> I'll do it as well
[22:34:49] <yngwin> thanks
[22:35:53] <yngwin> anything else?
[22:35:57] <pesa> btw has anyone tested qt without X11 recently?
[22:36:12] <yngwin> not me
[22:36:26] <ayoy> there was a bug that got reopend, or resubmitted recently
[22:36:33] <ayoy> about qt-core depending on libX11
[22:36:37] <ayoy> pesa: do you mean this issue?
[22:36:43] <wired> i thought i fixed htat
[22:36:46] <pesa> i dunno
[22:36:47] <wired> i didn't?
[22:36:50] <ayoy> yeah, it got fixed
[22:37:08] <wired> it didn't "get fixed", i fixed it :P
[22:37:08] <pesa> i noticed a problem with PyQt4 which involves mkspecs
[22:37:19] <ayoy> wired: sry :P
[22:37:25] <wired> ayoy: :D
[22:37:37] <yngwin> bug 304115
[22:37:39] <willikins> yngwin: https://bugs.gentoo.org/304115 "=dev-python/PyQt4-4.7 with USE="-X" tries to link with -lXext"; Gentoo Linux, Applications; NEW; orzel@×××××××××××.org:qt@g.o
[22:38:01] <pesa> more precisely, linux.conf seems to hardcode "-lXext -lX11 -lm" in QMAKE_LIBS_X11
[22:38:14] <ayoy> bastard
[22:38:25] <pesa> do you know if this happens in qt too?
[22:38:40] <pesa> IIRC we just patch the configure
[22:38:40] <ayoy> no idea, I can quickly check
[22:38:58] <ayoy> yes, it does
[22:39:05] <pesa> mmm
[22:39:11] <pesa> so how can that work?
[22:39:20] <wired> interesting
[22:39:28] * wired builds qt-core in his Xless chroot for testing
[22:39:31] <pesa> qmake always tries to link with libX11 and friends
[22:39:32] <ayoy> well, but this is just QMAKE_LIBS_X11
[22:39:39] <ayoy> not necessarily used to build QtCore
[22:39:49] <yngwin> also bug 304971 is related to the earlier issue
[22:39:51] <willikins> yngwin: https://bugs.gentoo.org/304971 "qt-core stores machine-specific information in /usr/share/qt4/mkspecs"; Gentoo Linux, Library; NEW; ohnobinki@××××××××××××××.net:qt@g.o
[22:39:57] <pesa> not to build qt-core, but to build packages depending on it
[22:40:07] <ayoy> ah right
[22:40:41] <yngwin> so can you two try to figure this out?
[22:40:54] <wired> so pesa trying to build quassel-core would fail on an Xless system?
[22:41:09] <pesa> wired: i don't know, i'm asking if it fails
[22:41:18] <yngwin> then i think we can conclude the meeting, unless there is anything else
[22:41:19] <ayoy> yngwin: I can take a look and maybe figure out the solution
[22:41:22] <wired> im starting a merge now pesa 
[22:41:26] <yngwin> great
[22:41:28] <wired> so we'll know in ~20m
[22:41:29] <wired> :)
[22:41:29] <pesa> wired: great thanks
[22:41:44] <ayoy> yngwin: but we're doing stuff that's unsupported by upstream, I'm afraid
[22:41:56] <yngwin> "stuff"?
[22:42:04] <ayoy> messing up with mkspecs
[22:42:06] <wired> pesa: do you want me to test stable (4.5) or testing?
[22:42:11] <pesa> wired: i'll be surprised to know that qmake hardcodes -lX11 but the build succeeds nonetheless :P
[22:42:13] <ayoy> well, even splitting qt to modules :P
[22:42:20] <ayoy> but let's not talk about it :D
[22:42:27] <yngwin> yes, we are aware
[22:42:35] <pesa> wired: uhm... 4.6.x i guess
[22:42:37] <wired> ok
[22:42:53] <pesa> since it's going stable in the near future
[22:42:54] * wired switches to testing chroot
[22:42:59] <pesa> :)
[22:43:34] <wired> ok here goyes
[22:43:37] <wired> ok here goes*
[22:43:40] <yngwin> ok we're done then?
[22:43:45] <ayoy> I guess so
[22:43:45] <wired> i guess
[22:43:46] <ayoy> :)
[22:43:46] <wired> :)
[22:43:48] <wired> lol
[22:43:50] <ayoy> :D
[22:43:52] <yngwin> ====================================
[22:43:55] <wired> the END