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