path: root/meeting-logs/kde-project-meeting-log-20140810.txt

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