[01:04] <bobboy> Hi I would like to discuss a possible bug with someone.
[11:20] <ligemeget> Can someone please tell me if it was wrong of me to open bug 232166 ?
[14:00] <sectech> That's two bugs that users changed back to new from incomplete on me... right in the middle of me asking for information...
[14:01] <james_w> sectech: you changed it, and then went to add the comment afterwards?
[14:02] <sectech> james_w,  I asked for information... they provided it.. and changed it back to new from incomplete themselves... I always look at a persons profile if they do that, they were new enough to launchpad...
[14:02] <james_w> sectech: I don't think that's a problem.
[14:02] <sectech> I left a note stating while a bug is in triage it stays as incomplete (as new indicates a triager hasn't looked at it yet)
[14:03] <james_w> ah, ok.
[14:04] <sectech> james_w,  I was under the impression that if a bug was in the process of being triaged, it's incomplete until it can be marked as confirmed or invalidated
[14:04] <james_w> I'm not sure what the best thing to do is here, I think New is ok for them, but I realise that I may not be in the majority on this.
[14:05] <sectech> I just figure it risks not having multiple triagers noticing the same bug and asking for the same information (saves on resources)
[14:06] <hggdh> james_w: usually, New is meant as not yet worked on, re-opened
[14:07] <hggdh> if there are questions being asked to the reporter, or actions required from the reporter, it should be either Incomplete or Triaged
[14:09] <james_w> but if the user has provided the required information, but the triager hasn't been able to move it forward yet?
[14:09] <sectech> Anyone good with gnome-do? I have a bug #230908 that I am getting no where with
[14:10] <sectech> I am not sure what else to ask for.... I have checked for dups... and I am trying to figure out if gnome-do is even related....
[14:11] <sectech> james_w, I can understand if a triager hasn't replied in quite some time.... If they don't set it back to new it could expire... but they shouldn't set it to new right after replying with new info
[14:42] <sectech> Okay, no one wants to look at that bug... that's fine...   Are we allowed emailing the reporter ourselves to ask questions? I don't want to fill up the bug with a lot of chat conversation...
[14:43] <Iulian> sectech: Please add comments to the bug report. It doesn't really matter if they are too long.
[14:43] <Iulian> sectech: And btw, what bug?
[14:44] <sectech> Bug #230908
[14:44] <sectech> Okay... I'll stick to launchpad.
[14:44] <Iulian> Sure
[14:45] <sectech> I don't want to abandon bugs.... but I don't know what more to do with this one, I can't find a problem in the log files
[14:46] <sectech> I installed gnome-do and was unable to reproduce the problem
[14:46] <hggdh> sectech: if the problem is on resuming from suspend, it probably has to do with hardware
[14:47] <sectech> hggdh,  but he stated that if he removes gnome-do it resumes fine...
[14:47] <sectech> The next step was for me to treat it as an ACPI issue and request those logs
[14:47] <hggdh> sectech: so OK, gnome-do seems to be doing something
[14:49] <hggdh> sectech have you looked at https://wiki.ubuntu.com/DebuggingKernelSuspend?highlight=%28Debugging%29?
[14:49] <sectech> No I haven't.... I'll take a look at it now
[14:50] <hggdh> and -- sectech -- if you get over your head on a bug, there is no shame is saying so, and doing something else.
[14:51] <hggdh> in this case, I agree with james_w -- if you were working on a bug, and cannot keep on, it might be a good idea to put it back into New. Just add a comment stating why you are doing that
[14:52] <sectech> hggdh,  I know...   I wasn't able to consult with anyone in the channel until now though.... I'll look at that wiki and see if I can come up with anything.... If not, I'll note it and return it to new
[14:52] <sectech> hggdh,  I won't let bugs expire just because I can't triage them... I just don't want to be giving up too soon
[14:53] <hggdh> sectech: that's OK, and methinks we all agree on doing that. Unfortunately, I do not deal with ACPI/suspend/etc. Never even tried to do it on my laptop ;-)
[14:54] <sectech> hmm... I just read that wiki... It looks like this one might have to be set back to new again
[14:56] <james_w> sectech: it sounds pretty odd.
[14:56] <james_w> I cannot reproduce either.
[14:56] <sectech> james_w,  I am not 100% convinced that gnome-do is causing the bug....  It might appear is it is, but I don't think it's the case
[14:57] <sectech> I have been fighting with this one for a few days now trying to find out what else might help
[15:03] <hggdh> sectech -- do something else. Leave it be for some time, and either get another bug (thank you, BTW), or -- <gasp/> -- walk around in the park, or whatever :-)
[15:03] <sectech> I released the bug back to the wild... I'll watch it to see what someone else does, if someone else takes it
[15:04] <hggdh> eventually, someone will. Also, gnome-do causing problems with suspend cannot be said to be a critical issue
[15:04] <sectech> hggdh,  heh don't they say the best answers come when your on the toilet? j/k haha
[15:05] <hggdh> :-)
[15:05] <sectech> yeah I gave this one a good shot....
[15:06] <sectech> I can use this bug as a good example bug when I eventually apply to bug control "Knowing when to give someone else a shot at the bug and releasing it"
[15:07] <hggdh> sectech indeed. It is not only what bugs you did a good job (usually meaning you successfully triaged/resolved the issue), but also the bugs you tried, and failed (and accepted the failure)
[15:08] <hggdh> per the reporter description, sounds like ACPI issues on suspend/resume
[15:10] <sectech> I need a good wiki to use privately so I can keep track of bug tracking issues... Using Tomboy is good locally, it lacks what I need though
[15:11] <sectech> Something that I can add my own personal notes to...
[15:12] <hggdh> well, there's wiki.ubuntu.com
[15:12] <hggdh> but everybody will be able to see it also
[15:13] <sectech> I am going to throw up a wiki about me eventually,  if wiki.ubuntu.com is appropriate I'll use that... but I would like something private for my own triage stuff
[15:13] <sectech> I'll find something
[15:54] <sectech> What do we do with problems with the non-free nvidia drivers? I have a bug report that relates to that
[15:57] <james_w> sectech: if they installed the ones from Ubuntu and it is related to them not working then look for the appropriate linux-restricted-modules package
[15:57] <sectech> k
[15:57] <james_w> linux-restricted-modules-2.6.24 for hardy I think
[16:05] <sectech> james_w,  Is there a hardware list of what video cards are supported?
[16:05] <james_w> I'm not sure I'm afraid.
[16:06] <sectech> Found something
[17:12] <sectech> Bug #231986... Should I be reporting this upstream to kernel.bugzilla?
[17:17] <_max> #93360
[17:17] <_max> Bug #93360
[17:18] <_max> Bug #39707
[17:18] <_max> those two bugs address sort of the same problem with dhcdbd causing one to loose connection to the network, and recieving dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth1 for sub-path
[17:19] <_max> when this happens to me it seems to broadcast something onto the switch, cause -every- port on the switch starts flashing with 1 second intervals
[17:19] <_max> the funny thing is that it -kills- the switch, all clients connected to the other ports are cut of from the network
[18:28] <afflux> morning
[18:33] <Iulian> Hey afflux
[18:34] <afflux> hi Iulian
[20:56] <sectech> I need some advice on bug #231986, I am not sure if I should report this bug upstream in kernel.bugzilla or not
[21:25] <hggdh> sectech: you there?
[21:28] <sectech> hggdh, yes
[21:28] <hggdh> on this sound issue -- what is the reporter's sound card?
[21:28] <hggdh> I cannot find it
[21:29] <sectech> It's a laptop... All I have is the chipset for it,  I did make the request for the standard hardware detection debugging files though
[21:30] <sectech> I wasn't going to put in a report up-stream until I had those files.
[21:30] <sectech> It's a ALC861VD chipset I believe
[21:31] <sectech> I already looked for dups and I looked through kernel.bugzilla
[21:31] <sectech> The odd thing is that lspci -vvv doesn't even show the audio device
[21:32] <hggdh> yes
[21:32] <hggdh> you might try on #ubuntu-kernel
[21:38] <sectech> heh, I just gave a short description of the issue and referenced the bug but I doubt I'll get a reply... Topic states "Ubuntu kernel development discussion ONLY"
[21:38] <sectech> And the reporter just added what I had requested... brb
[21:45] <hggdh> I do remember there were people dealing with audio here, but I do not remember where...
[21:54] <sectech> hggdh, I did get a reply after all... It is a known issue...  They asked me to request that the user run a specific script to get more info...
[21:55] <hggdh> good
[21:55] <hggdh> :-)
[21:55] <sectech> hggdh,   Once I get that info I'll confirm the bug... I'm not sure if it should go upstream though
[21:55] <hggdh> no, I do not think so
[21:56] <sectech> okay... It will remain confirmed then...
[21:56] <hggdh> you could set it to triaged. The kernel people will eventually get to it
[21:59] <sectech> .... I would if I could but I am not bugcontrol yet...
[21:59] <limcore> hello
[21:59] <sectech> hggdh,  lol should I just apply now to bug-control and if accepted keep doing what I am doing?
[21:59] <limcore> how about stopping ubuntu from farting? It is on by default, and it seem to annoy new users, especially ones that user console
[21:59] <limcore> (or firefox ctrl-f)
[22:01] <hggdh> sectech -- tell me when you are done, and I will set it
[22:01] <hggdh> limcore: what do you mean?
[22:01] <sectech> okay...
[22:01] <limcore> hggdh: open firefox, ctrl-f, type in asdf
[22:01] <limcore> or, open a console, type letter a and press and hold tab
[22:02] <limcore> hackedbian didnt fixed this 1990's style approach to UI sound... perhaps ubuntu should?
[22:02] <hggdh> limcore: I am not sure what you would want to find in an empty ff page
[22:03] <hggdh> on both of them I have no sound
[22:03] <limcore> hggdh: on default ubuntu installation, in both situtions, the computer will fart loudly
[22:03] <limcore> of course this can be disable... but why not make the default to be not annoying
[22:04] <sectech> limcore,  I have a default ubuntu install... I don't hear a thing
[22:04] <limcore> you do have pc speaker working?
[22:04] <hggdh> limcore: please have a look at System/Preferences/Sound/Sounds
[22:05] <hggdh> no, no PC speaker
[22:05] <limcore> most people in EU do
[22:05] <limcore> and they are annoyed by the farting
[22:05] <hggdh> but go there, and tell me the name of the offending sound
[22:05] <limcore> hggdh: right, it can be disabled, but why the default
[22:06] <limcore> hggdh: bash terminal,  vim,  firefox,  thoes apps by default use pc speaker if not configured properly.  I dont know what do you mean by name of sound?
[22:06] <hggdh> limcore: if a sound is played, this sound will correspond to a "name", a file name to be played
[22:07] <limcore> hggdh: no sound is played, at least for vim, bash - they simply use system beep.
[22:07] <sectech> Oh I know what you mean... system bell
[22:07] <sectech> he is wondering why the system bell is turned on by default..
[22:07] <limcore> sectech: mostly, but that will affect only x terms... go to VT-1 and the problem is back again
[22:08] <limcore> also, firefox is a separate setting
[22:08] <limcore> overall, most users are probably pissed of by random farting. It should be turned off therefore
[22:09] <limcore> for example a  [x] STFU!  option in installation menu.  if active, then all kde/gnome apps sounds are set to none,   bash bell is off,   vim bell is off,   sound system system bell is off, also firefox, and so on
[22:09] <hggdh> limcore, on one of my machines, standard Ubuntu install, I have a beep
[22:11] <hggdh> limcore: anyway: this is not the correct venue for your request: you can open a bug stating the default bell is not nice, or you can email ubuntu-dev-discuss, if you want to propose a generic change
[22:13] <hggdh> but I cannot reproduce your issue here (and I am *assuming* you are talking about a low-frequency sound)
[22:13] <limcore> hggdh: ?
[22:13] <limcore> how come you can not reproduce it?
[22:13] <limcore> everyone else knows what Im talking about
[22:14] <hggdh> all I get is system beep -- medium frequency sound
[22:14] <hggdh> limcore: everyone else may know, but I do not
[22:14] <limcore> thats what I call farting
[22:14] <limcore> have a chilloutburger, it was a joke :)
[22:14] <hggdh> limcore, sorry, but I tend to be literal.
[22:14] <limcore> however, the issue is serious - the default sound is annoying, at it wastes user time to get rid of it
[22:16] <sectech> limcore,  this isn't the right group to be stating that to though, we cannot fix it...  We triage bugs and troubleshoot
[22:16] <limcore> sectech: ok, perhaps ubuntu's brain storm
[22:16] <hggdh> I again suggest you to email ubuntu-dev-discuss, and expose your issue, why you think the current bevhaviour is not good, and what you propose instead. #ubuntu-bugs is not the correct place to make this change
[22:16] <limcore> cool, hggdh
[22:39] <hggdh> limcore: tell you the truth... every so often I also get annoyed by the beep
[23:16] <nabcore> localedef seems to be hanging when I install 8.04 server (i386), any ideas why?