[00:03] <nailor> ﻿bdmurray: is there any public background information about why it's this way? i like empty todo-lists and hearing that all these expiring bugs are not even really on their slow way to nirvana does not sound too good...
[00:05] <bdmurray> nailor: no, as far as I know there isn't anything publicly available.  However, I happy to discuss it.  Additionally, there are lists of the ones marked for expiration so if someone wanted to manually expire them that would be possible.
[00:27] <nailor> ﻿bdmurray: i am quite new to really working with launchpad and i noticed that bugs without a package tend to stale. so i looked for bugs without packages, scrolled down the list to the ones ~1 month old and tried to "get rid of them". there are some types of bugs. one type is "simply overlooked": i look at them and try to find out what program might be related and choose the appropriate package. then there are "feature XY doe
[00:27] <nailor> i subscribe to all the bugs i touch so i can see what happens to them, and i am happy if one gets solved, invalidated or a dev picks it up. i hate the bugs that will probably litter the database forever. i'd like to have no open bugs that have no future of becoming solved one day. but thats impossible without expiring old bugs. it would feel much better if i could put them into a pipeline and be sure that the bug either becomes
[00:27] <nailor> last thing: i'd be glad to get some advice how to treat the people/bugs where some ﻿wireless/sound/graphic/suspend does not work and i cant tell if this devices does not work at all/well/ok/out of the box with ubuntu. i'd would be nice to either have a place where i could look up the "usual suspects" and tell them how their chances are to get it working with much/little/no work or have some dedicated team that i can refer the
[00:27] <nailor> ps sorry, didnt want to write THIS much :)
[00:32] <bdmurray> nailor: it looks like some of your message got cut off.  maybe private message me?
[01:07] <Gralco> bdmurray what did you mean by"it says the kernel team only wants kernel
[01:07] <Gralco> bugs assigned to them"
[01:09] <bdmurray> Gralco: I mean they don't want update-manager bugs assigned to them
[01:13] <Gralco> bdmurray who should be assigned update-manager bugs then?
[01:14] <Gralco> My computer finally arrived
[01:34] <bdmurray> Gralco: bug reports generally should *not* be assigned to people the kernel team is the exception here
[01:57] <Gralco> bdmurray who should be assigned update-manager bugs?
[02:00] <persia> Gralco: Nobody should be assigned update-manager bugs, except by themselves if they plan to work on it.
[02:00] <persia> There are about 5 people who spend time on update-manager, and only one of them really understands it completely.
[02:00] <persia> When there is work done on update-manager, people search for bugs on update-manager directly, rather than looking at bug assignments.
[02:01] <persia> A similar model applies for the majority of packages, where there may be a few people who look at it, but anyone is welcome to try to fix a bug.
[02:01] <persia> Assigning the bugs discourages other people from working on them.
[02:02] <lifeless> to put it another way
[02:02] <lifeless> assignment means 'I am working on this now'
[02:02] <lifeless> not 'I intend to work on this in the future'
[02:02] <persia> Or, sometimes, I'm planning to work on this, so leave it alone.
[02:03] <persia> Once in a while it means "I was going to work on this, but forgot".
[02:03] <lifeless> but note the common use of "I" not "They"
[02:03] <lifeless> only *I* can make the statement that *I* intend to do something
[02:03] <Gralco> so basically I assign kernel bugs to the kernel team and if anything else assign it to no one
[02:03] <lifeless> yes
[02:04] <persia> And in rare cases, it means "You should work on this", but that's only correct in those rare cases where one member of Ubuntu happens to be responsible for directing activities of another member (e.g. mentoring, sponsored developers, etc.)
[02:04] <lifeless> right, when there is an agreement to delegate the decision
[02:06] <persia> Gralco: In summary, except for kernel bugs, don't assign unless you are either doing the work yourself or otherwise providing the resource to do the work.
[02:06] <nickellery> why is it that people assign bugs to Desktop Bugs?
[02:06] <nickellery> persia
[02:07] <persia> nickellery: No need to poke, just because I'm a slow typist.
[02:07] <nickellery> persia: sorry, wasn't sure how long ago you wrote that :-P
[02:07] <persia> nickellery: That team has a special triage process.  My understanding is that only members of Desktop Bugs are supposed to assign Desktop Bugs, and that they typically get reassigned as soon as feasible.
[02:08] <persia> I believe it falls under the claim rule above: we're going to work on this, so talk to us before you do anything.
[02:08] <persia> Others oughtn't assign to them, as others can't know if it's a bug they wish to claim.
[02:08] <nickellery> persia:  I see, so generally you should keep away from assigning
[02:08] <nickellery> except for kernel bugs
[02:08] <persia> nickellery: Precisely.
[02:09] <nickellery> persia:  thanks for your help :)
[02:58] <nhandler> Could someone help me get 5-a-day working. I've followed the instructions in the wiki, but it doesn't seem like it is working
[03:04] <persia> nhandler: What error are you getting?
[03:05] <nhandler> persia: When I do an update-signature, I get "bzr: ERROR: No WorkingTree exists for "file:///home/cheater/.5-a-day-data/.bzr/checkout/".
[03:05] <nhandler> bzr failed with error code 768
[03:05] <nhandler> "
[03:08] <persia> nhandler: You might need to be in the 5-a-day team (I'm not sure)
[03:09] <persia> Ah, no I found it.
[03:09] <nhandler> persia: What is it?
[03:10] <persia> Nope.  I thought it was cheater@LP vs. cheater@nathan-laptop, but I'm mistaken.
[03:11] <nhandler> persia: Ok, and I am a member of the 5-a-day team on LP
[03:11] <persia> Right.  I was confused by cheater@LP.  My apologies.
[03:11] <nhandler> persia: It's oik
[03:11] <nhandler> s/oik/ok/
[03:14] <persia> nhandler: I think you got hit by bug 181367
[03:15] <persia> to work around it, call `cd ~/.5-a-day; bzr checkout .` (I think)
[03:15]  * persia welcomes anyone more familiar with 5-a-day to chime in
[03:20] <nhandler> persia: That fixed it. Thanks
[09:31] <leoquant> howto to get: Bug #237254 on the wishlist?
[09:42] <james_w> leoquant: asking in here is the best way
[09:42] <james_w> I've just done it for you, thanks.
[10:04] <james_w> hi Hobbsee, can I ask why you unconfirmed that report?
[10:05] <Hobbsee> james_w: pebkac - i loaded it, went to hit wishlist, and hit save changes - unfortunately, i got sidetracked, and saw that you'd gotten to the bug first.
[10:05] <Hobbsee> but didn't realise you'd also set it to confirmed.
[10:06] <Hobbsee> james_w: or whatever it actually was
[10:06] <james_w> Hobbsee: ah, no problem, want me to put it back?
[10:06] <Hobbsee> james_w: please do :)
[10:06] <james_w> sure, just wanted to make sure I hadn't made an error.
[10:06] <Hobbsee> nah, twas me.
[10:47] <thekorn> what's the best way of filing a translation bugreport? against which package? should I subscribe the related translation-team?
[10:56] <seb128> thekorn: open a bug against the corresponding language pack variant and subscribe the corresponding l10n team on launchpad
[10:57] <thekorn> seb128, ok, thanks
[14:26] <Iulian> Hey
[14:57] <thekorn> bug 153380
[15:40] <bddebian> Boo
[15:42] <persia> bah Bim DING!
[15:42] <bddebian> :)
[16:59] <persia> This might be a reasonable fallback channel for a QA meeting
[17:00] <pedro_> persia: is going to happen on #ubuntu-testing
[17:00] <pedro_> QA Meeting on #ubuntu-testing feel free to join us
[17:17] <yuriy> time conflict for the meeting?
[17:18] <persia> yuriy: Essentially.  Ought be better next time :)
[17:19] <yuriy> also how come this is the first time i've heard of these meetings
[17:19] <yuriy> they were never announced to buqsquad before
[17:20] <pedro_> yuriy: they were announced in the ubuntu-qa mailing list, i'll make sure to announce them to the bugsquad weekly from now on :-)
[17:20] <persia> Maybe just accident?  Anyway, meetings are good :)
[18:55] <pwnguin> is there a special trick to debugging a system freeze by serial port?
[19:04] <persia> pwnguin: Yep.
[19:04] <pwnguin> doh
[19:05] <pwnguin> if its complicated i dont want to recommend it over LP
[19:06] <persia> pwnguin: http://wiki.sangoma.com/wanpipe-linux-system-debugging is a fairly short guide to capturing an OOPS, but it's not trivial.
[19:06]  * pwnguin wonders if usb - > serial devices really work
[19:06] <pwnguin> i thought usb was userspace
[19:53] <afflux> hi
[19:55] <nhandler> Hi afflux
[20:09] <nhandler> Does anyone here know why I keep getting an error code 104 when I try to add a bug using the 5-a-day-applet?
[20:11] <afflux> nhandler: not sure, but you could check /tmp/5-a-day-applet.txt or ~/.bzr.log
[20:12] <nhandler> afflux: /tmp/5-a-day-applet.txt has this message:
[20:12] <nhandler> bzr failed with an error. Debug information: None None
[20:12] <nhandler> ... Finished with ErrCode 106
[20:14] <afflux> nhandler: hm, anything more useful in ~/.bzr.log?
[20:16] <nhandler> afflux: Here is my ~/.bzr.log: http://pastebin.ubuntu.com/16947/
[20:16] <nhandler> afflux: I don't know enough about how bzr works to know what the stuff means in there
[20:17] <afflux> you somehow created conflicts in the .5-a-day-data directory. Either remove it and pull it again or resolve the conflict
[20:18] <james_w> WARNING: Conflict adding file .teams.  Moved existing file to .teams.moved.
[20:19] <james_w> that may be a bug in 5-a-day, I don't know. I'm just on my way out, so I can't look now.
[20:20] <nhandler> afflux: james_w: I removed the .5-a-day directory, but I still get the error when I try to use the applet. Does this mean anything "NotBranchError: Not a branch: "/home/cheater/"."
[20:20] <afflux> nhandler: err, yes, that looks like it means something
[20:21] <nhandler> afflux: Do you know what it means?
[20:22] <afflux> nhandler: it means 5-a-day is trying to access a path which is not a bzr branch. Actually, it's trying to access the wrong path. Let me check some things, wait a minute.
[20:22] <nhandler> afflux: Ok
[20:24] <afflux> nhandler: what happens if you do a simple "5-a-day --update"
[20:27] <nhandler> afflux: It says: Tree is up to date at revision 4387.
[20:27] <afflux> nhandler: that sounds good. What happens on adding now exactly?
[20:28] <nhandler> afflux: It says that the bug was already added today (which it has). Is there any way to verify that it actually submitted the data?
[20:29] <afflux> yes
[20:29] <nhandler> afflux: How?
[20:30] <afflux> you can: "cd ~/.5-a-day-data; bzr status" and check if your file shows up. If it does not show up and the bug number is in the file, it's submitted.
[20:31] <nhandler> afflux: Here is the result of bzr status: http://pastebin.ubuntu.com/16952/
[20:32] <afflux> nhandler: oh. I wonder what went wrong there. Try removing .teams and .teams.moved and "bzr up"
[20:33] <nhandler> afflux: I removed .teams and .teams.moved. Then I did "bzr up". However, "bzr status" still shows the same thing as before
[20:34] <afflux> err? that's weird. What did bzr up say?
[20:34] <nhandler> afflux: bzr up said "Tree is up to date at revision 4387."
[20:34] <afflux> grr... seems like bzr does not like me
[20:35] <nhandler> afflux: What do you mean? It doesn't like me. It is probably working fine for you.
[20:38] <afflux> nhandler: "bzr revert" may help
[20:38] <nhandler> afflux: After "bzr revert", "bzr status" says: unknown: nhandler
[20:39] <afflux> nhandler: bzr add nhandler
[20:39] <nhandler> afflux: Now "bzr status" says: added: nhandler
[20:39] <afflux> nhandler: perfect
[20:40] <afflux> nhandler: well, that means that we can push the data to the server now (usually you don't have to do this on your own). bzr commit -m "added nhandler" nhandler
[20:45] <nhandler> afflux: I had to do a "bzr update" before I could do commit. It looked like the commit worked. And the nhandler file contains a list of all the bugs I submitted. But shouldn't I show up on http://daniel.holba.ch/5-a-day-stats/
[20:45] <afflux> nhandler: that page is updated every hour. check again in 10-15 minutes.
[20:48] <nhandler> afflux: I'll check it out later. If it doesn't work, I'll probably end up back here ;) Thanks again for the help
[20:49] <afflux> hehe, you're welcome ;)
[21:17] <bdmurray> thekorn: I've updated the bug check list with your suggestion
[21:19] <thekorn> bdmurray, ok, cool, thanks
[23:33] <lberg> hey....is there any bug regarding the rt73 chipset reporting different bitrate speeds between nm-applet and iwconfig?
[23:33] <lberg> nm-applet reports 2mbps :( :( but iwconfig reports 54mbps.
[23:33] <lberg> yet my connection is excrutiatingly slow.
[23:55] <soonick_cancun> hello everyone. I have just sign in to ubuntu bugsquad becouse i would like to help fixing ubuntu bugs but i dont know how to start
[23:55] <soonick_cancun> can someone help me?
[23:58] <lberg> soonick_cancun: idk if anyone's "here" right now....I asked a uestion like half an hour ago....
[23:58] <lberg> **question