From e60831e56d67c58fbe458bef5d364651bf4d3418 Mon Sep 17 00:00:00 2001 From: "Andreas K. Hüttel" Date: Thu, 31 Mar 2011 21:14:17 +0000 Subject: Added log of kde meeting --- meeting-logs/kde-project-meeting-log-20110331.txt | 370 ++++++++++++++++++++++ 1 file changed, 370 insertions(+) create mode 100644 meeting-logs/kde-project-meeting-log-20110331.txt (limited to 'meeting-logs') diff --git a/meeting-logs/kde-project-meeting-log-20110331.txt b/meeting-logs/kde-project-meeting-log-20110331.txt new file mode 100644 index 0000000..84ecd70 --- /dev/null +++ b/meeting-logs/kde-project-meeting-log-20110331.txt @@ -0,0 +1,370 @@ +[20:07:42] !herd kde +[20:07:42] (kde) abcd, alexxy, dilfridge, jmbsvicetto, patrick, reavertm, scarabeus, spatz, tampakrap +[20:07:43] -*- alexxy here +[20:07:47] roll call please +[20:07:49] -*- dilfridge here +[20:07:57] here +[20:08:00] -*- scarabeus blurps +[20:08:14] dilfridge: wanna chair? +[20:08:17] for change +[20:08:21] uh oh +[20:08:36] err ok +[20:09:01] hehe the topic still links to last meeting +[20:09:16] so... +[20:09:26] let's look at the agenda. +[20:09:42] 1) kde-git/eclasses migration and status +[20:09:58] since I dont do live, what's the status? +[20:10:23] scarabeus: ^^ git eclass status? +[20:10:47] -*- ABCD can't stay too long +[20:10:48] i got nice hint from exherbo guys and currently am attempting it to make bare checkouts even with submodules +[20:10:57] so if i manage to do that it would be epic +[20:11:17] oook, I remember the discussion on the ml +[20:11:20] but i didnt have time to focus on it lately +[20:11:22] can i get an option to use non-bare checkouts instead? +[20:11:25] as i blaged +[20:11:42] it is easy to override those commands as-is already +[20:12:07] i guess the more interesting question is does it still work then +[20:12:34] -*- dilfridge can symlink /bin/echo to /usr/bin/portage +[20:12:55] but anyway +[20:13:33] the hard question: scarabeus: what's your guess how long this will take? very roughly? +[20:13:52] few days when i work on it so i can test everything +[20:14:18] afaik kde eclasses don't need anything, we are only waiting for git-2 to hit tree first +[20:14:26] correct me if i'm wrong +[20:14:54] if it is so it is quite easy to make them git.eclass dependant +[20:15:17] since there are no live ebuilds in main tree it does not affect anything by default +[20:15:18] meaning they would also work with current git.eclass? +[20:15:32] ah ok +[20:15:51] yeah, i'll prefer those eclasses to hit tree before 4.6.2 +[20:16:07] so we can get proper testing from the stable candidate +[20:16:07] that could be pretty soon (today is official tagging day) +[20:16:26] yeah, this week +[20:17:11] do you want to selectively patch the main tree eclass or just copy everything from overlay (better)? +[20:17:14] can you paste us the link of the topics please? +[20:17:38] http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/maintainers/meetings/meeting-2011-03-31;hb=HEAD +[20:17:48] i'd like a quick review first, a patch in the alias or in -desktop would be preffered +[20:18:03] ok +[20:18:22] I'm asking because we "collect differences" between tree and overlay +[20:18:46] i would like to hear from reavertm before merging them +[20:18:47] at some point it would make sense to sort this out +[20:18:50] true +[20:18:54] we could ask for comments on -dev as is +[20:19:01] i don't know if he had any todo for the eclasses we are missing +[20:19:07] or that +[20:19:09] at least you others could work on the stuff people point out +[20:20:01] so, summarizing: we should do a review of the current overlay eclasses... +[20:20:08] yup +[20:20:10] * figure out what actually depends on git-2 +[20:20:15] why +[20:20:18] that does not matter +[20:20:26] i can move it to git.eclass in 20 secs +[20:20:32] git-2 is not showstopper +[20:20:35] ok +[20:20:40] even better +[20:21:20] * collect a todo list (or make reavertm send us his) +[20:21:37] * and review the current differences between tree and overlay +[20:21:53] any volunteers? :D +[20:22:28] i'm not the eclass expert +[20:22:39] anyway +[20:22:48] back to teh agenda +[20:23:01] 2) move kdepim 4.6 beta in tree masked? +[20:23:07] opinions? +[20:23:13] no +[20:23:18] 1) it is outdated +[20:23:24] true +[20:23:24] 2) it depends on updating eclasses first +[20:23:27] 2) there is no eclass support for it yet :P +[20:23:30] true +[20:23:39] but anyway, it is too outdated +[20:23:49] anyone in favour? +[20:24:07] and upstream kdepim will create new kdepim snapshots when a core kde developer asks to +[20:24:13] huge mess +[20:24:22] wtf +[20:24:27] they should release that shitz :D +[20:24:28] i could create our own snapshots, but i don't care enough to be honest +[20:24:34] I guess that answers the question +[20:24:36] most people are getting annoyed :) +[20:24:47] any news about an official release (schedule)? +[20:25:14] no +[20:25:21] :( +[20:25:26] tampakrap: is there any kdepim version that can work with 4.5.5, 4.6* ? +[20:25:28] kde* +[20:25:28] they said about an rc1 but apparently it didn't make it +[20:25:35] yes, 4.4.10 +[20:26:12] tampakrap: so we can use kdepim-4.4.10 with kde-4.5.5/4.6 to move forward? +[20:26:32] seems so +[20:26:40] and sorry for anticipating the next point +[20:26:42] if you are talking about a stable candidate, yes, 4.4.10 is fine +[20:26:55] yes +[20:27:20] ok... following the logical order of things instead of the numerical one... +[20:27:32] 5) 4.6 status / stabilization / important bugs +[20:27:48] apart from the blockers list on the tracker, no idea +[20:27:53] major is that akonadi integration in basic pkgs +[20:28:01] and i guess that tracker catched everything +[20:28:05] we have 5 or 6 major blockers, i am aware of all of them +[20:28:13] what akonadi integration? +[20:28:28] given the current status with upstream about 4.6, anyone sees any reason to delay getting 4.5.5 marked stable instead of keep waiting for a possible 4.6 stable candidate? +[20:28:30] the -semantic-desktop failure bug? +[20:28:33] yep +[20:28:57] 4.5.5 is completely broken +[20:29:23] general question: how many of you get akonadi errors on login? +[20:29:40] i don't +[20:29:49] and i use kdepim and kdepimlibs master +[20:30:03] tbh, I never checked +[20:30:33] I always get and have not been able to solve that... maybe I should start collecting info... +[20:30:37] ok +[20:30:44] I use what I was forced to use with 4.6.1 (having to enable semantic-desktp) +[20:30:56] let's have a quick look at the blockers +[20:31:19] three of them are about -semantic-desktop and -kdepimlibs support +[20:31:28] one is about kdepim 4.4.10 translations +[20:31:34] i don't remember the others +[20:31:42] Bug 353048 +[20:31:44] dilfridge: https://bugs.gentoo.org/353048 "kdebase/kwin-4.6 USE=-opengl does not compile"; Gentoo Linux, KDE; NEW; sefi:kde +[20:31:51] this is fixed upstream +[20:32:05] and the fix may be in 4.6.2 if it is backported in 4.6 branch +[20:32:34] Bug 353726 +[20:32:35] dilfridge: https://bugs.gentoo.org/353726 "kde-base/plasma-workspace-4.6.0 should not depend on kdepimlibs"; Gentoo Linux, KDE; REOP; ikandros:kde +[20:32:41] yeah i mentioned that +[20:32:56] i'm on it +[20:33:16] Bug 353730 +[20:33:19] dilfridge: https://bugs.gentoo.org/353730 "kdeplasma-addons-4.6.0 USE=-semantic-desktop fails to build without akonadi/semantic-desktop"; Gentoo Linux, KDE; REOP; KeithBHarrison:kde +[20:33:23] this is probably related +[20:33:25] and that +[20:33:41] Bug 357545 +[20:33:43] dilfridge: https://bugs.gentoo.org/357545 "kde-l10n-4.6.1 wants to overwrite kde-misc/konq-plugins-4.4.0-r1 files"; Gentoo Linux, KDE; NEW; panard:kde +[20:33:53] no idea, scarabeus^^ +[20:33:56] that should HOPEFULLY be fixed with 4.6.2 +[20:34:02] as it is pretty trivial +[20:34:11] tampakrap: i told you that they have to use konq-plugins-4.6.1 +[20:34:19] tampakrap: if they do so no clashes +[20:34:28] ok, so we should adjust deps +[20:34:33] dilfridge: plz2fix +[20:34:34] they got the release of 4.6.1 completely screwed up there +[20:34:50] later +[20:35:03] Bug 357959 +[20:35:04] no blocker, remove it from the list please +[20:35:05] https://bugs.gentoo.org/357959 "kde-base/nepomuk-4.6.1: nepomuk service stub crashes after update"; Gentoo Linux, KDE; NEW; dilfridge:kde +[20:35:09] or lower severity +[20:35:30] done +[20:35:41] your nepomuk bug, can't reproduce +[20:35:42] that one is pretty annoying but an upstream problem +[20:35:46] a user reported something +[20:36:09] yes but I dont think it is gentoo-only +[20:36:18] hey, upstream says it is fixed +[20:36:32] yes 462 +[20:36:34] good +[20:37:40] Bug 359979 +[20:37:41] dilfridge: https://bugs.gentoo.org/359979 "media-libs/xine-lib crash with MKV WebM"; Gentoo Linux, Applications; ASSI; rezbit.hex:media-video +[20:37:44] a bit obscure +[20:37:47] huh? +[20:37:52] vlc is default +[20:37:55] kde upstream says it's a xine-lib bug +[20:38:10] probably this should not be a blocker either +[20:38:15] oh guys +[20:38:16] I think we should close all phonon-xine bugs as CANTFIX +[20:38:23] i would make phonon-gstreamer default +[20:38:26] not the vlc +[20:38:28] blocker removed +[20:38:35] i find bit stupind to demand videoplayer +[20:38:36] for that +[20:38:41] not phonon-gstreamer, please +[20:38:46] -*- dilfridge bangs on the table... open floor is later :) +[20:39:03] ok back to the actuall agenda +[20:39:05] dilfridge: open floor is for people outside the team ;) +[20:39:17] jmbsvicetto: so you rather pull in the vlc? +[20:39:18] :) +[20:39:29] xine does not work +[20:39:34] scarabeus: I think that's what upstream expects us to use as default +[20:39:40] so do we agree we should consider 462 as "potential stable candidate"? +[20:39:43] (I'm not sure though) +[20:39:45] scarabeus: if you consider webkit part of the environment, then you'll need a video player ;) +[20:39:47] i didnt see it yet +[20:40:02] jmbsvicetto: gstreamer can manage over phonon +[20:40:07] jmbsvicetto: and i use mplayer +[20:40:11] I don't think we should see 462 as a stable candidate +[20:40:19] jmbsvicetto: well we have to +[20:40:22] one magic word +[20:40:23] HAL +[20:40:29] why not? +[20:40:30] :| +[20:40:33] +1 +[20:40:39] that releases will be broken forewer +[20:40:39] hal should be dropped +[20:40:45] just take look on what upstream does :) +[20:40:52] because I don't believe they'll be able to "not break" kdegraphics on this release +[20:40:55] so we just have to bite it and sadly release somehow +[20:40:58] +1, unless upstream breaks 4.6.2 even worse +[20:41:09] It's not about "stability" or it working, but about KDE being able to package the release +[20:41:33] well 4.6.1 works pretty well +[20:41:37] yes but I expect that the kde git migration will take another century or so +[20:41:46] alexxy: minus the semantic-desktop stuff ;) +[20:41:47] (while we dont even start...) +[20:41:53] yeah +[20:42:02] I don't expect it to *ever* be completely done -- see kde-wallpapers +[20:42:02] also we still need kdepim stuff +[20:42:06] hey, infra is busy +[20:42:38] oook +[20:42:39] tampakrap: My only issue with 4.6.2 is that I expect us to get a broken release (packaging wise). If the regressions about akonadi/pimlibs get fixed, I have no issue with it being marked stable +[20:42:40] and they again doing something with git,kde.org and projects.kde.org +[20:42:46] i said already kdepim 4.4.10 is fine along 4.6, don't make me repeat it in caps +[20:42:58] I still antecipate we may get some "angry" users, but there's little we can do about it +[20:43:15] we'll always get some angry users +[20:43:18] those are issues with the sponsors, even we have those kind of issues +[20:43:21] actualy now i see how childish i was when i look on the tiny issues with 4.5 ;P +[20:43:21] don't confuse things +[20:43:24] anyway +[20:43:32] we can talk about that again in three weeks +[20:43:35] i could've stabled some of that :) +[20:43:48] yes. +[20:43:50] nah i would give it 14 days for the stablebug if everything works +[20:44:06] we are behind schedule for that stuff for freedesktop stuff +[20:44:14] 3 weeks is 1 week after tagging, 2 weeks after release +[20:44:20] yep works +[20:44:23] well given that kde-462 will take another week or so, we can for sure have another meeting before the stablebug filing +[20:44:38] ok +[20:44:42] we are not behind if samuli is acting like a maniac about hal without proper documentation / announcements +[20:44:49] true +[20:44:53] <+willikins> New bug: https://bugs.gentoo.org/?????? Marked KDE-4.6.2 stable (URGENT) - HAL needs to die +[20:44:57] scarabeus: ^^ ? ;) +[20:45:08] DIE DIE DIE +[20:45:09] jmbsvicetto: something like that +[20:45:19] btw we can smash in solid4.6 +[20:45:19] :D +[20:45:25] and pretend everything is perfect xD +[20:45:37] so +[20:45:41] now for the optional stuff +[20:45:45] scarabeus: you mean solid-4.5? +[20:45:46] also there can be another issue +[20:45:55] because of nm-0.9 stuff +[20:45:59] nm? +[20:46:05] networkmanager +[20:46:07] what about it? +[20:46:09] jmbsvicetto: nah, hal is out since 4.6 :) so we can stable just solid :P +[20:46:11] new api +[20:46:14] totaly different +[20:46:18] but it does not matter +[20:46:23] current solid will not work with it at all +[20:46:23] since knetworkmanager is already working on it +[20:46:27] and it wont use solid at all +[20:46:43] ok +[20:46:46] i know +[20:46:52] scarabeus: right, so you want to kill solid-4.5 :P +[20:46:57] and they working on solid backend for it +[20:47:11] jmbsvicetto: 4.4 +[20:47:11] better to kill kde < 4.6 +[20:47:19] jmbsvicetto: we talk about stable :D +[20:47:38] what alexxy said +[20:48:37] so, summary: need some stable kde-4.6 in the near future, as the pressure is rising(tm) +[20:49:08] next point +[20:49:16] 3) Shall we drop useflag kdeprefix to simplify code? +[20:49:16] "The problem is that bindings are not prefixed, and a possible fix (proposed +[20:49:16] by reavertm) would be to slot sip. tampakrap said he'll work on this, and bring +[20:49:16] the topic back in next meeting." +[20:49:39] any news? +[20:49:41] can i get another month please? +[20:49:45] busy with gsoc proposal +[20:49:49] does any of us use kdeprefix? +[20:49:58] i started using it +[20:50:05] you're the boss, but does anyone actually use it? +[20:50:05] but i'm still stuck on my 4.6 +[20:50:08] hmm +[20:50:26] it's masked i don't see why you want to drop it +[20:50:33] for testing better to use VMs +[20:50:34] if we drop kdeprefix, we can simplify a *lot* of things -- including slotmoving everything to :4 +[20:50:38] like lxc or xen +[20:50:52] no it isn't better +[20:50:53] and the eclasses will be much simpler +[20:50:55] alexxy: or even just a chroot +[20:50:59] i will have to maintain to boxes then +[20:51:11] its simple +[20:51:20] share binary packages across them +[20:51:23] My feeling for a long time is that kdeprefix also needs to die +[20:51:30] it's not simple +[20:51:34] use KSM to save your memory +[20:51:36] and so on +[20:51:38] different use flags different configurations +[20:51:46] it's not a resource problem +[20:51:57] it'a a pain in the neck having to maintain an extra box +[20:52:05] wait, sorry, I mean kdeenablefinal, not kdeprefix +[20:52:08] its not too hard +[20:52:30] I liked kdeprefix, but as it needs upstream work and we can't get their collaboration, I no longer object to killing it +[20:52:30] ok, let me disagree +[20:52:45] anyway, i want that useflag but if you guys want we can go on a vote +[20:52:59] -*- alexxy running many VM's @works to test new stuff (like experimental gromacs patches and so on) +[20:53:02] -*- ABCD votes to kill it +[20:53:09] -*- alexxy also +[20:53:12] -*- dilfridge votes to kill it +[20:53:57] -*- jmbsvicetto abstains +[20:54:29] I'd say since that is less than 50% of the team we dont change anything for now. +[20:54:43] make vote over ml so everyone state the opinion +[20:55:10] for now decision postponed again +[20:55:17] next point +[20:55:26] 4) Making +consolekit and +policikit on by default or removing the useflags as whole (non working stuff run-as is annoying) +[20:55:26] "No consensus was reached, the topic will be continued in the gentoo-desktop mailing list." +[20:55:26] Mailing list query resulted in two user voices for "default on but still configurable" +[20:55:30] I have to leave now, as I have a meeting in ~1 hour that's ~55 minutes away +[20:55:38] cya +[20:55:41] cu +[20:55:44] about the flags, people want them +[20:55:59] additionally people want udev deps optional as well +[20:56:00] yes but do we want to maintain them? +[20:56:22] i still support the profile/kde and use.force solution +[20:56:33] udev deps at least have to be removed with USE=prefix +[20:56:39] tampakrap: udev and policykit optional deps needed to have kde on kernels other than linux +[20:56:58] and prefix can't do udev/polkit/consolekit +[20:57:14] I don't see a point for the kde profile, but I just use linux/amd64/10.0 +[20:57:25] *bsd/solaris/hurd cant have udev +[20:57:44] polkit may still work +[20:58:16] dilfridge: are the above sufficient to you? +[20:58:22] anyway. are there any objections to making +consolekit and +policykit on by default in the ebuilds, and forcing them in the kde profile? +[20:58:28] so if we will have udev deps unconditional we should drop prefix/*bsd and all non native linux stuff +[20:58:48] dilfridge: I don't have an issue with IUSE defaults and don't use the kde profile +[20:58:59] yeah no objections +[20:59:01] dilfridge: its good idea +[20:59:07] ok +[20:59:13] alexxy: I'd prefer to maintain prefix compatiblity, if possible +[20:59:25] then we go with that I'd say +[20:59:32] last point +[20:59:35] open floor +[20:59:53] anything else to discuss? +[20:59:56] also gentoo prefix can be used instead of kdeprefix =D +[21:00:10] well +[21:00:28] alexxy: that is actually interesting... gentoo on gentoo :))) +[21:00:28] we again have problems with arches like x86-fbsd ppc* +[21:00:45] -*- alexxy uses prefix on rhel4 cluster +[21:01:09] alexxy: ppc is still recovering from their lost boxes +[21:01:13] what problems? +[21:01:26] unkeyworded deps as usual +[21:01:30] I need to resume my discussion from council with arch teams +[21:01:42] oh +[21:01:50] yeah but xarthisius is pretty helpful and responsive +[21:01:52] that's their problem, not ours +[21:02:28] last time i masked some use flags or whole kde release on arm ppc ppc64 and x86-fbsd +[21:02:28] it's mainly about giving a friendly poke if something is really needed I think +[21:03:17] I dont know nothing about x86-fbsd +[21:03:46] i dont know anybody who is using it +[21:03:48] ok +[21:04:00] but kde has ~x86-fbsd keywords +[21:04:03] dilfridge: aballier +[21:04:29] yes but aballier afaik was only contact to a user somewhere +[21:04:45] !bug 357403 +[21:04:46] https://bugs.gentoo.org/357403 "[KDE] Please keyword kde-4.6 deps to unmask needed useflags"; Gentoo Linux, Ebuilds; NEW; alexxy:kde +[21:05:04] dilfridge: he lost his bsd boxes +[21:05:06] well i can setup x86-fbsd VM +[21:05:14] ok +[21:05:46] If I find time to reconfigure my home network I can do arm at some point +[21:05:48] i may already have one +[21:05:49] http://choqok.gnufolks.org/2011/03/choqok-is-going-to-leave-kde-for-gnome/ +[21:05:52] he would like to resume his work on bsd +[21:06:04] dilfridge: what arm board do you have? +[21:06:11] openrd +[21:06:57] so, summary: about keywords nothing really changed :] +[21:07:06] anything else? +[21:07:21] or shall we call it a day? +[21:08:14] -*- dilfridge takes this as "no, and yes" +[21:08:26] I'll post the log +[21:08:33] could one of you please make the summary? +[21:08:40] i'll handle the summary +[21:08:43] ok cool +[21:08:46] tomorrow, i'm about to pass out +[21:08:49] :) +[21:09:16] cheers and thanks for being here :D -- cgit v1.2.3-65-gdbad