diff options
author | 2009-09-17 21:13:41 +0000 | |
---|---|---|
committer | 2009-09-17 21:13:41 +0000 | |
commit | d60211faee09a52fb9c2c8dd9c97a6e452df670d (patch) | |
tree | f2b89825eaa09d558eb97d206409be85a75bb86b | |
parent | Added the log and summary for the 20090820 KDE meeting. (diff) | |
download | kde-d60211faee09a52fb9c2c8dd9c97a6e452df670d.tar.gz kde-d60211faee09a52fb9c2c8dd9c97a6e452df670d.tar.bz2 kde-d60211faee09a52fb9c2c8dd9c97a6e452df670d.zip |
Added IRC log for KDE project's 20090917 meeting.
-rw-r--r-- | meeting-logs/kde-project-meeting-log-20090917.txt | 572 |
1 files changed, 572 insertions, 0 deletions
diff --git a/meeting-logs/kde-project-meeting-log-20090917.txt b/meeting-logs/kde-project-meeting-log-20090917.txt new file mode 100644 index 0000000..5cbdcf5 --- /dev/null +++ b/meeting-logs/kde-project-meeting-log-20090917.txt @@ -0,0 +1,572 @@ +[22:01:31] *** Joins: wired (n=wired@gentoo/developer/wired) +[22:01:32] *** Joins: ayoy (n=ayoy@cs78245237.pp.htv.fi) +[22:01:55] *** Joins: dabbott (n=david@gentoo/developer/dabbott) +[22:02:07] *** Joins: toralf (n=toralf@g224122197.adsl.alicedsl.de) +[22:02:33] *** Joins: Battousai (n=bryan@maduin.southcape.org) +[22:03:44] * wired makes sure logging is on +[22:04:59] *** Parts: Pesa (n=Pesa@bluemchen.kde.org) +[22:05:07] <reavertm> I'm here +[22:05:09] *** Joins: Pesa (n=Pesa@bluemchen.kde.org) +[22:05:39] <wired> scarabeus: jmbsvicetto? +[22:05:44] *** Quits: ABCD (n=ABCD@gentoo/developer/abcd) (Read error: 104 (Connection reset by peer)) +[22:06:02] *** Joins: ABCD (n=ABCD@gentoo/developer/abcd) +[22:07:24] *** Quits: |Francis| (n=kvirc@AGrenoble-152-1-48-33.w82-122.abo.wanadoo.fr) (Remote closed the connection) +[22:07:35] <reavertm> wasn't it moved to friday? :P +[22:08:02] <wired> scarabeus sent "correction" email +[22:08:02] <wired> :p +[22:09:06] <jmbsvicetto> oh, I was already here +[22:09:08] <wired> yeah +[22:09:11] <wired> didn't i hilight you? +[22:09:18] <wired> :P +[22:09:25] <spatz> scarabeus said he might not make it, who else is late? +[22:09:25] <ABCD> I'm not sure how well my connection is going to hold up, so... +[22:09:29] <jmbsvicetto> Yeah, but I had forgot I was around here +[22:10:27] * jmbsvicetto makes mental note - win 76 +[22:10:29] <jmbsvicetto> Anyone logging? +[22:10:37] <reavertm> everytbody +[22:10:43] <wired> i am +[22:10:55] <wired> yngwin won't be coming, scarabeus too +[22:10:56] <jmbsvicetto> ok +[22:11:02] <wired> we're missing patrick, tampakrap +[22:11:11] <reavertm> and some more qt representatives +[22:11:26] <wired> ayoy spatz and Pesa are here +[22:11:33] <wired> hwoarang is on long devaway +[22:11:36] <jmbsvicetto> Let's give them a few more minutes? +[22:11:38] <ayoy> yngwin is away too +[22:11:47] <spatz> we're waiting for bonsaikitten? +[22:12:05] <wired> i pinged them +[22:12:07] *** Joins: bonsaikitten (i=quassel@gentoo/developer/bonsaikitten) +[22:12:08] <spatz> good, on his way :) +[22:12:19] *** Joins: tampakrap (n=tuxicity@gentoo/developer/tampakrap) +[22:12:29] <wired> good +[22:12:43] <jmbsvicetto> So, who wants to chair this one? +[22:13:01] <jmbsvicetto> I could use the break to get ready another thing I'm working on +[22:13:34] <tampakrap> hello +[22:14:14] <wired> jmbsvicetto: i'll do it +[22:14:45] <reavertm> good, do we have decisive power? +[22:14:46] <wired> lets get going, first topic, 4.3 stabilization +[22:14:58] <jmbsvicetto> wired: thanks +[22:15:04] <reavertm> to vote stuff and such? it's quite few of us +[22:15:26] <tampakrap> wired: roll call first +[22:15:47] <spatz> here +[22:15:58] <jmbsvicetto> reavertm: I don't think we have much to vote today. It's more about getting processes started +[22:16:02] <jmbsvicetto> here +[22:16:04] <wired> that was done, but present yourselves for the record if you want :) +[22:16:26] <tampakrap> here +[22:16:38] <ayoy> here +[22:16:46] <reavertm> i am +[22:16:56] <reavertm> ok, wired, move on +[22:17:20] <wired> first topic, kde 4.3 stabilization +[22:17:26] <wired> are we still going with 4.3.1? +[22:17:34] *** Parts: Pesa (n=Pesa@bluemchen.kde.org) +[22:17:38] <ABCD> here +[22:17:52] <reavertm> yaah, we're going with 4.3.1, I wanted to bring this topic to... +[22:18:14] <reavertm> gather some manpower to fix blocker bugs (or talk about dropping some blockers) +[22:18:38] <wired> are there any specific blocks we should focus on? +[22:18:50] <reavertm> https://bugs.gentoo.org/show_bug.cgi?id=277868 +[22:18:50] <spatz> is there a list/tracker? +[22:18:54] <reavertm> this is bug +[22:19:09] <wired> btw meeting agenta: http://archives.gentoo.org/gentoo-desktop/msg_1abe5bf232579eabb51aadc3d80b397b.xml +[22:19:15] <jmbsvicetto> wired: yes +[22:19:18] <wired> in case you don't have the mail available +[22:20:10] <wired> 12 bugs +[22:20:18] <jmbsvicetto> One thing we need to do ASAP is adding the patches being sent to the packagers ml +[22:20:28] <wired> i agree +[22:21:14] <wired> if we could focus these 2 weeks ideally we could request stablereq right after the 1 month period +[22:21:26] <reavertm> yes +[22:21:38] *** Joins: [Enrico] (n=chiccoro@gentoo/contributor/Enrico) +[22:21:49] <reavertm> I've already set java as default backend so one bug less (about redland crashing) +[22:21:58] *** Joins: Pesa (n=Pesa@bluemchen.kde.org) +[22:22:03] <wired> great +[22:22:03] <reavertm> and there's postinst message +[22:22:35] <wired> so guys please do your best so we can finally have kde4 in stable :D +[22:22:43] <jmbsvicetto> We should also start opening stabilization bugs for deps: automoc, strigi, soprano, phonon. Anything else? +[22:23:04] <wired> are we stabling the phonon snapshot? +[22:23:22] <reavertm> yes, it works fine +[22:23:30] <reavertm> (it has unstable API) +[22:23:44] <wired> well it'll have to do if thats all we've got +[22:23:58] <reavertm> it's known to work anyway +[22:24:05] <wired> ok +[22:24:08] <jmbsvicetto> what's the minimum working version? +[22:24:25] * wired looks ar reavertm +[22:24:29] <wired> at +[22:24:38] <jmbsvicetto> And we need to get it stable or there'll be no stable KDE-4.3.1 +[22:25:12] <reavertm> 4.3.1 should od +[22:25:23] <reavertm> do +[22:25:33] <reavertm> but... mplayerthumps would need changes +[22:25:48] <jmbsvicetto> By the way, we're including KDE-4.3.1 in the 10.0 livedvd, so we should try to get it stable around October 4th +[22:25:49] <reavertm> (disabling phonon backend - as it only works with latest phonon) +[22:25:59] <reavertm> otherwise kde would pull mplayer... +[22:26:22] <jmbsvicetto> reavertm: can 't we leave it out? (mplayerthumbs) +[22:26:39] <reavertm> why should we? part of kdemultimedia +[22:27:00] <wired> whats wrong with having mplayer as a dep (besides an extra dep)? is it not working ok? +[22:27:44] <wired> reavertm? +[22:27:45] <reavertm> I suppose it is, whatever if you like one could go with 4.3.1 phonon and that change in mplayerthumbs +[22:28:08] <jmbsvicetto> reavertm: I mean if it's too much trouble to get it working with current deps, we can leave it out for now and get it marked stable later (perhaps even on 4.3.2 or later releaes) +[22:28:11] <reavertm> I won't die for this cause, 4.4pre is just not worse than 43.1 +[22:28:34] <wired> jmbsvicetto: well we have tested the phonon snapshot extensively +[22:28:47] <jmbsvicetto> wired: ok +[22:29:04] <jmbsvicetto> as long as its an exception (snapshots) ;) +[22:29:10] <reavertm> I even asked some kde devs about it :P +[22:29:36] <wired> jmbsvicetto: is there an issue with stabling it +[22:29:36] <wired> ? +[22:29:43] <wired> ok +[22:29:52] * wired kicks isp for lag +[22:30:07] <wired> anyone else wanna say anything about stabilization? +[22:30:25] <reavertm> apart from get to work? :) +[22:30:30] <tampakrap> yeah +[22:30:43] <tampakrap> it isn't possible to have it fully stabilized until october 4th +[22:30:58] <bonsaikitten> well, we need more stable testers ... +[22:31:42] *** Joins: alexxy (n=alexxy@gentoo/developer/alexxy) +[22:31:48] <wired> alexxy :) +[22:31:51] <alexxy> hi all! +[22:31:53] <reavertm> bonsaikitten: I use stable system :P +[22:31:59] <alexxy> sorry that i'm late +[22:32:02] <bonsaikitten> ooh :) +[22:32:14] <reavertm> (with exceptions for kde and its deps) +[22:32:15] <alexxy> isnt meeting was schedulet for tommorow? +[22:32:22] <reavertm> initially it was +[22:32:24] <wired> alexxy: scarabeus sent a correction email +[22:32:25] <tampakrap> the problem is that the one month period is beyond that date +[22:32:28] <wired> he failed at the date +[22:32:31] <reavertm> nevermind, you missed nothing +[22:32:43] <tampakrap> not to mention the time that arch teams need +[22:33:15] <wired> tampakrap: no its not, you added the ebuilds on sept 1st +[22:33:15] <wired> the problem is getting archs to stable it in 3 days +[22:33:15] <wired> assuming we have fixed bugs +[22:33:33] <tampakrap> one month with no open bugs +[22:33:50] <jmbsvicetto> wired: 4.4_pre? Preferably we should do 4.3.1 instead, but if 4.4_pre solves other issues, let's go with it +[22:33:54] <tampakrap> i hope i'm wrong on this one... +[22:34:16] <jmbsvicetto> tampakrap: sure, but we can start the work to get it marked stable asap +[22:34:30] <wired> jmbsvicetto: 4.4_pre20090520 yeah, thats the one we have in ~testing now +[22:34:50] <jmbsvicetto> tampakrap: we can file an "early request" bug +[22:35:00] <jmbsvicetto> tampakrap: it's up to arch teams whether they want to mark it stable or not +[22:35:02] <tampakrap> ah ok then +[22:35:07] <wired> and we also have one extra motive +[22:35:09] <jmbsvicetto> tampakrap: and for the livedvd we only need amd64/x86 +[22:35:10] <wired> livedvd +[22:35:33] <tampakrap> ok let's hope this will work then +[22:35:47] <wired> I recommend we do a mini meeting next week +[22:35:56] <reavertm> may be +[22:35:57] <wired> to check on the state of bugs +[22:35:59] <jmbsvicetto> tampakrap: Besides, I think we're starting to have many amd64/x86 users on KDE-4 +[22:36:00] <tampakrap> nice idea +[22:36:16] <jmbsvicetto> wired: good idea +[22:36:49] <wired> same day next week? 24th? +[22:37:20] <tampakrap> fine by me +[22:37:35] <wired> great, i'll send the email, we can adjust if needed +[22:37:36] <jmbsvicetto> wired: sure +[22:37:57] <wired> lets do our best and close all bugs :D +[22:38:07] <wired> ok enough with this then, lets proceed +[22:38:17] <wired> kde3.5, kde-sunset +[22:38:28] <wired> who's taking care of this and can give us an update? +[22:38:33] <wired> tampakrap?/ +[22:38:41] <tampakrap> there is no progress in that subject +[22:38:59] <tampakrap> apart from the fact that scarabeus created the overlay :P +[22:39:01] <jmbsvicetto> On that spirit, I'd like to ask all of you interested in the livedvd to join #gentoo-ten get the ISOs, test them and fix any KDE bugs +[22:39:06] <reavertm> so nobody is interested - good :) +[22:39:19] <wired> reavertm: heh +[22:39:20] <jmbsvicetto> I'm "owing" an email about it +[22:39:28] <wired> jmbsvicetto: lol click send +[22:39:48] <jmbsvicetto> The official email putting the "death seal" on KDE-3.5 +[22:39:51] *** Parts: Pesa (n=Pesa@bluemchen.kde.org) +[22:39:55] <wired> ah that one +[22:40:25] <wired> is anyone else interested in helping make the move to kde-sunset? +[22:40:39] <wired> besides tampakrap? :P +[22:40:45] <reavertm> no! +[22:40:53] <reavertm> it should rot and die +[22:40:56] <jmbsvicetto> hehe +[22:40:56] <wired> reavertm: think positive, we'll get rid of it from the tree +[22:40:58] <wired> :D +[22:40:58] <tampakrap> i agree noone else is needed +[22:41:07] <tampakrap> we just need to stabilize kde4 and kill 3 +[22:41:08] <jmbsvicetto> wired: I can help move the ebuilds there +[22:41:22] <wired> great +[22:41:34] <wired> not sure if we need scarabeus to give us access to it or if he added us all +[22:42:03] <wired> ok, next item +[22:42:06] <wired> kdeprefix +[22:42:09] <tampakrap> wait +[22:42:12] <tampakrap> about kde3 +[22:42:15] <wired> yeah? +[22:42:26] <tampakrap> i have set some rules before moving ebuilds to kde-sunset +[22:42:49] <wired> you should make Documentation/CODE +[22:42:50] <tampakrap> i sent them in the previous meeting through scarabeus because i wasn't present then +[22:42:55] <tampakrap> ah ok +[22:43:05] <tampakrap> nice idea #2 +[22:43:25] *** Joins: Pesa (n=Pesa@bluemchen.kde.org) +[22:43:29] <wired> OK +[22:43:34] <wired> anyone else anything about kde3? +[22:44:06] <wired> moving on then +[22:44:08] <wired> kdeprefix +[22:44:18] <wired> not sure what scarabeus had in mind when he added it to agenda +[22:44:32] <wired> perhaps removing it completely? +[22:44:49] <reavertm> I think there's no need to drop it from eclass +[22:44:51] <reavertm> to much work :P +[22:44:59] <alexxy> well its not usable in current state +[22:45:06] <reavertm> and its masked +[22:45:08] <alexxy> and it causes much more bugs +[22:45:22] <jmbsvicetto> wired: I asked him to add this point to the agenda +[22:45:25] <alexxy> so let it stay masked =) +[22:45:33] <reavertm> we explicitly don't support any kdeprefixed installations +[22:45:41] <wired> jmbsvicetto: ok, what did you have in mind? +[22:46:09] <jmbsvicetto> The point is we should send an email letting those using kdeprefix of the new breakage and warning them they should really move out of +kdeprefix +[22:46:25] <reavertm> I think we should still keep code in mind that it may be enabled as some point +[22:46:25] <jmbsvicetto> +know +[22:46:36] <reavertm> but this mail is needed +[22:47:07] <wired> jmbsvicetto: ok, but they should know already, portage should have screamed when we masked it +[22:47:28] <wired> but an email (and perhaps a blog post, i could do that) would help +[22:47:42] <jmbsvicetto> That's all I'm after +[22:47:44] <Pesa> a news item maybe? +[22:47:50] <spatz> post a sticky in the forums, many go there +[22:48:05] <reavertm> I think it is mentioned already +[22:48:13] <reavertm> in stick in Desktop Environment +[22:48:33] <wired> okay.. who wants to send the email? +[22:48:52] <reavertm> Gentoo KDE Lead volunteered, no? :) +[22:49:10] *** Parts: [Enrico] (n=chiccoro@gentoo/contributor/Enrico) +[22:49:10] <jmbsvicetto> hehe +[22:49:11] <wired> (jmbsvicetto) The point is we should send an email +[22:49:16] <jmbsvicetto> I did +[22:49:30] <wired> :) +[22:49:31] <wired> ok +[22:49:34] <wired> I'll write a blog post +[22:49:57] <wired> anyone else have anything on kdeprefix? +[22:50:18] * reavertm will add one quick point to agenda later +[22:50:18] <wired> moving on +[22:50:26] <wired> qt 4.5 +[22:50:43] <wired> some people (and some qt devs apparently?!) say its broken with gcc 4.4 +[22:50:54] <reavertm> is everyone aware of the problem? if not, then qt-4.5 may break with 4.4 +[22:50:58] <alexxy> wired: i dont see any breakages +[22:51:00] <ayoy> do we have any evidence? +[22:51:03] <alexxy> with gcc-4,4 +[22:51:07] <wired> not any im aware of +[22:51:11] <reavertm> (apparently when strict aliasing is enabled) +[22:51:36] <wired> well +[22:51:39] <reavertm> gcc-4.4. is officially not supported (well, not listed in supported), for 4.5 +[22:51:57] <spatz> I remember someone reporting breakage with 4.4, and Sput confirming it's known to break, but I personally use it successfully +[22:52:00] <tampakrap> isn't it in stabilization process though? +[22:52:03] <jmbsvicetto> All I can say is that I haven't noticed any KDE-4.3.1 program crashing with qt-4.5.2 and gcc-4.4 +[22:52:06] <reavertm> and portage already spits QA warnings with gcc-4.3.2 +[22:52:11] <wired> does ANY of you have issues with qt 4.5 and gcc 4.4{,.1}? +[22:52:11] <wired> cause so far its all blah blah blah +[22:52:11] <wired> but no evidence +[22:52:38] <wired> i say its FUD until proved otherwise by bug reports +[22:53:07] <Pesa> no problem here, but gcc's warnings are quite scary +[22:53:24] <ayoy> Pesa: what warnings? :) +[22:53:27] <reavertm> I'll ask thiago about details and get back on next meeting (should have done it already..) +[22:53:33] <Pesa> about strict aliasing +[22:53:36] <wired> reavertm: alright +[22:53:42] <wired> i still think we need proof of breakage +[22:53:45] <ayoy> mhm +[22:54:02] *** Quits: toralf (n=toralf@g224122197.adsl.alicedsl.de) (Client Quit) +[22:54:23] <reavertm> ok, but... +[22:54:34] <reavertm> if let's say it's horrible breakage, what then? +[22:54:44] <reavertm> (and proven) +[22:55:09] <Pesa> is it fixed in 4.6? +[22:55:12] <jmbsvicetto> reavertm: The point is that if it's true, we can't get KDE-4.3.1 marked stable +[22:55:16] <reavertm> who thinks we can hold back gcc-4.4 stabilization (with all those ricers around) until 4.6 is out? :P +[22:55:22] <wired> well if its strick-aliases, can't we disable it? +[22:55:30] <wired> strict* +[22:55:40] <reavertm> jmbsvicetto: as of current stable gcc 4.3.2 we can +[22:57:00] <reavertm> jmbsvicetto: it's not a matter of kde but qt4 (already stable :P) +[22:57:19] <jmbsvicetto> hehe +[22:57:28] <jmbsvicetto> qt? Who's that? ;) +[22:57:39] <wired> jmbsvicetto: want to remove Qt from tree and see if kde works? +[22:57:40] <wired> :D +[22:58:25] <wired> anyway, we'll need to look into this +[22:58:39] <reavertm> we need to work some procedures in case it's breakage :P +[22:58:44] <wired> i wonder if enforcing something like -fno-strict-aliases would work, then again i have no idea of the problem or what causes it +[22:59:14] <reavertm> can we filter flags for anything that builds against qt4? +[22:59:34] <reavertm> I mean *anything* +[22:59:40] <Pesa> nope +[22:59:42] <wired> not really +[22:59:44] <reavertm> (with qt4 itself) +[22:59:56] <wired> but maybe building the libs with that flag would be enough +[23:00:01] <reavertm> so if anyone encounters random runtime failures ... +[23:00:04] <wired> we really need more info and test cases +[23:00:15] <Pesa> wired: nope, there are templates :) +[23:00:21] <reavertm> unfortunately some code may be inline... templates +[23:00:34] <Pesa> QVector for example +[23:00:41] <wired> then we have to try to find more info and failure cases +[23:01:00] <ABCD> the problem, I think, is in 2 headers installed by Qt; the flag would have to be added to every package that uses either header +[23:01:05] <reavertm> and I think thiago talked about QVector suffering from aliasting for example +[23:01:16] <wired> i suggest we look for info ( reavertm please ask like you said ) and we talk about this *important* issue on mini-meeting as well +[23:01:26] <wired> even sooner in chat if we have updates +[23:01:55] <jmbsvicetto> ok +[23:01:58] <reavertm> on my TODO, next? +[23:02:05] <wired> great +[23:02:08] <Pesa> if the problem is limited to only some classes, is there a patch we can backport? +[23:02:24] <wired> Pesa: well sput said that they're not willing to fix it +[23:02:35] <Pesa> O_O +[23:02:40] <reavertm> we can create one :P (with workaround maybe - like some gcc directive :P) +[23:02:56] <wired> but this whole ordeal looks like fud to me, if its serious they will have to fix it +[23:02:56] <wired> we can check other distros using gcc 4 +[23:02:56] <wired> 4.4 +[23:02:56] <wired> for custom patches +[23:03:03] <reavertm> I think that's because there are too many changes 4.5<->4.6 +[23:03:20] <Pesa> i see +[23:03:34] <wired> i'll try to see what other distros with gcc-4.4 (if any?! :P) do - if they do anything at all +[23:03:44] <reavertm> they may not know +[23:03:52] <wired> you never know +[23:03:53] <reavertm> (kde devs may no know even) +[23:04:00] <wired> or there might really be not issue at all +[23:04:04] <wired> :) +[23:04:17] <Pesa> next fedora and next ubuntu have gcc 4.4 afaik +[23:04:35] <Pesa> maybe current fedora too +[23:04:43] <wired> ok +[23:04:43] <ayoy> wired: well, like you say, if was critical, they would have fixed it +[23:04:52] <wired> ayoy: yes thats what i believe as well +[23:04:52] <ayoy> and Qt 4.6 comes out ~December maybe +[23:04:56] <alexxy> fedora has bleeding edge svn gcc version +[23:05:06] <wired> they wouldn't leave their only stable release broken +[23:05:09] <wired> i hope +[23:05:10] <alexxy> since its test ground for rhel +[23:05:14] <ayoy> exactly +[23:05:21] <reavertm> ok, next please +[23:05:27] <wired> right +[23:05:28] <ABCD> it's QVector and QMap that are the issues, I think +[23:05:28] <ABCD> /usr/include/qt4/QtCore/qmap.h:588: warning: dereferencing pointer 'y' does break strict-aliasing rules +[23:05:28] <ABCD> /usr/include/qt4/QtCore/qvector.h:315: warning: dereferencing pointer 'pretmp.11332' does break strict-aliasing rules +[23:05:29] <ayoy> btw, new OpenSuSE uses 4.4 iirc +[23:05:46] <wired> we're dwlling on this, lets do our research and return +[23:05:49] <wired> dwelling +[23:05:55] <wired> wtf is wrong with me today +[23:06:10] <wired> next item +[23:06:19] <reavertm> next topic - Qt 4.5.2 stab (ilization) +[23:06:22] <wired> yeah +[23:06:28] <reavertm> do it! +[23:06:57] <reavertm> I mean - now - it fixes several issues with kde (including webkit crashes in quassel) +[23:06:59] <wired> i don't see why not +[23:07:14] <reavertm> also it makes kdevelop katepart faster (using raster) +[23:07:18] <ayoy> is the exceptions flag issue fixed in the tree already? +[23:07:25] <Pesa> no +[23:07:32] <Pesa> and there's no issue with exceptions in 4.5 +[23:08:02] <wired> ayoy: is there a reason to touch exceptions in intree 4.5 ebuilds? +[23:08:05] <Pesa> please leave 4.5 alone +[23:08:26] <ayoy> well, what was the thing that we tested in overlay? +[23:08:30] <reavertm> don't touch, cc arches :) +[23:08:32] <ayoy> not 4.5-related?... +[23:08:50] <wired> ayoy: you mean 4.6 tech preview 1? +[23:09:03] <Pesa> i really don't know why we added that flag for 4.5 +[23:09:03] <ayoy> xml-patterns dependent on core w/exceptions +[23:09:05] <ayoy> is it for 4.6? +[23:09:08] <Pesa> yes +[23:09:08] <wired> thats 4.6 +[23:09:11] <ayoy> aahhhh +[23:09:12] <wired> 4.5 doesn't need it +[23:09:13] <ayoy> sorry :) +[23:09:28] <wired> any outstanding bugs in 4.5.2 im unaware of? +[23:09:41] *** Joins: tkmorris (n=unknown@201-66-183-55.paemt704.dsl.brasiltelecom.net.br) +[23:09:47] <reavertm> (how is sip/pyqt4 btw?) +[23:09:48] <ayoy> i don't see any +[23:10:25] <Pesa> reavertm: bug 284707 +[23:10:42] <wired> http://bugs.gentoo.org/show_bug.cgi?id=284707 +[23:11:15] <reavertm> very well +[23:11:23] <alexxy> we need Wilkins here +[23:11:56] <reavertm> ok, are we done iin this topic? +[23:12:11] <wired> ok then who wants to open the stablereq bug? +[23:13:00] <ayoy> wired: seems like you +[23:13:05] <wired> heheh +[23:13:08] <wired> alright +[23:13:12] <wired> i'll do it +[23:13:16] <wired> next item +[23:13:24] <wired> eclass unitests +[23:13:32] <reavertm> yeah, I think we could use some +[23:13:39] <reavertm> in kde world at least +[23:14:05] <reavertm> to verify blocks/dependencies,- in general kde-functions +[23:14:41] <reavertm> just a general idea, what do you think +[23:15:03] <ayoy> sounds interesting as for me +[23:15:11] <wired> tests to make sure blocks/deps are correct? +[23:15:16] <reavertm> yes +[23:15:16] <Pesa> unit tests are usually a good idea for regression testing +[23:15:26] <wired> sounds good +[23:15:26] <reavertm> sto avoid further breakages in eclasses +[23:15:54] <jmbsvicetto> sorry guys, I'm being swampped elsewhere. Please poke me if you need anything from me +[23:16:01] <reavertm> sure +[23:16:06] <wired> jmbsvicetto: np, whats your thought on unittests? :P +[23:16:36] <wired> so.. reavertm you're on this? +[23:16:45] <reavertm> I think nobody really objects, just someone will need to do it +[23:16:54] <reavertm> i may start wriing simple tests +[23:17:03] <wired> a headstart would be nice +[23:17:08] <reavertm> ok, next item +[23:17:14] <wired> great +[23:17:15] <reavertm> jmbsvicetto: sets :) +[23:17:16] <wired> sets +[23:17:48] <reavertm> https://bugs.gentoo.org/show_bug.cgi?id=272488 +[23:17:56] <reavertm> I filed following bug ^ +[23:18:05] <reavertm> it's one of ways +[23:18:16] <jmbsvicetto> wired: They're always a good idea +[23:18:19] <jmbsvicetto> sets +[23:18:30] <reavertm> i think it's generally accepted fact that current sets doesn't fit best +[23:18:33] <jmbsvicetto> sorry, wired I meant about unittests +[23:18:40] <jmbsvicetto> reavertm: agreed on that +[23:18:46] <wired> jmbsvicetto: ok, reavertm will do the start +[23:19:05] <wired> reavertm: yeah i've read that bug, its interesting +[23:19:09] <jmbsvicetto> This is another email I'm "owing" us +[23:19:10] <reavertm> so,I wanted to bring your attention on discussion about sets +[23:19:12] <wired> but it seems the whole sets thing is "stale" +[23:19:25] <wired> is anything being developed by zac/portage team? +[23:19:46] <reavertm> wired: no interest - no need to make progress +[23:20:13] <reavertm> if we present strong interest in some idea, zac may start coding +[23:20:41] <reavertm> PROPERTIES=set has this nice feature that most of syntax is already there and may need a litlle work just to get it done +[23:21:00] <reavertm> (with no operators supported - operators have been disabled from sets anyway) +[23:21:21] <reavertm> s/a little/little/ +[23:21:42] <reavertm> so, please read this bug, form some opinion and comment on this bug +[23:21:48] <reavertm> I think this is everything from me +[23:22:12] <wired> anyone any ideas/comments? +[23:22:22] <jmbsvicetto> reavertm: I think PROPERTIES="sets" has some interesting points and may be useful in some cases, but I still think the "original" sets are in general better for KDE +[23:22:37] <Pesa> reavertm: very interesting idea +[23:22:48] <reavertm> jmbsvicetto: only for live maybe +[23:22:53] <reavertm> Pesa: it's zac idea :P +[23:23:03] <jmbsvicetto> reavertm: I do need to write something about it and until I do, I should shut up as I'm not providing ideas for others to be able to comment on +[23:23:21] <reavertm> jmbsvicetto: ;) +[23:23:29] <wired> jmbsvicetto: you did have another idea, no? :) +[23:23:59] <reavertm> properties set would only need us to maintain 'metapackages' +[23:24:25] <reavertm> and i personally don't need anything else (even as a maintainer) +[23:24:49] <jmbsvicetto> wired: my main point is that a list of package atoms can be more versatile +[23:25:05] <reavertm> jmbsvicetto: USE flags? +[23:25:10] <jmbsvicetto> wired: just to give you an example, I think that would be a clever way to fix the PDEPEND problem of QT +[23:25:20] <reavertm> or dedicated USE_EXPAND variable? +[23:25:26] <wired> jmbsvicetto: maybe instead of trying to write a spec, you could write a short comment @ reavertm's bug to get discussion going? +[23:25:38] <jmbsvicetto> reavertm: I know what you mean and that's where optional deps would need to be supported by sets +[23:25:41] <wired> (comment with a short description of what you're thinking) +[23:26:11] <jmbsvicetto> wired: I'm not planning to write a spec, but I need to tie myself to a chair and write a few ideas before I can get people talking about them ;) +[23:26:18] <wired> heheheh +[23:26:28] <wired> you could trying the other way around +[23:26:36] <wired> start a discussion and let it tie you to the chair to answer +[23:26:38] <wired> :) +[23:26:53] <reavertm> you mean trolling? :) +[23:27:13] <wired> throwing ideas to each other isn't necessarilly trolling :) +[23:27:44] <wired> reavertm: maybe you could ask zac to make a sample implementation of properties +[23:27:48] <wired> if its easy to implement +[23:28:21] <reavertm> for us to verify it's usefulness? :P +[23:28:30] *** Parts: Pesa (n=Pesa@bluemchen.kde.org) +[23:28:41] *** Joins: Pesa (n=Pesa@bluemchen.kde.org) +[23:28:46] <wired> if its easy to implement yeah, itd be nice to have some hands on and might give us more ideas +[23:29:24] <reavertm> wired: just imagine metapackage that pulls everything it's listed there even when uninstalled :P +[23:29:31] <wired> some new portage guy could also do it for excersice :P +[23:29:31] <wired> exercise +[23:29:41] <jmbsvicetto> reavertm: That's what metapackages already do ;) +[23:29:44] <reavertm> this is what properties=set is +[23:29:54] <reavertm> jmbsvicetto: uninstalled... +[23:30:04] <reavertm> or reemerged +[23:30:20] <jmbsvicetto> reavertm: The new behaviour is for meta packages to pull all packages when they're already installed and or to remove all packages when uninstalling +[23:30:37] <jmbsvicetto> reavertm: ok, you meant uninstalling +[23:30:43] <reavertm> 'new behaviour'? never heard of it +[23:31:25] <jmbsvicetto> reavertm: I mean that the goal of the PROPERTIES="set" proposal is to have the PM do that with those meta-packages - thus it's a new behaviour +[23:31:27] <reavertm> yes, so it's easy to imagine how it works +[23:31:36] <jmbsvicetto> sure +[23:31:42] <reavertm> wired: ^ :P +[23:31:52] <wired> :) +[23:32:03] <wired> ok so we didn't get anywhere with sets +[23:32:10] <reavertm> of course, for official implementation it will need GLEP and such +[23:32:15] <jmbsvicetto> It doesn't address the optional deps (and I don't mean the use deps) and or set operations (math set operations) +[23:32:34] <jmbsvicetto> which could be very useful +[23:32:45] <reavertm> jmbsvicetto: what is 'optional deps'? USE_EXPAND variable wouldn't work? +[23:32:58] <jmbsvicetto> let me give an example +[23:33:05] <reavertm> operators - of course - we could use those +[23:33:13] <reavertm> (but not really blocker for me :P) +[23:33:27] <jmbsvicetto> let's say we want to have in the @kdebase set, kdebase-startkde as the only required dep (with all of its deps) +[23:34:07] <jmbsvicetto> So anyone having @kdebase in their system could remove at will any package in the @kdebase set and the PM would respect it, except if it was kdebase-startkde or one of its deps +[23:34:46] <jmbsvicetto> So emerge -uDav @kdebase would only update the installed packages - would work by default as emerge -uDav @kdebase/@installed +[23:34:49] <reavertm> so 'install all by default' but allow uninstall +[23:34:55] <jmbsvicetto> yes +[23:35:20] <reavertm> please comment on bug :) +[23:35:21] <jmbsvicetto> For instance, I might want to have the @kdenetwork set, but I really hate krfb and I don't want it around +[23:35:25] <jmbsvicetto> hehe +[23:35:34] <wired> how do you reemerge the whole set? +[23:35:39] <wired> @kdebase/@all ? +[23:35:45] <jmbsvicetto> wired: ^^ See, I'm already being asked to tie myself to chair ;) +[23:35:53] <wired> jmbsvicetto: yeah, it worked +[23:35:55] <wired> jmbsvicetto: :D +[23:36:04] <wired> jmbsvicetto: keep going! =] +[23:36:40] <jmbsvicetto> wired: That would need some discussion and documentation, but I could see emerge -uDav @<set> only updating the installed (and required deps) and emerge -av @<set> installing all packages in the set +[23:36:43] <tampakrap> --keep-going +[23:36:50] <reavertm> you can attach channel log :P +[23:36:52] <jmbsvicetto> --jobs=5 +[23:36:58] <wired> -jobs=512 +[23:37:05] <reavertm> no @ oeprators +[23:37:19] <reavertm> keep it simple and stupid :P +[23:37:30] <wired> alright, so this should continue in bug, we should all ping jmbsvicetto once a day to tie him to the chair +[23:37:33] <wired> :D +[23:37:42] <jmbsvicetto> The tricky part is that the PM will need to store sets and need to use them for dep resolution +[23:37:50] <jmbsvicetto> hehe +[23:37:52] <reavertm> but is there. just needs attention +[23:38:04] <reavertm> bug* +[23:38:22] <jmbsvicetto> reavertm: another example - emerge -C @kdebase - 3 years from now when the sets are long gone ;) +[23:38:50] <wired> EAPI="10" ? :) +[23:39:06] <reavertm> but we should start to make people forget about '@' :P +[23:39:38] <wired> alright +[23:39:43] <reavertm> ok, anythig else +[23:39:44] <wired> we're closing in 2 hours +[23:39:52] <wired> reavertm: you wanted something extra to discuss about? +[23:40:10] <reavertm> ah yes +[23:40:18] <reavertm> versioning eclasses +[23:40:35] <wired> I think we really need that +[23:40:42] <reavertm> but just as 'stamp eclass version to be able to guess from 'environment' which eclass is really used +[23:41:19] <reavertm> some EVERSION_kde4_base=number (incremented with every file.eclass commit) would work +[23:41:27] <jmbsvicetto> reavertm: versioned eclasses were a good idea that never took off +[23:41:37] <reavertm> I could be even posisble to do it as pre-commit hook +[23:41:50] <jmbsvicetto> reavertm: that sounds doable +[23:42:02] <jmbsvicetto> reavertm: hmm, let me check something +[23:42:04] <reavertm> jmbsvicetto: I only would like to stamp version, not use for dependencies or such +[23:42:18] <ayoy> reavertm: what for then? +[23:42:25] <jmbsvicetto> reavertm: what you want is already there - # $Header$ +[23:42:44] <jmbsvicetto> reavertm: what we need is a way to put that in the environment.bz2 +[23:42:45] <reavertm> jmbsvicetto: but it's not in environmeny as varianle +[23:42:52] <jmbsvicetto> yes, I understand +[23:42:59] <jmbsvicetto> reavertm: but there might be a way to get it +[23:43:35] <jmbsvicetto> reavertm: hmm, thinking a few more seconds about it, are you sure it's not there? +[23:43:46] <jmbsvicetto> reavertm: iirc, the complete eclass is supposed to be in environment.bz2 +[23:44:15] <reavertm> with all comments stripped +[23:45:06] <reavertm> export "EVERSION_${ECLASS//-/_}"=1 +[23:45:15] <reavertm> for simple manual approach +[23:45:30] <wired> some quick thinking, could we have eclass wrappers loading "custom-versioned" eclasses based on ebuild PN/PVs? +[23:45:32] <reavertm> (pre-commit hook would be more clever) +[23:45:37] <jmbsvicetto> reavertm: right +[23:45:46] <jmbsvicetto> reavertm: maybe we could ask Zac to keep the version in the file +[23:45:57] <jmbsvicetto> reavertm: It seems to me it would be very useful for other cases as well +[23:46:08] <reavertm> how would he gather such info? +[23:46:14] <jmbsvicetto> He already does +[23:46:33] <reavertm> i mean, eclass version +[23:46:48] <reavertm> what he he does is checking some timestamp I suppose +[23:46:49] <jmbsvicetto> environment.bz2 picks the used eclasses. Currently the comments are being stripped, but it seems it could be useful to keep the 3rd line in the eclass +[23:47:23] <jmbsvicetto> reavertm: I'm going after a "simpler" solution +[23:47:32] <spatz> avoid using anything CVS specific as we might want to move away from that one day +[23:47:35] <reavertm> yeah, and may even be sufficient +[23:47:53] <wired> if that was doable we could have kde4-meta in ebuilds, kde4-meta-1 and kde4-meta-2 for example and kde4-meta would inherit per case, wouldn't that be easy to implement and practical? +[23:48:02] <reavertm> jmbsvicetto: actually it won't +[23:48:17] <jmbsvicetto> reavertm: why not? +[23:48:35] <reavertm> jmbsvicetto: or at least we should set out own header in pre-commit anyway +[23:48:57] <jmbsvicetto> spatz: The current discussions include using the git md5 for similar purpose +[23:49:00] <reavertm> (as overlay eclasses are usually copy-paste to tree, so don't have cvs version signature) +[23:49:16] <jmbsvicetto> reavertm: but the minute you commit an eclass to the tree, it gets a version +[23:49:32] <jmbsvicetto> reavertm: and we could be using commit hooks in the overlay for the same goal +[23:49:33] <reavertm> jmbsvicetto: the point is I don't want to work it only with tree +[23:49:49] <reavertm> yes, ^ +[23:50:08] <reavertm> "or at least we should set out own header in pre-commit anyway" +[23:50:09] <jmbsvicetto> I'm not arguing against commit hooks, just saying that for the tree we already have it ;) +[23:50:12] <wired> jmbsvicetto: reavertm is what im saying doable? +[23:50:41] * reavertm reads +[23:50:49] <jmbsvicetto> wired: I'm too tired to think about it and am I'm no expert, but I think invariancy rules don't allow that +[23:50:57] <jmbsvicetto> -am +[23:51:22] <reavertm> wired: but it includes some eclass dependencies +[23:51:28] <jmbsvicetto> wired: or you'll have to use the "safe vars" to do that if/case +[23:51:29] <reavertm> sure it's easy to be done +[23:51:51] <wired> think eclass bumping, big version changes would not affect old ebuilds/eclasses if that worked +[23:52:00] <wired> and we don't need to get eclass versioning in portage +[23:52:29] <jmbsvicetto> anyway, are we done for tonight? +[23:52:34] <reavertm> it's just a matter what inherit depending on PV +[23:52:40] <reavertm> I think we are +[23:52:43] <wired> reavertm: i know, i wonder if portage would like it +[23:52:46] <wired> we are +[23:52:50] <wired> unless anyone wants to add something +[23:52:53] <jmbsvicetto> reavertm: PV is one of the "safe vars" ;) +[23:53:14] <wired> its seems noone wants +[23:53:19] <wired> dismissed +[23:53:20] <reavertm> jmbsvicetto: it's not safe unless it's marked readonly :) +[23:53:33] <jmbsvicetto> :) +[23:53:34] <wired> meeting ends, until next thursday :) +[23:53:49] <jmbsvicetto> wired: can you please upload the log to the kde project space? +[23:53:56] <jmbsvicetto> I can do the summary in the weekend +[23:54:35] <wired> jmbsvicetto: cvs? sure +[23:58:48] *** Parts: ayoy (n=ayoy@gentoo/developer/ayoy) |