[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] I'm here [22:05:09] *** Joins: Pesa (n=Pesa@bluemchen.kde.org) [22:05:39] 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] wasn't it moved to friday? :P [22:08:02] scarabeus sent "correction" email [22:08:02] :p [22:09:06] oh, I was already here [22:09:08] yeah [22:09:11] didn't i hilight you? [22:09:18] :P [22:09:25] scarabeus said he might not make it, who else is late? [22:09:25] I'm not sure how well my connection is going to hold up, so... [22:09:29] Yeah, but I had forgot I was around here [22:10:27] * jmbsvicetto makes mental note - win 76 [22:10:29] Anyone logging? [22:10:37] everytbody [22:10:43] i am [22:10:55] yngwin won't be coming, scarabeus too [22:10:56] ok [22:11:02] we're missing patrick, tampakrap [22:11:11] and some more qt representatives [22:11:26] ayoy spatz and Pesa are here [22:11:33] hwoarang is on long devaway [22:11:36] Let's give them a few more minutes? [22:11:38] yngwin is away too [22:11:47] we're waiting for bonsaikitten? [22:12:05] i pinged them [22:12:07] *** Joins: bonsaikitten (i=quassel@gentoo/developer/bonsaikitten) [22:12:08] good, on his way :) [22:12:19] *** Joins: tampakrap (n=tuxicity@gentoo/developer/tampakrap) [22:12:29] good [22:12:43] So, who wants to chair this one? [22:13:01] I could use the break to get ready another thing I'm working on [22:13:34] hello [22:14:14] jmbsvicetto: i'll do it [22:14:45] good, do we have decisive power? [22:14:46] lets get going, first topic, 4.3 stabilization [22:14:58] wired: thanks [22:15:04] to vote stuff and such? it's quite few of us [22:15:26] wired: roll call first [22:15:47] here [22:15:58] reavertm: I don't think we have much to vote today. It's more about getting processes started [22:16:02] here [22:16:04] that was done, but present yourselves for the record if you want :) [22:16:26] here [22:16:38] here [22:16:46] i am [22:16:56] ok, wired, move on [22:17:20] first topic, kde 4.3 stabilization [22:17:26] are we still going with 4.3.1? [22:17:34] *** Parts: Pesa (n=Pesa@bluemchen.kde.org) [22:17:38] here [22:17:52] yaah, we're going with 4.3.1, I wanted to bring this topic to... [22:18:14] gather some manpower to fix blocker bugs (or talk about dropping some blockers) [22:18:38] are there any specific blocks we should focus on? [22:18:50] https://bugs.gentoo.org/show_bug.cgi?id=277868 [22:18:50] is there a list/tracker? [22:18:54] this is bug [22:19:09] btw meeting agenta: http://archives.gentoo.org/gentoo-desktop/msg_1abe5bf232579eabb51aadc3d80b397b.xml [22:19:15] wired: yes [22:19:18] in case you don't have the mail available [22:20:10] 12 bugs [22:20:18] One thing we need to do ASAP is adding the patches being sent to the packagers ml [22:20:28] i agree [22:21:14] if we could focus these 2 weeks ideally we could request stablereq right after the 1 month period [22:21:26] yes [22:21:38] *** Joins: [Enrico] (n=chiccoro@gentoo/contributor/Enrico) [22:21:49] 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] great [22:22:03] and there's postinst message [22:22:35] so guys please do your best so we can finally have kde4 in stable :D [22:22:43] We should also start opening stabilization bugs for deps: automoc, strigi, soprano, phonon. Anything else? [22:23:04] are we stabling the phonon snapshot? [22:23:22] yes, it works fine [22:23:30] (it has unstable API) [22:23:44] well it'll have to do if thats all we've got [22:23:58] it's known to work anyway [22:24:05] ok [22:24:08] what's the minimum working version? [22:24:25] * wired looks ar reavertm [22:24:29] at [22:24:38] And we need to get it stable or there'll be no stable KDE-4.3.1 [22:25:12] 4.3.1 should od [22:25:23] do [22:25:33] but... mplayerthumps would need changes [22:25:48] 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] (disabling phonon backend - as it only works with latest phonon) [22:25:59] otherwise kde would pull mplayer... [22:26:22] reavertm: can 't we leave it out? (mplayerthumbs) [22:26:39] why should we? part of kdemultimedia [22:27:00] whats wrong with having mplayer as a dep (besides an extra dep)? is it not working ok? [22:27:44] reavertm? [22:27:45] I suppose it is, whatever if you like one could go with 4.3.1 phonon and that change in mplayerthumbs [22:28:08] 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] I won't die for this cause, 4.4pre is just not worse than 43.1 [22:28:34] jmbsvicetto: well we have tested the phonon snapshot extensively [22:28:47] wired: ok [22:29:04] as long as its an exception (snapshots) ;) [22:29:10] I even asked some kde devs about it :P [22:29:36] jmbsvicetto: is there an issue with stabling it [22:29:36] ? [22:29:43] ok [22:29:52] * wired kicks isp for lag [22:30:07] anyone else wanna say anything about stabilization? [22:30:25] apart from get to work? :) [22:30:30] yeah [22:30:43] it isn't possible to have it fully stabilized until october 4th [22:30:58] well, we need more stable testers ... [22:31:42] *** Joins: alexxy (n=alexxy@gentoo/developer/alexxy) [22:31:48] alexxy :) [22:31:51] hi all! [22:31:53] bonsaikitten: I use stable system :P [22:31:59] sorry that i'm late [22:32:02] ooh :) [22:32:14] (with exceptions for kde and its deps) [22:32:15] isnt meeting was schedulet for tommorow? [22:32:22] initially it was [22:32:24] alexxy: scarabeus sent a correction email [22:32:25] the problem is that the one month period is beyond that date [22:32:28] he failed at the date [22:32:31] nevermind, you missed nothing [22:32:43] not to mention the time that arch teams need [22:33:15] tampakrap: no its not, you added the ebuilds on sept 1st [22:33:15] the problem is getting archs to stable it in 3 days [22:33:15] assuming we have fixed bugs [22:33:33] one month with no open bugs [22:33:50] 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] i hope i'm wrong on this one... [22:34:16] tampakrap: sure, but we can start the work to get it marked stable asap [22:34:30] jmbsvicetto: 4.4_pre20090520 yeah, thats the one we have in ~testing now [22:34:50] tampakrap: we can file an "early request" bug [22:35:00] tampakrap: it's up to arch teams whether they want to mark it stable or not [22:35:02] ah ok then [22:35:07] and we also have one extra motive [22:35:09] tampakrap: and for the livedvd we only need amd64/x86 [22:35:10] livedvd [22:35:33] ok let's hope this will work then [22:35:47] I recommend we do a mini meeting next week [22:35:56] may be [22:35:57] to check on the state of bugs [22:35:59] tampakrap: Besides, I think we're starting to have many amd64/x86 users on KDE-4 [22:36:00] nice idea [22:36:16] wired: good idea [22:36:49] same day next week? 24th? [22:37:20] fine by me [22:37:35] great, i'll send the email, we can adjust if needed [22:37:36] wired: sure [22:37:57] lets do our best and close all bugs :D [22:38:07] ok enough with this then, lets proceed [22:38:17] kde3.5, kde-sunset [22:38:28] who's taking care of this and can give us an update? [22:38:33] tampakrap?/ [22:38:41] there is no progress in that subject [22:38:59] apart from the fact that scarabeus created the overlay :P [22:39:01] 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] so nobody is interested - good :) [22:39:19] reavertm: heh [22:39:20] I'm "owing" an email about it [22:39:28] jmbsvicetto: lol click send [22:39:48] The official email putting the "death seal" on KDE-3.5 [22:39:51] *** Parts: Pesa (n=Pesa@bluemchen.kde.org) [22:39:55] ah that one [22:40:25] is anyone else interested in helping make the move to kde-sunset? [22:40:39] besides tampakrap? :P [22:40:45] no! [22:40:53] it should rot and die [22:40:56] hehe [22:40:56] reavertm: think positive, we'll get rid of it from the tree [22:40:58] :D [22:40:58] i agree noone else is needed [22:41:07] we just need to stabilize kde4 and kill 3 [22:41:08] wired: I can help move the ebuilds there [22:41:22] great [22:41:34] not sure if we need scarabeus to give us access to it or if he added us all [22:42:03] ok, next item [22:42:06] kdeprefix [22:42:09] wait [22:42:12] about kde3 [22:42:15] yeah? [22:42:26] i have set some rules before moving ebuilds to kde-sunset [22:42:49] you should make Documentation/CODE [22:42:50] i sent them in the previous meeting through scarabeus because i wasn't present then [22:42:55] ah ok [22:43:05] nice idea #2 [22:43:25] *** Joins: Pesa (n=Pesa@bluemchen.kde.org) [22:43:29] OK [22:43:34] anyone else anything about kde3? [22:44:06] moving on then [22:44:08] kdeprefix [22:44:18] not sure what scarabeus had in mind when he added it to agenda [22:44:32] perhaps removing it completely? [22:44:49] I think there's no need to drop it from eclass [22:44:51] to much work :P [22:44:59] well its not usable in current state [22:45:06] and its masked [22:45:08] and it causes much more bugs [22:45:22] wired: I asked him to add this point to the agenda [22:45:25] so let it stay masked =) [22:45:33] we explicitly don't support any kdeprefixed installations [22:45:41] jmbsvicetto: ok, what did you have in mind? [22:46:09] 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] I think we should still keep code in mind that it may be enabled as some point [22:46:25] +know [22:46:36] but this mail is needed [22:47:07] jmbsvicetto: ok, but they should know already, portage should have screamed when we masked it [22:47:28] but an email (and perhaps a blog post, i could do that) would help [22:47:42] That's all I'm after [22:47:44] a news item maybe? [22:47:50] post a sticky in the forums, many go there [22:48:05] I think it is mentioned already [22:48:13] in stick in Desktop Environment [22:48:33] okay.. who wants to send the email? [22:48:52] Gentoo KDE Lead volunteered, no? :) [22:49:10] *** Parts: [Enrico] (n=chiccoro@gentoo/contributor/Enrico) [22:49:10] hehe [22:49:11] (jmbsvicetto) The point is we should send an email [22:49:16] I did [22:49:30] :) [22:49:31] ok [22:49:34] I'll write a blog post [22:49:57] anyone else have anything on kdeprefix? [22:50:18] * reavertm will add one quick point to agenda later [22:50:18] moving on [22:50:26] qt 4.5 [22:50:43] some people (and some qt devs apparently?!) say its broken with gcc 4.4 [22:50:54] is everyone aware of the problem? if not, then qt-4.5 may break with 4.4 [22:50:58] wired: i dont see any breakages [22:51:00] do we have any evidence? [22:51:03] with gcc-4,4 [22:51:07] not any im aware of [22:51:11] (apparently when strict aliasing is enabled) [22:51:36] well [22:51:39] gcc-4.4. is officially not supported (well, not listed in supported), for 4.5 [22:51:57] 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] isn't it in stabilization process though? [22:52:03] 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] and portage already spits QA warnings with gcc-4.3.2 [22:52:11] does ANY of you have issues with qt 4.5 and gcc 4.4{,.1}? [22:52:11] cause so far its all blah blah blah [22:52:11] but no evidence [22:52:38] i say its FUD until proved otherwise by bug reports [22:53:07] no problem here, but gcc's warnings are quite scary [22:53:24] Pesa: what warnings? :) [22:53:27] I'll ask thiago about details and get back on next meeting (should have done it already..) [22:53:33] about strict aliasing [22:53:36] reavertm: alright [22:53:42] i still think we need proof of breakage [22:53:45] mhm [22:54:02] *** Quits: toralf (n=toralf@g224122197.adsl.alicedsl.de) (Client Quit) [22:54:23] ok, but... [22:54:34] if let's say it's horrible breakage, what then? [22:54:44] (and proven) [22:55:09] is it fixed in 4.6? [22:55:12] reavertm: The point is that if it's true, we can't get KDE-4.3.1 marked stable [22:55:16] who thinks we can hold back gcc-4.4 stabilization (with all those ricers around) until 4.6 is out? :P [22:55:22] well if its strick-aliases, can't we disable it? [22:55:30] strict* [22:55:40] jmbsvicetto: as of current stable gcc 4.3.2 we can [22:57:00] jmbsvicetto: it's not a matter of kde but qt4 (already stable :P) [22:57:19] hehe [22:57:28] qt? Who's that? ;) [22:57:39] jmbsvicetto: want to remove Qt from tree and see if kde works? [22:57:40] :D [22:58:25] anyway, we'll need to look into this [22:58:39] we need to work some procedures in case it's breakage :P [22:58:44] 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] can we filter flags for anything that builds against qt4? [22:59:34] I mean *anything* [22:59:40] nope [22:59:42] not really [22:59:44] (with qt4 itself) [22:59:56] but maybe building the libs with that flag would be enough [23:00:01] so if anyone encounters random runtime failures ... [23:00:04] we really need more info and test cases [23:00:15] wired: nope, there are templates :) [23:00:21] unfortunately some code may be inline... templates [23:00:34] QVector for example [23:00:41] then we have to try to find more info and failure cases [23:01:00] 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] and I think thiago talked about QVector suffering from aliasting for example [23:01:16] 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] even sooner in chat if we have updates [23:01:55] ok [23:01:58] on my TODO, next? [23:02:05] great [23:02:08] if the problem is limited to only some classes, is there a patch we can backport? [23:02:24] Pesa: well sput said that they're not willing to fix it [23:02:35] O_O [23:02:40] we can create one :P (with workaround maybe - like some gcc directive :P) [23:02:56] but this whole ordeal looks like fud to me, if its serious they will have to fix it [23:02:56] we can check other distros using gcc 4 [23:02:56] 4.4 [23:02:56] for custom patches [23:03:03] I think that's because there are too many changes 4.5<->4.6 [23:03:20] i see [23:03:34] 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] they may not know [23:03:52] you never know [23:03:53] (kde devs may no know even) [23:04:00] or there might really be not issue at all [23:04:04] :) [23:04:17] next fedora and next ubuntu have gcc 4.4 afaik [23:04:35] maybe current fedora too [23:04:43] ok [23:04:43] wired: well, like you say, if was critical, they would have fixed it [23:04:52] ayoy: yes thats what i believe as well [23:04:52] and Qt 4.6 comes out ~December maybe [23:04:56] fedora has bleeding edge svn gcc version [23:05:06] they wouldn't leave their only stable release broken [23:05:09] i hope [23:05:10] since its test ground for rhel [23:05:14] exactly [23:05:21] ok, next please [23:05:27] right [23:05:28] it's QVector and QMap that are the issues, I think [23:05:28] /usr/include/qt4/QtCore/qmap.h:588: warning: dereferencing pointer 'y' does break strict-aliasing rules [23:05:28] /usr/include/qt4/QtCore/qvector.h:315: warning: dereferencing pointer 'pretmp.11332' does break strict-aliasing rules [23:05:29] btw, new OpenSuSE uses 4.4 iirc [23:05:46] we're dwlling on this, lets do our research and return [23:05:49] dwelling [23:05:55] wtf is wrong with me today [23:06:10] next item [23:06:19] next topic - Qt 4.5.2 stab (ilization) [23:06:22] yeah [23:06:28] do it! [23:06:57] I mean - now - it fixes several issues with kde (including webkit crashes in quassel) [23:06:59] i don't see why not [23:07:14] also it makes kdevelop katepart faster (using raster) [23:07:18] is the exceptions flag issue fixed in the tree already? [23:07:25] no [23:07:32] and there's no issue with exceptions in 4.5 [23:08:02] ayoy: is there a reason to touch exceptions in intree 4.5 ebuilds? [23:08:05] please leave 4.5 alone [23:08:26] well, what was the thing that we tested in overlay? [23:08:30] don't touch, cc arches :) [23:08:32] not 4.5-related?... [23:08:50] ayoy: you mean 4.6 tech preview 1? [23:09:03] i really don't know why we added that flag for 4.5 [23:09:03] xml-patterns dependent on core w/exceptions [23:09:05] is it for 4.6? [23:09:08] yes [23:09:08] thats 4.6 [23:09:11] aahhhh [23:09:12] 4.5 doesn't need it [23:09:13] sorry :) [23:09:28] 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] (how is sip/pyqt4 btw?) [23:09:48] i don't see any [23:10:25] reavertm: bug 284707 [23:10:42] http://bugs.gentoo.org/show_bug.cgi?id=284707 [23:11:15] very well [23:11:23] we need Wilkins here [23:11:56] ok, are we done iin this topic? [23:12:11] ok then who wants to open the stablereq bug? [23:13:00] wired: seems like you [23:13:05] heheh [23:13:08] alright [23:13:12] i'll do it [23:13:16] next item [23:13:24] eclass unitests [23:13:32] yeah, I think we could use some [23:13:39] in kde world at least [23:14:05] to verify blocks/dependencies,- in general kde-functions [23:14:41] just a general idea, what do you think [23:15:03] sounds interesting as for me [23:15:11] tests to make sure blocks/deps are correct? [23:15:16] yes [23:15:16] unit tests are usually a good idea for regression testing [23:15:26] sounds good [23:15:26] sto avoid further breakages in eclasses [23:15:54] sorry guys, I'm being swampped elsewhere. Please poke me if you need anything from me [23:16:01] sure [23:16:06] jmbsvicetto: np, whats your thought on unittests? :P [23:16:36] so.. reavertm you're on this? [23:16:45] I think nobody really objects, just someone will need to do it [23:16:54] i may start wriing simple tests [23:17:03] a headstart would be nice [23:17:08] ok, next item [23:17:14] great [23:17:15] jmbsvicetto: sets :) [23:17:16] sets [23:17:48] https://bugs.gentoo.org/show_bug.cgi?id=272488 [23:17:56] I filed following bug ^ [23:18:05] it's one of ways [23:18:16] wired: They're always a good idea [23:18:19] sets [23:18:30] i think it's generally accepted fact that current sets doesn't fit best [23:18:33] sorry, wired I meant about unittests [23:18:40] reavertm: agreed on that [23:18:46] jmbsvicetto: ok, reavertm will do the start [23:19:05] reavertm: yeah i've read that bug, its interesting [23:19:09] This is another email I'm "owing" us [23:19:10] so,I wanted to bring your attention on discussion about sets [23:19:12] but it seems the whole sets thing is "stale" [23:19:25] is anything being developed by zac/portage team? [23:19:46] wired: no interest - no need to make progress [23:20:13] if we present strong interest in some idea, zac may start coding [23:20:41] 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] (with no operators supported - operators have been disabled from sets anyway) [23:21:21] s/a little/little/ [23:21:42] so, please read this bug, form some opinion and comment on this bug [23:21:48] I think this is everything from me [23:22:12] anyone any ideas/comments? [23:22:22] 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] reavertm: very interesting idea [23:22:48] jmbsvicetto: only for live maybe [23:22:53] Pesa: it's zac idea :P [23:23:03] 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] jmbsvicetto: ;) [23:23:29] jmbsvicetto: you did have another idea, no? :) [23:23:59] properties set would only need us to maintain 'metapackages' [23:24:25] and i personally don't need anything else (even as a maintainer) [23:24:49] wired: my main point is that a list of package atoms can be more versatile [23:25:05] jmbsvicetto: USE flags? [23:25:10]