so lets start with qt 4.8 btw, where's spatz? or abcd !herd qt (qt) abcd, johu, pesa, spatz, tampakrap, wired -*- wired is over-hyped ;p -*- johu here i haven't seen spatz for a long time now !seen spatz^ johu: nope! !seen spatz johu: spatz was last seen 11 months, 1 day, 23 hours, 3 minutes and 56 seconds ago, quitting IRC (Quit: Bye) willikins: meh ABCD is undercover, only pops up when he hears something interesting to him ^_^ ok before we go to qt 4.8 i'll readd the github account issue tampakrap forwarded yngwin's mail to me but github says no account exists with it same for qt@ wtf what about his gmail/other account? whats the problem? so I don't know wtf is going on there i sent a recovery to his gmail account and it worked but yngwin says that account doesn't have the qting-edge repo johu: we've lost admin access to qting-edge repo on github we have two options wired: but we have gitorious?! hold on 1. contact github, tell them what happened, request access 2. delete the repo's contents, add a single readme file with instructions where to find the new one and there's always 3. screw it, just keep pushing there while we can 2! 2! 2! and move to gogo well, this is related to the migration to gogo tampakrap: we'll move anyway, but i'd like to be able to edit the freakin repo description and keep it synced for practical reasons i am trying to remember who/when that repor was created nah, just remove it so we're going to have the overlay in *3* different locations? was it before Ben? are you sure it did not existed before yngwin? hwoarang: ben says he created it, but every recovery attempt has failed exactly, move it in gogo and delete everything, we don't need them hmm pesa: why not? +1 for one repo gogo is still primary, but i like backups wired: local clones are backups say gogo goes offline for a few months because tampakrap screwed it :p ;p hwoarang: yes, but not available to everyone git is decentral, backup enough :) why not? i have root for a reason still you can push somewhere in case of an emergency if I can't screw it why have root then? lol pushing in 3 places is overkill yeah 3 is too much the truth is gitorious is enough unless we always push to gogo and then sync(cron?) the others as long as we have at least 2 have script cloning and pushing to others im happy ok look keep gitorious we're in the process of migrating everything to git.gentoo.org (flycatcher) which has anon servers synced, plus excellent backups per fs and per repo so, keeping an external repo is not needed imho tampakrap: external repo helps because of the interface i still like to have at least gitorious around pull requests etc and if something goes really wrong we can setup an alternate repo when needed and it is easy to give access to non-gentoo ppl it is easy for overlays as well people come on but i agree we can ditch github the overlays team is very rapid in requests hwoarang: if gogo becomes primary all access will be given there wired: ok. merge requests are still better through gitorious if we're going to keep a backup, I must say I prefer github interface see dilfridge used it once others may do as well in the future hwoarang: well then we shouldn't move to gogo i don't want to have to pull and push and pull and push to sync things hwoarang: github is even better imho one main repo, one slave pesa: yeah but no admin account on that one ) hwoarang: i think we can fix that issue wired: no reason to do that. when you push it will sync repos automatically if your remotes are set correctly hwoarang: no it won't if you push to a secondary it'll be messy it will probably appear as a merge branch but still you have them in sync try push something only in github now then in another clone try syncing hell this only violates history yeah it's a mess if someone forgots to push to both repos ok, move to gogo and end of story? *forgets pesa: its not if they forget, its if they cant because they don't have access tampakrap: will we have merge requests in gogo? wired: then maybe use gogo and use a linode to sync repos is not that hard wired: ah that's even more serious then do you use them? hwoarang: no thanks, still messy tampakrap: rarely but yes i can set up a reviewboard for you, but if you use it i presume you can use the kernel way but pulling and merging directly from your console no need for an interface then s/but/by hwoarang: but pulling from where? i mean, how will guests make public clones? anonymous and send email patches wired: using github/gitorious :p this discussion is taking too much for no reason imho, sorry, gx86 needs those features, qting-edge doesn't again imho then can use their account to setup a public clone. it's free :p this is a very marginal issue imho, we don't have many external contributors ok ok tampakrap++ so who cares about github? votes me i'd like control as well gogo join overlays team then!! me again (gogo+github) alright, i'll send an email to github to try to reclaim the account and we can revisit the issue agreed? sure lets move on to serious stuff great qt 4.8 so, i fixed a few things yesterday the hilight was the eselect-qtgraphicssystem module did you guys have a look at it? i did o.O yes, it is awesome, thank you very much you can add my name on Reviewed-by:! heh what does it do? yw, i had fun writing it and i finally know how eselect modules work how can we make it to not require logout/login? i will have a look tomorrow pesa: short desc: or, why does it require logout/login? qt modules that provide graphics systems touch files in /usr/share/qt4/graphicssystems the eselect module reads the available systems from that folder and creates /etc/env.d/44qt4-graphicssystem containing QT_GRAPHICSSYSTEM="${SELECTED_GRAPHICS_SYSTEM_HERE}" eselect qtgraphicssystem list gives you the available systems, set [system] applies it you have to logout because your active shell doesn't have the new variable hwoarang: ^^ err what if you use env-update && source /etc/profile the next shell will have it? right your launcher is the issue you mean the parent of your X ? new shells will have the new var hmm i see i mean whatever is launching your apps wired: ok thanks for the explanation ok it makes sense then what's the default graphicssystem? raster raster to follow upstream makes sense and alternatives are opengl and what? native, raster openvg opengl and openvg (both suck and crash atm) ah native is still there then yes and the QT_GRAPHICSSYSTEM var is the only way to set it it's gone from configure wired: have you tested opengl? yeah I noticed that i remember back in 4.7 opengl did not work due to linking problems hwoarang: crashes on my hw. but i think openvg worked they try tho so qt-gui install both raster and native, qt-opengl installs opengl and qt-openvg installs openvg, yes? yes no USE flags right? fury wired ~ $ ls /usr/share/qt4/graphicssystems/ native opengl openvg raster no use flags, raster use is gone, qt-gui depends on the eselect module solution sounds good source for the eselect module is in gitorious nice released v1.0 in qting-edge! ^_^ good work! thanks a lot good job wired: one beer from me at fosdem each day thanks xD for each graphicssystem lol so, are you coming? hehe almost yes ;p o/ anyone else coming? nope :/ nah :/ lol :*( meh i also fixed bug 363939 wired: https://bugs.gentoo.org/363939 "x11-libs/qt-gui-4.7.2: Qt Designer segfaults at startup in QRegion::~QRegion() () from /usr/lib64/qt4/libQtGui.so.4"; Gentoo Linux, Development; CONF; sbar.geek:qt in qt 4.8 is it ready to move to tree? and the cairo in qting-edge works fine, not sure if it's in the tree yet (i think it's not), we should move it I asked likewhoa to create a new dvd for me for a kde release party I plan to do here yeah we definitely should and I'd like to have 4.8 I think it's ready someone said there's a patched cairo in x11 overlay too... does it carry the same patch? no idea first comes first served mmm I'll check either way, it's important that we move cairo to the tree maybe even release a news item about it may I have an ETA (and a name so I can ping him :P) ? iirc some people had to rebuild some things to fix the issue, hwoarang you had some issues? I need to let likewhoa know i have to rebuild pango iirc have to find a box with 4.7 and check again i can move 4.8 this weekend unles someone else wants to do it i have to check whether the scripts still work are we moving qt-openvg too? is there a reason not to? -*- pesa never tested it pesa: i'd say yes it works well, it builds ;p worked here too ok great then maybe it is also time to clean up some arches? btw I also removed the qt-opengl[-egl] restriction for 4.8 in PyQt4, it builds haven't tested if you dropped any keywords dilfridge: ^^ we are about to move Qt 4.8 in tree i haven't touched keywords in tree? ok well *oh well before we move to the arches issue, let's finish with the 3rd point: qpa useflag it seems quite experimental in 4.8 there is a big fat warning isn't it? raster was experimental and we kept it no matter what :) tbh yeah true but still... i'd like to mask qpa and c++0x qt-webkit has -fpermissive with c++0x enabled just to build oh! (either that or you patch it to... well... disable c++0x :p) uhm... i thought c++0x support was a 4.8 feature! o.O yeah right well everything builds fine except from qt-webkit afair disable it for qt-webkit only? that thing needs major patching before it'll build with c++0x i don't think you can disable it per module you can the generated code will be rather fragile but the results well hm crap yeah, fragile is a good word they're different libraries what if they both link to the same app :p who cares there are also inter-lib dependencies you can't mix and match flags well, with -fpermissive the thing builds it's the same as having QtCore with c++0x support and glibc without and an app linking to both one relatively simple solution would be to remove the inner-module c++0x use deps for qt-webkit and use mask c++0x only for qt-webkit that way we can avoid -fpermissive maybe we can wait for 4.8.1? if qt-webkit is the only problem they will likely fix it didn't seem simple to me i don't say we fix it it's possible, but not sure the use deps should be [c++0x], not [c++0x=] oops sorry pesa: hm? I mean, [c++0x?], not [c++0x=] maybe "?" ok why? i wanted to enforce the same everywhere (at the time anyway, to ensure consistency among modules), hence the = because libraries not using c++0x shouldn't force everything to build without c++0x support if they can work with different flags there is no need to enforce it pesa: so you're 100% sure no issues can arise from it? although this does not look safe to me well, not 100% me neither ;p libraries not compiles with c++0x may not be able to use symbols compiled with c++0x i am not sure how compatible these standards are hwoarang: i doubt that i've no idea think of all the qt consumers the only problem could come from header-only template classes but I do fear there may be corner cases it seems rather dangerous to me i'd suggest to postpone that and release 4.8 as it *as is ok we can play it safe and keep the = either mask it all together or leave it as is ok so lets sum up mask qpa? go for it +1 +1 +1 yep great wrt to c++0x leave as is OR leave as is mask c++0x for qt-webkit (adjusting deps to allow it) leave others as is OR just mask the use flag mask it altogether we will some more testing during time better safe than sorry :) ack yeah hwoarang convinced me tbh all three solutions are fine for me I believe to leave as is, things are moving forward in Qt-land imho ok so we'll mask it for 4.8.0 and see how it goes yeah, we will unmask them later ok great we keep the current keywords in qt 48? any reason to cleanup them? i am not sure about ppc* and sparc. Can we drop them and I will request a rekeyword plz? :p u sure that won't take 2 years? :p either way it is better for us maybe leaving them keyworded and letting kde people do the testing would be better ;p lol either we remove them (finally!) or they try to keep up hmm ppc is special story well the issue is that upstream doesn't care i dont know why should we :) I am not sure if anyone builds Qt in these arches. If they do, it will be easy to rekeyword it what are the actively supported archs for qt 4.8? x86/64 arm ... x86, amd64 and arm i guess wait that would be my guess too^ http://developer.qt.nokia.com/doc/qt-4.8/supported-platforms.html of course symbian means arm what a load of fail ;p also, looking at the code, it looks like mips is supported meh :/ great, so only ubuntu is supported mips has not stable keywords lets drop qt ;p so it wont slow us down in any way yeah lol hwoarang: indeed well then one solution a bit extreme but interesting would be to drop keywords for anything but amd64 x86 arm and prefixes in 4.8 and force everyone to retest arches would hunt us down and kill us tho ;p no way tampakrap will kill us :) the configure has support for ppc{,64} too kde folks will start screaming i don't care much actually, sorry :) hwoarang: we would make a party if ppc goes away from kde as soon as kde works, drop every minor arch, i don't care well, sparc ia64 alpha and hppa are "easy" to drop, right? no kdelibs there alpha ia64 are gone already i don't seem them in keywords i think sparc too sparc is there wat? yeah sorry alpha stopped at 4.6.x ah sorry yeah ia64 and sparc can go away hppa and ia64 have ~keywords in 4.7.x tampakrap: tickets booked and there's -sparc exactly, there's an ancient bug with qt-webkit crashing yep put this on a vote? and deal with it? so the question is what to do for ia64 and hppa? hppa(jer) is active he should be able to test it rather quickly im leaning on keeping everything keyworded let the users short it out instead of the arches if there are any users tbh tbh ia64 is not exactly a desktop machine :P yeah it doesn't make much sense :p qt-core is useful on servers think quassel core do we have stable keywords for them? if we don't, let's keep it that way hah you have a point http://znurt.org/search.php?search=&q=qt-core&x=0&y=0 tampakrap: yes we do drop stable keywords then? 4.6 is stable everywhere ok, drop it? ;) tampakrap: at some point we'll have to force new stable versions everywhere and 4.6 will have to go no hurry imho but just dropping stable without replacement i don't like that (at least yet) let's keep 4.6 for them (they aren't stabilizing 4.7 anyway) exactly, announce that we won't support stable for those arches any more and stop ask stabilization request for them any more if they dont stabilize 4.7 what is the point of having them even in ~testing? it clearly does not work for them tampakrap: that means you have to de-stabilize all qt consumers let 46 as is for now agreed *4.6 +1 +1 but it seems a bit pointless to keep pretending we support these arches let keywords in 4.8 as they are now, consider their future if/when bugs pop out +1 so it might work removing them in 4.8 i dont know ok hwoarang: i say give them a test drive with 4.8.0 again, let's keep them in testing we'll see what happens fine ok, are we going to keep asking for stabilizations too? well 4.8.0 is not getting stabilized so thats not an issue atm ;p i know but well... the 4.7.2 stabilization bug is still open for them pesa: we can always try and hope ;p and we're at 4.7.4 :P true, true then again i still have a stable bug for tmux 1.5 open because of ppc iirc if they decide to not stabilize 4.7.X we can drop them from 4.8 ok so we postpone the decision on this matter +1 +1 kk but can we drop -sparc at least? does it make sense to keep -sparc in 4.8? +1 i like that, yeah lets drop it drop excellent let's move on awesome or should i say, i3 :P so, gogo migration, we talked about it enough me thinks, but there is one interesting thing we still need to vote on date? announcement? do we want gogo as primary or gitorious/github? we didn't really settle on that yes i trust tampakrap gogo primary WE WANT GENTOO INFRA AS PRIMARY OF COURSE!! omfg that was easy where is Robin? heh "qt" as repo name please but I also want a bot in #-commits :D all gogo repos have yeah me too, i like how it works now ;p plus gentooo-commits ml i flood commits with qting-edge crap f*** yeah ok gogo it is mmm are we changing the name too? now qting-edge VS qt ok wtf qt! johu's suggestion was intruiging *oh qting-edge +1 i don't care needs to be in sync git gitorious/github why? otherwise ppl will get confused hmmm i like qt they think they are two different repos it says... qt qting is not qt repo name != layman list name true we have used qting-edge in blogs/forums/etc repo_name = qt ppl are familiar with it hwoarang: perhaps I can announce it, that's not an issue but anyway, I don't care much :P layman can't handle the url change right? users will have to -d and -a? I don't care either, provided we keep consistency for some definition of consistenct *cy it is not consistent to use a backup(github/gitorious) repo with different name. so qting-edge +1 from me. feel free to vote :p we can rename that too? :P how? :p no account remember ok, let's drop it then :) as discussed earlier as tampakrap said drop it :D github will die if we don't get access we agreed to rescue the admin rights 0006 and still in my car awesome enjoy it well my laptop has 4h battery left ;p so...? so i can be here all night lol no lol i was talking about the name :P hehe truth is I'd like to change it but it'd be a fuss not really, I'll handle it hwoarang wants qting-edge, tampakrap and I don't care, johu wants qt :p good summary wired is unsure yes, just make up your mind as a leader qt++ then meh! wth ok, that task is mine I'll do it during the weekend woot on sunday more specifically hmm can we just simply change the uri= on .git/ and keep using the same repo? or do we need to clone from scratch? tampakrap: will you announce the migration too? you should be able to continue using it we can change the refs there is a command assuming tampakrap pushes the current one in gogo easy one, did it for a university gitolite migration to new server in the past to keep history as well please let us know what we need to do once you set everything up like how to migrate existing repos to new uri etc i will, i'll write announcement ok thx thanks thx tampakrap: i assume you're going to push the gitorious master into gogo right? yes when will that happen? I need ACL do you have it? ETA master admin? you can drop any branches btw as I said, sunday so changing .git/config should be enough ok there is a update-refs something command anyway, ACL? hmm see gitorious i dont think we have no-qt members with +w access hold on ok https://gitorious.org/+gentoo-qt-devs https://gitorious.org/+gentoo-qt-devs/memberships ok thanks tampakrap: no, thank you :) but my original question remains: ETA and guy responsible for Qt 4.8 migration please? I need it really asap for the livedvd i said I can do it! i can do it tomorrow night / saturday morning ok wired :P ok thanks lol cairo first ofcourse : :) dont forge the masked flags ;) *forget :p nah, no forging needed ;p xD lol so i dont need an access for gitorious i will just wait for gogo indeed yep tampakrap: don't forget to add kensington as well kk minions.... er... contributors need access ;) and it seems he likes patches ;p he knows his way around, and he already started the quizzes seems like a good catch yeah he's very active -*- johu has asked him :) excellent ok how are you people on time? wired: should we move the eselect module to gogo? :p kiddin hwoarang: why not it'd make tampakrap happy ;p :) tampakrap: feel free to create a repo for it if you want (it's just one commit for now anyway ;p) ok, open bugs? yes please kk "the qdoc3 ran for a few days" rotfl poor guy thats bug 398885 wired: https://bugs.gentoo.org/398885 "x11-libs/qt-assistant-4.7.4 qdoc3 broken on arm"; Gentoo Linux, Applications; CONF; maekke:qt no idea on that one google doesn't help no arm to test :-/ and it's blocking stabilization :/ meh a kvm could be helpful with this, but that takes time if arm is supported maybe send this upstream? we could ask him if it works when building manually ah yeah good question we should include a configure command to make sure he tries the proper build who'd like to leave a comment with that? I can do it awesome, thanks bug 394533 wired: https://bugs.gentoo.org/394533 "Libreoffice crashes in qt on exit"; Gentoo Linux, Ebuilds; CONF; scarabeus:qt we need someone with a fast machine to try opensuse patches :P please someone fix that, I have scarabeus every day telling me about this bug wait wait wait in person, and he is a soldier :P i can't reproduce this with latest libreoffice (3.5.0.1) and qt 4.7.4 maybe it fixed itself? hmm yep works fine right now well, leave a comment in the bug i will :) or even close as WORKSFORME (I looked at opensuse patches and I couldn't find anything that seemed related to the crash) i just left a comment ty yw bug 392433 wired: https://bugs.gentoo.org/392433 "x11-libs/qt-gui-4.7.4-r1: desktop file name issues"; Gentoo Linux, Applications; UNCO; toralf.foerster:qt wth? ;p what is the problem? the names are generated by make_desktop_entry aesthetics :P yes they are indeed so he wants to change that function? just because we doesnt like the filename? but read my comment in the agenda no wait, that's not the issue The bug itself is invalid IMHO, but why are we passing absolute paths to make_desktop_entry? are absolute paths not allowed? eclass does not say so they are allowed but I don't see any reasons to do that well ok we can fix that on 4.8 and qt is the only package installed on my system that does that *in agree? i don't see why not please remember to fix it when you move 4.8 sure sweet ++ yeah, I can fix it in the overlay later probably pesa: that'd be nice, i'll try to remember to check it out as well bug 388551 wired: https://bugs.gentoo.org/388551 "x11-libs/qt-gui should depend on gnome-base/libgnomeui-2 when USE="gtkstyle" is enabled"; Gentoo Linux, Applications; UNCO; brad:qt hell no lol ;p i'll handle that bug ;p my comment was: Do we want to add that as an optional PDEPEND controlled by gnome USE flag? What about gnome 3? well the bug is semi-invalid qt upstream sucks here because they used obsolete libraries it's actually much simpler you have to set GTK2_RC_FILES=/home/wired/.gtkrc-2.0 and it works without libgnomesucksui i know because i use it ;p what if my user is not called wired? sweet tampakrap: i leave that for you to solve ;) :( tampakrap: rename your user lol ok so no dep (woot) what we could do is add a elog message in qt-gui[gtkstyle] saying that for things to work you either need libgnomeui or that variable set properly in your env + kk but notice user dont read elogs :P johu: i know heck, devs don't read them either best example xorg update oh i love that update everyone keeps breaking evdev xD well that's their problem yeah elog and we are finished with this bug seems johu wants to tackle this one :P as soon gogo repo is up heh it's not important either way sure i'll probably do it then when adding 4.8 if I don't forget or we can just give johu access to gitorious ^_^ heheh j/k bug 382559 wired: https://bugs.gentoo.org/382559 "qt4-build.eclass: qt_mkspecs_dir() returns bad spec directory"; Gentoo Linux, Library; CONF; oas:qt johu: you can add the elog to 4.7.x in portage too pesa: yes but normally i want do this complete ok :) pesa: i have no idea why we use libdir afaik there is no reason to use LIBDIR there "BTW why do we use $LIBDIR instead of get_libdir() ?" it is probably a leftover from the old days that's what I thought too maybe because it's easier to cut "lib" out ? ;p i will have a look on that get_libdir() is the "standard" interface for multilib after 4.8 hits portage. Will change it to get_libdir() and see what happens but there might be other useful functions hwoarang: please test locally before applying to portage, since it'd be a global change try rebuilding some qt apps too yeah that's my plan so it may take a while it should be safe anyway those lines look suspicius to me tbh if libdir was /usr/lib64 it'd try to remove /usr/64? :p uhm no... LIBDIR is "lib64" right, so it tries to remove 64? remove? oh no didn't read it right it adds -64 yep ok as far as the bug itself is concerned... close as invalid? worksforme? yeah worksforme seems ok fair enough well, if we do change the eclass, it should be fixed no? something is his box overrides the default env so it may fix it or it may not ok well, his env is totally fscked up so I don't know what may happen make sure you point out that it's his fault and should find out why his env is screwed sure thanks yw the last one bug 359391 wired: https://bugs.gentoo.org/359391 "qt4-build.eclass should check for --buildpkgonly before downgrade sanity check"; Gentoo Linux, Eclasses and Profiles; CONF; konovalov.alexey:qt we discussed this some time ago the conclusion was: this is pointless since even if he manages to build qt-core, he won’t be able to build any other modules. we decided to ask the reporter what he wants to accomplish before taking action. we did awesome work then ;p yeah rotfl RESOLVED NEEDINFO :) afaik yeah, and actually ask him what he wants to do the only wait to downgrade is to remove Qt altogether and merge again zomg it's been a year ;p agreed, i don't like it it is pretty much the same like rebuilding it so you can write that as a comment we already try really hard to avoid all that's dangerous for users, i don't like allowing new ways of fail no i mean, tell him to remove everything and merge whatever binpkg he wants he should be ok and i agree ahok mmm true even simpler who'll do it? so invalid? i can do it WONTFIX id say ok +! +1 lol +1 offtopic: project page, is there a alphabetical order? ot: wired: mind if i remove ayoy and chiiph from qt alias? johu: i think so go ahead hwoarang: ^ kk johu: with wired at the top since he's the boss hwoarang: you sucked with your command :P tampakrap: add kensington to qt@ command/commit ah you failed to sync lol hrhr yes next up: next meeting lets set it now, otherwise we'll get lost for a year again qt 5 is comming closer oh that reminds me crap lol spring first beta I'd like someone to sync the live ebuilds with 4.8.0 PLEASE xD sync with what april/may you know live ebuilds are my babys i will do it hwoarang: the live ebuilds are so outdated - {Tageswechsel: Fr. Jan 27 00:00:00 2012} i'm wondering how they still work seriously ;p yet they do i just build 8.9999 2 weeks ago please diff them with 4.8.0 and carry any fixes you find kk (you'll find a lot) thank you yeah they're severely out-of-sync meeting then and update to eapi4 :) i had to redo the last two major qt version bumps because they were based on live ebuilds and all kinds of stuff was missing (like prefix changes) eapi 4 is also an important topic does qt4-build support eapi 4? who'd like to give that a look pesa: it should why not dunno, just asking pesa: i don't think anyone has ever tried, but i have a feeling it should work almost ouf of the box yeah it uses pure EAPI2 features so it should be just fine i will look into it s/ouf/out/ along with the LIBDIR stuff awesome ok hwoarang: if you do it together with the live ebuilds we can use them in the next bump hopefully yes :) that would be nice next meeting: Thursday, 23th of February, 2000 UTC? it should be ok... dunno tbh yes from my side I'm moving to LA at the end of february so I really dunno woa nice :) yep :D w00t for how long? what for?! yes tell us 1 year, research collaborator at UCLA woa nice again :) network lab ah nifty ! seeing bits flying around lets set that date now to have something concrete and we can re-arrange if the need arises have fun! I'll be working on wireless vehicular networks wired: sure, I'll let you know goodie awesome one last thing who wants to do the summary? xD me and johu LOL rotfl weekend as well etherpad session excellent thanks thank you guys was really bored to do it xD so thank you all for being here can we go to bed now? really productive meeting hehe :P (rare occasion) no, we have a hangout, join us :p i am under my bed covers ready to watch House! ftw rotfl im 11km away from my bed covers time to get there :P i am in the bed and i dont think my gf wants that i wake her up say hi for us :P :D johu * gentoo/xml/htdocs/proj/en/desktop/qt/index.xml: add myself to project \o/ fuck yeah welcome to the qlub cute oh, just FYI, I'm having a look at qt5 lately... does it work? no lol :P excellent pesa: talk with kokeroulis, he is writing patches for qt upstream uhm great it have to work, kde frameworks will need it that implies that kde works bright future I'm still trying to write an initial qt5-build.eclass don't misinform people like that ;p although I don't have much time :/ pesa: a clean eclass for qt5, that would be nice :) I'll push to $our_new_overlay when I have something that works no-one has time, i stole some work time to make that eselect module ;p wired: indeed we're still months away from a 5.0 release anyway 3 month probably I believe they want to release this summer first beta as i know the feature freeze is soon yes meeting end? a while back hehehe need my drug night night then thank you all :) thank you! gn ;) gn gn