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