[08:23] <duanedesign> bug 537610
[08:26] <duanedesign> bug 537282
[09:35] <duanedesign> hello rye. Have a good weekend?
[09:35] <duanedesign> d'oh
[10:41] <duanedesign> connection giving you a hard time this morning rye ?  :)
[10:42] <rye> duanedesign, well, at first I was logged inv via ipv4, my router forgot that it has ipv6 link - reconnected. Then the power went off - router rebooted and forgot about ipv6 again (i.e. No route o_O).
[10:43] <rye> and I am not good at kernel debugging, especially if it is 2.4 :)
[10:43] <duanedesign> heh, right
[10:44] <rye> duanedesign, you know why there are no that much bug reports now?
[10:44] <duanedesign> hope you had a good weekend. Uneventful here, but sometimes thats nice
[10:44] <rye> duanedesign, bug #538097 :)
[10:44] <duanedesign> rye: i thought it strange that there have been no new reports in a few days
[10:44] <duanedesign> ugh
[10:45] <rye> yup
[10:46] <duanedesign> i had two that i was looking at that i was gonna ask if you had seen before....
[10:47] <duanedesign> bug 537610
[10:47] <duanedesign> i think the title might be decieving. There is another error in the log as well
[10:47] <rye> duanedesign, you might now that better- if the package says Fix Released for a package but one build (i386) failed - should I file a new bug report or reply to existing one?
[10:48] <rye> duanedesign - yes, I am checking that now - it looks like I have got this as well, but ignored for some strange reason thinking that my system is somehow biased
[10:48] <duanedesign> rye: yes there are a couple with that error
[10:50] <duanedesign> rye: i asked about the build failed question in #ubuntu-bugs to be certain.
[10:50] <rye> duanedesign,  thanks!
[11:20] <rye> duanedesign, hm, are launchpad-gm-scripts working for you?
[11:25] <duanedesign> rye: i was having trouble with the 'add tag' feature, but other than that yes
[11:25] <rye> hmm..
[11:25] <duanedesign> rye: are they not working at all?
[11:25] <rye> duanedesign, here - nope... Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2) Gecko/20100308 Ubuntu/10.04 (lucid) Firefox/3.6
[12:24] <pfibiger`> muffinresearch: ping
[12:24] <muffinresearch> pfibiger`: hi
[13:35] <oly> hi guys are there any known problems with notes currently on ubuntu one ?
[13:36] <oly> I have not been able to access the notes tab in the interface for around a week now
[13:36] <beuno> oly, a week sounds like a lot
[13:37] <oly> yeah hence why i am asking
[13:37] <beuno> oly, do you get oopses?
[13:37] <oly> i only have one note with a single link in it
[13:37] <oly> yep one sec
[13:37] <oly> OOPS-ID-1535appserver59000
[13:38] <beuno> oly, you got that one just now?
[13:38] <oly> yes, i just this second went to the webpage and pasted it here
[13:38] <beuno> rye, pfibiger, ^
[13:39] <beuno> pfibiger, are oopses accesible yet?
[13:40] <oly> not a great loss, although the link would be handy at some point was kind of waiting figuring it will be sorted soon
[13:40] <pfibiger> beuno: yes, but not at that url. we maybe have seen some still missing, but the major culprit of losing oopses has been fixed.
[13:40] <pfibiger> it ought be on buffaloberry within an hour, or early if manually synced.
[13:41] <beuno> pfibiger, an hour sounds too long to debug on IRC  :)
[13:41] <beuno> pfibiger, launchpad syncs them within minutes
[13:42] <oly> well there are probably others oops, as i have tried a few times to access the notes tab
[13:51] <rye_> great, my mission-control-5 segfaults  on a netbook
[13:52] <rye_> sometimes
[14:19] <rye_> alevine, hi, so, is desktopcouch replication working for you now?
[14:20] <rye_> i.e. has anything changed?
[14:22] <alevine> rye_, everything seems to be "working" fine. let me take a look if I still don't have a notes db
[14:22] <alevine> by working I mean I can synchronize notes
[14:23] <alevine> rye, still just have users and management dbs in couch
[14:33] <rye_> duanedesign, btw, default upload/download rate should be 2Mbit
[14:33]  * rye_ is reading backlogs to find alevine's log
[14:34] <rye_> alevine, could you please try restarting desktopcouch service (I fail to remember whether I asked you to do that or not) from the terminal
[14:35] <alevine> rye_, I think you did ask me, and it didn't make a difference. but can you remind me how to restart desktopcouch?
[14:36] <rye_> alevine, python /usr/lib/desktopcouch/desktopcouch-stop
[14:36] <rye_> alecu, then killall desktopcouch-service
[14:36] <rye_> alevine, ^ ( alecu, sorry :) )
[14:36] <rye_> alevine, afterwards, from the terminal - /usr/lib/desktopcouch/desktopcouch-service
[14:38] <rye_> alevine, if that prints something - could you please paste it to some pastebin. If it does not, then filing a private bug against desktopcouch with desktopcouch-replication log attached might help
[14:38] <alevine> rye_, stopping works. When starting: RuntimeError: Unable to find file descriptors in /proc
[14:38] <rye_> hm, I wonder whether attachments from private bug reports are inaccessible ...
[14:38] <alevine> do I need to sudo?
[14:38] <rye_> alevine, as, I start to remember, yeah - the regexp
[14:39] <rye_> alecu, no, desktopcouch runs as a local user, are you running it via sudo?
[14:39] <alevine> no I did not
[14:39] <rye_> alevine, ok, then summoning desktopcouch team...
[14:39]  * rye_ summons thisfred_ CardinalFang 
[14:40] <thisfred_> ohai
[14:40]  * CardinalFang arrives in a puff of smoke.
[14:41] <rye_> thisfred_, hi, question - desktopcouch fails to find listening port. Even while I was a Perl programmer, it takes a while to find out what that regexp for proc file means
[14:41] <thisfred_> sounds like a job for: SuperCardinalFang! :)
[14:41] <rye_> alevine, could you please find out the pid of beam.smp / beam of couchdb that is running the desktopcouch database?
[14:41] <thisfred_> (I know very little about the actual desktop parts of desktopcouch)
[14:42] <alevine> rye_, 5551
[14:42] <alevine> i assume you want me to do something with that now :)
[14:42] <rye_> alevine, ok, now could you please post the contents of /proc/5551/net/tcp to pastebin
[14:43] <rye_> alevine, I have definitely asked you to do that in the past, but testing how pastebin can take data is also good :)
[14:43] <alevine> rye_, http://pastebin.com/jDDen1Uu
[14:43] <rye_> alevine, and the log file for our past talk is buried somewhere in irclogs
[14:43] <CardinalFang> rye, Hrm, send me the contents of your running couchdb's  /proc/NNN/net/tcp .
[14:44] <rye_> CardinalFang, this is affecting alevine, and his proc/tcp entries are here - http://pastebin.com/jDDen1Uu
[14:46] <rye_> ok, me is returning to the base, see you as a normal 'rye'
[14:48] <CardinalFang> alevine, Hi.  Paste the contents of "ls -l /proc/5551/fd" in a pastebin also, please.
[14:49] <alevine> CardinalFang, http://pastebin.com/wFyk9rXu
[14:50] <CardinalFang> alecu, so the first is 'desktopcouch-service' and the second is a 'beam.smp' or 'beam'?
[14:51] <alecu> CardinalFang, I'm sure you mean "alevine", right?
[14:51] <alevine> alecu, you must hate me :)
[14:51] <CardinalFang> alecu, and figure out why your IRC cleint thinks your name is "alecu', too!
[14:52] <CardinalFang> Got that, alevine?
[14:52] <alecu> :-)
[14:53] <alevine> CardinalFang, sorry. your question is over my head. I don't know much about couchdb or anything about desktopcouch
[14:53] <CardinalFang> alevine, You pasted two things.  Why two?
[14:54] <alevine> the paste that rye sent you is the contents of /proc/5551/net/tcp, the one I sent you is the output of ls -l /proc/5551/fd
[14:54] <CardinalFang> alevine, Oh, wait, I see.  Sorry.
[14:54] <CardinalFang> alevine, pastebin looks different.  I thought there were two pastes.  The second is really another submission box.
[14:55] <alevine> pastebin changed their interface last week I think :)
[14:55] <CardinalFang> Yeah, someone bought and rewrote it, I heard.
[14:57] <alevine> odd
[15:00] <CardinalFang> alevine, Hrm, it works for me, using your data.
[15:01] <CardinalFang> alevine, let's open a terminal and run 'python'
[15:01] <alevine> CardinalFang, done
[15:01] <CardinalFang> alevine,  >>> import desktopcouch; desktopcouch.find_port()
[15:02] <alevine> CardinalFang, 36745
[15:02] <alevine> was returned in single quotes
[15:02] <CardinalFang> alevine, Er, okay.  That's what I expected to happen.
[15:03] <CardinalFang> alevine, Maybe we should back up.  What is the problem you see?
[15:04] <alevine> CardinalFang, as a user, I have no problem. I can synchronize my notes correctly. But I think rye was worried about the fact that I have no notes db in my couch when I open it with futon
[15:06] <CardinalFang> alevine, okay.  I think I see how we got here.  What version of desktopcouch do you have installed?  $ dpkg -l desktopcouch |cat
[15:07] <alevine> CardinalFang, ii  desktopcouch                               0.5-0ubuntu1
[15:19] <CardinalFang> statik, Can you upload to 9.10?  Prob not, right?  I was sure this branch/release landed months ago.
[15:19] <CardinalFang> https://code.edge.launchpad.net/~ubuntuone-control-tower/ubuntu/karmic/desktopcouch/release-0.5.1/+merge/16433
[15:56] <statik> CardinalFang, for that to go into 9.10 we would follow the SRU process. I can upload to karmic-proposed, yes. I probably need to do it not-today though.
[15:58] <CardinalFang> statik, agreed, not urgent at all.  I'll review SRU checklist again.
[15:59] <alevine> CardinalFang, let me know if you need me to run anything else. the problem isn't urgent to me...but i'm here to help if you think you should look into it
[15:59] <CardinalFang> alevine, Okay, I think your desktopcouch-service will start, but not every time you run it.   There's a timing problem, that we have a fix for already proposed.  It has not landed in Ubuntu 9.10 yet, though it has in 10.04-pre.
[16:00] <alevine> CardinalFang, sounds good. is there a bug I can subscribe to so I can test when the fix is released?
[16:02] <CardinalFang> alevine, https://bugs.edge.launchpad.net/ubuntu/+source/desktopcouch/+bug/465216  When that goes from Confirmed -> Fix Released for desktopcouch (Ubuntu) , it should be fixed.
[16:04] <alevine> CardinalFang, great. I'll test when 0.5.1 comes to karmic
[16:04] <alevine> thanks for your help
[16:07] <dpm> hey dobey, another quick question on ubuntuone-client. This string seems to cause confusion to translators -> https://translations.launchpad.net/ubuntu/lucid/+source/ubuntuone-client/+pots/ubuntuone-client/ca/4/+translate Some people think it's a variable and shouldn't be translated. I've had a quick look at the code and if I understand it correctly, it can be translated as any other. Could you confirm that? And the second question is: would it be possible
[16:07] <dpm>  to add a comment to the string, so it gets extracted and put in the template for translators to see?
[16:09] <dobey> it might make sense to remove the <> there, and not use all caps.
[16:09] <dobey> sure
[16:10] <dobey> a comment is fine
[16:10] <dobey> i'm off to lunch at the moment, though :)
[16:28] <dpm> dobey, yeah, that would sound fine to me as well. It's just a minor thing, though, and I thought I'd just mention it rather than opening a bug. Anyway, enjoy your lunch!
[17:03] <rye> i believe <pre> is not a good tag for <monospace> in Tomboy. <tt> might be better. <monospace> is not block-level, it is inline element
[17:26] <tcole> agreed, generally you want block/inline agreement
[17:36] <dobey> dpm: well, bugs are good for tracking things, even if they are trivial. do you know if there is a bug on it? also, are you making a branch for it?
[17:42] <duanedesign> i imagine everyone is aware of this, just to be sure. bug 537237
[17:43] <duanedesign> oop, nevermind. Its been assigned :) needed to refresh the browser :P
[17:43] <dobey> yes
[17:44] <dobey> we are aware
[17:44] <dobey> and it will be fixed soon :)
[17:46] <duanedesign> thank you dobey
[18:03] <dpm> dobey, I can do both, filing a bug and providing a trivial fix, no probs. I just want to always check first with the devs what they think and which workflow they follow
[18:04] <dobey> dpm: cool. if you've ever seen a tornado, that's pretty much what my workflow is like.
[18:06] <dpm> :-)
[18:08] <duanedesign> rye: does bug 537138 sound like a dupe of bug 531273
[18:09] <dobey> duanedesign: maybe, not sure
[18:10] <dobey> duanedesign: yeah, it does seem like a dup
[18:10] <duanedesign> dobey: thanks dobey. Just trying to finish up on a few notes i made this weekend
[18:47] <duanedesign> huh, im not seeing my /5
[18:47] <duanedesign> oops
[18:47] <duanedesign> lol, seems i have to do that at least once a day :P
[18:56] <mesula> Why does ubuntuone-syncd use so much CPU?
[18:58] <dobey> not sure. we'd need more info to give you an exact answer. presumably there is a bug you're seeing, and it shouldn't be using that much cpu.
[18:59] <mesula> 50%
[18:59] <mesula> Is it even actually doing anything useful?
[19:00] <mesula> It might have something to do with the fact that I just told it to sync up a directory containing 1.5GB of data.
[19:00] <dobey> i don't know what it's doing, aside from "something," based on the information you've recited :)
[19:00] <dobey> how many files?
[19:00] <mesula> dobey: About 8,500.
[19:01] <dobey> https://launchpad.net/bugs/531273
[19:01] <dobey> that's probably what you're seeing then :-/
[19:01] <mesula> dobey: I guess it'll keep going all night, then...
[19:01] <dobey> it's going to be a while, yes
[19:01] <mesula> dobey: I have a crappy Intel CPU. :(
[19:01] <mesula> And I'm running Bittorrent and playing FLAC music.
[19:02] <mesula> Intel P4
[19:02] <dobey> i'm sorry that you're hitting the bug. i hope we can figure out a solution for it soon and make it super fast.
[19:15] <mesula> dobey: The Services tab in Ubuntu One Preferences is all greyed out. :(
[19:16] <mesula> I want to sync my bookmarks and contacts, too.
[19:16] <mesula> Oh, and my Tomboy notes.
[19:16] <dobey> mesula: tomboy is a separate thing, and we can't control whether it's synced or not from that. it has to be set up in Tomboy itself
[19:17] <dobey> mesula: and bookmarks and contacts are already synced by default. it's greyed out because the backend implementation for that functionality isn't complete (althouth it will be in the next few days, and will be in beta2)
[19:17] <mesula> dobey: Does bookmark syncing work with Midori. Also, it doesn't make it obvious it's referring to web bookmarks.
[19:18] <mesula> It could mean ebookmarks or anything else.
[19:18] <dobey> no, bindwood is only available for Firefox at the moment
[19:18] <dobey> ebookmarks?
[19:18] <mesula> dobey: Firefox is stupid and isn't GTK and doesn't integrate properly with my lovely GTK desktop.
[19:18] <mesula> dobey: ebook bookmarks
[19:18] <mesula> dobey: Let's not confuse the users.
[19:18] <dobey> Firefox is gtk+. But yes, it does lack some things.
[19:19] <mesula> dobey: Firefox doesn't use native GTK widgets.
[19:19] <dobey> actually it does
[19:19] <mesula> dobey: Actually, it doesn't.
[19:19] <dobey> (unless you build it with qt)
[19:19] <mesula> Firefox and Openoffice aren't actually GTK.
[19:19] <dobey> in that case, neither is midori i guess
[19:19] <dobey> openoffice certainly isn't
[19:19] <dobey> but firefox is
[19:20] <mesula> WTF Openoffice isn't at all.
[19:20] <mesula> Midori is.
[19:20] <mesula> Themes and stuff always work with Midori and Abiword because they're GTK.
[19:22] <dobey> the drawing code in webkit for widgets is almost exactly the same as the code in firefox for drawing widgets on the web.
[19:22] <dobey> are you referring to firefox nightlies or something?
[19:23] <dobey> gtk+ themes work fine for me re: firefox
[19:23] <mesula> If something looks like a GTK app, doesn't mean it's a GTK app.
[19:25] <dobey> no. but have you read the firefox code? :)
[19:26] <dobey> just because the ui is built with xul, doesn't mean it's not using gtk+ to actually do stuff, either. :)
[19:27] <mesula> dobey: Whenever I want to move my GTK widgets around to weird places on my screen or use some awesome themes, Firefox and OpenOffice don't do it for me.
[19:28] <mesula> For example, I like to use the Dust Sand theme and move my menu bars to the top left corner of my screen.
[19:28] <dobey> move your menu bars?
[19:29] <dobey> with the global-menu applet thing?
[19:29] <mesula> dobey: Yeah, that buggy piece of shit.
[19:29] <mesula> gnome2-globalmenu
[19:30] <dobey> ok. well because firefox doesn't work with it also doesn't mean it's not gtk+. :)
[19:31] <dobey> but anyway, bindwood is only available for firefox at the moment. there has been some work (by someone whom i can't recall the name of at the moment) to make a version for Chrome as well
[19:31] <dobey> i don't know if there is any way to actually extend Midori in that way
[19:31] <dobey> though it might be possible to haven a version for Epiphany
[19:31] <mesula> I wish my 14 year old friend (who's a girl) would log into MSN so that I can arrange to walk her home after school tomorrow.
[19:32] <mesula> dobey: Epiphany sucks
[19:33] <dobey> yes, well. i'm not here to argue about what one thinks is an acceptable version of a web vm. :)
[20:55] <rye_> nessita, do you mind if I comment on tree-deletion-when-prior-conflict with Needs Fixing? I am not a reviewer but it looks like the code will fail to protect users' data inside folders that were themselves renamed in to U1conflict - only filenames are checked
[20:56] <rye_> desktop+/chicharra team - when does a folder get renamed into .u1conflict one ?
[20:57] <dobey> rye_: you can review the branch if you wish
[20:58] <dobey> rye_: it doesn't matter what day you are nominally on-call reviewer for. you can review branches any time
[20:58] <rye_> rye_, erm, I believe I am not in a reviewer at all
[21:00] <dobey> rye_: uhm, yes you are.
[21:00] <dobey> rye_: if you review something, you are a reviewer.
[21:01] <rye_> :)
[21:01] <dobey> rather simple really :)
[21:01] <rye_> dobey, I meant not in a @reviewers :)
[21:01] <rye_> not in @reviewers list
[21:02] <rye_> the third time it looks correct
[21:03] <dobey> rye_: that's just the list of people who are on-call to do reviews for the day
[21:03] <dobey> rye_: but like i said, you don't have to be in that list to do reviews :)
[21:43] <seg|away> thisfred: hey, I just saw your gwibber bug report about couchdb
[21:44] <seg|away> thisfred: let me know if you need any help. I'd really like to get a fix for that in for lucid
[21:45] <seg|away> I suspect it's fairly trivial to accomplish
[21:45] <thisfred> seg|away: ok, I'll try tonight, but I may not have anything left. I'm explicitly not getting canonical time to work on this ;)
[21:46] <thisfred> yeah I've started on the branch. I figure if there were tests, it would have been 5 mins of work ;)
[21:46] <seg|away> yeah
[21:46] <seg|away> the hard part is really making sure it doesn't break anything. :-(
[21:47] <thisfred> I'll see, if it's not much work, I'll add some tests, if not, we can leave that for later, if I can figure out how to make sure I didn't break stuff
[21:47] <seg|away> If you don't have time, I can help with the testing
[21:47] <seg|away> how far have you gotten?
[21:47] <thisfred> ok, I figured I'd ask you for a review specifically anyway :)
[21:48] <thisfred> well, I changed the views, which was trivial, just need to go through the code to see where the value was used, and substitude 'doc' for that
[21:48] <seg|away> gwibber fortunately has a very active and vocal community of daily testers, so we will know almost immediately if something does break and we miss it
[21:49] <seg|away> yeah
[21:49] <thisfred> or uglier but easier, in the big dict, poke the doc value into 'value'
[21:50] <seg|away> thisfred: your report said that you could just use include_docs
[21:50] <seg|away> if that's the case, you can just add that in the same place where we set the record limit in MessageStreamView
[21:50] <seg|away> and that should cover like 90% of the cases where we actually need the doc
[21:51] <seg|away> am I missing something?
[21:51] <thisfred> seg|away: yes, you can pass that as a keyword arg to the python-couchdb view, but then 'doc' is the key in the resulting rows, where before it would have been 'value' I think
[21:51] <seg|away> oh I see
[21:51] <thisfred> this is all from a not very stainless memory
[21:54] <seg|away> thisfred: in any case, I think that it will be pretty easy to add it to view.options in MessageStreamView rather than having to add it to all of the execute_view invocations in the model
[21:54] <thisfred> yeah, I think that's what I
[21:54] <thisfred> 'll do
[21:54] <seg|away> cool
[21:54] <thisfred> it can be prettified later
[21:56] <seg|away> thisfred: where is the view data cached in desktopcouch?
[21:56] <seg|away> I was under the impression that it was part of the actual db file
[21:56] <seg|away> but your bug report seems to indicate that it is separate
[21:56] <thisfred> it is:
[21:57] <thisfred> ls -la $HOME/.local/share/desktop-couch/
[21:57] <thisfred> you'll see a lot of dot directories, one for each db
[21:57] <thisfred> that's where the 'indexes' live
[21:58] <seg|away> ah thanks. I didn't know about that before
[21:58] <seg|away> do those get synced with u1?
[21:58] <thisfred> this is just the way couchdb stores them, not unique to d-c
[21:59] <thisfred> seg|away: no, luckily: the design docs do, but the view indexes are built on first call, and hence never, on the server
[21:59] <seg|away> ok
[21:59] <seg|away> that's good. We have enough trouble already with the network overhead of syncing the message db. ;-)
[21:59] <thisfred> hehe
[22:00] <seg|away> I should probably implement auto-compaction or something
[22:00] <seg|away> will removing the doc data from the views also make view computation less cpu-intensive?
[22:01] <thisfred> I'm not sure, it might
[22:01] <thisfred> auto compaction should come to d-c, since there's a daemon running for replication anyway, IMO
[22:01] <seg|away> we get cpu spikes sometimes when it's generating the views after loading a lot of new messages
[22:02] <thisfred> yeah, so it may be less expensive with smaller views, but I would expect it to affect memory more than CPU
[22:02] <seg|away> ah
[22:02] <thisfred> that is without much knowledge of the internals though, so who knows ;)
[22:02] <seg|away> do you think that batch updating would help lower the cpu usage?
[22:03] <seg|away> I'm currently just doing put_record in a loop, basically
[22:03] <thisfred> yes, that may certainly help, as the views would only need to be regenerated once
[22:04] <thisfred> that, or hold off on calling any views between updates, but that's hard in a desktop app where the UI is making its own requests, probably
[22:04] <seg|away> yeah
[22:04] <seg|away> I think our monitoring might also be slowing it down