[02:07] <Bojhan> Hey
[02:08] <Bojhan> I am wondering who I should contact regarding usability/ux projects/efforts in ubuntu?
[07:27] <pitti> Good morning
[07:51] <pitti> asac: ah, I think I identified the culprit: it seems to happen while trying to apply patches to generate the sourceful stack trace; debian/rules setup seems to trigger starting xulrunner
[07:52] <mvo> is the retracer running again (I guess it takes a bit of time to catch up again). bug #347602 is why I ask
[07:53] <pitti> mvo: it got stuck again
[07:53] <pitti> mvo: I just killed them, and will now work around it by disabling sourceful stack traces
[07:54] <mvo> thanks pitti
[08:22] <tonyyarusso> Any chance I could get someone to take a look at a small pet bug for my dad?  (It's the last thing keeping him from using OOo apparently.)  He filed a report at https://bugs.edge.launchpad.net/openoffice/+bug/275676
[08:26] <asac> pitti: huh?
[08:26] <asac> pitti: isnt it just ".postinst"?
[08:26] <asac> we run xulrunner --gre-version
[08:27] <pitti> asac: haven't looked at the package yet, just applied the workaround for now (disabling sourceful stack trace)
[08:27] <pitti> asac: I'll try to get back to this in the afternoon and take a closer look
[08:27] <asac> pitti: well. if its the same issue from yesterday i can confirm that simply installing xulrunner-1.9.1 in fakechroot hangs
[08:28] <pitti> ah, okay
[08:28] <pitti> asac: I have a handful of such cases, I usually just dpkg-divert them away and replace them with a no-op shell script
[08:29] <asac> oh so xulrunner isnt alone? thats good to know ;)
[08:29] <asac> its the postinst you would need to prevent somehow i guess
[08:30] <pitti> asac: gconf-schemas and polkit-auth also give trouble, yes
[08:30] <pitti> and ucf
[08:31] <pitti> asac: as long as the number of affected programs is so small, it's easier to divert them away than trying to fix fakechroot for each and every corner case
[08:32] <asac> pitti: thats good. as long as that doesnt mean we wont get backtraces for xul 1.9.1 at least
[09:05] <seb128> good morning there
[09:05] <seb128> pitti: hello
[09:06] <didrocks> good morning seb128 :)
[09:06] <seb128> lut didrocks
[09:06] <didrocks> seb128: are you enjoying being in UK?
[09:06] <pitti> bonjour seb128
[09:06] <seb128> didrocks: yes, being in London and at the canonical office is always nice ;-)
[09:06] <didrocks> hi pitti
[09:06] <didrocks> seb128: great! ;)
[09:10] <seb128> pitti: did you read the xulrunner discussion yesterday?
[09:10] <pitti> seb128: yes; I think it hung on the "get sourceful stacktrace" step, when trying to apply patches
[09:11] <seb128> pitti: hum, what we figured with asac is that it hangs on the xulrunner --gre-version
[09:11] <pitti> seb128: I disabled that for now and restarted them
[09:11] <seb128> ok that was my question
[09:11] <seb128> thanks
[09:11] <seb128> I close IRC and went to the pub just after asac suggested that
[09:12] <seb128> so I didn't know what happened next
[09:12] <asac> pitti: so you disabled xulrunner-1.9.1?
[09:12]  * seb128 hugs pitti
[09:12] <pitti> let's see how it goes
[09:12] <pitti> seb128: I'll look into a more proper workaround this afternoon
[09:12] <pitti> seb128: I think I can just dpkg-divert the xulrunner binary
[09:12] <asac> i just want to know if there is action required from my side if i want to get backtraces for xul 1.9.1 or not ;)
[09:12] <pitti> asac: not yet, working on some other stuff still
[09:13] <asac> ok let me know. we can probably eliminate the xulrunner --gre-version invocation if thats needed.
[09:13] <pitti> asac: you should get them again
[09:17] <pitti> it shouldn't run the postinst in the first place
[09:19] <asac> ah ok.
[09:23] <crevette> hello
[09:24] <asac> hi crevette
[09:24] <crevette> hey asac
[09:40] <asac> is there a "advanced new bug" page or something for bgo where i can do everything on one page?
[09:41] <asac> hmm i cant find gtkhtml3 in bgo
[09:42] <seb128> asac: it's gtkhtml there
[09:42] <seb128> asac: and what do you mean, there is everything on the same page in bgo
[09:42] <seb128> asac: http://bugzilla.gnome.org/enter_bug.cgi?product=gtkhtml
[09:42] <seb128> I guess you opened the simple form ui rather than this one
[09:43] <seb128> no?
[09:43] <asac> seb128: could be ... i didnt expect that simple form is decided on first page ... let me check
[09:43] <asac> i am blind yeah
[09:43] <asac> still odd that i only could find gtkhtml2 on the simple form ;)
[09:43] <seb128> asac: it's written (simple form), did you click there? ;-)
[09:44] <asac> seb128: its not even on this page: http://bugzilla.gnome.org/enter_bug.cgi
[09:44] <asac> only gtkhtml2
[09:44] <seb128> asac: it's listed there
[09:44] <asac> seb128: i clicked on "New bug" on the top ;)
[09:44] <seb128> asac: GtkHtml
[09:44] <seb128> in the desktop section
[09:44] <asac> sigh
[09:44] <seb128> " GNOME's lightweight engine for the rendering, printing and editing of HTML."
[09:44]  * asac puts new eyes on his wishlist
[09:44] <seb128> asac: you should get some coffee ;-)
[09:50] <asac> seb128: so is gtkhtml we have mostly trunk or i should i look if the patch is relevant on trunk before submitting?
[09:53] <seb128_> re
 asac: we have mostly trunk, ie the tarball is a week old and they are not that active on it
