1. Roll call (5 minutes) !herd kde -*- creffett|irssi here (kde) ago, alexxy, creffett, dastergon, dilfridge, jcallen, jmbsvicetto, jmorgan, johu, kensington, mrueg, mschiff, patrick, reavertm, scarabeus, thev00d00 -*- scarabeus beeps hi pong. -*- johu here 2. EAPI 4 kde4.eclasses deprecation (10 minutes) - KDE overlay is fully migrated to EAPI 5 and all older EAPI's are banned - No issues known with EAPI 5 - Discuss and vote question: I know we've handled this in-overlay, but what's the state of packages in-tree? -*- jcallen is here i bumped alot to EAPI 5 let me check. (would be nice if pkgcore worked enough to give us the EAPI-by-eclass breakdown) so its only a question of stable requests and some packages not maintained by us pkgcore-9999 works good enough now and it fixed on qa-reports I think yes qa-reports is fixed really. thats why i started to do the tree EAPI 5 work news to me we should ban it in the overlay and in the tree once that's cleaned up kde-base: 21, kde-misc: 20 eapi 4 packages (eapi per cat) so...bump the requirement in-overlay, news item on -dev or -dev-announce, file bugs? http://qa-reports.gentoo.org/output/eapi-per-eclass/kde4-base.eclass/4.txt ^^ most of them have already EAPI 5 rev bumps cool then stablereq and request cleanup yup around 20th april we can start mass stabilization and see whats left so eapi4 ban would mean drop kdepim 4.4.x, right? mrueg: I wish nope are those not EAPI 5? we just bump them to EAPI 5 yeah i poked dilfridge about it already and he wants to do it probably no need for a revbump, tbh creffett|irssi: just checked for knotes still eapi=4 kk creffett|irssi: it's stable packages kensington: blarg anyone who wants to keep EAPI 4? punt it ok vote: no need to keep, but what is the need to punt it? I know it's stable, but I doubt the bump will actually change installed files, and those aren't using any eaapi features, afaik just progress? +1 burnintae *burninate +1 mrueg: for 4 -> 5 not much, but eg. it might let us assume subslot support for something in the future should be fine for 4->5 so +1 creffett|irssi: we have already subslots implement for kde-base in the eclass johu: oh, right, forgot about those revbump it is. kensington: i just wonder if ebuilds in overlays will fail because eclass disallows in the past, dropping <3 let us clean up a lot of junk from the eclasses *non-kde overlays mrueg: not our problem they will, that's their problem, we will announce as per usual we announce it they fix their own okay sounds good. :) +1 I did a couple of the 'major' ones for the las ttime we make a tracker for the packages not maintained by us yup; I can do that if you'd like creffett|irssi: lets do it after the mass stabilization it would be nice to get a repoman error if eapi is deprecated for used eclass okay mrueg: that would require eclasses have a DEPRECATED_EAPIS sort of variable which would be nice, admittedly creffett|irssi: raise that topic in qa please yep :) johu: in portage, actually :P mrueg: file a bug :) probably talk to TomWij or file a bug ;) will do. next topic I would look into it if I had time in the next...two months. 3. KDE overlay contribution model (10 minutes) mmkay - We have a github mirror, which offers pull requests, reviews and comments - Allows us to get more QA for user contributions - Proposal: Drop all user ssh keys from overlay and promote the github contribution model (for example with a overlay news item) - Discuss and vote -*- creffett|irssi is in favor of switching to github/pullreq model and dropping users' keys I am against dropping all user ssh keys -*- mrueg wants to wait until infra deploys gitolite-3 on gogo mrueg: what offers gitolite-3? johu: easier mirroring we should encourage pullreqs for more user contributions, but I think some users is fine to commit directly kensington: hmm, that's valid kensington: but where you draw the border that said, there have been a couple problematic commits as of late one user drop one not I don't think we even have a list of who has access thats easy question for infra... -*- creffett|irssi asks right now mirroring means someone with access to both repositories does this on git push and pull, right? dastergon can probably help with that mrueg: yes, no server automation is currently supported so we come back to the question of who we want to have access infra won't do a hook, and github need to contact their support to have them mirror kensington: please propose the criteria which user can proceed to commit and who not imho it should be consistent the thing is that most commits I've seen have been devs; of non-devs, there have only been a couple committing regularly, and at least one of those has been subpar iow, we don't have a high non-dev commit rate to start with I think we could allow only pushes to a non-master branch for users and merge it regularly it's impossible to have a list of checkboxes in general, makes enough patches that are good seems like a good rule, it worked in the past nah just do it simple, they start with pull requests and if they are good they get the commit access directly, if they screw up they loose it scarabeus++ good enough for me that's what we used to do anyway, except with patch on bugzie instead of pull request but do we keep everyone's access? also *lose... :D for those interested: 13:28 <@a3li> hi creffett|irssi, I'd have this list of additional keys besides all developers for you: caleb christian civil creffett cryos dastergon dessa devurandom dmaggot eliasp genstef helgc idella4 johu kensington krytzz letharion lxnay mattepiu mrueg mschiff mva okias ronis_br skiarxon spatz sput terietor tgurr travlr wizzleby wohnout yngwin I...uh..have no idea who half of those people are. :P and the other half is people that went on to be devs :p yup so do we want to keep all of those? i raised this topic to make the contribution easier for non-devs and as github is generally accepted i think this is the consistent way for example clean up wiki page with contribution info remove hackers file etc etc yeah -*- johu thinking in long term to a git migrated tree :D johu: heh. -*- creffett|irssi drinks can anyone add a instruction how to mirror both repositories? last time i tried to merge a pull request on my own overlay, it went all mad. so for the moment, any objections to leaving current contributors with access and switching to encouraging everyone else to use github pullreqs? ++ fine by me mrueg: I personally use github "merge on command line" instruction, then rebase and push otherwise you can merge in github ui, pull, then push to gogo mrueg: you have to add another remote to you local git clone kensington, scarabeus: any objections? jcallen: and you creffett|irssi: no, since this is the current process anyway :p kensington, johu: an example gitconfig would be nice. ;) well, that's a majority johu: your turn mrueg: http://bpaste.net/show/195334/ http://dpaste.com/1763251/ thanks looks like i did something wrong here. http://bpaste.net/show/pqp20cn2F7hNvn7aQjWI/ ;) so please vote on the general plan I have no problem with cleaning up at least some of the access list, I agree there have been some 'interesting' commits lately with the exception of not dropping keys at once +1 +1 +1 ok i will prepare a news item and send it to kde @ we can optimize it then sounds good next topic 4. KDE Frameworks 5 (15 minutes) yay! Overview: KDE Frameworks New kde-frameworks eclass needs internal review/feedback. It's not yet ready for -dev ml due to potential major changes for workspaces and applications. It appears (final strategy not confirmed yet) that rather than one SC as seen in KDE 4 there will be 3 groups released separately: frameworks, workspaces, and applications. We should consider how this should be categorised. kde-frameworks is currently approximately 60 packages, with the potential for future 30+ additional packages. Potential scheme which is consistent with existing categories (see gnustep for -libs precedent): frameworks -> kde-frameworks/kde-libs workspaces -> kde-base applications -> kde-apps See Naming scheme, Dicuss and vote wheeeee what about kde-misc? people are going to complain about us having three categories. there's precedent, see gnustep didn't say no precedent, said there will be complaining ;) i would follow naming scheme from upstream-> frameworks -> kde-frameworks a lot of frameworks stuff is designed to be not so kde-specific, so I think they deserve their own category that said, the suggested split sounds good to me -workspaces -> kde-workspaces -applications -> kde-apps we also may want to consider doing something with kde-misc, but that's a different question for a different day kde-misc stuff doesn't fit into any of those other categories kensington++ I mean more like there's a lot of cruft in there that I doubt anyone uses like I said, different question for a different day yeah, it could use some testing, I last-rited a youtube package in there that is probably broken for years johu: that means for the mean time 5 categories, right? kde-apps, kde-base, kde-frameworks, kde-misc, kde-workspaces I agree with johu, but I think we will get a lot of pushback on -dev yup. i think it is a good idea to seperate the release groups just move the two proposals to -dev and see how it turns outr question: when is kde 4 set to stop getting releases creffett|irssi: when there is a stable kf5 based release kde-{workspaces,apps} creffett|irssi: maybe there's also a trinitiy project for that do we want to support kde sc 4 and kf 5 installed in parallel? frameworks is about to hit beta, and workspaces is about to hit alpha kf5 is almost co-installable with kdelibs kde-runtime will be co-installable, kde-workspace will not well, at least we have time before the tree move to get flamed who raises the cat discusion to -dev ? just think about a package depending on kwin for example I would like to have some team agreement, because the runtime/workspaces split is about to happen and I want to package asap +1 from me mrueg: kwin will not be co-installable, but not much depends on it anyway i have no objections, please dont re-introduce a kde-prefix again also, I volunteer kensington for emailing the ML :P kensington: just thinking if we want to deal with slots or categories ooh! kde-prefix! so kde-base/kwin:4 or kde-base/kwin because kwin:5 will be in kde-frameworks or somewhere else. all kde5 stuff is already in slot 5 vote on: kde-frameworks, kde-workspaces, kde-apps +1 +1 if -dev is against it we should go with kde-apps, kde-libs, kde-base kde-base for kde4, kde-misc for everything else probably eclass can use the category to decide which release group the package is so we don't need anything like TIER=1 inside of the ebuild mrueg: it's all in split repos TIER=foo was only for frameworks stuff when it was still in kdelibs ack kensington: ah okay didn't know that :) anything left to discuss for now on kf5? yup lately there was a discussion to merge qt-overlay and kde-overlay? if anyone has a free moment, check the eclass, there are a few design decisions that could use a review what about the ebuild naming scheme? mrueg: i dont see the purpose, the split was decided with the herd split and thats totally fine johu: i don't know, can't both sides profit from a shared repository? there's not much crossover the only commonality, really, is qt5 mrueg: there was a time where no qt herd exists and the qt stuff was maintained by kde I actually did not know that and then the split was decided because of the reason that there is no much crossover though that explains the large number of qt people in our repo's access list :P but what would be the drawbacks of a joint repository? because kde is just one consumer the effort to merge it and people migrating to it I guess we have high kde commit rate because of the monthly releases and someone who dont want to have extra kde stuff but newest qt stuff is pushed to get all those changes... johu: probably we can work on seperate branches and with a joint master branch naming scheme is important if we end up using kde-base for kde5 stuff -*- johu is against a re-joined qt-kde repo mrueg: eww and if not it would be nice to not have to manually pin ebuilds to a branch they don't match okay :) i see we better stay at status-quo :) kensington++ so, we can either just update the sets (eg. kde-live pulls in kcalc-9999 and kwin-4.12.49.9999) or make fake versions like 4.9999 sets sounds more reasonable ++ ++ but this decision is a little bit influenced by the cat discusion on -dev yeah yup also, I think kde-workspaces will end up to be not many packages maybe kde-base fits here okayish it's being split into 12 repos, probably only that many packages kensington: i would suggest to write the -dev mail as soon as possible and then do the reasonable move! johu: I will wait 1 or 2 days until the split is done, to get an accurate number of packages if 12 repos = 12 packages, a new category for that will be definitely be rejected we could discuss this per mail if it is realy urgent and needs a fast decision johu++ I will mail a draft to the alias depending on what happens upstream ++ ++ anything left on kf5? otherwise I guess it will just be kde-frameworks/libs + kde-base btw kensington thank you for your great work mhm btw, mimetypes is fixed upstream in case you didn't see :-) kensington++ 5. Bugs (15 minutes) bug 445392 johu: https://bugs.gentoo.org/445392 "kde-base/konsole-4.9.3, x11-terms/xterm: backgroundcolor is not reset when scrolling"; Gentoo Linux, Applications; UNCO; toralf.foerster:kde RESO NOTOURBUG ++ c7 ++ ++ hello i dont want to do upstream work hi ago hey ago sorry for the delay, I had a prob. good enough, will mark it bug 456360 johu: https://bugs.gentoo.org/456360 "kde-base/print-manager looking for org.fedoraproject.Config.Printing"; Gentoo Linux, KDE; CONF; kirelagin:reavertm erm : bug 445392 vanished away / was solved in the mean while (at least with 4.12.3+4.11.7) https://bugs.gentoo.org/445392 "kde-base/konsole-4.9.3, x11-terms/xterm: backgroundcolor is not reset when scrolling"; Gentoo Linux, Applications; UNCO; toralf.foerster:kde toralf: that's good news johu: that bug confuses me. printer stuff needs gnome bla to get full working, so there was a proposal to split stuff up but i got lost by all those user comments is reavertm around lately? haven't seen reavertm, no in the last years not realy I guess the real solution is to improve the splitting, we can see how other downstreams do it add a minimal useflag to system-config-printer-gnome and activate that in kde profile by default? minimal useflag triggers the patch mrueg++ it would be cleaner to do the split but this would be more effort mrueg: volunteer? johu: maybe upstream accepts the patch if eta is 1 month + x, i can take a look at it otherwise, i'm short on time it's all one package upstream I think? i guess yes bug 482652 johu: https://bugs.gentoo.org/482652 "[kde overlay] dev-db/virtuoso-server-7.0.0 fails to integrate with akonadi/nepomuk"; Gentoo Linux, KDE; CONF; johannes.hirte:reavertm do we realy need virtuoso-7? nope nepomuk is going away \o/ BOOM lets keep the bug open and then last rite virtuoso when nepomuk is gone... +1 as virtuoso comaintainer :P does it work on x86 anyway? nope nope! virtuoso upstream stoped caring about...pretty much anything so I'm fine with burninating we can close that bug, there's no new development of nepomuk obviously 14:22 < johu> mrueg: volunteer? oops, sorry stupid putty paste buffer kensington: yeah but you will always get version bump requests even when it makes no sense lets move on then but i am fine with it to drop the stuff there's still the other bug about it open bug 490600 johu: https://bugs.gentoo.org/490600 "kde 4.11.3 missing oxygen theme after update"; Gentoo Linux, KDE; CONF; nikhatzi:kde this is re-occuring with kstyles/qt updates what is there that we can do? how about to just add a einfo/ewarn? johu++ yeah we would need a eclass/portage mechanism to get this proper fixed I'm still not sure exactly which package is triggering the breakage though i guess qtgui bug 497314 johu: https://bugs.gentoo.org/497314 "No standard directories created after login to KDE"; Gentoo Linux, KDE; UNCO; oldium.pro:kde kensington: whats to discuss there? what (if anything) to do do we want to add a useflag for that? if we do /etc/skel we have to coordinate with other desktops kensington: please do its the proper way or we can copy the env thing from hnome copy & paste is dirty please do the skel way what package do we put it in? kde-env ? sgtm sure we might as well just copy the gnome env file then, it's less copy-and-paste then manually creating a bunch of directories /usr/portage/gnome-base/gnome-session/files/10-user-dirs-update-gnome-r1 ok if you say its easier faster and not that dirty, "Just do it" make it so! 6. Elect new lead (10 minutes) i'll have to leave now !herd kde (kde) ago, alexxy, creffett, dastergon, dilfridge, jcallen, jmbsvicetto, jmorgan, johu, kensington, mrueg, mschiff, patrick, reavertm, scarabeus, thev00d00 nominees I will go again if nobody desperately wants the role creffett|irssi++ i nominate johu too thanks accepted Xfce has the same code as /usr/portage/gnome-base/gnome-session/files/10-user-dirs-update-gnome-r1 in startxfce4 at upstream level (where it really belongs) creffett|irssi, but, but, I was hoping you'd be portage lead...;) dol-sen: NOPE. ssuominen: what is your opinion on what we should do, as the resident freedesktop expert :D -*- dol-sen goes back into hiding in the corner do we have any more nominees? i would nomintate dilfridge but i guess he has enough work with council and he is not here to dis-/agree yeah all right ok do we want to do this via mail? then let's vote I have no preference i have the feeling that to less people are here... mrueg just left the building okay, then I'm good with email voting ++, I have to go too kensington: got nothing unexpected to say :) I'd add the file like gnome has, but at the same time, also write a patch that does the same and file upstream ticket creffett|irssi: check please the kde mail alias with herd members...there are some not following the mails johu: uh, I can't right now, but off the top of my head reavertm isn't on the list and possibly dastergon? creffett|irssi: scarabeus too i guess scarabeus isn't I think and mschiff maybe too yeah so better check ssuominen: ok, I'll go ahead with that, thanks -*- creffett|irssi can't do that until tomorrow night creffett|irssi: yeah lets say let us do the vote within 10 days