[01:30] <rickspencer3> kenvandine, I think I figured out how to write a GUI to choose which desktopcouch databases to synch
[01:30] <rickspencer3> I'll try it tonight, seems like it would take about an hour or so
[01:41] <rickspencer3> kenvandine, http://imgur.com/qnfuD
[02:28] <kenvandine> rickspencer3, sweet!
[02:29] <kenvandine> slip cover... lol
[02:29] <kenvandine> :)
[02:33] <rickspencer3> :)
[02:39] <rickspencer3> kenvandine, accessing the gwibber_preferences couchdb immediately pegs my CPU
[02:39] <kenvandine> wow
[02:39] <rickspencer3> gwibber-server and desktopcouch-se
[02:39] <kenvandine> got a test case?
[02:39] <rickspencer3> I'll package the app I just wrote
[02:39] <rickspencer3> and you can run it yourself
[02:39] <kenvandine> great
[02:39] <rickspencer3> it's 100% reliable
[02:39] <rickspencer3> hold on
[02:40] <kenvandine> i would like to get ryan to do it to
[02:40] <rickspencer3> kenvandine, can i just email you the deb?
[02:40] <kenvandine> sure
[02:40] <kenvandine> or IM it to me :)
[02:40] <kenvandine> empathy rocks
[02:41] <rickspencer3> $quickly package ftw
[02:41] <rickspencer3> sure, good idea
[02:41] <kenvandine> quickly rocks too
[02:41] <rickspencer3> kenvandine, so when you run this, it will list out each of your desktopcouch databases as a button
[02:42] <rickspencer3> see what happens when you click gwibbermessages
[02:42] <kenvandine> ok
[02:43] <kenvandine> i get a crash dialog :)
[02:43] <kenvandine> from slip-cover
[02:43] <kenvandine> but
[02:43] <rickspencer3> oh well
[02:43] <kenvandine> not for other dbs
[02:43] <rickspencer3> it doesn't even run?
[02:43] <kenvandine> let me change my passwords to plaintext so i can run gwibber
[02:43] <kenvandine> :)
[02:43] <kenvandine> it does
[02:44] <kenvandine> just clicking on gwibbermessages gives me a crash dialog
[02:44] <kenvandine> it doesn't seem to crash though
[02:44] <rickspencer3> oh
[02:44] <rickspencer3> I bet my way of getting the records from it doesn't work
[02:44] <rickspencer3> I used a super convenience method
[02:44] <rickspencer3> let me see if there is a better way
[02:45] <rickspencer3> oh crikey
[02:45] <kenvandine> oh... here
[02:45] <kenvandine>   File "/usr/lib/python2.6/dist-packages/desktopcouch/records/server_base.py", line 454, in get_records
[02:45] <kenvandine>     raise KeyError("View doesn't already exist.")
[02:45] <kenvandine> KeyError: "View doesn't already exist."
[02:45] <rickspencer3> I have to do hard things
[02:45] <rickspencer3> right
[02:45] <kenvandine> that was in the terminal
[02:46] <kenvandine> no worries
[02:46] <kenvandine> ok, gwibber is running
[02:46] <rickspencer3> so get_records() doesnt' quite work reliably
[02:46] <kenvandine> let me make sure the cpu doesn't peg
[02:46] <rickspencer3> kenvandine, if you run photobomb first, and go to the gwibber tab, it should work
[02:46] <rickspencer3> slipcover, that is
[02:47] <rickspencer3> actually, I wonder if that will pin the CPU
[02:48] <kenvandine> i just did 3 refreshes
[02:48] <kenvandine> with plaintext password... no load
[02:48] <kenvandine> ok, time for slip-cover again
[02:48] <rickspencer3> I have plane text passwords too
[02:48] <kenvandine> you said gwibberpreferences pegs it?
[02:48] <rickspencer3> yes
[02:49] <rickspencer3> kenvandine, can you see if photobomb pegs it for you?
[02:49] <rickspencer3> bzr branch lp:~rick-rickspencer3/+junk/photobomb
[02:49] <kenvandine> yeah, one sec
[02:49] <kenvandine> so just opening gwibberprefernces pegs it for you?
[02:49] <rickspencer3> yes
[02:50] <rickspencer3> but I've run photobomb, which asks gwibber_preferences to create a view for get_records
[02:50] <rickspencer3> that's why slip-cover works for me on that database
[02:50] <rickspencer3> I'll have to write a few lines to create a proper view
[02:52] <kenvandine> i ran it
[02:52] <kenvandine> waiting now :)
[02:52] <kenvandine> gwibber_messages is pretty big
[02:54] <kenvandine> http://pastebin.ubuntu.com/407861/
[02:54] <kenvandine> rickspencer3, ^^
[02:54] <rickspencer3> wtf
[02:54] <kenvandine> and i am not seeing the CPU load
[02:55] <rickspencer3> kenvandine, do you have quickly-widgets installed from universe?
[02:55] <kenvandine> yes
[02:55] <kenvandine> 10.02.2
[02:56] <rickspencer3> weird
[02:56] <rickspencer3> *sigh*
[02:56] <kenvandine> i wonder how your accessing it that causes it
[02:57] <kenvandine> do you read in all the records?
[02:58] <rickspencer3> kenvandine, yes
[02:58] <rickspencer3> db.get_records()
[02:59] <rickspencer3> kenvandine, photobomb also causes the cpu to pim
[03:00] <kenvandine> not for me
[03:00] <rickspencer3> when you refresh on the gwibber tab?
[03:00] <rickspencer3> it does not peg your CPU?
[03:00] <kenvandine> refresh?
[03:00] <rickspencer3> on photobomb, there is a gwibber tab
[03:01] <kenvandine> oh
[03:01] <kenvandine> let me do that
[03:01] <rickspencer3> you have to hit the refresh button for it to start grabbing photos from your gwibber accounts
[03:01] <rickspencer3> it also reads you gwibber settings database and pulls your facebook credentials
[03:03] <kenvandine> wow... photobomb is using a ton of ram
[03:04] <kenvandine> 2G and growing
[03:04] <rickspencer3> hehe
[03:04] <rickspencer3> a tad leaky?
[03:04] <kenvandine> hehe
[03:05] <kenvandine> not really seeing any load problems though
[03:05] <rickspencer3> kenvandine, so the gwibber page didn't peg your CPU?
[03:05] <kenvandine> nope
[03:05] <rickspencer3> this is soooo weird
[03:05] <kenvandine> you said it does it to desktopcouch too
[03:06] <kenvandine> desktopcouch-service? or beam.smp?
[03:06] <rickspencer3> so certain apps, when they access gwibber preferences, cause the CPU to peg
[03:06] <rickspencer3> kenvandine, both
[03:06] <rickspencer3> all
[03:06] <rickspencer3> but the thing is, the apps that do this are different for different people
[03:06] <rickspencer3> IT MAKES NO SENSE
[03:06] <kenvandine> very weird
[03:06] <kenvandine> so if it is making gwibber-service spike
[03:06] <kenvandine> it must be changing records
[03:07] <kenvandine> otherwise gwibber would never even know it
[03:07] <rickspencer3> like something is listening for record changes?
[03:07] <kenvandine> but, gwibber-service does have "Monitors" setup for the dbs it cares about
[03:07] <kenvandine> yeah, so gwibber sees records added or updated as events
[03:08] <rickspencer3> and then gwibber writes records in response to these events, gets invoked, etc...?
[03:08] <kenvandine> but you are doing a get_record
[03:08] <kenvandine> no
[03:08] <kenvandine> gwibber sees something else writing to it
[03:08] <kenvandine> it wouldn't get an event for it at all if there aren't records changing
[03:08] <rickspencer3> my desktopcouch-se is just running one of my CPUs at 99%
[03:08] <kenvandine> which is weird
[03:08] <rickspencer3> for like the last 5 mins
[03:08] <rickspencer3> right
[03:08] <kenvandine> ok... well... that is familiar :)
[03:09] <kenvandine> is slip-cover still running?
[03:09] <rickspencer3> no
[03:09] <rickspencer3> gwibber though
[03:09] <kenvandine> i bet that is the same thing i was seeing
[03:09] <kenvandine> killall gwibber gwibber-service
[03:09] <rickspencer3> but I never saw this until I accesssed gwibberaccounts
[03:09] <kenvandine> which is weird
[03:10] <kenvandine> we need chad
[04:10] <rickspencer3> kenvandine, oh well, at least  you found that bug in DictionaryGrid for me
[04:10] <rickspencer3> was happy to fix that
[04:10] <rickspencer3> g'night
[04:10] <kenvandine> :/
[04:10] <kenvandine> good night
[04:10] <rickspencer3> kenvandine, we'll figure it out tomorrow
[04:10] <rickspencer3> the answer is staring you guys in the face, I am convinced
[04:11] <rickspencer3> a good night's sleep will prolly help ;)
[04:11] <kenvandine> :)
[07:34] <huats> morning
[07:38] <vuntz> huats: hello
[07:38] <huats> hello vuntz
[07:39] <vuntz> didrocks: any idea why simple-scan is at 0.9.10 in the ubuntu packages, but the latest tarball is 0.9.9?
[08:14] <didrocks> vuntz: robert_ancell probably forgot to create the milestone and upload the tarball. Do you want it? I can apt-get source and push it somewhere
[08:14] <didrocks> vuntz: that's why Quickly rules: it does it for you :p
[08:14] <didrocks> hey huats
[08:14] <huats> hello didrocks
[08:33] <vuntz> didrocks: better to annoy rob when he'll be here :-)
[08:33] <didrocks> vuntz: sure, do not hesitate :p
[08:57] <desrt> vuntz: hey
[08:57] <desrt> didrocks: hello
[08:57] <didrocks> hey desrt, quite late for you, isn't it?
[08:57] <desrt> can't sleep
[08:57] <didrocks> argh :/
[08:57] <desrt> didrocks: might i be able to harass you about some universe stuff?
[08:58] <didrocks> desrt: sure
[08:58] <desrt> normally i bother seb, but he's committed to vacationing today :)
[08:58] <desrt> two things:
[08:58] <didrocks> (yeah, it's a shame :))
[08:58] <desrt> 1) can you guys update to the freshly-released valac version?
[08:58] <desrt> (that's the easy one)
[08:59] <desrt> 2) http://packages.debian.org/source/sid/zeromq
[08:59] <desrt> (that's the hard one)
[09:00] <desrt> i'm not really familiar with how difficult it is to get new package into the archive this late in the cycle if they have upstream versions already existing in debian
[09:01] <didrocks> desrt: nothing too risky in the new vala release? ("Infer type arguments when calling generic methods." <- no impact?)
[09:01] <vuntz> didrocks: it's the stable release
[09:01] <didrocks> vuntz: ok, 0.7.10 isn't? it follows odd number == unstable too?
[09:01] <vuntz> so better to have a stable release than a development one, I'd say
[09:01] <didrocks> right
[09:01] <desrt> didrocks: no.  0.8.
[09:02] <desrt> quite freshly released
[09:02] <didrocks> desrt: yeah, I was asking if "0.7.10" (the current one we have) is unstable. Understood, will update :)
[09:02] <didrocks> for the new package
[09:02] <didrocks> it should be easy to get a Feature Freeze Exception
[09:02] <desrt> i don't think vala really follows the normal stable/unstable versioning scheme in a meaningful way
[09:03] <didrocks> desrt: care about opening a bug telling why this package is necessary? Then we will subscribe ubuntu-archive to get a grant
[09:03] <desrt> didrocks: i'm not sure it *is* necessary :)
[09:04] <desrt> but it seems like a relatively easy (and entirely zero-risk) inclusion
[09:04] <desrt> and there's a good chance that dconf will use it
[09:04] <didrocks> desrt: well, let's say "it's good to have and there is no risk"
[09:04] <didrocks> desrt: just open a bug stating that and I will subscribe to get the grant
[09:04] <desrt> ok.  cheers.
[09:04] <desrt> what do i file against, exactly?
[09:05] <didrocks> updating vala now
[09:05] <didrocks> desrt: ubuntu itself
[09:05] <desrt> ok
[09:09] <desrt> didrocks: what do you guess the chances are?
[09:09] <desrt> god i hate launchpad
[09:09] <desrt> every time i try and use it it's a timeout error :(
[09:13] <didrocks> desrt: for the new package? it's high has there is no impact on existing things
[09:14] <didrocks> desrt: but it will be treated probably after beta2 (next thursday)
[09:14] <desrt> of course
[09:15] <desrt> https://bugs.launchpad.net/ubuntu/+bug/553858
[09:15] <desrt> didrocks: thanks
[09:15] <didrocks> desrt: thanks, subscribing now :)
[09:16] <didrocks> I'm updating vala now and try to build something with it
[09:16] <didrocks> desrt: btw, do you know what's the best practice for vala is concerning upstream?
[09:16] <desrt> didrocks: the best test case for vala is vala itself :)
[09:16] <didrocks> I mean, I see some upstream generated the .c file in the tarball, and some not
[09:16] <desrt> didrocks: bugzilla
[09:16] <desrt> oh.  that.
[09:16] <desrt> the widely accepted practice is to have .c in the tarball
[09:17] <desrt> but not in git
[09:17] <didrocks> sure, only in the tarball
[09:17] <didrocks> ok, I'll track down upstreams which don't do that :)
[09:17] <desrt> well
[09:17] <desrt> there's nothing wrong with shipping tarballs without .c
[09:17] <desrt> it's just non-standard behaviour
[09:18] <didrocks> yeah, I mean, I guess that most of the time, they don't really know it's best for packagers
[09:18] <desrt> and everyone, really
[09:18] <desrt> note also: the automake vala rules do this automatically
[09:18] <desrt> add the .c files to the dist tarball
[09:19] <desrt> so the only time you'll encouter .vala-only is in cases were people have homebrew makefiles or have manually worked-around the standard automake behaviour
[09:19] <didrocks> desrt: oh, so they just don't include it
[09:19] <didrocks> right
[09:19] <desrt> if you're going to file bugs with upstreams it might be useful to point that out
[09:19] <desrt> the vala support came with automake version 1.11
[09:20] <didrocks> yeah, I note that down to be able to help upstream making this
[09:23]  * desrt plays with zeromq a bit as a sleep-deferal strategy :)
[09:25] <didrocks> heh :)
[09:26] <desrt> didrocks: thanks for the vala refresh and the zeromq sponsor
[09:26] <didrocks> desrt: y/w ;)
[09:27] <didrocks> desrt: note that the vala refresh, even in universe, should be pushed manually in the repo by an archive admin
[09:27] <didrocks> desrt: so, probably Monday or Tuesdsay with Easter week-end :)
[09:27] <didrocks> (beta freeze is no more a soft freeze, even for universe)
[09:28] <desrt> yes.  that's quite reasonable.
[10:10] <asac> what is needed to get auot login nowadays?
[10:11] <asac> is that gconf setting?
[10:11] <asac> didrocks: ^^
[10:11] <didrocks> asac: no, it's in /etc/gdm/custom.conf. One sec
[10:12] <asac> ok... thats enough info
[10:12] <didrocks> ok :)
[10:12] <asac> we just wondered if thats still it because it doesnt work here for someone
[10:12] <asac> ;)
[10:12] <asac> we will figure
[10:12] <didrocks> asac: hum, it should work :) the live system use that :)
[10:12] <didrocks> ok, good luck!
[10:12] <Nafai> Hi didrocks!
[10:12] <Nafai> <- can't sleep :)
[10:12] <asac> didrocks: yeah. you probably get a bug ;)
[10:13] <didrocks> hey Nafai, you should go to sleep :)
[10:13] <Nafai> I will go back in a bit
[10:13] <didrocks> asac: I'm sure you will file one and assigne to me :)
[10:13] <Nafai> rick mentioned yesterday that I should collaborate with you on UNE stuff
[10:13] <didrocks> Nafai: how was your first official day as Canonical employee? :)
[10:14] <Nafai> Good, just a lot of "meta" work (reading wiki, subscribing to mailing lists, etc)
[10:14] <didrocks> right, first days is that :)
[10:14] <asac> didrocks: seems he had wrong gnome session file for une
[10:14] <asac> didrocks: installed just ubuntu-netbook
[10:14] <asac> why doesnt that install the right one?
[10:15] <didrocks> asac: asac if you install  ubuntu-netbook, the session is set to une if no default session has been set previously
[10:15] <didrocks> asac: DefaultSession=gnome in custom.conf?
[10:15] <vish> hmm , is seb on vac today?
[10:15] <asac> didrocks: =une was in there
[10:16] <asac> just installed ubuntu-minimal ... then ubuntu-netbook
[10:16] <asac> then a few times worked and rebooted
[10:16] <asac> suddenly it was broken
[10:16] <didrocks> asac: hum, apart from the fact they he unlog, set a different one into gdm (and so populate .dmrc), I don't see what changed it
[10:16] <asac> let me ask
[10:17] <didrocks> vish: right, Lorraine and some countries are on national holidays today
[10:17] <asac> didrocks: ok. afte rinstallin ghtere was  no custom.conf
[10:17] <vish> oh , :(
[10:17] <asac> so he added that manually
[10:17] <vish> didrocks: thanks ..
[10:17] <asac> so guess was a user bug
[10:18] <didrocks> asac: yeah, no custom.conf is quite strange, let's blame the user :)
[10:18] <didrocks> vish: some for next Monday btw
[10:19] <fta> where are the keyboard layout options stored?
[10:19] <vish> didrocks: ah, ok.. do you have any info about the humanity update?  seb  was doing it last night , but it seems to have not landed..
[10:19] <asac> didrocks: whats the gnome-session file installed
[10:19] <asac> ?
[10:20] <didrocks> vish: he maybe pushed it but as we are in beta freeze, an archive admin has to accept it
[10:20] <vish> didrocks: ah , the admins .. thanks
[10:20] <didrocks> asac: gnome-session file? ~/.config/gnome-session or /etc/X11/Xsession.d/55gnome-session_gnomerc?
[10:21] <asac> didrocks: wasnt there a .desktop file?
[10:21] <didrocks> oh, the desktop file
[10:21] <didrocks> right, so, concerning session management
[10:21] <didrocks> you have .desktop file in /usr/share/xsessions/
[10:22] <fta> (n-m, gconf)
[10:22] <didrocks> gnome.desktop for the gnome session, you get the failsafe session and when installing une, you got the une.desktop file
[10:23] <didrocks> basically DefaultSession={name_of_the_file_without_extension}
[10:23] <asac> didrocks: yeah. thx. we have to check something here
[10:32] <didrocks> y/w
[10:36] <asac>   * debian/patches/70_glib2.0-gatomic-arm.patch:
[10:36] <asac>     - dropped since that patch was added without details nor reference
[10:36] <asac>       to a launchpad or upstream bug and it's not clear if it's still required
[10:36] <asac>       now with the change done upstream recently
[10:36] <asac> thats ANNOYING
[10:37] <asac> when seb comes back i will have to talk to him
[10:38] <asac> especially because HE added that patch on his own
[10:38] <asac> two uploads before
[10:39] <didrocks> asac: he will be there on Tuesday
[10:41] <asac> i know
[10:50] <asac> didrocks: what should be in custom.conf to start proper une?
[10:51] <asac> we get a full gnome + the launcher if we use une in there
[10:51] <asac> imo this feels not natural ;)
[10:52] <asac> ok we figured
[10:52] <didrocks> asac: just DefaultSession=une, but if user changed it, it's in .dmrc
[10:52] <asac> using une-efl seems to start full gnome + launcher
[10:52] <asac> why does it need to be like that?
[10:53] <asac> thats a bug i guess?
[10:53] <asac> e.g. using just une works
[10:53] <didrocks> asac: right, I told you that we should create a setting package
[10:53] <didrocks> asac: I pinged you and Jamie about it a while ago
[10:53] <asac> yeah sorry. long time ago that was ;)
[10:53] <didrocks> yeah :)
[10:54] <didrocks> asac: that can be easily done. I can have a look next week if you want. You want the same settings than une?
[10:55] <asac> didrocks: is there anything that strikes you that we wpuldnt want from the une setting
[10:55] <asac> ?
[10:56] <didrocks> asac: hum… we hide some items on the menu but it will make sense for you too… and now that go-home-applet is compatible, I don't see anything you won't want
[11:01] <asac> whats going on:
[11:01] <asac> "You are not the bug assignee nor the maintainer of glib2.0 (Ubuntu), and therefore cannot edit this bug's status. "
[11:01] <asac> core devs cant change bug status anymore?
[11:01] <asac> or is that because launchpad is currently read-only?
[11:05] <didrocks> asac: I guess it's a side effect about the read-only yeah
[11:08] <asac> hmm. its not coming back :(
[11:08] <asac> its supposed to be back since 10 minutes ;)
[11:08] <asac> oh its still one more hour
[11:15] <didrocks> yeah  :/
[12:54] <asac> anyone sees the searchplugin being amazon here?
[12:54] <asac> please test http://people.canonical.com/~asac/tmp/ubufox_0.9~rc1-0ubuntu1_all.deb
[12:54] <asac> to see if its fixed there
[12:59] <didrocks> asac: how can I reset to the default one to check if it's fixed?
[13:01] <chrisccoulson> didrocks - you could try a fresh profile in a guest session
[13:02] <didrocks> chrisccoulson: right, good idea, let's try this
[13:02] <chrisccoulson> didrocks - i tried it in french already :P
[13:02] <didrocks> oh ok, no need so :)
[13:02] <chrisccoulson> you can still test it ;)
[13:03] <didrocks> it's ok there :)
[13:03] <zyga> hello
[13:03] <chrisccoulson> asac - did you see the gnome-shell module proposal on desktop-devel-list?
[13:04] <chrisccoulson> they mentioned briefly about the dependency on spidermonkey, but nobody seems to think it's a real issue :/
[13:07] <asac> chrisccoulson: jump in there and say thats a dead end ;)
[13:07] <asac> one second
[13:08] <asac> let me see if i can find the bugzilla bug
[13:08] <chrisccoulson> asac - yeah, i think i will draft a response later, but i want to do it in a way that doesn't get me shot-down by everybody ;)
[13:11] <didrocks> chrisccoulson: spidermonkey is so bad?
[13:11] <chrisccoulson> didrocks - yes
[13:12] <chrisccoulson> didrocks - we're actively trying to reduce the number of dependencies on spidermonkey, to fit more with the new mozilla support model
[13:12] <asac> chrisccoulson: i need to find the upstream bug where they made it clear that they dont want to make any efforts to maintain a stable API even in securty updates
[13:13] <chrisccoulson> asac - ok, thanks, that would be interesting
[13:13] <didrocks> chrisccoulson: hum, right, that doesn't sound good at all
[13:13] <chrisccoulson> ^^^didrocks - asac's response summarizes quite well why we are doing this ;)
[13:13] <didrocks> chrisccoulson: yeah, I was at the UDS discussion about the new mozilla support model
[13:14] <chrisccoulson> didrocks - so, there is no guarantee of API stability even between minor versions, and consider that we are going to move to a model where we follow major updates throughout the life of a release....
[13:14] <didrocks> so, that's weird that they rely on a mozilla component
[13:14] <chrisccoulson> ....that would make something like gnome-shell unsupportable
[13:14] <didrocks> right
[13:15] <asac> mozilla bug 506890
[13:15] <asac> read that and there you go
[13:16] <asac> chrisccoulson: ^^
[13:16] <asac> reading this ... everyone using mozjs needs to go somewhere else
[13:16] <asac> if they ask "where?" ... i dont have an answer
[13:16] <asac> but the answer is definitly not "stay with mozjs"
[13:16] <asac> they should complain on that bugt
[13:17] <asac> maybe having upstreams complain that they wasted all their effort etc. will change their minds
[13:17] <chrisccoulson> asac - thanks, that's interesting to read
[13:17] <asac> i tried to discuss this in various ways
[13:17] <asac> distro pushing doesnt help
[13:17] <asac> only upstream folks going to that bug might help
[13:17] <asac> they should appeal to mozillas foundation approach ... e.g. they want to be the good guys and want to make the web a better place
[13:17] <asac> imo having a js lib is the way to go
[13:17] <asac> maybe if they notice how many folks they bust they will move a bit
[13:18] <asac> chrisccoulson: the folks commenting there are all senior ... VP etc.
[13:18] <asac> its not that its some random developers saying that
[13:18] <asac> its their official strategy in order to compete against chrome
[13:19] <asac> similar folks should go to chrome and tell them that v8 should become stable
[13:19] <asac> they have the same answer: "dont use us  .. we dont care if there is no other solution ... but its not us" ;)
[13:19] <zyga> asac: may I ask what are you talking about? js library?
[13:20] <asac> yes ...
[13:20] <asac> read above
[13:20] <asac> i think the right way would be someone coming up with a small subset of essential js funcs
[13:20] <asac> and then writing a wrapper for mozjs
[13:20] <zyga> I read but I'm a little puzzled, is the question about having a stable (api-wise) js library?
[13:20] <asac> that can be maintained in case they break api
[13:21] <asac> zyga: yes. if that exists now ( i think there was something for gnome now) ... thats the way to go
[13:21] <asac> we cant really let anything in the archive with a straight face that uses mozjs or v8
[13:21] <zyga> asac: what about jscore from webkit?
[13:22] <zyga> asac: it's not v8 but it's was good enough for a long while
[13:22] <asac> havent checked with them
[13:22] <asac> maybe thats a choice
[13:22] <asac> we should try
[13:22] <asac> but we should first check if its stable with them ;)
[13:22] <zyga> asac: what's the target for that library (I assume it's not a browser)
[13:22] <asac> desktop apps needing js
[13:22] <zyga> asac: I think that's your choice then
[13:22] <asac> everyone uses mozjs ... and complains that we dont make a system lib out of it (e.g. we make it intentionally hard to use it=)
[13:23] <asac> right. i think i pointed a few folks to webkit in the past
[13:23] <zyga> asac: what's the point with mozilla not willing to make it stable api-wise
[13:23] <zyga> (disregarding the fact that mozilla has horrible api that doesn't look like anything else)
[13:23] <asac> but then webkit has problems on its own wrt to stability/security updates from what i was told by security team
[13:23] <asac> zyga: go to that bug and complain
[13:23] <asac> i dont see it
[13:23] <asac> zyga: i tried to discuss a small subset api
[13:23] <asac> but they are not even willing to do that
[13:24] <zyga> asac: jscore is pretty small, do have a look at that
[13:24] <zyga> and it's pure C++
[13:24] <asac> e.g. i would be willing to do a separate source package ... with --build-stable-api-only
[13:24] <asac> if that option existed
[13:24] <zyga> no nifty quirky runtimes
[13:24] <asac> and mozjs developers thought it was a good eceision
[13:24] <asac> but hen that bug above made it clear that noone with seniority in mozilla wants that
[13:24] <zyga> asac: I think webkit is not going forward so rapidly and they don't put everything and the kitchen sink inside
[13:25] <asac> zyga: C++ APIs aren't really famous for its easy ABI stability ;)
[13:25] <zyga> mozilla is more like 'ooh, we have this shiny new js function'
[13:25] <zyga> asac: I know that C++ is not perfect but C++ WITH some klunker like Qt or mozilla code is worse than plain C++
[13:25] <asac> but all js solutions are C++ ... so we just need to find someone who says: yes, we have policy to maintain ABI/API stability for security/stability updates
[13:25] <zyga> asac: what about apple
[13:26] <zyga> asac: apple uses jscore for safari
[13:26] <asac> they use the full webkit stuff ... dont they?
[13:26] <zyga> asac: that sounds/smells/feels like 1) stable 2) maintained 3) secured
[13:26] <asac> imo they will be next feeling pressured to boost their performane most likekly
[13:26] <zyga> asac: yes
[13:26] <asac> with all browser having to catch up with chromium
[13:26] <zyga> asac: but the jscore is a part of the plaftorm (AFAIR, i'd need to check that)
[13:27] <zyga> so breaking the api is a no-no for them
[13:27] <asac> thats what make mozilla drop all this ... as they dont see competitive when they have to keep js api stable
[13:27] <asac> zyga: please check that
[13:27] <asac> zyga: also find whatelese is using htat in the platform
[13:27] <asac> if its just one or too rdepends its easy for them to just roll all at the same time
[13:27] <zyga> asac: I think lots
[13:27] <zyga> asac: basically apple commited to this by putting webkit in the official apis for everything
[13:28] <zyga> from iphone/ipad to the desktop
[13:28] <zyga> I'll try to give you a nice link, wait
[13:28] <fta> funny, if i open https://bugs.edge.launchpad.net/ubuntu/+source/xinit/+bug/320886 both in ff and ch, ff lacks the comments i made ~1h ago
[13:28] <asac> zyga: does jscore work on windows?
[13:28] <zyga> asac: yes
[13:29] <asac> stuff like couchdb need that etc.
[13:29] <zyga> asac: it's on safari for windows after all
[13:29] <asac> ydeah. anyway. i usuallypoint folks to webkit if they want something
[13:30] <asac> so i will just continue to do that ... cant be worse than mozjs
[13:30] <zyga> asac: it's better IMHO
[13:30] <asac> chrisccoulson: so everyone wanting to use mozjs should go jscore of webkit
[13:30] <zyga> mozilla has the momentum but webkit has the efficiency and focus on being slim
[13:30] <asac> otherwise they cant go in main ... and we will not export mozjs as system lib
[13:30] <asac> if they want mozjs they should complain on the upstream bug
[13:30] <asac> chrisccoulson: ^^
[13:31] <zyga> asac: http://webkit.org/projects/javascript/index.html
[13:31] <asac> kk
[13:32] <zyga> asac: jscore builds to a separate .so already
[13:32] <zyga> asac: so it's not really bound to webkit
[13:33] <zyga> asac: I'm not 100% up-to-date with this (I's 1.5 year old experience) but if you want to ship webcore + jscore (webkit) + some apps then you should not need to duplicate everything
[14:25] <baptistemm> someone can approve my mail in ubuntu-devel? thanks
[14:44] <didrocks> well, time for me to take an early week-end, taking the train to help my brother moving this week-end
[14:45] <didrocks> see you on Tuesday ;)
[14:47] <LaserJock> kenvandine: so are all the CPU-at-100% bugs supposed to be fixed for gwibber now?
[14:58] <kenvandine> LaserJock, no
[14:58] <kenvandine> :(
[14:58] <LaserJock> k
[15:28] <rickspencer3> kenvandine, hi
[15:29] <kenvandine> hey rickspencer3
[15:29] <kenvandine> hey seb128
[15:29] <rickspencer3> release meeting in 30 minutes, right?
[15:29] <seb128> hello kenvandine rickspencer3
[15:29] <seb128> how are things going today?
[15:29] <kenvandine> i think it is in an hour
[15:29] <kenvandine> i should check :)
[15:29] <seb128> I noticed none of the dx or ols went through
[15:29] <rickspencer3> kenvandine, let's ask for some help with this couch<->keyring<->gwibber bug
[15:30] <kenvandine> yeah
[15:30] <kenvandine>           value = gnomekeyring.find_items( gnomekeyring.ITEM_GENERIC_SECRET, {"id": str("%s/%s" % (account["_id"], key))})[0].secret
[15:30] <kenvandine> i replaces that with value = "mypassword"
[15:30] <kenvandine> and no load
[15:30] <kenvandine> i tried to get the debugger in there and failed
[15:30] <kenvandine> in python-gnomekeyring
[15:30] <seb128> do you get the bug using a small pygtk test too?
[15:30] <kenvandine> can't figure out where it is happening
[15:30] <seb128> or only in desktopcouch context?
[15:31] <rickspencer3> that's a good question
[15:31] <rickspencer3> hi seb128, btw
[15:31] <rickspencer3> ;)
[15:31] <kenvandine> no, but i can't see how this could be related to couch
[15:31] <rickspencer3> seb128, I tried to write a minimal repro script last night by calling desktopcouch
[15:31] <rickspencer3> sometimes is repro'd, sometimes not
[15:31] <kenvandine> and duplicating this would be a fair bit of code
[15:32] <kenvandine> rickspencer3, but we would want to something that uses threads the same way as gwibber-service
[15:32] <rickspencer3> kenvandine, but could we not write a program that ask the keyring for something
[15:32] <kenvandine> but without using desktopcouch
[15:32] <rickspencer3> like a 2 line python script
[15:32] <rickspencer3> see if that can trigger it
[15:32] <kenvandine> rickspencer3, that wouldn't break it
[15:32] <kenvandine> it is threading related
[15:32] <rickspencer3> so call it from a thread
[15:32] <rickspencer3> we need a reliable repro for this
[15:33] <rickspencer3> I can give that a shot
[15:33] <seb128> kenvandine, duplicating what?
[15:33] <kenvandine> there is no couch code at all in this part of gwibber
[15:33] <seb128> just write a few liners calling gnomekeyring.find_items
[15:33] <seb128> to see if python-gnomekeyring bugs
[15:33] <rickspencer3> seb128, I'll try now
[15:33] <kenvandine> we would need to do it with python multiprocessiing
[15:33] <seb128> if you think the issue is this call
[15:33] <kenvandine> calling it from a script is fine, gotta call it from a thread
[15:33] <rickspencer3> I can put it on a thread and do it in a loop on a thread or something
[15:33] <seb128> so it's a multuprocessing issue?
[15:34] <kenvandine> yes
[15:34] <seb128> urg
[15:34] <seb128> good luck with that
[15:34] <dobey> it's a thread locking issue
[15:34] <seb128> I'm not even sure gnome-keyring is meant to work in those case
[15:34] <kenvandine> dobey's work around was by using gtk.gdk.lock
[15:34] <seb128> lot of libs are not
[15:35] <dobey> the exact same keyring call works fine if i just do it directly in interactive python (without threads, just making the keyring calls)
[15:35] <kenvandine> and it is a real pain that i can't get any trace that shows keyring access at all
[15:35] <dobey> but inside threads, bam, lock.
[15:35] <dobey> at least, if there's a glib main loop
[15:35] <dobey> it's probably ok from a thread without a glib main loop
[15:35] <dobey> though i haven't tested it
[15:36] <dobey> kenvandine: what does the trace show? dbus junk?
[15:36] <rickspencer3> dobey, do you think you could write a minimal repro script?
[15:36] <kenvandine> mostly curl actually
[15:36] <kenvandine> dobey, but it doesn't show anything remotely keyring related, afaict
[15:37] <dobey> rickspencer3: probably, yes. shouldn't be hard
[15:37] <seb128> not sure if that's a keyring bug
[15:37] <kenvandine> seb128, chad has found a version of libgnome-keyring0 that he thinks works with desktopcouch
[15:38] <seb128> or a desktoptouch
[15:38] <kenvandine> but that version doesn't fix gwibber
[15:38] <kenvandine> but it does seem to fix desktopcouch
[15:38] <seb128> which one?
[15:38] <seb128> well
[15:38] <seb128> does the update from yesterday fix desktopcouch?
[15:38] <dobey> desktopcouch *might* just be getting lucky
[15:38] <kenvandine> 2.29.4git20100224-0ubuntu2
[15:38] <seb128> k
[15:38] <kenvandine> seb128, chad said it didn't
[15:38] <seb128> so it's the new codebase
[15:38] <seb128> not 2.28
[15:39] <seb128> the diff is not that much to review
[15:39] <dobey> because it has a weird function that does some main thread check thing
[15:39] <kenvandine> but that version is still broken for gwibber :/
[15:39] <dobey> and it could be that the keyring calls might just always end up being from the main thread anyway in some cases
[15:39] <dobey> which would mask the problem
[15:39] <seb128> good luck with that
[15:40] <dobey> alright, let me get fully awake in the next few minutes, and i'll write a simplified test case
[15:40] <seb128> dobey, do you think it's a keyring bug?
[15:41] <seb128> or it should just be used as it's used now?
[15:41] <dobey> seb128: i think a change to libgnome-keyring is exposing problems in existing code in apps using it
[15:41] <seb128> change = rewrite
[15:41] <seb128> 2.28 to 2.29 is basically a rewrite
[15:41] <seb128> gnome-keyring uses dbus now
[15:41] <dobey> seb128: mainly because threading in gtk+/glib is insane
[15:42] <seb128> the lib is just a wrapper for compatibility
[15:42] <dobey> if people don't get it right
[15:42] <kenvandine> dobey do you think we should be looking at python-gnomekeyring instead of libgnome-keyring0?
[15:42] <dobey> kenvandine: no
[15:43] <kenvandine> ok
[15:44] <dobey> although, i don't think any minor change is going to fix the problem either, if it's switched to using dbus-glib
[15:44] <dobey> and it sems it has, which is the cause of all these problems
[15:45] <seb128> it seems to use libdbus rather
[15:45] <seb128> but as said before yes that's new
[15:45] <seb128> it used to use sockets
[15:45] <seb128> and it's using dbus since this cycle
[15:48] <kenvandine> i love the beta-2 burndown :)
[15:48] <kenvandine> way below the line :)
[15:49] <dobey> heh
[15:50] <dobey> eh, dbus is just an abstraction over sockets
[15:50] <dobey> anyway, let me write simple test cases
[15:52] <seb128> bbl
[16:24] <dobey> huh
[16:24] <dobey> wtf :)
[16:25] <dobey> i wonder if i somehow installed a keyring update that works now
[16:27] <kenvandine> ha
[16:28] <kenvandine> dobey, seb128 did upload another patch that did fix it for gvfs yesterday
[16:28] <dobey> HA!
[16:28] <kenvandine> but not for gwibber :)
[16:28] <dobey> bad gwibber!
[16:29] <dobey> class Dispatcher(dbus.service.Object, threading.Thread):
[16:29] <dobey> formula for BOOM
[16:29] <kenvandine> ?
[16:29] <dobey> it's mixing up main loop and thread interaction all over the dispatcher
[16:30] <rickspencer3> dobey, could I ask you to log a bug on that and briefly describe why it's bad a potential work around?
[16:30] <rickspencer3> and dobey, do you think such a thing could be implicated in the 100% bug?
[16:30] <kenvandine> or comment on bug 554005
[16:30] <dobey> rickspencer3: yes, this definitely could cause threadlocks
[16:30] <rickspencer3> yeah, that's better
[16:33] <dobey> hmm
[16:36] <dobey> kenvandine: how do i run tests in gwibber source?
[16:36] <kenvandine> tests...
[16:36] <kenvandine> we need a test suite :/
[16:36] <kenvandine> that is on my todo list for next cycle
[16:37] <dobey> ok
[16:37] <kenvandine> gwibber desparately needs it
[16:37] <dobey> i think i have a proper fix
[16:37] <dobey> i'll push and you can try
[16:37] <kenvandine> woot
[16:37]  * kenvandine waits to hug dobey...
[16:39] <dobey> kenvandine: merge lp:~dobey/gwibber/gwibber-keyring-unthreaded and see if it's fixed for you
[16:39]  * dobey thinks it should be
[16:40] <Nafai> morning all
[16:40] <kenvandine> dobey, ok... i just tried nearly the same thing and it didn't fix it
[16:41] <kenvandine> i didn't do this
[16:41] <kenvandine> -gobject.threads_init()
[16:41] <dobey> kenvandine: well is it fixed? i ran gwibber-service from my tree and it wasn't eating any cpu, but i don't know if that's because it fixes it or because i don't have anything in the keyring
[16:41] <rickspencer3> hi Nafai
[16:42] <dobey> kenvandine: but desktopcouch-service was grinding my cpu hard
[16:42] <rickspencer3> Nafai, should be a quiet day today, because lot so euro-folks are on holiday
[16:42]  * Nafai nods
[16:43] <Nafai> I talked with didrocks for a moment in the night when I had a bit of a "I can't sleep" moment, we're going to sync up on Tuesday
[16:43] <rickspencer3> Nafai, awesome
[16:43] <rickspencer3> Nafai, apparently Dx has a bug with keyboard access for indicators
[16:43] <rickspencer3> maybe you could ask if they need some help with that?
[16:44] <Nafai> Sure thing
[16:44] <rickspencer3> apparantly if you key into an indicator, and then hit escape, you are rather screwed
[16:44]  * Nafai heads over to #ayatana
[16:44] <rickspencer3> I really want good key access for indicators in Lucid ;)
[16:45] <dobey> kenvandine: did my branch fix it? :)
[16:45] <kenvandine> dobey, it seems fixed!
[16:45] <dobey> yay me!
[16:45] <kenvandine> sorry, busy in release meeting too :)
[16:45] <kenvandine> yay dobey
[16:45]  * kenvandine hugs dobey
[16:45] <kenvandine> let me test a bit before i upload
[16:45] <dobey> kenvandine: tell them to put the new ubuntuone-client in the archive :)
[16:46] <dobey> kenvandine: one second, and i'll re-submit my merge proposal :)
[16:54] <dobey> kenvandine: https://code.edge.launchpad.net/~dobey/gwibber/gwibber-keyring-unthreaded/+merge/22704
[16:54] <kenvandine> thx dobey
[16:54] <kenvandine> dobey, he said he would look at u1 client later today
[16:54] <dobey> yay
[16:54] <dobey> and now, for some lunch :)
[16:54] <kenvandine> dobey, no code change in that merge proposal, right?
[16:55] <dobey> kenvandine: hrmm? that proposal is for the branch i just had you test
[16:55] <kenvandine> ok
[16:55] <kenvandine> just checking
[16:55] <dobey> so it removes the threading from Dispatcher, yes :)
[16:56] <dobey> unless i'm confused and you're asking about u1-client package or something
[17:35] <fta> is there a way to unlock the keyring permanently? i mean, for a home desktop in autologin mode, there's no point in asking a password to start evolution
[17:45] <tgpraveen1> fta: only way is to set blank password for it or something like that iirc
[17:49] <fta> well, it's worked on my previous desktop, but in my fresh install of lucid, i can't find where it's supposed to be done
[17:49] <fta> -'s
[17:59] <Nafai> rickspencer3: looks like they have a fix in the works, do you have any other high priority things I should look at today?
[18:06] <tgpraveen1> fta: previous desktop was pre karmic? it used to work for me alos back then
[18:06] <tgpraveen1> though i dont know how. if you ever do get a fix for this pls do tell me
[18:14] <seb128> rickspencer3, hey
[18:14] <seb128> rickspencer3, why did you reopen the libgnome-keyring bug?
[18:15]  * Nafai takes an early lunch
[18:15] <rickspencer3> seb128, because gwibber was still busted and we needed on for the release meeting
[18:15] <seb128> k
[18:15] <rickspencer3> seb128, you can change it back though
[18:15] <seb128> can we get an another bug?
[18:15] <rickspencer3> seb128, I already did that
[18:15] <seb128> I feel we are mixing issues in the same bug
[18:15] <rickspencer3> seb128, yes
[18:15] <seb128> which makes things harder to work on an track
[18:15] <rickspencer3> I just haven't set the keryring back to fix-released yet
[18:16] <seb128> ok good
[18:16] <rickspencer3> but we've opened a new bug and, etc
[18:16] <seb128> I was just going to hint we should open a new bug
[18:16] <seb128> rather than keep using this one
[18:16] <seb128> excellent
[18:16] <seb128> thanks
[18:16] <seb128> did you get a testcase while I was not there?
[18:17] <seb128> or did you make any progress on the issue
[18:18] <kenvandine> we have a branch of gwibber that stops using threads in the dispatcher
[18:18] <kenvandine> which fixes the load problem... but breaks something else
[18:19] <dobey> hrmm
[18:20] <dobey> kenvandine: does it break something, or are other issues just more apparent now?
[18:21] <kenvandine> no, it breaks functionality
[18:21] <kenvandine> loading_complete seems to never get called
[18:21] <kenvandine> which is from the timeout_add
[18:22] <dobey> i think it's another thread vs. mainloop issue
[18:23] <dobey> but i don't really see from reading the code, how it ever would have worked :)
[18:24] <kenvandine> it worked fine :)
[18:24] <kenvandine> and it still works fine if i add the gobject.threads_init() back
[18:24] <kenvandine> but of course then i get the lock
[18:26] <rickspencer3> Nafai, sort of
[18:26] <rickspencer3> Nafai, https://launchpad.net/bugs/357673
[18:26] <rickspencer3> the deal here is that this is fixed in the kernel, but not on the desktop
[18:26] <dobey> kenvandine: how can it work fine if it's using 100% cpu and thread locked? :)
[18:27] <kenvandine> dobey, it still works... just makes my laptop very hot :)
[18:27] <rickspencer3> if you could look into this and at least see where the fix needs to be made, that would be helpful
[18:28] <rickspencer3> Nafai, this one looks rather harmful for certain users as well:
[18:28] <rickspencer3> https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/548891
[18:28] <dobey> kenvandine: weird
[18:28] <dobey> kenvandine: but it clearly marks this as another thread vs. mainloop issues
[18:28] <kenvandine> yes
[18:28] <dobey> and i really have no idea how it actually managed to work in the first place :)
[18:38] <robbiew> seb128: ping
[18:41] <robbiew> can anyone tell me how to change the background of the login screen?  I apparently did for Karmic, and cannot UNDO for Lucid :/
[18:42] <jcastro> I have a machine that updated to lucid but is still stuck with the karmic wallpaper in gdm so I would like to know how to do that too
[18:44] <seb128> robbiew, sudo -u gdm gnome-appearance-properties or gconf-editor
[18:45] <seb128> robbiew, you can also remove .gconf in /var/lib/gdm
[18:45] <robbiew> thnx
[18:45] <seb128> you're welcome
[20:04] <Nafai> back :)
[20:08] <rickspencer3> hey Nafai
[20:08] <rickspencer3> wb
[20:08] <Nafai> thanks
[20:09] <Nafai> I saw the two bugs you shared after I stepped away
[20:10] <Nafai> Of course the thinkpad one isn't exhibited on *my* Thinkpad :)
[20:13] <rickspencer3> bummer
[20:14] <rickspencer3> Nafai, so when you use hardware buttons to control volume, you get notifications?
[20:14] <Nafai> Yeah
[20:14] <rickspencer3> *sigh*
[20:14] <Nafai> I have a T-61p, which might have a better ACPI implementation
[20:14] <rickspencer3> ok, what about the no keyboard for gdm in kvm one?
[20:14] <rickspencer3> can you repro that?
[20:15]  * Nafai looks
[20:16] <Nafai> I can install VMware and try if you like
[20:27] <rickspencer3> Nafai, well, what else is on your list?
[20:28] <Nafai> other than a rhythmbox bug that MacSlow says he is looking at a potential notify-osd fix for, not mcuh really
[20:28] <rickspencer3> then ya', it would be helpful to get kvm set up and see if you can repro that bug
[20:29] <rickspencer3> also, kenvandine can probably use some help testing gwibber and related fixes
[20:29] <Nafai> ok
[20:29] <kenvandine> :)
[20:29] <kenvandine> Nafai, you a python threading guru by chance?
[20:32] <Nafai> kenvandine: not really, but I'm good enough at Python to take a stab. :)  All concurrency I've done in Python has been asynchronous with Twisted or glib :)
[20:37] <kenvandine> Nafai, if you don't mind, take a look at this
[20:37] <kenvandine> https://code.edge.launchpad.net/~dobey/gwibber/gwibber-keyring-unthreaded/+merge/22704
[20:38] <Nafai> sure
[20:38] <kenvandine> it is to deal with threadlock and the keyring
[20:38] <dobey> hmm
[20:39] <kenvandine> problem is... removing the gobject.threads_init() means it never calls the callback on complete
[20:39] <dobey> kenvandine: do i need to help fix the other issues too?
[20:39] <kenvandine> so anything that depends on that, is busted
[20:39] <kenvandine> but it fixes other issues
[20:39] <kenvandine> dobey, if you can figure out why that callback never gets called :)
[20:39] <kenvandine> that is the only real issue
[20:39] <dobey> because it's being called from a thread
[20:40] <kenvandine> so?
[20:40] <kenvandine> the threads complete
[20:40] <kenvandine> all the individual operations complete
[20:40] <dobey> so it's calling something that doesn't exist on that thread
[20:40] <kenvandine> humm
[20:40] <kenvandine> well... this is the weirdest part
[20:41] <kenvandine> when the next scheduled refresh starts, the first thing that happens is loading_complete gets called
[20:41] <kenvandine> it's like waiting
[20:45] <Nafai> btw, does anyone have a recommendation for a good netbook?  I'm considering buying one.  My wife has an Acer Aspire one that I feel is a little flimsy, so I'd like other options
[20:55] <kenvandine> Nafai, i don't
[20:55] <kenvandine> ok... i might have fixed gwibber now
[20:55] <Nafai> Yay
[20:56] <Nafai> I've just been looking at the API docs for this stuff :)
[20:56] <Nafai> I've got a ton to learn
[20:56] <kenvandine> threading.Thread.__init__(self, target=loop)
[20:56] <kenvandine> setting the mainloop there in MapAsync seems to do the trick
[20:56] <Nafai> let me know if you need me to test
[20:56] <kenvandine> the is no end to the google search results for people complaining about problems with threading in python :)
[20:56] <kenvandine> Nafai, thx
[20:57] <LaserJock> Nafai: my only netbook is a AA1, which I like, maybe you need an iPad :-)
[20:57] <Nafai> LaserJock: haha
[20:57] <Nafai> Now I wouldn't mind a tablet for web surfing and games, since my laptop doesn't leave the office now its primary function is work.  But...no thanks.
[20:58] <LaserJock> I just tried out Gmail's tablet UI, it might not be so bad
[20:58] <Nafai> yeah, I saw some screenshots
[20:58] <LaserJock> but I would require a terminal and that's where I think the iPad and I would part ways
[20:58] <Nafai> probably
[20:59] <Nafai> and I couldn't easily run Emacs on it, either :)
[20:59] <LaserJock> hmm
[20:59] <LaserJock> emacs doesn't run "easily" on a lot of things I use
[20:59] <LaserJock> but when you get the OS loaded initially it seems to go ok ;-)
[21:00] <kenvandine> dobey, mind reviewing my fix?
[21:01] <dobey> kenvandine: which one?
[21:01] <Nafai> I had it running on my G1 in a Debian chroot
[21:01] <Nafai> that was interesting :)
[21:01] <dobey> hrmm
[21:02] <kenvandine> threading.Thread.__init__(self, target=loop)
[21:02] <kenvandine> is the gist of it
[21:02] <kenvandine> in class MapAsync
[21:02] <kenvandine> setting it to use the same mainloop
[21:02] <kenvandine> dobey, that is on top of your branch
[21:04] <dobey> kenvandine: MapAsync doesn't have a loop argument
[21:04] <dobey> kenvandine: url to your diff? :)
[21:04] <kenvandine> it does now :)
[21:04] <kenvandine> one sec
[21:06] <kenvandine> http://pastebin.ubuntu.com/408282/
[21:06] <kenvandine> dobey, ^^
[21:06] <rickspencer3> Nafai, netbook = Dell mini 10v
[21:06] <rickspencer3> the "v" is important
[21:06] <Nafai> I seem to remember you saying you had wireless problems...is that because you got the non-v?
[21:06] <rickspencer3> Nafai, when you run gwibber, do you get your CPU pegged at 100% sometimes?
[21:07] <dobey> kenvandine: also i don't think that works how one expects it to
[21:07] <dobey> kenvandine: i'm surprised that works...
[21:07] <kenvandine> why?
[21:07] <kenvandine> you didn't think this could have worked before :)
[21:07] <dobey> grr, pydoc docs suck.
[21:08] <dobey> well, at this point i am just classifying gwibber code as 'magic' :)
[21:08] <Nafai> rickspencer3: I haven't noticed because the last time I ran gwibber it was crashing on me with some desktopcouch error and I seem to remember you guys talking about it, so I haven't tried it
[21:08] <Nafai> dobey: Usually that's the case when you use threads :)
[21:08] <rickspencer3> Nafai, so do a distupgrade
[21:08] <rickspencer3> the crashers should be fixed
[21:08] <dobey> Nafai: no no. i ♥ threads
[21:08] <dobey> Nafai: and i still think gwibber is magic :)
[21:09] <Nafai> yeah, I just re-launched after this morning's upgrade and it launched fine, no CPU pegging yet
[21:09] <Nafai> dobey: async :)
[21:09] <rickspencer3> but kenvandine and dobey are trouble shooting a threading bug, and if you can repro it, I'd like you to help with testing
[21:09] <dobey> target is the callable object to be invoked by the run() method. Defaults to None, meaning nothing is called.
[21:09] <dobey> kenvandine: ^ that's why i am amazed that works
[21:09] <kenvandine> ok... so this re-introduced the CPU load problem :)
[21:09] <rickspencer3> Nafai, ok .. then please do this:
[21:09] <kenvandine> humm... that isn't what i read
[21:09] <rickspencer3> 1. go to your gwibber settings
[21:09] <rickspencer3> 2. pick identical
[21:09] <kenvandine> but now it works again as expected with plaintext passwords
[21:10] <rickspencer3> 3. change the password, then change it right back to the right one
[21:10] <rickspencer3> 4. click save
[21:10] <dobey> kenvandine: so your fix brought the cpu usage back? :)
[21:10] <rickspencer3> then reboot and see if you get the pegging problem
[21:10] <dobey> hah
[21:10] <kenvandine> yup :)
[21:10] <kenvandine> damn
[21:10] <kenvandine> but now the operations complete :)
[21:10] <kenvandine> shit!
[21:10]  * kenvandine is getting frustrated!
[21:10] <rickspencer3> kenvandine, I can see that you are close
[21:11] <kenvandine> dobey, but without that, even not using the keyring it never called loading_complete
[21:11] <dobey> kenvandine: haha, thraedlocks ftf
[21:11] <rickspencer3> I'm guess there is just a tad more complexity and you just have a bit more to tease out
[21:11] <dobey> ok, let me poke at the code
[21:11] <kenvandine> and google is no help... full of people having the same problems and no solutions
[21:11] <kenvandine> dobey, thx!
[21:11] <kenvandine> dobey, you clearly understand this way better than me :)
[21:13] <dobey> kenvandine: at some point in time, i made it a point to try and understand threads + glib/gtk+ :)
[21:13] <Nafai> ok, I'm getting the CPU pegging when I added my identi.ca account :)
[21:13] <kenvandine> Nafai, yay!
[21:13] <kenvandine> now hang tight to test fixes :)
[21:13] <Nafai> sure thing
[21:13] <kenvandine> or poke at code to make it not suck... your choice
[21:13] <kenvandine> :)
[21:14] <kenvandine> but i think dobey will fix it before we could :)
[21:14] <kenvandine> dobey, from what i have found on google... not many people understand this, at least in python
[21:15] <Nafai> yeah, probably
[21:15] <dobey> kenvandine: most people don't understand it in C either
[21:16] <Nafai> rickspencer3: so the 10v isn't available any more, supposedly the current mini 10 supercedes it.  what was the reason for the "v"?
[21:16] <jcastro> you want the v if it's a 10
[21:16] <jcastro> the normal 10 was pulsbo
[21:16] <kenvandine> dobey, your right, clearly target= is wrong
[21:16] <jcastro> you want a mini 1012 if you want a dell
[21:16] <kenvandine> bad google juice there
[21:17] <jcastro> Nafai: just make sure it doesn't have a GMA500.
[21:17] <dobey> kenvandine: yeah, and calling mainloop.run() on a running mainloop isn't going to be useful
[21:17] <dobey> GMA500 is the debil
[21:17] <jcastro> Nafai: ime the hp mini's have better keyboards, and I find the touchpad on the dell netbook basically unusable
[21:18] <dobey> at least not from another thread
[21:18] <Nafai> jcastro: oh, I do remember playing with an HP, the keyboard did seem nice
[21:19] <rickspencer3> jcastro, the touchpads on the Dell mini's were fixed by tsleliot like 6 months ago
[21:19] <rickspencer3> they work quite fine now
[21:19] <jcastro> rickspencer3: I have a problem with it even after the fix, I think it's just the built in buttons don't jive with me
[21:19] <rickspencer3> meh
[21:20] <rickspencer3> they work find
[21:20] <rickspencer3> fine, even
[21:20] <rickspencer3> though if you can't get the "v", there's nothing to discuss
[21:20] <rickspencer3> you don't want poulsbo graphics :(
[21:20] <Nafai> It says it has an Intel NM10 Express graphics card
[21:21] <rickspencer3> Dell is quite supportive of Ubuntu and FOSS, so I default to them
[21:21] <jcastro> the mini 1012 has all the new pinetrail hotness, but they don't offer that on their ubuntu store yet
[21:21] <Nafai> yeah, the one I'm looking at comes with XP
[21:22] <dobey> i wish fujitsu would make a new U without gma500
[21:22] <jcastro> Nafai: when you decide on one lmk, I am looking for an ubuntu netbook for my dad
[21:22] <Nafai> sure thing
[21:22] <jcastro> but I am waiting on dell to refresh their options.
[21:23] <Nafai> I might be until after UDS, though I'll probably wish it was before when I get there :)
[21:23] <LaserJock> you should get one with Windows 7 on it, it makes you appreciate Ubuntu that much more ;-)
[21:24] <Nafai> :)
[21:24] <LaserJock> I spent hours and hours and hours on mine just to get iTunes set up, I can't believe they actually sell that stuff
[21:24] <rickspencer3> Nafai, are you getting the Gwibber 100% bug?
[21:25] <Nafai> yeah, I was until I quit gwibber :)
[21:25] <kenvandine> LaserJock, :-D
[21:26] <dobey> ugh, reading python modules written in C that wrap C libs hurts
[21:28] <Nafai> dobey: too much refs and unrefs and the like?
[21:28] <dobey> Nafai: too many weird line breaks and the like
[21:28] <dobey> and all the weird PyExc names and stuff
[21:28] <Nafai> ah
[21:28] <Nafai> I wish there was a decent FFI that was used more
[21:29] <Nafai> One thing I like about Haskell.  You wrap C code by written Haskell code
[21:30] <dobey> heh
[21:31] <vish> hmm , this README needs to be removed/modified : /usr/share/notify-osd/icons/hicolor/scalable/status/README
[21:31] <dobey> hrmm
[21:31] <dobey> i think i might need to call C from python
[21:32] <vish> iirc it was either pitti or macslow who made the last upload
[21:38] <dobey> where the heck is glib.threads_init even defined
[21:38] <dobey> grr
[21:40] <dobey> kenvandine: so this sucks
[21:41] <dobey> kenvandine: so i think the 'correct' answer here, is that we need to make a fairly large fix to pygobject :(
[21:41] <kenvandine> :/
[21:42] <dobey> kenvandine: because it doesn't currently wrap gthread.[ch], except for calling g_thread_init() for threads_init()
[21:42] <dobey> kenvandine: and all the mutex stuff is in there
[21:43] <kenvandine> that sounds sub-optimal... and like fixing that would be useful
[21:43] <kenvandine> but yikes!
[21:44] <dobey> yeah
[21:45] <dobey> kenvandine: we might be able to use ctypes to load libgthread and map/call a few methods that we need, as an interim fix though
[21:48] <kenvandine> all this to store passwords in the keyring :)
[21:48] <dobey> no
[21:48] <dobey> the keyring thing is just a little bump. i don't know how gwibber wasn't already having these problems
[21:49] <dobey> i think it was but nobody noticed them until now :)
[21:49] <kenvandine> without the call to gnomekeyring.find_items_sync, everything is fine
[21:51] <dobey> for different perceptions of fine i guess :)
[21:51] <kenvandine> hehe... well it all worked with no CPU load problems... but was insecure, sure
[21:53] <dobey> i mean, i am surprised that it would have worked without threadlocking
[21:55] <dobey> and desktopcouch threadlocks for me still
[21:56] <kenvandine> yeah, chad has found an older version of libgnome-keyring0 that doesn't cause that
[21:56] <kenvandine> 2.29.4git20100224-0ubuntu2
[21:56] <kenvandine> that is the last version that didn't expose this
[21:57] <kenvandine> but, that version doesn't fix gwibber
[21:57] <dobey> well it's weird, because i wrote a test script with the intention of locking up
[21:57] <dobey> and it runs just fine :(
[21:57] <kenvandine> :(
[21:58] <dobey>     Thread(target=get_kr_entries).start()
[21:58] <dobey> all that does is find_items_sync() and return them
[21:58] <dobey> and it succeeds
[22:06] <kenvandine> dobey, so you think those are the two possible fixes? fix pygobject or map the C methods ourself in gwibber?
[22:11] <dobey> yes
[22:12] <dobey> so i've got myself a threadlock now in a simple test
[22:14] <dobey> hmm
[22:21] <dobey> kenvandine: http://pastebin.ubuntu.com/408313/
[22:47] <dobey> kenvandine: or the other option is to just remove all the threading stuff, and use objects/signals instead
[22:48] <dobey> kenvandine: and just make it async
[22:48] <dobey> which it should probably do anyway. dispatcher.py frightens me :)
[22:49] <rickspencer3> signals ftw
[22:59] <dobey> later, gotta get away from the computer :)
[23:01] <rickspencer3> bye dobey