[01:17] <Gralco_> bdmurray if you confirm a bug do you assign the bug to no one or should you keep the bug assigned to yourself?
[01:18] <bdmurray> Gralco_: bugs should only be assigned to people when they are In Progress really
[01:19] <greg-g> adding more: assignment is used mainly to show who is working on FIXING the bug, not diagnosing/triaging it
[01:19] <bdmurray> greg-g: hey, how's it going?
[01:19] <Gralco_> bdmurray what will usually happen to a bug after it is confirmed then?
[01:19] <hggdh_> Gralco if you are done with the bug (i.e., confirmed/triaged it, set owner to nobody
[01:19] <hggdh_> the maintainers will eventually look at it
[01:19] <Gralco_> once i unassign it
[01:20] <bdmurray> Or a member of bug control may set it to Triaged
[01:20] <Gralco_> who fixes the bug
[01:21] <hggdh_> it may need forwarding upstream -- in this case upstream will fix it
[01:21] <greg-g> bdmurray: hiya, it is going well, really busy with my internship :) (hence not responding to that email from pedro yet ;) )
[01:21] <hggdh_> or, if it is something under our control, one of the maintainers will fix it (or even you, if you know what to do)
[01:22] <greg-g> bdmurray: how have things been with you?
[01:23] <bdmurray> greg-g: good, working on some exciting stuff
[01:23] <greg-g> bdmurray: was that a question or a statement? :)
[01:24] <bdmurray> That was a statement.
[01:24] <greg-g> because, for me, yes, I am working on some pretty cool stuff.  But, I have also notice some cool/good changes coming from QA
[01:24] <greg-g> s/notice/noticed/
[01:27] <bdmurray> How do you like the west coast?
[01:32] <greg-g> I like it, I'm getting used the crazy weather here in the bay area (it was 100 degrees in Oakland last weekend, and now it is in the 60s).  And, hearing people say that highs in the 60s is like winter weather.
[01:33] <bdmurray> Right not much snow in that area.
[01:33] <greg-g> But, having a great time doing my intern duties; met with some people at Apple yesterday, specifically their Open Source person (kinda like Chris DiBona at Google) (and yes, Apple does have one, honest)
[01:33] <greg-g> he is actually on the board of the Open Souce Initiative
[01:34] <greg-g> so, I've been busy, but fun busy.
[01:34] <bdmurray> That's always good.
[01:34] <greg-g> yeah
[01:38] <Gralco_> where do i find a bugs identification number
[01:39] <Gralco_> is it just the number of the bug?
[01:39] <bdmurray> Gralco_: yes, those numbers are unique
[01:40] <Gralco_> bdmurray: its the number that is in the url correct?
[01:40] <bdmurray> yes, that is correct
[01:40] <Gralco_> okay thanks
[01:42]  * greg-g heads out
[01:42]  * greg-g waves to bdmurray and everyone else
[01:46] <Gralco_> bdmurray when i apply for the bug control team do you want me to show you the bugs that i marked as duplicates for a bug that i triaged
[01:46] <Gralco_> within the application
[01:47] <bdmurray> I'd ideally like to see different types of activities.  So maybe 1 duplicate marking, 1 converting to a question, 3 conversations with reporters.
[01:48] <bdmurray> There are some guidelines at the bug control page as to what I look for.
[01:51] <Gralco_> bdmurray: What do you mean by converting to a question?
[02:00] <hggdh> Gralco_, its when you find a bug that is actually a question, an usage issue, not a package problem
[02:03] <Gralco_> hggdh: Yeah, I just saw it it under https://wiki.ubuntu.com/Bugs/HowToTriage Special types of bugs.
[02:04] <Gralco_> hggdh: I just don't know whats required of me with triaging them
[02:05] <hggdh> Gralco_, basically: reading the bug description, and checking if (1) you understand the issue; (2) if all necessary data is available; (3) asking for clarification or more specific data, if needed
[02:06] <hggdh> you may not understand what the bug is about -- do not get stressed over it. Leave it alone, and go find another. If you do not know what to do, but would like to learn, you can add yourself as a subscriber
[02:07] <Gralco_> okay
[02:07] <Gralco_> is there a wiki for triaging these
[02:08] <hggdh> it is just using common sense, and reading the wiki pages on how to triage specific packages (see https://wiki.ubuntu.com/DebuggingProcedures)
[02:08] <hggdh> and -- of course -- learning ;-)
[02:09] <hggdh> Gralco_, you may feel more confortable, to start, if you find a package you like; then work on bugs for either only, or mostly, this package
[02:11] <hggdh> Gralco_, yes, the HowToTriage is a good introduction to what we do. A priori, I would suggest you to *not* work on the "special" bugs, until you understand what they are about
[02:13] <Gralco_> hggdh: Okay I understand how to triage all other bugs though.
[02:15] <hggdh> cool. The "special" ones are dealt directly by package maintainers (or some of us with a LOT of experience on what they mean). They pretty much deal with packaging
[02:20] <hggdh> Gralco_, one most important point is the difference between package bugs and support issues (which need to be re-routed to https://answers.launchpad.net/ and/or to #ubuntu. For example, "I cannot connect to my email server" is almost certainly a support issue, not a package issue
[02:20] <hggdh> so -->> off to answers.launchpad.net with it (in a nice way)
[02:21] <persia> Except in the rare case where it is because the preferred email client crashes on start, in which case the title ought be altered :)
[02:21] <hggdh> :-)
[02:22] <hggdh> I was just writing about it  -->"on the other hand, "Evolution crashes when connecting to email server" is a real bug
[02:22] <persia> hggdh: Ah.  Sorry then.  I've just seen a few bugs that look like support requests, but have attached stacktraces or the like.
[02:23] <hggdh> persia, np, I undertood you, and you were faster than I was :-)
[02:24] <hggdh> but this is still a good point: one must understand WHAT is the problem before making a decision
[02:24] <persia> Unfortunately, not all submitters understand the distinction between "this software has a defect", and "my use case doesn't work with this software as configured in my environment".  I believe this is due to the large grey area, where something could be solved as support, but may well be a case of missing or incorrect defaults, etc.
[02:25] <hggdh> indeed; this can also be applied here -- sometimes we fail to correctly distinguish them
[02:25] <persia> If we had an infinite number of bug triagers and question answerers, I'd like to have a feature "fork into a question" to handle the difference, but I think both teams have enough work now without such duplication.
[02:26] <hggdh> and we also had the fact that the reporter is free to re-open the bug
[02:26] <hggdh> Gralco_, ^^^
[02:26] <hggdh> s/had/have/
[02:26] <persia> In cases in the grey area, I think I prefer to keep it a bug, and post the workaround in the bug.  Otherwise it might never get the attention it deserves (unfortunately few developers are also question answers, whereas many are also bug triagers)
[02:26] <Gralco_> hggdh what do you mean by re-open
[02:27] <hggdh> I think this is a sane approach, persia: when in doubt keep it
[02:28] <hggdh> Gralco_, when we close a bug, for whatever reason, the reporter (or anyone, in fact) can disagree with our action, and reset the bug status to new
[02:28] <hggdh> (a bug is considered closed when it has "Invalid", "Wont fix", or "Fix released" as status
[02:30] <persia> Thinking about it, it may be useful to alter the recommended template to avoid the term "re-open", as it may cause confusion.  Instead, we could provide those disagreeing with the recommendation to return the status to "New" with an appropriate comment (to signal that new triage is required).
[02:31] <hggdh> huh, if we had an infinite number of bug triagers and question answerers, we might also get the complete works of Shakespeare ;-)
[02:31] <hggdh> bdmurray ^^
[02:31] <persia> Heh.  There is that.
[02:32] <hggdh> see persia's comment, please. I agree -- makes things more consistent
[02:32]  * hggdh must train to say "set to new" instead of "reopen"
[02:34] <hggdh> Gralco_, still. The discussion we just had here points to the fact that one MUST understand what is the issue, before deciding on s course of action
[02:36] <persia> That's the hardest part of bug triage.
[02:37] <persia> On the other hand, it can be the most rewarding.  There are few things that can be as satisfying as truly understanding a problem, understanding a solution that works, and documenting it sufficiently that it benefits all users.
[02:38] <hggdh> yes, I agree -- but then this is what I do for a living (solve problems), so I am biased...
[02:38] <persia> Even just documenting the problem can be very satisfying, if someone else then understands clearly, and can get think of a solution.
[02:39] <hggdh> and this is part of the work -- understanding the issue, and (perhaps) rephrasing it in more consistent way
[02:39] <persia> Yep.  I think that's why I like apport so much.  It provides all the puzzle pieces: with a couple hours, one can usually describe the problem.
[02:40] <hggdh> and I *never* understood why we disable apport on release...
[02:40] <persia> volume.
[02:41] <hggdh> even with the automation we are putting behind it, for duplicates?
[02:41] <persia> Essentially, we have a medium-sized team here triaging bugs, and only 10-15 people watching the new bugs in #ubuntu-bugs-announce.
[02:41] <hggdh> and we will be releasing 8.4.01 soon -- without apport set on?
[02:41] <persia> When 3 million people report a bug because of a crash in a default application, we have an issue.
[02:42] <hggdh> well, yes... if they all report at the same time, we will run out of storage, bandwidth, and bug numbers...
[02:42] <persia> When 1 of those people is sufficiently frustrated to report a bug, and is willing to run apport manually on the crash report (in GNOME, `gnome-open /var/crash/...`), this is often sufficient to prepare a fix.
[02:43] <hggdh> (on my case, I run it manually when I feel the need)
[02:46] <persia> Right.  When a user reports a non-apport crash, and the triager is able to open an apport report, verify it is complete (clean trace, etc.), and link the original report as a duplicate of the new, complete, report, we get a good bug, and we don't get lots of extra apport bugs.
[02:47] <persia> One of the classes of apport bugs that annoys me is the appoort prompt on startup, after an environmental system crash (loss of power, etc.).  The user may be told to file 5 or more bugs, when there was no actual problem other than that the system state was corrupt.
[02:47] <persia> Restricting use to volunteer testers and those who understand the tool helps reduce the invalid bug reports generated in this sort of situation.
[02:47] <persia> Of course, with an infinite number of triagers, turning it on makes sense :)
[02:52] <hggdh> and the infinite storage and bandwidth :-)
[02:53] <hggdh> sigh... just found that upstream is not going to backport to stable a fix to Evolution...
[05:45] <LaserLine> Can someone help me file a bug... I'm trying to file a bug for gnome-about-me, but it's saying the package doesn't exist in launchpad
[05:48] <crimsun_> the name of the source package is gnome-control-center
[05:49] <crimsun_> dpkg -S $(/bin/which gnome-about-me)
[05:51] <LaserLine> crimsun:  Thanks.  Hopefully I did everything correctly... it's filed here https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/243429
[06:04] <EverettgM1819> is the file tranfer problem in ﻿Pidgin 2.4.1 for the AIM client a bug?
[06:10] <EverettgM1819> Is the file tranfer problem in ﻿Pidgin 2.4.1 for the AIM client a bug?
[06:10] <EverettgM1819> ﻿Is the file tranfer problem in ﻿Pidgin 2.4.1 for the AIM client a bug?
[06:10] <EverettgM1819> ﻿Is the file tranfer problem in ﻿Pidgin 2.4.1 for the AIM client a bug?
[06:11] <EverettgM1819> oops bad key
[06:12] <persia> The answer is a firm "maybe".  You likely need to specify "the file transfer problem" in more detail, as others may not be familar with that which you are experiencing.
[06:12] <RAOF> persia: Too slow, he's gone. :(
[06:13] <persia> Such is ever the case with the new ones.  Like fresh fish, they must be hooked sharply at the first bite.
[06:14] <RAOF> But not too sharply, lest the hook simply cut through the lip.
[06:15] <persia> Right.  There's an art to it.
[06:34] <bliZZardz> persia : am getting bored now :) .. someone debug me
[06:59] <Gralco> how do i report an upstream for rhythmbox
[06:59] <bliZZardz> Gralco : create a bug there and report it in launchpad as part of the comment. Change the status to 'confirmed' (if you find that there is indeed a bug upstream)
[07:00] <techno_freak> interesting bug #243431, as far as i enquired around you can use only the space available in the source FS and the size of local FS becomes invalid
[07:01] <Gralco> where do i go to report one that i have confirmed
[07:01] <techno_freak> Gralco, check "also affects project" link  n the left
[07:01] <techno_freak> on*
[07:01] <Gralco> does that send it upstream
[07:01] <techno_freak> Gralco, you have to check upstream bugs, if you dont find a similar one, report upstream and link it here
[07:02] <Gralco> yes there are no duplicates
[07:02] <techno_freak> Gralco, then, if my knowledge is right, create a bug in upstream and link it here
[07:04] <Gralco> what is the url for upstream bug to send to rhythmbox
[07:07] <techno_freak> Gralco, think it's the GNOME bugzilla
[07:37] <Iulian> Gralco: http://bugzilla.gnome.org/enter_bug.cgi?product=rhythmbox
[14:49] <qense> persia: I'm creating a Blueprint for the Ubuntu Wanted site and to make the links to previous discussion complete I'd like to upload our conversation about it and link to it. Do you mind if I'd upload the email you sent me?
[14:57] <persia> qense: Firstly, my apologies for the delay in responding to your last message about it: I've not yet gelled a response.
[14:57] <qense> no point :) persons tend to be busy
[14:58] <persia> That said, I think it may make more sense to distill the concepts from the discussion for the wiki, rather than pointing to them as some historical document.
[14:58] <qense> ok
[14:58] <qense> I'm creating a detailed specification at the wiki anyway, so if you'd wait a few minutes you'll have something mroe to response
[14:59] <qense> and if I'd forget something you've said you can always edit the page
[14:59] <persia> qense: With luck, I'll have some time to think on this more on Sunday, so even if you find a delay, it shan't likely have significant impact.
[14:59] <qense> ok
[15:01] <qense> Sunday isn't that far away, but I don't know what shan't means :D
[15:02] <persia> Oh, and in terms of nomenclature, I think I prefer "role" to "task", in the hopes of generating repeat activity and empowering people, rather than just listing all the stuff that isn't done yet.
[15:02] <persia> Anyway, more when I'm less distracted :)
[15:02] <qense> ok
[15:02] <qense> it's indeed better, I've already been doubting what to use
[15:03] <persia> james_w: Have you confirmed that the new upstream nicotine still expresses bug #180363?  Despite my explanation of the trace, I'm not sure it's triaged.
[15:07] <persia> If nothing else, if verified, it would benefit from an updated title and description.
[15:08] <james_w> persia: ah, I forgot it was an older version
[15:10] <james_w> I've got an intrepid box upstairs, I'll try it later.
[15:14] <persia> james_w: Even confirming on Hardy has value: that was a hardy development snapshot issue.
[15:15] <persia> Also, I'm not sure it's "Medium".  It only happens for hu_HU.UTF-8, and only if python-pyvorbis (in Recommends:) is not installed.  Isn't that "Low"?
[15:16] <persia> (assuming it still happens at all)
[15:16] <james_w> oh, yeah, I forgot you had to have that package missing as well.
[15:17] <james_w> not my finest bug triage :-)
[15:18] <persia> james_w: No worries.  Leaving a testcase comment and not triaging the bug likely wasn't the best example of my work either :)
[15:57] <vhaarr> persia: http://pastey.net/90123
[15:58] <vhaarr> that's what I got when I followed https://wiki.ubuntu.com/Backtrace
[15:59] <persia> Yeah.  That's why I want an apport trace.  There's some symbols missing (I don't know why), and they are missing at the interface between audacious and the libraries, which is likely the source of the bug.
[16:00] <vhaarr> I thought apport was supposed to magically pop up when something crashed, but I'm not getting anything.
[16:00] <persia> It might be a vfs bug also, but I'd be more interested in fixing audacios, as it's probably easier to understand the problem there.
[16:00] <persia> vhaarr: It needs to be forcibly enabled to automatically pop up.
[16:02] <persia> On the other hand, by being installed, you should get something in /var/crash/ which you can open directly (e.g. apport-cli -c /var/crash/$(thiscrashreport) )
[16:02] <vhaarr> yeah it doesn't create any logs there
[16:02] <vhaarr> unless I need to reboot after installing the apport daemon
[16:02] <persia> Hmm..  I don't know enough about how apport works to direct you then: I'm more of an apport consumer.
[16:03] <vhaarr> but I don't think so
[16:08] <vhaarr> perhaps it would be an idea for me to jump on audacious' IRC channel, if they have one, and relay the bug report there
[16:08]  * vhaarr checks
[16:12] <bdmurray> apport is only enabled for development releases
[16:14] <primes2h> Hi all. Since Edgy reached end of life, can I set 2.6.17 kernel version bugs as Invalid?
[16:15] <bdmurray> primes2h: just a second let me check something
[16:16] <bdmurray> primes2h: this wiki page https://wiki.ubuntu.com/UbuntuBugDay/20080425 has some guidelines for what to do with them
[16:16] <persia> bdmurray: Is there a way to generate an apport trace on a stable release, or is it impossible?
[16:17] <bdmurray> the 2.6.17 task should be "Won't Fixed" but we'd really like to find out what happens with Hardy if they can test or already running it
[16:18] <bdmurray> persia: yes, I'm looking for the relevant documentation
[16:18] <persia> bdmurray: Excellent news.  Thank you.
[16:18] <bdmurray> persia: https://wiki.ubuntu.com/Testing/EnableProposed
[16:19] <persia> vhaarr: That' it: `gconftool -s /apps/update-notifier/show_apport_crashes --type bool true` and set true in /etc/default/apport  You'll need to restart /etc/initi.d/apport or reboot.
[16:21] <primes2h> bdmurray: Thank you very much. Just a question, I'm using launchpad beta and 'won't fix' is not listed anymore.
[16:21] <primes2h> ?!
[16:22] <vhaarr> persia: that didn't make it generate a log or pop up a dialog either, but it seems the bug has gotten some more debug info now, and I talked to some audacious person and pasted my conversation with him in the bug as well
[16:22] <bdmurray> primes2h: Right, sorry that is an ACL'd status so using Won't Fix will be fine.
[16:22] <vhaarr> well, 'sudo /etc/init.d/apport restart' didn't make it work, I won't reboot now, leaving for work anyway
[16:22] <persia> vhaarr: Hmm.  Maybe there's something else stripping the symbol then.  Thanks for trying.
[16:22] <vhaarr> thanks for your help, I have to go :)
[16:23] <primes2h> bdmurray: what do you mean? I can't set it as 'won't fix'
[16:23] <bdmurray> primes2h: that's correct only members of a certain team can so using Invalid will be fine.  sorry about that.
[16:24] <primes2h> bdmurray: Ok, thank you very much indeed.
[16:24] <Hobbsee> !ping
[16:30] <bdmurray> pedro_: where does $line come from?
[16:30] <pedro_> bdmurray: a cat file | while read line
[16:31] <bdmurray> okay, what I'm really curious about is the the contents of that file
[16:32] <pedro_> bdmurray: i'll send it to you if you want to
[16:33] <bdmurray> pedro_: that'd be great
[16:33] <sbeattie> pastebin perhaps?
[16:33] <pedro_> sure, it's just a list of packages anyways
[16:35] <pedro_> bdmurray: http://pastebin.ubuntu.com/23329/
[16:40] <bdmurray> pedro_: are you using a packaged version or a bzr version?
[16:41] <pedro_> bdmurray: the packaged version 0.2.14
[16:41] <bdmurray> okay, I'll see what I can find out
[16:42] <pedro_> rock, thanks you ;-)
[17:39] <norsetto> pedro_: re. bug 243522, what makes you think that gmplayer is in the gnome-mplayer package?
[17:39] <pedro_> norsetto: the search list on LP returns me that, if is not feel free to re assign it
[17:40] <norsetto> pedro_: the search list on LP returns a list of packages, they have nothing to do (ok, some do) with the binaries they contain
[17:41] <norsetto> pedro_: you can use apt-file, or p.u.c. for that
[17:42] <pedro_> norsetto: sure, next time
[17:42] <norsetto> pedro_: thx
[17:42] <LimCore> hello
[17:42] <LimCore> another day, another EPIC failure of ubuntu
[17:43] <LimCore> it seems that recently in 8.04 amd64 kwallet suddenly stoped working?  I cant open wallets, dont see any wallets, I even can not create new walles. No messages, no nothing, it just dont show up
[18:39] <yjwong> Hi, I would like to bring attention to bug #208750 (regarding GVFS), which I think can be fixed right now with any GVFS/GNOME (or even just C programmers) hackers. I have traced the bug down to code level. Anyone willing to help?
[18:39] <yjwong> Upstream has not confirmed the bug; as they said that "Unconfirmed" has essentially the same status as "New" (:
[18:40] <yjwong> Oh, and if this should not be here, I would appreciate if someone direct me to the right channel
[18:41] <pochu> #nautilus on irc.gimp.net is a better place, if you're sure that's an upstream bug
[18:41] <pochu> otherwise, this is ok
[18:42] <pochu> explaining what you have found in the bug report is a good start though
[18:42] <yjwong> It's upstream, in GVFSD. But GVFS is a subproject of Nautilus?
[18:43] <pochu> no, but there's is no #gvfs channel and gvfs hackers are in #nautilus
[18:43] <yjwong> Ah, I see. Thanks for your information (:
[18:43] <pochu> np
[18:43] <pochu> (and gvfs discussion is on-topic there)
[18:44] <yjwong> Alright, thanks. I was afraid it wasn't on topic, and talking about that, I still feel the Ubuntu community is more friendly (:
[18:45] <pochu> GNOME folks are nice :)
[18:45] <bdmurray> pochu: there is some packaging python documentation that you've written or worked on right?
[18:45] <yjwong> Haha sure. But I've never really participated in GNOME, so yeah. I'm copying and pasting my sentence there (:
[20:29] <pochu> bdmurray: yup
[20:31] <pochu> bdmurray: I gave a session on OpenWeek, https://wiki.ubuntu.com/MeetingLogs/openweekhardy/PythonPackaging, which somebody then converted to a tutorial, https://wiki.ubuntu.com/PackagingGuide/Python
[20:31] <pochu> I haven't reviewed it yet though
[20:38] <emgent> heya pochu :)
[20:43] <pochu> hey emgent!
[20:43] <pochu> how are you :)
[20:43] <emgent> fine, but it`s very hot.. :(
[20:43] <emgent> and you?
[20:44] <pochu> fine, thanks :)
[20:44] <emgent> nice
[22:53] <Majost> Hello
[23:05] <bdmurray> Majost: hi there
[23:11] <Majost> I submitted a case which I think should be looked at with a bit of seriousness
[23:12] <Majost> 243630
[23:12] <Majost> It'
[23:12] <Majost> Not really a security hole... but still pretty important. ;P
[23:13] <bdmurray> bug 243630
[23:21] <bdmurray> Majost: thanks for bringing it up we are looking into it
[23:25] <Majost> np
[23:25] <Majost> =)
[23:25] <Majost> I didn't check any other releases, but it probably would be wise. heh