[22:07:55] sooooo [22:07:59] who's here? [22:07:59] that would rock :) [22:08:16] meetings are quite understaffed recently :P [22:08:21] yeah i have a feeling [22:08:23] here [22:08:24] blame scarabeus [22:08:26] we'll be missing a lot today [22:08:27] I'm here [22:08:35] ROLLCALL :D [22:08:52] * ABCD is here [22:08:57] * reavertm reporting [22:08:58] <--tampakrap but due to family issues i may leave without notice [22:09:29] *** Joins: alexxy (n=alexxy@gentoo/developer/alexxy) [22:09:36] hi all [22:09:42] yo [22:09:44] heya alexxy [22:09:46] hey alexxy [22:09:50] shouting brings ppl [22:09:52] * wired is impressed [22:10:08] it's good you're here alexxy because I've planned last minute agenda topic that is sort of related to you :) [22:10:13] lol [22:10:23] he wont be happy [22:10:24] :p [22:10:33] I think in longer run he will [22:10:39] :) [22:10:39] hehe [22:10:46] omg =) [22:10:49] so lets wait 5 more minutes [22:11:09] maybe jmbsvicetto and bonsaikitten will show up [22:11:41] we're also missing spatz [22:12:53] * wired orders some food [22:13:38] btw i have a rather unstable internet connection these days, so i may disappear in the middle of the meeting :( [22:14:40] jmbsvicetto mentioned to me he might not make it [22:14:59] and I'm present, but not conscious [22:15:10] * reavertm slaps bonsaikitten [22:19:25] alright [22:19:30] lets begin [22:19:35] Hi [22:19:38] w00t [22:19:42] that's timing [22:19:42] :p [22:19:48] yeah [22:20:02] hey boss [22:20:14] but i'll leave sorry [22:20:34] cya [22:20:59] Hi everyone [22:21:04] jmbsvicetto: :) [22:21:04] hi :) [22:21:10] I'm also present, but not very "conscious" [22:21:33] maybe we should look into that, it seems to be spreading [22:21:33] :p [22:21:43] ok.. [22:21:54] lets start with kde stabilization [22:22:07] can someone please outline the current bugs state? [22:22:26] there are a few left [22:22:57] two java (some hotspot issue with non-sun jvms) related, two grub issues (patch is attached to one of them) [22:23:14] some deps are also pending stabilisation [22:23:42] I've eliminated two more today (one as test-request and second marked as not blocking stabilization) [22:24:15] anything we can't solve in the following days, or something we should focus on? [22:24:21] *** Parts: nim_ (n=nim@adsl14-107.lsf.forthnet.gr) [22:24:32] Pesa: one is probably yours? (consolekit and dbus related) [22:24:58] yep, it shouldn't block stabilization imho [22:25:07] it's not a regression afaik [22:25:11] one could try to applyt hat grub patch from bug 242736 and see whether it works [22:25:21] i'll try that [22:25:36] We need to apply all the patches sent to the packagers ml [22:25:44] jmbsvicetto: in overlay [22:25:44] it's nice to see policykit went stable on x86/amd64 [22:25:55] In particular the ones that prevent some kdepim packages from crashing and kmail from eating imap mails [22:26:04] reavertm: Great! Thanks [22:26:06] https://bugs.gentoo.org/show_bug.cgi?id=241638 - also sci team would need to add some pkg_postinst [22:26:13] nice [22:26:20] jmbsvicetto: only ldap. I yet to see imap crash patch posted [22:26:40] reavertm: hmm, I could swear I noticed an email about that [22:27:04] well, my 4.3.9999 branch is still crashing occasionally so it's not fixed [22:27:37] reavertm: <200909131956.22847.mcguire@kde.org> <- mailid [22:28:01] please someone slap sci team to add that pkg_postinst message about the possible need to reemerge cln and/or libqualculate in case some linking problems appear [22:28:49] reavertm: I've forward the mail to you [22:28:56] jmbsvicetto: ah, that one, yeah [22:29:43] jmbsvicetto: i dont see any problems with kmail related to imap [22:29:55] * alexxy uses it on dayly basis [22:30:05] alexxy: its something about moving folders [22:30:07] neither do I (use it all the time on 2 PCs) [22:30:08] and its ugly [22:30:09] it sometimes crashes kmail on exit [22:30:22] iirc you can lose a folder full of emails :P [22:30:26] alexxy: It's an upstream commit [22:30:39] (the patch) [22:30:39] hmm [22:30:56] my kmail can handle imaps folders with 100k+ mails [22:30:59] the only problem I can see with kmail/kontact is that it sometimes lunches two instances on startup and when you close any of them it crashes [22:31:09] someone needs to bump doxygen 1.6.1 to fix bug https://bugs.gentoo.org/show_bug.cgi?id=282598 [22:32:06] https://bugs.gentoo.org/show_bug.cgi?id=275326 can be probably maked as non-blocker since java is now enabled by default (and there's postinst message warning that redland is known to not work) [22:32:19] (btw it seems to be fixed in trunk soprano) [22:32:45] sounds good [22:33:05] reavertm: mind adding all the bugs you know about as blockers to the stabilization bug? [22:33:29] jmbsvicetto: I'm just reading this list [22:33:38] about doxygen - if nerdboy doesnt bump it in the next few days we can do it i guess [22:33:48] if there are some new 4.3.1 issues that should be maked as blockers, then wel... [22:33:53] Also, can anyone please open bugs for the KDE deps (automoc, strigi, soprano, phonon, etc), assign it to us and cc amd64 / x86? [22:34:34] I'll create stabilization list for 4.3.1 [22:35:33] ok [22:35:35] separate bug for each dep? [22:35:49] jmbsvicetto? [22:35:53] In this case, we can have a single bug for all deps [22:36:54] I'd like someone (or more of you) to take a look at recent 4.3.1 bugs that may be considered blockers [22:36:55] alright [22:37:29] if you're bored that is :) [22:37:31] i'll have a look this weekend [22:37:47] reavertm: I want to start looking at some, but work is leaving me dead tired when I finally get home :\ [22:38:03] jmbsvicetto++ i have the same issue and this weekend im working... [22:38:06] stupid deadlines [22:38:23] ok, I think that's it when it comes to kde stabilization, anything else here? [22:38:29] alright, anything else pending for stabilization? [22:38:43] lets move on to Qt [22:38:47] before we talk about gcc [22:38:53] quick update on stabilization [22:39:07] after talking with yngwin i pushed news item in -dev [22:39:13] about the use flag changes [22:39:26] i'll request stabilization after I've added the news item [22:39:38] probably on saturday [22:39:46] since i need to wait 72 hours [22:39:53] nice :) [22:39:55] cool [22:40:05] sooooo [22:40:21] did anyone get any info, crashes or anything else on qt 4.5 w/ gcc 4.4 combo? [22:40:26] gcc and qt4.. [22:40:32] no! [22:40:39] ftr no crashes for me [22:40:47] nope [22:41:00] nope. I'm using 4.4.1 and 4.5.2 and all is fine [22:41:02] it may not be that severe considering no other distros I looked into made any patches for aliasing [22:41:14] reavertm: did you talk with upstream? [22:41:16] wired: still no noticeable crashes here [22:41:35] anyway - it affects all template classes like QHash, QList, QMap, QVector and maybe some other [22:41:40] also no crasghes here with qt-4.5.x [22:41:46] well [22:41:51] if no one can replicate crashes [22:41:57] worksforme [22:42:02] :) [22:42:06] it may be enough to add -fno-strict-aliasing somewhere to make it even less severe [22:42:28] we could [22:42:31] other way (thiago asuggested) is to simply (providing it's simple) - backport those classes from 4.6 [22:42:44] but why bother touching something [22:42:45] that works [22:42:48] keep in mind [22:42:52] that users are best testers [22:42:56] and we don't have bug reports :) [22:42:59] thats a good sign :P [22:43:05] * alexxy has several crashes with qt-4.6 and kde4 and amarok [22:43:21] well, yes, we may need to wait for some fireworks because maybe it's not really needed [22:43:41] where would you add -fno-strict-aliasing? remeber those classes are templates... [22:43:44] Oh, let me thank whoever has been doing the latest taglib{-extras} and amarok bumps [22:44:09] if we wake one morning and bugzilla is full of Qt4 crash duplicates we'll worry about it, but seriously this is fud, there's no way they wont fix it if it ever breaks [22:44:31] wired: fine with me [22:44:47] well, this may not be a fud, but we've seen several aliasing-related warnings on gentoo for multiple packages [22:44:59] so it's not a reason for panic [22:45:19] alright [22:45:28] so, let's wait for user/testers feedback, hmm? [22:45:31] thats settled until a storm comes then [22:45:39] :) [22:45:39] ok [22:45:44] reavertm: your floor :) [22:45:50] last (hidden) agenda item :) [22:46:00] I've had a couple of crashes that might be related, but I can't be sure [22:46:25] ABCD: gather coredumps and/or just backtraces then [22:47:06] last agenda item - stop shipping unstable svn snapshots - several reasons: [22:47:26] - they need to be repacked (not really an issue) [22:47:38] - they are known to be broken [22:48:10] - they somewhat distract users from using tagged packages in portage (4.3.1) and such [22:48:47] i dont really mind, but yeah, especially the early ones could be avoided [22:48:51] for users' sake [22:48:55] (of course we're not talking about dropping beta1, beta2, rc1, rc2 .. releases as those have some tagging involved, not just auto-tagging) [22:48:57] what about providing only beta/rc version? [22:49:06] lol nvm [22:50:07] alexxy: you used to bump them, what do you think about not doing it anymore? :) [22:51:37] well there some people who relay use them =) [22:52:03] alexxy: apart from yourself? :) [22:52:12] yep [22:52:26] sorry, phone [22:52:33] I say if someone wants to do them let's have snapshots [22:53:02] as long as we have alexxy to make em eh? :P [22:53:05] the point is, people come here and report that they are broken (like pykde4 + some temporary svn issues) and expect us to fix it [22:53:28] and I'd prefer kde devs were not bothered with this :P [22:53:57] oh, and they makes repoman full takes longer :) [22:54:18] we could add ewarn-that-no-one-reads to snapshot ebuilds *** NO SUPPORT ANYWHERE *** :P [22:54:21] reavertm: then simply add something like [22:54:22] (whatever this means in english :P) [22:54:35] reavertm: I agree with bonsaikitten, but we should add a note that may have been lost with time - let's add a pkg_postinst for those ebuilds telling users not to report bugs to Gentoo [22:54:42] snapshot is known to be broken so report all busg about them to bugs.kde.org [22:54:43] =) [22:54:46] to eclass [22:54:53] omg [22:55:03] something like that, yes [22:55:10] they'll come down to us with grenades man [22:55:11] lol [22:55:15] also - less versions - less synchronization work [22:55:17] okay with me, so long as it's conditional on [[ -z ${I_KNOW_WHAT_I_AM_DOING} ]] :) [22:55:28] (the message, that is :) ) [22:55:31] I know not all of you do ebuild synchornization work but.... :) [22:55:58] and I don't mind dropping those versions, either :) [22:56:13] at least I'm not going to touch them anymore [22:56:59] and I don't want to see blocks involving 4.3.56 -> 4.3.57 changes in ebuilds :P [22:57:11] *** Parts: Pesa (n=Pesa@bluemchen.kde.org) [22:57:12] so lets leave it at "as long as someone is interested lets keep em and add a fat warning in eclass" [22:58:03] *** Joins: Pesa (n=Pesa@bluemchen.kde.org) [22:58:12] great [22:58:15] actually we should only provide blocks that involve versions that are going to be in tree [22:59:11] pesa [21:57:13] so lets leave it at "as long as someone is interested lets keep em and add a fat warning in eclass" [22:59:40] fine with me, thanks :) [22:59:57] i don't really use them [23:00:34] reavertm: why? if something has rdep "! so, anything else left for today? [23:01:18] i think we're good [23:01:22] assuming all goes well [23:01:35] next week we'll be ready [23:01:47] ABCD: it's about always increasing bloat and complexity of those blocks [23:01:48] whoever closes the last blocking bug should bug all the rest [23:02:06] and begin stab(ilization) procedures :) [23:02:29] reavertm: that's why I created a add_blocker function that takes care of all that stuff [except that I was told I shouldn't use it yet...] [23:02:39] *** Parts: Pesa (n=Pesa@bluemchen.kde.org) [23:02:52] ok, then I'm going to do something "stupid" like watching tv or playing a stupid psp game ;) [23:02:55] I know [23:03:23] jmbsvicetto: yay! heheh, i'll fire up my xbox :P [23:03:45] :) [23:03:48] later [23:03:53] meeting end! [23:04:00] jmbsvicetto: i'll add log same place :) [23:04:24] wired: thanks