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