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

[Johannes Huber (johu)]

johu        12/01/29 14:55:23

  Added:                qt-project-meeting-20120126.txt
  Log:
  Add meeting log 2012-01-26

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

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

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