[09:54] <asac> ouch
[09:54] <asac> a new brain too.
[09:54]  * crevette wishes gtkhtml will be replaced by something better (webkit)
[09:57] <asac> right i have to check webkit too
[09:57] <asac> what is using webkit?
[10:02] <crevette> asac, some projects are migrtating like lifearea
[10:03] <crevette> some Novell developer involved in evolution are rewriting a lightweight mail client for small form factor called anjal using webkit too
[10:04] <crevette> asac, http://blogs.gnome.org/sragavan/2009/03/18/announcing-anjal-the-new-mail-for-netbooks/
[10:07] <seb128_> crevette: it's not a rewrite, it's a new UI but it's still using evolution
[10:08] <crevette> seb128_, yeah it on top on eveolution
[10:11] <andreasn> crevette, there is a devhelp branch using webkit as well
[10:12] <seb128_> asac: did you consider webkit 1.1 for jaunty btw?
[10:12] <crevette> hey andreasn,
[10:12] <crevette> andreasn, I was searching the one which were switch from gtjhtml to webkit, devhelp use moz I guess
[10:12] <andreasn> yes, it does
[10:15] <crevette> asac, the patch in http://bugzilla.gnome.org/show_bug.cgi?id=576694 seems broken
[10:16] <crevette> s/broken/not a patch/
[10:17] <seb128_> it's a patch with noise too ;-)
[10:18] <mvo> pitti: what is the best way to debug http://people.ubuntu.com/~mvo/tmp/Fehler.png ?
[10:18] <pitti> mvo: f-spot remembers the previously used directory and selects it by default; if it doesn't exist, it brings up that error message
[10:19] <pitti> mvo: it should just check if it doesn't exist any more, and silently select the default folder instead IMHO
[10:19] <mvo> pitti: this was a fresh instrepid install with upgrade
[10:19] <mvo> pitti: ok, I can have a look at the code
[10:19] <asac> crevette: thanks indeed
[10:19] <pitti> mvo: if you find a bug, I heard that robert_ancell is interested in the mono stack
[10:19] <pitti> mvo: LP bug report, I mean
[10:20] <crevette> asac, you're welcome I'm so bored at work I read patch incoming for gnome :/
[10:20]  * robert_ancell regrets this already...
[10:20] <seb128_> crevette: you could triage bugs ;-)
[10:20] <crevette> I could ... but this is much work
[10:20] <asac> crevette: thats indeed interesting ;)
[10:20] <pitti> robert_ancell: cowtrading season is open
[10:20] <asac> dont let your boss find the channel log
[10:23] <asac> we need text file preview in gtk file selector ;)
[10:23] <seb128_> pitti: who wants to trade when you can give things away? ;-)
[10:23] <crevette> asac, I'm not a slacker I do some work though
[10:23] <seb128> crevette: you could triage bugs!
[10:23] <seb128> and prove you are not slacking ;-)
[10:25] <crevette> seb128, it was about my day work, but i'm not slacking for ubuntu, I raise my karma from 1000 to 5000 damn it !!
[10:25] <crevette> :)
[10:26] <seb128> good work ;-)
[10:26] <seb128> it's nice that you work on the bluetooth satck
[10:26] <seb128> stack
[10:26] <crevette> yeah, I'm not that happy, I don't understand that much bluetooth
[10:27] <seb128> good chance to learn ;-)
[10:29] <crevette> yeah :/
[10:31] <didrocks> crevette: I'm sure seb128 will be delighted if you put some work on Compiz as well :p
[10:32] <crevette> I don't use compiz and I don't wanna have to learn what it is
[10:32] <crevette> :)
[10:32] <didrocks> :)
[10:33] <seb128> didrocks: ok, you can get compiz if you really insist!
[10:34] <didrocks> seb128: let's say I'm not using it too ;) And I know that you are so eager to maintain the associated package that it will be a crime to remove this pleasure to you :)
[10:35] <didrocks> seb128: and first, I'm going deeper in GNOME technology first :) reading http://library.gnome.org/devel
[10:35] <crevette> didrocks, and not being cano I can easily refuse any assignment on compiz :)
[10:36] <didrocks> crevette: yeah, no tag to push for us ;)
[10:36] <pitti> please note that compiz has a very responsive upstream
[10:37] <didrocks> pitti: I think it's not a problem of responsive upstream, but more to go deep in the code, managing graphics layers, etc. I think that getting into the code might be more than time-consuming
[10:38] <didrocks> it's a really good piece of work, but I don't know how new people easily can get into it
[10:38] <pitti> didrocks: I don't think that mvo did much hacking on the code iself either
[10:39] <pitti> don't get me wrong, I'm not trying to push the package on you
[10:39] <pitti> but from my perspective it seems that maintaining compiz is more a "keep good relations to upstream" and "do good bug triage" problem than hacking on the code yourself
[10:39] <pitti> mvo: ^ what are your experiences so far?
[10:39] <pitti> mvo: i. e. what would you hand out as a 'job description'?
[10:40] <didrocks> yeah, I think that having mvo point of view is the right way :)
[10:40] <seb128> ok, I already asked that before
[10:40] <seb128> but where would you put a list of packages <-> usual maintainer
[10:41] <mvo> pitti: yes, that is a good description, preparing updates, keep an eye on the git tree and be nice to upstream (they are always very nice to us)
[10:41] <seb128> I was thinking desktop-bugs or ubuntu-desktop team bzr on launchpad
[10:41] <pitti> seb128: you want to keep that as a static list?
[10:41] <seb128> I'm open to suggestions
[10:42] <pitti> seb128: or something like "set of uploaders of last 10 uploads"?
[10:42] <seb128> what I see is a list of packages the team maintain
[10:42] <seb128> and who is usually doing updates
[10:42] <mvo> I don't mind doing updates, compiz is fun really, the problem is that I suck at bug triage
[10:42] <seb128> ie if somebody usually does ask him or her before starting on an update
[10:43] <seb128> I'm usually doing the gvfs and nautilus updates for example because I track upstream changes closely etc
[10:43] <asac> hmm ... is there a way for me to grep through the full gnome svn ?
[10:43] <seb128> so I don't want somebody to jump on those because I'm not around
[10:43] <pitti> seb128: my initial gut feeling is that this could just be a dynamic list
[10:43] <seb128> but nobody is working actively on, let's say gucharmap and that is free to claim by contributors
[10:43] <seb128> ie first to come = first served
[10:44] <pitti> seb128: ah, I see; so for gucharmap the changelog scanning wouldn't say "free for all"
[10:44] <asac> seb128: how about setting Maintainer to seb128@ubuntu.com for those packages that you care really hard about
[10:44] <asac> ;)
[10:44] <pitti> and for the others, ubuntu-desktop@
[10:44] <asac> yes.
[10:44] <didrocks> I saw that in some packages already
[10:45] <asac> well at lesat mozillateam sets it to mozillateam to indicate that folks should talk to us first before touching.
[10:45] <asac> so if ubuntu-desktop is too broad you can narrow it down by your own name
[10:45] <seb128> asac: well what we do know is that I dispatch updates on IRC
[10:46] <seb128> but I'm not always around and I don't want to block work
[10:46] <seb128> and it would be better to have a public list of what is being worked by who
[10:46] <asac> yeah. thats a workflow system ;)
[10:46] <asac> you could auto create a batch of Needs packaging bugs
[10:46] <asac> when tarballs get rolled upstrream
[10:46] <asac> and then use the assignee notion
[10:48] <seb128> right, I don't fancy opening 70 bugs every new GNOME week
[10:48] <seb128> it's lot of "paper work"
[10:48] <seb128> and waiting on launchpad
[10:48] <crevette> seb128, back to bluetooth, the problem is bluez doesn't have a BTS which is really boring
[10:50] <asac> seb128: autocreating bugs would be ok though? or even too heavy weight?
[10:51] <seb128> it feels like lot of paper work to me
[10:51] <seb128> we could have a table which lists upstream versions and current jaunty ones
[10:51] <pitti> seb128: what about a social solution to just tell every contributor to check the changelog and Maintainer: field first?
[10:51] <seb128> and say that anybody is free to claim anything not update
[10:51] <pitti> seb128: http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html is pretty neat
[10:51] <seb128> so we would move the maintainer info to individuals?
[10:52] <asac> so you want merge-o-matic for upstream with work assignment feature ;)
[10:52] <seb128> pitti: right, something around those lines
[10:52] <seb128> asac: not really mergo-o-matic is about producing diffs no?
[10:53] <seb128> asac: well something around that for updates yes
[10:53] <asac> seb128: yeah i referred to the "newer version in upstream part"
[10:53] <seb128> ie listing things not uptodates as we list merges to do would be nice yes
[10:53] <asac> maybe talk to scott ... gnome tarballs should be as debian packagesjust that they dont have a debian/ dir ;)
[10:54] <seb128> we have plenty of similar pages already
[10:54] <seb128> see the ubuntu-x page pitti just gave
[10:54] <seb128> the pkg-gnome debian team has one too
[10:55] <didrocks> seb128: this one: http://www.0d.be/debian/debian-gnome-2.26-status.html ?
[10:55] <seb128> yes
[10:55] <asac> but if you just that that and you cannot claim a "tarball" it doesnt solve your initial problem?
[10:55] <asac> or is your initial problem that you have to hand out tasks ?
[10:55] <seb128> right we want:
[10:55] <seb128> - a list
[10:55] <seb128> - an easy way to claim updates on this list
[10:55] <asac> yeah. claiming updates should be like making a timed lock
[10:55] <seb128> which are somewhat orthogonal things
[10:55] <asac> e.g. for 36 hours or so
[10:56] <asac> or whatever time seems reasonable
[10:56] <seb128> I was thinking just have a bzr where you add a line "source name"
[10:56] <seb128> to claim that you work on "source"
[10:56] <seb128> and have the page code looking that that bzr
[10:56] <seb128> we could also have a small command list tools
[10:56] <seb128> ie, list-to-do
[10:57] <asac> seb128: so if we want to look for the future claiming could simply be creating a new
[10:57] <seb128> which would list available updates and being worked ones just by using watch files and this bzr todo list
[10:57] <asac> UNRELEASED changelog entry
[10:57] <asac> in bzr
[10:57] <asac> e..g
[10:57] <pitti> seb128: on a tangent, retracers are grinding
[10:57] <seb128> well, that's not because you fix a typo in the control description and don't want to upload that you want to keep a lock on the source
[10:57] <asac> dch -i -DUNRELEASED "*new gnome tarball x.x.x"; then commit means its claimed
[10:57] <seb128> pitti: excellent
[10:58] <asac> i mean if you could just express that you work on it in the bzr tree where you will work on directly it makes most sense, no?
[10:58] <asac> instead of maintaing a different file that everybody has to remember to use and so on
[10:58] <seb128> right
[11:01] <asac> so how about the idea of claiming through UNRELEASED changelog entry
 well, that's not because you fix a typo in the control description and don't want to upload that you want to keep a lock on the source
