diff options
| -rw-r--r-- | meeting-logs/kde-project-meeting-log-20120517.txt | 324 |
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 |