| rickspencer3 | TheMuso, robert_ancell, bryceh, RAOF Eastern Edition? | 00:02 |
|---|---|---|
| TheMuso | Sure. | 00:02 |
| RAOF | Yup. | 00:04 |
| robert_ancell | go | 00:05 |
| rickspencer3 | k | 00:05 |
| rickspencer3 | should be right quick | 00:05 |
| rickspencer3 | how about I touch on the highlights, then you can read the wiki at your leisure? | 00:05 |
| rickspencer3 | https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-04-06 | 00:05 |
| rickspencer3 | so first: | 00:05 |
| rickspencer3 | 1. Welcome Nafai to the team | 00:06 |
| rickspencer3 | he started full time last Thursday | 00:06 |
| rickspencer3 | he'll be working with didrocks on UNE, and also other coding tasks | 00:06 |
| rickspencer3 | for partner update, the thing here is that Gwibber is still giving lots of heart ache | 00:07 |
| rickspencer3 | basically, it thread locks when trying to access the key ring | 00:07 |
| rickspencer3 | and this pegs the CPU to 100% | 00:07 |
| * TheMuso saw that bug. | 00:07 | |
| rickspencer3 | it doesn't look easy to fix without a pretty major refactoring | 00:07 |
| bryceh | heya | 00:07 |
| rickspencer3 | anyone can feel free to take a look there and see if they can help | 00:07 |
| rickspencer3 | hiya bryceh | 00:07 |
| rickspencer3 | kubuntu is looking good | 00:08 |
| rickspencer3 | so, blueprints | 00:08 |
| rickspencer3 | I'd like everyone to have a *list* of blueprints ready to discuss at next team meeting | 00:08 |
| rickspencer3 | you don't have to have the blueprint all detailed out, but a list of topics you want to cover at UDS | 00:09 |
| rickspencer3 | for ones you are certain about, seb128 says to go ahead and log the blueprint | 00:09 |
| rickspencer3 | for ones you are not certain about, add the list to your section for your activity report | 00:09 |
| TheMuso | Sounds good. | 00:09 |
| RAOF | Yup | 00:09 |
| rickspencer3 | 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 |
| rickspencer3 | sound good? | 00:10 |
| bryceh | yep | 00:10 |
| rickspencer3 | for release status, well ... we're getting down to the end | 00:10 |
| rickspencer3 | pitti notes all the work is done, but we've got some bugs, some bad ones | 00:10 |
| bryceh | RAOF, shall I register the Xorg blueprints or would you prefer to? | 00:10 |
| rickspencer3 | and only 9 days left before final freeze | 00:10 |
| rickspencer3 | https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus | 00:10 |
| rickspencer3 | bryceh could you walk RAOF through the process some time this week? | 00:11 |
| bryceh | rickspencer3, certainly | 00:11 |
| RAOF | bryceh: I'd like to learn the blueprinting ropes, yeah. | 00:11 |
| rickspencer3 | I think it would be easier for you both if RAOF has logged them, but he'll need some help | 00:11 |
| rickspencer3 | also RAOF may want to make one or two of his own | 00:11 |
| rickspencer3 | :) | 00:11 |
| bryceh | alright, we can tackle it after the meeting | 00:12 |
| rickspencer3 | robert_ancell, well well well, you'll be back on the desktop team! | 00:12 |
| rickspencer3 | that will be so awesome | 00:12 |
| robert_ancell | rickspencer3, yay! | 00:12 |
| rickspencer3 | so think about blueprints that you want to do | 00:12 |
| rickspencer3 | I started a list of ones that I am interested in here: | 00:13 |
| rickspencer3 | https://wiki.ubuntu.com/DesktopTeam/10.10/BlueprintList | 00:13 |
| rickspencer3 | that was the meeting | 00:13 |
| TheMuso | short and sweet. | 00:13 |
| rickspencer3 | bryceh, anything to discuss/report regarding xorg? | 00:13 |
| rickspencer3 | TheMuso, same question for sound | 00:13 |
| TheMuso | 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 |
| rickspencer3 | k | 00:14 |
| rickspencer3 | TheMuso, this is only certain Mac models, right? | 00:15 |
| TheMuso | rickspencer3: its not mac, its thinkpad. | 00:15 |
| rickspencer3 | oh | 00:15 |
| TheMuso | sorry ideapad | 00:15 |
| rickspencer3 | ah | 00:15 |
| rickspencer3 | bummer | 00:15 |
| bryceh | rickspencer3, plenty of bugs, but I think we're doing ok | 00:15 |
| rickspencer3 | bryceh, plenty of bugs, or plenty of bug reports? ;) | 00:16 |
| bryceh | rickspencer3, plenty of bug reports ;-) | 00:16 |
| bryceh | there seem to be no major catastrophes going on, which is nice | 00:16 |
| RAOF | 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 |
| rickspencer3 | 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:16 |
| bryceh | 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 | |
| bryceh | http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid-workqueue.svg | 00:17 |
| bryceh | ^ 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 |
| rickspencer3 | http://bugs.launchpad.net/bugs/550218 | 00:18 |
| ubottu | Launchpad bug 550218 in xorg-server "xserver crashes when closing application using clutter" [High,Confirmed] | 00:18 |
| bryceh | I managed to get -ati completely caught up for a few moments yesterday :-) | 00:18 |
| rickspencer3 | wow | 00:19 |
| rickspencer3 | pretty neat | 00:19 |
| rickspencer3 | bryceh, I see you only have 2 Highs assigned to you | 00:19 |
| rickspencer3 | seems quite a change from previous releases ... great job! | 00:19 |
| bryceh | yeah, I need to review that patch sarvatt posted last night, it sounds like it might be a good fix | 00:20 |
| rickspencer3 | nice | 00:20 |
| rickspencer3 | well ... that's all I want to pester you guys about this morning/afternoon | 00:20 |
| rickspencer3 | any other business? | 00:20 |
| bryceh | 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:20 |
| rickspencer3 | bryceh, that's great to hear | 00:21 |
| rickspencer3 | sounds a lot saner too | 00:21 |
| rickspencer3 | bryceh, I'm hoping you bake some of this learning (and these sweet charts) into launchpad during Maverick | 00:21 |
| desrt | so..... just put the beta on my new computer | 00:21 |
| bryceh | oh I've got one other thing... | 00:21 |
| rickspencer3 | go ahead | 00:21 |
| desrt | 13 seconds from grub to sitting at my desktop with nautilus and panel loaded | 00:21 |
| bryceh | I've produced reports of 'upstream-fixed' bugs | 00:21 |
| desrt | very nice. | 00:22 |
| rickspencer3 | hi desrt | 00:22 |
| desrt | rickspencer3: hi :) | 00:22 |
| bryceh | oh wait, it's broke | 00:22 |
| bryceh | rickspencer3, nevermind | 00:22 |
| rickspencer3 | hehe | 00:22 |
| * bryceh gtg's a todo | 00:22 | |
| desrt | bryceh: you're using gtg? nice. | 00:22 |
| rickspencer3 | bryceh, I need an irc interface into your gtg | 00:23 |
| rickspencer3 | bryce doesn't just *use* gtg | 00:23 |
| bryceh | hehe | 00:23 |
| rickspencer3 | he *is* gtg | 00:23 |
| RAOF | :) | 00:23 |
| bryceh | nah I just contribute bits and pieces to it when I have free time, which these days is hardly ever ;-) | 00:24 |
| rickspencer3 | lol | 00:24 |
| rickspencer3 | well, I was a bit referring to how organized you are | 00:25 |
| rickspencer3 | but yeah, there's the contributions too ;) | 00:25 |
| bryceh | oh, heh, that's true! | 00:25 |
| rickspencer3 | desrt, so you're finding the beta ok? | 00:25 |
| desrt | i've had *a lot* of issues | 00:26 |
| desrt | almost all of them X-related | 00:26 |
| desrt | like X crashes on startup on this new dell PC i got | 00:27 |
| desrt | it has some ultra-new nvidia card in it that's not properly covered by nouveau yet | 00:27 |
| desrt | works OK with binary drivers | 00:27 |
| bryceh | desrt, RAOF will be interested in looking at the bug reports you file about the -nouveau issues | 00:27 |
| RAOF | He will indeed. | 00:28 |
| bryceh | 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 |
| rickspencer3 | ah, nvidia | 00:28 |
| RAOF | City of myyystery? | 00:28 |
| rickspencer3 | true | 00:28 |
| desrt | bryceh: ya. i honestly don't care too much about the opensource-purity thing anymore | 00:28 |
| rickspencer3 | we've had uses in much worse situations I suppose | 00:28 |
| desrt | i lose too much of my tiem and sanity being a freedom warrior when it comes to graphics drivers | 00:29 |
| bryceh | 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 |
| TheMuso | 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 |
| rickspencer3 | desrt, did jockey do the right thing for you then? | 00:29 |
| desrt | no? | 00:29 |
| rickspencer3 | (install the binary driver easily)? | 00:29 |
| * TheMuso doesn't need 3D. | 00:29 | |
| RAOF | A better -nv for the moment. Maverick should include nouveau's 3D too, I think. | 00:29 |
| desrt | i didn't even get the chance. it crashed on startup. | 00:30 |
| desrt | first boot | 00:30 |
| desrt | oddly, the installer CD was fine | 00:30 |
| rickspencer3 | ewe | 00:30 |
| TheMuso | RAOF: Nice. | 00:30 |
| desrt | so not sure what the difference there is | 00:30 |
| rickspencer3 | RAOF might know | 00:30 |
| desrt | maybe it's because i plugged my second monitor in after that | 00:30 |
| bryceh | desrt, out of curiosity after crash did it boot into failsafe mode? | 00:30 |
| desrt | no. i don't think so. | 00:30 |
| desrt | i had to manually go into recovery mode | 00:30 |
| RAOF | desrt: Oh. By “crash” do you mean “plymouth hung at five red dots”? | 00:30 |
| desrt | and install the binary driver | 00:30 |
| desrt | RAOF; yes. that's distinctly possible | 00:31 |
| bryceh | ah | 00:31 |
| desrt | that certainly describes what i was seeing on the screen at the time | 00:31 |
| bryceh | yeah that's not a "crash" but rather a "freeze" (or "gpu hang") | 00:31 |
| RAOF | desrt: Welcome to the wonderful world of bug #533135 | 00:31 |
| desrt | glad you know about it | 00:31 |
| ubottu | 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:31 |
| desrt | installing the nvidia binary driver gives me a really ugly plymouth | 00:32 |
| desrt | 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 | |
| desrt | the thing boots in the blink of an eye anyway | 00:32 |
| TheMuso | Sounds like vga16 wasn't ready in time for lucid... | 00:32 |
| desrt | RAOF: is there a way for me to get the text-mode one? | 00:32 |
| desrt | my bootup tends to be something like: | 00:33 |
| desrt | first 2 seconds: nothing | 00:33 |
| desrt | next 5 seconds: blinking cursor, sometimes an fsck message | 00:33 |
| desrt | next 1 second: some flicker or somthing | 00:33 |
| desrt | next 1 second: i see plymouth | 00:33 |
| desrt | then: X is loaded, login screen | 00:34 |
| desrt | i'd much rather look at 2 seconds of nothing followed by 7 seconds of some pretty text-based thing followed by X :) | 00:34 |
| RAOF | I thought the 5 seconds should have a plymouth screen on them. | 00:35 |
| * desrt reboots, takes careful notes | 00:36 | |
| RAOF | There's a plymouth-set-theme or something to switch between themes; you could swith to text there. | 00:36 |
| desrt | ok. my numbers are pretty much correct | 00:52 |
| desrt | the splash is up for ~1sec | 00:53 |
| rickspencer3 | desrt, I think that plymouth is actually not working on computers with hard drives (as apposed to SD drivers) atm | 00:53 |
| rickspencer3 | that may have been fixed though | 00:53 |
| desrt | SD drivers? | 00:53 |
| rickspencer3 | I mean sd drives, sorry | 00:53 |
| desrt | well, this has an ssd | 00:54 |
| rickspencer3 | oh | 00:54 |
| rickspencer3 | then it should be working in any case | 00:54 |
| desrt | it's an sata ssd, if that makes a difference | 00:54 |
| rickspencer3 | desrt, there is something wrong | 00:54 |
| desrt | meh. i don't lose too much sleep over it | 00:54 |
| rickspencer3 | like the fsck message should be handled by plymouth and such | 00:54 |
| desrt | 5 seconds of looking at a blinking cursor instead of a pretty screen isn't high on my worries list :) | 00:55 |
| rickspencer3 | especially since it looks like your boot is like 10 seconds ;) | 00:55 |
| desrt | more or less | 00:55 |
| desrt | my girlfriend took a video of the boot and she's uploading it to youtube now | 00:55 |
| rickspencer3 | still, some users will be bothered by the boot not being "pretty" | 00:55 |
| desrt | it's taking a while because the file is big, but i'll share the link when it's done | 00:56 |
| rickspencer3 | kewl | 00:56 |
| === bjf is now known as bjf-afk | ||
| desrt | RAOF: http://www.youtube.com/watch?v=jX9L1VPjgEA | 01:17 |
| desrt | that's what i get | 01:18 |
| RAOF | 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:24 |
| desrt | so i ask again: why bother? | 01:25 |
| desrt | if the soonest that plymouth can start up is about 1 second before X starts.... | 01:26 |
| RAOF | 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:28 |
| desrt | ah | 01:30 |
| === bjf is now known as bjf-afk | ||
| desrt | let me see about marking my drives for mandatory fscking on next boot | 01:31 |
| TheMuso | desrt: afaik thats not possible any more with upstart... | 01:51 |
| LaserJock | arrrg, what happened to pinned tabs in Chromium?! :( | 02:32 |
| kenvandine | hey rickspencer3 | 03:37 |
| rickspencer3 | hi kenvandine | 03:38 |
| LaserJock | hey, my two favorite guys | 03:45 |
| LaserJock | so ..... any word on gwibber? :-) | 03:45 |
| kenvandine | not yet... | 03:45 |
| kenvandine | called in the big guns... Nafai is going to try to crack it :) | 03:45 |
| LaserJock | is it looking like the fix will have to be deep? | 03:46 |
| kenvandine | it looks like python multiprocessing just doesn't like gobject threads | 03:46 |
| LaserJock | mhm | 03:46 |
| kenvandine | it might require a pretty significant refactoring in gwibber in order to use the keyring | 03:46 |
| kenvandine | unless Nafai can figure out a way to make it work :) | 03:47 |
| rickspencer3 | well, yeah, I figured as such | 03:48 |
| rickspencer3 | kenvandine, are there tests for Gwibberg? | 03:48 |
| rickspencer3 | Gwibber, even? | 03:48 |
| rickspencer3 | Gwibberg is another project i am working on | 03:48 |
| kenvandine | hehe | 03:48 |
| LaserJock | hmm | 03:49 |
| rickspencer3 | kenvandine, perhaps we could spend one day writing tests | 03:49 |
| * LaserJock imagines rickspencer3 toiling away in a secret basement lab | 03:49 | |
| rickspencer3 | then refactor the code starting the next day? | 03:49 |
| kenvandine | rickspencer3, i have a good test case already | 03:49 |
| rickspencer3 | kenvandine, test cases for gwibber? | 03:50 |
| kenvandine | no... but for this problem | 03:50 |
| rickspencer3 | right | 03:50 |
| kenvandine | outside of gwibber | 03:50 |
| kenvandine | we need a test suite though | 03:50 |
| LaserJock | but you need to make sure you don't introduce regressions | 03:50 |
| kenvandine | one of the things i want to work on :) | 03:50 |
| rickspencer3 | right | 03:50 |
| rickspencer3 | so what I am suggesting is this | 03:50 |
| kenvandine | we can't write a test suite in the next couple days :) | 03:50 |
| rickspencer3 | 1. tomorrow is dedicated to writing a test suite | 03:50 |
| * kenvandine is on vacation tomorrow :) | 03:50 | |
| rickspencer3 | 2. next day we start refactoring | 03:50 |
| rickspencer3 | ok, then move it up to Thursday | 03:51 |
| kenvandine | :) | 03:51 |
| rickspencer3 | we really only need to untangle the key ring part, | 03:51 |
| rickspencer3 | so we can focus writing tests in that area | 03:51 |
| rickspencer3 | I don't foresee an easy fix | 03:51 |
| rickspencer3 | we still have 9 days to move this forward, which should be enough for this problem | 03:52 |
| kenvandine | actually that is the least of my worries :) | 03:52 |
| rickspencer3 | what else are you worried about? | 03:52 |
| kenvandine | it is easy to see if the keyring is a problem with the refactor | 03:52 |
| kenvandine | it is all the "operations" | 03:52 |
| kenvandine | ryan writes very compact code :) | 03:52 |
| kenvandine | so he has this constructor that creates a number of different types of operations | 03:53 |
| kenvandine | and they get wrapped up and thrown at map_async to run them | 03:53 |
| rickspencer3 | hmmm | 03:53 |
| kenvandine | i am just worried about the potential breakage we could hit move that out of map_async | 03:53 |
| Pupuser402 | hello, | 03:54 |
| rickspencer3 | kenvandine, what is map_async exactly? | 03:54 |
| Pupuser402 | I've been having problem sending to the desktop mail list | 03:54 |
| kenvandine | from multiprocessing.Pool | 03:54 |
| Pupuser402 | I've contacted the owner but nothing changed | 03:54 |
| Pupuser402 | any one can help? | 03:54 |
| kenvandine | rickspencer3, it runs a method in a pool of processes and handles calling the defined callbacks for success, failures... timeout, etc | 03:55 |
| rickspencer3 | kenvandine, is it ryan's code? | 03:55 |
| kenvandine | rickspencer3, do you own that list? | 03:55 |
| rickspencer3 | or part of a library | 03:55 |
| kenvandine | rickspencer3, yes | 03:55 |
| rickspencer3 | kenvandine, no | 03:55 |
| rickspencer3 | kenvandine, it's ryan's code? | 03:55 |
| kenvandine | all ryan's | 03:55 |
| kenvandine | and it is kind of ugly | 03:55 |
| rickspencer3 | an every operation goes through there? | 03:55 |
| kenvandine | yes | 03:55 |
| kenvandine | however... it is possible that the nature of this will make the refactoring easy... assuming we understand what it is doing :) | 03:56 |
| kenvandine | easy as in # of lines to change | 03:56 |
| kenvandine | but my fear is all the corner cases | 03:56 |
| rickspencer3 | kenvandine, is multiprocessing a python library? | 03:57 |
| kenvandine | 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 |
| kenvandine | yes | 03:57 |
| kenvandine | it handles dispatching operations into separate processes that share some data | 03:58 |
| rickspencer3 | so it all gets channeled through line 339 of dispather.py | 03:58 |
| kenvandine | yes | 03:58 |
| rickspencer3 | so we either find the magic "make it work" flag | 03:59 |
| kenvandine | pool.map_async(self.func, self.iterable, callback=self.callback).get(self.timeout) | 03:59 |
| kenvandine | that runs every operation | 03:59 |
| rickspencer3 | or we change map_async.run() to use some other threading mechanism | 03:59 |
| rickspencer3 | basically write our own map_async() | 04:00 |
| kenvandine | yeah, gut the MapAsync class and make it run them a new way | 04:00 |
| rickspencer3 | jeezum | 04:01 |
| rickspencer3 | this is almost exactly like my asynch_task_progressbox class | 04:02 |
| kenvandine | humm | 04:02 |
| kenvandine | pastebin? | 04:02 |
| rickspencer3 | what does iterable do? | 04:02 |
| kenvandine | that is operations | 04:02 |
| kenvandine | a list of operations | 04:02 |
| rickspencer3 | kenvandine, you can look at quickly.widgets.asynch_task_progressbox.py | 04:02 |
| rickspencer3 | it just uses python threads | 04:03 |
| rickspencer3 | so it | 04:03 |
| rickspencer3 | s week | 04:03 |
| rickspencer3 | kenvandine, would this work at all with threads? | 04:04 |
| kenvandine | i think so | 04:04 |
| rickspencer3 | obviously it would lack the ability to use mutliple processors and such | 04:05 |
| rickspencer3 | kenvandine, what does iterable do? | 04:05 |
| kenvandine | it is a list of things to do | 04:06 |
| kenvandine | so in this case it is a nested list i think | 04:06 |
| rickspencer3 | I see | 04:07 |
| rickspencer3 | like a list of functions to call? | 04:07 |
| kenvandine | no :) | 04:07 |
| kenvandine | they all call perform_operation | 04:07 |
| kenvandine | but look at the args to perform_operation | 04:07 |
| kenvandine | the args to that method is a single item in iterable | 04:08 |
| rickspencer3 | so it's useless | 04:08 |
| kenvandine | def perform_operation((acctid, opname, args, transient)): | 04:08 |
| kenvandine | (acctid, opname, args, transient) | 04:08 |
| kenvandine | that is a single item in a list | 04:08 |
| kenvandine | so it calls perform_operation a bunch of times in parallel with a different operation for each | 04:09 |
| kenvandine | like twitter:receive, twitter:replies, twitter:private_messages | 04:09 |
| kenvandine | etc | 04:09 |
| kenvandine | if you post a status update | 04:09 |
| kenvandine | it creates a list of operations that include send for each service you have send_enabled for | 04:10 |
| kenvandine | and calls them all in parallel | 04:10 |
| kenvandine | this is also why it is so hard for us to know if a single operation fails or not | 04:10 |
| kenvandine | i actually really hate this code | 04:11 |
| kenvandine | if there are problems it is quite hard to really get in and figure it out to debug | 04:11 |
| kenvandine | however... i have never actually found a bug in this code path... but have looked there many times | 04:11 |
| rickspencer3 | yes, it's hard to read | 04:14 |
| rickspencer3 | and it may not be buggy per se | 04:14 |
| kenvandine | rickspencer3, it is a pain though | 04:15 |
| rickspencer3 | yes indeed | 04:16 |
| kenvandine | i don't think we should touch perform_operation though | 04:16 |
| kenvandine | but perhaps the pool stuff that calls it | 04:16 |
| kenvandine | rickspencer3, i am still hoping the awesome Nafai comes through... it is nice to use the library to do it :) | 04:18 |
| rickspencer3 | seems that perform_operation could be put on a thread manually | 04:18 |
| rickspencer3 | kenvandine, would gwibber break if each operation was done in sequence instead of in parallel? | 04:19 |
| kenvandine | shouldn't | 04:20 |
| rickspencer3 | jeezum | 04:21 |
| rickspencer3 | MapAsync is itself a thread | 04:21 |
| rickspencer3 | which then spawns all these processes | 04:21 |
| kenvandine | i don't know if there is a specific reason he chose it | 04:22 |
| rickspencer3 | dude, what if we just set processes to 1? | 04:22 |
| kenvandine | i tried | 04:23 |
| kenvandine | doesn't work | 04:23 |
| kenvandine | i also tried chunksize 1 | 04:23 |
| rickspencer3 | dang it | 04:23 |
| rickspencer3 | no easy answers | 04:23 |
| kenvandine | yeah... tell me about it | 04:24 |
| rickspencer3 | wouldn't chunksize kinda be 1 by default? | 04:24 |
| kenvandine | i think so, but that isn't clear | 04:24 |
| kenvandine | learning a little more about this pool stuff has been intersting | 04:24 |
| kenvandine | it is cool stuff | 04:24 |
| rickspencer3 | yeah | 04:26 |
| rickspencer3 | but when you write threaded code, it has to be tight and readable :/ | 04:26 |
| RAOF | And preferably not actually threaded :) | 04:26 |
| RAOF | (I've played with twisted before, and the Deferred stuff is nice) | 04:27 |
| rickspencer3 | yeah | 04:27 |
| rickspencer3 | kenvandine, calling pool like this seems to be working for now: | 04:28 |
| rickspencer3 | pool = multiprocessing.Pool(1) | 04:28 |
| rickspencer3 | maybe it's just luck though | 04:28 |
| rickspencer3 | yeah, looks like it was just luck, when I told gwibber to refresh it pegged again | 04:29 |
| kenvandine | rickspencer3, it takes 2 or 3 refreshes to see it | 04:31 |
| rickspencer3 | yeah | 04:31 |
| kenvandine | which i find weird | 04:31 |
| rickspencer3 | well, it pretty reliable pegs on the first try for me | 04:31 |
| kenvandine | http://pastebin.ubuntu.com/410145/ | 04:32 |
| kenvandine | that is a good script to play with for trying to make the pool stuff work | 04:33 |
| rickspencer3 | so ken, you think the best approach is to try to make the call to the keyring work in the existing model | 04:33 |
| rickspencer3 | rather than try to refactor the code? | 04:33 |
| kenvandine | yes | 04:34 |
| kenvandine | if it can work... | 04:34 |
| kenvandine | although i was ready to give up yesterday :) | 04:34 |
| rickspencer3 | you need a day off | 04:34 |
| kenvandine | i do | 04:35 |
| kenvandine | :) | 04:35 |
| rickspencer3 | I'll put Nafai on this full time starting tomorrow | 04:35 |
| kenvandine | great | 04:35 |
| rickspencer3 | RAOF, what are you working on? | 04:35 |
| RAOF | X bugs, and lentil soup. | 04:35 |
| RAOF | Particularly: making it so that lucid will boot on recent macbook pros. | 04:36 |
| rickspencer3 | mmm | 04:36 |
| rickspencer3 | that sounds important too :) | 04:36 |
| RAOF | A bit of python hacking sounds fun, though. | 04:37 |
| kenvandine | ha... this isn't the fun kind :) | 04:37 |
| rickspencer3 | RAOF, yeah, so this is a pretty tough nut | 04:39 |
| RAOF | I'm always suspicious of python without unittests :). | 04:39 |
| rickspencer3 | basically, if you can make that script that ken pasted in work | 04:40 |
| rickspencer3 | without pegging the CPU, obviously | 04:40 |
| kenvandine | i really need to resurrect those tests | 04:41 |
| kenvandine | and create mock stuff for all the services | 04:42 |
| rickspencer3 | can gwibber just get all of the passwords it needs and store them in memory | 04:42 |
| rickspencer3 | and then replace the call to the king ring to a call to a new function that just reads from a dict? | 04:43 |
| kenvandine | potentially, i looked at that | 04:43 |
| kenvandine | then we need to add the credentials to the operation | 04:43 |
| kenvandine | it is nearly as much code to change as refactoring out the pool code | 04:44 |
| rickspencer3 | really? | 04:44 |
| kenvandine | and... we would need a way to change that password if the user does | 04:44 |
| rickspencer3 | we can't just write a module | 04:44 |
| kenvandine | yeah, cause some services use a secret_key, some password, etc | 04:44 |
| rickspencer3 | an replace a call to that module where the call to the key ring occurs? | 04:45 |
| kenvandine | right | 04:45 |
| kenvandine | oh, that doesn't work :/ | 04:45 |
| kenvandine | cause it gets called from that thread | 04:45 |
| kenvandine | i did that | 04:45 |
| RAOF | Or just monkey-patch gnomekeyring to take a lock before all the operations? | 04:45 |
| kenvandine | same thing happens | 04:45 |
| rickspencer3 | kenvandine, I mean, write a module that gets all the credentials at startup out of the keyring | 04:46 |
| kenvandine | RAOF, i tried that | 04:46 |
| rickspencer3 | and stores those in a hash | 04:46 |
| kenvandine | rickspencer3, oh.. yeah... humm | 04:46 |
| rickspencer3 | and then just make that hash globably accessible | 04:46 |
| kenvandine | we need a way to update it if the password changes | 04:47 |
| RAOF | I'm actually a bit surprised that works at all; libgnome-keyring is pretty aggressively thread-unsafe in my experience. | 04:47 |
| rickspencer3 | RAOF, it doesn't work at all | 04:47 |
| kenvandine | RAOF, exactly | 04:47 |
| kenvandine | it threadlocks | 04:47 |
| rickspencer3 | hmm | 04:48 |
| rickspencer3 | if the password changes | 04:48 |
| kenvandine | although, this example works fine | 04:48 |
| RAOF | Perhaps I should rephrase. “I'm surprised it doesn't assert() out immediately” | 04:48 |
| rickspencer3 | kenvandine, is there a way to make the password change other than with the gui? | 04:48 |
| kenvandine | http://pastebin.ubuntu.com/408313/ | 04:48 |
| kenvandine | no | 04:48 |
| kenvandine | so we could make it call a method | 04:49 |
| rickspencer3 | so the gui could update the hash | 04:49 |
| rickspencer3 | so we'd add to the startup time the time it takes to read all the passwords from the key ring | 04:49 |
| rickspencer3 | but that should be minimal | 04:49 |
| kenvandine | it is fast | 04:49 |
| rickspencer3 | and then we just have the passwords hanging around in memory | 04:50 |
| rickspencer3 | and I guess put a semiphore around it when anyone tries to read or write it | 04:50 |
| rickspencer3 | kenvandine, would it be worth it to send Nafai exploring down this path tomorrow? | 04:51 |
| kenvandine | maybe, let him try to fix it first | 04:51 |
| rickspencer3 | ok | 04:51 |
| rickspencer3 | kenvandine, please don't let me catch you online tomorrow! | 04:52 |
| kenvandine | :) | 04:52 |
| kenvandine | i shouldn't be | 04:52 |
| rickspencer3 | I think a break will help you be more productive | 04:52 |
| kenvandine | i am going to see tigers with the kids | 04:52 |
| rickspencer3 | just, for the love of god, stay away form gwibber | 04:52 |
| rickspencer3 | for one day | 04:52 |
| rickspencer3 | that should be good | 04:52 |
| rickspencer3 | will help your mind reset priorities ;) | 04:52 |
| rickspencer3 | kenvandine, but you want Nafai to try making the call to the keyring work in some way | 04:53 |
| RAOF | It looks like maybe seahorse triggers a similar bug? | 04:53 |
| rickspencer3 | some magic flag | 04:53 |
| kenvandine | RAOF, oh? | 04:53 |
| rickspencer3 | and if that doesn't work, we'll work around it | 04:53 |
| kenvandine | rickspencer3, right | 04:53 |
| kenvandine | i think the pool stuff is generally useful, and it would be sad if we can't limit the amount of context it shares | 04:54 |
| RAOF | Open up a keyring, and inspect any of the keys contained therein. Seahorse will consume 100% of a core until you stop looking at that key. | 04:54 |
| rickspencer3 | kenvandine, if the keyring is not threadsafe, it's not threadsafe | 04:55 |
| kenvandine | yeah | 04:55 |
| rickspencer3 | that fundamental problem is out of scope for Lucid of course | 04:55 |
| kenvandine | RAOF, wow... your right | 04:55 |
| rickspencer3 | it's kinda nutty really | 04:55 |
| rickspencer3 | hmm | 04:55 |
| rickspencer3 | so there are probably a ton of little bugs like this scattered around the desktop | 04:56 |
| rickspencer3 | gotta run | 04:58 |
| rickspencer3 | kenvandine, http://imgur.com/W8nt8 | 05:00 |
| rickspencer3 | :) | 05:00 |
| rickspencer3 | bye bye | 05:00 |
| kenvandine | hit and run from rick | 05:00 |
| kenvandine | :) | 05:00 |
| TheMuso | crimsun: the ideapad U150 and U350 use the same SSID, hense whyusers have a working headphone jack switch. | 06:26 |
| pitti | Good morning | 07:00 |
| RAOF | Good morning pitti | 07:01 |
| pitti | rickspencer3: turn off autosync> we don't start gwibber by default, so I don't think it's a beta-2 issue | 07:01 |
| pitti | hey RAOF, how are you today? | 07:02 |
| kenvandine | pitti, if you have accounts configured, we do | 07:02 |
| kenvandine | and good morning :) | 07:02 |
| pitti | hello kenvandine | 07:02 |
| pitti | kenvandine: yes, but you don't have accounts in a fresh install | 07:02 |
| kenvandine | yup | 07:02 |
| pitti | and for upgrades we can just as well fix it right after beta-2 release | 07:02 |
| kenvandine | and one way or another we will have a fix for it ready right after beta-2 :)_ | 07:02 |
| pitti | 'zactly | 07:03 |
| crimsun | TheMuso: yes, hence why I suggested looking at codec SSID (not PCI SSID) -- with the caveat that I don't know the codec SSID for the original hw that merged the ideapad model & quirk | 07:05 |
| RAOF | pitti: I'm good. Went to see Micmacs last night, which was fun, and I'm very nearly in sync with non-daylight-savings now :) | 07:06 |
| pitti | Micmacs? | 07:06 |
| pitti | a movie? | 07:06 |
| pitti | micro machines? | 07:06 |
| RAOF | A movie :) | 07:06 |
| RAOF | http://www.imdb.com/title/tt1149361/ | 07:06 |
| TheMuso | crimsun: oh right, gotcha now. | 07:06 |
| RAOF | Although micro machines could also be cool! | 07:08 |
| TheMuso | crimsun: Ah I still have an alsa-info dump from having access to the U350 back in Feb, so have the Codec subsystem ID. I guess that helps some. | 07:09 |
| didrocks | good morning | 08:13 |
| seb128 | hello there | 08:28 |
| * pitti waves to the French mafia | 08:28 | |
| didrocks | hey seb128, pitti | 08:31 |
| seb128 | lut didrocks, pitti | 08:31 |
| didrocks | seb128: no, it wasn't so late, it was just late for en "early evening" :) | 08:31 |
| didrocks | that said, how are you guys? | 08:31 |
| pitti | I'm great, thanks! | 08:32 |
| pitti | you too? | 08:32 |
| seb128 | I'm great too | 08:32 |
| didrocks | yeah, my legs are better. I can almost walk normally but won't run :) | 08:32 |
| seb128 | lol | 08:32 |
| seb128 | see, sport is good for you | 08:33 |
| seb128 | you wouldn't have all those troubles after some exercice if you were doing regular sport :p | 08:33 |
| didrocks | seb128: oh, I'm sure it is. It's just more than 15 hours of steps in 2 days isn't for me :) | 08:33 |
| robert_ancell | seb128, hey, am I able to take git patches for gcalctool and apply them to the Lucid version? (i.e. is that considered a stable update exempt from a freeze break?) | 08:52 |
| seb128 | hey robert_ancell, yes | 08:53 |
| seb128 | robert_ancell, I was just thinking about you | 08:54 |
| seb128 | I didn't notice you were still online | 08:54 |
| seb128 | robert_ancell, not sure what was the logic behind dropping base conversion from gcalctool but that was not a nice move for users | 08:54 |
| seb128 | I keep getting complain about it | 08:54 |
| seb128 | it's annoying me too :p | 08:54 |
| seb128 | I've to find an another calculator to use now | 08:55 |
| didrocks | seb128: how come you use base conversion? | 08:55 |
| * seb128 slaps didrocks | 08:55 | |
| didrocks | ouch :) | 08:55 |
| robert_ancell | seb128, yeah, I'm not going to hear the end of this one... we can, revert to the older gcalctool for Lucid, you can use the PPA I made for Karmic, you can install the package manually from Karmic, or use another calculator (recommended qalculate, speedcrunch, galculator) | 08:56 |
| seb128 | robert_ancell, I think we will not change anything now | 08:56 |
| robert_ancell | the good news is I spent easter doing the work I wanted to do this cycle and gcalctool master is now awesome | 08:56 |
| seb128 | it's just a shame to rewrite an useful tool to make it useless | 08:56 |
| seb128 | ok, there is some trolling there ;-) | 08:56 |
| robert_ancell | it's one feature... | 08:57 |
| seb128 | but that's one of the things I use in a scientific calculator | 08:57 |
| seb128 | and gcalctool used to work great | 08:57 |
| robert_ancell | the old version still exists | 08:57 |
| seb128 | well, one feature that lot of scientific people need | 08:57 |
| robert_ancell | programmers | 08:57 |
| seb128 | right, programmers on computers, electronic, students | 08:58 |
| robert_ancell | I would argue scientific people would more like the new features like polynomials | 08:58 |
| === almaisan-away is now known as al-maisan | ||
| seb128 | let's be honest, people will judge on what is installed by default and laugh to us if we told them to get the old version from a ppa | 08:59 |
| seb128 | anyway just being curious but what was the rational behind dropping those options from gcalctool? | 08:59 |
| seb128 | so I know what to reply to hate emails I get | 08:59 |
| seb128 | we should also probably change the package maintainer info | 09:00 |
| seb128 | so you do get those users emails :p | 09:00 |
| robert_ancell | sure, it's a shit release in a lot of respects. Not sure what I should have done in hindsight, as i didn't get enough time to finish the features. Perhaps we should have stuck with the older one from a distros perspective. | 09:00 |
| seb128 | yeah, we had an UDS session about things we wanted to stay away from this cycle | 09:00 |
| seb128 | ie rewrites etc | 09:00 |
| seb128 | gcalctool should maybe have been on the list | 09:01 |
| robert_ancell | there were big internal changes that meant the old methods didn't work. The changes will make the next version awesome, I didn't get time to reimplement the base functionality as I wanted | 09:01 |
| robert_ancell | sure | 09:01 |
| seb128 | though it's only a calculator, not end of the world | 09:01 |
| seb128 | anyway | 09:01 |
| robert_ancell | well, I'd support rolling it back if people thought that was appropriate | 09:01 |
| seb128 | not sure if you saw my reply before but backporting git changes if those are bug fixes is fine | 09:01 |
| seb128 | I keep doing that | 09:01 |
| seb128 | since our schedule will be tight and we will not get GNOME 2.30.1 I think this cycle | 09:02 |
| seb128 | or in SRU updates after lucid | 09:02 |
| robert_ancell | ok, I have to go, one more question. I want to release simple-scan 1.0 (a few minor bugfixes). Should I do that now or wait until after B2 (I've been looking out for serious bugs, there don't seem to be any in the last release) | 09:02 |
| seb128 | as you want | 09:02 |
| seb128 | it will be queue until after beta2 | 09:02 |
| seb128 | so upload at any time between now and freeze next week | 09:02 |
| robert_ancell | seb128, ok, will wait until after B2 in case someone notices something | 09:02 |
| seb128 | seems good | 09:03 |
| seb128 | rolling back gcalctool, I don't know | 09:03 |
| seb128 | I don't think it's required, but I don't use it a lot | 09:03 |
| seb128 | I started it a week ago or so to do an hex to dec conversion | 09:03 |
| robert_ancell | I think it would be a good idea as this is a LTS. | 09:03 |
| robert_ancell | my 2c | 09:03 |
| seb128 | which failed because I didn't find how to do it with the new version | 09:03 |
| seb128 | rolling back? | 09:03 |
| robert_ancell | yes | 09:03 |
| seb128 | ok, I will discuss it with other people and let you know | 09:04 |
| seb128 | enjoy your evening! | 09:04 |
| seb128 | pitti, ^ | 09:04 |
| robert_ancell | there are enough people complaining (they often miss other major problems in the past, it's only this feature they've noticed!!) | 09:04 |
| robert_ancell | bye | 09:04 |
| pitti | seb128: rolling back gcalctool? no strong opinion either way, it's a "leaf" package and thus rolling it back doesn't break anything else | 09:05 |
| seb128 | pitti, ok | 09:05 |
| pitti | the karmic one was fine | 09:05 |
| seb128 | robert_ancell as an upstream seems to be in favor of rolling back | 09:06 |
| pitti | and yes, I'm missing dec<->hex<->oct conversion, too, but by now I got used to just using python for that | 09:06 |
| seb128 | I will play with both today | 09:06 |
| cassidy | seb128, https://bugs.edge.launchpad.net/ubuntu/+source/empathy/+bug/556977 has been linked on a bug report but I don't have rights to see it. Can you make it public please? | 09:12 |
| ubottu | Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/556977) | 09:12 |
| seb128 | I don't have right to see it either | 09:12 |
| seb128 | is that a crash which has not been retraced yet? | 09:12 |
| cassidy | maybe, it's a crash according the upstream report | 09:14 |
| seb128 | *shrug* | 09:42 |
| seb128 | i386 retracing backlog is 630 bugs now | 09:42 |
| * pitti wishes LP would be a bit more stable these days | 09:42 | |
| seb128 | cassidy, it might take a while before getting this one retraced | 09:42 |
| cassidy | seb128, that's a fine, I think I got the reason of the crash | 09:43 |
| seb128 | cool | 09:43 |
| seb128 | pitti, we should probably turn apport off by default now if we didn't yet | 09:45 |
| pitti | seb128: hm, we usually do after RC, but we can also do it earlier | 09:45 |
| seb128 | well I'm just not sure how useful it is | 09:46 |
| seb128 | we have a backlog of over 800 crashes not retraced | 09:46 |
| seb128 | new one will probably show up after lucid as "can't be retraced due to outdated versions" now | 09:46 |
| mvo | dpm: I need to update some string in update-manager to fix 10.04 -> 10.04 LTS | 09:54 |
| mvo | dpm: now I wanted to just to that manually (update, unfuzzy) | 09:54 |
| mvo | dpm: but for some odd reason I get additional fuzzy strings from a fresh launchpad export | 09:55 |
| mvo | dpm: when running intltool-update -g update-manager -p and intltool-update -d -g update-manager | 09:55 |
| mvo | dpm: any hints? is there a know issue here? | 09:55 |
| dpm | hi mvo, sorry, I got disconnected. The last thing I got was: "dpm: when running intltool-update -g update-manager -p and intltool-update -d -g update-manager" | 10:03 |
| dpm | mvo, what's the branch you are testing? And what's the link to the LP export? I can try myself I can see what could be wrong | 10:04 |
| dpm | _if I can see_, I meant | 10:05 |
| mvo | dpm: cool, thanks. I use "lp:update-manager" and the export from the lucid source package | 10:05 |
| mvo | dpm: https://translations.edge.launchpad.net/ubuntu/lucid/+source/update-manager | 10:06 |
| dpm | mvo, yeah, but when you requested the export of the translations, you got a link to the tarball. Could you give me the link, so that I can use that and don't have to request a new export? | 10:08 |
| mvo | dpm: sure http://launchpadlibrarian.net/43330966/launchpad-export.tar.gz | 10:09 |
| dpm | mvo, cool, thanks. Let me see if I can see anything unusual | 10:09 |
| mvo | dpm: german may be a good example language, it should be 100% | 10:12 |
| chrisccoulson | hello everyone | 10:18 |
| seb128 | hey chris | 10:18 |
| seb128 | hey chrisccoulson | 10:18 |
| chrisccoulson | hey seb128, how are you? | 10:19 |
| seb128 | good! you? | 10:19 |
| chrisccoulson | yeah, not bad thanks | 10:20 |
| dpm | mvo, I've done the following: used lp:update-manager, downloading the translations tarball from the link you gave me, put the update-manager-de.po file (after renaming it to de.po) in the po folder, run 'intltool-update -g update-manager' and then 'intltool-update de'. I can only see 3 fuzzies, which are the ones in which you changed LTS -> http://pastebin.ubuntu.com/410485/ | 10:28 |
| dpm | which other fuzzies do you get? | 10:29 |
| seb128 | oh, robert_ancell is back | 10:29 |
| seb128 | robert_ancell, quick one for you too | 10:29 |
| robert_ancell | seb128, hey | 10:29 |
| seb128 | robert_ancell, did you see the bug about gnome-games lpi being broken? | 10:29 |
| robert_ancell | seb128, no | 10:30 |
| seb128 | robert_ancell, the changes need to be updated to reflect the binaries split you did | 10:30 |
| robert_ancell | seb128, oh, right. I can fix that | 10:30 |
| seb128 | cool, thanks | 10:31 |
| robert_ancell | bug #? | 10:31 |
| seb128 | I was not sure if you were reading the gnome-games bug emails or not | 10:31 |
| robert_ancell | seb128, I get so many email I miss a lot | 10:31 |
| robert_ancell | seb128, pitti, am planning to look at bug 532531 tommorrow. Been busy with oem stuff, but feel free to have a look if you guys have spare time (which I'm assuming you don't) | 10:32 |
| ubottu | Launchpad bug 532531 in gdm "No way to come back if fast user switcher is activated accidentally" [High,Confirmed] https://launchpad.net/bugs/532531 | 10:32 |
| seb128 | robert_ancell, not sure about the number now, it's on the most recent bugs in the buglist | 10:32 |
| seb128 | robert_ancell, ok good | 10:32 |
| robert_ancell | seb128, pitti, I see you're both fine with a gcalctool rollback - what version number do I give it to make it work in Lucid? | 10:33 |
| seb128 | I don't like epochs | 10:33 |
| seb128 | I would say current.lucid.is.real.version | 10:33 |
| seb128 | ie 2.29.is.2.28 | 10:34 |
| seb128 | or whatever the versions are | 10:34 |
| robert_ancell | (I think on the balance it is worth rolling back as the new version will annoy some users+help others whereas keeping the old one will be a neutral change) | 10:34 |
| seb128 | I think we didn't get too many complain about gcalctool in karmic | 10:35 |
| seb128 | so let's stay on this version for lucid | 10:35 |
| seb128 | and rock with the new code for next cycle | 10:35 |
| robert_ancell | seb128, yeah, I figured it would be like that but I wasn't sure of a good version number | 10:35 |
| seb128 | the new.is.old is what we used for similar cases recently | 10:35 |
| seb128 | not really nice but the other option is an epoch, ie 1:2.28 | 10:36 |
| robert_ancell | seb128, yeah I hope there aren't too many bugs in the karmic one as the codebase is very brittle. I finally got GObjects all through the new one - much nicer! | 10:36 |
| seb128 | which is nicer but means we can't sync on Debian again later | 10:36 |
| robert_ancell | epochs are only useful for permanent changes though - we will be in sync for Lucid+1 | 10:36 |
| seb128 | right | 10:37 |
| robert_ancell | ok, will upload it now | 10:37 |
| seb128 | thanks | 10:37 |
| mvo | dpm: thanks, I try it again, maybe before I did something (unreleated) wrong | 10:37 |
| * seb128 grrrs at pitti and bzr | 10:37 | |
| seb128 | nautilus bzr changed format and bzr pull doesn't work | 10:38 |
| robert_ancell | seb128, how is lucid going for you at the moment? | 10:38 |
| seb128 | robert_ancell, quite good, I think it will be a solid version | 10:38 |
| seb128 | I'm a bit concerned about the number of crash bugs we received recently | 10:38 |
| seb128 | but it might just be because the retracers were broken and are catching up | 10:38 |
| seb128 | so lot of crashers show up now | 10:38 |
| seb128 | there is still quite some bug fixing to do though | 10:39 |
| seb128 | robert_ancell, what do you think about it? | 10:39 |
| robert_ancell | seb128, I get some weird behaviour with some subsystem not working that stops the sound and power operations from working. Can't work out what it is, but guessing it's not widespread. I have some strange packages on my system though | 10:39 |
| seb128 | robert_ancell, when do you finish oem officially btw? | 10:39 |
| robert_ancell | seb128, I think it's at UDS? | 10:39 |
| seb128 | k | 10:39 |
| seb128 | what I though but I was not sure | 10:39 |
| pitti | seb128: bzr upgrade? | 10:39 |
| robert_ancell | I need to check too | 10:40 |
| seb128 | pitti, dunno, it said something about doing that for me but failed at it | 10:40 |
| seb128 | I rm -r ubuntu and bzr get it again now | 10:40 |
| pitti | strange | 10:40 |
| seb128 | those format changes are so annoying | 10:40 |
| seb128 | it's ridiculous | 10:40 |
| seb128 | "This may take some time. Upgrade the repositories to the same format for better performance. | 10:40 |
| seb128 | bzr: ERROR: KnitPackRepository('file:///home/seb128/boulot/package/nautilus/ubuntu/.bzr/repository/') | 10:40 |
| seb128 | is not compatible with" | 10:40 |
| seb128 | pitti, ^ that's the error I got | 10:41 |
| seb128 | "Doing on-the-fly conversion from RemoteRepositoryFormat(_network_name='Bazaar repository format 2a (needs bzr 1.16 or later)\n') to RepositoryFormatKnitPack1()." | 10:41 |
| robert_ancell | seb128, yeah they annoy me too! | 10:41 |
| didrocks | yeah, I don't get as well why it's upgrading and downgrading all the time for me as well :/ | 10:41 |
| didrocks | hey robert_ancell :) | 10:41 |
| robert_ancell | didrocks, hey! | 10:41 |
| dpm | mvo, ok, just let me know if I can help in any way | 10:42 |
| robert_ancell | seb128, does it not upgrade from the LP page? | 10:42 |
| seb128 | robert_ancell, I did rm the dir and got a new checkout | 10:42 |
| seb128 | it's working now | 10:42 |
| seb128 | seems pitti did change the format in some way when he touched it | 10:43 |
| mvo | dpm: many thanks, I re-run the full update, unfuzzy again and see how it goes | 10:43 |
| seb128 | and bzr pull didn't manage to deal with it | 10:43 |
| seb128 | a new checkout is working though | 10:43 |
| seb128 | go wonder | 10:43 |
| dpm | ok | 10:43 |
| mvo | dpm: there is no risk here, right? 9.10 -> 10.04 LTS should not be a problem in any langauge? | 10:43 |
| robert_ancell | seb128, and bzr upgrade didn't work from your system? | 10:43 |
| seb128 | it's usually faster to checkout again than to try to understand the issue | 10:43 |
| mvo | dpm: that the string does no longer make sense? | 10:43 |
| mvo | dpm: because there is a different prefix used for 9 than 10 or something? | 10:43 |
| seb128 | robert_ancell, bzr pull did "upgrading" and failed at it with a "ERROR: KnitPackRepository is not compatible with" | 10:44 |
| robert_ancell | seb128, as I understand it you need to upgrade at the server and the local copy. You upgrade the server side from LP and the client side by runing "bzr upgrade" | 10:44 |
| seb128 | next time I will try to run bzr upgrade manually | 10:44 |
| seb128 | bzr pull is supposed to do that for you which failed there | 10:45 |
| seb128 | but maybe bzr upgrade does something different and would have worked | 10:45 |
| seb128 | anyway issue solved with a new checkout | 10:45 |
| robert_ancell | I think bzr pull just tries to translate the formats on the fly (and doesn't always work perfectly), bzr upgrade does the change permanently | 10:45 |
| dpm | mvo, I can only think of people using different numbering systems, but I'd think translators tend to stick to the same translation as in English. Thus I'm not sure if it should be translatable. Perhaps it could be a variable in a next version of update-manager? I can ask translators to see if they translate the version string and see what they think | 10:46 |
| pitti | seb128: oh, you didn't run bzr upgrade? | 10:46 |
| seb128 | pitti, no, bzr pull said "upgradign" | 10:46 |
| pitti | seb128: bzr pull does not upgrade automatically; it claims to do in-place conversion, but that often fails | 10:47 |
| seb128 | which I though was "doing bzr upgrade for you" | 10:47 |
| mvo | dpm: good point, I will make it a var in the next release | 10:47 |
| pitti | it converts the individual commits to the other format | 10:47 |
| seb128 | I see | 10:47 |
| seb128 | good to know for next time | 10:47 |
| dpm | ok | 10:47 |
| dpm | mvo, another quick thing. While you are at it, perhaps you can manually correct this in de.po-> http://pastebin.ubuntu.com/410488/ It just needs the \r\n removed (the \r makes msgmerge complain) | 10:49 |
| mvo | dpm: sure, thanks | 10:51 |
| mvo | dpm: done | 10:53 |
| dpm | cool, thanks mvo! | 10:53 |
| chrisccoulson | hey pitti | 10:53 |
| pitti | hey chrisccoulson | 10:53 |
| chrisccoulson | would you mind doing another archive removal for me if you get the chance? | 10:53 |
| chrisccoulson | (bug 553686) | 10:53 |
| ubottu | Launchpad bug 553686 in kazehakase "Please remove kazehakase source and binaries from Lucid" [Wishlist,Triaged] https://launchpad.net/bugs/553686 | 10:53 |
| pitti | didrocks: hm, I just installed current UNE; I don't see plymouth during boot | 10:53 |
| didrocks | pitti: oh? let me try with today's image. I got it in my upgraded box | 10:54 |
| pitti | I have plymouth{,-x11,-theme-ubuntu-log,-theme-ubuntu-tex} installed | 10:54 |
| pitti | chrisccoulson: sure | 10:55 |
| chrisccoulson | pitti - thanks | 10:55 |
| chrisccoulson | pitti - we're turning off the "Report a bug" menu option in lpi aren't we? | 10:57 |
| pitti | chrisccoulson: right | 10:57 |
| chrisccoulson | i think we need to patch ubufox separately | 10:57 |
| pitti | didrocks: oh, got it -- /var/crash/_sbin_plymouthd.0.crash :) | 10:59 |
| * pitti -> more CD testing | 10:59 | |
| didrocks | oupsss, it's on the mini ? | 10:59 |
| huats | morning everyone | 11:00 |
| pitti | didrocks: yes | 11:02 |
| pitti | didrocks: and synaptics crept back into the "system tools" menu | 11:02 |
| pitti | seb128, mvo: ^ was that changed recently? or gnome-menus bug? | 11:02 |
| robert_ancell | later all! | 11:03 |
| seb128 | bye robert_ancell | 11:03 |
| pitti | bye robert_ancell | 11:03 |
| huats | gn robert_ancell | 11:03 |
| seb128 | pitti, I would say changed recently | 11:03 |
| seb128 | but I don't know | 11:04 |
| didrocks | pitti: same on the desktop, just noticed it | 11:04 |
| seb128 | it would be weird as a gnome-menus bug | 11:04 |
| robert_ancell | huats, later (you should probably take gcalctool off me - I keep breaking things :) ) | 11:04 |
| pitti | Categories=PackageManager;GTK;System;Settings; | 11:07 |
| pitti | ^ synaptic | 11:07 |
| pitti | that's pretty much what computer-janitor has as well | 11:08 |
| seb128 | weird | 11:09 |
| seb128 | it's the same in the cache? | 11:09 |
| pitti | seb128: yes | 11:09 |
| seb128 | k, so I don't know | 11:09 |
| seb128 | it's showing in system, admin there | 11:09 |
| seb128 | I didn't update for some days though | 11:09 |
| seb128 | but the category in the same | 11:09 |
| didrocks | nothing in changelog related to that… | 11:10 |
| pitti | seb128: what is the magic for this, actually? | 11:11 |
| seb128 | pitti, for what? | 11:11 |
| pitti | /etc/xdg/menus/applications.menu says "<Category>System</Category> and not <Category>Settings</Category> | 11:11 |
| pitti | i. e. it's not supposed to show this? | 11:11 |
| seb128 | right, it's supposed to be in system, admin | 11:12 |
| seb128 | it's correctly there with the same Categories on my box | 11:12 |
| seb128 | do you get the same bug without the cache? | 11:12 |
| seb128 | just to make sure it's not a cache thing | 11:12 |
| pitti | seb128: I'm just trying that :) | 11:12 |
| seb128 | or in gmenu-simple-editor | 11:12 |
| pitti | works without cache | 11:13 |
| didrocks | <Category>Utility</Category> contains <Not><Category>System</Category></Not> which is normal as well :) | 11:13 |
| seb128 | what is the synaptic entry in the cache? | 11:13 |
| didrocks | ok, side effect of the cache, how do you unactivate it pitti for testing? (just curious) | 11:13 |
| seb128 | can you pastebin it? | 11:13 |
| pitti | and rebuilding the cache/restart panel, it comes back | 11:14 |
| seb128 | didrocks, delete the cache? | 11:14 |
| didrocks | seb128: oh yes, it's true the cache isn't build at first loading | 11:14 |
| seb128 | didrocks, it's a trigger | 11:14 |
| seb128 | pitti, can you pastebin your cache for this entry? | 11:15 |
| pitti | http://paste.ubuntu.com/410499/ | 11:15 |
| seb128 | seems about right | 11:15 |
| seb128 | it's not listed twice? | 11:16 |
| pitti | seb128: ooh! | 11:16 |
| pitti | [synaptic-kde] | 11:16 |
| seb128 | ah | 11:16 |
| pitti | seb128: I think your recent change to add the "Hidden" entries to the cache also added the OnlyShowIn | 11:17 |
| seb128 | I did a typo | 11:17 |
| seb128 | it's fixed in unapproved | 11:17 |
| pitti | ah, great | 11:17 |
| seb128 | I added ShowOnlyIn | 11:17 |
| seb128 | instead of OnlyShowIn | 11:17 |
| seb128 | which explains why it works there | 11:17 |
| seb128 | I've the fixed version | 11:17 |
| didrocks | (I confirm, it's the synaptic-kde which is launched there) | 11:17 |
| * pitti hugs seb128 for retroactive bug fixing | 11:17 | |
| * seb128 hugs pitti & didrocks | 11:18 | |
| * didrocks hugs seb128 & pitti | 11:18 | |
| pitti | didrocks: btw, there are plenty of bug reports for that plymouth crash already | 11:18 |
| didrocks | pitti: ok, I'm still syncing the iso. I'll have a look if you think it's only UNE related | 11:19 |
| pitti | didrocks: no, I don't think so; but 553745 has plenty of dupes | 11:20 |
| pitti | bug 553745 | 11:20 |
| ubottu | Launchpad bug 553745 in plymouth "plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events()" [High,Confirmed] https://launchpad.net/bugs/553745 | 11:20 |
| didrocks | pitti: ok, in keybuck's hands so :) | 11:20 |
| didrocks | seb128: I have OnlyShowIn=KDE; in synaptic-kde.desktop | 11:21 |
| seb128 | didrocks, right, cf backlog | 11:21 |
| seb128 | didrocks, the cache didn't list the OnlyShowIn due to a typo | 11:22 |
| seb128 | it's fixed in the queue but didn't get accepted yet | 11:22 |
| didrocks | seb128: I don't have the typo version "ShowOnlyIn" but "OnlyShowIn" which is the right version, no? Or understand the contrary? (and I have the bug) | 11:23 |
| seb128 | didrocks, the typo is in the cache builder | 11:23 |
| seb128 | didrocks, the cache doesn't have the "OnlyShowIn" | 11:23 |
| seb128 | I listed "ShowOnlyIn" in the known keys to cache | 11:23 |
| seb128 | instead of "OnlyShowIn" | 11:23 |
| didrocks | seb128: oh ok, I thought you was talking about the synaptic-kde.desktop file containing the typo. understood :) | 11:23 |
| seb128 | so the cache just doesn't list any "OnlyShowIn" | 11:24 |
| didrocks | were* | 11:24 |
| pitti | ok, so my three grievances with CD testing are all bug-ified | 11:24 |
| didrocks | sure, I misunderstood where the typo was, hence my question :) | 11:24 |
| seb128 | it's all good! | 11:24 |
| mvo | seb128: aha, all good while I was at lunch? | 12:02 |
| seb128 | yes | 12:03 |
| mvo | cool | 12:05 |
| baptistemm | heh, launchpad under maintenance again | 12:05 |
| seb128 | james_w, hey | 12:12 |
| seb128 | baptistemm, no it's not? | 12:12 |
| james_w | hey seb128 | 12:12 |
| seb128 | james_w, did you see the update on the pitivi fix you sponsored? | 12:12 |
| seb128 | there is a new comment and commit | 12:12 |
| james_w | yeah | 12:12 |
| james_w | I rejected it from UNAPPROVED | 12:13 |
| james_w | I'll upload the fixed version today | 12:13 |
| baptistemm | seb128, hmmm, I had a message when I logged in, perhaps some caching issue | 12:13 |
| seb128 | james_w, ok good, thanks | 12:13 |
| james_w | sorry for not commenting, but I was just leaving | 12:14 |
| baptistemm | james_w, ah, I have also a fix; mine is for bluez :) | 12:14 |
| james_w | baptistemm: I saw | 12:15 |
| james_w | I'll get to it after lunch | 12:16 |
| baptistemm | no problemo, thanks a lot | 12:16 |
| seb128 | james_w, that's ok, I just noticed because they were discussing the bug on #pitivi | 12:17 |
| james_w | ah | 12:17 |
| james_w | ah they happy with the fix in that patch? | 12:17 |
| james_w | the documentation states you shouldn't use the function | 12:18 |
| seb128 | james_w, they are unsure about it, they are looking for people to test if that fixes the issue or not | 12:19 |
| === MacSlow is now known as MacSlow|lunch | ||
| chrisccoulson | pitti - is there a spec for disabling the "report a bug" menu items? | 12:48 |
| pitti | chrisccoulson: https://blueprints.launchpad.net/ubuntu/+spec/desktop-lucid-bug-management | 12:48 |
| chrisccoulson | pitti - thanks | 12:48 |
| mvo | dpm: I unfuzzied now all the language that looked safe, I guess I still need to send a mail to the translators list as e.g. fi.po I did not dare to touch | 12:54 |
| dpm | mvo, cool, thanks! Were there many languages which were not safe to unfuzzy? | 12:58 |
| mvo | dpm: very few | 12:58 |
| mvo | dpm: but some had postfixes like 10.04:en and I didn't feel like I can mug around with those (too dangerous) | 12:59 |
| * dpm nods | 12:59 | |
| edsiper | seb128, ping | 13:15 |
| seb128 | edsiper, pong | 13:18 |
| seb128 | (but on phone) | 13:18 |
| seb128 | edsiper, I'm back | 13:22 |
| edsiper | seb128, it was me (Eduardo Silva), i pinged you as i heard the girl in the line so i didn't knew if you were listening... | 13:26 |
| edsiper | :) | 13:26 |
| seb128 | oh ok | 13:26 |
| seb128 | I didn't hear the girl there, the line just went silent | 13:26 |
| seb128 | I guess they had some routing issue or something | 13:27 |
| === MacSlow|lunch is now known as MacSlow | ||
| edsiper | seb128, yeah, well it was fun, i thought that was another interviewer... | 13:27 |
| seb128 | pitti, http://cgit.freedesktop.org/media-player-info/commit/?id=8f2caea0c49e1b92f493230d717987aa7bf91096 | 13:47 |
| seb128 | pitti, might be worth getting in lucid, it could fix those bugs we get about sansa devices | 13:47 |
| seb128 | pitti, not sure if that would fix the "don't get mounted" though | 13:47 |
| pitti | seb128: I still have those in my mailbox, will look at them in the next days | 13:48 |
| seb128 | pitti, ok | 13:48 |
| pitti | I'm off for some 1.5 hours for an appointment | 13:48 |
| seb128 | pitti, see you | 13:48 |
| didrocks | see you pitti | 13:52 |
| hearthrob | hello all | 14:02 |
| hearthrob | nautilus fails with a segmentation fault when i try to use it as my user, but works with sudo | 14:07 |
| hearthrob | anyone have any ideas? | 14:08 |
| jpds | hearthrob: Sounds like a corrupt configuration file for your user. | 14:08 |
| jpds | hearthrob: Try: strace -e open -f nautilus | 14:08 |
| seb128 | didrocks, btw no need to look at the seahorse crashers, I found what the issue is | 14:59 |
| didrocks | seb128: yeah, I saw that in a comment from the bug report, sweet :) | 14:59 |
| rickspencer3 | seb128, pitti, Nafai, can we talk about gwibber in the next hour or so? | 15:01 |
| rickspencer3 | I dug into it quite a bit last night, I think we'll have to write some code to work around the issue | 15:01 |
| hearthrob | thanks jpds | 15:03 |
| hearthrob | it was trying to read a big file i guess... solved by deleting the file :) | 15:03 |
| james_w | seb128: pitivi is back in the queue, let me know if you want me to pull it again | 15:06 |
| seb128 | rickspencer3, hey, ok | 15:09 |
| seb128 | james_w, ok, thanks | 15:09 |
| rickspencer3 | ccheney, ping | 15:16 |
| === bjf-afk is now known as bjf | ||
| rickspencer3 | pitti, ? | 15:22 |
| seb128 | rickspencer3, he had to run for an appointment, he said he would be away 1.5 hours | 15:23 |
| rickspencer3 | ok | 15:23 |
| seb128 | rickspencer3, that was around 1.5 hours ago though so he should be back soon I guess | 15:23 |
| rickspencer3 | I think Nafai is not online yet | 15:23 |
| rickspencer3 | so maybe we can meet in this channel when everyone is back | 15:24 |
| seb128 | seems good | 15:24 |
| rickspencer3 | seb128, I see a way forward for gwibber, but there will be some work involved | 15:24 |
| seb128 | I'm around for the new 2 hours | 15:24 |
| rickspencer3 | I think Nafai can do it | 15:24 |
| rickspencer3 | seb128, sounds good | 15:24 |
| seb128 | next | 15:24 |
| seb128 | I guess pitti will be back before that and Nafai will be up too | 15:24 |
| rickspencer3 | btw, kenvandine is on vacation today | 15:24 |
| seb128 | ok | 15:24 |
| rickspencer3 | I told him *not* to get online ;) | 15:25 |
| seb128 | did you find what is wrong in gwibber? | 15:25 |
| rickspencer3 | yes, it's pretty obvious that the gnome key ring is not thread safe | 15:25 |
| seb128 | is that the multiprocessing sharing context issue chrisccoulson and others were mentioning yesterday? | 15:25 |
| rickspencer3 | anyone who calls it from a thread has issues | 15:25 |
| seb128 | right | 15:25 |
| SEJeff | If pitivi gets effects like this: http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/thibaultsaunier/t127060149183 would it be possible to have it as an update in Lucid? | 15:25 |
| seb128 | it's not only gnome-keyring | 15:25 |
| seb128 | seems using libdbus is an issue too | 15:25 |
| rickspencer3 | so, why, specifically that happens to the key ring, I don't know | 15:25 |
| rickspencer3 | could be | 15:26 |
| SEJeff | Since that will be such a common user request, it seems to make sense if pitivi upstream agrees | 15:26 |
| rickspencer3 | so I know where in the code the problem is | 15:26 |
| rickspencer3 | and I know the pieces that don't work | 15:26 |
| rickspencer3 | but the keyring is a blackbox to me | 15:26 |
| rickspencer3 | and I see how other people solved the problem, and we can take a similar approach | 15:26 |
| seb128 | ok | 15:26 |
| seb128 | maybe wait for pitti and Nafai for details | 15:26 |
| rickspencer3 | yeah | 15:26 |
| seb128 | so you don't have to explain twice | 15:26 |
| rickspencer3 | that was just my long winded answer to "do you know what the problem is?" ;) | 15:27 |
| seb128 | hehe | 15:27 |
| SEJeff | rickspencer3, Try sshing to > 50 boxes at once and watch the agent completely tank. Could it be due to seahorse storing the info in the keyring? | 15:27 |
| seb128 | SEJeff, seahorse has nothing to do with ssh | 15:27 |
| pitti | rickspencer3: hello | 15:28 |
| rickspencer3 | hiya pitti | 15:28 |
| SEJeff | seb128, Well the ssh-agent functionality of it was pulled into gnome-keyring since the previous 2 gnome releases | 15:28 |
| rickspencer3 | welcome back | 15:28 |
| SEJeff | And it is horribly busted | 15:28 |
| pitti | thanks | 15:28 |
| rickspencer3 | SEJeff, yes, I suspect that seahorse is quite impacted | 15:28 |
| seb128 | SEJeff, if you say so, I never got an issue with it | 15:28 |
| pitti | rickspencer3: took a little longer, still played around with bug 556253 | 15:28 |
| ubottu | Launchpad bug 556253 in xorg-server "[2.6.32-19 regression] Does not check lid status any more, external screen powered off" [Undecided,Confirmed] https://launchpad.net/bugs/556253 | 15:28 |
| rickspencer3 | I also hear that there are other issues with seahorse and CPU pegging | 15:29 |
| seb128 | but I know there is some open bugs from people ssh lot of boxes at the same time | 15:29 |
| seb128 | rickspencer3, this ssh DoS issue is there since jaunty or so | 15:29 |
| rickspencer3 | RAOF mentioned a bug to me last night about just viewing keys in seahorse pegs a CPU | 15:29 |
| seb128 | ie nothing to do with the rewrite this cycle | 15:29 |
| SEJeff | seb128, It is easy to reproduce. Download onall from here: https://code.ticketmaster.com/trac/browser/onall/trunk/onall | 15:30 |
| SEJeff | then just do onall -f hostlist.txt "uptime" with a list of hosts around 50 or more | 15:30 |
| seb128 | SEJeff, ok, so maybe somebody who has the issue could upstream it where people writting the code would read about it | 15:30 |
| seb128 | SEJeff, we have no gnome-keyring hacker around | 15:30 |
| SEJeff | After doing that a few times, it will kill the agent. ssh-agent from ssh works fine | 15:30 |
| SEJeff | fair enough | 15:30 |
| seb128 | SEJeff, I understand the concern but discuss it there will not really bring you anywhere closer to get that one worked | 15:31 |
| pitti | rickspencer3: is that really keyring itself, or dbus-glib? | 15:31 |
| SEJeff | seb128, and I understand. I've got one of those bugs open in fact and will upstream it later today | 15:31 |
| * pitti made really bad experiences with using python-dbus in threaded programs | 15:31 | |
| kklimonda | .b 9 | 15:31 |
| pitti | I discussed that with upstream even, and eventually gave up | 15:31 |
| rickspencer3 | pitti, I don't know | 15:32 |
| rickspencer3 | pitti, seb128 can we focus on gwibber for a moment | 15:32 |
| ccheney | rickspencer3: hi | 15:32 |
| rickspencer3 | I have a few lines of discussion I can paste in | 15:32 |
| rickspencer3 | The situation: | 15:32 |
| rickspencer3 | * gwibber uses mutliprocessing.pool in a deeply integrated way | 15:32 |
| rickspencer3 | * calling gnome keyring from threads causes threadlocks | 15:32 |
| rickspencer3 | * this effects other apps as well (seahorse, couch, etc...) | 15:32 |
| rickspencer3 | Possible solutions: | 15:32 |
| rickspencer3 | * Store passwords in plain text in desktopcouch | 15:32 |
| rickspencer3 | * Refactor gwibber so it doesn't use threads | 15:32 |
| rickspencer3 | * Roll back the keyring package to a version that does not exhibit the bug | 15:32 |
| rickspencer3 | * Try to tweak the existing code, looking for a magic formula to make calling the keyring from a thread not thread lock | 15:32 |
| rickspencer3 | * Write a new module for gwibber that loads all of the passwords from the keyrings into memory at startup, outside a thread. Call this module from the threads. Figure out how to update these passwords in memory if the user changes passwords in the GUI. | 15:32 |
| rickspencer3 | obviously I think the last option is the best | 15:33 |
| rickspencer3 | thoughts? | 15:33 |
| pitti | I think we can safely discard the "Store passwords in plain text in desktopcouch" option | 15:34 |
| rickspencer3 | agreed | 15:34 |
| james_w | * Figure out why calling gnome-keyring from different *processes* hangs, and if it's possible to stop that while using multiprocessing | 15:34 |
| rickspencer3 | james_w | 15:35 |
| chrisccoulson | if seahorse exhibits the same beahviour, then it should be easier to debug it using seahorse (no python interpreter) | 15:35 |
| rickspencer3 | right | 15:35 |
| rickspencer3 | chrisccoulson, I don't know that it does exhibit the same behavior | 15:35 |
| pitti | how about having just one thread doing the keyring calls? | 15:35 |
| rickspencer3 | pitti, that seems like a rather major refactoring | 15:36 |
| chrisccoulson | rickspencer3, i've noticed seahorse uses a lot of CPU when viewing secrets | 15:36 |
| pitti | but if several *processes* lock up, then it's not the dbus-glib threading issue | 15:36 |
| pitti | back then, I had no problem at all with multiple processes | 15:36 |
| rickspencer3 | yes, it's processes, not threads, sorry | 15:36 |
| pitti | ok, that's more difficult then, due to the IPC involved | 15:36 |
| rickspencer3 | pitti, gwibber uses mutliprocess.pool() | 15:36 |
| rickspencer3 | then map_async | 15:37 |
| pitti | I'm not familiar with that :( | 15:37 |
| seb128 | neither am I | 15:37 |
| rickspencer3 | basically it's a library that makes it easy to spin off processes | 15:37 |
| SEJeff | To get around python's GIL | 15:37 |
| rickspencer3 | but the point is that changing how the processes run would be major open heart surgery on gwibber | 15:38 |
| pitti | but if the problem also affects seahorse, etc., then I don't understand why we are focussing on gwibber? | 15:38 |
| james_w | pitti: it's processes, but they are not clean processes I believe, sharing too much state in this case. | 15:38 |
| james_w | http://pastebin.ubuntu.com/410145/ <- Ken's minimal reproducer | 15:38 |
| pitti | hm, those do look like threads, though? | 15:39 |
| rickspencer3 | well, the way I read the code is | 15:39 |
| seb128 | chrisccoulson said they shared the same context though which was an issue | 15:39 |
| rickspencer3 | ryan creates a thread, which then spawns processes | 15:39 |
| rickspencer3 | so MapAsync is a thread, right? | 15:39 |
| pitti | it doesn't call dbus.mainloop.glib.threads_init() ? | 15:39 |
| pitti | does that even work? | 15:40 |
| rickspencer3 | and then in run it spawns processes through multiprocess.pool() | 15:40 |
| rickspencer3 | and perform_operation is within one of those processes | 15:40 |
| rickspencer3 | however, I could easily be reading it wrong | 15:40 |
| pitti | what does the program do? | 15:41 |
| pitti | if I start it, I see no output | 15:41 |
| pitti | oh, now I do | 15:41 |
| pitti | two lines of gibberish, then "Complate" | 15:41 |
| james_w | yeah, there's a 10 second delay | 15:41 |
| rickspencer3 | pitti, the program prints your desktopcouch auoth secret | 15:41 |
| pitti | repeated | 15:41 |
| rickspencer3 | forever | 15:42 |
| rickspencer3 | and your CPU pegs | 15:42 |
| james_w | it spawns a thread to monitor the children | 15:42 |
| james_w | that thread then spawns two processes, both of which request your desktopcouch oauth from gnome-keyring and print it | 15:42 |
| james_w | when they are done the thread callbacks to the main object (but not main thread) to print the "Complate" | 15:43 |
| pitti | and that does work with the karmic gnome-keyring? | 15:43 |
| james_w | dunno, anyone have a karmic vm to hand? | 15:43 |
| seb128 | well gnome-keyring in karmic was not using dbus for communication | 15:43 |
| seb128 | I don't think that shows especially a gnome-keyring issue | 15:44 |
| seb128 | but the fact it uses dbus now shows gwibber design issues | 15:44 |
| rickspencer3 | seb128, right | 15:44 |
| rickspencer3 | but a full refactor of gwibber is out of scope | 15:45 |
| pitti | ah, that'd be it | 15:45 |
| rickspencer3 | for Lucid | 15:45 |
| seb128 | right | 15:45 |
| seb128 | I'm just saying why it doesn't happen in karmic keyring version | 15:45 |
| rickspencer3 | ok, noted | 15:45 |
| pitti | seb128: woudl it even be an option to downgrade keyring? I mean, did the data format on disk change, or anything? | 15:45 |
| seb128 | I don't think anything changed no | 15:46 |
| asac | in UNE ... do apps get the focus after starting by default? | 15:46 |
| seb128 | the libgnome-keyring api stayed compatible | 15:46 |
| seb128 | the storage too | 15:46 |
| seb128 | they just refactored gnome-keyring to be a dbus service now | 15:46 |
| seb128 | and libgnome-keyring to be a compatibility wrapper | 15:46 |
| seb128 | ie you can still use it the same way but it's meant to be deprecated for direct dbus calls in the next cycles | 15:47 |
| pitti | asac: they should; WFM, anyway (they usually start fullscreen anyway) | 15:47 |
| asac | yeah | 15:47 |
| asac | we have this -efl bug --- which is why i wasnt sure | 15:47 |
| asac | UNE is using metacity or compiz? | 15:48 |
| ogra | metacity | 15:48 |
| ogra | well ... maximus | 15:48 |
| ogra | which is meta on crack :) | 15:48 |
| pitti | seb128, rickspencer3: so could we add the old libngome-keyring/python-gnomekeyring as a parallel package for usage with gwibber? | 15:48 |
| asac | ogra: thought maxiumus just sits outside and forces windows tec. | 15:49 |
| rickspencer3 | I was thinking that | 15:49 |
| seb128 | pitti, urg, no | 15:49 |
| rickspencer3 | and perhaps seahorse or others as needed | 15:49 |
| pitti | it seems like a very large hammer, though | 15:49 |
| ogra | asac, i alwqays thought it was a part of metacity | 15:49 |
| seb128 | pitti, libgnome-keyring gnome-keyring is one set | 15:49 |
| pitti | I wouldn't like to roll back half of the desktop just for gwibbeer | 15:49 |
| asac | ogra: source wise its a separate package | 15:49 |
| seb128 | pitti, the lib talked to the daemon via sockets in karmic which the new daemon doesn't have now | 15:49 |
| asac | ogra: i think its also a separate process | 15:49 |
| ogra | ah | 15:49 |
| seb128 | pitti, they communicate via dbus now which gnome-keyring in karmic didn't do | 15:49 |
| LaserJock | ogra: I think asac's right | 15:50 |
| pitti | seb128: ok, so we could only roll it back completely | 15:50 |
| seb128 | pitti, ie, storage and lib api are compatible but the communication lib, daemon changed | 15:50 |
| LaserJock | you can just kill maximus for instance and have regular old metacity | 15:50 |
| asac | didrocks: does -efl and non-efl use the same window manager? all metacity? | 15:50 |
| rickspencer3 | seb128, what is the cost of rolling back both parts? | 15:51 |
| rickspencer3 | lack of support going forward in the LTS? | 15:51 |
| seb128 | that | 15:51 |
| LaserJock | asac: I think the only thing that changes is the launcher | 15:51 |
| rickspencer3 | seb128, why could we not install both parts in parallel for gwibber and perhaps other apps to use as needed? | 15:51 |
| seb128 | + I don't know if the storage format is really 100% compatible or if it would not handle downgrades | 15:51 |
| asac | LaserJock: yeah. which is odd. we have bug complaining that apps dont get focus in -efl | 15:51 |
| asac | after starting | 15:51 |
| seb128 | + we didn't test GNOME 2.30 on gnome-keyring 2.28 | 15:52 |
| seb128 | not sure if that would raise another class of bugs in other softwares which have been made to work with the new one | 15:52 |
| rickspencer3 | right | 15:52 |
| rickspencer3 | so a full roll back is risky | 15:52 |
| seb128 | rickspencer3, you can't have 2 daemon running for the same thing | 15:52 |
| rickspencer3 | ok | 15:52 |
| seb128 | they would race to reply etc | 15:52 |
| rickspencer3 | understood | 15:52 |
| seb128 | and you can't have both version of the lib installed anyway since soname didn't change | 15:53 |
| rickspencer3 | well, I was thinking that we would change the name spaces or what not so they wouldn't race | 15:53 |
| seb128 | couldn't we just default to not use the keyring to store passwords? | 15:53 |
| rickspencer3 | if we installed in parallel | 15:53 |
| LaserJock | asac: could perhaps the launcher be stealing focus or something? | 15:53 |
| seb128 | rickspencer3, I think it would be less risky and costy to refactor gwibber | 15:53 |
| rickspencer3 | seb128, that is an option, store the passwords in plain text in desktopcouch | 15:53 |
| didrocks | asac: metacity is the default for non-efl. as -efl has no paticular -settings package, it should be distribution default, ie compiz | 15:53 |
| rickspencer3 | but kees nacked that | 15:53 |
| asac | didrocks: ah. | 15:54 |
| rickspencer3 | pitti, I agree with seb128 | 15:54 |
| pitti | potential instability of other parts of the desktop, which we just tested against the new g-k | 15:54 |
| pitti | seb128, james_w: could it be possible to hack python-gnome-keyring to serialize the calls, with a mutex? | 15:54 |
| pitti | ^ yes, quite | 15:54 |
| pitti | rickspencer3: I veto that as well | 15:54 |
| asac | didrocks: but if there is no 3d compiz falls back to meta on its own? | 15:54 |
| didrocks | asac: normally yes | 15:54 |
| rickspencer3 | seb128, pitti what would you think of having Nafai start working on: | 15:54 |
| rickspencer3 | 1. batch up all the calls to gnome-keyring in gwibber at startup in an non-threaded way | 15:54 |
| seb128 | pitti, serialize, dunno | 15:54 |
| asac | didrocks: how much work would it be to make -efl do the right thing wrt settings etc.? | 15:54 |
| asac | this seems to come back regularly, so i wonder if we should just fix that | 15:55 |
| rickspencer3 | 2. replace the 3 or 4 places that gwibber calls gnome keyring in threads to get the stored passwords there | 15:55 |
| rickspencer3 | ? | 15:55 |
| rickspencer3 | this seems like "not rocket science" programming | 15:55 |
| seb128 | one other option we didn't try would be to talk to gnome-keyring daemon directly | 15:55 |
| didrocks | asac: not that much, need a new -settings package, NEWed it, and setting the right parameter | 15:55 |
| rickspencer3 | seb128, interesting | 15:55 |
| didrocks | asac: can work on that tomorrow (as it's too late for beta2 in any case) | 15:56 |
| rickspencer3 | you can do this in python ok? | 15:56 |
| seb128 | ie using direct dbus calls to the daemon | 15:56 |
| james_w | pitti: that could work | 15:56 |
| seb128 | it's only dbus... | 15:56 |
| asac | didrocks: is there a way we can easily test if that would fix our focus thing? | 15:56 |
| seb128 | you can do dbus calls in python yes | 15:56 |
| pitti | rickspencer3: speaking d-bus in python is dead easy | 15:56 |
| rickspencer3 | right | 15:56 |
| asac | didrocks: like putting some file somewhere? | 15:56 |
| pitti | but as I said, using python-dbus has tons of threading problems as well | 15:56 |
| rickspencer3 | just use the d-bus library and replace those calls | 15:56 |
| pitti | threads and dbus just don't mix, sorry | 15:56 |
| seb128 | I'm not sure the server has methods for what we need or not, I've not looked to the dbus interface | 15:56 |
| rickspencer3 | pitti, right, but it seems worth a shot | 15:56 |
| pitti | rickspencer3: I think your "batching in the main thread" would be the safest option | 15:56 |
| pitti | rickspencer3: I think we should modify the reproducer for the various possibilities that we have | 15:57 |
| rickspencer3 | right, but hacking the d-bus api directly would take like 30 minutes to try | 15:57 |
| pitti | rickspencer3: i. e. (1) direct d-bus), (2) use mutexes to isolate calls | 15:57 |
| seb128 | well pitti seems to say dbus will not like that by experience | 15:57 |
| pitti | rickspencer3: the reproducer script is nice because it's much faster to hack on than gwibber | 15:57 |
| didrocks | asac: for testing, you can copy every files (but netbook-launcher) containing "une" in the path and replace them with "une-efl" (/etc/xdg-efl mostly and gconf related stuff) from the ubuntu-netbook-default-settings package | 15:57 |
| rickspencer3 | (3) batch the "get_password" calls before the threads start | 15:57 |
| rickspencer3 | pitti, yup | 15:58 |
| didrocks | asac: then, start the UNE 2D session | 15:58 |
| pitti | rickspencer3: right, forgot that | 15:58 |
| rickspencer3 | ok, who wants to try (1)? | 15:58 |
| asac | gwibber still uses multithreading? thought that was fixed this cycle ;) | 15:58 |
| asac | (ignore me) | 15:58 |
| rickspencer3 | asac, it doesn't use multithreading, it uses multithreads which spawn multiple parallel processes | 15:58 |
| james_w | could using the async keyring calls be worth a look too? | 15:59 |
| pitti | rickspencer3: so, assuming that (1), (2), or (3) works, these are by far my most preferred solutions | 15:59 |
| pitti | rickspencer3: anythign else is crackful or way too risky IMHO | 15:59 |
| seb128 | +1 | 15:59 |
| rickspencer3 | much agreed | 15:59 |
| pitti | james_w: async d-bus calls, you mean? | 15:59 |
| rickspencer3 | I think (3) is a good fallback | 15:59 |
| james_w | the sync ones share context and block on it apparently, but doing this ourselves could work around that | 15:59 |
| rickspencer3 | that's the approach that other apps took to work around this | 15:59 |
| james_w | pitti: or just the ones wrapped by libgnome-keyring. It currently calls _sync versions | 16:00 |
| pitti | james_w: I'm not that fancy rewriting libgnome-keyring, TBH | 16:00 |
| pitti | we don't know which other apps it can affect, or what we screw up | 16:00 |
| james_w | pitti: it already has theM! | 16:00 |
| pitti | oh! | 16:00 |
| pitti | james_w: yes, definitively | 16:01 |
| Damascene | hello, what is the way to accept some package to be installed for rtl language? | 16:01 |
| Damascene | like mlterm for rtl support in terminal? | 16:02 |
| rickspencer3 | I didn't quite track that, so james_w is going to try (2)? | 16:02 |
| Damascene | https://bugs.launchpad.net/vte/+bug/263822/ | 16:02 |
| ubottu | Launchpad bug 263822 in vte "RTL (right to left) support in terminal (BiDi)" [Low,Triaged] | 16:02 |
| pitti | rickspencer3: I think james_w's proposal is quite the opposite of (2) .. it makes them "more" async :) | 16:02 |
| rickspencer3 | oh | 16:03 |
| seb128 | I think james_w's suggestion is what I would try first there | 16:03 |
| rickspencer3 | you mean make the keyring asynchronous so threads don't block when they call into it | 16:03 |
| rickspencer3 | ? | 16:03 |
| Nafai | I'm here | 16:03 |
| rickspencer3 | that seems rather bold | 16:03 |
| rickspencer3 | Hi Nafai we are discussing how to solve the problem with gwibber, please read the scroll back | 16:04 |
| pitti | I remember having had problems with that, too | 16:04 |
| seb128 | rickspencer3, libgnome-keyring has asyncs calls | 16:04 |
| Nafai | ok | 16:04 |
| seb128 | you don't have to make those, just to use those | 16:04 |
| pitti | i. e. sync calls which block the mainloop from continuing, which is required to finish the call, etc. | 16:04 |
| rickspencer3 | seb128, sorry to be dense ... is the suggestion to use async calls within gwibber? | 16:04 |
| pitti | hey Nafai | 16:04 |
| seb128 | rickspencer3, I think so yes | 16:04 |
| pitti | rickspencer3: yes | 16:04 |
| rickspencer3 | hmmmm | 16:05 |
| seb128 | <james_w> the sync ones share context and block on it apparently, but doing this ourselves could work around that | 16:05 |
| rickspencer3 | that seems rather easy, yes | 16:05 |
| seb128 | I would start by trying that | 16:05 |
| rickspencer3 | at least worth a try in the repro script | 16:05 |
| rickspencer3 | so (4) replace value = gnomekeyring.find_items_sync() with find_items_asynch() | 16:06 |
| james_w | nope, that seems to use a lot of CPU as well | 16:07 |
| seb128 | :-( | 16:07 |
| rickspencer3 | no easy answers | 16:08 |
| pitti | I'll try mutexes now | 16:08 |
| pitti | i. e. (2) | 16:08 |
| james_w | is it possible that libgnome-keying just uses a lot of CPU time? | 16:08 |
| seb128 | james_w, no | 16:08 |
| seb128 | empathy has no cpu use issue | 16:08 |
| seb128 | neither does evolution | 16:08 |
| rickspencer3 | james_w, it pegs one core forever | 16:08 |
| james_w | right | 16:09 |
| james_w | just checking :-) | 16:09 |
| seb128 | rickspencer3, the question was rather to know if gnome-keyring is just buggy and does that whatever you do | 16:09 |
| seb128 | which it's not the case | 16:09 |
| seb128 | since we have other desktop components using it without issues | 16:10 |
| chrisccoulson | james_w - so, my theory from yesterday is probably not the issue then (if you tried with an async call) | 16:10 |
| rickspencer3 | seb128, well, not actually true | 16:10 |
| rickspencer3 | desktopcouch had the same issue | 16:10 |
| chrisccoulson | but using the async call from a separate thread has it's own issues | 16:10 |
| rickspencer3 | so they worked around it | 16:10 |
| seb128 | rickspencer3, the all use multiprocessing though? | 16:10 |
| rickspencer3 | right | 16:10 |
| === al-maisan is now known as almaisan-away | ||
| chrisccoulson | (it adds an event to the default context, so the callback you pass to the async call will execute in the main process) | 16:11 |
| seb128 | so it means gnome-keyring used in that context has issues | 16:11 |
| rickspencer3 | well, tbh, I don't know for certain if it was "processes" verses "threads" | 16:11 |
| seb128 | it doesn't mean gnome-keyring is buggy | 16:11 |
| rickspencer3 | seb128, right | 16:11 |
| rickspencer3 | correct | 16:11 |
| rickspencer3 | I think these are just incompatibilities | 16:11 |
| seb128 | well it's just safe to be used in those contexts | 16:11 |
| seb128 | which apparently dbus is not either | 16:11 |
| rickspencer3 | anyway Nafai done reading scrollback? | 16:12 |
| Nafai | yeah | 16:12 |
| rickspencer3 | ok | 16:12 |
| rickspencer3 | so ... | 16:12 |
| pitti | ok, mutexes don't help either | 16:12 |
| rickspencer3 | I think in gwibber we'll end up with: | 16:12 |
| rickspencer3 | (3) batch the "get_password" calls before the threads start | 16:12 |
| rickspencer3 | this will mean I will ask you to write some code for this | 16:12 |
| Nafai | ok | 16:13 |
| Nafai | that does seem to be the best solution for the time which we have | 16:14 |
| rickspencer3 | Nafai, do you have the bandwidth to focus on this 100% today? | 16:14 |
| rickspencer3 | I'd like to see a branch that we can start testing this tomorrow | 16:14 |
| pitti | strace shows that it's constantly poll()ing | 16:14 |
| pitti | which returns with "I have data" | 16:15 |
| pitti | but it doesn't seem to fetch it | 16:15 |
| Nafai | I could, I just need to make sure I pass what I've seen with the bug I'm looking at off to the dx guys since it seems to be in the app indicator code itself | 16:15 |
| pitti | james_w, rickspencer3, seb128: no luck with mutexes, sorry | 16:16 |
| rickspencer3 | yeah | 16:16 |
| rickspencer3 | pitti, I believe we are retreading ground that kenvandine has already been over | 16:16 |
| seb128 | Nafai, the fallback icon bug is a minor one | 16:16 |
| seb128 | it's only fallback for people not using indicators | 16:16 |
| Nafai | yeah | 16:16 |
| rickspencer3 | (not that we shouldn't analyze it) | 16:16 |
| seb128 | you can just ignore it for lucid | 16:16 |
| Nafai | ok | 16:16 |
| pitti | in the end, I bet it's the old dbus-glib problem | 16:17 |
| pitti | you have one main loop, and a different thread which wants the data | 16:17 |
| rickspencer3 | Nafai, pitti, seb128, james_w, fwi, this worked fine: http://pastebin.ubuntu.com/410585/ | 16:18 |
| rickspencer3 | that's the (3) approach | 16:18 |
| pitti | so I think having the main thread collect the account passwords and store them in mlock()ed memory will work best | 16:18 |
| seb128 | +1 | 16:18 |
| pitti | rickspencer3: right | 16:18 |
| rickspencer3 | I propose we focus today on getting gwibber reading the passwords working without issue | 16:19 |
| pitti | rickspencer3: I think that'd be the only rock solid an unintrusive (on a global desktop level) solution | 16:19 |
| rickspencer3 | then tomorrow figure out what to do when users change the passwords | 16:19 |
| pitti | but nevertheless it was interesting to check the alternatives | 16:19 |
| rickspencer3 | pitti, agreed | 16:19 |
| rickspencer3 | the analysis was useful | 16:19 |
| rickspencer3 | and not too time consuming | 16:19 |
| pitti | rickspencer3: at worst they'd have to restart gwibber? | 16:19 |
| rickspencer3 | exactly | 16:19 |
| rickspencer3 | well, gwibber-service, but yeah | 16:20 |
| pitti | oh, rather, restart gwibber if the account which they are already logged in to disconnects | 16:20 |
| rickspencer3 | pitti, seb128, Nafai, james_w - are we all agreed that Nafai should start down path (3) today? | 16:20 |
| pitti | changing passwords wouldn't disconnect running clients, I suppose? | 16:20 |
| pitti | rickspencer3: +1 | 16:20 |
| seb128 | +1 | 16:20 |
| Nafai | +1 :) | 16:20 |
| pitti | the dbus-glib threading problem is known upstream for years | 16:20 |
| pitti | I don't think we'll find a solid solution within days | 16:21 |
| rickspencer3 | pitti, right, all the easy answers have been tried | 16:21 |
| Nafai | I should work off of gwibber trunk, right? | 16:21 |
| rickspencer3 | this seems SMOP | 16:21 |
| pitti | Nafai: Qapla'! | 16:21 |
| Nafai | :) | 16:22 |
| Nafai | pitti: I admit it's been a while since I've done a lot of C, so I'm not familiar with mlock(); is this available from Python? | 16:23 |
| pitti | Nafai: hm, doesn't seem so :( | 16:23 |
| pitti | Nafai: I propose you write a stub function mlock() which does nothing | 16:24 |
| pitti | Nafai: and then we can try and write somethign using ctypes | 16:24 |
| Nafai | ok, sounds good | 16:24 |
| * Nafai dives in | 16:25 | |
| didrocks | rickspencer3: thanks for winpdb hints, it's really a time saver (even regarding to pdb) :) | 16:29 |
| rickspencer3 | didrocks, nice | 16:29 |
| Nafai | yay for quickly debug :) | 16:32 |
| didrocks | :) | 16:33 |
| didrocks | (it's more "debugging quickly" now TBH :)) | 16:33 |
| didrocks | and "$ quickly debug quickly" isn't automated :) | 16:33 |
| seb128 | I'm out for some testing, sport and then dinner | 16:59 |
| seb128 | see you later | 16:59 |
| Nafai | out for lunch and a rest and then back to the gwibber fixes | 18:14 |
| james_w | I'm not convinced we are looking at the right cause for the keyring problem | 18:15 |
| james_w | you don't need multiple processes to trigger it | 18:16 |
| james_w | running with Pool(1) (which should give a single process in the pool) shows the issue | 18:16 |
| james_w | and from the moment the child writes the secret out until the parent kicks of the new process the parent is busy looping, polling a couple of fds that I think communicate with the child | 18:17 |
| james_w | I realise that desktopcouch had the same symptoms, but it's possible we are looking at two different causes | 18:18 |
| james_w | however, what is stopping me from declaring it to be unrelated to the keyring is that I can't reproduce with the child just doing a sleep | 18:18 |
| james_w | which leads me to believe that libgnome-keyring is stopping the child from exiting cleanly somehow | 18:19 |
| rickspencer3 | james_w, I don't think there is any doubt that we are focused on a workaround at this point | 18:24 |
| rickspencer3 | but we are too close to release to not have a workr around in place | 18:25 |
| rickspencer3 | and too close to release to start mucking with libgnome keyring internals | 18:25 |
| rickspencer3 | but knowing the root cause would be a dramatic improvement in our state of affairs | 18:25 |
| james_w | but yes, it appears that chriscoulson is correct. The two processes share a GMainContext, and so share the pipe that they use when you init threads. When the child process exits it obviously leaves the context in an invalid state, because it just continually wakes, leading to the high cpu usage. | 18:42 |
| james_w | if you don't call g_thread_init() then you don't get the pipe or the helper thread that polls it, so you don't get the issue as Ken found (but it's not the right answer) | 18:43 |
| james_w | making them real processes, rather than the multiprocessing ones would fix that, but the gwibber tasks look too dynamic to make that easy enough to do | 18:50 |
| rickspencer3 | james_w, do you think that is a reasonable refactoring to do in 10.10? | 18:56 |
| james_w | It depends how Ryan wants to play it | 18:56 |
| rickspencer3 | or is it even worth investing some time right now to see if that will work | 18:56 |
| rickspencer3 | in 10.04, I mean | 18:57 |
| rickspencer3 | ? | 18:57 |
| james_w | oh | 18:57 |
| === almaisan-away is now known as al-maisan | ||
| james_w | maybe, I haven't dug in to the code sufficiently to see how much work would be required | 18:57 |
| rickspencer3 | one thing about Ryan's code is that it is pretty centralized | 18:57 |
| rickspencer3 | if you look in dispatcher.py, there is a MapAsync class that does all the work | 18:58 |
| james_w | yeah | 18:58 |
| james_w | it's the operations that I didn't research though | 18:58 |
| rickspencer3 | mmm | 18:58 |
| rickspencer3 | yeah, I didn't find that easy to understand | 18:58 |
| rickspencer3 | in other words, I didn't understand that part ;) | 18:59 |
| james_w | I'm still looking at multiprocessing though | 19:00 |
| james_w | I don't understand how it is sharing so much state | 19:00 |
| rickspencer3 | break time for me | 19:02 |
| rickspencer3 | bbl | 19:02 |
| === MacSlow is now known as MacSlow|afk | ||
| james_w | hmm, multiprocessing just does a single fork, meaning that the children will inherit the open fds of the parent, including this thread fd, that could be the reason | 19:24 |
| baptistemm_ | heya | 19:32 |
| james_w | there we go, a real minimal test case: http://paste.ubuntu.com/410667/ | 19:38 |
| james_w | no keyring, no threads, just threads_init(), multiprocessing and unclosed fds | 19:38 |
| james_w | so, a proper fix would have the called functions create a new GMainContext and use that, but I don't think that many things support that | 19:41 |
| === Amaranth_ is now known as Amaranth | ||
| james_w | and I doubt that g_main_context_push_thread_default is supported enough to be a substitute | 19:42 |
| james_w | and it seems you can't call it from python anyway | 19:48 |
| james_w | right, enough of that, time for dinner | 19:48 |
| mvo | is it just me does LP has a bad day today? oops, oops, oops | 20:17 |
| baptistemm_ | mvo, yeah, ... | 20:30 |
| maxb | I'm not sure if there's a better channel for NetworkManager questions, so I'll ask here. | 20:52 |
| maxb | Is there any way for a program to tell NetworkManager to use a different DNS server? | 20:52 |
| chrisccoulson | does anybody use a B+W laser printer at home with Ubuntu? (and could recommend one that works reliably) | 21:03 |
| * pitti has used a Samsung ML-1610 for some years, with quite good results | 21:03 | |
| seb128 | not me | 21:04 |
| chrisccoulson | pitti - thanks, i'll look at one of those | 21:04 |
| soren | chrisccoulson: Does it have to be b/W? | 21:05 |
| chrisccoulson | heh, i bet hardly anyone uses black and white printers now ;) | 21:05 |
| chrisccoulson | soren - it doesn't have to be b/w | 21:05 |
| soren | chrisccoulson: I'm quite happy with my Konica Minolta Magicolor 2530 DL. | 21:06 |
| chrisccoulson | but it should be relatively low-cost to maintain (I have a photo printer, but the ink cartridges for that are incredibly expensive, and it's no good for printing lots of pages) | 21:06 |
| chrisccoulson | soren - thanks | 21:06 |
| soren | chrisccoulson: It's served me quite well for.. hmm... 4 years now, I think. | 21:06 |
| soren | chrisccoulson: Not too expensive, and they actually went through the trouble of writing linux drivers for it. | 21:06 |
| chrisccoulson | excellent, that sounds good | 21:07 |
| soren | chrisccoulson: (which suck, but there are other ones (not developed by Konica) that work well) | 21:07 |
| chrisccoulson | the LEXMARK X264dn looks quite nice actually (and it's available in a store a couple of miles away from me) | 21:17 |
| chrisccoulson | it does scanning too :) | 21:17 |
| seb128 | http://paste.ubuntu.com/410710/ | 21:17 |
| seb128 | does it look like a libusb or libmtp bug? | 21:18 |
| seb128 | libusb I guess | 21:18 |
| seb128 | I never know how to read the 2 parts in valgrind logs | 21:18 |
| seb128 | the second one is the allocation and the first one the error? | 21:18 |
| chrisccoulson | seb128 - yeah, that's how interpret it too | 21:19 |
| chrisccoulson | i think that looks like a libusb bug | 21:20 |
| seb128 | thanks | 21:20 |
| seb128 | pitti, seems you have an account on the libusb bug tracker? | 21:21 |
| fta | xchat still crashing on exit because of the indicator thing (bug 549972) | 21:22 |
| ubottu | Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/549972) | 21:22 |
| seb128 | fta, you are welcome to send a patch for the issue or to not use the indicator | 21:23 |
| fta | ok, i will disable it then :( | 21:23 |
| rickspencer3 | james_w, still around? | 21:51 |
| james_w | yup | 21:52 |
| rickspencer3 | Nafai, ? | 21:52 |
| rickspencer3 | ok, so I just changed dispatcher.py | 21:52 |
| Nafai | ok | 21:52 |
| rickspencer3 | I made MapAsync not be a thread | 21:52 |
| Nafai | did that fix it? | 21:52 |
| rickspencer3 | maybe | 21:52 |
| rickspencer3 | wait, prolly not | 21:52 |
| rickspencer3 | hold on | 21:52 |
| rickspencer3 | dammit | 21:53 |
| rickspencer3 | it survived several refreshes | 21:53 |
| rickspencer3 | but on like the fourth one it pegged again | 21:53 |
| rickspencer3 | never min | 21:53 |
| rickspencer3 | d | 21:53 |
| * rickspencer3 cries a little | 21:53 | |
| Nafai | :( | 21:53 |
| james_w | rickspencer3: did you see my reproducer? | 21:56 |
| rickspencer3 | is it the one that we were using this morning? | 21:56 |
| rickspencer3 | if so, then yes | 21:57 |
| james_w | no | 21:57 |
| rickspencer3 | oh | 21:57 |
| james_w | <james_w> there we go, a real minimal test case: http://paste.ubuntu.com/410667/ | 21:57 |
| james_w | <james_w> no keyring, no threads, just threads_init(), multiprocessing and unclosed fds | 21:57 |
| rickspencer3 | interesting | 21:57 |
| james_w | I'm pretty sure that's equivalent | 21:57 |
| james_w | I'll try putting in a callback or something in the child in a minute | 21:58 |
| rickspencer3 | wait | 21:59 |
| rickspencer3 | so it occurs to me then | 21:59 |
| rickspencer3 | interesting | 22:00 |
| rickspencer3 | so in ken's reproducer | 22:00 |
| rickspencer3 | if I make MapAsync not be a thread | 22:00 |
| rickspencer3 | and delete threads.init() | 22:00 |
| rickspencer3 | it doesn't peg | 22:00 |
| rickspencer3 | let me try a few times | 22:00 |
| james_w | rickspencer3: threads_init is one of the critical parts of the issue | 22:02 |
| james_w | Ken found that it stopped it hanging the other day | 22:02 |
| rickspencer3 | james_w, isn;'t that because MapAsync is a thread? | 22:02 |
| rickspencer3 | so now if MapAsync is not a thread, why init threading at all? | 22:02 |
| james_w | but it's broken, so not a viable solution or workaround | 22:03 |
| james_w | well, yeah, I said minimal reproducer, not sensible one :-) | 22:03 |
| james_w | but you aren't going to get very far pulling the threads out of gwibber I fear | 22:04 |
| rickspencer3 | how many threads are there in gwibber? | 22:04 |
| rickspencer3 | let me look | 22:04 |
| james_w | well, one for every MapAsync | 22:04 |
| rickspencer3 | right | 22:05 |
| james_w | note that the implementation in the new reproducer *blocks the main thread* | 22:05 |
| rickspencer3 | but I made MapAsync *Not* a thread | 22:06 |
| rickspencer3 | it's still pegging though | 22:06 |
| james_w | and still had the timeouts? | 22:06 |
| james_w | meaning you made it not a thread, keeping the behaviour that allows you to have timeouts, and not blocking the main thread? | 22:06 |
| rickspencer3 | Dispatcher is itself a thread :( | 22:06 |
| james_w | if so, then that's a fine way to proceed, but I don't see how to do that without major surgery | 22:07 |
| rickspencer3 | james_w, all the thread does is spawn processes | 22:07 |
| rickspencer3 | I don't even know what value have MapAsync a thread brings | 22:07 |
| rickspencer3 | I guess it brings a bit more parallelism | 22:07 |
| james_w | it allows you to timeout the child processes | 22:07 |
| rickspencer3 | but dispatcher is itself a thread | 22:08 |
| rickspencer3 | making dispatcher not a thread seems a bit more invovled | 22:09 |
| james_w | right, so it sounds like removing threads from gwibber is going to be difficult | 22:09 |
| rickspencer3 | well, dispatcher is the only other thread | 22:09 |
| james_w | we could make it a subprocess | 22:09 |
| rickspencer3 | note that we shouldn't stop Nafai down his path | 22:09 |
| Nafai | ok, good | 22:09 |
| Nafai | cause I'm still working on that path | 22:09 |
| rickspencer3 | Nafai, ignore this conversation and get your merge proposal ready ;) | 22:10 |
| * Nafai nods | 22:10 | |
| rickspencer3 | james_w, the gui is also threaded | 22:10 |
| james_w | there's gwibber/microblog/util/couch.py:class Monitor(gobject.GObject, threading.Thread): | 22:10 |
| rickspencer3 | do you think that will be an issue? | 22:10 |
| rickspencer3 | didn't see that one | 22:10 |
| james_w | if there is more than one thread in the gwibber-service process then you have to call gobject.threads_init() | 22:11 |
| rickspencer3 | the gui is not in gwibber-service | 22:11 |
| james_w | if you call the function and then use gobject based stuff with multiprocessing you get the bug | 22:11 |
| james_w | whichever process has the hang | 22:11 |
| james_w | the high CPU I mean | 22:11 |
| rickspencer3 | that's gwibber-service | 22:11 |
| rickspencer3 | so would it be feasible to turn dispatcher and monitor from threads into processes? | 22:12 |
| rickspencer3 | I've worked with threads and time outs, but not processes | 22:12 |
| james_w | possible, yes | 22:12 |
| james_w | I assume | 22:12 |
| james_w | realistic, maybe not | 22:13 |
| AnAnt | Hello, what has happened to guile-gnome2-* packages ? | 22:13 |
| james_w | what does gwibber-service do? It's the bit you call to send messages etc? | 22:13 |
| rickspencer3 | yah | 22:14 |
| rickspencer3 | well sends and receives messages | 22:14 |
| rickspencer3 | stuffs them into desktopcouch | 22:14 |
| rickspencer3 | rips a notification too, I think | 22:14 |
| james_w | right | 22:15 |
| james_w | so, Dispatcher is a thread, I'm not sure it has to be yet | 22:15 |
| === bjf is now known as bjf-afk | ||
| rickspencer3 | I'm truing it as a multiprocess.Process | 22:18 |
| james_w | yeah, it has no run() method | 22:18 |
| rickspencer3 | it seemed to work | 22:19 |
| rickspencer3 | at least it retrieved new messages | 22:19 |
| james_w | right, so the reason MapAsync is a thread is to allow it to process multiple requests in parallel, and also to implement timeouts on them | 22:20 |
| james_w | however, we can do that in a subprocess as well | 22:20 |
| james_w | it does mean that gwibber could be quite the resource hog if it is busy :-) | 22:21 |
| rickspencer3 | right | 22:21 |
| rickspencer3 | but less than 100% probably ;) | 22:21 |
| rickspencer3 | so Dispatcher is dbus object right? | 22:22 |
| rickspencer3 | doesn't it just sit around until it gets called? | 22:22 |
| james_w | yeah | 22:25 |
| james_w | my changes seem to have broken it | 22:25 |
| james_w | no 100% CPU, but nothing working either :-) | 22:25 |
| === al-maisan is now known as almaisan-away | ||
| rickspencer3 | well, it's working for me | 22:28 |
| rickspencer3 | there is no more gobject.threads_init() | 22:28 |
| rickspencer3 | but yet I am still pegging the cpu :/ | 22:29 |
| rickspencer3 | let me make sure I'm doing this right | 22:29 |
| james_w | rickspencer3: I've got it working | 22:32 |
| james_w | however, there's one thing that concerns me about it | 22:32 |
| rickspencer3 | kewl | 22:32 |
| rickspencer3 | only 1 thing? | 22:32 |
| rickspencer3 | that's good progress ;) | 22:32 |
| james_w | that I had to make "daemon = False" on a bunch of stuff | 22:32 |
| james_w | so it will leave stale processes around | 22:32 |
| rickspencer3 | mm | 22:33 |
| rickspencer3 | even if you quite from the GUI? | 22:33 |
| rickspencer3 | could we add a bit of clean up code there? | 22:33 |
| james_w | yeah | 22:33 |
| james_w | but tracking all the paths won't be that easy | 22:33 |
| james_w | or it may just all work :-) | 22:34 |
| rickspencer3 | heh | 22:34 |
| james_w | http://paste.ubuntu.com/410733/ | 22:34 |
| rickspencer3 | so you changed all the threads to processes? | 22:34 |
| james_w | just the couchdb one | 22:35 |
| rickspencer3 | itneresting | 22:35 |
| james_w | oh, and MapAsync | 22:35 |
| james_w | if you have a hammer... :-) | 22:35 |
| james_w | the couch monitor appears to actually want to be async | 22:36 |
| rickspencer3 | right | 22:36 |
| rickspencer3 | james_w, can you push a branch I can pull? | 22:36 |
| rickspencer3 | I can test it out here | 22:36 |
| rickspencer3 | or I can just revert and apply your patch I suppose | 22:38 |
| rickspencer3 | running now | 22:39 |
| rickspencer3 | the people and groups I follow are always annoyingly quiet when I am testing gwibber | 22:43 |
| james_w | lp:~james-w/gwibber/fix-threading | 22:46 |
| jcastro | rickspencer3: refresh. :D | 22:49 |
| Nafai | sweet | 23:13 |
| Nafai | this may have been easier than I thought | 23:14 |
| rickspencer3 | Nafai, are you making progress on your branch? | 23:15 |
| Nafai | yes, I have a first pass for others to test, I'm about to push it to launchpad | 23:15 |
| Nafai | lp:~nafai/gwibber/gnomekeyring-fix | 23:18 |
| james_w | Nafai: does it have much startup time impact? | 23:25 |
| Nafai | Not sure, I'll have to measure it against the previous one. There is a little spike in the CPU at first, but then the CPU goes down | 23:26 |
| james_w | you could use multiprocessing to distribute the work across a few processes rather than doing it all sequentially ;-) | 23:27 |
| rickspencer3 | haha | 23:28 |
| rickspencer3 | james_w ... your patch seems to be working, except I'm not sure notifications are | 23:28 |
| Nafai | it's the battle of the patches! | 23:28 |
| james_w | hmm, what are the chances that libnotify uses threads? | 23:30 |
| rickspencer3 | heh | 23:31 |
| TheMuso | Good morning. | 23:31 |
| rickspencer3 | james_w, I am sure libnotify is quite solid code | 23:31 |
| rickspencer3 | I could just be missing them | 23:31 |
| Nafai | Hello TheMuso | 23:31 |
| james_w | rickspencer3: no, I see it too | 23:32 |
| rickspencer3 | wow, I planned for being totally pinned down by the default search provider announcement | 23:32 |
| * TheMuso is just seeing that announced in various places. Interesting. | 23:33 | |
| RAOF | Morning all. | 23:35 |
| rickspencer3 | hi RAOF | 23:35 |
| Nafai | Hey RAOF | 23:35 |
| RAOF | Good gwibber morning to you, too! | 23:35 |
| Nafai | rickspencer3: Had a chance to try out my branch? | 23:35 |
| Nafai | It's gwibber day for us here :) | 23:36 |
| rickspencer3 | Nafai, no | 23:36 |
| rickspencer3 | will do right now | 23:36 |
| Nafai | ok | 23:37 |
| RAOF | seb128: Re: using gnome-keyring's DBus interface - I had a look at that for gnome-keyring-sharp, and I don't think it's ready yet. There's no introspection data, the last mailinglist thread I found said “not finished yet”, and most of the calls from libgnome-keyring go to org.gnome.keyring.ShamefullInternalInterface :) | 23:37 |
| seb128 | RAOF, hey, ok, I was not sure about that | 23:37 |
| rickspencer3 | Nafai, where's the branch? | 23:38 |
| rickspencer3 | james_w, fwiw, when I quit your gwibber, all the gwibber-services process went away | 23:38 |
| RAOF | seb128: Just thought I could spare you some time if you wanted to go looking :) | 23:38 |
| james_w | cool | 23:38 |
| james_w | rickspencer3: found the notifications issue | 23:38 |
| RAOF | Also, org.gnome.keyring.ShamefullInternalInterface is funny :) | 23:38 |
| Nafai | lp:~nafai/gwibber/gnomekeyring-fix | 23:39 |
| rickspencer3 | Nafai, just run gwibber-service and gwibber? | 23:39 |
| Nafai | yeah | 23:39 |
| rickspencer3 | seb128, I think we have at least 2 viable options for fixing gwibber now | 23:40 |
| seb128 | rickspencer3, I've been reading discussions and seeing that, nice | 23:40 |
| rickspencer3 | Nafai, I started gwibber-service and started getting notifications | 23:41 |
| rickspencer3 | so that's a good sign ;) | 23:41 |
| Nafai | :) | 23:41 |
| rickspencer3 | Nafai, so far, wfm | 23:42 |
| Nafai | yay | 23:42 |
| rickspencer3 | Nafai, have you handled the case of when a user changes their password? | 23:42 |
| Nafai | not yet, but I can | 23:43 |
| rickspencer3 | well, I guess we'll need to | 23:43 |
| * Nafai nods | 23:43 | |
| rickspencer3 | I suppose the UI you could just shut down and restart gwibber-service | 23:43 |
| rickspencer3 | well, not "from the UI" but from the code for the settings UI | 23:43 |
| rickspencer3 | awesome clarity on my part | 23:44 |
| rickspencer3 | Nafai, maybe I spoke too soon | 23:44 |
| Nafai | spike in CPU? | 23:45 |
| rickspencer3 | beam.smp seems awefull busy | 23:45 |
| rickspencer3 | it's not pegged | 23:45 |
| rickspencer3 | but mean.smp is at like 81% and gwibber service about 30% | 23:45 |
| rickspencer3 | they seem to be sharing a core | 23:45 |
| rickspencer3 | and between them pegging that core | 23:45 |
| james_w | my approach isn't going to work without some more effort | 23:46 |
| james_w | you can't use gobject signals across processes, and multiprocessing doesn't provide an equivalent | 23:46 |
| rickspencer3 | james is that for the notifications integration? | 23:47 |
| james_w | yeah | 23:47 |
| james_w | and possibly other things | 23:47 |
| rickspencer3 | james what about good old pipes? | 23:48 |
| james_w | well, they don't work like signals | 23:48 |
| james_w | without, like, threads or something | 23:48 |
| james_w | we want to use the glib mainloop | 23:49 |
| james_w | to get woken up when a new message appears in couch | 23:49 |
| james_w | we can put the messages in a queue when we see them on couch | 23:49 |
| james_w | but we the either need to poll, or use a thread or something to watch it | 23:49 |
| james_w | we could throw another process at it | 23:49 |
| rickspencer3 | this reminds me of i956 graphics in Jaunty | 23:52 |
| rickspencer3 | Nafai, it's odd that mean.smp is spiking for me | 23:53 |
| rickspencer3 | I thought that was a desktopcouch process | 23:53 |
| Nafai | yeah, I didn't change anything to increase couch access | 23:53 |
| rickspencer3 | even if you did, they fixed it I thought | 23:56 |
| rickspencer3 | Nafai, is it not spiking your CPU? | 23:56 |
| Nafai | other than a bit on startup, no | 23:56 |
| rickspencer3 | hmmm | 23:57 |
| desrt | hello hackers | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
