[00:02] TheMuso, robert_ancell, bryceh, RAOF Eastern Edition? [00:02] Sure. [00:04] Yup. [00:05] go [00:05] k [00:05] should be right quick [00:05] how about I touch on the highlights, then you can read the wiki at your leisure? [00:05] https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-04-06 [00:05] so first: [00:06] 1. Welcome Nafai to the team [00:06] he started full time last Thursday [00:06] he'll be working with didrocks on UNE, and also other coding tasks [00:07] for partner update, the thing here is that Gwibber is still giving lots of heart ache [00:07] basically, it thread locks when trying to access the key ring [00:07] and this pegs the CPU to 100% [00:07] * TheMuso saw that bug. [00:07] it doesn't look easy to fix without a pretty major refactoring [00:07] heya [00:07] anyone can feel free to take a look there and see if they can help [00:07] hiya bryceh [00:08] kubuntu is looking good [00:08] so, blueprints [00:08] I'd like everyone to have a *list* of blueprints ready to discuss at next team meeting [00:09] you don't have to have the blueprint all detailed out, but a list of topics you want to cover at UDS [00:09] for ones you are certain about, seb128 says to go ahead and log the blueprint [00:09] for ones you are not certain about, add the list to your section for your activity report [00:09] Sounds good. [00:09] Yup [00:10] if you haven't been through blueprinting before, or don't know what blueprints you want to create, to talk to me me/or pitti and/or seb128 [00:10] sound good? [00:10] yep [00:10] for release status, well ... we're getting down to the end [00:10] pitti notes all the work is done, but we've got some bugs, some bad ones [00:10] RAOF, shall I register the Xorg blueprints or would you prefer to? [00:10] and only 9 days left before final freeze [00:10] https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus [00:11] bryceh could you walk RAOF through the process some time this week? [00:11] rickspencer3, certainly [00:11] bryceh: I'd like to learn the blueprinting ropes, yeah. [00:11] I think it would be easier for you both if RAOF has logged them, but he'll need some help [00:11] also RAOF may want to make one or two of his own [00:11] :) [00:12] alright, we can tackle it after the meeting [00:12] robert_ancell, well well well, you'll be back on the desktop team! [00:12] that will be so awesome [00:12] rickspencer3, yay! [00:12] so think about blueprints that you want to do [00:13] I started a list of ones that I am interested in here: [00:13] https://wiki.ubuntu.com/DesktopTeam/10.10/BlueprintList [00:13] that was the meeting [00:13] short and sweet. [00:13] bryceh, anything to discuss/report regarding xorg? [00:13] TheMuso, same question for sound [00:14] rickspencer3: No, except for the bug we were talking about yesterday, which I will continue looking into today, need to read the latest bits on the bug from overnight. [00:14] k [00:15] TheMuso, this is only certain Mac models, right? [00:15] rickspencer3: its not mac, its thinkpad. [00:15] oh [00:15] sorry ideapad [00:15] ah [00:15] bummer [00:15] rickspencer3, plenty of bugs, but I think we're doing ok [00:16] bryceh, plenty of bugs, or plenty of bug reports? ;) [00:16] rickspencer3, plenty of bug reports ;-) [00:16] there seem to be no major catastrophes going on, which is nice [00:16] I think the X bugs look a little worse than it is; I think that lots of the Intel reports I looked at yesterday should be fixed in the 2.6.32-19 kernel. [00:16] bryceh, any progress on the bug where clutter crashes when programs exit? I saw there was a patch for it, but bug reports seemed to suggest it didn't work everyone [00:17] rickspencer3, that's right. It's looking to be a kernel bug, but I'm still tracking it. Sarvatt has been identifying patches which may be relevant [00:17] * rickspencer3 gets bug # [00:17] http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid-workqueue.svg [00:18] ^ shows we're getting new bugs coming in at a pretty heavy clip but all the bumpiness in the graphs show that triagers are quite active [00:18] http://bugs.launchpad.net/bugs/550218 [00:18] Launchpad bug 550218 in xorg-server "xserver crashes when closing application using clutter" [High,Confirmed] [00:18] I managed to get -ati completely caught up for a few moments yesterday :-) [00:19] wow [00:19] pretty neat [00:19] bryceh, I see you only have 2 Highs assigned to you [00:19] seems quite a change from previous releases ... great job! [00:20] yeah, I need to review that patch sarvatt posted last night, it sounds like it might be a good fix [00:20] nice [00:20] well ... that's all I want to pester you guys about this morning/afternoon [00:20] any other business? [00:20] rickspencer3, yeah I tell you this approach of looking only at bugs tagged 'lucid' helps a lot, since I can focus a lot more on the most relevant bugs [00:21] bryceh, that's great to hear [00:21] sounds a lot saner too [00:21] bryceh, I'm hoping you bake some of this learning (and these sweet charts) into launchpad during Maverick [00:21] so..... just put the beta on my new computer [00:21] oh I've got one other thing... [00:21] go ahead [00:21] 13 seconds from grub to sitting at my desktop with nautilus and panel loaded [00:21] I've produced reports of 'upstream-fixed' bugs [00:22] very nice. [00:22] hi desrt [00:22] rickspencer3: hi :) [00:22] oh wait, it's broke [00:22] rickspencer3, nevermind [00:22] hehe [00:22] * bryceh gtg's a todo [00:22] bryceh: you're using gtg? nice. [00:23] bryceh, I need an irc interface into your gtg [00:23] bryce doesn't just *use* gtg [00:23] hehe [00:23] he *is* gtg [00:23] :) [00:24] nah I just contribute bits and pieces to it when I have free time, which these days is hardly ever ;-) [00:24] lol [00:25] well, I was a bit referring to how organized you are [00:25] but yeah, there's the contributions too ;) [00:25] oh, heh, that's true! [00:25] desrt, so you're finding the beta ok? [00:26] i've had *a lot* of issues [00:26] almost all of them X-related [00:27] like X crashes on startup on this new dell PC i got [00:27] it has some ultra-new nvidia card in it that's not properly covered by nouveau yet [00:27] works OK with binary drivers [00:27] desrt, RAOF will be interested in looking at the bug reports you file about the -nouveau issues [00:28] He will indeed. [00:28] desrt, so long as at least one video driver is sufficing to get you up and running, though, that's the important thing [00:28] ah, nvidia [00:28] City of myyystery? [00:28] true [00:28] bryceh: ya. i honestly don't care too much about the opensource-purity thing anymore [00:28] we've had uses in much worse situations I suppose [00:29] i lose too much of my tiem and sanity being a freedom warrior when it comes to graphics drivers [00:29] we're sort of viewing nouveau in lucid mainly as a bridge to get the binary driver installed, since -nouveau lacks 3D and other niceties [00:29] Being an NVIDIA user myself, it is nice to not have to install NVIDIA drivers any more to use my system at a deacent performance. [00:29] desrt, did jockey do the right thing for you then? [00:29] no? [00:29] (install the binary driver easily)? [00:29] * TheMuso doesn't need 3D. [00:29] A better -nv for the moment. Maverick should include nouveau's 3D too, I think. [00:30] i didn't even get the chance. it crashed on startup. [00:30] first boot [00:30] oddly, the installer CD was fine [00:30] ewe [00:30] RAOF: Nice. [00:30] so not sure what the difference there is [00:30] RAOF might know [00:30] maybe it's because i plugged my second monitor in after that [00:30] desrt, out of curiosity after crash did it boot into failsafe mode? [00:30] no. i don't think so. [00:30] i had to manually go into recovery mode [00:30] desrt: Oh. By “crash” do you mean “plymouth hung at five red dots”? [00:30] and install the binary driver [00:31] RAOF; yes. that's distinctly possible [00:31] ah [00:31] that certainly describes what i was seeing on the screen at the time [00:31] yeah that's not a "crash" but rather a "freeze" (or "gpu hang") [00:31] desrt: Welcome to the wonderful world of bug #533135 [00:31] glad you know about it [00:31] Launchpad bug 533135 in plymouth "System fails to boot with plymouth installed (nouveau driver with >1 display)" [Medium,Triaged] https://launchpad.net/bugs/533135 [00:32] installing the nvidia binary driver gives me a really ugly plymouth [00:32] to be honest, i'm not sure why you guys bothered [00:32] * RAOF quite likes the text-mode plymouth. It's neat! [00:32] the thing boots in the blink of an eye anyway [00:32] Sounds like vga16 wasn't ready in time for lucid... [00:32] RAOF: is there a way for me to get the text-mode one? [00:33] my bootup tends to be something like: [00:33] first 2 seconds: nothing [00:33] next 5 seconds: blinking cursor, sometimes an fsck message [00:33] next 1 second: some flicker or somthing [00:33] next 1 second: i see plymouth [00:34] then: X is loaded, login screen [00:34] i'd much rather look at 2 seconds of nothing followed by 7 seconds of some pretty text-based thing followed by X :) [00:35] I thought the 5 seconds should have a plymouth screen on them. [00:36] * desrt reboots, takes careful notes [00:36] There's a plymouth-set-theme or something to switch between themes; you could swith to text there. [00:52] ok. my numbers are pretty much correct [00:53] the splash is up for ~1sec [00:53] desrt, I think that plymouth is actually not working on computers with hard drives (as apposed to SD drivers) atm [00:53] that may have been fixed though [00:53] SD drivers? [00:53] I mean sd drives, sorry [00:54] well, this has an ssd [00:54] oh [00:54] then it should be working in any case [00:54] it's an sata ssd, if that makes a difference [00:54] desrt, there is something wrong [00:54] meh. i don't lose too much sleep over it [00:54] like the fsck message should be handled by plymouth and such [00:55] 5 seconds of looking at a blinking cursor instead of a pretty screen isn't high on my worries list :) [00:55] especially since it looks like your boot is like 10 seconds ;) [00:55] more or less [00:55] my girlfriend took a video of the boot and she's uploading it to youtube now [00:55] still, some users will be bothered by the boot not being "pretty" [00:56] it's taking a while because the file is big, but i'll share the link when it's done [00:56] kewl === bjf is now known as bjf-afk [01:17] RAOF: http://www.youtube.com/watch?v=jX9L1VPjgEA [01:18] that's what i get [01:24] Hm. I think that looks about right, actually. You could get an earlier splash (at the expense of slightly slower boot) by including the kms drivers in the initramfs (my laptops have this, because it's needed for cryptsetup), but that looks to me like plymouth starts up pretty much once you've left the initramfs, which is as soon as it can be. [01:25] so i ask again: why bother? [01:26] if the soonest that plymouth can start up is about 1 second before X starts.... [01:28] On stonking fast hardware, yes. And plymouth isn't just the bootsplash; IIRC it's also useful for user-prompting and it *should* give a nice fsck progress info box thingy. [01:30] ah === bjf is now known as bjf-afk [01:31] let me see about marking my drives for mandatory fscking on next boot [01:51] desrt: afaik thats not possible any more with upstart... [02:32] arrrg, what happened to pinned tabs in Chromium?! :( [03:37] hey rickspencer3 [03:38] hi kenvandine [03:45] hey, my two favorite guys [03:45] so ..... any word on gwibber? :-) [03:45] not yet... [03:45] called in the big guns... Nafai is going to try to crack it :) [03:46] is it looking like the fix will have to be deep? [03:46] it looks like python multiprocessing just doesn't like gobject threads [03:46] mhm [03:46] it might require a pretty significant refactoring in gwibber in order to use the keyring [03:47] unless Nafai can figure out a way to make it work :) [03:48] well, yeah, I figured as such [03:48] kenvandine, are there tests for Gwibberg? [03:48] Gwibber, even? [03:48] Gwibberg is another project i am working on [03:48] hehe [03:49] hmm [03:49] kenvandine, perhaps we could spend one day writing tests [03:49] * LaserJock imagines rickspencer3 toiling away in a secret basement lab [03:49] then refactor the code starting the next day? [03:49] rickspencer3, i have a good test case already [03:50] kenvandine, test cases for gwibber? [03:50] no... but for this problem [03:50] right [03:50] outside of gwibber [03:50] we need a test suite though [03:50] but you need to make sure you don't introduce regressions [03:50] one of the things i want to work on :) [03:50] right [03:50] so what I am suggesting is this [03:50] we can't write a test suite in the next couple days :) [03:50] 1. tomorrow is dedicated to writing a test suite [03:50] * kenvandine is on vacation tomorrow :) [03:50] 2. next day we start refactoring [03:51] ok, then move it up to Thursday [03:51] :) [03:51] we really only need to untangle the key ring part, [03:51] so we can focus writing tests in that area [03:51] I don't foresee an easy fix [03:52] we still have 9 days to move this forward, which should be enough for this problem [03:52] actually that is the least of my worries :) [03:52] what else are you worried about? [03:52] it is easy to see if the keyring is a problem with the refactor [03:52] it is all the "operations" [03:52] ryan writes very compact code :) [03:53] so he has this constructor that creates a number of different types of operations [03:53] and they get wrapped up and thrown at map_async to run them [03:53] hmmm [03:53] i am just worried about the potential breakage we could hit move that out of map_async [03:54] hello, [03:54] kenvandine, what is map_async exactly? [03:54] I've been having problem sending to the desktop mail list [03:54] from multiprocessing.Pool [03:54] I've contacted the owner but nothing changed [03:54] any one can help? [03:55] rickspencer3, it runs a method in a pool of processes and handles calling the defined callbacks for success, failures... timeout, etc [03:55] kenvandine, is it ryan's code? [03:55] rickspencer3, do you own that list? [03:55] or part of a library [03:55] rickspencer3, yes [03:55] kenvandine, no [03:55] kenvandine, it's ryan's code? [03:55] all ryan's [03:55] and it is kind of ugly [03:55] an every operation goes through there? [03:55] yes [03:56] however... it is possible that the nature of this will make the refactoring easy... assuming we understand what it is doing :) [03:56] easy as in # of lines to change [03:56] but my fear is all the corner cases [03:57] kenvandine, is multiprocessing a python library? [03:57] besides all that, i am surprised that something so generally useful like python multiprocesssing just can't be made to work with gobject [03:57] yes [03:58] it handles dispatching operations into separate processes that share some data [03:58] so it all gets channeled through line 339 of dispather.py [03:58] yes [03:59] so we either find the magic "make it work" flag [03:59] pool.map_async(self.func, self.iterable, callback=self.callback).get(self.timeout) [03:59] that runs every operation [03:59] or we change map_async.run() to use some other threading mechanism [04:00] basically write our own map_async() [04:00] yeah, gut the MapAsync class and make it run them a new way [04:01] jeezum [04:02] this is almost exactly like my asynch_task_progressbox class [04:02] humm [04:02] pastebin? [04:02] what does iterable do? [04:02] that is operations [04:02] a list of operations [04:02] kenvandine, you can look at quickly.widgets.asynch_task_progressbox.py [04:03] it just uses python threads [04:03] so it [04:03] s week [04:04] kenvandine, would this work at all with threads? [04:04] i think so [04:05] obviously it would lack the ability to use mutliple processors and such [04:05] kenvandine, what does iterable do? [04:06] it is a list of things to do [04:06] so in this case it is a nested list i think [04:07] I see [04:07] like a list of functions to call? [04:07] no :) [04:07] they all call perform_operation [04:07] but look at the args to perform_operation [04:08] the args to that method is a single item in iterable [04:08] so it's useless [04:08] def perform_operation((acctid, opname, args, transient)): [04:08] (acctid, opname, args, transient) [04:08] that is a single item in a list [04:09] so it calls perform_operation a bunch of times in parallel with a different operation for each [04:09] like twitter:receive, twitter:replies, twitter:private_messages [04:09] etc [04:09] if you post a status update [04:10] it creates a list of operations that include send for each service you have send_enabled for [04:10] and calls them all in parallel [04:10] this is also why it is so hard for us to know if a single operation fails or not [04:11] i actually really hate this code [04:11] if there are problems it is quite hard to really get in and figure it out to debug [04:11] however... i have never actually found a bug in this code path... but have looked there many times [04:14] yes, it's hard to read [04:14] and it may not be buggy per se [04:15] rickspencer3, it is a pain though [04:16] yes indeed [04:16] i don't think we should touch perform_operation though [04:16] but perhaps the pool stuff that calls it [04:18] rickspencer3, i am still hoping the awesome Nafai comes through... it is nice to use the library to do it :) [04:18] seems that perform_operation could be put on a thread manually [04:19] kenvandine, would gwibber break if each operation was done in sequence instead of in parallel? [04:20] shouldn't [04:21] jeezum [04:21] MapAsync is itself a thread [04:21] which then spawns all these processes [04:22] i don't know if there is a specific reason he chose it [04:22] dude, what if we just set processes to 1? [04:23] i tried [04:23] doesn't work [04:23] i also tried chunksize 1 [04:23] dang it [04:23] no easy answers [04:24] yeah... tell me about it [04:24] wouldn't chunksize kinda be 1 by default? [04:24] i think so, but that isn't clear [04:24] learning a little more about this pool stuff has been intersting [04:24] it is cool stuff [04:26] yeah [04:26] but when you write threaded code, it has to be tight and readable :/ [04:26] And preferably not actually threaded :) [04:27] (I've played with twisted before, and the Deferred stuff is nice) [04:27] yeah [04:28] kenvandine, calling pool like this seems to be working for now: [04:28] pool = multiprocessing.Pool(1) [04:28] maybe it's just luck though [04:29] yeah, looks like it was just luck, when I told gwibber to refresh it pegged again [04:31] rickspencer3, it takes 2 or 3 refreshes to see it [04:31] yeah [04:31] which i find weird [04:31] well, it pretty reliable pegs on the first try for me [04:32] http://pastebin.ubuntu.com/410145/ [04:33] that is a good script to play with for trying to make the pool stuff work [04:33] so ken, you think the best approach is to try to make the call to the keyring work in the existing model [04:33] rather than try to refactor the code? [04:34] yes [04:34] if it can work... [04:34] although i was ready to give up yesterday :) [04:34] you need a day off [04:35] i do [04:35] :) [04:35] I'll put Nafai on this full time starting tomorrow [04:35] great [04:35] RAOF, what are you working on? [04:35] X bugs, and lentil soup. [04:36] Particularly: making it so that lucid will boot on recent macbook pros. [04:36] mmm [04:36] that sounds important too :) [04:37] A bit of python hacking sounds fun, though. [04:37] ha... this isn't the fun kind :) [04:39] RAOF, yeah, so this is a pretty tough nut [04:39] I'm always suspicious of python without unittests :). [04:40] basically, if you can make that script that ken pasted in work [04:40] without pegging the CPU, obviously [04:41] i really need to resurrect those tests [04:42] and create mock stuff for all the services [04:42] can gwibber just get all of the passwords it needs and store them in memory [04:43] and then replace the call to the king ring to a call to a new function that just reads from a dict? [04:43] potentially, i looked at that [04:43] then we need to add the credentials to the operation [04:44] it is nearly as much code to change as refactoring out the pool code [04:44] really? [04:44] and... we would need a way to change that password if the user does [04:44] we can't just write a module [04:44] yeah, cause some services use a secret_key, some password, etc [04:45] an replace a call to that module where the call to the key ring occurs? [04:45] right [04:45] oh, that doesn't work :/ [04:45] cause it gets called from that thread [04:45] i did that [04:45] Or just monkey-patch gnomekeyring to take a lock before all the operations? [04:45] same thing happens [04:46] kenvandine, I mean, write a module that gets all the credentials at startup out of the keyring [04:46] RAOF, i tried that [04:46] and stores those in a hash [04:46] rickspencer3, oh.. yeah... humm [04:46] and then just make that hash globably accessible [04:47] we need a way to update it if the password changes [04:47] I'm actually a bit surprised that works at all; libgnome-keyring is pretty aggressively thread-unsafe in my experience. [04:47] RAOF, it doesn't work at all [04:47] RAOF, exactly [04:47] it threadlocks [04:48] hmm [04:48] if the password changes [04:48] although, this example works fine [04:48] Perhaps I should rephrase. “I'm surprised it doesn't assert() out immediately” [04:48]