1. Roll call !herd kde (kde) alexxy, creffett, dastergon, dilfridge, jcallen, jmbsvicetto, jmorgan, johu, kensington, mrueg, mschiff, patrick, reavertm, scarabeus, thev00d00 -*- alexxy here -*- kensington here -*- johu here too pong me too good 5 is enough to start 2. kde4-*eclass GCC minimum version (10 minutes) Please discuss and vote on raising gcc minimum version to 4.7 Open Bugs: bug #462550 - [4.6/ICE] sys-devel/gcc-4.6.3 Segmentation fault (program cc1plus) compiling kde-base/rocs-4.10.1 on ppc64 bug #471770 - =kde-misc/homerun-1.0.0 - fails to build with bug #508324 - kde-base/kig-4.13.0 fails to build with johu: https://bugs.gentoo.org/462550 "[4.6/ICE] sys-devel/gcc-4.6.3 Segmentation fault (program cc1plus) compiling kde-base/rocs-4.10.1 on ppc64"; Gentoo Linux, KDE; CONF; jmorgan:toolchain johu: https://bugs.gentoo.org/471770 "=kde-misc/homerun-1.0.0 - fails to build with johu: https://bugs.gentoo.org/508324 "kde-base/kig-4.13.0 fails to build with 3rd bug is one of the stable blockers -*- dilfridge|mobile here we did it in kde5.eclass and already there was a complaint kensington: why do people complain? only one... nah we do these rises quite periodically mrueg: because it unconditionally required it for every package and people complain but still they should use latest-stable anyway kensington: okay, i don't consider that relevant. do it and gcc 4.7 is stable for >few months raise it its bare minimum so its good to raise it to 4.7 ok official vote: or there are some arch that dont support it? -*- alexxy vote for gcc 4.7 in deps +1 +1 +1 ok fine 2. KDE SC 4.13.3 stabilization (15 minutes) bug #517344 - KDE SC 4.13.3 + KDE Workspace 4.11.11 stabilization semantic-desktop refactoring (old semantic stack -> nepomuk use flag, new semantic stack -> semantic-desktop use flag): Are we happy with it? Do we need an news item? Baloo alternate KCM: Now that upstream provides an option to disable indexing in their KCM, do we still want to hack the alternate KCM into the baloo ebuild? Please discuss and vote to stabilize KDE SC 4.13.3 https://bugs.gentoo.org/517344 "KDE SC 4.13.3 + KDE Workspace 4.11.11 stabilization"; Gentoo Linux, Keywording and Stabilization; CONF; johu:kde i would disable the hack otherwise +1 ack with scarabeus not sure about news item Same here if there is possibility to disable indexing using upstream kcm then there no need to hack alternative one can we do a news item conditional on installed with -semantic-desktop ? i dont care about the alternate kcm i want to punt alternate kcm hack from ebuild, it's still around if someone wants to install it himself fine by me^ fine^^ are we happy about baloo performance? only have ssd to test on laptop it's improved over nepomuk EDONTCARE any objections to 4.13.3? no, it's a good target No use flag refactoring was OK? sgtm ok first vote on the topic: 4.13.3 is our next stable candidate refactor worked out well, i think everything was converted ++ +1 + + ok now about the procedure kde-stable looks dead to me no mail after ago's reitrement so i will add arches directly so should we dissolve the project? fine, it's been very quite release in ~arch anyway which leads to the question which arches @-dev mail about ppc/ppc64 or can we reactivate them for kde5 somehow? Talk to pl ppc Ask them who was elected to be lead of the 2 herds? Imho we don't need ppc stable But if they want... johu: jmorgan iirc Gotta go, have fun... ok i will contact him when we have the stable list in place which will require some work to catch up all pkgs about the use flag refactoring ppc 32 bit is a dead arch its only exist in routers don't they need to go stable at the same time anyway? yes thats why they have to be IN the list alexxy: ack so it may be safe to drop them i will ask them if they want to keep stable keywords if x86 32bit somehow alive since some still use it even if there no processors which run only 32bit mode for 10 years yeah some ppl install still 32 env on 64 systems... however x86 32bit can be considered dead in quite near future ok last question in this topic if there is no objections on this. Do we need a news item? johu: they still wann be paladins and play necromants games +1 for news item ++ + +1 there was some confusion about 2 use flags when it hit ~arch ok volunteer? users should know or they will scream kensington: native speaker, you wanna do this? sure ok fine, so in some weeks we will have a new stable kde next topic 4. KDM (5 minutes) jmbsvicetto suggested to rethink kde-base/kdm as a dependency in kde-base/kdebase-meta:4, as kdm will not exist after KDE 4 and users might have already migrated to something else. Do we want to add IUSE="+display-manager" with RDEPEND="display-manager? ( || ( x11-misc/lightdm-kde x11-misc/sddm kde-base/kdm ))"? If so, which order? Please discuss and vote to make kdm optional (and if yes on the proposed solution/order) kill'em =D make it optional, add display-manager IUSE, order: not sure about it. sounds reasonable -> RDEPEND="display-manager? ( || ( x11-misc/lightdm-kde x11-misc/sddm kde-base/kdm )) kde upstream supposed to use sddm? right? for kde5+ may be it good to create virtual/display-manager for kde4 let's keep the default the same yeah the order for kde4 should be untouched and for :5 i would vote for sddm as upstream is heavily contributing to sddm we can worry about :5 later, we don't even have meta packages for it yet kensington: is on my long todo list kensington: i'll create them =D i'm run it @work anything to add before vote? tbh dm shouldn't even be pulled in kde 5 meta pacakge; we don't pull in xorg-server also sddm should work for wayland that i wanna give a try on laptop OK please vote on making dm optional and keep current order untouched for :4 +1 +1 +1 there is no current order, it's just kdm just put there or with kdm first "s/current order/kdm default" makes more sense kdm use flag then since kdebase-meta is just a list of kdebase packages display-manager sounds more generic and sddm isn't even stable we just need one stable in the RDEPEND options ;) thats not the problem any other opinion about the use flag name? ok, silence So please vote on use flag name: a) display-manager b) kdm -*- kensington doesn't care about flag name so let's go with display-manager fine does it mean kde:4 display-manager? ( kdm ) or display-manager? ( || ( kdm lightdm sddm ) ) -*- kensington votes for the first one i'd be okay with both -*- creffett|irssi here and i think jmbsvicetto, too. display-manager i would say give freedom to the ppl: display-manager? ( || ( kdm lightdm sddm ) ) iirc he just wanted an option to disable kdm there Gentoo is all about choices don't use a meta package for pulling in kdebase packages then its outlined in our official guide -*- creffett|irssi passes johu a drink you can still choose what you want, but the kdebase-meta pulls in all kdebase-packages wallpapers use flags pulls in kde-wallpapers, not || ( kde-wallpapers gnome-wallpapers ) ok all arguements on the table? vote on a) only kdm controlled by the use flag b) even more options, like lightdm sddm gdm? a b a all those sleeping birds creffett|irssi, alexxy, scarabeus? b b lightdm[kde] or just lightdm? ;) come on scarabeus say a then we have a draw suggest we do || ( kdm virtual/display-manager) then ++ += last chance to object^ there's no virtual/display-manager ? 5. Phonon backend (5 minutes) mrueg: thats an good argument kensington: where do you find it? it doesn't exist yet, alexxy suggested to create it fine by me, but please do it fast as it needs to be stabilized too otherwise i would vote for kdm only and do the long track for 4.14 sgtm ok next topic, 5. Phonon backend (5 minutes) The current default backend is gstreamer, the same as in Kubuntu, and has the greatest number of features. However, upstream now chooses VLC as the default. Should we switch or remain the same? Please discuss and vote on switching to vlc as default backend switch to vlc vlc vlc no opinion p-gstreamer has such a low commit rate also 1 vlc is nicer than 100 gstreamer-badugly-foo btw. what about phonon-qt7? homepage is dead, last snapshot in tree is from 2011 +vlc mrueg: if you want last rite it and see what happens mrueg: i look forward to punting it along with all other unmaintained prefix kde stuff http://quickgit.kde.org/?p=phonon-quicktime.git looks deadish kensington: please do so :) there was complaints last time i tried...but still nobody would even test it so probably it will disappear when kde4 is gone kensington: try it again 6. KDE 5 a) Categories (10 minutes)[edit] kde-frameworks has already been approved on gentoo-dev. Plasma 5 is currently 23 packages, should it go in its own category (kde-workspaces?)? If so, we would likely need a new category for applications (kde-apps?) and eventually remove kde-base (and kde-misc?). -*- kensington doesn't know why not use kde-misc instead of kde-apps? kde-frameworks, kde-workspaces, kde-misc it will have official kde and third party applications in the same category then kde-plasma? its the official wording for the DE so why not following it for the category and then would make kde-apps sense to me otherwise i would stick to kde-base kensington: post pone this topic? i guess b) Moving to tree (10 minutes) Qt 5 will be in the tree soon (masked). Are we happy to move KF5 / Plasma 5 after that's done? kde-workspaces looks better its good to move -*- johu is for KF5 tree, plasma 5 overlay when qt5 hits the tree at least releases kf5 are nonsence without apps and plasma so its like all or nothing its not the best user experience when almost all kde apps are not ported yeah but we can keep it masked that's a feature, not a bug alexxy: wrong tomahawk already uses a kf so if someone wanna use it they will it's expected behaviour to use kde4 apps and porting will be slow i guess at christmas time big porting will happen arroundish will plasma-active get into the tree somewhere in the near future? oh sorry. nvm OK vote 1) When Qt5 hits the the KF5 will be added too tree ++ ++ johu: kf5 + plasma otherwise ++ ++ (without plasma) 2) When Qt5 hits the tree Plasma 5 will be added too -1 -- ++ ++ for plasma-5.1 4.0 was the same story plasma is pretty stable though but the kde4 apps looking ugly kensington: is the package splitting done? kensington: +1 i use it as default DE @work i didn't notice, maybe we have different themes only porblem is that it doenst work with 2 monitors mrueg: which splitting? and there are a lot of usability issues unresolved kensington: dolphin:5 etc.? 2:2 mrueg: we didn't work on it yet, hoping upstream will split repos there's not even release schedule yet so we've got some time i take my lead head on and say lets revisit the topic with 5.1 release kensington: i'd say get it into the tree, when this is done we have no hurry to rush at the moment mrueg: applications are on a different release cycle to plasma kcalc may well be released at a different time to dolphin eg. kensington / alexxy are you fine with postpone the plasma decision? yep fine, probably 5.1 will be released before qt5 in tree anyway he he =D or 6.1.... 7. Bugs (15 minutes) first one: 456360 bug 456360 johu: https://bugs.gentoo.org/456360 "kde-base/print-manager looking for org.fedoraproject.Config.Printing"; Gentoo Linux, KDE; CONF; kirelagin:reavertm was this discussed last meeting? i think so, don't remember the outcome ok then we need to grep the last log and see what we are going to do bug 492434 johu: https://bugs.gentoo.org/492434 "lib-net/libnm-qt should depend on systemd or consolekit (was: kde-misc/plasma-nm should depend on kdm[consolekit])"; Gentoo Linux, KDE; UNCO; cruzki123:kde not much we can do unless someone volunteers to do the package split i think it was me to check whats going on, but haven't found time for that RESOLVED WONTFIX imho as networkmanager already provides those flags which one actually requires it? libnm-qt or networkmanager plasma-nm is not useable without consolekit/systemd but it depends on libnm-qt which depends on networkmanager and networkmanager already provides the requested use flags... -*- kensington no opinion its dependency chain as plasma-nm is the only consumer of libnm-qt so libnm-qt should depend on nm with any of this use flags can't libnm-qt depend on || ( networkmanager[consolekit] networkmanager[systemd] )? yeah we can add that^ fine RESOLVED FIXED soon (tm) bug 497314 johu: https://bugs.gentoo.org/497314 "No standard directories created after login to KDE"; Gentoo Linux, KDE; UNCO; oldium.pro:kde kensington: last comment from you meh do we even want to do something downstream? if its a hack no if its doable without hack fine by me kensington: what about comment 4? but at least some progress on this would increase user experienc sounds good. mrueg: we can do it, it's kind of hacky but it works kensington: is this for plasma5 needed too? if yes i would vote for an upstream action! as we want to get rid of such things yeah samuli mentioned /etc/skel solution, i'll ask him about that too ok lets see if the bug is unresolved next meeting ;) I dont care about dirs acutaly bug 497734 johu: https://bugs.gentoo.org/497734 "www-client/rekonq-2.4.0 should RDEPEND on kde-base/kdebase-kioslaves"; Gentoo Linux, KDE; CONF; rossi.f:kde kensington: last comment from user responded to your question, so whats left here to get a RESOLVED? i could reproduce with my config, but not his so we can 1) add the dep 2) too bad use runtime-meta 3) tell upstream not to use ioslaves to display a blank page 2) +3) or 1) ok seems i have no opinion on that does kdebase-kioslaves add many dependencies? (if you're using gnome and want rekonq as a browser) not much beyond kdelibs okay, then 1) + 3) ^ ++ bug 511570 johu: https://bugs.gentoo.org/511570 "[kde overlay] KDE Frameworks requires gcc 4.5, not 4.8"; Gentoo Linux, KDE; UNCO; matthew:kde topic 2) revisited for KF5 well we did raise it to gcc-4.7? (for kde-4) 1. too bad 2. conditional on package type yeah we did if we raise for kde4 to gcc47 its fine to have gcc48 for kf5 Is there a need for 4.8? i guess we would get a lot of bugs if we lower it to gcc45 why not use 4.7 for both (if it works) plasma 5 requires 4.8 ah okay the 4.8 is fine thats the reason^ (just asked because 4.7 is stable, 4.8 is testing) WONTFIX imho +1 4ю8 шы ашту sorry 4.8 is fine -*- alexxy on 4.9 already -*- johu too kensington: did you test kf with 4.5? :) no, it's just the upstream claim i don't even have 4.5 installed 4.5 is too old i guess nobody will test it from herd as we already on newer newer version more interesting kensington: so thats a closing reason for it, we dont have the manpower to support such old setup bug 514384 johu: https://bugs.gentoo.org/514384 "cmake-utils.eclass: please deprecate all those fancy cmake-utils_use_*"; Gentoo Linux, Eclasses and Profiles; CONF; mgorny:kde yeah, it's less relevant anyway since we move to 4.7 -- no problem to add the function he wants, but a lot of the existing functions are useful kensington:++ same opinion maybe we can grep to see if there's some old unused function to remove and dilfridge already expressed his opinion in the bug yeah do it so 8 Open floor (15 minutes) kde member of the month: kensington for his great effort on KF5/Plasma5 and upstreaming cheers and next month it may be pesa to get Qt5 into the tree i did a big reshuffle of cmake-utils in overlay, it tests ok locally for ages so i'd like to move that it's mostly cosmetic we are almost done with EAPI4, do we need to announce it on -dev? <10 pkgs don't think it's required, maybe some overlay users care ok i need to leave, my food is ready Thank you all johu++