path: root/meeting-logs/20120116.txt

<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