diff options
Diffstat (limited to 'meeting-logs/20120116.txt')
| -rw-r--r-- | meeting-logs/20120116.txt | 630 |
1 files changed, 630 insertions, 0 deletions
diff --git a/meeting-logs/20120116.txt b/meeting-logs/20120116.txt new file mode 100644 index 0000000..aa6bc0d --- /dev/null +++ b/meeting-logs/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 |