[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