From 2b61447b5ef770a5de03db08efc16eb54bdc23eb Mon Sep 17 00:00:00 2001 From: Johannes Huber Date: Mon, 16 Jan 2012 22:07:21 +0000 Subject: Meeting log 2012/01/16 --- meeting-logs/kde-project-meeting-log-20120116.txt | 630 ++++++++++++++++++++++ 1 file changed, 630 insertions(+) create mode 100644 meeting-logs/kde-project-meeting-log-20120116.txt diff --git a/meeting-logs/kde-project-meeting-log-20120116.txt b/meeting-logs/kde-project-meeting-log-20120116.txt new file mode 100644 index 0000000..aa6bc0d --- /dev/null +++ b/meeting-logs/kde-project-meeting-log-20120116.txt @@ -0,0 +1,630 @@ + meeting starts now + roll call again please: alexxy / ABCD / jmbsvicetto / dilfridge / +johu / mschiff / Thev00d00 +-*- johu here + here +-*- alexxy here +-*- alexxy here again and again =D + here +-*- alexxy like quantum particle here and not here with non zero probability + first topic: elect new lead + nominations? +-*- johu nominates tampakrap + Do we really want to do it at this meeting? + raise your complain please + Nothing prevent us to anticipate the election, but that means +the 2011 term had only 11 months and that for the future the election will +happen before FOSDEM + we could vote whether we want to vote + or we could just vote by acclamation at fosdem :D + When dilfridge mentioned this topic at IRC, I got the impression +the point was to talk about the election, not to have it today + i dont care, maybe I just misunderstood + me dont care too + If no one has any reason to do it today, I'd have us wait 3 +weeks + lead is bad for your health anyway + ok, skipped for next meeting + you guys can pick Theo at FOSDEM and then we can do a mail tally +just to record it + hehe + he he + next topic +-*- alexxy seems like cannot participate fosdem this year + As in the past, I'll keep abstaining from kdepim issues :P + What shall we do with kdepim-4.4 (15 minutes) + * Discuss/vote: At the moment KDEpim-4.4 is still fully +functional, no known + regressions. Functionality of KDEpim-4.7 is slowly stabilizing, +with occasional + pains. Do we want to keep KDEpim-4.4 in the main tree? + dilfridge: yours + well... + I'm happy with how it is now + means, keep 4.4 for the moment, but also keep stabilizing newer +4.[78] versions + i dont care about kdepim 4.4 as long its work we can maintain it + right + at the moment it's zero work + to maintain it + it's just about giving people a choice + It's up to you, but if that's what you think, I see no reason to +change the status quo + if it's zero work, why remove it then? + a note from upstream they want to change migration to import ... + rumors + if this feature will come we can think about removing + hmm? + dilfridge: how about use kde-4.[78] kde-l10n for old kdepim-4.4? + you'll have to explain why... + to not keep separate kdepim-l10n + alexxy: this doesnt work as i know + it partly works, some translations are broken afterwards + alexxy: I don't think that'll work + alexxy: the l10n of kdepim-4.4 and kdepim-4.7 is not compatible + well then we should add kdepim-l10n to rdeps then + and its not much work to create the kdepim-l10n + ok =) + good + any additions? + then we should add kdepim-l10n to rdeps for all kdepim packages + final resolution: we keep it there, we'll have to create l10n +though + to make it pull kdepim-l10n + alexxy: wasn't there a kdepim-base package? + alexxy: that could be added there + sorry very late guys, reading backlog + Or did that become kdepimlibs? + kdepim-meta pulls kdepim-l10n with nls useflag + http://paste.pocoo.org/show/535829/ + same as kde-meta pulls kde-l10n with nls useflag + dilfridge: i have this flag + can we make that nls flag global in kde packages then? + and i dont have kdepim-l10n installed + ok + tampakrap: why make it a use flag for all packages? + i mean, global like semantic-desktop, put it in every kde package + alexxy: we'll sort this out + because i for example want only konsole and am an xfce user + tampakrap: I'd try to add it to a base package - like kdelibs +for non-pim packages + but i also want translations of konsole + or that, kdelibs is also acceptable + he he =) + +1 for tampakrap + alexxy: thanks :P + +1 from me + dilfridge / jmbsvicetto: nls in kdelibs, acceptable? + we could do the following: have the eclass add kde-l10n and if +needed kdepim-l10n to rdeps if any lingua is set + tampakrap: yes but that does not solve the kdepim-l10n problem + adding the rdep in the eclass is better + tampakrap: that's what I suggested :P + dilfridge: rdep via use flag + =) + =D + ok fine, add useflag to all kde packages: if "nls" is set, pull +*-l10n + dilfridge: Is there no base kdepim package that we could do the +same as in kdelibs? + no, unfortunately not + Please don't add it to all kde packages + Why do we want a use flag to all packages when all it does is +pull one dep? + kdepimlibs would be a candidate, but it's not really used by all +afaik + well + It would make sense to add it to all packages if the packages +tarballs add the l10n stuff and we could enable/disable for each package + kdepimlibs is separate from kdepim + err + sorry + libkdepim + yes, that works + Don't all kdepim packages depend on libkdepim? + so, kdelibs for kde-l10n and libkdepim for kdepim-l10n, +acceptable? + let's try that, yes. + s/add/had/ + tampakrap: yes + alexxy / johu ^^ + tampakrap: yep + good, i'll do it + excellent. + actually, i'll assign it to a non-dev to do it + :D + for practice + he he + for idella4? + anything else here? + he is very active + =) + no, i have a list of interested people, don't worry + he is indeed + =) + never mind + anything else here? + next topic: + 4. kdeenablefinal revisited (15 minutes) + * Discuss/vote: See last test run bug #353246. Should we +provide this + feature anymore? What is the purpose nowadays, in fact of +upstream keep + going split the huge packages (kde frameworks, kdepim)? +-*- johu had a kernel panic :-/ + dilfridge: ^^ yours again + not mine + no its mine + i want get rid of this mess + well, add your names next to the topic next time people + tampakrap: https://bugs.gentoo.org/353246 "[Tracker] +kdeenablefinal build failures"; Gentoo Linux, KDE; CONF; dilfridge:kde + tampakrap: last time we agreed to let it be as esigra was doing +all the work and we just left the bugs alone ;) + tampakrap: is it still works? + or do we still need this + upstream do not maintain it active + and it seams only one user uses it + most upstream devs don't even know about its existance + and i do not see the purpose + tampakrap: I still have no interest in it and won't shed any +tears if we drop it +-*- dilfridge does not care either way + but anyway, it doesn't make much sense that now most packages are +split in separate git repos + so lets kill it + =) + yes! + like we did for kdeprefix + =) + ok, do it + thanks +-*- Thev00d00 woops + hehe + anything else? +-*- dilfridge wants to close the bugs + ok will purge it tomorrow + and closes the bugs as well + next topic: + 5. phonon-xine removal (5 minutes) + * Discuss/vote: Upstream declared it as dead. Already masked +since 1. Dec + 2011. We have two other working and maintained backends. +Current open bugs + #359979, #397585. + who? + i + write your name next time or i'll come to germany and choke you + kill it =D + eofl + *rofl + is this still the latest? or are they resuming development since +xine-1.2 is out? + But yeah bitrot should be removed + dilfridge: I was going to ask about it + have a look at p.k.o + johu: did you ask any upstream devs about it? + dilfridge: the reason for the p. mask was that we thought it was +completely dead, but now it seems there are people working on t + it* + i'm not aware of anything official + tampakrap: it was announced as dead with kde 4.6.0 + johu: yes, but xine itself was considered to be dead. Now it +seems it might not be + jmbsvicetto: well, 3 commits in 12 months... + we have to ask in #phonon + I've moved to phonon-vlc a long time ago, so I have no direct +interest in xine/phonon-xine + dilfridge: hmm, that doesn't seem to active to me + * #phonon: Cannot join channel (+i) - you must be invited + in any case, I think we should make sure before we kill it + thats why we mask it + wait people + i'll ask apachelogger + if xine is still dead, then let's kill phonon-xine. Otherwise, +we can keep phonon-xine for a few more weeks / months to see if anything turns +out of it + i asked apacheloger, depending on the answer i get we'll act +accordingly + apacheloger = upstream phonon dev + acceptable? + yes + I also asked on #kde-multimedia, let's see + dilfridge: seems like #phonon is redirecting to #kde-multimedia + anything else here? + next: + 6. qt-4.8 (5 minutes) + * Short discussion about potential problems. + i updated to 4.8, everything seemed fine apart from kdenlive + no glitches, no compilation failures + ! + anyone here who updated with kde-4.7.x ? + i'll switch if it in tree + yes, i updated to qt 4.8 and kde 4.7.4 + I updated 3 machines, no problems at all with kde-4.8 beta/rc + kokeroulis: if you want to speak just do it + on Qt 4.8 there is an issue with the pointers + dilfridge: I'm just running ~arch these days + they are not killed + but updating a running kde-4.7.4 made all kde programs segfault in +oxygen style until I rebuilt kstyles + there is a post on plasma-devel ML + ok + let's see + johu: you could help us (qt) about it + wired should know better + and pesa + tampakrap: you can ask me to join the herd :P + i'll send you an invitation + kokeroulis: how serious is that issue? + and how much does it affect us? + I suggest we make two revs of kstyles-4.7, one requiring qt-4.7, +one requiring qt-4.8 ---> forces a rebuild, one problem solved + +1 + +1 + +1(external) + tampakrap: it seems a alot. Because some upstream devs has +mention that the KDE 4.8 should be shipped with Qt 4.8, so we will fix it +until the major upgrade of the binary distros. Otherwise all the binary distro +will ship KDE with this issue on their major version + dilfridge: how are you going to manage the revision numbers? + jmbsvicetto: by hand... -r0 & -r10 ... + I'll figure somethign out + it only requires talking to qt + just put one in overlay until 4.8 is out + exactly + and mask it together with qt-4.8 + dilfridge: sure, but I meant the numbers. So we can use 9 +revisions for kde-4.7. OK :) + kokeroulis: do you have a link to the ml post? + dilfridge: +http://mail.kde.org/pipermail/plasma-devel/2012-January/018493.html + ook +-*- dilfridge librarian mode + tampakrap: shall we move to RPATH ? + there are more about this conversation but the web archives have +some issue about that + dilfridge: i found it. +http://lists.kde.org/?t=132630064900003&r=1&w=2 + jmbsvicetto: dunno + anyway, is it so important to discuss it now? can we continue the +discussion in the mailing list or next meeting? +-*- wired is here :) + next meeting^ + tampakrap: wired: any plans to move qt-4.8 to the main tree (even +masked)? + wired: issues with qt 4.8? + dilfridge: unmasked, prolly sometime next week (near end), unless you +kde guys have any serious issues with it + heh + wired: no only kdenlive failed to build + that makes the priority a bit higher + mmmmmm qt-4.8-y goodness + wired: afaik no serious problems + it appeared to be a tiny fixable problem + at least I'm running it + I have not hit the problem yet that kokeroulis mentioned + wired: issues/tracker to help? + omg + it's starting + what? + tampakrap: hadn't had the time to do anything yet, no major issues +afaik, just opportunities to fix things :) + [21:55:23] ago * gentoo-x86/app-misc/strigi/ +(strigi-0.7.7.ebuild ChangeLog): + [21:55:23] Stable for amd64, wrt bug #396359 + [21:55:23] (Portage version: 2.1.10.41/cvs/Linux x86_64) + [21:55:26] CIA-4: https://bugs.gentoo.org/396359 "KDE +4.7.4 and dependencies stabilization"; Gentoo Linux, Keywording and +Stabilization; CONF; dilfridge:kde + https://bugs.gentoo.org/396359 "KDE 4.7.4 and dependencies +stabilization"; Gentoo Linux, Keywording and Stabilization; CONF; +dilfridge:kde + lololol + dilfridge: you will get a lot of highlights now + right. + wired: i have not used the Qt 4.8, so i don't know if there is +any big issue.... + ok good + kokeroulis: i've installed it on my two main workstations and it works +fine, however I don't have KDE anywhere ^) + anything else here or shall we move? + move + move it baby + wired: talk to me please before you bump qt + 7. Dropping RPATH from installed binaries (5 minutes) + * Short discussion- any objections to testing this in the +overlay eclasses and later + moving it to the main tree if it works? + dilfridge: sure, was planning to anyway :) + this is mine + we already removed the RPATH from qt libraries successfully + with no real benefit probablhy + ;p + it's possible because we add the qt library dir to /etc/ld.so.conf + whats the purpose? + well, all binaries built by qmake not also have no RPATH + dilfridge: I don't agree with dropping RPATH from binaries on +Linux + I'd say simplifying things + what can break? + we do not need two pointers to the lib dir + dilfridge: and by dropping it from the Qt eclass we were +supposely telling the linker to use what KDE defined - and not building +binaries with empty RPATH + dilfridge: just leave #gentoo-commits for a while :) + no, the plan was to get rid of the RPATH entirely + dilfridge: the issue is that binaries with empty RPATH have an +higher security sensitivity + err... why? + dilfridge: the reason we set the RPATH is to ensure that a user +is not able to "subvert" a legitimate binary by having it use libraries on a +exploited dir + dilfridge: if you have a binary A that uses library B and you +allow the user to specify the library dirs in which A should check for B, you +allow the user to add a "compromised" B library to a dir he controls and with +that you allow A to be compromised + dilfridge: at least that's my understanding. I might be wrong + LD_LIBRARY_PATH is ignored for setuid + and you could always copy a normal binary and set its RPATH + jmbsvicetto: with LDPATH and LD_LIBRARY_PATH i wonder if RPATH is +really preventing what you're talking about + wired: but LDPATH is controlled by root, right? + system files as well + dilfridge / wired: in any case, if you guys are not sure, I +think we should talk with the hardened team before dropping RPATH from +binaries + and with the prefix team probably :| + that has to happen before qt 48 goes to main tree + we should track down diego + I'll try to talk with Diego about it + ah, he's coming to fosdem + he's alive and kicking @twitter ^_^ + anything else? + I haven't caught him on jabber in a while :-\ + move? + move, decision postponed + 8. To eselect Boost or not to eselect boost (10 minutes) + We need to figure out what is actually the best desired +behaviour :| + who? + dev-zero + :] + newest info was that eselect goes away + see comments in the bug + we need to discuss this on the mailing list + but boost maintainers seem to prefer always building against +newest version + so lets talk to dev-zero and if this not help dev ml +-*- tampakrap is confused + ok now i get it + so move? + no move + at least not to tree + move to next topic i mean + yeah^ + * dev-util/cmake picks always the latest boost. + * Fix in overlay since 13. Dec. Move to tree? + https://bugs.gentoo.org/show_bug.cgi?id=335108 + I still think this should be moved to the gentoo-dev ml + tampakrap: this is the same^ + This is far more involving that just kde, and can affect any +package using cmake - like mysql-5.5 ;) + * cmake-utils.eclass PREFIX is not defined, any progress? + https://bugs.gentoo.org/show_bug.cgi?id=358059 + johu: raise the topic in the ml then? + tampakrap: seems that this my part + @boost + [22:14:00] dilfridge: pxine is dead + [22:14:09] no plans to revive + johu: the arguments from dev-zero about the use of boost should +also be discussed as boost should be compared to gcc, python, ruby, etc + dilfridge: so we can remove it + fine with me + johu: I think so, yes +-*- johu will do this + i will send a 10 days last rite + hey guys I am very sorry, I slept away two hours ago... :-/ + " * cmake-utils.eclass PREFIX is not defined, any progress?" + the last comment from this bug was that reavertm want to investigate, +but nothing happend + johu: use the usual 15 days, please + jmbsvicetto: its masked since start of dec + johu: otherwise someone will complain about it and we'll get in +an argument that will likely be less useful than just waiting 15 days ;) + johu: I know, but mask is not the same as last-rite and I +believe it's more productive to wait 5 more days than get in an argument for +not having followed policy + jmbsvicetto: fine with me + move to next? + see some lines above + the cmake PREFIX bug + johu: that one will require work with the prefix team, no? + jmbsvicetto: it would be good if reavertm were here + maybe he have infos about that + johu: That won't be easy as grobian is not a fan of cmake and it +does seem to have base flaws to support prefix + jmbsvicetto: not really afaik + that is not something related to "Gentoo prefix" + more like, cmake build magic + dilfridge: sorry, then I must be thinking at another bug + jmbsvicetto: yeah you think about the other cmake bug + the macosx request + ok, can we skip that then for next meeting? + reavertm is not here today + Ah, now I recall this bug + I still don't see what that patch actually fixes + That patch assumes prefix is defined and if it's empty it +doesn't add /usr + yes + I still think that patch is wrong + better still, that patch moves the definition of prefix to the +start and then does the same as it was doing before + so the only real change there is the following: + - SET (CMAKE_INSTALL_LIBDIR ${libdir} CACHE PATH +"Output directory for libraries") + + SET (CMAKE_INSTALL_LIBDIR ${PREFIX}/${libdir} +CACHE PATH "Output directory for libraries") + everything else is just a "format" change + ok + so the question is whether libdir should or should not be +relative to prefix + tampakrap: anyway, we can move to next bug :) + thank you + * Remove hard dep on media-libs/phonon from kde-base/kdelibs + https://bugs.gentoo.org/show_bug.cgi?id=356681 + https://bugs.gentoo.org/show_bug.cgi?id=388041 + Has upstream fixed the bug that made us add the hard dep? + no + iirc, knotify would stuck if we didn't had phonon in the system + phonon still requires at least a backend to work + and taking out phonon from kdelibs is not possible + so WONTFIX / UPSTREAM ? + so we have to postpone this to kde frameworks? + can you build kdelibs against qt-phonon? + so, kdelibs still needs phonon and we can't substitute it with +qt-phonon yet + no, we asked upstream already + dilfridge: and i think you did actually :) + I only asked if you need a backend to phonon + not if qt-phonon were a substitute to phonon + you are in the channel, ask them about it now then :) + I would like us to be able to drop the phonon dep, but upstream +doesn't allow us to present that choice to users :-\ + so resolution? + let's ask upstream first + but i'm 99,99% sure it's not possible + and if not, close it as UPSTREAM + ok move on + just did + * Eclass problem with handbook without LINGUAS. + https://bugs.gentoo.org/show_bug.cgi?id=372457 + idella4: do you have find something out? + that's an obscure one + ^ + ?? + about this bug? + yes + well you caught me on the hop + I seem to remember working it + I had it compile effectively without LINGUAS set from memory + but -handbook was causing the flaw + that must be around a week ago + maybe I left some good comment in the bug +-*- dilfridge gets a drink + ok, is there anything to discuss here? + no + * MacOSX request for cmake-utils.eclass: + Remove force of CMAKE_BUILD_WITH_INSTALL_RPATH=TRUE + https://bugs.gentoo.org/show_bug.cgi?id=398437 + -> can easily be done, because the FORCE affects only prefix +anyway + jmbsvicetto: here we go^ + jmbsvicetto: ^^ is that the one you confused earlier? + no reason to drop that hard requirement + yes + bah, sorry. I meant to say, no reason *not* to drop that hard +requirement + so let's do what prefix asked + thats sound reasonable + move on? + fine with me + we've reached kde-base/kcolorchooser by now +-*- johu is watching the chat monitor + * Revise the change "semantic-desktop? -> semantic-desktop=". + Why was the change needed. + https://bugs.gentoo.org/show_bug.cgi?id=396491 + dilfridge: if you want, we can highlight you a bit on +#gentoo-kde ;) + yeah well reavertm is still not here + hehe + i am fine with dropping the '=' + so, I never liked that semantic-desktop? -> semantic-desktop= +move, but it was done with the argument that we were getting strange and +unexplicable bug reports and that it was causing issues in the upstream bug +tracker + I dont see why we should allow "?" + because nobody gains from it + +1 @ dilfridge + once you have kdelibs with semantic-desktop, you have all the +dependencies + dilfridge: As I don't want semantic-desktop at all, being able +to just enable it where I'm forced, would be a plus. But I think we should try +to be consistent + but dont you need kdelibs[semantic-desktop] for any +semantic-desktop enabled package? /me confused + can we skip it for next meeting? + sure + yawn + good + OPEN FLOOR + there were real reasons that we agreed with to have +semantic-desktop= back then (we as in the kde team, even if I disagreed) + dilfridge: ? allows that + yes + dilfridge: the point with = was that I would have to had every +kde package built with semantic-desktop if just a single one required +semantic-desktop + scarabeus was the one to push that decision + tampakrap: talk to scarabeus in office about that + tampakrap: I feel like were starting to have a "memory issue" in +the KDE team. We got enough new people recently that some of the old issues +are being raised again as the team (or a substantial part of the team) doesn't +know the history behind them + jmbsvicetto: i believe that is reasonable though, things change, +new decisions are taken + tampakrap: that means we should probably start thinking about +providing better documentation for decisions so that people know sometime +later whey they were done + technically it should be in the meeting logs + i agree with the documentation, and it is entirely my fault + i'll do my best from now on though + open floor: cleaning up herd? + again? + tampakrap: I don't think it's a bad thing. I'm just stating that +I've noticed it and that we should perhaps rethink a few things in how we +operate ;) + i did that in less than a year :( + jmbsvicetto: +1 + !herd kde + (kde) abcd, alexxy, dilfridge, jmbsvicetto, johu, mschiff, +patrick, reavertm, spatz, tampakrap, thev00d00 + spatz? + patrick? + tampakrap: Hey, at this point in time I'm the "oldest" kde dev +around ;) + patrick is special + yes, let's kick jmbsvicetto out + meow + :D + tampakrap: hehe, "special" ;) + tampakrap: I've told you at this point I only care about amarok +and related packages :P + johu: i'll talk to spatz, ok + can somebody make me wise? +-*- jmbsvicetto blesses johu with wiseness + thx + :) + Patrick I suspect is soon to wake up + another topic for open floor: + !time bonsaikitten + dilfridge: I don't know where bonsaikitten is, (s)he should use +!time set / to let me know + idella4: I can finally make fun of Patrick at some hours without +risking him replying to me ;) + China + when the Cat's away + I'm doing a kde release party here in prague a week after fosdem, +probably at suse office, you are all invited + idella4: He used to be more time online than me :) + he is on-line alot + see he is in my timezone + tampakrap: It seems I'm too "heavy" to catch the fiber optic to +your office :P + tampakrap: travelling already that weekend, sorry + tampakrap: otherwise I would take your invitation and go check +the "blankets" ;) + you loose + oldies + anyway, meeting closed + i'll do the summary, someone upload the log please -- cgit v1.2.3-65-gdbad