Gentoo Archives: gentoo-commits

From: "Markos Chandras (hwoarang)" <hwoarang@g.o>
To: gentoo-commits@l.g.o
Subject: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/desktop/qt/logs: qt-project-meeting-20120603.txt
Date: Sat, 09 Jun 2012 10:34:49
hwoarang    12/06/09 10:34:39

  Added:                qt-project-meeting-20120603.txt
  Add log for 20120603 meeting

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

file :

Index: qt-project-meeting-20120603.txt
[14:01:02] <yngwin> !herd qt
[14:01:03] <willikins> (qt) abcd, hwoarang, johu, kensington, pesa, spatz,
wired, yngwin
[14:01:07] <yngwin> meeting starts
[14:01:10] -*- johu is here
[14:01:22] <yngwin> agenda at
[14:01:24] -*- pesa here
[14:01:28] <yngwin> who else is here?
[14:01:35] <hwoarang> i am here
[14:02:00] <johu> lets start
[14:02:26] <yngwin> kensington?
[14:02:39] <hwoarang> spatz?
[14:02:46] <hwoarang> abcd?
[14:02:46] <hwoarang> :)
[14:02:49] <johu> kensington is marked as away
[14:03:11] <johu> so he is not connected to quassel core
[14:03:20] <yngwin> ok
[14:03:23] <yngwin>  lets start
[14:03:36] <yngwin> who is logging?
[14:04:09] <hwoarang> i guess I do
[14:04:20] <yngwin> being closest to utc :)
[14:04:25] <yngwin> 1. Qt5 progress
[14:04:51] <pesa> I am logging too
[14:04:53] <yngwin> anything new to mention here?
[14:05:17] <pesa> well, they skipped alpha2 afaik
[14:05:32] <pesa> and are aiming for a beta release mid June
[14:06:12] <johu> ok so we have to wait for upstream
[14:06:25] <pesa> Sput pointed out that installation from git works again
[14:06:37] <pesa> so I've resumed working on live ebuilds
[14:06:42] <yngwin> great
[14:06:46] <johu> great
[14:07:01] <pesa> but I have very limited compile power (hardware failure on
main dev box)
[14:07:13] <yngwin> mid june is in 2 weeks, and i should have time then
[14:07:26] <pesa> so I'll try to push what I have for qt-core to qt overlay
[14:07:28] <yngwin> yeah i have limited hw too
[14:07:47] <johu> hwoarang do you have a compile box?
[14:08:06] <yngwin> should we put in a request at infra for access to a build
[14:08:10] <hwoarang> i have few vms for testing
[14:08:13] <pesa> flameeyes said you can give me a shell on the new tinderbox
but no ETA on that
[14:08:19] <pesa> err..*he can give
[14:08:41] <yngwin> yeah DrEeevil also promised me sth like that
[14:08:47] <hwoarang> if you commit live ebuilds I can merge them
[14:08:50] <hwoarang> that is not an issue
[14:08:57] -*- hwoarang loves his 6-core cpu
[14:09:07] <pesa> heh :)
[14:09:14] <pesa> there's always the qmake binary issue to solve
[14:09:36] <pesa> i.e. it conflicts with qt4's qmake
[14:09:41] <DrEeevil> yngwin: ya, need more time to set things up
[14:09:54] -*- DrEeevil feels a bit frustrated with not having enough
[14:09:58] <hwoarang> pesa: what do other people do?
[14:10:00] <yngwin> i feel ya
[14:10:09] <hwoarang> having qmake-qt4 and -qt5 ?
[14:10:33] <hwoarang> i presume other distores will support both at the same
[14:10:34] <pesa> I think other distros will have qmake-qt[45]
[14:10:42] <pesa> yes sure
[14:10:52] <pesa> debian still has qt3
[14:11:01] <johu> debian...
[14:11:10] <hwoarang> would it make sense to start using qmake-qt4 from now?
[14:11:18] <yngwin> we still have kde-sunset
[14:11:20] <hwoarang> as in have qmake be a symlink to qmake-qt4?
[14:11:29] <hwoarang> so the migration would be smoother?
[14:11:40] <pesa> hwoarang: it might make sense yes
[14:11:47] <johu> kde-sunset is a user contributed overlay
[14:11:57] <johu> nothing official
[14:12:16] <pesa> in the end I'm not sure if we should have a qmake symlink
switchable via eselect, or just drop /usr/bin/qmake entirely
[14:12:21] <yngwin> johu: yeah we dont officially support it, but its
[14:12:36] <johu> yngwin: true
[14:13:02] <yngwin> pesa: well, we have time, so we can think about the pros
and contras of both options
[14:13:11] <pesa> yep
[14:13:50] <yngwin> ok, i think we can leave this point at that for now
[14:14:05] <pesa> ok
[14:14:10] <yngwin> 2. qt4.eclass deprecation
[14:14:19] <johu> in a good shape^
[14:14:25] <yngwin> we're doing really well there
[14:14:30] <yngwin> just 2 ebuilds left
[14:14:32] <johu> 2 ebuilds left
[14:14:48] <yngwin> sci-biology seems unresponsive
[14:15:00] <yngwin> i also pinged them on #-dev the other day
[14:16:20] <yngwin> i think we should just go ahead and add arches, unless
there are other suggestions?
[14:16:29] <pesa> I agre
[14:16:33] <johu> ++
[14:16:33] <pesa> agree
[14:17:28] <johu> amd64 and x86 should be done realy fast
[14:17:28] <pesa> wrt vlc-2.0.x stabilization, aballier told me he'd rather
wait for 2.0.2
[14:17:33] <yngwin> ok
[14:17:36] <yngwin> yeah
[14:17:51] <yngwin> but its been a month since your last comment on bug 408881
[14:17:52] <willikins> yngwin:
"<media-video/vlc-2.0.1 : Multiple vulnerabilities (CVE-2012-{1775,1776})";
Gentoo Security, Vulnerabilities; IN_P; ago:security
[14:18:20] <yngwin> i think it's time for a stable vlc-2, especially since 1.*
is vulnerable
[14:18:38] <johu> but there is a cve on 2.0.1 too
[14:18:45] <pesa> true
[14:18:45] <johu> it think thats the blocker
[14:19:56] <pesa> no signs of a 2.0.2 release upstream
[14:20:15] <johu> !meta media-video/vlc
[14:20:16] <willikins> johu: Package: media-video/vlc Herd: video Maintainer:
[14:20:31] <johu> talk to aballier i would suggest
[14:20:34] <hwoarang> well we waited for like 2 years
[14:20:37] <yngwin> yeah
[14:20:39] <hwoarang> we can wait a little bit longer
[14:21:03] <yngwin> but it will be the last ebuild
[14:21:25] <hwoarang> yeah but what can we do?
[14:21:30] <pesa> hwoarang++, no hurries imho
[14:21:37] <hwoarang> if 2.0.1 is not good enough
[14:21:56] <johu> yes its a matter of time that upstream will release a
security fix
[14:21:57] <yngwin> well, 2.0.1 is better than 1.* either way
[14:22:32] <hwoarang> yngwin: give upstream sometime, once the fix is out
x86/amd64 will stabilize it within hours
[14:22:58] <yngwin> if upstream is already taking 1 month or more
[14:23:15] <yngwin> well, lets see again what aballier has to say
[14:23:25] <hwoarang> ok
[14:23:29] <yngwin> you're right that there is no need to hurry with the
eclass issue
[14:24:08] <johu> btw good job to all with the deprecation work :)
[14:24:08] <yngwin> 3. qt4-r2.eclass updates
[14:24:49] <yngwin> pesa: i havent seen that mail yet?
[14:24:59] <pesa> correct :P
[14:25:01] <hwoarang> heh
[14:25:25] <pesa> I'm still not convinced
[14:25:37] <pesa> so I wasn't really motivated
[14:25:43] <yngwin> i see
[14:25:44] <pesa> sorry about that anyway
[14:26:02] <hwoarang> we are talking about the translations right?
[14:26:07] <pesa> yes
[14:26:09] <yngwin> yes
[14:26:11] <hwoarang> wanna make it smarter?
[14:26:27] <pesa> that was my idea but I didn't have time to look into it
[14:26:43] <hwoarang> we can make it smarter during time
[14:26:48] <yngwin> i'm holding out on adding code to e.g. qupzilla
[14:26:50] <hwoarang> as we find different cases in different ebuilds
[14:27:52] <yngwin> well, we may get some good suggestions if we put it out on
the ml
[14:28:01] --> pesa_
(~Pesa@××××××××××××××××××××××××××××××××××××××××××××××××.it) has joined
[14:28:01] <-- pesa_
(~Pesa@××××××××××××××××××××××××××××××××××××××××××××××××.it) has quit (Changing
[14:28:01] --> pesa_ (~Pesa@gentoo/developer/pesa) has joined #gentoo-meetings
[14:28:08] <-- pesa (~Pesa@gentoo/developer/pesa) has quit (Disconnected by
[14:28:10] <-> pesa_ is now known as pesa
[14:28:17] <johu> you will get bikeshedding :D
[14:28:22] <hwoarang> true
[14:28:27] <pesa> sorry my ISP sucks
[14:28:30] <hwoarang> which you can ingore > /dev/null
[14:28:33] <hwoarang> *ignore
[14:28:50] <hwoarang> the discussion will probably move to git issue as usual
[14:28:52] <yngwin> yeah, just keep the relevant feedback
[14:29:08] <pesa> anyway if someone else wants to do the translations work,
I'd be more than happy ;)
[14:29:43] <hwoarang> i am not gonna lie to you. i am too lazy to do it
[14:29:49] <hwoarang> but if nobody else wants to do it, I will
[14:30:04] <yngwin> we already have some code that works
[14:30:24] <pesa> yes we can merge that for now
[14:30:45] <yngwin> i'd say at least submit it to ml for comments
[14:30:49] <yngwin> there are some clever ppl there
[14:31:55] <pesa> true
[14:32:12] <yngwin> so let's do that in 2 parts then, right? translations and
[14:32:25] <pesa> yes
[14:32:32] <yngwin> ok
[14:32:35] <hwoarang> ok
[14:32:52] <yngwin> 4. Qt on exotic arches (again)
[14:32:59] <pesa> iirc 2 ebuilds in gx86 need to be adapted to the new docs
[14:33:32] <yngwin> ok
[14:33:33] <pesa> I'll find them again
[14:33:45] <yngwin> yeah if you can leave a note somewhere
[14:33:58] <yngwin> wrt Qt 4.6
[14:34:08] <yngwin> its so old, i think we need to remove it
[14:34:47] <pesa> and it is vulnerable too
[14:34:57] <pesa> that is my main concern
[14:34:57] <yngwin> yeah thats the more reason
[14:35:29] <yngwin> arches that are too slow and cant keep up, sorry, but we
cant keep this
[14:35:44] <johu> +
[14:35:56] <pesa> maybe we should mail them directly?
[14:35:57] <yngwin> i say we should mask qt-4.6* and deps on those arches,
pending removal
[14:36:31] <yngwin> eh revdeps
[14:38:17] <yngwin> ia64 can keep ~ keywords, they are just too slow to stabe
[14:38:21] <yngwin> stable*
[14:38:45] <yngwin> but alpha and sparc, i dont know if we can do anything
else for them
[14:39:18] <pesa> indeed
[14:40:13] <yngwin> any other ideas?
[14:40:18] <pesa> so maybe warn them, giving them 1-2 weeks to answer, then
mask 4.6* for removal
[14:40:31] <johu> good plan
[14:40:39] <yngwin> yeah
[14:40:59] <pesa> ok, who's gonna write the email?
[14:41:17] <yngwin> i can
[14:42:19] <yngwin> 5. Qt overlay on
[14:42:32] <pesa> yngwin: ty
[14:42:55] <yngwin> Since there is now an official Gentoo project on github,
do we want our overlay mirrored there again?
[14:43:07] <johu> i dont care at 5., i am fine with g.o.go
[14:43:35] <hwoarang> sigh
[14:43:58] <pesa> I'd say yes, we might get more visibility and more
contributions, on the other hand I'm fine with gogo to be honest
[14:44:03] <hwoarang> yeah true
[14:44:22] <yngwin> i'm fine with gitorious
[14:44:34] <yngwin> but yeah, i think the exposure could be useful
[14:44:39] <pesa> gitorious web interface is really a pita sometimes
[14:44:59] <pesa> (slow, redirect loops, etc..)
[14:45:13] <yngwin> yeah sometimes
[14:45:32] <yngwin> but from an admin point of view its the best there is
[14:45:46] <pesa> yes
[14:46:48] <pesa> overall, I'm fine with github mirroring, but I'm fine with
the status quo too, so...I don't really care :P
[14:46:56] <yngwin> so who is in favor of adding github?
[14:47:20] <pesa> I'm in favor but I won't push too hard for it
[14:47:27] <johu> lets wait for gx86 git :)
[14:47:41] <yngwin> pesa: i think most of us feel that way
[14:49:13] <yngwin> ok, "dont care"
[14:49:36] <yngwin> lets move on then
[14:49:44] <yngwin> 6. Open bugs
[14:49:53] <yngwin> #286550 new package: dev-ada/qtada – anyone interested? If
not, we should remove ourselves from CC
[14:50:31] -*- pesa isn't interested
[14:50:38] -*- yngwin neither
[14:51:14] <pesa> btw we are Cc'ed on many more maintainer-wanted bugs
[14:51:21] <yngwin> but since there is no bug activity, we could simply stay
on cc
[14:51:46] <johu> makes no difference to stay in cc or not, we have a small
bug queue
[14:52:11] <pesa> true
[14:53:23] <yngwin> its not a very relevant package, but if someone wants to
write an up-to-date ebuild for it, i'm sure we'd be willing to lend a hand
[14:54:01] <yngwin> ok, leave as is?
[14:54:05] <johu> ++
[14:54:06] <hwoarang> sure
[14:54:15] <pesa> fine
[14:54:18] <yngwin> #388551 x11-libs/qt-gui should depend on
gnome-base/libgnomeui-2 when USE=“gtkstyle” is enabled
[14:54:29] <yngwin> is there anything more for us to do here?
[14:55:08] <pesa> mmm
[14:56:10] <pesa> * #388551 qt-gui[gtkstyle] should depend on
[14:56:11] <pesa> We will add a elog message in qt-gui[gtkstyle] saying that
for things to work
[14:56:13] <pesa> you either need libgnomeui or that variable set properly in
your env.
[14:56:22] <pesa> from qt-project-meeting-summary-20120126.txt
[14:57:48] <yngwin> ok, so that still needs to be committed
[14:59:28] <yngwin> who volunteers for that?
[15:00:18] <yngwin> if no-one else, then i will
[15:00:33] <yngwin> #398497 /usr/include/qt4/Gentoo/gentoo-qconfig.h should be
under package manager control
[15:00:59] <pesa> yngwin: go ahead :P
[15:01:47] <johu> we agreed on it should be under package control last meeting
[15:02:01] <johu> but no progress i guess
[15:02:20] <yngwin> pesa: do you want to implement the suggested solution?
[15:02:46] <pesa> yes sure I can try
[15:03:01] <yngwin> ok, that would be appreciated
[15:03:22] <yngwin> #413541 revdep-rebuild not detected
needed by qt-core (post mortem)
[15:03:26] <pesa> there's the collision-protect case that must be handled
separately but it should be doable I think
[15:03:45] <kensington> :| sorry
[15:03:56] <pesa> hey kensington :)
[15:04:13] -*- yngwin spanks kensington
[15:04:20] <yngwin> glad you could make it :)
[15:04:22] <johu> this bug is kind of solved?!
[15:04:43] <johu> by qt-core-4.8.1-r3
[15:04:46] <pesa> johu: it is...well it's more a workaround rather than a
[15:04:57] <johu> but what we can do about it?
[15:05:01] <yngwin> afaiu the problem will pop up again at the next icu bump
[15:05:49] --> pesa_ (~Pesa@gentoo/developer/pesa) has joined #gentoo-meetings
[15:05:51] <-- pesa (~Pesa@gentoo/developer/pesa) has quit (Disconnected by
[15:05:52] <-> pesa_ is now known as pesa
[15:06:05] <pesa> sorry I went offline again
[15:06:27] <yngwin> the bigger problem imo is that arfrever is still able to
break the stable tree
[15:06:45] <hwoarang> not an icu problem if you ask me
[15:06:45] <pesa> sad but true
[15:06:58] <pesa> not a Qt problem either
[15:07:13] <hwoarang> yeah more like a gentoolkit issue
[15:07:16] <hwoarang> or corner case if you want
[15:07:20] <yngwin> so how can we prevent this problem from occuring again?
[15:07:26] <hwoarang> patch gentoolkit
[15:07:32] <pesa> gentoolkit cannot do anything about dlopen
[15:07:42] <hwoarang> pesa: yes but you can instruct it
[15:08:03] <pesa> hwoarang: how?
[15:08:12] <pesa> yngwin: more testing before stabilizing stuff
[15:08:31] <hwoarang> pesa: the dirty way
[15:08:44] <hwoarang> look for recent icu updates and force rebuild of
packages that you know are affected
[15:08:55] <hwoarang> or write an elog in icu ebuild
[15:09:46] <pesa> yes
[15:09:55] <pesa> I asked arfrever to add that elog but...
[15:10:50] <pesa> and floppym and phajdan kind of rushed the stabilization of
icu imho
[15:11:12] <hwoarang> i will talk to him
[15:11:15] <hwoarang> and add the elog myself
[15:11:24] <pesa> well the elog is useless now
[15:11:32] <hwoarang> will be useful in the future
[15:11:36] <pesa> we force >=icu-49
[15:11:38] <hwoarang> yngwin asked how to not get this problem again
[15:11:41] <pesa> ah yes
[15:11:56] <hwoarang> or!
[15:12:00] <yngwin> yeah i think it is a good idea
[15:12:06] <hwoarang> roll out a new qt-core eveytime you get a new icu
[15:12:09] <hwoarang> :p
[15:12:34] <pesa> that's the only reliable solution, because people don't read
elog messages
[15:12:49] <pesa> (btw I'd suggest an ewarn)
[15:12:53] <hwoarang> yeah
[15:13:08] <hwoarang> but that is why i suggested this is fixed using
hardcoded paths in gentoolkit
[15:13:45] <kensington> can that be done generically, or does it need updating
every time icu breaks?
[15:13:49] <pesa> (btw #2, qt5 has a hard dep on icu so.. :/ )
[15:13:59] <yngwin> oh my
[15:14:10] <yngwin> well, then it will be more widely known
[15:14:10] <hwoarang> kensington: not everytime
[15:14:23] <hwoarang> only when soname changes afaik
[15:15:13] <yngwin> ok, is there anything more to discuss about this?
[15:15:50] <yngwin> hwoarang: maybe the gentoolkit suggestion should be
discussed on dev ml?
[15:16:13] <hwoarang> not sure
[15:16:23] <hwoarang> a but to dev-portage@ people should be enough
[15:16:26] <hwoarang> *bug
[15:16:39] <hwoarang> maybe..
[15:16:41] <yngwin> ok
[15:17:14] <yngwin> #413653 app-text/qpdfview-0.2_beta1 does not display
toolbar icons
[15:18:44] <hwoarang> close it as NEEDINFO or TEST-REQUEST
[15:18:53] <yngwin> yeah
[15:18:57] <yngwin> i cant reproduce
[15:19:04] <johu> beta2 is out^
[15:19:05] <yngwin> i'm using 0.2.2 just fine
[15:19:41] <johu>
[15:20:34] <yngwin> 0.3_beta2, ah good to know
[15:21:45] <yngwin> ok, i'll bump again and ask the user to test
[15:21:52] <yngwin> #413093 implement virtual for stardict, assigned to
maintainer-needed, anyone wants to help?
[15:22:20] <hwoarang> why are we there
[15:22:33] <pesa> for goldendict I guess
[15:22:41] -*- johu isnt interested
[15:22:57] <hwoarang> i am not interested either
[15:23:04] <pesa> same here
[15:23:12] <kensington> ditto
[15:23:47] <yngwin> i occassionaly use goldendict
[15:24:25] <yngwin> !meta -v stardict
[15:24:26] <willikins> yngwin: Package: app-text/stardict Herd: app-dicts
Maintainer: app-dicts Description: StarDict is an international dictionary
Software. It has powerful features ...
[15:24:27] <willikins> yngwin: (app-dicts) pva
[15:24:54] <yngwin> so, imo it should be assigned to app-dicts to implement
the virtual
[15:25:15] <hwoarang> yeah...
[15:25:28] <pesa> mmm right
[15:25:51] <pesa> not sure why it's maintainer-needed
[15:25:56] <yngwin> i dont mind helping out, once my summer holidays start
[15:26:47] <pesa> good, thanks
[15:27:04] <yngwin> pesa: i guess because stardict.eclass doesnt mention a
[15:27:25] <hwoarang>   it does
[15:27:39] <hwoarang> but he is retired :p
[15:27:56] <pesa> yngwin: ah i see
[15:28:40] <yngwin> anyway, i'm not convinced we need a virtual
[15:28:52] <yngwin> just a dep on ||
[15:29:24] <yngwin> but i guess a virtual is "cleaner"
[15:29:54] <pesa> if the || dep is going to be only in the eclass, I agree,
the virtual is not necessary
[15:30:21] <yngwin> afaics its only needed for the eclass
[15:30:24] <pesa> and this seems the case
[15:30:59] <pesa> ok then the virtual is redundant imho
[15:31:04] <yngwin> ok, i will take care of that then
[15:31:28] <yngwin> #417633 www-client/qupzilla-1.2.0 does not work with
SOCKS5 proxy
[15:32:05] <yngwin> we need to find out what the problem is here, since i cant
[15:32:28] <pesa> I can reproduce and I investigated a bit but without any
[15:32:52] <pesa> I suspect the problem might actually reside in libQtNetwork
[15:33:25] <yngwin> so what can we do?
[15:33:44] <pesa> I'll try to debug again
[15:34:43] <yngwin> ok, tnx
[15:34:49] --> pesa_ (~Pesa@gentoo/developer/pesa) has joined #gentoo-meetings
[15:34:49] <-- pesa (~Pesa@gentoo/developer/pesa) has quit (Disconnected by
[15:34:52] <-> pesa_ is now known as pesa
[15:34:54] <yngwin> #418251,#417105 weird build failures, anyone can
[15:35:03] <pesa> meh
[15:35:07] <pesa> did you say something?
[15:35:33] <yngwin> <pesa> I'll try to debug again
[15:35:33] <yngwin> <yngwin> ok, tnx
[15:35:33] <yngwin> <yngwin> #418251,#417105 weird build failures, anyone can
[15:35:43] <pesa> ok
[15:36:21] <johu> not using gcc47 at all
[15:36:35] <pesa> yeah I'm on 4.6 too
[15:36:35] <kensington> had no problems with gcc47 here
[15:37:04] <pesa> kensington: the reporter said he has graphite enabled
[15:37:11] <yngwin> cant reproduce 418251 and i'm not using gcc47 yet
[15:37:23] <kensington> yeah, I have that disabled
[15:37:55] <hwoarang> i will try
[15:38:07] <hwoarang> i have 47+graphite
[15:38:33] <pesa> hwoarang: great, use the same or similar gcc flags as the
[15:38:34] <yngwin> but i have seen other bugs with glib.h problems
[15:39:18] <yngwin> so you might want to have a look at those and compare
[15:39:37] <pesa> 418251 was reported against gcc 4.5 instead and that's
really weird
[15:39:56] <pesa> since it always worked for me
[15:40:32] <kensington> my bet would be on the reporter having a broken
[15:40:35] <pesa> so I'm suspecting a hardware failure here
[15:40:49] <pesa> yes that too
[15:40:58] <johu> broken toolchain/system whatever
[15:41:01] <yngwin> if no-one can reproduce, there isnt much we can do
[15:41:25] <pesa> NEEDINFO?
[15:41:32] <yngwin> yeah
[15:42:01] <yngwin> or sth like that
[15:42:12] <yngwin> 7. Open floor
[15:42:17] <yngwin> anything else?
[15:42:30] <johu> our meetings are way to long :P
[15:43:01] <yngwin> i will try to tighten it up next time
[15:43:06] <pesa> well it's been 3 months since the last one
[15:43:13] <johu> tampakrap left kde and qt herd
[15:43:32] <pesa> oh
[15:43:50] <yngwin> yeah he's concentrating on infra now
[15:43:50] <johu> he will focus on infra stuff
[15:43:56] <pesa> is he focusing on infra stuff only?
[15:44:00] <johu> :D
[15:44:06] <pesa> hehe
[15:44:10] <yngwin> so thanks tampakrap for all the work you've done for Qt!
[15:44:21] <pesa> yeah, thank you tampakrap ;)
[15:45:12] <yngwin> is anyone else using razorqt?
[15:45:31] <johu> only compiled and had a small look
[15:45:34] <pesa> not yet
[15:45:56] <johu> but its not kde, so i cant use it :P
[15:46:19] <yngwin> since i dont want to compile kde on my laptop, its my
gentoo DE
[15:46:51] <yngwin> (tho i have a triple boot with archlinux with kde, and
[15:47:21] <johu> fine
[15:47:48] <yngwin> anyway, as you may have noticed i keep pushing qt apps
into overlay and gx86
[15:48:18] <johu> yes i already noticed it, good job
[15:48:22] <yngwin> :)
[15:48:38] <yngwin> ok, anything else?
[15:49:05] <johu> enjoy the rest weekend  ;)
[15:49:05] <pesa> I guess not
[15:49:08] <yngwin> then this meeting is over