Meeting log 2012/05/17.

1 files changed, 324 insertions, 0 deletions

diff --git a/meeting-logs/kde-project-meeting-log-20120517.txt b/meeting-logs/kde-project-meeting-log-20120517.txt
new file mode 100644
index 0000000..6a87757
--- /dev/null
+++ b/meeting-logs/kde-project-meeting-log-20120517.txt
@@ -0,0 +1,324 @@
+<kensington> 1. roll call
+<kensington> !herd kde
+<willikins> (kde) abcd, alexxy, creffett, dilfridge, jmbsvicetto, johu, kensington, mschiff, patrick, reavertm, scarabeus, tampakrap, thev00d00
+-*- johu is here
+-*- dilfridge here
+-*- creffett is somewhere around here
+-*- kensington of course
+<kensington> 2. Add LINGUAS support to cmake-utils.eclass
+<alexxy> kensington: looks like itterative process which should coverage
+<dilfridge> hehe
+-*- alexxy here
+<kensington> :P
+<dilfridge> err there's one more part for 1. :)
+<dilfridge> first of all a big welcome for our new team members kensington and creffet :D
+-*- creffett waves
+-*- johu applaudss
+<dilfridge> ok that was it from me :D
+<johu> kensington: what would your linguas implementation cover?
+<creffett> kensington, how did you forget to add "make everyone congratulate us" to the agenda?
+<kensington> creffett: I wrote that before we finished recruiting, so that's my excuse :P
+<kensington> basically, just copy straight out of qt4-r2, so need to stick an ugly loop adding linguas_X in packages that need them
+<kensington> *no need
+<kensington> for x in ${LANGS}; do
+<kensington>         IUSE+=" linguas_${x}"
+<kensington> done
+<johu> hm ok would reduce some ebuild code
+<kensington> any objectsion to that?
+<johu> is there an standard handling for the linguas handling planed?
+<dilfridge> no idea
+<kensington> it would be nice, but I do not know of any
+<dilfridge> but the code looks everywhere the same
+<dilfridge> just use a "safely unique" variable name for x and unset it afterwards again
+<kensington> do we need to send to -dev about it too?
+<johu> i have no objections
+<creffett> no objections
+<dilfridge> no objections... hic...
+<kensington> 3. Live KDE ebuilds are unconditionally test restricted
+<alexxy> btw may be we can write generic linguas.eclass?
+<johu> kensington: but gentoo-dev can not hurt
+<johu> alexxy: there was already a discussion about that on -dev?!
+<dilfridge> alexxy: nice idea but that needs to be bikeshedded on -dev
+<kensington> generic eclass would be nice, but I don't know if there's much beyond those three lines that are portable between build systems / packages ?
+<alexxy> johu: yep it was about a year ago
+<dilfridge> probably not.
+<dilfridge> ah ok, dont remember
+<creffett> re 3: I say leave them as restricted, because we have enough trouble already with the official release tests
+<dilfridge> well... anyway. I think whoever runs live kde with tests seriously needs some disruptions.
+<kensington> :D
+<dilfridge> but, from a practical point of view, creffett is right
+<alexxy> he he
+<alexxy> i use 9999 on my laptop
+<alexxy> but i didnt enabled tests =D
+<johu> i would say enable them with the magic var!
+<johu> its not a bug deal
+<dilfridge> I_REALLY_REALLY_KNOW_WHAT_I_AM_DOING
+<johu> big
+<creffett> haha
+<kensington> dilfridge: I like that idea :P
+<johu> ynauv
+<johu> yet not another useless variable^
+<dilfridge> how about we just add it to the usual I_KNOW_WHAT_I_AM_DOING ?
+<dilfridge> who sets this should be able to handle the fallout
+<johu> test enable on  I_KNOW_WHAT_I_AM_DOING
+<alexxy> dilfridge: better to use YEP_I_REALY_REALY_SURE_THAT_I_WANT_BIG_HEADACHE
+<dilfridge> ... AND_I_PROMISE_TO_NEVER_EVER_FILE_BUGS
+<johu> can we become serious? :)
+<dilfridge> Yessir. :)
+<reavertm> I_KNOW_WHAT_I_AM_DOING___SERIOUSLY
+<johu> <johu> test enable on  I_KNOW_WHAT_I_AM_DOING
+<dilfridge> agreed
+<kensington> I agree with johu
+<alexxy> +1
+<reavertm> sounds fine, +1
+<johu> reavertm nice to see you sir
+<johu> :)
+<kensington> 4. KDE 4.8 stabilization and powerpc
+<johu> ok thats my topic
+<johu> i added it because gcc47 was dep to keyword it
+<reavertm> elaborate on it please :)
+<johu> but JoseJX told me some hours ago that he will keyword it tonight
+<johu> it was a mistake with gcc47
+<dilfridge> cool
+<johu> but they need qt 481
+<johu> i think b) can be seen as obsolote
+<JoseJX> Hey
+<dilfridge> ok sounds good
+<JoseJX> I'm the PowerPC rep I guess
+<dilfridge> hey JoseJX :)
+<johu> but we should discuss if ppc64 make sense
+<JoseJX> I'd really like to not drop keywords if possible
+<johu> JoseJX: whats your opinion about that?
+<JoseJX> KDE still runs well on my G5
+<JoseJX> I can see the argument for dropping ppc64 from stable, but keeping unstable, since we don't really have the manpower to handle it.
+<JoseJX> There's also the fact that most of our users are not running ppc64, even on ppc64 machines
+<JoseJX> Most are set up with a 32bit userland (the ppc keyword)
+<dilfridge> I think that already happened some time ago, at the moment we only have stable "amd64 ppc x86"
+<johu> scarabeus said that ppc64 are serve machines
+<JoseJX> dilfridge: I think that's reasonable
+<dilfridge> but if the gcc-4.7 problem is gone, we should try to keep things as they are (ppc ~ppc64)
+<JoseJX> That's what I'm aiming for now
+<JoseJX> ppc/~ppc are definitely fine
+<johu> but makes ppc64 realy sense?
+<JoseJX> I'm still working on testing ~ppc64
+<johu> thats the first question we should find a answer
+<JoseJX> I do know that we might have some TOC issues, which might make this all moot anyway on ppc64
+<JoseJX> But those will be fixed when gcc-4.7/4.8 is ready
+<dilfridge> is there any ~1line summary for that? /me does not have a clue
+<JoseJX> I'll try to explain
+<JoseJX> ELF on ppc builds tables of function calls, but on ppc64, the tables get too big and the TOC runs out of space because the pointers are 2x bigger.
+<johu> but gcc-4.7 stable will hapen maybe 2013...
+<JoseJX> Basically linking > 32MB (I think that's the size) doesn't work on ppc64 because the jumps are too big
+<JoseJX> We can work around it with --minimal-toc and that's what we have been doing.
+<JoseJX> That's the short version
+<johu> JoseJX: are there lot of desktop systems with ppc64? 
+<dilfridge> ok... what's the problem with (for kde) global --minimal-toc ?
+<JoseJX> dilfridge: None that I'm aware, but ranger would be the better one to ask.
+<dilfridge> ok
+<JoseJX> johu: Honestly? No.
+<JoseJX> johu: I run it on my G5, but I'm sure I'm an edge case
+<johu> ok, makes no sense to me to keep ppc64 then
+<dilfridge> johu: but ~ppc64 is not really a problem...
+<JoseJX> I think that's where I'm at too
+<dilfridge> anyone else has an opinion?
+<JoseJX> I agree there's no need for stable keywords, but if possible, I'd like to keep the unstable ones.
+<johu> ok please vote on keep ~ppc64:
+<johu> -1
+<dilfridge> +1
+<alexxy> 0
+<kensington> 0
+<alexxy> or keep ~ppc64
+<alexxy> i dont currently have any ppc hw
+<creffett> 0
+<alexxy> so i cannot test
+<johu> meh
+<johu> seems we cant find a decision here so lets keep it...
+<JoseJX> Well, how about this. If everything is working when I do the ~ppc keywording later today, I'll also mark ~ppc64. If not, I'll let it drop.
+<kensington> +1
+<dilfridge> +1
+<johu> i will raise this issue again for sure ;)
+<alexxy> +1
+<alexxy> =D
+<reavertm> why not, +1
+<JoseJX> johu: That's fair. I don't see what dropping unstable keywords helps with though?
+<johu> JoseJX: because server systems != desktop systems
+<dilfridge> I've tried already to build a ppc/ppc64 qemu chroot but right now this fails because of a qemu-static bug
+<johu> and KDE is for sure a desktop/tablet env
+<JoseJX> johu: Only new ppc64 machines are server systems, but in the past, we had the PS3/G5 both which definitely were not server systems
+-*- dilfridge thinks mips tablet and runs fast...
+<creffett> did someone say mips? :D
+-*- creffett hands dilfridge a cobalt raq2
+<kensington> keywords all the archs!
+<johu> JoseJX: ok i think you can do your job tonight ;)
+<johu> JoseJX: and big thanks for that
+<JoseJX> Okay! Thanks guys. I have to get back to work, but I'll probably be doing the keywording around midnight EST.
+<JoseJX> Just for a heads up!
+<johu> JoseJX: if the work load is to big to stable 483 you can wait for 484
+<JoseJX> johu: No worries
+<JoseJX> When is 4.8.4 expected?
+<JoseJX> Would it be better for us to wait?
+<johu> 484 is tagged end may
+<dilfridge> it's always one month later
+<JoseJX> In either case, we need to go forward with the unstable keywords first, so that won't change
+<johu> so we will start with stable mid june
+<dilfridge> makes sense
+<JoseJX> Okay, we'll probably target 4.8.4 for stable on ppc then, figure one month in unstable gets us to June anyway
+<dilfridge> yes
+<JoseJX> As long as that's fine with you guys
+<johu> its totally finee
+<dilfridge> sure
+<JoseJX> Great!
+<kensington> :)
+<johu> JoseJX: thanks for being here
+<johu> kensington: procede pls
+<JoseJX> No worries, later!
+<kensington> 5. Bugs
+<kensington> bug #380899
+<willikins> kensington: https://bugs.gentoo.org/380899 "Trying to change full name in KDE System Settings results in error or crash"; Gentoo Linux, KDE; UNCO; gentoobugzilla:kde
+<kensington> there is a workaround that disables that feature from ubuntu, do we want to apply that? (looks like upstream doesn't care about the bug)
+<johu> kensington: i saw a other solution, fallback to nickname on reviewboard
+<johu> kensington: you have good connections to upstream try to talk to them
+<kensington> johu: if we are thinking of the same patch, it didn't work
+<kensington> still crashed
+<dilfridge> hmm
+<dilfridge> seems like the feature does not work, why not disable it
+<dilfridge> I suspect once the code is fixed our patch will not apply anymore and we will notice
+<johu> https://git.reviewboard.kde.org/r/104965/
+<johu> kensington: this one?^
+<kensington> johu: no, I was thinking of a different one, sorry
+<dilfridge> does that really fix the same problem?
+<johu> i am not realy sure
+-*- dilfridge confused
+<kensington> I don't think so, the issue from the bug is systemsettings hangs because it can't talk with chfn properly
+<johu> i would suggest try to talk to upstream and if you get no good answer or proper response disable it
+<kensington> +1
+<johu> say 2 weeks time limit
+<dilfridge> ok who's going to do it?
+<kensington> ok I will
+<johu> ok next pls
+<kensington> bug #410347
+<willikins> kensington: https://bugs.gentoo.org/410347 "app-cdr/k3b: use media-libs/musicbrainz:3 instead of :1"; Gentoo Linux, Applications; CONF; pacho:kde
+<dilfridge> reavertm: you probably know more about this one
+<creffett> we can probably just drop musicbrainz altogether
+<reavertm> last time I checked there was no musicbrainz:3 support at all in k3b (but it was long time ago)
+<dilfridge> well k3b has not changed much lately
+<creffett> mhm, that's what the comments on the bug indicate
+<reavertm> (I mean, there's api difference between those two)
+<kensington> I agree with creffett, I couldn't find any evidence that musicbrainz is actually being used anymore
+<dilfridge> in gentoo terms k3b would be maintainer-needed
+<johu> :1 is obsolete
+<johu> drop it
+<dilfridge> ack
+<kensington> bug #405181
+<willikins> kensington: https://bugs.gentoo.org/405181 "dev-util/cmake: FindPythonLibs behaviour broken by Gentoo patches"; Gentoo Linux, KDE; CONF; gentoo-bug:kde
+<dilfridge> meh
+<johu> i hate it
+<dilfridge> the best way woudl be to
+<dilfridge> * remove the patches
+<dilfridge> * and force cmake onto a specific python version via commandline defines
+<dilfridge> that _should_ work
+<dilfridge> but I have not tried yet
+<kensington> sounds good, should we try that then?
+<dilfridge> yes, but no guarantees it'll work
+<kensington> bug #410139
+<willikins> kensington: https://bugs.gentoo.org/410139 "kde-misc/networkmanagement-0.9.0 and kde-misc/networkmanagement-0.8_p20110714 wrong doc dir specified"; Gentoo Linux, KDE; UNCO; gritoo:kde
+<johu> cant never reproduce this...
+<kensington> ditto
+<kensington> couldn't see how it might be run into, looking at the eclass :(
+-*- creffett guesses funny user settings
+<dilfridge> we could ask for the environment and the eclass debug log
+<johu> maybe it was fixed with the eclass changes that we introduced?
+<dilfridge> but I dont have any other ideas
+<dilfridge> (maybe funny variables in make.conf?)
+<dilfridge> ok I can try to take care of this one, it's obscure enough to be interesting
+<johu> RESOLVE NEEDINFO
+<dilfridge> hehe
+<kensington> bug #383733
+<willikins> kensington: https://bugs.gentoo.org/383733 "kde-misc/interceptor - KDE4 Plasmoid - intercept (catch) the log info from the syslog"; Gentoo Linux, Ebuilds; CONF; fitzadam:maintainer-wanted
+<creffett> this one's mine
+-*- johu dont need the package and have no interest in it :P
+<creffett> basically, it's a plasmoid that requires an init script and modifications to the system's syslog configuration
+<dilfridge> I also thinks it's overkill and potential security problem
+<creffett> and there's continuing trouble with using the FIFOs required
+<creffett> so, I suggest we resolve wontfix
+<dilfridge> but we could show it to recruiters as replacement for w...
+<kensington> haha
+<creffett> nah, it's not quite _that_ bad
+<johu> rating 65%
+<dilfridge> creffett: not talking about your ebuild, just about the general problem :D
+<kensington> wontfix, or just take us off cc and suggest sunrise?
+<dilfridge> latter
+<dilfridge> maybe someone will pick it up
+<kensington> bug #406353
+<willikins> kensington: https://bugs.gentoo.org/406353 "dev-util/cmake-2.8.6-r4 - stop Xvfb after failed test phase"; Gentoo Linux, KDE; UNCO; toralf.foerster:kde
+<dilfridge> good catch
+<kensington> if tests die, virtualx can't kill Xvfb it started
+<kensington> will be a problem too for virtualdbus (coming soon!)
+<johu> is there any phase we could use to clean it up?
+<dilfridge> i'm asking in #-portage
+<creffett> kensington: are you making any progress on virtualdbus?
+<creffett> I looked at it some, but couldn't figure out a way to make it work for bash commands
+<kensington> I had the same problem, but it seems to work by just exporting the appropriate envvars
+<creffett> oh?
+<creffett> I'll talk to you about it later, then, but I'd love to hear your progress
+<kensington> creffett: this is my work in progress http://dpaste.com/749504/ which is working reliably for the package I've been testing with, systemsettigns
+<creffett> cool, I'll have a look later
+<dilfridge> k
+<dilfridge> seems we might need some input from zmedico et al here
+<dilfridge> let's see if any of them responds
+<johu> next topic!
+<kensington> 5. open floor
+<johu> dilfridge: whats the arm state? You wanted to ask the guys
+<dilfridge> no really definite response yet
+<dilfridge> only people that replied did not have fast enough machine
+<johu> hm
+<dilfridge> (remember this is many gadgets and embedded stuff)
+<johu> ok postponed
+<kensington> my open floor is ^, I'll bring it up again when there's no more calls to ugly_hack()
+<dilfridge> hehe
+<kensington> anyone else?
+-*- dilfridge hears the silence
+<johu> yes
+<dilfridge> kde-4.9 beta is coming out soon
+<johu> kde 483 stable and the last outstanding bug
+<johu> the dav foo!
+<dilfridge> right
+<dilfridge> anyone has a dav-based calendar server?
+<johu> do we want to stable -r2 which have the upstream "fix" but no positive feedback or just use r0 which is fucked up for sure
+<dilfridge> -r2 in case of doubt imho
+<dilfridge> someone will be unhappy either way
+<kensington> some feedback on the upstream bug saying it's still not fixed, but it might be a different but similar bug
+<johu> yes i read this too
+<johu> the other people have different problems
+<kensington> +1 on -r2 then
+<johu> so if noone raise objections i give ago the go tomorrow after keywording ppc/ppc64 is done...
+<dilfridge> awesome
+<kensington> cool, anything else?
+-*- johu needs more beer
+<kensington> meeting over then :P
+<johu> organization question, who writes the  summary?
+<dilfridge> +1
+<dilfridge> always whoever asks first :D
+<johu> always johu i guess
+<johu> creffett: make a draft i review it!
+<dilfridge> next time creffett is chairing
+<dilfridge> :D
+<johu> dilfridge: if 7 days over i do it for sure on my own as last time with you lazy guy :P
+<creffett> dilfridge: out of contact at the time, sorry
+<dilfridge> hehe
+<dilfridge> creffett: ah yes have a great time, when does your trip start?
+<creffett> which reminds me: I'm disappearing from the 20th through june 15th
+<creffett> ^^
+<johu> creffett: set your devaway then please
+<creffett> I will
+<creffett> and I'll forward my gentoo mail to the email address I get to use on the boat which doesn't cost me money to use, but I won't be committing or anything
+<johu> enjoy your trip
+<creffett> I'll try
+<johu> and dont think about gentoo in this time
+<johu> we will save some bugs for you
+<creffett> thanks :P
+<kensington> s/save/make/
+<johu> 3
+<johu> 2
+<johu> 1
+<johu> end