[00:53] <rickspencer3> robert_ancell: hi
[00:53] <robert_ancell> rickspencer3: hi rick
[00:54] <rickspencer3> did TheMuso mention setting a meeting time?
[00:54] <robert_ancell> rickspencer3: no, haven't heard anything about that
[00:54] <rickspencer3> robert_ancell: ok
[00:55] <rickspencer3> the idea is to set up a desktop team meeting "Eastern Edition"
[00:55] <rickspencer3> so I asked him to get together with you and find a time once per week that was mutually agreeable for the three of us
[00:55] <robert_ancell> rickspencer3: sounds good.  Do you have the IRC log for the previous western meeting?
[00:55] <rickspencer3> I don't mind popping in one evening a week as long as it's not too late
[00:56] <rickspencer3> robert_ancell: It's logged on the web
[00:56] <rickspencer3> I haven't done the summary yet, and looks like I won't get to it today
[00:56] <rickspencer3> (have a call in 4 mins. and then company for dinner)
[00:56] <robert_ancell> Where is it logged?
[00:56] <robert_ancell> OK, no problem.  Did you give TheMuso your preferred times for meetings?
[00:57] <rickspencer3> http://irclogs.ubuntu.com/
[00:57] <rickspencer3> all is logged!
[00:57] <rickspencer3> hi TheMuso
[00:57] <rickspencer3> I was mentioning that desktop team meeting "Eastern Edition" to robert_ancell
[00:57] <TheMuso> Ah ok.
[00:57] <rickspencer3> so could you guys pick a time that is not too late here, but reasonable for you two?
[00:57] <rickspencer3> Other folks may attend if it's not too late
[00:58] <TheMuso> robert_ancell: what suits you, I am quite flexible so can do most times.
[00:58] <rickspencer3> hehe
[00:58] <rickspencer3> you are both so agreeable, you'll never decide :)
[00:58] <robert_ancell> I'm fine between 9am and 6pm Australia time.  I figure rickspencer3 has the strongest opinion regarding time!
[00:59] <rickspencer3> well, just not too late in the evening for me
[00:59] <TheMuso> right, that time frame suits me. :)
[00:59] <rickspencer3> it's 10am there, right?
[00:59] <TheMuso> I tend to start my day between 8 and 8:30AM.
[00:59] <rickspencer3> hmm
[00:59] <TheMuso> Correct.
[00:59] <rickspencer3> if we do 9am on Wednesday
[00:59] <robert_ancell> rickspencer3: is 1600-1700 your time good? That is 9am for us
[00:59] <rickspencer3> that will be 4pm for me
[00:59] <TheMuso> Works for me.
[00:59] <rickspencer3> on the same day as the Western edition
[01:00] <rickspencer3> oops
[01:00] <rickspencer3> gotta run
[01:00] <rickspencer3> gotta call, but let's call this a plan
[01:00] <robert_ancell> cya
[01:00] <TheMuso> ok fine by me
[01:00] <TheMuso> cya
[01:22] <rickspencer3> Yingying_Zhao: o/
[01:42] <rickspencer3> TheMuso: robert_ancell
[01:42] <rickspencer3> I sent out the team meeting minutes after all
[01:42] <TheMuso> heh ok.
[01:43] <rickspencer3> gotta run
[01:43] <rickspencer3> but if you have any questions, we can talk tomorrow
[06:39] <pitti> Good morning
[07:23] <didrocks> good morning
[08:00] <crevette> good morning
[08:10] <pitti> I'm off for an appointment, back in ~ 3 hours
[08:55] <seb128> hello everybody
[08:55] <seb128> pitti: what did you do to the retracers?
[09:03] <didrocks> hey seb128 o/
[09:03] <didrocks> seb128: pitti is away for 2 hours
[09:08] <seb128> lut didrocks
[09:08] <seb128> didrocks: ok thanks
[09:20] <asac> hmm, the autoduper seems to dupe zillions of bugs now
[09:20] <asac> like bug 193811
[09:21] <asac> its kind of a useless stacktrace, but still apport thinks its a dupe ;)
[09:21] <asac> pitti: has something changed?
[09:21] <asac> basically i am flooded with apport duping really old bugs
[09:26] <seb128> asac: I asked first!
[09:26] <seb128> asac: pitti is away for 2 hours apparently though
[09:26] <seb128> asac: hey btw ;-)
[09:28] <seb128> robert_ancell: hey
[09:29] <Ampelbein> seb128, asac: apparently the retracer removes CoreDump.gz from duplicate bug reports. Yesterday in #ubuntu-devel it was mentioned that this happens for privacy reasons
[09:29] <robert_ancell> hi seb
[09:29] <seb128> robert_ancell: how was your day?
[09:30] <robert_ancell> seb128: reasonable useful, got g-c-c merged
[09:30] <robert_ancell> working on inkscape at the moment
[09:30] <seb128> Ampelbein: thanks, that I had noticed, I'm wondering why that has not been publically discussed or announced though
[09:30] <Ampelbein> asac: 193811 wasn't duped by apport.
[09:33] <asac> seb128: hey. so i am not the only one ;)?
[09:33] <seb128> asac: I got 477 retracer emails during the night
[09:33] <Ampelbein> seb128: Don't know why it has not been announced. Nonetheless I think it's the right thing to do.
[09:33] <asac> yeah. seems its enough if top most method is the same
[09:33] <asac> and the rest ?? ;)
[09:34] <seb128> but they seem be mostly apport delete coredump.gz on duplicates as said before
[09:34] <asac> ah
[09:34] <asac> yeah.
[09:34] <asac> that explains it
[09:34] <asac> great.
[09:34] <seb128> those have not been marked duplicates now
[09:34] <seb128> seems pitti just did some cleaning round
[09:34] <asac> just got scared when apport started to touch bugs with 5 digits ;)
[09:34] <crevette> heya
[09:34] <Ampelbein> asac: if some person thinks it's a dupe and marks it that way it's not apports fault ;-)
[09:34] <seb128> which is fine but I would appreciate some earlier notice to avoid the "wtf" moment this morning looking at those
[09:35] <asac> i agree. was just confused by the mail format
[09:35] <asac> and yeah. giving heads up could have prevented me rubbing my eyes ;)
[09:37] <asac> ArneGoetje: hi.
[09:37] <asac> ArneGoetje: do you have any idea on what goes wrong with the mozilla exports?
[09:37] <asac> maybe the "po" filenames have changed?
[09:37] <crevette> seb128, for https://wiki.ubuntu.com/DesktopTeam/Specs/Karmic/GNOME3, perhaps running gnome-shell in a clean gconf environment to not mess GNOME 2 would be something to have? I don't know if http://blog.fishsoup.net/2009/06/07/hacking-local-defaults-into-gconf/ would be feasible
[09:38] <crevette> asac, doid you see the text I sent yesterday night?
[09:38] <seb128> crevette: why would it mess with other applications settings?
[09:38] <seb128> crevette: trying anjuta doesn't mess your gedit settings, those are different softwares
[09:38] <crevette> I don't know, perhaps some gconf key values
[09:38] <seb128> crevette: why would that be different?
[09:38] <crevette> for mutter
[09:38] <asac> crevette: yes. not sure what you exactly wanted an answer for ;)
[09:39] <seb128> crevette: I doubt they write new software that destroy your user settings for the fun there
[09:39] <seb128> crevette: give some credit to owen work ...
[09:40] <asac> crevette: the GCompareFunc cast? yes, i think its right
[09:40] <asac> (if it makes the warning go away ;))
[09:40] <crevette> owen has my full suport :)
[09:40] <crevette> asac, yep it does
[09:40] <crevette> asac, what is the role of this cast?
[09:40] <crevette> (sorry, my c is *very* limited)
[09:41] <asac> crevette: for the compiler the signature of
[09:41] <asac> int                 g_strcmp0                           (const char *str1, const char *str2);
[09:41] <asac> compared to
[09:41] <seb128> crevette: so to reply to your weird question I don't understand, I see no reason to start complicated gconf magic if there is not a real proved issue
[09:42] <asac> gint                (*GCompareFunc)                     (gconstpointer a, gconstpointer b);
[09:42] <asac> is not essentially the same
[09:42] <asac> so casting tells the compiler to assume that you know what you are doing
[09:43] <asac> e.g. typedef const void *gconstpointer;
[09:44] <crevette> I seen some cast was used with (GFunc) for another g_list_* so I assumed it is okay
[09:44] <crevette> I'll push the fix on GNOME git tonight
[09:46] <crevette> seb128, It was just a bit "worried" about gconf weirdness between GNOME2/ GNOME3, I remember not good behaviour when I was playing with GNOME 2 on GNOME 1.x, but I'm certainly wrong
[09:46] <seb128> crevette: GNOME1 and GNOME2 were different desktops
[09:46] <seb128> crevette: GNOME3 is GNOME2 using recents api + some new softwares
[09:47] <seb128> nautilus will still be the same, gedit too, etc
[09:47] <asac> crevette: nice
[09:53] <mpt> "It is unsafe to open “ubuntu-uploads.ogv” as it could potentially damage your documents or invade your privacy. You can download it instead."
[09:54] <mpt> wtf, Epiphany, it's a video
[09:55] <crevette> hmm, can it be possible to do crafted video to produce damage and execute commands?
[09:56] <seb128> everything is possible, you can do crafted website for that too ;-)
[09:56] <mpt> crevette, apparently so. I tried to open the video, and it logged me out.
[09:56] <seb128> it's not really likely though
[09:56] <seb128> mpt: using karmic?
[09:56] <mpt> no, 9.04
[09:56] <seb128> hum ok, I would still say that xorg crashed
[09:56] <seb128> but it would have been less surprising on karmic
[09:57] <mpt> ... And the problem's reproducible :-)
[09:57] <crevette> seb128, X is supposed to be stabler in karmic than jaunty?
[09:57] <crevette> I mean at this point
[09:57] <seb128> crevette: no, that's why I say I would not have been surprised if that was xorg crashing in karmic
[09:58] <crevette> ah yeah? sorry I misread
[09:58] <seb128> mpt: xorg crashing, what videocard and driver do you use?
[09:58] <mpt> seb128, it's Intel ... 965? 695?
[09:58]  * mpt forgets how to look it up
[09:59] <seb128> does it crash on any video?
[10:00] <mpt> seb128, no, <http://video.ubuntu.com/uds/jaunty/notifications.ogv> works fine for example
[10:01] <mpt> (Seriously, what's the graphical way for me to find what kind of video card this computer has?)
[10:01] <seb128> weird
[10:01] <seb128> (none)
[10:02] <ArneGoetje> asac: the bug is in Rosetta, that's all I know. It's the database which has problems due to the message sharing transition. Therefor no useful imports and exports for now.
[10:03] <ArneGoetje> asac: I'm working with the Rosetta guys to resolve that issue.
[10:04] <asac> ArneGoetje: cool. let me know in case mozilla processor still does not work after the rosetta fix
[10:04] <mpt> seb128, so would it be useful to report a bug about this, and if so, what's the best apport command?
[10:05] <seb128> mpt: "this" being the security warning from epiphany or the xorg crash?
[10:05] <mpt> the xorg crash
[10:05] <mpt> "ubuntu-bug xserver-xorg-video-intel"?
[10:05] <crevette> mpt, I would say that
[10:06] <crevette> perhaps some folks on #ubuntu-x can help you
[10:06] <mpt> ah, thanks, I didn't know of that channel
[10:06] <crevette> https://wiki.ubuntu.com/X/Reporting
[10:06] <mpt> ugh, and now Epiphany's given up on anti-aliasing text too
[10:08] <seb128> mpt: ubuntu-bug xorg-server I would say
[10:08] <mpt> ok
[10:08] <crevette> the wiki page says "ubuntu-bug -p xorg"
[10:08] <mpt> "Package xorg-server does not exist"
[10:08] <seb128> mpt: do you have any crash mention in /var/log/Xorg.0.log.old?
[10:09] <seb128> mpt: xserver-xorg sorry
[10:09] <seb128> or "xorg"' should do
[10:09] <seb128> wait
[10:10] <mpt> seb128, no, there's nothing in there that looks like a crash to me
[10:10] <seb128> mpt: no error at the bottom of the log?
[10:11] <seb128> and nothing in /var/log/syslog or /var/log/messages either?
[10:11] <mpt> Free list:
[10:11] <mpt>  FREE Offset:0002c000, Size:000fe000, F.
[10:11] <mpt> End of memory blocks
[10:11] <mpt> That's the last three lines
[10:11] <ArneGoetje> asac: will do
[10:12] <seb128> mpt: no segfault mentioned?
[10:13] <mpt> nothing relevant in /var/log/syslog
[10:13] <mpt> nothing relevant in /var/log/messages
[10:15] <seb128> mpt: ok, ubuntu-bug xserver-xorg-video-intel
[10:15] <mpt> thanks seb128
[10:15] <seb128> you're welcome
[10:15] <seb128> about the epiphany warning ... do you have the video url? is it public?
[10:15] <seb128> I would like to give a try, epiphany basically has a list of safe mimetypes
[10:16] <seb128> ogg should be there, I'm wondering if that's the "ogv" rather than "ogg" confusing it
[10:16] <seb128> or if that's the server returning a wrong mimetype
[10:18] <mpt> seb128, go to <http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2009/05/28#2009-05-28-code_swarm> and click on "video"
[12:21] <pitti> seb128: I cleaned up all the obsolete core dumps (some 8.000)
[12:21] <seb128> pitti: you confused quite some people
[12:21] <pitti> asac: not dup'ing, just deleting coredumps
[12:21] <seb128> pitti: next time would be nice to email the list saying you are going to do that so people can delete the spam rather spend an hour going through to understand what's going on
[12:22] <pitti> sorry, I wasn't even aware that it'd send bug mail
[12:22] <pitti> gosh, it's way too chatty
[12:22] <seb128> I got 477 emails this morning
[12:22] <seb128> added to the 250 bug watch updates emails from yesterday
[12:25] <asac> :)
[12:27] <seb128> speaking about apport bug spam I would happily trade the emails we receive now about duplicates, incorrect retracing etc for emails about bugs which have been retraced correctly
[12:28] <seb128> ie I want to know about useful bugs, not about all the cleaning done on the non useful set
[12:31] <pitti> that's why I thought that people wouldn't like to get apport crash bug mail at all
[12:31] <pitti> we could keep the duplicates private
[12:31] <pitti> that would avoid the spam of closed duplicates, I think
[12:33] <seb128> having access to duplicates informations is useful though
[12:34] <seb128> but having a bugsquad member going through all duplicates to see if they have useful informations and mark some public is not optimal
[12:34] <seb128> I tend to agree with asac, the real issue is that crashes should probably not go in the bug tracker by default, but that's not something we will change soon
[12:36] <asac> \o/
[12:37] <asac> one idea is to create a virtual crash package where all crashes are filed again
[12:37] <asac> and then providing some way to access the retrace crash db
[12:37] <asac> (which probably already has all the stacktraces)
[12:38] <asac> what do you think pitti? what info is in that retracer db? could that be used to make stacktraces navigatable on the web?
[12:38] <asac> (and sortable by dupes)
[12:39] <pitti> seb128: well, I don't mind so much about them being in the bug tracker; I'm more worried about the bug mail spam, as well as LP's inability to hide them
[12:40] <pitti> asac: the primary information is in LP itself; the retracer only has a DB with "stack trace signatures" for dup detection
[12:40] <seb128> right, those issues are there because we try to use the bugtracker to handle things which are not really bugs or don't fit in the workflow
[12:40] <pitti> well, they are bugs, but they inherently get a lot of dupes
[12:40] <pitti> asac: getting _only_ the crashes has always been easy
[12:41] <pitti> just search for apport-crash
[12:41] <pitti> it's hard to get only the non-crash bugs
[12:41] <pitti> we could keep the dupes private, that should kill the dup bug mais
[12:41] <pitti> mails
[12:41] <pitti> if that would help you, that's easy to do
[12:43] <asac> i want to keep crashes out of bugs entirely
[12:43] <asac> instead you want to create bugs if there is a crash that is interesting
[12:44] <seb128> we have thousand of useless crash bugs sitting in launchpad
[12:44] <asac> other projects like mozilla and google got this right and did their crashdb outside of bugzilla
[12:45] <asac> and they only create bugs out of them if there is actually a way to reproduce
[12:45] <pitti> asac: I'm not opposed to that, we just don't have it right now
[12:45] <asac> or if suddenly a new top-crashers appears
[12:45] <pitti> I'm not convinced myself that it would be an improvement, but that's just my personal opinion
[12:46] <asac> pitti: yeah. so what info is missing in the current retracer db? signature is most likely the main thing we want (together with initial comment from reporter)
[12:46] <seb128> what sucks is launchpad not being able to filter on !apport-crash
[12:46] <pitti> asac: info for what?
[12:46] <pitti> seb128: right, that seems to be the main thing to fix here
[12:46] <seb128> you get your bug lists polluted by those
[12:46] <asac> pitti: above i wondered why we cant use the apport retracer database (currently used for dupe matching) and make that browsable on the web
[12:47] <asac> you said that it just has signatures ... which i think is actually the main content we want from crashes
[12:47] <pitti> asac: what would that give you that you can't do with a simple LP search (by distro or per-package, and apport-crash tag)?
[12:48] <asac> pitti: i cannot find stack signature elements
[12:48] <pitti> asac: Stacktrace.txt attachments?
[12:48] <asac> well. you cannot search that ;)
[12:48] <seb128> the main issue is that launchpad query sucks
[12:49] <pitti> oh, signatures
[12:49] <seb128> you can't do "search bugs which have a Stacktrace listing this function"
[12:49] <pitti> asac: the top 5 stack trace lines are in a comment, that should be perfectly searchable
[12:49] <seb128> you would think
[12:49] <asac> afaik launchpad doesnt search comments
[12:49] <asac> just summary
[12:49] <asac> and description
[12:50] <seb128> the real issues are launchpad limitations
[12:50] <seb128> but those are there for some years and they is no sign they will fix those in the next years
[12:50] <seb128> at least I don't see any visible work being put on having search not sucking out of using google
[12:50] <asac> also putting this into the crash db rather than bugs would change our workflow to more like a "lets pull in the gems from the crash db and make a bug" and not "lets push away all the garbage to find the gems"
[12:50] <pitti> well, *shrug*, https://bugs.edge.launchpad.net/ubuntu/+bugs?field.searchtext=PyErr_PrintEx, or use google
[12:51] <pitti> but do you really think that searching for particular pieces in crashes is the main problem that we have?
[12:51] <pitti> (honest question)
[12:51] <asac> no the main problem is that having bugs for every crash makes our workflow to be: "lets push away all the garbage to find the gems"
[12:51] <seb128> pitti: that query works before the function is listed in the non debug stacktrace in the summary
[12:52] <seb128> before -> because
[12:52] <asac> also making our own webfrontend for a db will allow us to be more flexible and independent from launchpad features
[12:52] <pitti> seb128: perhaps, google then :)
[12:53] <pitti> asac: well, is it really that, or rather an excuse for not looking at crashes at all?
[12:53] <seb128> but pitti has a point
[12:53] <seb128> "what are we trying to solve there"
[12:53] <pitti> anyway, of course we could go ahead and create a separate crash db
[12:53] <pitti> but what would that give us, except for a year of work
[12:53] <pitti> ?
[12:53] <pitti> we want subscriptions, comments, we want to link them to upstream bugs, assign them to people, etc.
[12:53] <pitti> sounds very much like a bug tracker to me
[12:54] <pitti> we shoudl fix the shortcomings in searching/reporting IMHO, not rewrite the entire thing
[12:54] <pitti> that would fix the immediate issues and keep the rich feature set that the bug tracker offers to us
[12:54] <pitti> asac: well, how would a crash db look significantly different/
[12:54] <pitti> ?
[12:55] <pitti> with bug gravity or "hotness" we can find the top crashers, and if LP would grow a "hide crashes" checkbox, wouldn't that make the workflow much better?
[12:55] <pitti> that might actually be achievable in a month's time instead of "two years or never"
[12:56]  * pitti just tries to get some practical solution here
[12:56] <seb128> yeah
[12:56] <seb128> what I want is a !apport-crash filter
[12:56] <pitti> yeah, me too
[12:56] <pitti> seb128: and reduce the bug mail spam, too, I think
[12:56] <seb128> can we put that high on the platform team wishlist list for launchpad hackers?
[12:56] <seb128> do we still have a such list?
[12:56]  * pitti notes that down to channel it through the management chain
[12:56] <asac> having a negative tag search was requested lots of times ;)
[12:57] <seb128> pitti: danke
[12:57] <asac> basically what i i want to be able to look at the stacktraces of the top crashes without going through bugs
[12:57] <pitti> one thing that we can do immediately is to keep duplicates private
[12:57] <pitti> this avoids sending mail at all
[12:57] <seb128> now for the bug email spam, either we mark things private which complicate triagging and access to the information
[12:57] <asac> and also clicking on method signatures there and see crashes that have the same method (even from other packages)
[12:57] <seb128> or we use special titles or something which allow easy client side filtering
[12:58] <pitti> asac: if that's useful, we could provide access to the duplicate DB
[12:58] <pitti> asac: a web UI will take some time, but if a CLI will do, that should be easy
[12:58] <seb128> asac: why not going through bugs? those usually have useful informations
[12:58] <seb128> I tend to filter apport-crash bugs by number of duplicates when I do that
[12:59] <seb128> and go through the bugs, it's quick enough and descriptions can have useful details
[12:59] <asac> i dont say that bugs are useless
[12:59] <asac> i just say that the initial comment together with the stacktrace would help more
[12:59] <asac> e.g. i look at a top crasher and see the stacktrace with all the initial comments
[12:59] <asac> (and links to the bugs if i think it helps to ask something)
[13:00] <seb128> "see the stacktrace with all the initial comments" is basically the bug page no?
[13:00] <seb128> anyway it should be easy to use launchpadlib to do that
[13:00] <asac> but most crashes are not easily reproducible (at least in mozilla world). but looking at a bunch of initial comments might help you to narrow down what is actually the reason for a crash
[13:00] <seb128> rick's application already do a query on new bugs and list those in a pygtk interface
[13:00] <seb128> you could tweak that to list apport-crash bugs
[13:00] <pitti> top crashers sounds like a report we should be able to request from the QA team
[13:00] <seb128> and make it display the stacktrace.txt there
[13:01] <asac> seb128: the bug page? the maste bug only has the comment of that bug
[13:01] <asac> if we copied the duped initial comments to the master bug that would work
[13:01] <seb128> ah, I see what you want
[13:01] <seb128> should be easy to do a small tool doing that though
[13:01] <pitti> http://qa.ubuntu.com/reports/package/gt2dupes/compiz.html
[13:01] <asac> i see a crash with dupes in firefox, users comment:
[13:01] <pitti> something like that, for crashes
[13:01] <asac> 1. i dont kmnow what i did
[13:01] <asac> 2. i navigated to this site and hit the back button
[13:02] <seb128> what asac wants is the description of all the duplicates on one page
[13:02] <asac> right
[13:02] <seb128> so you can read through quickly for useful clues
[13:02] <pitti> that makes sense
[13:02] <asac> exactly
[13:02] <pitti> sounds very achievable with launchpadlib and some scripting
[13:02] <asac> thats basically the view i would expect from a simple bug db (stacktrace + descriptions for all dupes)
[13:02] <seb128> yeah
[13:02] <asac> if thats in the bug its great
[13:03] <seb128> it's not to far of what rick is already doing with the triaging application
[13:03] <pitti> yeah, probably you'd rather wait for 10 minutes in the beginning to download all the stuff
[13:03] <pitti> and then be able to quickly browse through it
[13:03] <pitti> than to constantly wait for the web ui
[13:04] <pitti> asac, seb128: so if you both agree that bug mail spam about closed duplicates is annoying, I'm going to make that change right now
[13:04] <seb128> hum
[13:04] <asac> well. personally i think writing ricks desktop app is much different to provide a webUI, but well
[13:04] <asac> is not much different i mean
[13:04] <seb128> what implication does it have on bug triagers work
[13:05] <seb128> ie will it block people to work efficiently on bugs because they don't have access to informations?
[13:05] <seb128> ie the "get the description from all duplicates" require to have access to those
[13:05] <asac> pitti: with "closed duplicates" you mean keeping them private?
[13:05] <asac> if so we definitly need to copy all descriptions to the master bug imo
[13:05] <seb128> I'm a bit concerned that we trade spam easy to filter client side for manual bugsquad extra work
[13:06] <pitti> seb128: right, but for an useful work you need access to the original bug
[13:06] <pitti> since the dupes get all valuable information stripped (core dump, stack trace, etc.)
[13:06] <pitti> asac: well, as private as the master bug, i. e. accessible to triagers
[13:06] <seb128> right, but tomorrow the master bug is made public
[13:06] <seb128> which means anybody can work on it
[13:06] <seb128> all the duplicates are still private
[13:06] <asac> pitti: currently we open up master bugs asap
[13:06] <asac> at least i do that
[13:07] <pitti> okay
[13:07] <seb128> should somebody go through all of those to allow whoever is not bugsquad to work on the public bug?
[13:07] <asac> if all dupes are still private that would hinder people to look at the other bugs
[13:07] <pitti> ok, seems this is not that unanimous, so perhaps better to leave it like it is right now
[13:07] <seb128> pitti: the concern is that flipping the master to public will not flip all the duplicates
[13:07] <seb128> which means it's not easy to work on a public bug
[13:08] <seb128> since you don't have access to all the informations
[13:08] <seb128> right
[13:08] <seb128> it's easy enough to put a small filter on the "apport retracing service" if you want
[13:08] <seb128> I'm wondering if we could set custom titles when doing cleaning
[13:09] <seb128> ie when you clean the coredump from duplicate
[13:09] <seb128> so we could filter those emails only if we want
[13:09] <pitti> right, you could ditch all bug mail from the bot
[13:09] <pitti> this would kill the duplicates and the cleanup stuff
[13:10] <seb128> ok, let's stay with what we have now then
[13:10] <pitti> so, searching -> pygtk app, mail silencing -> filter rule to drop apport bot mail, non-crashes search -> needs to be fixed in LP
[13:11] <pitti> does that fit as a summary?
[13:11] <pitti> seb128: unfortunately (well, for this discussion) I processed my bugs mailbox to zero yesterday
[13:11] <pitti> but when I'll get the next bunch, I'll update the Bugs/HowtoFilter page
[13:11] <seb128> pitti: yes
[13:11] <pitti> seb128: if you still have some of these, feel free to do it yourself
[13:11] <seb128> will do
[13:12] <pitti> I'm not sure whether they come from apport@piware.de or have another name
[13:12] <seb128> the things is that some retracer emails are interesting to me
[13:12] <seb128> could you customize the title in cleaning or duplicating cases?
[13:13] <pitti> seb128: dup mails are trivial to find, aren't they?
[13:14] <seb128> in fact the only ones I'm interested in are "[Bug nnnnnn] Stacktrace.txt (retraced)"
[13:14] <seb128> those have new stacktraces
[13:14] <seb128> "Apport retracing service <der.pitti at gmail.com>"
[13:14] <pitti> ah, that address
[13:14] <seb128> is the retracer email
[13:15] <pitti> so it would be: 1. that email plus "Stacktrace.txt (retraced)" -> good
[13:15] <pitti> 2. that email -> /dev/null
[13:15] <seb128> for me yes
[13:15] <pitti> personally I'm not even interested in the first
[13:15] <seb128> I'm not sure how much other people are interested to know about bugs which have been retraced
[13:15] <pitti> but well, that's why everyone can customize it to their liking
[13:15] <seb128> right
[13:16] <pitti> and I never look at duplicate mail anyway
[13:16] <pitti> mutt marks them specially for me, and I just delete them
[13:16] <pitti> color index             yellow          default '~b "This bug is a duplicate of bug"'
[13:16] <pitti> muhaha
[13:16] <seb128> ;-)
[13:22] <seb128> ok, compiz crashing leads to a weird session hang while apport is working on it
[13:22] <seb128> I was near to power down the computer
[13:46] <pitti>  rickspencer3-afk: hm, so no blueprint love in launchpadlib; screenscraping it is, then
[13:52] <pitti> seb128, asac, rickspencer3-afk: RFC: I added a proposed "work items" format to https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-symptom-based-bug-reporting; do you think that's easy enough/suitable?
[13:52] <pitti> empty status == "TODO" (we could also explicitly write "TODO", I don't mind)
[13:54] <seb128> pitti: lot of DONE already ;-) The format looks good to me, no need to overload by using TODO
[13:56] <pitti> so, it'd be /^work items:$/i, followed by one line of work item, ":", and {,DONE,TODO,POSTPONED}
[13:56] <pitti> until an empty line
[13:56] <pitti> and '' == 'TODO'
[13:56] <seb128> good
[13:56] <pitti> this looks natural, and is easy to parse, too
[14:16] <rickspencer3> pitti: right, wget ftw
[14:18] <pitti> hey rickspencer3
[14:19] <pitti> rickspencer3: well, urllib.urlopen(), I presume :)
[14:19] <rickspencer3> pitti: right, but it's the same thing
[14:19] <rickspencer3> no worries, I've written plenty of screen scraping code
[14:20] <rickspencer3> my problems are that I am not too facile with regex
[14:20] <pitti> rickspencer3: and you'd grab all desktop-karmic-* from https://blueprints.edge.launchpad.net/ubuntu/karmic ?
[14:20] <rickspencer3> so parsing code can be a bit cumbersome
[14:20] <seb128> re
[14:20] <seb128> the linux scheduler is a piece of crap sometime
[14:20] <rickspencer3> right, I figured I'd just extract the URLs from there, follow the links, and pull out the status, and save it
[14:21] <pitti> right
[14:21] <rickspencer3> then have a another program that reads that file and creates the chart
[14:21] <rickspencer3> easy peasy
[14:21] <seb128> no way to use the machine when you run out of swap, I've shut it down after several minutes waiting for a command to respond
[14:25] <tjaalton> asac: where does tb get it's sounds from? there does not seem to be a way to disable them, when not running gnome at least
[14:26] <asac> tjaalton: tbird 3?
[14:26] <asac> uses libcanberra
[14:26] <tjaalton> asac: no, 2.0.x in jaunty
[14:26] <tjaalton> it starts pulseaudio
[14:27] <tjaalton> but I don't know how to disable the sounds. it starts when you try to attach a file to a message, the file open dialog pops up and it spawns pa among other daemons
[14:27] <asac> tjaalton: edit -> preferences -> General -> "When new messages arrive:" ?
[14:28] <asac> uncheck "play a sound"
[14:28] <tjaalton> asac: no the sound is heard when you open the dialog, or close it
[14:28] <tjaalton> but I get no such sounds when running it under gnome :)
[14:28] <tjaalton> same profile
[14:29] <asac> tjaalton: which dialog ?
[14:29] <tjaalton> attach-a-file dialog
[14:29] <tjaalton> when writing a message
[14:29] <asac> is that a gtk file selector?
[14:29] <tjaalton> yes
[14:29] <asac> then i would think its a gtk thing
[14:30] <tjaalton> hmm ok
[14:30]  * asac never heard sound when opening tbird 2 file selector
[14:33] <kenvandine> should apparmor be getting enabled in karmic by default?
[14:34]  * kenvandine just figured out apparmor was preventing cups from starting
[14:34] <kenvandine> but only on one box... weird
[14:36] <pitti> kenvandine: it's been enabled by default for ages
[14:36] <kenvandine> hummm
[14:36] <kenvandine> it prevents cupsd from running on my desktop
[14:36] <kenvandine> and it isn't running on my laptop
[14:36] <dobey> the canberra thing has silly sounds support
[14:37] <kenvandine> pitti: cupsd was working until i rebooted yesterday
[14:37] <pitti> kenvandine: dmesg?
[14:38] <kenvandine> [176590.909239] type=1503 audit(1244641101.197:30): operation="sysctl" requested_mask="r::" denied_mask="r::" fsuid=0 name="/proc/sys/crypto/fips_enabled" pid=8975 profile="/usr/sbin/cupsd"
[14:47] <salty-horse> hi. any idea why the gnome menu's icon search algorithm can't find the icon for kdiff3? it's included in the package and is in a standard place: /usr/share/icons/hicolor/32x32/apps/kdiff3.png
[14:51] <pitti> kenvandine: hm, what's fips? anyway, please report it against cups and assign it to me, easy to fix
[14:52] <pitti> kenvandine: if you do "sudp aa-complain cups", does it start again then?
[14:52]  * kenvandine checks
[14:53] <kenvandine> pitti: works now
[14:53] <pitti> kenvandine: ok, please send current dmesg to the bug
[14:53] <kenvandine> ok
[14:53] <pitti> (after aa-complain and startup)
[14:56] <kenvandine> ok, so send everything in dmesg since i ran app-complain cups?
[14:56] <seb128> salty-horse: what Icon= is used in the entry?
[14:57] <salty-horse> Icon=kdiff3
[14:57] <kenvandine> actually, it's already filed
[14:57] <salty-horse> seb128, ^^
[14:58] <kenvandine> pitti: bug 335898
[14:58] <seb128> salty-horse: does moving /usr/share/icons/hicolor/icon-theme.cache away fixes the issue?
[14:59] <pitti> kenvandine: thanks, I grabbed that
[14:59] <salty-horse> seb128, after moving it, should I refresh something?
[14:59] <kenvandine> pitti: cool
[14:59] <seb128> salty-horse: try to "touch" on the .desktop for the entry
[15:00] <salty-horse> seb128, no difference. menu still shows the default application icon. btw the desktop file is in /usr/share/applications/kde4/kdiff3.desktop
[15:01] <seb128> salty-horse: oh, 32x32 is not the correct dimension for menu items, it's 22 or 24
[15:02] <salty-horse> seb128, so kde's menu standard is different?
[15:02] <seb128> dunno what they do
[15:02] <tjaalton> asac: fyi, unsetting $GTK_MODULES helped, somehow it used canberra directly
[15:03] <salty-horse> seb128, I can find no mention of those dimensions: http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
[15:04] <seb128> salty-horse: why would the icon theme spec dictate what menus are doing?
[15:04] <asac> tjaalton: yeah thats gtk
[15:04] <asac> tjaalton: not sure why and how GTK_MODULES is setup on kde
[15:04] <asac> maybe thats a bug on its own?
[15:04] <salty-horse> seb128, see the "Icon" category of desktop files: http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html -- it mentions no specific dimensions and links to the icon theme spec
[15:05] <seb128> salty-horse: why would a spec dictate what you do with your menu look?
[15:05] <seb128> salty-horse: the goal of a specification is to define a format
[15:06] <tjaalton> asac: it's set up in /etc/X11/Xsession.d/52libcanberra-gtk-module_add-to-gtk-modules
[15:06] <seb128> salty-horse: theorically you could have zoom options for your menu look
[15:06] <tjaalton> asac: and the guy uses fvwm2 :)
[15:06] <salty-horse> seb128, ok. back to gnome. is it a good reason not to load any icon?
[15:06] <seb128> salty-horse: do you have a 24x24 icon to load?
[15:06] <seb128> salty-horse: rescaling a 32x32 icon to 24x24 often doesn't work, or is really ugly
[15:06] <seb128> salty-horse: not there that's better than not displaying an icon
[15:07] <salty-horse> seb128, nope. kdiff comes with in 16x and 32x variants
[15:07] <asac> tjaalton: still interesting that GTK_MODULES gets set ;)
[15:07] <salty-horse> then how about upscaling the 16x16?
[15:07] <seb128> fix it to ship a correct icon for menus then
[15:07] <seb128> try but that's often ugly too
[15:07] <crevette_> can it be also a problem with the gtk icon cache?
[15:07] <seb128> crevette_: no
[15:08] <seb128> crevette_: we delete the icon cache first thing if you read the backlog
[15:08] <seb128> deleted
[15:08] <salty-horse> seb128, but it's "correct" according to spec. seems to me like the gnome implementation isn't flexible enough. (there's probably a good reason for that)
[15:08] <seb128> salty-horse: having no icon displayed is correct indeed
[15:08] <seb128> I'm not sure what you are trying to achieve there
[15:08] <salty-horse> seb128, I actually moved it and it hasn't regenerated yet
[15:09] <tjaalton> asac: well it's for every desktop, but maybe that should be narrowed down
[15:09] <salty-horse> I'm trying to see the icon :)
[15:09] <seb128> standard menus icons are 24x24 fix your buggy software to ship an icon with the correct format and it will work
[15:09] <salty-horse> seb128, where is that standard written?
[15:09] <asac> tjaalton: i think we shouldnt enable gtk modules that rely on gnome settings in DE's other than those that support to configure them
[15:09] <seb128> salty-horse: you don't need an icon cache when it's not there you are sure it's not masking anything
[15:09] <tjaalton> asac: yeah, I'll file a bug
[15:10] <asac> great
[15:10] <seb128> salty-horse: no, as I tried to explain you before standard are to describe format, they are not there to dictate graphical preferences to users
[15:10] <seb128> salty-horse: you could have an option "zoom" for menus which let you choice 16, 24, 32, 48 icons for entries
[15:10] <seb128> salty-horse: that would be a valid option, why a specification forbid you to do that?
[15:11] <seb128> salty-horse: those are the standard sizes, if you want your application to work in flexible situations ship those that's what most softwares do
[15:11] <salty-horse> seb128, I understand that. I'd like to know where is gnome menu's preference of 24x24 is documented. if I want to file a kdiff bug I need some more info, and I can't find it
[15:12] <seb128> salty-horse: it's the value used, you want each choice to be publicly described in a official signed document on a website or what?
[15:12] <seb128> salty-horse: read the code?
[15:12] <seb128> but that start being ridiculous, why do you ask if you don't trust what people tell you?
[15:12] <salty-horse> yes, I want it to be publicly described, as it should. I'm not saying I don't trust you, I want it to be documented. and if it's not, that's another bug I'll try and fix :)
[15:12] <seb128> *as it should*
[15:13] <seb128> gnome-panel code writer do write code
[15:13] <seb128> there is no reason they should start keeping some journal of the code variable values online for no reason
[15:14] <salty-horse> seb128, interoperability is a good reason, I think. I'll ask the gnome-panel peeps then.
[15:14] <salty-horse> thanks for the info!
[15:14] <Mark__T> tedg: any roadmap for indicator-applet 0.2?
[15:15] <tedg> Mark__T: Roadmap meaning dates or features?
[15:16] <Mark__T> tedg: maybe combination of both
[15:17] <tedg> Mark__T: Don't have any specific dates other than the Ubuntu release schedule, WRT features we have the blueprint that we did at UDS.  Let me look up the link.
[15:17] <tedg> Mark__T: If there are specific dates you need, I'd be happy to take them into consideration (assuming they're not tomorrow ;) )
[15:18] <crevette_> asac, what is the relation of couchdb with mozilla, I've seen you just uploaded it
[15:18] <crevette_> sorry for being curious
[15:18] <kenvandine> crevette_: no relation to mozilla
[15:18] <tedg> Mark__T: https://wiki.ubuntu.com/MessagingMenu/UDSKarmic
[15:18] <asac> pochu: are you the right one to prod about eclipse?
[15:18] <asac> crevette_: look at the changelog ;)
[15:18] <crevette_> hey kenvandine
[15:18] <kenvandine> hey crevette_
[15:19] <asac> crevette_: couchdb uses libmozjs ... which is a problem on its own. it still used the 1.8 libmozjs so i ported/hacked it to use xulrunner 1.9 now
[15:19] <kenvandine> asac: oh weird
[15:19] <asac> trying to fix bug 352968 finally
[15:23] <seb128> why can't bzr just push by default to the same location you used for the get
[15:23] <seb128> grr
[15:24] <dobey> seb128: or the same place you pushed to previously
[15:24] <seb128> it does that I think
[15:24] <asac> seb128: i think the idea is that if you work on a branch directly you use checkout
[15:24] <asac> dobey: it does that
[15:24] <seb128> I do sponsoring
[15:24] <crevette_> asac, should I send a mail on ubuntu-dev to ask people with bluetooth device to test it?
[15:24] <seb128> I do bzr get whatever is to sponsor
[15:24] <asac> dobey: we.. it pushes to the location you first pushed ... unless you change that with --remember
[15:25] <seb128> change the target to karmit
[15:25] <crevette_> s/it/gnome-bluetooh/
[15:25] <seb128> and bzr push and get an error
[15:25] <asac> crevette_: not yet. we need to also update bluez i think
[15:25] <seb128> then I've to figure the url again, copy it, etc that's ridiculous
[15:25] <asac> crevette_: lets call for testing after we updated the whole bt stack
[15:25] <crevette_> asac, 4.40 is supposed to work with it, myself I use gnome-bluetooth git master and it works fine
[15:26] <seb128> asac: checkout and get are not the same thing?
[15:28] <dobey> james_w: https://code.edge.launchpad.net/~dobey/ubuntu/karmic/icontool/karmic <- does this look correct for a source package branch? :)
[15:34] <asac> seb128: no checkout binds your branch
[15:34] <james_w> dobey: tarball-in-tarball packaging?
[15:35] <asac> seb128: meaning that each commit gets automatically pushed (so no more forget to push)
[15:35] <asac> seb128: oh sorry. not sure about "get" ... branch vs. checkout are definitly different
[15:36] <asac> but given that you complain about not remembering where to push i would think that "get" is like "branch"
[15:36] <dobey> james_w: hrmm?
[15:36] <pitti> I think he's just complaining about "bzr push" not having any default
[15:37] <james_w> dobey: it looks like tarball-in-tarball packaging, but the rules file doesn't look like it copes with that
[15:37] <asac> right. my answer was use "checkout" ;) ... which most likely is what he wants anyway
[15:37] <seb128> asac: I don't want every commit to go online
[15:37] <asac> but i agree that the pull branch should be implicitly the push branch
[15:37] <dobey> james_w: i don't know what you mean by tarball-in-tarball
[15:37] <james_w> so if you've no idea what tarball-in-tarball is then you've probably done something wrong :-)
[15:37] <seb128> asac: I want get and push to be smart by default
[15:37] <james_w> dobey: why did you commit a tarball to the branch?
[15:38] <dobey> james_w: i was trying to emulate what the libnss-ldap has
[15:38] <james_w> ah
[15:38] <james_w> bad choice :-/
[15:38] <dobey> james_w: and it has the debian dir, tarball and md5
[15:39] <dobey> james_w: oh. bad example for the UDS session then :)
[15:39] <james_w> because it uses tarball-in-tarball packaging
[15:39] <james_w> yeah, I should have checked first :-)
[15:40] <james_w> if you do "apt-get source libnss-ldap" you'll see the unpacked source package looks unlike most other packages
[15:40] <james_w> what you want there instead is the source that's in the tarball, not the tarball itself
[15:40] <seb128> james_w: is there a variable I can set or a config to change to get push to use the get location by default?
[15:41] <james_w> seb128: nope
[15:41] <james_w> you can "bzr push :parent"
[15:41] <dobey> james_w: oh, so it should be branch_tag + debian/?
[15:41] <james_w> but there's no config for it, or option to "get" currently
[15:41] <james_w> yeah
[15:41] <dobey> james_w: for things that are also in bzr already anyway
[15:41] <seb128> james_w: ok ... thanks anyway!
[15:42] <james_w> dobey: yeah, if you "bzr branch" your upstream branch and then add the "debian" directory to that, commit it and push it up you should have the right thing
[15:42] <dobey> james_w: ah ok.
[15:43] <james_w> I should write "bzr dh_make" or something
[15:43] <kenvandine> james_w: you should!
[15:44] <james_w> hey kenvandine
[15:44] <james_w> thanks for working on that empathy patch
[15:44] <dobey> bzr dh_make_me_some_toast
[15:44] <kenvandine> james_w: happy to do it :)
[15:44] <kenvandine> james_w: thanks for the first pass :)
[15:44] <kenvandine> james_w: have you played with it?
[15:44] <james_w> I have "bzr make-me-a-sandwich" already
[15:44] <kenvandine> it is built in my ppa
[15:44] <kenvandine> james_w: haha
[15:44] <james_w> I haven't tried your updated version yet, sorry
[15:45] <james_w> let me know if I can explain anything needed to fix it for the review comments
[15:45] <kenvandine> james_w: ok
[15:45] <kenvandine> i made some changes, like moved the config to the notifications tab
[16:09] <asac> crevette: so wanna help getting latest bluez?
[16:10] <asac> or are you saying that 4.40 is definitly good enough?
[16:10] <asac> i think we need more recent bluez also for pulseaudio
[16:17] <crevette> asac, no pulseaudio 0.9.15 should work with few latest version of bluez, I don't remember how the precise version but perahps 4.34
[16:18] <asac> crevette: anyway. i would feel safer if we have latest upstream release ;)
[16:19] <asac> Release of bluez-4.41
[16:19] <asac> This release contains multiple fixes for the audio subsystem and makes the Bluetooth daemon itself more and more stable.
[16:19] <crevette> asac, this is the usual message for each release :)
[16:19] <asac> point is i dont want to ask people to stress test stuff if there  is a new bug fix release out there
[16:20] <asac> especially audio which is flaky enough ;)
[16:21] <crevette> bluez developpers follow the guidelines "release early, release often", and if you want my opinion, this is rather "release really early, release too often"
[16:21] <crevette> :)
[16:22] <crevette> but this is getting better and better, in jaunty I was not able to play sound to my bluetooth gateway, I had a lot of cut in the stream, now it is working seamlessly (with 4.40)
[16:22] <asac> crevette: so you dont want to do the new upstream? ;)
[16:23] <crevette> not what I said, to be honest I thought Mario Limenciello would do it :)
[16:23] <crevette> Limonciello
[16:24] <asac> ok i check with him
[16:25] <crevette> is Mario working for canonical?
[16:25] <crevette> after 4.41, we need to check delta with debian
[16:32] <dobey> ugh. so uname -r doesn't really work so well in the build farm
[16:40] <asac> awe: there?
[16:41] <awe> asac: yea
[16:41] <awe> asac: with a working computer...
[16:41] <awe> ;/
[16:43] <asac> great ;)
[16:44] <asac> awe: what did you buy?
[16:44] <awe> another macbook
[16:44] <awe> now i'm stuck with the broadcom 'wl' driver for good.
[16:46] <pochu> asac: not really, I was quite happy when I stopped being TIA ;)
[16:48] <asac> pochu: could you do one last thing ... figuring out why we are not yet using xulrunner-dev :(
[16:48] <pitti> rickspencer3-afk, seb128, asac: FYI, bug 81575; it's scheduled for LP 2.2.6
[16:48] <seb128> pitti: \o/
[16:48] <pitti> awe: ooh, new toy? \o/
[16:49] <awe> pitti: yea...still trying to get everything working!  ;)
[16:49] <seb128> hum
[16:49] <seb128> tomorrow is a national holiday for germany?
[16:49]  * seb128 needs a world national holidays calendar
[16:50] <asac> amen
[16:50] <asac> seb128: most likely only for the weak germans that consider themselves highly religious
[16:50] <asac> so south/east germany
[16:50] <seb128> lol
[16:50] <asac> i dont have holiday here
[16:50] <asac> bavaria has 10 more public holidays or so than we have
[16:51] <seb128> ok good, I will not be alone working tomorrow ;-)
[16:51] <asac> they celebrate even the second hick-up of jesus in his 6th live of living ;)
[16:51]  * pitti hugs seb128 and asac and joins them for the Thursday workforce
[16:51]  * seb128 hugs pitti
[16:51] <asac> yay!
[16:51] <awe> ahhhh...  german political correctness ( or the lack thereof ).  I luv it!  ;/
[16:51] <pitti> asac: *chuckle*
[16:52] <asac> sorry if my statement offended someone :)
[16:55]  * asac install gjdoc to see where it stores its version
[16:58] <XCP2> hi. there's a bug in xorg in the newer versions of ubuntu that has not been fixed. however, there is a PPA on launchpad that apparently fixes the problem (not in clean way, but it's okay for me). Now my question: if I apply this PPA patch and some time later there is an official ubuntu patch for this problem, or any other update to xorg, will and can this newer update still be applied, although I manually changed my xorg some time before?
[16:59] <seb128> depends of the ppa
[16:59] <seb128> don't install random package from random ppa if you want no surprise
[16:59] <Ampelbein> XCP2: what is the version of the package in the ppa?
[16:59] <seb128> if that's from the official xorg ppa that's probably ok
[17:00]  * dobey hopes his first REVU upload is correct
[17:00] <seb128> they are still using revu?
[17:01] <XCP2> here's the link... https://edge.launchpad.net/~ubuntu-x-swat/+archive/xserver-no-backfill ... it fixes a problem in xorg, which causes xorg to use up 6GB+ memory after a while and take it 3-4 seconds to maximize a single window, each time leaking memory..
[17:01] <dobey> seb128: "they"?
[17:01] <seb128> XCP2: try on #ubuntu-x for xorg question
[17:01] <seb128> dobey: the motu team or whoever is using revu nowadays
[17:02] <XCP2> Ampelbein: the version of the package is 'jaunty main'. if that's what you are referring to?
[17:02] <dobey> seb128: i hope so. statik asked me to get icontool up on REVU for inclusion in karmic. and we'll have other packages to get in as well, that we need for ubuntuone-* packages
[17:03] <seb128> they probably do, universe workflow has been based on it for a while
[17:03] <seb128> I just don't see the point of the whole thing and dislike it
[17:04] <dobey> ah
[17:06] <seb128> wth
[17:06] <seb128> mvo: !!!
[17:07]  * mvo hides from seb128
[17:07] <seb128> mvo: something is eating my ram and I though that was compiz but it seems I was wrong ;-)
[17:07] <seb128> mvo: you can unhide
[17:07] <mvo> *pffeeewww*
[17:07]  * mvo crawls out from under the desk
[17:07] <seb128> I would still like to know where my 2G of ram are being used when top list nothing excessive
[17:08] <mvo> firefox ;) ?
[17:08] <seb128> I had the issue 2 hours ago
[17:08] <seb128> 2Go of RAM and 3.5G of swap eaten
[17:08] <dobey> firefox, evolution <- i tend to find these to be blameworthy
[17:08] <seb128> and the linux scheduler doesn't work enough to make you do anything
[17:09] <seb128> 293m  97m  16m S    0  4.9   2:21.65 evolution
[17:09] <seb128> and I've closed my web browser already
[17:09] <seb128> 1047m  28m 7624 S    1  1.4   2:22.13 compiz.real
[17:09] <seb128> the 1047m for compiz is weird though
[17:09] <seb128> but that's only VIRT
[17:10] <seb128> still
[17:10] <seb128> mvo!!!!!!
[17:10] <dobey> rhythmbox likes to get high on the VIRT list too
[17:10] <seb128> mvo: why compiz is using over 1G of virt memory
[17:10] <mvo> it should not use that much
[17:10] <seb128> I knew I should have stayed on jaunty ;-)
[17:10] <pochu> asac: I guess it would need to be ported :-)
[17:10] <mvo> I supsect it might be a leak in the X server?
[17:10] <dobey> 12690 dobey     20   0  488m 199m  25m S  0.7 19.9  96:45.89 epiphany-browse
[17:11] <dobey> nice
[17:11] <seb128> mvo: dunno
[17:11] <pochu> asac: or upgraded to a newer version
[17:11] <dobey> although, epiphany has other issues
[17:11] <dobey> so eh
[17:11] <pochu> asac: it's using xulrunner 1.8 right now
[17:13] <asac> pochu: i know that its using xul 1.8
[17:13] <asac> which has to change this cycle
[17:13] <asac> otherwise i am not sure what will  happen
[17:13] <pochu> there was an eclipse session at UDS
[17:13] <pochu> as to what to do with it, it's quite outdated but the package is huge and complicated
[17:13] <asac> pochu: was there anyone who seemed to take ownership of eclipse?
[17:13] <pochu> the current codebase is a few years old
[17:14] <pochu> I wasn't in the session, but I've read the notes
[17:14] <pochu> sec
[17:14] <pochu> asac: https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-karmic-eclipse-update
[17:14] <asac> thanks
[17:15] <pochu> so I guess if it's updated, the new code will use Xul 1.9
[17:15] <pochu> but I haven't checked it
[17:17] <hyperair> pitti: i noticed you were working on getting the fn keys stuff working for whatever's replacing hal for it. are the screen brightness keys included in that?
[17:17] <pitti> hyperair: all the keys; however, my primary concern is the keys being recognized
[17:18] <pitti> hyperair: I'm not working on e. g. getting kernel support for sony vaio backlights
[17:34] <seb128> ok, enough work for today now
[17:35] <seb128> let's try going swimming again ;-)
[17:39] <Ampelbein> seb128: have fun swimming.
[17:40] <seb128> thanks!
[18:06] <hyperair> pitti: what about regressions? e.g. they used to work prior to dropping the 30-keymap-whatever fdis?
[18:06] <pitti> hyperair: that's the kind of bug I'm interested in
[18:06] <hyperair> pitti: that's the case, at least for me.
[18:06] <hyperair> what information do you need?
[18:06] <pitti> hyperair: please follow /usr/share/doc/udev-extras/README.keymap.txt and do 'ubuntu-bug udev-extras'
[18:06] <hyperair> alright
[18:06] <pitti> hyperair: thanks!
[18:07] <hyperair> no, thank you for working on this =)
[18:12] <hyperair> pitti: it doesnt seem to detect my brightness key O_o
[18:12] <pitti> hyperair: hm, I translated the hal-info ones one-to-one
[18:12] <hyperair> hmm maybe it's modesetting..
[18:12] <hyperair> i'll try boot without modesetting and see
[18:13] <pitti> hyperair: please check with /lib/udev/keymap -i
[18:13] <hyperair> i did check
[18:13] <hyperair> there was no response at all
[18:13] <hyperair> at least, nor from fn keys
[18:13] <pitti> if it brings the right key name, but doesn't do anything, then it's likely KMS
[18:13] <pitti> hyperair: use findkeyboard
[18:13] <hyperair> hmm
[18:13] <hyperair> yes i used that
[18:13] <hyperair> there was a response with every other fn key
[18:13] <hyperair> just not the brightness ones
[18:14] <pitti> hm, odd
[18:14] <pitti> hyperair: maybe they are attached to a different input device
[18:14] <hyperair> another? O_o
[18:15] <hyperair> lemme try one by one
[18:17] <awe> asac: do you have the bug # for the bug that includes the "disable background scanning patch" we discussed @ UDS?
[18:17] <hyperair> pitti: what are the brightness key names?
[18:18] <pitti> hyperair: brightness{up,down}
[18:19] <asac> awe: yes. let me check
[18:19] <hyperair> pitti: the dump from /lib/udev/keymap input/event5 didn't have anything of that sort
[18:20] <pitti> hyperair: seems your kernel doesn't generate an input event for the keypresses then
[18:20] <pitti> hyperair: can you please check with acpi_listen if you get acpi events?
[18:21] <pitti> hyperair: and then "ubuntu-bug linux" with the acpi events and missing keys?
[18:21] <pitti> hyperair: unless they are being sent through another input device, of course
[18:24] <pitti> good night everyone
[20:57] <Steven666> how do i make ubuntu desktop unhackible?
[21:00] <crevette> asac: I discussed with Mario, he reviewed the delta between ubuntu & debian bluez package yesterday, and syncing is okay for him
[21:00] <crevette> we just need to wait to have 4.41 on debian, or slap filippo to motivate him
[21:06] <asac> crevette: ok. i already talked to him too
[21:06] <MenZa> &w 61
[22:33] <chrisccoulson> hi seb128 - is there any packaging work to do over the next few days?
[22:33] <seb128> chrisccoulson: hey, depends of the few days definition, new 2.27 due next week
[22:34] <chrisccoulson> yeah, that should be good:)
[22:34] <seb128> do you want something to do before?
[22:34] <seb128> there is a tracker 0.6.95
[22:35] <seb128> but I'm not sure if you track tracker 0.7 now?
[22:35] <chrisccoulson> i've been looking at tracker 0.7 but its not ready for upload yet
[22:35] <chrisccoulson> too much stuff doesnt work yet and there's still a lot of big architectural changes before 0.7 is released too
[22:36] <chrisccoulson> i could do 0.6.95 for now
[22:36] <seb128> ok so you might want to do the 0.6 update
[22:36] <chrisccoulson> yeah, i can work on that
[22:36] <seb128> there is gnome-themes and bug-buddy to update to 2.27 too
[22:36] <seb128> if you are bored, they are not high priority but need to be done at some point with resyncing on debian
[22:36] <chrisccoulson> yeah, i'll take a look at those if i get the chance, and if someone else hasn't already done them
[22:37] <seb128> I don't think anybody has been working on those and they are available for some weeks so they are probably ok
[23:39] <rickspencer3> bryce: hey wiki King, is there a wiki page that I can point mdz to regarding -ati instead of fglrx for R500?
[23:40] <bryce> ummm yeah there is at https://wiki.ubuntu.com/X/Drivers
[23:41] <bryce> there isn't an in-depth discussion about it anywhere afaik; ATI had this under NDA for a long time so I didn't write anything up, but I'd be happy to explain in more depth if there are particular questions
[23:41] <rickspencer3> https://help.ubuntu.com/community/RadeonDriver
[23:41] <rickspencer3> ?
[23:41] <rickspencer3> bryce: tx
[23:42] <rickspencer3> I already sent mdz ^^^
[23:42] <bryce> that h.u.c page looks pretty out of date.  A lot of what it says to do is no longer necessary
[23:43] <rickspencer3> oh
[23:43] <rickspencer3> oops
[23:43] <rickspencer3> I suck
[23:43] <rickspencer3> it seemed to be updated to include Jaunty
[23:44] <rickspencer3> is w.u.c/X/Drivers, better?
[23:44] <bryce> yep
[23:44] <bryce> more authoritative anyway
[23:44] <rickspencer3> ok
[23:45] <rickspencer3> I'll reply to my own mail :)
[23:45] <bryce> help.ubuntu.com is such a hodge-podge of conflicting info, I mostly confine myself to the X pages in wiki.ubuntu.com as a more tractable set
[23:47] <bryce> rickspencer3: ah yes the portion of that page you quoted is accurate.  Not sure who wrote that, but it's consistent with the Drivers page
[23:47] <rickspencer3> bryce: ack
[23:47] <rickspencer3> I sent mdz your link as well, so all is good
[23:47] <bryce> cool