ok let's start !herd kde (kde) abcd, alexxy, dilfridge, jmbsvicetto, patrick, reavertm, spatz, tampakrap roll call 1 2 -*- dilfridge hears bonsaikitten munching in the distance 3 http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/maintainers/meetings/meeting-2011-05 agenda ^^ jmbsvicetto: here? until he shows up, anyone familiar with the status of 4.7 so far? nope here so, 4.6.80 can you give us a brief summary of the betas please? -*- alexxy here I think I got most of kdebase, kde-utils, kde-graphics, kde-games and kde-network working alexxy then bumped the rest about the status of the upstream tree / tarballs: most problematic is kdebindings I think no package is working status of upstream tree / tarballs: about kdebindings... I vaguely remember an e-mail longtime ago when kde-4.7 was started, where the new split was explained i recall that too kdebase was split on 3 tarballs - kdebase, kde-runtime and kde-workspace do you think we should rename our metas? the info is available in the readme.modularization of the tarball http://old.nabble.com/kdebindings-split-td30617636.html http://paste.pocoo.org/show/399690/ The question is will they stick to the names or not at this point I think they haven't made up their minds yet but they have the repos ready don't they follow their repo naming schema? alexxy: ^^ I'm not sure they're doing it consistently >:| for example, smoke (which I think is a single repo) was split into 3 tarballs --> Skiarxon (~quassel@ppp091138207078.dsl.hol.gr) has joined #gentoo-meetings smokegen, smokeqt, smokekde sec like in the deptree can i have a list of the bindings tarballs? I'm not sure as I didn't had the time to go after the repos. I based my work in the existing tarballs and on the live ebuilds - which were in very good shape!!! i'd like to compare with the repos right now I can give you the tarballs names for them. I still think there's a missing krosspython, but after 3 emails I've yet to get a proper reply i follow the list, yes so as I said: smokegen, smokeqt and smokekde jmbsvicetto: I'd hope the live ebuilds were in good shape -- I use them myself :) here are the repos for referrence: https://projects.kde.org/projects/kde/kdebindings smoke is consistent so far -*- alexxy also use live =) but now gonna switch to betas perlqt, perlkde, qtruby, qyoto, korundum, kimono and pykde4 tampakrap: ok, then the live ebuilds need to be updated as well perl is consistent should we pkgmove smoke to smokegen, or just add a block on smokegen to smoke? everything is checked block, because we're not changing :4.4 and :4.6, I'd think :) the tarballs are consistent to the names in the README.MODULARIZATION file ruby is consistent ABCD: only 4.7 is involved dilfridge: everything is :) tampakrap: pkgmove moves *every* version unconditionally so, to get kdebinding we need to start by spliting smoke. I wasn't sure if the live ebuild was ok or not, so I didn't start that (you *cannot* use a versioned atom in that spot) so, we follow upstream's repos for kdebindings since the tarballs and repos, do we all agree? yes ABCD: correct, i got you wrong yes seems a good idea and I'm for blocker, not move also seems we need something to do with kross* modules If no one beats me to it, I'll work on it this weekend blocker is one way alexxy: what about them? where are the tarballs? :) tampakrap: no tarball for krosspython mia tampakrap: dunno =) if you want, prepare the live ebuilds then tampakrap: the README mentions the pykde4 tarball, but it no longer includes any code i believe they'll follow the repo names as the rest of the module this is about the only really crucial piece of binding because of plasma... jmbsvicetto: sorry? where is the pykde4 code then? sorry, I'm mixing tarballs ok, we're done with bindings jmbsvicetto: give us the modules that are monolithic please kdepim is one of them, what else? kdegames kdeutils kdenetwork those haven't migrated yet correct? kdenetwork kdemultimedia -*- tampakrap checks kdetoys kate (kinda), kde-baseapps, kde-runtime, kde-workspace, kdeaccessibility, kdeadmin, kdeartwork, kdegames, [kdelibs], kdemultimedia, kdenetwork, kdepim, kdeplasma-addons, kdesdk, kdetoys, kdeutils, kdewebdev kdesdk kdegames, kdeutils, kdenetwork, knemultimedia, kdesdk are still in svn oh yeah, kate was also fun also kdetoys, kdeaccessibility, kdeadmin, kdeartwork kate is now the name of the module, so I had to update the eclass as we hadn't "predicted" that case and the src_unpack was failing so, i'd say let's keep them as they are kdelibs is something we need to watch out. There's some doubt whether it'll be split kdelibs and kdelibs-experimental one by one please don't mix them kdelibs-experimental is not going to be a tarball it is an experimental repo yes, but kdelibs-4.6.80 had a dep on libs from it. Dirk ended up "smashing" it all together in kdelibs-4.6.80 ...one that's currently *required* by kdelibs proper yeah which was a mistake --> devurandom (~devu@unaffiliated/devurandom) has joined #gentoo-meetings there was a discussion in the ml whether that dep was a mistake or not. I don't recall the conclusion so, about the ones that haven't migrated yet anyone knows if this will be done during 4.7? it's likely causing more mess? of course :) we're fsck'd then oh well probably with kde-5.0 they'll move to mercurial... anyway lol what about the kde-* ones? should we change our metas? kde-baseapps kde-runtime kde-workspace What's the name of the repos? the same personally i'd prefer sticking to the repos name and tarballs name of course in that case it would make sense - unless they decide to rename it again no they won't we could perhaps wait for next beta release, just to be sure ;) sure of course, that means we'll have to check for `has_version kde-base/kdebase-runtime-meta || has_version kde-base/kde-runtime-meta` everywhere i think we covered all the monolithic/not converted yet tarballs so far yes it is a major change at this point I don't think krosspython will be fixed on this release (Dirk already said a kdepim issue would have to wait for next release) ok so, what about kate? it should be working now --> ni1s (~ni1s@1-1-4-36a.dre.sth.bostream.se) has joined #gentoo-meetings do you also fix the 4.7 lives? <-- ni1s (~ni1s@1-1-4-36a.dre.sth.bostream.se) has left #gentoo-meetings I actually forgot to test it on my test box :\ I started by touching 4.6.80. I think ABCD and alexxy applied the changes to 9999 now I don't know anything about 4.7.9999 there is no 4.7.9999 yet because upstream hasn't branched lol? they tagged from master? yeah -- just like they usually do for the betas :) ok that sucks so, how's 9999 then? alexxy probably knows best 9999 is fine -- I forward ported most of the -4.6.80 changes so that we can bump 4.6.85 (or whatever) from 9999 -- note that okular-4.6.85 will be coming from its own tarball, not the "monolithic" kdegraphics-4.6.*.tarball (or it should be -- they just finished that split) great, thanks speaking of kdegraphics so, anything else on monolithiks/no migrated yet heh. also i think we can drop eclass foo from all :live tarballs before proceeding to the splitted/migrated ones? the kdegraphics libs are tagged from the same branch as the ones distributed with digikam since we now know how they will be packaged alexxy: the if blocks? meaning with 4.7 the incompatibilities will go away sure, I already did it for 4.6.80 ebuilds yeah so we should do it for :live ABCD: did you push those changes to 9999? alexxy: already done -- 4.6.9999 keeps it, though jmbsvicetto: yeah also i'm going to make universal ebuild for kde-l10n (that should support :live and regular tarballs) good dilfridge: yours ? you were saying that kdegraphics... fyi, if/when slotting gets dropped, 4.x.9999 will become something like 4.x.49.9999 to keep versions in order the kdegraphics libs are tagged from the same branch as the ones distributed with digikam so our problems with digikam will go away cool ABCD: what do you mean? slotmove everything back to 0? tampakrap: yeah are you crazy?? not 4? tampakrap: that would seem to be the goal of dropping the slotting i don't see a reason to do that i think it makes sense the main reason we had slots to begin with was +kdeprefix -- kdeprefix will be gone as of Monday next week dilfridge: if we want to drop kdeprefix, we should drop the slots jmbsvicetto: yes that is what I mean we should definitely drop the slots yeah, but 4.x.49.9999 doesn't dilfridge: I don't know if we should use :0 or :4 :) 0 or 4 is all the same and why are slot 4 so bad? not when 5 comes along :) <-- devurandom (~devu@unaffiliated/devurandom) has left #gentoo-meetings then you admit to introduce kdeprefix later? :P 4.x.49.9999 makes actually a lot of sense tampakrap: 4.x.11 < 4.x.49.9999 < 4.x.80 (4.{x+1} beta 1) 4.x.80 (4.{x+1} beta 1) < 4.x.9999, which means that portage would see it as a downgrade what is the big problem with slot 4 anyway? yes, 4.x.49.9999 sounds good, even though we could argue that 4.x.49 would be the same i don't understand jmbsvicetto: given the differences between kde-3 and kde-4, I would not rule anything out with kde-5 tampakrap: I don't have a problem with slot 4. I'm just saying that have slot=4 or slot=0 is all the same for the PMs tampakrap: the idea is to get the versions in some sort of order, such that 4.x.y, where y < 50 is KDE 4.x, and 4.x.y where y > 50 is KDE 4.{x+1} ABCD: I agree, but as I said, 4.x.49 would be as good as 4.x.49.9999 there should never be any 4.x.49 release - or they'll have to modify their release numbers ;) except at some point maybe someone will introduce a 9999-magic in portage... jmbsvicetto: 4.x.49.9999 makes it a bit more obvious that it's live (and I think at least one PM assumes that it can't be a live ebuild if it doesn't have "9999" in the version) and the 9999 use is a "design" option, not a requirement repoman does that similarly PMS doesn't acknowledge 9999 as special, afaik repoman is based on eclass inheritance, iirc I think paludis does (I remember hearing something about that) I know portage uses inherit() to determine what "live" is in any case I don't have anything against 4.x.49.9999 ok i must admit i still don't understand I just fell 4.x.49 is smaller and if it works as well (which I think it should) we may want to use that but since the rest of the team does, i step aside tampakrap: what part don't you understand? tampakrap: what don't you understand? The ordering? 1) why slotmove a million ebuilds to 0 again 2) what is 49? tampakrap: why slotmove? it makes upgrading *much* easier (no more nasty blockers) well i think we still should have slots =) please no slots anymore ok it makes life so much simpler and without kdeprefix there is no real reason for it there will be kde5 next year not sure so we should have at least one slot tampakrap: as we're dropping kdeprefix, there won't be any more reason to have different slots for each version yes, that's ok I'd go for "move everything to 4" +1 2) what is 49? It's less than 50, which is the arbitrary cutoff used to determine if 4.x.y is part of KDE SC 4.x or KDE SC 4.{x+1} tampakrap: and if we put all packages in the same slot, we can simplify the eclasses ok about slot=0 or slot=4, that is something that only has meaning to humans, not to the PM put everything to 4 then? quick vote 0 or 4 whatever slot you want to use +1 for :4 slot 4 4 -*- ABCD doesn't care I can live with both. 0 would be more "accurate" if we don't want to have kdeprefix anymore, 4 otherwise i don't intend to slotmove all the kde-misc ebuilds again by dropping slots, we need to update all deps to use versions and not slots and we won't have kdeprefix (the actual flag might live for a short while longer, but if it does, it will just be to do pkg_setup() { use kdeprefix && die ....; ....; }) jmbsvicetto: they already do -- except when USE=kdeprefix ABCD: about 49, since 4.x.80 are 4.x+1, why not just use this? and deal with an extra number? -*- ABCD isn't sure what you're trying to say, tampakrap tampakrap: the idea is that the first release KDE will ever do of a new version is 4.x.50 that's what they've written in their release "rules" yes, but the tarballs are shown after 4.x.80 before that there is only live ebuilds sure, but since 4.x.50 is a new version, 4.x.49 should be used as the last version of a version tampakrap: they've released tarballs for alphas before, with lower numbers they won't anymore though bah, terrible language :\ they said that interested parties can get the tarballs from redmine or gitweb tampakrap: why take the chance? i don't think there is a chance here but anyway 49 it is tampakrap: 4.x.50 should never be used for version 4.x - recently the most they've been getting is 4.x.7 anyway, right? true anyway, i think we all agree here and 49 is just an arbitrary number that is definitely between the last 4.x release but before the first 4.{x+1} release (and I've hardcoded the 4.x.50 assumption in other places) ok next the "50 limit" is already in the eclass jmbsvicetto / alexxy status of migrated/ split modules? yeah do we follow upstream there? should we? besides the missing krosspython, everything else should be working I think we should (follow upstream) actualy most of migrated and splited modules has same spliting as we do on 4.6.80 we're already doing it one by one kde edu, check? https://projects.kde.org/projects/kde kdeedu we are 100% following upstream kde graphics, check? the split on our end is complete for both kde base kdegraphics, they didn't finish splitting in time for 4.6.80, but should be done for 4.6.85 (we might want to package the new mobipocket repo, though -- I'll look into that) kdebase is consisted of three monolithic and two split repos as i see so we're fine here - {Day changed to Fri Jun 3 00:00:00 2011} plus one more (kinda) monolithic repo: kate :D kwrite moved from kde-baseapps to kate kdepim/kdepim-runtime is monolithic, check yeah how are we on that area? tampakrap: they may split it kate/kwrite i mean kdepim is NOT going to get split and nothing that migrated is going to change kdepimlibs/kdelibs are monolithic on both sides last question: is the bump ready from our side? should i announce it? update docs? bump of what? 4.6.80 in general tampakrap: we should run more tests and still need to fix some stuff tampakrap: its NOT ready what's missing please? tampakrap: upstream to release a kross-interpreters tarball :D if you speak now you may get more help :P yeah, apart from that :) kdebindings =) kdebase + kdegraphics + kdemultimedia + kdenetwork + kdeedu + kdegames + kdetoys + (most of) kdeutils, should work afaik kdebindings is broken. I don't know kdepim status assuming that you disable anything that needs krosspython (pykde4 probably should work, I would think) ok, so i suppose i should not recommend people to update to it at all pykde4 build on my test system. I haven't tested it though jmbsvicetto: kdepim should work not at this stage I'd wait for a krosspython release (probably next beta) ok, so what's needed from our side? tampakrap: for the above list, I can say my testing system is running. I'm not using too many kde apps on it though I'm using it mostly as a build box, some browsing (FF), kwrite, kopete and general DE use cool thank you guys for handling it good job I haen't tested the games or kdeedu apps yet i don't have to say anything else on 4.7, if anyone has to say something speak now sorry for the commit noise, but I'm a "old grumpy" dev ;) we'll kick your ass later dilfridge: next topics are yours ho hum use flag defaults for kde subprofile (bug 365251) tampakrap: https://bugs.gentoo.org/365251 "Use flag defaults for the desktop/kde profile"; Gentoo Linux, KDE; CONF; dilfridge:kde ok... all that I listed were (as far as I remember) not in the desktop profile maybe we just go quickly through use-flags and vote whether they should be enabled in the kde profile (NOT forced of course) 1) cups - I think this is a clear usability improvement isn't the system-config printer broken? and hardmasked? eww possibly as I stated when the kde profile was created, I don't like the idea too much, but as I don't use it, I don't care cups: no we'll come back to that topic later ("open floor") ok 2) dri, xcomposite, xinerama +1 since kwin heavily relies on all that stuff 3) -gnome no this is to avoid problems like the recent glib-networking desaster don't need it -- I don't think desktop/ sets +gnome anyway :) ok then not true 4) nsplugin since konqueror provides a plugin container no opinion no strong opinion here either, so maybe lets forget about it 5) semantic-desktop :) yes! as it is needed by kdepim 6) xscreensaver to provide more eyecandy +1 opengl gles -1 on gles, I think (unless I'm mistaken) opengl +1, gles -1 as I thought that gles was primarily for embedded, or something like that but +1 on opengl kwin will work with it better then with opengl opengl is already in desktop there we go :) if you use gallium drivers that's not a reason to force it in every kde user ok that's it for me on this topic, I summarize: these are defaults, not forced :) we add the following flags to the default use flags in the kde subprofile: wait i want more ok qt, qt4 qt4 is in desktop qt? not qt is old apparently declarative yes kipi yes phonon? is that enabled already? no we should add it ok and qt3support? is this being dropped by upstream? in desktop i know if it's being dropped of 4.7 we should consider dropping it from desktop good question, I know they are working in that direction ah and plasma is that enabled? no, I'll add it to the list. qt3support maybe worth a mail to the releaseteam ok that's all "declarative dri kipi phonon plasma semantic-desktop xcomposite xinerama xscreensaver" ^ any further comments? ok then with your ok I'll add this later to the profile no, i want to announce it first ah ok fine anything else? next topic would be kdeprefix status we already discussed it i suppose yes ok next... kde-4.6.3 should be fine, i don't see bugs :) I would like to file a stablereq in a week or so (30days etc), just so stable keeps up bug reports that is ok... if there are any problems or if you have any objections, talk to me please :) that's all? from the agenda, yes *) open floor open floor- one point from me shoot i was kind of crazy enough to mail tgurr about cups-1.4 stabilization basically I can go ahead sorting the remaining bugs etc this may take some time, but at some point I hope we'll have some news there that's all ok and one point from me: we lost scarabeus, we need new people i mean, what comes next? losing jmbsvicetto? -*- jmbsvicetto slips away we should all move on to qa and recruit diego for kde :D actually, he was a kde guy long ago did not know that tampakrap: all I can say about that is that I'm trying to use my council hat to ensure we fix the issues that affected Tomas motivation Diego and Dan Armak started kde on Gentoo, I think if not, they maintained kde on gentoo for many years we need scarabeus and ssuominen back at this point and unless people change, that seems unlikely btw, meeting closed, thanks for coming