Meeting log 2012/01/16

1 files changed, 630 insertions, 0 deletions

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