[11:01] <asac> and a website that parses bzr trees for versions currently worked on
[11:01] <asac> (and how long idle)
[11:01] <asac> seb128: hmm
[11:01] <asac> valid argument.
[11:01] <seb128> my feeling is that bugs are too much of a constrain
[11:01] <seb128> and that changelog updates are racy and don't work in all cases
[11:01] <seb128> we used the wiki for a while but it takes ages to load and commit changes
[11:01] <seb128> I leaning toward a simple bzr list and a wrapper tool
[11:01] <seb128> desktop-todo claim source
[11:02] <seb128> desktop-todo info source
[11:02] <seb128> that sort of thing
[11:02] <seb128> and use a bzr for infos storage
[11:02] <Laney> Couldn't you have a page like Bryce's with a "Claim" button that uses LP auth?
[11:02] <seb128> well if somebody wants to do that
[11:02] <pitti> CLI++
[11:03] <didrocks> seb128: I can work on that if you wish, once jaunty released (too much work atm, as you know)
[11:03] <seb128> but I've no clue about lp authentification and I don't want to spend time on a website
[11:03] <seb128> didrocks: would be nice, we can discuss it at uds if you will be there
[11:03] <Laney> i'll see
[11:03] <seb128> dunno if invitations have already been sent
[11:03] <Laney> the code is probably stealable from bryce and REVU
[11:03] <didrocks> seb128: I hope I will be there, still waiting for sponsoring results :)
[11:04] <asac> didrocks: maybe make claiming so that it either shows how old the claim is
[11:04] <asac> or that it gets automatically unset after a while
[11:04] <asac> i guess showing  how old is good
[11:04] <didrocks> asac: yes, timeline is import there, for not having deadlock
[11:04] <seb128> asac: right
[11:05] <didrocks> important*
[11:07] <andreasn> mpt, ping
[11:12] <seb128> asac: you already got commit approval for your evolution change ;-)
[11:13] <seb128> the evolution guys are reactive nowadays that's cool
[11:13] <crevette> yep M barnes is really working hard on evo
[11:14] <crevette> until he'll be relocated on other things
[11:14] <crevette> :/
[11:14] <seb128> does redhat relocate people often?
[11:14] <seb128> mchra is doing most of the bug fixing work I notice
[11:14] <crevette> mccaan seems to be a moving target
[11:15] <seb128> mbarnes is rather doing the switch away from bonobo etc changes
[11:15] <seb128> right
[11:15] <seb128> but mchra and mbarnes are on evolution for several cycles now
[11:15] <crevette> but I guess now mchra and barnes are really involved in evo so I hope they'll continue to work for some time
[11:16] <crevette> Laney, hey
[11:16] <Laney> yo
[11:16] <crevette> Laney, upsating libgupnp fixed the crash in nautilus-sendto-universe
[11:16] <Laney> excellent
[11:16] <crevette> I did a FFe request to have it updated
[11:17] <Laney> seb can approve that
[11:17] <crevette> even universe packages ?
[11:17]  * Laney thinks so
[11:17] <seb128> crevette: only universe packages rather ;-)
[11:18] <seb128> I'm not approving packages for main
[11:18] <seb128> what is the bug number?
[11:18] <Laney> bug 348122
[11:19] <asac> seb128: great. can you commit ;)?
[11:19] <seb128> asac: you don't have commit access to the GNOME svn yet? you should ask for that ;-)
[11:20] <asac> seb128: good. whats the process?
[11:21] <seb128> asac: http://live.gnome.org/NewAccounts
[11:23] <crevette> Laney, I didn't had to answer on the bug report but the upgrade seems to be really safe
[11:24] <seb128> nothing out of nautilus-sendto-universe is using the lib
[11:24] <crevette> yep
[11:24] <crevette> and all other gupnp packages are developped by the same people
[11:24] <crevette> I don't understand why this one was not updatd
[11:24] <Laney> because nobody did it
[11:24] <crevette> there others packages were synced and not this one
[11:25] <Laney> it was updated in Debian after FF
[11:25] <Laney> after DIF even
[11:25] <seb128> asac: mbarnes is commiting the change now, you should still apply for svn access ;-)
[11:26] <asac> seb128: are you voucher?
[11:26] <seb128> asac: yes
[11:26] <seb128> asac: you can probably list danw too
[11:26] <asac> seb128: i have to select a module
[11:26] <seb128> I guess you worked enough with him for that no?
[11:27] <asac> i think so
[11:27] <seb128> hum
[11:27] <seb128> asac: select nm, maybe just ping danw before ;-)
[11:28] <asac> yeah
[11:28] <seb128> vuntz: ^
[11:28] <asac> seb128: you are not a module owner right?
[11:28] <seb128> vuntz: is there any way to apply for a svn account without being active commiter on a specific component?
[11:28] <seb128> asac: well I'm one of the gnome-control-center ones but it would be weird if you applied for this one since you didn't contribute on it
[11:28] <asac> heh
[11:29] <asac> ok
[11:29] <asac> i will wait till dan pops up
[11:29] <asac> i can ask chpe too
[11:29] <seb128> just ask danw and pick nm I would say
[11:29] <crevette> seb128, this active component is not really relevant, I didn't touch specific modules neither
[11:29] <seb128> oh right
[11:29] <asac> let me check if he is online ;)
[11:29] <seb128> crevette: what component did you pick on the mango page then?
[11:29] <asac> not either ... i will decide based on who pops-up first ;)
[11:30] <asac> seb128: do the evo guys also have a hand on gtkhtml?
[11:30] <seb128> yes, mbarnes does gtkhtml too
[11:30] <crevette> seb128, I don't remember, dodji was the coucher for me, and I set hadess also
[11:30] <asac> seb128: ok. i marked the gtkhtml patch as a depends of the evolution bug so i guess they will see
[11:30] <seb128> asac: I expect he will review your other patch soon too, if he doesn't I'll ping him about it
[11:30] <crevette> s/coucher/voucher/
[11:31] <asac> seb128: no hurry.
[11:31] <asac> i am sure tat most patches get in in time for .1
[11:31] <seb128> right
[11:31] <asac> gnome folks have always been reponsive ... except maybe at-spi ;)
[11:32] <asac> hmm ... just found out that pidgin isnt even gnome ;)
[11:36] <seb128> no it's not
[11:36] <seb128> empathy is the GNOME im client
[11:36] <seb128> pidgin is only a GTK application ;-)
[11:39] <asac> seb128: re webkit. i have to check why gwibber doesnt work. i asked gwibber folks to investigate let me check
[11:43] <seb128> asac: don't bother, it's important in no way for jaunty
[11:44] <seb128> asac: I would just push epiphany-webkit to universe if we have 1.1
[11:44] <seb128> but a ppa will do
[11:45] <asac> seb128: how about syncing the webkit stuff to -desktop ppa? and then seeing how well it works?
[11:46] <asac> i dont want to put it into my ppa because its currently used for "font" topic ... unfortunately there is no sub-ppa support yet
[11:47] <asac> so if we can use -desktop for that it would be great
[11:50] <seb128> asac: there is a webkit ppa
[11:50] <seb128> asac: https://edge.launchpad.net/~webkit-team/+archive/ppa
[12:00] <asac> oh good
[12:04] <seb128> pedro_: hey
[12:04] <pedro_> salut seb128
[12:05] <seb128> pedro_: I think mvo could use some help triaging his components
[12:05] <seb128> pedro_: is there anything scheduled for the new bug day?
[12:05] <seb128> I was just running accross https://bugs.edge.launchpad.net/ubuntu/+source/software-properties
[12:05] <seb128> 82 bugs, 46 new
[12:05] <seb128> could that be a bug day target?
[12:05] <asac> i think mozilla components need a massive mass and flash hug ;)
[12:06] <pedro_> seb128: yep totally, there's nothing for tomorrow though and next week we are having a xorg one to help bryce with the bugs
[12:06] <seb128> pedro_: perhaps you can quickly announce software-properties for tomorrow? ;-)
[12:07] <seb128> well there is no hurry
[12:07] <seb128> I just came across it
[12:08] <pedro_> m i think we're too close to the date, we announce those to UWN as well
[12:08] <mvo> I would not mind help with hat
[12:08] <pedro_> seb128: i'll add it to the planning for April though
[12:08] <seb128> pedro_: thanks
[12:08] <pedro_> and will do some triaging there today in the meantime
[12:09] <seb128> you rock!
[12:09]  * seb128 hugs pedro_ mvo
[12:09]  * pedro_ hugs both 
[12:09] <seb128> pedro_: maybe you can manage to tackle that backlog by your own today who knows ;-)
[12:09] <seb128> I marked some duplicate right now but that's a bit too many bugs to triage right now for me to go through the list
[12:10] <asac> i dont even know the magnitude of my backlog
[12:10] <pedro_> heh yeah maybe, let's see how it goes :-)
[12:11] <pedro_> grgr i am the only one getting a lot of spam lately?
[12:11] <asac> define "a lot" ;)?
[12:12] <pedro_> well at least 40 emails a day
[12:12] <asac> pedro_: with or without spam filtering?
[12:12] <seb128> lol
[12:12] <seb128> pedro_: I'm going some hundred of spams through my spam filtering a day
[12:13] <seb128> and some thousand in the spam filter too
[12:13] <asac> i think i get a couple hundreds each day and also a bunch of legitimate mails i never see because my spam filtering is too strict
[12:13] <pedro_> asac: well I'm not filtering those locally
[12:13] <pedro_> mm i might consider that option, i'm getting tired of those
[12:13] <asac> so 40 mails get through your provider filter?
[12:14] <pedro_> yeah
[12:15] <kenvandine_wk> pitti: can you confirm you can login to ekiga.net with 3.2?
[12:16] <pitti> kenvandine_wk: ack; was broken this morning, seems to work now
[12:17] <pitti> kenvandine_wk: @ekiga.net's echo test still doesn't work for me, though
[12:17] <pitti> kenvandine_wk: oops, it does work for me now
[12:17] <kenvandine_wk> it works for me with 3.0.1, but not 3.2
[12:18] <kenvandine_wk> i get this request terminated message, which there has been at least one other report of on the mailing list
[12:18]  * kenvandine_wk is debugging it
[12:18] <pitti> kenvandine_wk: ekiga.net seems to be very brittle for me, too
[12:18] <kenvandine_wk> weird it works for you
[12:18] <pitti> tried it again, and it's silent
[12:19]  * pitti wonders whether so many people complain at ekiga, the application, because ekiga.net, the service, is totally unreliable
[12:19] <kenvandine_wk> likely :)
[12:19] <kenvandine_wk> the error code i am getting is what happens when you try to register/auth and before it answers you cancel it
[12:19] <pitti> both my Canonical as well as my diamondcard.us account have always worked perfectly
[12:19] <kenvandine_wk> but it happens in like a second
[12:20] <kenvandine_wk> rick said ekiga.net has been reliable for him, with 3.0.x
[12:20] <kenvandine_wk> it works amazingly well with our canonical setup
[12:20]  * kenvandine_wk thinks it is better than skype :)
[12:21] <pitti> can't compare, I have never used skype
[12:21] <kenvandine_wk> i've only used it a few times... but i always had little weird problems...
[12:28] <crevette> thanks seb128 for the ack for gunp
[12:28] <crevette> gupnp
[12:28] <seb128> crevette: you're welcome
[12:36] <pedro_> asac: do you know if there's anybody working on bug 341684 (in order to assign it to and set the right status) ?
[12:39] <asac> pedro_: commented
[12:40] <pedro_> asac: great, thanks you
[12:42] <kenvandine_wk> pitti: now ekiga.net is working for me in 3.2... but i get a segfault on exit
[12:43] <kenvandine_wk> pitti: do you get that?
[12:43] <pitti> kenvandine_wk: no, I don't
[12:43] <kenvandine_wk> running it from a terminal?
[12:43] <kenvandine_wk> it doesn't seem to trigger apport
[12:43]  * kenvandine_wk doesn't know what triggers that
[12:44] <kenvandine_wk> well the segfault isn't a regression... it is happening on 3.0.1 as well :)
[12:45] <seb128> you should not spend too much time on debugging ekiga I think
[12:46] <seb128> if the new version is mostly working push it after beta and send bugs upstream when they come
[12:48] <kenvandine_wk> yeah
[12:48] <kenvandine_wk> now that i see it is working with ekiga.net i will get it ready to push
[12:48] <kenvandine_wk> i didn't want to push it if it didn't work with ekiga.net
[12:48] <kenvandine_wk> what triggers apport of a crash?
[12:49] <kenvandine_wk> i am curious why this seg fault doesn't trigger it
[12:49] <pitti> kenvandine_wk: if it's a real SIGSEGV, you should get one
[12:49] <pitti> kenvandine_wk: have a look at /var/log/apport.log ?
[12:49] <kenvandine_wk> ok
[12:50] <kenvandine_wk> apport (pid 11235) Wed Mar 25 08:31:50 2009: called for pid 11212, signal 11
[12:50] <kenvandine_wk> apport (pid 11235) Wed Mar 25 08:31:50 2009: executable: /usr/bin/ekiga (command line "ekiga")
[12:50] <kenvandine_wk> apport (pid 11235) Wed Mar 25 08:31:50 2009: this executable already crashed 2 times, ignoring
[12:50] <pitti> there you go
[12:50] <kenvandine_wk> :)
[12:50] <pitti> kenvandine_wk: rm /var/crash/*
[12:50] <pitti> and try again
[12:51] <kenvandine_wk> ok, now it is triggering apport
[12:51] <asac> Keybuk: could you look into /lib/udev/rules.d/77-nm-probe-modem-capabilities.rules ... do you see anything obviously wrong with the $attr{idVendor} $attr{productId} subsitution?
[12:52] <Keybuk> asac: where is that rules file?
[12:52] <asac> Keybuk: /lib/udev/rules.d/77-nm-probe-modem-capabilities.rules ?
[12:52] <Keybuk> asac: other than the fact you probbaly mean $attr{idProduct} ? <g>
[12:52] <asac> yeah
[12:52] <asac> sorry. typo
[12:52] <Keybuk> err
[12:52] <asac> Keybuk: bInterfaceNumber works ... udevadm showed me that idProduct is in parent
[12:52] <Keybuk> I don't have any content like that in my file
[12:52] <asac> Keybuk: oh then you are not running latest
[12:52] <asac> let me psate
[12:53] <Keybuk> I updated a few days ago ;)
[12:53] <asac> Keybuk: http://pastebin.com/f2ae57f15
[12:53] <Keybuk> nm-probe-modem is in /lib/udev ?
[12:54] <asac> Keybuk: yes
[12:54] <Keybuk> I'm not sure $attr{driver} will work
[12:54] <asac> Keybuk: that works
[12:54] <asac> same for bInterfaceNumber
[12:54] <Keybuk> oh, neat
[12:54] <Keybuk> which doesn't work then?
[12:55] <asac> Keybuk: idProduct and idVendor
[12:55] <Keybuk> hmm
[12:55] <Keybuk> $attr{} should walk up the parent devices
[12:55] <asac> i thought its either a udev bug not looking high enough in parent
[12:55] <Keybuk> can you show me the udevadm info -a for this device?
[12:55] <asac> or its because its a feature and i have to match something in subsystem usb
[12:55] <Keybuk> could be both
[12:55] <asac> Keybuk: yeah ... wait a sec
[12:56] <asac> udevadm info -a -p $(udevadm info -q path -n /dev/ttyUSB0)
[12:56] <asac> http://pastebin.com/f434327a8
[12:56] <Keybuk> hah
[12:57] <Keybuk> you know you can use -n right? :P
[12:57] <Keybuk> udevadm info -a -n ttyUSB0
[12:57] <asac> heh ... no ;)
[12:57]  * asac happy now
[13:03] <Keybuk> ok
[13:03] <Keybuk> so this matches the SUBSYSTEM=="tty" (top-level)
[13:03] <Keybuk> it matches the KERNEL name too
[13:03] <Keybuk> (though that's pretty redundant given the subsystem match <g>)
[13:03] <asac> yeah
[13:04] <asac> hmm ... have to run to lunch ... back in half an hour
[13:04] <Keybuk> so I think this should work
[13:04] <Keybuk> it's probably a udev bug that it doesn't
[13:08] <mvo> seb128: do you know about http://people.ubuntu.com/~mvo/tmp/err1.png ?
[13:08] <mvo> seb128: that is with brasero
[13:08] <seb128> mvo: no but I'm not watching this product bugs, maybe better to ask pedro_
[13:09] <mvo> oh, sorry
[13:09] <mvo> pedro_: have you seen http://people.ubuntu.com/~mvo/tmp/err1.png before? happend on a fresh jaunty upgraded system when burning
[13:11] <seb128> mvo: did you get a successful record?
[13:18] <mvo> seb128: yes, that was fine
[13:26] <pedro_> mvo: if the disc was burned ok that's probably bug 294455
[13:26] <pedro_> (sorry for the delay was on a call)
[13:27] <mvo> thanks pedro_
[13:27] <pedro_> i truly hate you ubottu
[13:27] <pedro_> mvo: no problem :-)
[13:29] <seb128> what's up with this bot
[13:29] <seb128> it keeps timeouting since yesterday
[13:50] <asac> Keybuk: any idea where the bug could be or do we need to workaround this for now?
[13:51] <Keybuk> asac: haven't looked yet
[13:51] <Keybuk> it'll just be in the bit of udev that applies $attr{}
[13:55] <pitti> rickspencer3: good morning
[13:56] <rickspencer3> pitti: hi
[14:14] <Keybuk> asac: I have another udev problem to debug at the same time ;)
[14:15] <asac> Keybuk: so you are looking at something related now? (/me just did a dbg build to see more log output)
[14:15] <Keybuk> asac: will be in a few minutes
[14:16] <Keybuk> just clearing through my bugs to line them all up :)
[14:17] <asac> Keybuk: ok. this one is 346835
[14:37] <pitti> seb128: ah, I finally found out why consolidating the dup db takes two hours, and why we got all those "inconsistency detected: bug #336952 does not appear in get_unfixed(), but is not fixed yet" issues which slowed it down so much
[14:38] <pitti> seb128: it's fixed now; the next run will throw out all these invalidated bugs, and from then on it should be a matter of 5 minutes
[14:38] <seb128> pitti: excellent! what was it?
[14:40] <pitti> seb128: the function which checked the bug status still checked for "Rejected", instead of "Invalid"
[14:40] <pitti> that must have been changed ages ago
[14:40] <seb128> oh ok
[14:49] <asac> seb128: is there a fundamental reason why autologin with keyring cannot work?
[14:50] <seb128> asac: if you set a password for gnome-keyring? something needs to provide it the password
[14:50] <seb128> asac: when you type the password on the login screen we can unlock the keyring using that
[14:50] <seb128> if you do autologin how do you want to unblock it?
[14:50] <asac> seb128: i am looking at the -devel thread ... i just think we should fix the autologin problem instead of starting to move wifi keys to plain text
[14:50] <seb128> if the password was possible to read automatically by a software it would not be secure storing
[14:51] <asac> yeah. but making access to keyring insecure on systems that have autologin sounds more sensible than starting to move apps away from keyring
[15:00] <seb128> asac: right, see my reply on the list about setting a blank password when selecting autologin
[15:03] <pitti> I actually liked mdz's idea of just prompting for your own password
[15:09] <Keybuk> that kinda defeats auto-login though
[15:09] <Keybuk> since you still have to type a password
[15:10] <rickspencer3> I don't think we should set a blank password by default
[15:10] <rickspencer3> that seems very insecure to me
[15:10] <rickspencer3> don't people store quite sensitive info in the keyring?
[15:13] <asac> Keybuk: ubuntu branch mentioned in control doesnt have 140 (udev)? ... last log is 139-2
[15:14] <Keybuk> asac: pushing now
[15:14] <asac> just fyi
[15:14] <asac> ah cool.
[15:14] <asac> i wanted to diff 139 to 140 ... thats handy then
[15:15] <Keybuk> asac: could you run
[15:16] <Keybuk> udevadm test $(udevadm info -qpath -n ttyUSB0) for me
[15:17] <asac> Keybuk: http://pastebin.com/f4f8cf11
[15:18] <Keybuk> asac: are you on i386 or amd64?
[15:19] <asac> i386
[15:21] <Keybuk> asac: grab http://people.ubuntu.com/~scott/udevadm
[15:21] <Keybuk> then run
[15:21] <Keybuk> UDEV_LOG=debug ./udevadm test $(udevadm info -qpath -n ttyUSB0) > udevadm.log 2>&1
[15:21] <Keybuk> udevadm.log will be quite large
[15:23] <asac> Keybuk: http://people.ubuntu.com/~asac/tmp/udevadm.log
[15:29] <Keybuk> let me check with kay on this one
[15:31] <Keybuk> the code is deliberately not recursing up the parents
[15:31] <asac> yeah. i saw that it somehow only does two/three steps
[15:32] <Keybuk> it looking at the event device
[15:32] <Keybuk> (ttyUSB0)
[15:32] <Keybuk> and the device matched (the one that DRIVERS matched I think)
[15:32] <Keybuk> which is the usb interface
[15:34] <Keybuk> the code matches the comment
[15:35] <asac> code == case SUBST_ATTR in udeve-event.c, right?
[15:35] <Keybuk> right
[15:36] <asac> util_resolve_subsys_kernel -> /* handle "[<SUBSYSTEM>/<KERNEL>]<attribute>" format */
[15:36] <Keybuk> "the parent device, other matches have selected"
[15:36] <Keybuk> which is not "all parents"
[15:36] <asac> does that mean we have to specify something like XXX/idProduct ?
[15:37] <Keybuk> ohh
[15:37] <Keybuk> no, this is deliberate
[15:38] <Keybuk> this is because you can do DRIVERS=="foo", ATTRS{...}=="xxx"
[15:38] <Keybuk> and they both HAVE to match the same device
[15:38] <Keybuk> ie. it finds a single parent
[15:38] <Keybuk> it's consistent
[15:38] <Keybuk> the manpage is just wrong
[15:39] <Keybuk> which was your rule again?
[15:39] <asac> yeah
[15:39] <asac> http://pastebin.com/f2ae57f15
[15:39] <asac> Keybuk: ^^
[15:39] <Keybuk> DRIVERS will match the usb interface I think
[15:39] <Keybuk> can you confirm that for me
[15:39] <Keybuk> ls /sys/bus/usb/drivers/option/*
[15:40] <asac> http://pastebin.com/f672c0f3d
[15:40] <pedro_> mvo: may you give your opinion on bug 184226 later?
[15:41] <Keybuk> asac: great
[15:41] <asac> can you think of a trick how we can still get the product and vendor id for that IMPORT command? or do we need to dig that out on our own in the prober?
[15:41] <mvo> pedro_: sure, thanks
[15:41] <Keybuk> asac: try this
[15:42] <Keybuk> $attr{[usb/]idProduct}
[15:42] <Keybuk> $attr{[usb/]idVendor}
[15:42] <asac> damn
[15:42] <asac> i tried usb/idProduct ;)
[15:42] <Keybuk> if you change the rules, then you should be able to run the udevadm test command I gave you (using the debug binary)
[15:42] <Keybuk> I'd like to compare output
[15:42] <asac> i should have read the parser more carefully ;)
[15:42] <asac> checking
[15:44] <asac> hmm
[15:44] <asac> doesnt work i think
[15:45] <Keybuk> got the udevadm test output to compare?
[15:45] <asac> i still get
[15:45] <asac> Mar 25 16:43:45 tinya udevd-event[31220]: '[usb/]idProduct=(null)' added
[15:45] <asac> Mar 25 16:43:45 tinya udevd-event[31220]: will substitute format name 'attr'
[15:45] <asac> in syslog
[15:45] <Keybuk> yeah, need to look at the udevadm test output
[15:46] <asac> Keybuk: you wnat the long one?
[15:46] <Keybuk> I'm not quite sure it's right yet
[15:46] <Keybuk> but need to do a process of elimination to get there - since I don't have your dongle :p
[15:46] <asac> e.g. with UDEV_DEBUG ... i guess so
[15:47] <asac> http://people.ubuntu.com/~asac/tmp/udevadm2.log
[15:47] <asac> Keybuk: ^^
[15:48] <dobey> pitti: ping
[15:49] <Keybuk> asac: huh
[15:49] <asac> Keybuk: did i do something wrong?
[15:50] <pedro_> mvo:  thanks you!
[15:50]  * mvo hugs pedro_
[15:50]  * pedro_ hugs mvo back
[15:51] <Keybuk> asac: $attr{../idProduct} works though, right? :P
[15:51] <Keybuk> note no []s
[15:51] <asac> Keybuk: you mean usb/idProduct?
[15:52] <asac> i tried that yesterday after i found that code in udev_util
[15:52] <asac> or really ".."?
[15:52] <asac> let me try ../idProduct
[15:53] <Keybuk> really ..
[15:53] <asac> Keybuk: yeah. that did the trick. thats simple ;)
[15:53] <Keybuk> .. from a usb interface kobject is the usb device kobject
[15:53] <seb128> rickspencer3: the keyring on a normal install has basically your evolution and network manager passwords
[15:53] <Keybuk> ok
[15:53] <Keybuk> great
[15:53] <seb128> rickspencer3: ie wireless, email accounts, ldap and calendars server passwords too
[15:53] <asac> Keybuk: yeah ... is that the right fix ... is that how its ment to be or a trick?
[15:54] <Keybuk> that's supposed to work
[15:54] <asac> ok. so its not something that will suddenly will be unsupported ;)
[15:54] <Keybuk> ie. it's not a hack or a trick
[15:54] <asac> great
[15:54] <Keybuk> right
[15:54] <asac> cool. thanks for your help
[15:54] <asac> thats fixed then
[15:54] <Keybuk> I'll talk to Kay later though, because I'm not entirely convinced that this attr expansion being limited to the current device is the right behaviour
[15:54] <Keybuk> ATTR matches, sure
[15:54] <Keybuk> even ATTRS matches
[15:54] <Keybuk> but once you've matched, you should be able to use $attr{something-in-a-parent}
[15:54] <Keybuk> at least I think so :)
[15:55] <Keybuk> hmm, but then I suppose $env{} doesn't behave that way
[15:55] <Keybuk> at the very least, this type of thing should be documented with examples <g>
[15:55] <Keybuk> and the manpage fixed
[16:01] <pitti> dobey: hi
[16:02] <dobey> pitti: hey. i found some issues with the check command, and just pushed some fixes to my branch
[16:03] <dobey> pitti: and just proposed a merge for it :)
[16:04] <pitti> dobey: ah, nice; thanks
[16:07] <asac> Keybuk: i liked the manpage behaviour ;)
[16:07] <Keybuk> asac: it doesn't quite make sense though with the way udev tries to parse its rules
[16:08] <Keybuk> it's been gradually moving to a very well defined narrow behaviour
[16:08] <Keybuk> to avoid unexpected issues
[16:08] <Keybuk> esp. importance one everything currently in HAL fdi has to be rewritten as udev rules
[16:11] <asac> Keybuk: yes true. it was just confusing for me as an outsider reading the manpage and then not being able to access any attr from parents further up
[16:14] <pedro_> MacSlow: may you look at  344888 if you have a time later? it was reopened a few hours after you closed it
[16:14] <pedro_> MacSlow:  bug 344888
[16:16] <MacSlow> pedro_, *sigh* who did that? I wonder if they read this comment from Mat "Update - this won't be fixed for Jaunty (not enough time), but we'll factor that in for future development."
[16:17] <MacSlow> pedro_, I would set it to confirmed
[16:19] <pedro_> MacSlow: Mat reopened it. Ok, I've set it to Confirmed, thanks!
[16:41] <Keybuk> asac: -> #udev?
[17:20] <seb128> re
[17:21] <seb128> ok, so how do I valgrind X? ;-)
[17:21] <seb128> valgrind doesn't like the X binary setuid
[17:23] <seb128> ups
[17:23] <seb128> wrong channel
[17:47] <pitti> seb128: bug 328035 has a recipe for strace, which certainly works for valgrind as well
[17:47] <seb128> pitti: cf #ubuntu-devel
[17:56] <dobey> pitti: hrmm. are you/glatzor planning to release a new version of distutils-extra soon?
[17:57] <pitti> dobey: yes, I'll upload it to debian tomorrow morning
[17:57] <pitti> dobey: and then we can sync it to jaunty after the freeze (on Friday)
[17:59] <dobey> pitti: ok. i was going to build a package and stick it in ppa, so i can start using it in code.
[17:59] <dobey> pitti: and then we can just use the jaunty version after you sync it
[17:59] <pitti> dobey: sure, sounds good
[18:00] <dobey> pitti: awesome! thanks again
[18:23] <pitti> dobey: uploaded to Debian now
[18:24] <dobey> pitti: awesome
[18:24] <dobey> pitti: i've put a version in my ppa too :)
[18:41] <jcastro> seb128: are you guys (desktop people) staying for the full desktop summit or just the first few core days?
[18:42] <seb128> jcastro: dunno yet
[18:42] <jcastro> seb128: when you book travel can you ping me? I want to travel with the cabal.
[18:42] <seb128> depends of the actual scheduling details
[18:43] <seb128> ok
[18:43] <seb128> I think we will discuss it during the desktop team meeting next week
[18:43] <jcastro> ah great, I'll just follow along the notes then
[18:43] <seb128> is the detailled schedule available now?
[18:43] <dobey> ah crap, i need to do that
[19:39]  * mvo hugs pedro_ for his software-properties bug triage
[19:40]  * pedro_ hugs mvo back
[19:40] <pedro_> mvo: btw could you look at bug 308920 ? ;-)
[19:40]  * seb128 hugs mvo pedro_
[19:40]  * pedro_ hugs seb128
[22:55] <cj> awwww
[23:39] <Laney> bratsche: What should be done for the gnome-user-share bug?
[23:39] <Laney> Is the patch right?
[23:50] <bratsche> Laney: Let me take a look.. do you have the url handy?
[23:51] <bratsche> I found it
[23:51] <bratsche> https://bugs.launchpad.net/ubuntu/+source/gnome-user-share/+bug/337352  ?
[23:54] <bratsche> Laney: If that's the one you mean, then no.. I think this patch is incorrect.  I'll try to post a new one.
[23:55] <bratsche> Sorry this one kind of fell off my radar.  I'll try to implement the new specification soon.
[23:56] <Laney> bratsche: (bug 337352)
[23:56] <Laney> I'll unsubscribe the sponsors then. Please resubscribe when ready
[23:57] <bratsche> Thanks.
[23:57] <bratsche> Sorry for the trouble.
[23:57] <Laney> no problem at all
[23:57] <bratsche> I'm still kind of new at Ubuntu, figuring how how to work in Launchpad still. :)