[gentoo-commits] gentoo commit in xml/htdocs/proj/en/desktop/kde/meeting-logs: kde-project-meeting-log-20110602.txt kde-project-meeting-summary-20110602.txt

[gentoo-commits] gentoo commit in xml/htdocs/proj/en/desktop/kde/meeting-logs: kde-project-meeting-log-20110602.txt kde-project-meeting-summary-20110602.txt

[Theo Chatzimichos (tampakrap)]

tampakrap    11/06/02 23:17:39

  Added:                kde-project-meeting-log-20110602.txt
                        kde-project-meeting-summary-20110602.txt
  Log:
  Log and summary of today's meeting

Revision  Changes    Path
1.1                  xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20110602.txt

file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20110602.txt?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-log-20110602.txt?rev=1.1&content-type=text/plain

Index: kde-project-meeting-log-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



1.1                  xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20110602.txt

file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20110602.txt?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-project-meeting-summary-20110602.txt?rev=1.1&content-type=text/plain

Index: kde-project-meeting-summary-20110602.txt
===================================================================
rollcall
ABCD, alexxy,dilfridge,tampakrap,jmbsvicetto

1) KDE SC 4.6.80 bump

jmbsvicetto and alexxy did a great job so far about it, with ABCD
forward-porting the commits to the live ebuilds. It is not ready yet though,
and we'd not recommended to users yet, unless they know what they are doing.
Upstream split some of the tarballs in order to follow the repos for 4.7. We
were very lucky so far, and upstream's split was very similar to ours, apart
from kdebindings, which we'll have to re-package to follow them.

2) Drop of kdeprefix useflag

The kdeprefix USE flag is announced to be dropped this Monday. As a result,
we'll have to move all ebuilds to slot 4. We could move them to 0 as well in
order to drop the slotting entirely, but since most of them are already 4 it
will prevent us from doing another massive slotmove.

3) Useflags in kde profile

It was decided these useflags to be added to the kde profile: declarative,
dri, kipi, phonon, plasma, semantic-desktop, xcomposite, xinerama,
xscreensaver

4) KDE SC 4.6.3 stabilization

First of all, dilfridge deserves congratulations for taking care the
heavy job of doing the 4.6.2 stabilization, along with Qt 4.7 and a large
number of other Qt and KDE applications. Keep in mind that this was a really
hard job to do, since the previous stable version was 4.4.5. Things are now
back in order now, with 4.6.2 fully stabilized and 4.4 completely removed
(finally). 4.6.3 is the next stabilization target, to keep stable tree up to
date.

*)Open floor

Andreas said he is interested in doing some cups work, which we hope to affect
KDE and desktop users in general.

We lost scarabeus, one of our top developers. Thus,
we'd like to remind anyone that we always appreciate the help of new people.
If you are one of the guys that already has access to the overlay, time to
complete your ebuild and end quiz then!