path: root/meeting-logs/20120517.txt

<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