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