[00:00] hi bryceh, RAOF, TheMuso [00:00] Hey. [00:00] so no robert_ancell? [00:00] Good morning. [00:01] he's resting on his well-deserved laurels? [00:01] TheMuso, RAOF so I've been waaay to busy to update the wiki for hte meeting today :( [00:01] rickspencer3: Thats fine. [00:01] but I can remember the high points [00:01] rickspencer3: He is OS [00:01] OS? [00:01] out sick? [00:01] Overseas with the OEM guys [00:01] In Taipai. [00:01] so he's finally beened poisoned by GDM? [00:02] ok, we'll have to carry on without him [00:02] part 1 - partner update [00:02] basically, desktopcouch has been crashiiiiiing [00:02] but looks to be fixed, and kenvandine will upload the fix [00:02] meantime, since the meeting, this uncovered a but in gwibber account set up [00:02] I plan to give Gwibber a go today, should I wait? [00:03] but I don't expect it to be too hard [00:03] TheMuso, no, go ahead [00:03] ok [00:03] the bug only effects you if you've set it up on one computer, then synch your account settings on another computer, and do a gwibber first run [00:03] ah ok. [00:03] so next was Kubuntu [00:03] basically, teh status there is the Kubuntu team is doing awesome' [00:04] then we talked about x [00:04] this was not as fun [00:04] this was 845, 855 [00:04] bryceh, do you want to fill TheMuso on this? [00:05] I remember seeing bits of that discussion yesterday, so no its fine. [00:05] sure [00:06] 8xx has been a problem area for a long time but seems to just get worse and worse... we've been having lots of reports of X freeze issues [00:06] we've been pulling upstream patches, which seem to address some freezes but not all [00:06] at this point what we're doing is disabling functionality, starting with kms and dri on select cards [00:07] ouch [00:07] RAOF, care to add anything regarding 8xx? [00:08] Quick question out of scope for the meeting, how does one re-enable control + alt + backspace these days? [00:08] The big fundamental problem seems to be that it's easy to get the CPU and GPU out of sync, so the GPU will try to execute commands that haven't been flushed to memory yet. [00:09] TheMuso, the keyboard settings capplet has an option for it [00:09] There's a crazy huge patch upstream which may work, but there have been previous crazy huge patches that seemed to work, so... [00:09] bryceh: thanks [00:10] * rickspencer3 shudders [00:10] ok [00:10] so then we discuss blueprints [00:10] RAOF, indeed [00:11] RAOF, it's very reminiscent of some of the 9xx freezes we had at this point in past releases. [00:11] bryceh, RAOF, would it be worth putting that patch in a PPA for users who choose that route? [00:11] if it turns out to be the right thing, we could consider picking it up for 10.04.1 [00:11] rickspencer3, not a bad idea - RAOF does it look feasible for xorg-edgers? [00:12] It'd be fine in xorg-edgers. We'd need to get a working full-kernel build in there, but that shouldn't be too hard. [00:12] ouch [00:12] Everything requires a kernel patch! [00:12] however, we are explicitly choosing to maximize stability at the expense of some functionality for some users [00:12] and "some" is a non-trivial percentage [00:13] but it's the right call [00:13] RAOF, actually maybe better to have a separate ppa if it needs a tweaked kernel [00:13] I'd rather the see the "I want my compiz" than the "I lost my data" bugs [00:13] Or, in extreme cases, “I can't get to gdm” [00:13] :/ [00:13] ok [00:14] who owns setting up the patch so that it is installable by users who want it? [00:14] * rickspencer3 looks meaningfully at RAOF [00:15] Yeah. I'll take that. I want to get a kernel build in xorg-edgers anyway, for nouveau. linux-backports-modules-nouveau is getting a little out of sync. [00:15] bryceh, do you think this needs to be done by release time? [00:15] it seems a bit orthagonal to release [00:16] * bryceh ponders [00:17] ok [00:17] rickspencer3, I think it's ok as an SRU in this case [00:17] we can let that run on background thread [00:17] bryceh, I meant, "can RAOF put off working on the PPA a bit while he focuses on the release" [00:17] or do you think we'll need it ready soon? [00:17] I'll let you two decide that though [00:18] rickspencer3, it's not something that has to be done prior to final freeze [00:18] ok [00:18] so, we also discussed blueprints [00:18] so raof can schedule at his convenience [00:18] TheMuso, I am afraid this puts you a bit on the spot [00:19] as we discussed x blueprints this morning [00:19] Right [00:19] so, seb128 and I put together a bit of a schedule [00:19] rickspencer3: The three things I have for maverick, probably all needing blueprints are the following: [00:19] https://wiki.ubuntu.com/DesktopTeam/10.10/BlueprintingSchedule [00:19] 1) get accessibility and GNOME 3/at-spi2 over dbus working nicely. [00:20] 2) replace speech-dispatcher with a recently forked project of speech-dispatcher, called OpenTTS. [00:20] 3) add a console screen reader to Ubuntu. [00:20] TheMuso, I like and support those [00:20] but .. [00:20] sound? [00:20] this seems always a hot topic at UDS [00:20] Well, out of those, 2 should take the least amount of time [00:21] mmm [00:21] TheMuso, do you need a pulse session? [00:21] or perhaps crimsun will be planning that? [00:21] rickspencer3: I don't think so, but others always think we do. [00:21] TheMuso, right [00:21] it seems like "integrate upstream and fix bugs" [00:22] needs minimal discussion [00:22] right./ [00:22] ok [00:22] RAOF, aside from the blueprints you've registered any questions? [00:22] (as you've not been through this before) [00:23] I'm going over that blueprint schedule. [00:23] ok [00:23] just let me know if you have any questions [00:23] I'll register blueprints today/tomorrow. [00:23] bryceh, I'd appreciate your feedback on the schedule I linked to [00:23] One blueprint that I haven't registered yet was easy colour calibration/correction. [00:23] RAOF, ack [00:23] that sounds like a good one [00:24] TheMuso, RAOF, bryceh any other business? [00:24] no [00:24] No [00:25] ok [00:25] I'm going offline and heading home [00:25] bbl [00:25] thanks guys! [00:26] np [00:28] thanks [00:30] 00/c [01:57] kenvandine, hi [02:24] Doe anybody know what signal is given if one kills the desktop with ctrl + alt + backspace, i.e are processes killed with SIGKILL, or something else? [02:25] I thought the processes died because they lost their X connection rather than being explicitly killed? [02:26] RAOF: I don't know. This is why I am wondering. [02:27] * RAOF has a spare netbook for answering these sorts of questions. [02:27] Xlib exits when you loose the X connection [02:29] hrm ok. [03:19] TheMuso: SIGHUP [03:24] Sarvatt: thanks. [03:30] hey rickspencer3 [03:35] kenvandine, how goes it? [03:35] seems folks are pretty happy about chad's fix so far [03:35] yup :) [03:35] kewl [03:35] i am just about to dive into the gwibber bug [03:35] the password one> [03:35] ? [03:36] finally got the kids to bed... [03:36] yeah [03:36] I'm guessing that won't be too tough [03:36] crazy with having to eat out and hotel and all [03:36] nah [03:36] seems a run of the mill logic error [03:36] it's just weird [03:36] oh, right, your stuck in a hotel because of your floors [03:36] yeah... [03:36] that bites [03:36] likey bitey mcbites [03:36] i had saw dust in my beard! [03:37] and my door was closed :) [03:37] lol [03:37] our house is going to be a real mess [03:37] we've beent through the floors thing a couple of times [03:37] you'll be happy when it's done [03:37] yeah [03:37] it looks awesome [03:37] first coat of stain is down, saw it tonight [03:37] we can go back home tomorrow night [03:38] and move furniture back in on saturday [03:38] it's going to stink! (if our experience is any guide) [03:38] yeah [03:38] i am sure [03:38] tonight I shall dive a bit into map/reduce, I think [03:38] read up on it a bunch last night [03:38] awesome [03:38] I think desktopcouch needs an async api [03:39] when I do stuff with the gwibber database, it can really lag [03:39] * TheMuso is not a fan of renovations either. I feel your pain. [03:39] good luck on the gwibber password thing kenvandine! [03:40] ttyt [03:40] nite rickspencer3 [03:40] 'night. [03:40] banshee's support for my android is soooo much nicer than rhythmbox [03:40] bcurtiswx, are you staying up to keep an eye on kenvandine, make sure he fixes your bug? [03:40] :) [03:41] kenvandine, you should show us at UDS [03:41] rickspencer3: umm.. yes... it just helps prove i have no life :P [03:41] we can make RB better too [03:41] bcurtiswx, ;) [03:41] bcurtiswx, do you know python? [03:41] i want to.... [03:41] kewl [03:41] do it [03:42] if you learned you could fix bugs yourself, and make things work the way you want them to [03:42] rickspencer3, the difference in the user experience syncing music and stuff to my G1 between banshee and rhythmbox is like comparing a bmw to a pinto [03:42] any good beginners guides (other than dive right in) [03:42] kenvandine, you fanboy! [03:42] bcurtiswx, yes! [03:42] rickspencer3, i haven't really used banshee in a good six months :) [03:42] there is a really good mit class on it [03:42] * rickspencer3 looks [03:42] but i installed it again to test the u1music store in it [03:42] im close enough to ken, i'll give him a good slap across the face, or punch in the shoulder next time i make it to NC [03:43] hehe [03:43] bcurtiswx, where are you? [03:43] Northern VA [03:43] bcurtiswx, http://academicearth.org/courses/introduction-to-computer-science-and-programming [03:43] cool [03:43] bcurtiswx, I lived in Alexandria, VA for basically the 90s [03:43] bcurtiswx, near DC? [03:43] up until 1998 [03:44] kenvandine: yes, DC LoCo member with Crimsun and Maco [03:44] bcurtiswx, I would start on that class I linked you to [03:44] awesome [03:44] then when you get board with that ... [03:44] start with quickly [03:44] and join #ubuntu-app-devel [03:44] and start writing an app [03:44] rickspencer3: when i get free time i will def [03:44] its bookmarked [03:44] :) [03:44] * rickspencer3 wants everyone to know python :_ [03:45] well, it beats ARMv7 asm, that's for sure. [03:45] * kenvandine wishes we had a test suite for gwibber :/ [03:45] Python is *so* much more fun with a test suite. [03:45] kenvandine, UDS session? [03:46] seems something we could crowd source [03:46] yeah... perhaps [03:46] not until a UDS in which Canonical will pay for me to attend ;-) [03:46] crimsun, lol [03:46] i was thinking about creating the test suite first and then crowd sourcing test writing :) [03:46] bcurtiswx, you can attend remotely [03:46] yeah [03:46] rickspencer3: yup, i randomly skip work at times to see a few [03:46] like get 10 people to write 10 tests a piece [03:46] never written a test suite from scratch, just written tests [03:47] so it will be fun [03:47] one key thing I have found is to never fix a bug without writing a test first [03:47] yup [03:47] so at $JOB - 1 that was the culture [03:47] of course, I often ignore my own good advice ;) [03:47] no bug ever got fixed until the test was in the test suite [03:47] yeah [03:48] but if there is no test suite, it's tempting to keep fixing bugs [03:48] and often we created tests for new features and developed to the test [03:48] yeah :) [03:48] so we'll put the breaks on that for gwibber in Maverick [03:48] rpath has an awesome test driven development culture [03:48] the nice thing about test first is that it gives you a strong sense of progress [03:48] I made n tests work today [03:48] yup [03:49] and writing the test helps flush out the feature [03:49] sometimes... sometimes it is just lots of spinning wheels [03:49] * rickspencer3 nods [03:49] but for bug fixing for sure... [03:49] yeah, or sometimes it's *really* hard to write an automated test [03:50] like testing async code that requires UI and such [03:50] i fear that will be the case for a bunch of gwibber stuff [03:50] like we will need to mock out the services, facebook, etc [03:50] well, I have a bit of experience with pygtk [03:50] I wrote some tests for quidgets [03:50] and they helped a lot [03:50] good [03:50] and for non-trivial bugs I add a test before I fix them [03:50] but the coverage is spotty at best [03:51] i'll look at what you did there [03:51] so good UDS session [03:51] kenvandine, well, it's a lot of inspecting the treeview model [03:51] and I haven't done any for filters [03:52] just because it's too tedious to write the test code to select them and such [03:52] but I shouldn't be so lazy ;) [03:52] 'night guys! [05:57] Good morning [06:01] Morning pitti. [06:48] pitti: re at-spi again, a few weeks ago you suggested I add a sleep call after root window properties were set. Here is the boot chart after doing so. http://www.themuso.id.au/bootchart/strigy-lucid-20100414-1.png [06:49] TheMuso: can you please remind me again what the problem was? [06:50] TheMuso: hm, that is a 0-byte file [06:50] hrm ok hang on [06:50] pitti: the at-spi race condition. Sometimes panel/applets/desktop are not accessible. I can't reproduce it in the desktop, but other people can. [06:53] TheMuso: does it reproduce with the sleep call? [06:55] pitti: Since I can't reproduce myself, I need to get others to test that. Getting the package ready for PPA now, but I wanted to give you the boot chart, as you wanted to see whether the sleep call would affect much. [06:56] pitti: Ok here it is on another host: Seems the other one is not doing well with scp. http://packages.themuso.com/strigy-lucid-20100414-1.png [06:59] TheMuso: hm, that just gets to gdm, it's not autologin [06:59] TheMuso: it seems at-spi does't run in the gdm session? [06:59] I can't find at-spi at all on that chart [07:00] pitti: Right, at-spi only runs if accessible login is enabled. Hold on, I'll enable autologin and get another one. [07:00] TheMuso: so what I meant is, with introducing that sleep, this should reproduce the race condition much easier; did that work? I. e. is it broken with the sleep now/ [07:00] ? [07:00] pitti: not for me [07:01] TheMuso: so, ideally we would see an at-spi process which hangs for some seconds (the sleep), and nothing else would start in parallel [07:01] right [07:01] TheMuso: ok, let's get the autologin boot chart [07:02] ok brb [07:06] pitti: http://packages.themuso.com/strigy-lucid-20100414-1.png [07:07] TheMuso: ah, splendid [07:07] TheMuso: you did a 3 s sleep? [07:08] TheMuso: so, it seems most programs indeed block on at-spi to start up, except for pulseaudio and gnome-settings-daemon [07:08] TheMuso: I suppose PA is alright to start in parallel, since it doesn't have UI [07:09] pitti: right, yes it was a 3 second sleep. [07:09] TheMuso: I'm not sure about g-s-d; it doesn't have UI of its own either, but it certainly controls how other programs look (loading themes, etc); I'm afraid I don't know enough about SPI to tell whether g-s-d needs it, do you? [07:10] pitti: No I don't. Afaik GTK just loads the a11y modules if it sees the at-spi properties on the root window. [07:10] TheMuso: right, that would mean that each program needs to load SPI individually, right? [07:10] TheMuso: so, this chart looks fine to me [07:11] pitti: hrm ok [07:11] pitti: Each app using GTK would need to load a11y modules, if thats what you are getting at. [07:11] TheMuso: so it's working fine for you even with the sleep? [07:11] pitti: yes. [07:11] This is a fast box though. [07:12] TheMuso: faster boxes should be more likely to reproduce this, though [07:12] This is true. [07:12] TheMuso: so, if you have people who can reproduce this problem, I'd recommend the following: [07:12] 1) ask them to install your version with the sleep, and do a boot chart [07:13] pitti: Can do. [07:13] TheMuso: hm, I think only 1) for now; I need to see their charts to see what's starting prematurely, I think [07:13] TheMuso: just subscribe me to the bug, then I can reply directly, and you don't need to play the middle man :) [07:13] pitti: Ok, not sure if the person in question is still online, but I'll get my package into a PA and point them at it. [07:14] TheMuso: thanks! [07:14] ok will do once the package is ready. [07:14] TheMuso: for them, spi was broken on all apps, or just on some parts (like the panel)? [07:14] pitti: Just some parts. [07:15] TheMuso: oh, another interesting question for them: killall gnome-settings-daemon, alt+f2 gnome-settings-daemon (to restart it) [07:15] TheMuso: just in case g-s-d is involved into this after all [07:15] since neither of us seems to be sure about it [07:16] pitti: Right, will ask the above, point them to the package, and subscribe you, thanks for your help. [07:16] my pleasure, good luck! [07:16] thanks === dpm-afk is now known as dpm [07:39] pitti: heh I just rebooted, and with the at-spi version I built with the sleep call, I now have a desktop/panel that is inaccessible. [07:40] TheMuso: oh! did you get another boot chart? [07:41] hang on [07:42] meh, I removed it, thinking it wouldn't be needed. I'll grab again, and run. Whats the bet it will work properly. :S [07:42] good moorning [07:43] TheMuso: it will not ever fail as long as it's watched [07:43] heh [07:43] it's a fundamental principle of quantum physics [07:49] ah yes, heisenberg's *certainty* principle [07:50] it's like those days when life just goes great, and everything works out for you - you know a creator's running a debugger [07:51] heh [07:56] pitti: Ok new boot chart, and yes my desktop is inaccessible, as well as panel. http://packages.themuso.com/strigy-lucid-20100414-1.png [07:59] TheMuso: hm, I don't see an obvious difference to the previous one; does restarting g-s-d make any difference at all? [07:59] TheMuso: and can you check with xprop -root whether you have the property set? [08:00] TheMuso: (feel free to pastebin xprop -root, I can have a look) [08:06] pitti: ok just a sec, got caught up with something. [08:07] pitti: gsd makes no difference. [08:09] pitti: http://paste.ubuntu.com/414127/ [08:12] TheMuso: ok, there's AT_SPI_IOR, so the property seems to be set [08:13] yep [08:14] TheMuso: are newly started apps accessible? [08:14] pitti: Yes. [08:14] TheMuso: i. e. is this restricted to things like panel and/or nautilus? [08:14] Otherwise I wouldn't be talking with you now. [08:14] does restarting gnome-panel or nautilus help? [08:15] pitti: yes it helps [08:15] Once the apps restart, they see the accessibility property, and work normally. [08:15] TheMuso: so, panel/nautilus/etc. start immediately after the sleep(3) in at-spi-registry [08:16] TheMuso: this sounds like a-s-r needs some more initialization before it actually works? [08:16] TheMuso: i. e. it seems it registers to the session a tad too early? [08:16] pitti: I don't know to be honest. [08:17] TheMuso: I suspect the sleep helped to move the startup of panel etc. to a time where there is zero CPU activity, so their startup is much faster [08:17] which helps to trigger the race [08:17] Right [08:18] when a-s-r starts, there's still CPU activity from X, pulse, and IO from g-session [08:19] ok [08:21] TheMuso: hm, registry-main.c calls register_client() as the second-last thing before bonobo_main() [08:21] this looks alright.. [08:22] hey ccheney. do you have a estimate when a new OOo with the workaround for bug #556348 is uploaded? [08:22] Launchpad bug 556348 in openoffice.org "dapper->hardy->lucid upgrade fails with pre-depends error (fix for #442651 got dropped)" [High,Triaged] https://launchpad.net/bugs/556348 [08:23] pitti: I put my sleep call after registry_set_ior [08:24] TheMuso: seems right [08:24] good morning [08:24] ah, back in a bit [08:24] see you pitti ;) [08:47] hello [08:47] hey seb128, how are you? [08:48] hey didrocks, good! how are you? [08:48] I'm fine, thanks. I realized that I took the habits to sleep 9h a night now… That never happened to me before, that's bad… [08:49] that's good [08:49] I like to sleep 9h ;-) [08:49] I manage to do that only during weekends though [08:49] I would like to sleep 9h (or more) [08:50] but usually it does not work out :/ [08:50] I'm trying to get webservice-office-zoho to startup-notify because on slow hardware there is lag launching the browser. I changed StartupNotify to true in the .desktop file and nothing happened, has the parameter changed? [08:50] fortunately tea helps in the morning [08:51] bonjour didrocks, seb128 [08:51] hey pitti [08:51] hey mvo, hey didrocks [08:51] seb128: well,, that's good, but you lost one hour to do other things like interesting reading ;) [08:52] JamieBennett, nothing changed recently that I know about no [08:52] mvo, tea addict! [08:52] ;-) [08:52] seb128: Umm, not sure why I'm not seeing any notifications then. [08:52] * JamieBennett goes to investigate [08:52] didrocks: I never set an alarm clock; I just sleep until I wake up, which I find best [08:53] seb128: :P [08:53] which is usually 8 to 8:30 hours after I go to bed, unless I go to sleep very late [08:53] today I woke up at 6:30.. [08:53] pitti, that doesn't work for me, I would wake up at 11am every day ;-) [08:53] pitti: this is what I do too. But normally, I only sleep 7h40-8h… now it's more close to 9h, wasting time :) [08:53] seb128: don't go to bed so late :-) [08:54] didrocks: don't worry about it; cats sleep 15 hours a day and are perfectly happy :) [08:54] :) [08:54] slomo, hi [08:54] seb128: hi [08:54] TheMuso: so, I can't see something obvious in the code :( [08:54] TheMuso: obviously wrong, I mean [08:54] slomo, could you try if your updated vinagre crash when selecting a ssh gateway for vnc? [08:55] TheMuso: it might be that the XChangeProperty() call is not synchronous somehow, though [08:56] slomo, run vinagre, click connect, type a random host, click the checkbox at the bottom "use host <...> as a ssh tunnel", type a random host and connect [08:56] slomo, those don't need to be working vnc or ssh boxes [08:57] TheMuso: the only thing that still comes to my mind is to add an XSync (spi_get_display(), False); after the XChangeProperty() [08:58] yes, crashes [08:58] vinagre: symbol lookup error: /usr/lib/vinagre-1/plugins/libvnc.so: undefined symbol: vinagre_ssh_connect [08:58] wonderful :) [08:59] seb128: yes, crashes, symbol lookup error [08:59] is there a known fix already? :) [09:00] slomo_, no, that's a known issue on Ubuntu too I was just wondering if it was happening on debian or if that was a toolchain issue on lucid [09:00] slomo_, thanks for testing [09:02] well, should be easy to fix :) [09:03] let's take a look [09:07] seb128: is there an upstream bugreport? [09:08]