path: root/meeting-logs/20110602.txt

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