[00:16] <pckchem> bdmurray ping
[00:26] <Hobbsee> bug 256345
[00:38] <bdmurray> pckchem: pong
[00:39] <pckchem> bdmurray: Hey I think I found a problem with the launchpad scripts
[00:39] <bdmurray> pckchem: uh, which launchpad scripts?  the greasemonkey ones?
[00:39] <pckchem> bdmurray: Yes, sorry
[00:39] <pckchem> bdmurray:
[00:39] <pckchem> bdmurray: When you use the supplied config.xml, the scripts don't work
[00:40] <pckchem> bdmurray: The fix is fairly easy, you just change the basedir to "/"
[00:40] <pckchem> for all the scripts
[00:41] <pckchem> OR you can just make a individual folder for each file
[00:41] <bdmurray> pckchem: can you report a bug at https://bugs.edge.launchpad.net/launchpad-gm-scripts ?
[00:42] <pckchem> Sure, I'm about to work up a patch right now. Just wanted to make sure that wasn't intentional before I did it :/
[00:42] <bdmurray> pckchem: I actually not sure what that bit does. ;-)
[00:44] <pckchem> bdmurray: :) . I didn't either until a few moments ago. Had a bit of a learning moment. This is also a nice excuse to learn more bzr
[00:45] <pckchem> bdmurray: Thanks, that's all.
[01:23] <andresmujica> hello,
[01:24] <andresmujica> anyone has a sony vaio laptop with a ricoh webcam?
[01:24] <andresmujica> i need to test a patch from Alexander
[01:24] <andresmujica> to solve a pair of bugs...
[05:32] <d-b_> hi there what is the proper method of getting a log / debuggin nautlius
[05:32] <d-b_> this bug is rather funny .... https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/195798
[05:34] <d-b_> --> bug actually is rather critical
[05:35] <d-b_> if you do as in the example -> make a file called 123.abc  and then make one called 123.ABC.txt
[05:35] <d-b_> then make rename 123.ABC.txt to 123.ABC -> it will delete the 123.abc file
[05:36] <d-b_> then if you make a new file called 123.abc to replace the deleted file it will delete the 123.ABC file
[05:36] <d-b_> yes the file is deleted.
[05:38] <d-b_> dolphin informs me that access is denied to writing a file such as 123.ABC if i have 123.abc
[05:38] <d-b_> mmm wait that might be my fault
[05:39] <d-b_> ok seperate bug in dolphin then
[06:49] <zzxxzz> Just bought new notebook, and installed ubuntu 8.10 - Notice that when a file is sent to trash, the icon remains the same, and pointing at it displays "No items in Trash", but I can right click on the icon and click on "Empty Trash" and empty the content. Anyone know how to fix this? Or is this a bug?
[06:52] <maco> sounds like a bug
[06:52] <maco> i cant imagine it's intentional
[06:54] <maco> i cant reproduce it
[07:02] <zzxxzz> maco: I assume you responded to me? A friend also has the same problem in 8.10, and my other computer using 7.04 does not. It seems to take us over a year to resolve problems after each upgrade as new problems appear in addition to the old ones.
[07:02] <maco> yes
[07:02] <maco> oh
[07:02] <maco> was it a fresh install or an upgrade?
[07:05] <zzxxzz> maco: I wanted to upgrade my  existing system from 7.04 but we've been unable to resolve a problem keeping us from backing up the home partition and our bug report was closed as 7.04 is no longer supported, so I bought a new computer and did a fresh install using the alternate CD.
[07:06] <maco> mine's a fresh install with an old /home too..
[07:07] <zzxxzz> maco: It's a new home also as we can't move the home from the old computer yet. In fact we've done nothing more than install 8.10 and apply all the recommended updates so far.
[07:07] <maco> er, that is weird. does it consistently do that?
[07:08] <jmarsden> zzxxzz: I just tried it here (I basically never use Nautilus myself!), and the icon changes just fine.  8.10 64bit, fresh install.  So what you are seeing is probably not the general case.
[07:08] <jmarsden> CAn you create a new user, log in as that user, and se if they also get the same issue?
[07:11] <zzxxzz> maco: Yes, the icon always shows an empty waste basket, and if I create a text file and send it to the trash is remains the same, and pointing to the icon displays "No items in Trash", but if I click on the icon the browser displays the file(s) in the trash, and if I right click on the icon the "Empty Trash" function does remove the content.
[07:12] <zzxxzz> jmarsden: My friends computer has 2 users and both user log ins produce the same result.
[07:13] <maco> jmarsden: any chance the fact that there was trash in my bin when i installed is why i cant reproduce?
[07:13] <jmarsden> No idea.  I can't reproduse the problem here either, starting from an empty wastebasket...
[07:15] <zzxxzz> I've tried to find where the icon choices are located to no avail, but I assume the fact that it states there is no content might be the reason the icon remains the same.
[07:16] <jmarsden> Yes, sounds more like the applet doesn't "notice" (wasn't told?) that someone put some trash in it, somehow.
[07:16] <maco> the one on the panel or the one in nautilus?
[07:17] <jmarsden> maco: There is a trash icon in Nautilus?  Where?
[07:17] <maco> in the bar on the left...
[07:17] <jmarsden> The one that changes state for me is the one in the panel.  Right-click and About shows: Trash Applet 2.24.1
[07:18] <maco> i dont have that in my panel :P well, i dont have a bottom panel
[07:18] <maco> just open your home directory and its on the left
[07:18] <dholbach> good morning
[07:18] <maco> hello
[07:18] <dholbach> hi maco
[07:19] <zzxxzz> I just checked the 7.04 system which works, and my home directory there has a .Trash directory which contains entries for the deleted files. The 8.10 system does not have a .Trash directory, but shows 3 files totaling over 500MB in the trash.
[07:19] <greg-g> Heya dholbach, good flight back?
[07:19] <maco> zzxxzz: they moved in 8.04
[07:19] <jmarsden> maco: OK, that one I would not expect to change visual state etc, it is just... an icon... right?
[07:19] <maco> !trash
[07:20] <maco> jmarsden: it changes
[07:20] <dholbach> heya greg-g - yeah all good - how was yours?
[07:20] <greg-g> dholbach: slept through most of it, so great.
[07:20]  * jmarsden peers at screen... you are right... 1600x1200 here, so it's a small icon!
[07:21] <dholbach> greg-g: hardly surprising after the last night at UDS :)
[07:21] <maco> can jorge actually sing?
[07:21] <dholbach> maco: yes :)
[07:22] <maco> saw a photo and went O_o "jorge?"
[07:22] <greg-g> dholbach: yeah, there are some pictures of me online that are... incriminating :)
[07:22] <maco> ah we should've found a way to make him karaoke at OLF
[07:22] <greg-g> maco: Penguicon!
[07:22] <maco> greg-g: huh?
[07:22]  * maco googles
[07:22] <zzxxzz> ubottu is correct, the files are in the new location, but the icon is not changing from empty, nor giving an indication there is something in the trash.
[07:23] <maco> greg-g: wait is that the one that Tamora Pierce spoke at and i saw on someone's shirt at OLF and got all upset that i missed an insane combination of my favourite author and my favourite operating system?
[07:24] <greg-g> maco: probably
[07:25] <jmarsden> zzxxzz: Do permisions on ~/.local and ~/.local/share and ~/.local/share/Trash/ all look sane on your systems?  I'm not sure what could be causing you to see this... guessing...!
[08:16] <BoogieBoo> Hi
[08:18] <BoogieBoo> Where CAN I find help to my VPN connection problem? I have been struggeling to make the VPN work in intrepid, yesterday I finally manged to make it to work following the launchpad bud documentation about this problem. Then I switched of the computer, when todays I switched on and tried to connect again, CONNECTION FAILED message, but the configuration is still the same...THIS IS NOT ACCEPTABLE if we want Ubuntu to start sp
[08:18] <BoogieBoo> reading into work computer,
[08:19] <BoogieBoo> Is there anyone that can help me with this please?
[08:30] <Ryan52> BoogieBoo: ask in #ubuntu? that might get you more help..
[08:31] <BoogieBoo> well I ask here because actually is a bug
[08:32] <BoogieBoo> It is a shame to spend more than a month to make to work somethign that it was working before the upgrade.
[08:32] <BoogieBoo> And more when it is something necessary for diary working
[08:32] <BoogieBoo> it is a shame
[08:33] <BoogieBoo> And it seems to be a taboo in internet, I can't find anyhelp anywhere
[08:33] <maco> er, is a bug filed?
[08:33] <Ryan52> BoogieBoo, this channel is for working on bugs/triaging bugs, I think :)
[08:34] <BoogieBoo> It is actually a BUG
[08:34] <BoogieBoo> VPN connections to PPTP servers in intrepid is a crape
[08:34] <Ryan52> okay...
[08:34] <BoogieBoo> Networkmanager is not working properly
[08:34] <BoogieBoo> But there are some Launchpad guides to solve it
[08:34] <BoogieBoo> and the solution is not in the reposteries yet
[08:35] <BoogieBoo> Yesterday I followed the launchpad, and I manged tom amke it to work
[08:35] <BoogieBoo> I had to edit gconf-edit by my self, etc.. because Networkmanager is not saveing the values correctly
[08:36] <BoogieBoo> after that it woked
[08:36] <BoogieBoo> however today I restarted the computer and the VPN is not working again
[08:36] <BoogieBoo> I checked the changes I made in gconf.efdit and they still were there
[08:36] <BoogieBoo> so I can't understand now why it is not working?
[08:37] <BoogieBoo> This is a crucial issue; Million of people need to access their offices networks remotely,
[08:37] <BoogieBoo> to WORK
[08:38] <Ryan52> BoogieBoo, it sounds like you need help with something. but regardless, if you think it's a bug, do you see the bug already reported? if so, then please provide any more information on the problem that you can into that bug report. if not, then please report it.
[08:38]  * Ryan52 notes that openvpn works for him...so it probably doesn't affect millions.
[08:39] <maco> Ryan52: its only pptp vpn
[08:39] <maco> cisco vpn is fine too
[08:39] <Ryan52> ah, didn't see that.
[08:40] <maco> yeah, we've been over this before
[08:40] <maco> i told him to try using the vpn from the command line to see if its the nm plugin's fault or the vpn client's fault, but i dont think he did
[08:40] <maco> doing that is how i found that the route wasnt being set right by nm, but that the command line vpnc was doing it right, so i knew a bug i had was actually in nm
[08:41] <maco> er, was actually in nm-vpnc
[08:42] <BoogieBoo> maco
[08:42] <BoogieBoo> maco, yesterday following the launchpad, I managed the VPN to work
[08:43] <BoogieBoo> maco, it seems that Networkmanager-pptp is not working properly, it is not saving the parameters correctly
[08:43] <BoogieBoo> maco, so I opened gconf-edit and I added some keys manually and It worked, some keays as "refuse-eap"
[08:43] <maco> is the command line vpnc working?
[08:43] <BoogieBoo> vpnc is for cisco
[08:43] <maco> er, not vpnc
[08:43] <maco> vpn
[08:43] <maco> yeah, vpnc is what my fingers automatically do since i use it for school wireless :P
[08:43] <BoogieBoo> ah, vpnc ok, I am going to try in a minutes
[08:44] <maco> i dont know the command
[08:44] <maco> but im sure the linux-pptp must have a command
[08:44] <BoogieBoo> maco, well, so yesterday I was all the evening connected properly
[08:44] <BoogieBoo> maco, yesterday it was workign properly!
[08:44] <BoogieBoo> maco, today I switch on the computer again, and it is not working again
[08:45] <BoogieBoo> maco, I checked that all the chanegs I made in gconf-efit are still there after the reboot, and they are
[08:45] <BoogieBoo> so this is crace
[08:45] <BoogieBoo> crazy
[08:45] <BoogieBoo> this is really crazy unstable
[08:45] <maco> look, ive had odd bugs pop up from in nm caused by it not knowing how to handle bugs in my wireless driver
[08:45] <maco> so please try a command line method
[08:45] <maco> those are generally more failure-resistent
[08:46] <maco> ex: i cant connect to wep with nm because nm gets confused when my driver drops a few packets, but the command line does not.
[08:47] <BoogieBoo> I will try
[08:51] <BoogieBoo> nothing
[08:52] <BoogieBoo> looking at the syslog I can't understant whta is going on, the messages are not clear!
[08:55] <BoogieBoo> the funny thing is that here the other XP machines are already connected to the VPN
[09:04] <wicope> I really feel in a deadend, I don0t know what else can I do to solve this guys
[09:05] <wicope> and I really need it to work
[11:13] <hggdh> wicope: did you open a bug on this?
[11:33] <CrownAmbassador> Guys I'm lost! I just joined the bugteam, but have no idea where to go to start helping. Any help please?
[11:34] <BUGabundo_work> CrownAmbassador: how about taking a look at the most recent bugs?
[11:34] <BUGabundo_work> also ,if you dare, subscribe to some packages bug-mail
[11:34] <BUGabundo_work> or if you are crazy enouth the entire UBUNTU bug mail
[11:34] <BUGabundo_work> or just use feeds CrownAmbassador
[13:27] <duanedesign> I think the Importance of the following bugs should be set to  Wishlist
[13:27] <duanedesign> bug  #307684
[13:27] <duanedesign> bug #307715
[13:27] <duanedesign> bug #307796
[13:28] <duanedesign> bug #307744
[13:28] <duanedesign> Thank you for your help
[13:34] <asac> maco: thats as-designed, yes.
[13:35] <asac> its not undebated whether thats the right thing to do, but its currently a feature
[13:40] <BUGabundo_work> ogasawara maco removing the eth Sky2 driver helped suspend/hibernate to work with jaunty kernel
[13:40] <BUGabundo_work> I also got the pics and video of the crash... uploading now
[13:48] <maco> asac: how does one force the wireless to disconnect?
[13:48] <maco> BUGabundo_work: good to know, since this laptop has sky2
[13:49] <BUGabundo_work> LOL
[13:49] <BUGabundo_work> so don't use .28-2 kernel
[13:49] <BUGabundo_work> lol
[13:50] <BUGabundo_work> maco I disconnect  my wifi via soft switch
[13:50] <BUGabundo_work> no other way AFAIK
[13:50] <BUGabundo_work> but I've seen a few people complaing about the way NM07 connects to both wifi and eth (making a bridge)
[13:56] <asac> maco: right click on applet and "disable wireless" is a workaround
[13:58] <BUGabundo_work> it is asac... as long as kernel doesn't crash
[13:58] <BUGabundo_work> or you can enable it again
[13:58] <BUGabundo_work> it still doesn't work for everybody
[13:58] <BUGabundo_work> plus for some really strange reason
[13:59] <BUGabundo_work> enableling and disbling net interfaces seems to freeze the system for a few secs (2-3 sec)
[14:14] <asac> BUGabundo_work: freezes are driver issues
[14:14] <asac> iwl* stuff has that
[14:21] <BUGabundo_work> ahh
[14:21] <BUGabundo_work> but I get the same even for eth card
[14:22] <BUGabundo_work> and my card uses Sky2 driver asac
[14:33] <asac> BUGabundo_work: hmm ... does that driver use mac80211 stack?
[14:33] <BUGabundo_work> how can I check asac?
[14:43] <BUGabundo_work> ogasawara: maco: bug # 308185
[14:43] <BUGabundo_work> ogasawara: maco: bug #308185
[15:15] <asac> BUGabundo_work: lsmod | grep 802
[15:24] <BUGabundo_work> asac: http://paste.ubuntu.com/85625
[15:30] <asac> BUGabundo_work: so you have iwlagn chipset
[15:30] <asac> -> 15:14 < asac> iwl* stuff has that
[15:30] <BUGabundo_work> for the wifi, yes
[15:30] <BUGabundo_work> but I said that also the ethnet card would make the same freezes on NM
[15:31] <BUGabundo_work> EVEN with wifi turned off
[15:40] <KennethVenken> Hello, the person reporting bug 215915 just installed ubuntu 8.10 and isn't experiencing the problem any more, (had the problem with 8.04 beta). Currently the status is set to new. To what should i set the status: Invalid or Fix Released?
[16:34] <bdmurray> mvo: ping
[16:37] <mvo> hey bdmurray
[16:38] <bdmurray> mvo: Made it back safe?  Where are the release notes fetched when using 'update-manager -d'?
[16:39] <mvo> bdmurray: http://archive.ubuntu.com/ubuntu/dists/jaunty/main/dist-upgrader-all/current/ReleaseAnnouncement
[16:39] <mvo> bdmurray: that is the default location
[16:39] <bdmurray> mvo: and would it use the apt proxy to get that file?
[16:40] <mvo> bdmurray: hm, it should, let me check
[16:41] <mvo> bdmurray: yeah, newer version of u-m should honor the apt proxy (and the gconf proxy) for this. not sure when exactly this was added (but I can check the bzr logs)
[16:42] <bdmurray> mvo: I'm having an issue getting the release notes with apt-cacher right now
[16:46] <bdmurray> mvo: Okay, I got it - it's probably a bug with apt-cacher
[16:50] <mvo> bdmurray: ok, thanks
[17:35] <bddebian> Boo
[17:46] <MrKanister> Hi. Can someone please set the bug +308224 to wishlist
[18:31] <imachine> Hi
[18:31] <imachine> i've had issues with building nvidia drivers on updated 8.04 (updated to 8.10)
[18:32] <imachine> i'm on x86_64, dkms fails telling me it cannot determine kernel version
[18:32] <imachine> I've seen something similar on gentoo forums, and the problem was no asm-i386 in the 'include' dir for kernel sources (or headers)
[18:32] <imachine> I've symlinked, no go.
[18:34] <chrisccoulson> imachine - if you're looking for support, then you might like to try the #ubuntu channel
[18:34] <imachine> well, I'm not exactly looking for support.
[18:34] <imachine> I'm trying to pinpoint this bug, so we can develop a fix, together.
[18:34] <imachine> I've searched forums, generic ones, and found numerous solutions, yet none were able to fix this issue.
[18:35] <imachine> it doesn't seem like a simple 'pebkac'
[18:35] <imachine> :)
[18:35] <chrisccoulson> is this a bug with the ubuntu packaged nvidia drivers or are you trying to get the drivers from the nvidia website working?
[18:35] <imachine> nope, ubuntu packaged.
[18:35] <imachine> like I wrote, dkms fails at building them.
[18:36] <imachine> both using envy or the standard gtk2 driver thingy.
[18:36] <chrisccoulson> ok, i probably can't help you with that. the person who would normally be able to help (tseliot) is not here at the moment
[18:36] <imachine> ok
[18:36] <imachine> I see he wrote envy
[18:37] <chrisccoulson> that's right
[18:37] <imachine> that's cool, envy fails too since it seems a compilation error.
[18:37] <imachine> I mean envy etc does everything correctly, only fails later on, during the build itself.
[18:38] <imachine> http://pastebin.com/m6320267
[18:38] <imachine> this is what envy spews
[18:39] <imachine> http://pastebin.com/m1fb153eb and heere's the make.log
[18:40] <thekorn> I'm sure there are bugreports about this issue somewhere on launchpad
[18:40] <thekorn> let me try to find one
[18:41] <imachine> I've found it too
[18:41] <imachine> (well some of it)
[18:41] <imachine> but not much solutions.
[18:41] <imachine> I've seen the most informative on gentoo forums.
[18:41] <imachine> however their fix (the asm-i386) didn't quite help.
[18:42] <imachine> maybe I'm missing some build packages?
[18:42] <imachine> or have one too many, conflicting?
[18:48] <thekorn> sorry, I think I can't help you further, because I don't find the bug I was searching for
[18:49] <imachine> #
[18:49] <imachine> *** Unable to determine the target kernel version. ***
[18:49] <imachine> that's the line you'd find the report by
[19:01] <imachine> http://bbs.archlinux.org/viewtopic.php?pid=328232#p328232 some more info here
[20:56] <JugglerLKR> hi
[20:56] <JugglerLKR> anyone here?
[22:03] <danage1> i'm getting kernel panics (caps lock blinking) on a thinkpad x61s that is otherwise working fine. my suspect is ath9k. any quick commands that i could run/logs to check for a first debugß
[22:03] <danage1> upon second thought, it could also be virtualbox
[22:05] <LaserJock> bdmurray: around?
[22:05] <bdmurray> LaserJock: indeed
[22:06] <LaserJock> bdmurray: is there any bug policy for teams to sort of opt-out of triage?
[22:06] <LaserJock> or perhaps opt-out of parts of triage
[22:07] <bdmurray> Not that I know of
[22:07] <LaserJock> some of the general triage policies aren't fitting what I'm trying to do so well and I'd rather not have people (me, the team, and triagers) waste time
[22:08] <LaserJock> right now the only problem is people marking bugs as invalid due to inactivity
[22:09] <LaserJock> when they get marked Invalid they drop off the "radar"
[22:09] <bdmurray> From what state to Invalid?
[22:09] <LaserJock> usually Incomplete I think
[22:10] <LaserJock> the most common case is a triager does a "Is this bug still affecting you?" then some time later another triagers marks it Invalid because of a lack of response
[22:11] <LaserJock> which I know makes sense from a general perspective, but I'm looking at having to go through ~ 150 Invalid bugs looking for good bugs
[22:12] <bdmurray> I'd be interested to find out what makes a good bug and modifying the instructions for bug to Incomplete if they can be general cased.
[22:12] <LaserJock> what makes a good bug is having enough info to try to reproduce the bug
[22:12] <LaserJock> i.e. they gave some steps
[22:13] <LaserJock> or described what happened
[22:14] <LaserJock> I don't like having bugs marked as Invalid before we confirm that 1) we can't confirm it or 2) it's not a real bug
[22:15] <calc> LaserJock: in many cases the 'is this bug still affecting you?' is asked because the user didn't give enough information to begin with or its generally not reproducible
[22:16] <calc> LaserJock: so if the user also doesn't respond to the question then its no longer known to be reproducible by anyone at all
[22:16] <LaserJock> calc: that's not my experience
[22:16] <LaserJock> most often triagers don't even attempt to reproduce
[22:17] <LaserJock> and demand stuff from the reporter that I feel is not required to look into the bug
[22:17] <LaserJock> I want triagers to attempt to reproduce before closing
[22:17] <calc> LaserJock: demand what kind of stuff? i usually ask for an example file showing the problem (for OOo)
[22:17] <hggdh_> LaserJock, yes, I have seen it happen
[22:17] <LaserJock> if they can't reproduce and it looks like a one-off fine
[22:18] <calc> since the majority of the time i can't reproduce users bugs just from what little they report initially
[22:18] <calc> but i have also seen crack triagers as well
[22:18] <LaserJock> but I'd say a majority of my bugmail is from triagers closing my bugs for no good reason
[22:18] <LaserJock> and it makes it difficult for me because I have to go "fix" bugs
[22:19]  * calc has had the same problems at times
[22:19] <calc> some people close bugs mistakenly that are upstream... because they are upstream
[22:19] <LaserJock> at the point the "noise" is pretty high
[22:19] <bdmurray> Have you documented how to triage the packages you are talking about?
[22:20] <LaserJock> bdmurray: no, but I shouldn't have to
[22:20] <LaserJock> they're just general packages
[22:20] <LaserJock> about 30 or so of them, mostly in Main but some in Universe as well
[22:21] <LaserJock> my concern is that I'm losing info due to triaging, whereas I should be *gaining* info from triaging efforts
[22:22] <LaserJock> I realize that a lot of the problem would be sorted if we got to bugs faster, and triagers are just doing what they're told/trained to do
[22:23] <LaserJock> but I just don't see us getting to these bugs much faster  in the immediate future so I'd rather not lose the info
[22:24] <LaserJock> so I was wondering if there were any good ideas from the bug gurus :-)
[22:25] <hggdh> LaserJock, what packages are you being hit on?
[22:25] <LaserJock> they're random ones
[22:25] <calc> LaserJock: would an in-between status be useful for closing and only allow invalid/wontfix for bugsquad/maintainers or something like that, of course i don't know if that would be usable
[22:25] <LaserJock> but I focus on Edubuntu and Science packages so that's where I see it
[22:26] <hggdh> could you give us some examples?
[22:26] <hggdh> of bugs
[22:26] <LaserJock> sure
[22:26] <bdmurray> LaserJock: earlier you said 'demand stuff from the reporter that I feel is not required' which leads me to believe that documenting what you do think is useful for those packages would be helpful.  I also think there could be a general clearer policy on 'try as hard as possible' to recreate the bug before moving a bug from New -> Incomplete.
[22:27] <LaserJock> hggdh: bug #241610
[22:28] <calc> LaserJock: well they could have checked if it still affecting eg intrepid but not reporting bugs correctly does cause problems in many cases
[22:28] <LaserJock> bdmurray: the problem is that it's not a package-specific thing. I mean I can write up a doc for each one that says "please reproduce before closing" but I don't know that'd help all that much
[22:28]  * calc thinks that firefox apport plugin needs writing sooner than later
[22:28] <calc> and/or completely turn off reporting of bugs to regular packages in the web interface
[22:29] <hggdh> good example, LaserJock... the reporter does state what is needed to reproduce the issue
[22:29] <calc> hggdh: however using this as an example if the triager noted it did not affect current release they would have to somehow test all releases or ask the user that questions
[22:29] <calc> er question
[22:30] <LaserJock> a borderline example is bug #95292
[22:30] <calc> i often get bug reports still on dapper, etc many times without any apport info
[22:30] <LaserJock> it's not a great bug, but it's something I want to keep around
[22:30] <hggdh> calc, I agree. But the reporter did not state the versions of Ubuntu and Kino, and the closer -- I guess, just went for "too old, let's close it"
[22:31] <hggdh> Laserjock, a question, if you do not mind: when would a bug be "too old to consider". I understand this is a rather loaded question
[22:31] <calc> hggdh: i agree on the it should have been tested which it appears not to have been, but we have a huge percentage of drive by bug submitters who don't respond to any questions at all, even truely important ones
[22:32] <LaserJock> I don't understand why bug #125326 was closed
[22:32] <calc> hggdh: which probably has jaded our triagers
[22:32] <LaserJock> hggdh: there is no such thing as a bug too old
[22:32] <calc> with low quality submissions of bugs, submitters who never respond to bugs, triagers probably often don't feel like putting too much time into an individual bug
[22:33]  * calc personally tries to reproduce anything he can, but when that doesn't happen it often eventually ends up closed invalid since the submitter never responds to any questions at all
[22:33] <LaserJock> generally for me, 1) a bug can't be too old and 2) a reporter shouldn't need to respond to keep a bug open
[22:34] <LaserJock> but like I said before, I totally realize that some packages like firefox, OO.o, etc. have to have a different view
[22:35] <LaserJock> I'm just not sure one-size-fits-all triaging is a great idea
[22:35] <danage1> LaserJock: yes there is
[22:35] <calc> LaserJock: well if the quality of a bug report is so bad that you really can't figure out what the submitter is trying to say (for example) and can't reproduce the bug (and you have tried) and the submitter never responds then yes i believe in the general case the bug should be closed invalid
[22:35] <hggdh> the way I see it, we need to have base rules (that will apply if no exception is requested); but we should also cater for exceptions...
[22:36] <hggdh> which is the base rule ^^
[22:36] <calc> the qcad crashing example is a good example for the wrong reason
[22:36] <LaserJock> calc: agreed, but that's based on the bug reports merits, not on whether the reporter responds
[22:36] <calc> if it doesn't constantly crash then the triager wouldn't be able to do anything with that bug anyway since the user didn't attach the needed crash dump, etc
[22:36] <LaserJock> I don't want people closing bugs because somebody doesn't respond regardless of whether the bug has useful info
[22:37] <calc> asking if it is still reproducible is the wrong question but the user never responded at all so probably wouldn't have submitted a crash report either
[22:37] <LaserJock> some of these bugs are *very* old, some of the reporters probably aren't even using Ubuntu anymore
[22:37] <calc> ah yea the qcad bug is pretty old
[22:38] <calc> but the quality of the qcad bug itself isn't high enough that i would consider it useful to keep open
[22:38] <calc> qcad crashes... doing what exactly, no info, no crash report, etc
[22:38] <LaserJock> I'd probably close it
[22:38] <LaserJock> but *I* want to close it
[22:38] <LaserJock> having it disappear before I get a chance to look at everything just makes my life harder
[22:39] <greg-g> LaserJock: the new self-appointed bug closer for the majority of bugs in LP.  Get to work!   ;)
[22:39] <LaserJock> qcad is pretty buggy, period. I want to talk to upstream so I want to gather together all our qcad bugs, look at what's common, etc.
[22:40] <calc> LaserJock: are the appointed maintainer of qcad? otherwise anyone in core should be able to close (i would think) but you make sorta a good point in that i think as well that only people who have upload rights or maybe more restrictive than that should be able to close bugs as invalid or wontfix
[22:40] <calc> LaserJock: i meant to ask 'are you'
[22:40] <LaserJock> calc: there are no appointed maintainers
[22:40] <LaserJock> for almost all the packages I'm talking about
[22:40] <calc> LaserJock: so why did you think only you should be able to close the bug instead of pedro?
[22:40]  * calc must be confused about something
[22:41] <LaserJock> calc: no, that's a good question
[22:41] <Hobbsee> i don't think it's a case of "only i should close these bugs"
[22:41] <LaserJock> it's sort of a sticky point of Ubuntu maintainership style
[22:41] <Hobbsee> it's more of a "only people who are clued up and DTRT should close these bugs"
[22:41] <LaserJock> Hobbsee: basically
[22:42] <LaserJock> I'm not saying I have to do it because I'm the only one that should deal with qcad
[22:42] <LaserJock> but I want people who are gonna put some effort into it dealing with the bugs
[22:43] <LaserJock> maintaining packages is difficult, and it's made more difficult when people who may not know the whole story are closing bugs
[22:43] <greg-g> so a general raising of consciousness?
[22:44] <LaserJock> I'd rather not have to send an email to ubuntu-bugsquad every time I want to do something
[22:44] <LaserJock> i.e. get an overview of qcad bugs
[22:44] <greg-g> however that would be done (limiting "invalid" to bugcontrol, something else)
[22:44] <LaserJock> hmm
[22:44] <LaserJock> I don't think so much that
[22:44] <LaserJock> as I don't think a person can really know enough about everything
[22:45] <LaserJock> but more of a "don't touch it unless you're willing to "own" it"
[22:45] <greg-g> right
[22:45] <greg-g> hmmmm
[22:45] <LaserJock> I don't like people closing bugs who are obviously just running through a list closing things as fast as they can
[22:46] <greg-g> kinda goes against the idea of "anyone can help with triaging LP bugs, no memberships required"  not saying that is bad, just thinking out loud.
[22:46] <LaserJock> they're not taking the time to look at the bug, see if they can reproduce it, see if there are other similar bugs
[22:46] <LaserJock> yes, I think it sort of does that
[22:46] <LaserJock> I'd much rather see team triage groups than an Ubuntu-wide triaging team
[22:47] <maco> greg-g: every now and then i'm like "i dont care if you know nothing about how it works. you speak $language_i_don't_speak, so *please* translate it to English"
[22:48] <greg-g> LaserJock: like the desktop bugs team? so then a new "science bugs team" or something?
[22:48] <LaserJock> greg-g: well, you're gonna get me burnt at the stake
[22:48] <greg-g> :)
[22:48] <LaserJock> I think bugsquad should disappear basically
[22:48] <LaserJock> and that triaging should be incorporated into the relevant development teams
[22:48] <maco> hehe had LjL translating an italian bug reporter real-time in here yesterday :P
[22:48]  * greg-g lights LaserJock on fire
[22:49] <LaserJock> so similar to if a person wants to package, the "attach" on to a development team as a triager
[22:49] <LaserJock> *they
[22:49] <calc> LaserJock: have a team per cell i guess?
[22:49] <greg-g> LaserJock: that could be an interesting way of doing things: you get involved with a package or set of packages, not Ubuntu as a whole.
[22:49]  * calc doesn't know if 'cell' concept is well known yet
[22:50] <greg-g> oh yeah, the cell idea... I need to read up on those notes
[22:50] <LaserJock> calc: is that the reorganized archive?
[22:50] <calc> LaserJock: yes
[22:50] <LaserJock> then yeah
[22:50] <calc> and each subsection is its on cell more fine-grained than main/universe currently is
[22:50] <calc> maybe not a lot more fine-grained as its not done yet
[22:50] <LaserJock> I think having people join up to a cell as a triager would be better than the current "mile wide, inch deep" approach
[22:51]  * greg-g nods
[22:51] <LaserJock> there does need to be some generalists
[22:51] <Hobbsee> snowflakes!
[22:52] <LaserJock> we need a QA team that can support development teams in making good triaging practices/polices and makes sure things don't fall through cracks for non-seeded packages
[22:53] <LaserJock> but those would probably be people who have had pretty extensive experience within a triage team
[23:01] <crimsun> triaging doesn't _gain_ you info, jordan. that's a misperception.
[23:02] <crimsun> triaging makes it possible for people to get to the important bugs more quickly; it doesn't realise a net gain or anything.
[23:02] <greg-g> LaserJock: just so you know, I like this idea, and it should be revisited when the cells are implemented, I think.
[23:02] <crimsun> for that purpose, triagers need to prioritise, so quite a bit of info will be lost.
[23:02] <LaserJock> crimsun: well, it quite often will gain you info, but it sure should lose info that you want
[23:02] <crimsun> shouldn't*?
[23:02] <maco> was about to ask that
[23:02] <LaserJock> yes
[23:03] <LaserJock> i.e. triaging should get you missing info
[23:03] <LaserJock> and not lose the info you want to keep
[23:03] <crimsun> then you've moved beyond triaging
[23:03] <maco> to diagnosis?
[23:03] <crimsun> triaging is a first step; it's not the entire process.
[23:03] <crimsun> i.e., you wouldn't call surgery triaging
[23:04] <LaserJock> they I say get rid of triaging then, it's mostly useless to the developer
[23:04] <greg-g> I would call surgery devel/coding, but finding where/what the issue is would be triaging
[23:04] <LaserJock> not to sound insensitive, but I can "triage" better on my own thanks
[23:05] <LaserJock> when I have to re-"triage" it make my life more difficult
[23:05] <bdmurray> when you get to it right? ;-)
[23:05] <LaserJock> bdmurray: *exactly*
[23:05] <LaserJock> I may be very slow, but I'll get there
[23:05] <crimsun> so have you actually approached the triager(s) in question?
[23:05] <LaserJock> crimsun: no, because as far as I know they're just doing what they're told
[23:06] <calc> triaging of a bug should get enough info to be able to reproduce the bug outside of the original submitters machine
[23:06] <LaserJock> I don't want to start a dev/triager flame war
[23:06] <crimsun> so stop assuming and ask.
[23:06] <calc> not solve the bug itself
[23:06] <LaserJock> crimsun: hence why I'm here
[23:06] <calc> solving the bug would be the surgeons job in the analogy
[23:06] <calc> ah i see greg-g already said that above
[23:06]  * greg-g nods at calc 
[23:06]  * calc had been away dealing with his son
[23:06]  * maco fears a flamewar coming on
[23:06] <crimsun> frankly i see nothing particularly insensitive about the way javier has done his "job"
[23:06] <LaserJock> I did assume that the bugs that got marked as Invalid were done correctly according to current SOP
[23:07] <LaserJock> so I'm wondering about what to do about that
[23:07] <crimsun> i'm sure there are better examples
[23:07] <LaserJock> crimsun: I'm sure there are, I just having waded through the ~150 Invalid bugs to find them
[23:07] <calc> maco: we're all civil (i think) no need for a flamewar ;-)
[23:08] <crimsun> i'm not particularly civil, and because i'm not a member, i'm not bound by any CoC.
[23:08] <maco> crimsun: you havent signed the CoC/
[23:08] <maco> ?
[23:08] <greg-g> LaserJock: my only question is, is this an edge case.  The case being: A bug that is reported by someone with some of the required information, someone asks a "piddly" question, then 60 days later it is closed due to no response. You are assuming that bug can become a "good bug report" without further input from the reporter while others are assuming it can't (or is much harder).
[23:08] <calc> crimsun: eh you're not even a member anymore?
[23:08] <LaserJock> from my perspective I don't see how "triaging" is helping me any, and in fact it's making it harder
[23:09] <LaserJock> greg-g: it's happening to me more often then not
[23:09] <crimsun> LaserJock: do you have a list of bugs that you'd like everyone to stay away from, including the rest of core-dev?
[23:09] <crimsun> s/bugs/source packages/
[23:09] <maco> calc: he never went through the "become a member" process...had it automatically when in motu, but he's not motu anymore
[23:09] <greg-g> LaserJock: ok. But you probably only watch a subset of packages and thus might have a slightly skewed view
[23:09] <calc> maco: ah ok
[23:09] <LaserJock> crimsun: I don't want core-dev to stay away particularly
[23:10] <calc> don't you sign the CoC to be a Ubuntero?
[23:10] <LaserJock> greg-g: almost certainly
[23:10] <maco> calc: yeah, LP says crimsun is an ubuntero
[23:10] <greg-g> LaserJock: which is why you asked, at first, if some packages could opt-out, which would makes sense in your case.
[23:10] <maco> crimsun: dude, you did sign the CoC
[23:10] <LaserJock> greg-g: I fully acknowledge my team is probably a corner-case
[23:10] <calc> of course crimsun is civil anyway so its not much of an issue
[23:10]  * calc hugs crimsun 
[23:10] <maco> haha
[23:11] <crimsun> maco: of course i signed it when i joined lp, which is when i was an ubuntu-dev member. it doesn't apply now.
[23:11] <maco> well the speed of the conversation at one point was enough to make it seem like it was becoming heated
[23:11] <LaserJock> if triagers are just flipping bits but not doing much harm I'm ok
[23:11] <maco> crimsun: er...pretty sure you dont unsign the CoC
[23:11] <crimsun> maco: revocation.
[23:11] <LaserJock> but I'm just getting more and more bug closings which then means they drop off my package report
[23:11] <crimsun> LaserJock: of course that's the intent, but flipping bits is precisely the issue here, no?
[23:12] <maco> crimsun: i think he just wants to avoid flips to invalid
[23:12] <LaserJock> crimsun: flipping certain bits is more of a problem than others
[23:12] <maco> or won'tfix
[23:12] <LaserJock> if people are setting Importance, fine, it's useless but it's not getting in the way
[23:12] <LaserJock> if bugs drop off of +packagereport then I've got a problem
[23:12] <crimsun> i'd argue that missetting importance is a big deal
[23:13] <maco> crimsun: idk...i choose which bugs to try to fix based on my skills, not on the importance setting
[23:13] <greg-g> either way, lets not compound the issue
[23:13] <crimsun> i use all the fields when i deal with audio bugs, so if the priority bits are misset, then i have to reset them
[23:13] <LaserJock> crimsun: that's sort of my point
[23:13] <LaserJock> for me Importance isn't ... important
[23:14] <LaserJock> but for you it is, so obviously it's hard to work from a common set up triage policies
[23:14] <crimsun> LaserJock: right, so what could be proposed is that the general bugcontrol team not touch any bugs affecting x, y, z source packages
[23:14] <LaserJock> s/up/of/
[23:15] <LaserJock> well, that's not a great solution, but perhaps possible
[23:15] <maco> i guess for people with the skills to fix most anything they come across, Importance is a determining factor. for noobie coders its not :P
[23:15] <crimsun> it doesn't have much to do with coding ability, maco
[23:15] <crimsun> it's the ability to prioritise bug reports
[23:16] <LaserJock> right
[23:16] <LaserJock> it depends a lot on how many bugs you're getting, etc.
[23:16] <crimsun> LaserJock: what's a better resolution? growing the -science or edubuntu bug triaging teams?
[23:16] <maco> crimsun: i mean, when someone's going to *fix* something. if they know that source package well and are a good programmer, the importance can probably determine what they work on. if your skills are limited, you just fix whatever you can, regardless of importance setting
[23:16] <LaserJock> most of the packages I deal with have < 10 bugs so it's not a big deal
[23:17] <LaserJock> crimsun: well, I was thinking trying to get triagers to pay attention a bit more would help
[23:17] <LaserJock> or having a policy of trying to reproduce before closing
[23:18] <crimsun> certainly, that goes without saying.
[23:18] <crimsun> of course, if the bug summary is "qcad is broken" with nothing else, ...
[23:19] <LaserJock> right, that's why I said that bug was borderline
[23:19] <LaserJock> I can understand somebody closing that
[23:19] <LaserJock> but quite a few have had at least enough info to attempt to reproduce
[23:19] <LaserJock> and nobody has
[23:19] <LaserJock> and a developer hasn't made any comment
[23:19] <LaserJock> etc.
[23:20] <LaserJock> it's just a couple of form responses and it's closed
[23:20] <LaserJock> and then I get harrased about how Ubuntu sucks at taking care of bugs
[23:20] <crimsun> so perhaps a _better_ framework is appropriate, like providing a utility to automate installing the affected binary package(s) in a chroot/vm
[23:21] <LaserJock> that would probably be handy
[23:21] <crimsun> (not everyone will have sbuild or pbuilder installed, but i don't see why the general bugcontrol team can't move toward that)
[23:22] <maco> crimsun: and even if they have pbuilder, they might not know how to use it ;)
[23:22] <maco> you're going to tease me about not knowing "pbuilder build" anyway, so i might as well say it
[23:22] <LaserJock> I just don't like losing info for essentially no gain
[23:23] <LaserJock> it doesn't hurt to have the bugs open until a dev closes them
[23:23] <maco> so maybe bug control doesnt close bugs in any method other than duplicate?
[23:23] <crimsun> it also doesn't hurt to close the bug if it's not in a supported ubuntu release
[23:23] <LaserJock> crimsun: sure it does
[23:24] <bdmurray> It does if you have a package with hundreds of bugs and it is hard to find useful ones
[23:24] <maco> crimsun: it might still exist
[23:24] <LaserJock> we don't know if that bug *does* affect a supported relese
[23:24] <LaserJock> bdmurray: right, but I don't have any of those
[23:24] <crimsun> maco: it might. it won't matter in warty, hoary, or edgy.
[23:24] <LaserJock> bdmurray: I fully agree that it's important for Firefox, linux, Xorg, OOo, etc.
[23:25] <crimsun> or feisty
[23:25] <LaserJock> a lot of my packages don't change that often
[23:25] <crimsun> . if it's reproducible in gutsy, hardy, intrepid, jaunty, then obviously we care.
[23:25] <LaserJock> so the same exact version can be in multiple releases
[23:25] <LaserJock> but unless somebody *tries* to reproduce we learn nothing
[23:26] <crimsun> and yet that version can be a red herring, because sometimes it's something like wxwidgets that's the real culprit.
[23:26] <maco> if it's reported in Feisty, it might still exist
[23:26] <LaserJock> crimsun: yep, very true
[23:26] <LaserJock> so investiation is needed
[23:26] <crimsun> maco: yes, it _might_. move past that. i've already stated that it needs to be reproducible.
[23:26] <LaserJock> but investigation *won't* happen if people keep closing the bugs
[23:27] <crimsun> so we need to set down when to mark bugs as invalid
[23:27] <crimsun> (not that many of us don't already have a decent grasp, but for sake of discussion)
[23:28] <LaserJock> I'd like to, but I'm uncertain if we can come up with a archive-wide policy on that :(
[23:28] <crimsun> sure we can
[23:28] <crimsun> obviously different cells will have their own policies
[23:29] <LaserJock> that supersede the archive-wide policy?
[23:29] <maco> yeah
[23:29] <crimsun> the onus has always been on the triager to check for conflicting policies
[23:29] <maco> crimsun: do we trust all of us?
[23:30] <crimsun> not to mention that policies specific to source packages (logically extensible to cells) override archive-wide by their very definitions..
[23:30] <crimsun> e.g., ubiquity, alsa-driver, udev, linux
[23:31] <LaserJock> crimsun: right, but there seems to be some resistance to making it more difficult on triagers
[23:31] <maco> hey wait i have a triage question real quick
[23:31] <Hobbsee> there will be no questions!  :P
[23:31] <LaserJock> and I'd think "check to see which cell this package is in and read up on their policies" would be making it more difficult
[23:31] <crimsun> triaging is not supposed to be difficult; it's supposed to require due-digilence.
[23:31] <maco> if a bug *could* be in linux or *could* be in acpi, should i just mark it as affecting both and let the people that know those packages deal with squabbling over whose bug it is?
[23:31] <Hobbsee> maco: that's the usual idea
[23:32] <LaserJock> crimsun: well, I agree to that
[23:32] <maco> Hobbsee: ok then. the commenters on the bug can stop squabbling over it in that case :P
[23:32] <crimsun> maco: err, definitely don't. you'll earn the wrath of both tim, ben, and myself.
[23:32] <crimsun> and if you happen to do that with a gnome package, you'll earn the wrath of seb, too.
[23:33] <LaserJock> personally I feel like marking Invalid should be after: 1) clearly not a bug 2) reporter can't reproduce 3) at least one other person can't reproduce
[23:33] <crimsun> maco: i.e., until lp gains the ability to remove a task (RSN, i hear), just change the affected source package
[23:34] <crimsun> LaserJock: then the burden shifts to (1), which is not always obvious
[23:34] <LaserJock> crimsun: no, but I don't find as many problems there
[23:34] <crimsun> i.e., intractible for certain source package combinations(cells)
[23:34] <crimsun> intractable*
[23:35] <LaserJock> crimsun: it's primarily 3 that I have issue with
[23:35] <crimsun> maco: the reasoning is that even when marked invalid, multiple tasks still spam inboxes.
[23:35] <LaserJock> crimsun: I think "clearly" is a bit ambiguous but certainly not-a-bug is one of the uses for Invalid
[23:36] <crimsun> again, not so much an issue when tasks can be removed
[23:36] <maco> ok then...
[23:36] <crimsun> LaserJock: yes, agreed
[23:37] <LaserJock> maco: the problem is when the one task is marked "invalid" as it's not the right package, the team is still sub'd to the bug and so gets all the bugmail from it
[23:37] <LaserJock> not fun
[23:37] <maco> so if a mem= *and* an acpi= kernel parameter both get rid of the bug's symptoms, each with their own quirky side-effects...is that an acpi bug or a kernel bug?
[23:39] <crimsun> the latter.
[23:40] <crimsun> it's almost _never_ an acpi bug
[23:40] <crimsun> (at least in the age of jaunty)
[23:40] <maco> its in intrepid
[23:40] <crimsun> maco: same as for jaunty
[23:40] <maco> ok
[23:41] <crimsun> bdmurray: i think LaserJock's proposal regarding extending the requirements to mark a bug as invalid are sensible. can the docs be amended, or does the point warrant further discussion?
[23:43] <bdmurray> crimsun: looking at the scrollback - are your referring to the 1) 2) 3) comment?
[23:44] <crimsun> bdmurray: well, all
[23:46] <bdmurray> crimsun: I guess I'm not clear which requirements we are talking about then
[23:47] <maco> -_- any of you using irssi on intrepid?
[23:47] <crimsun> bdmurray: requiring that at least two people confirm that they cannot reproduce the symptoms in the current development version (https://wiki.ubuntu.com/Bugs/HowToTriage#Invalidating)
[23:47] <maco> did /away break?
[23:48] <nhandler> maco: I am using it on jaunty
[23:48] <LaserJock> crimsun: that's for Invalid?
[23:48] <maco> nhandler: does /away work?
[23:48] <LaserJock> crimsun: that seems a bit more like a "Fix Released"
[23:48] <crimsun> maco: check your scrollback position
[23:48] <nhandler> maco: Yep, I just tested it
[23:48] <maco> crimsun: what?
[23:49] <LaserJock> because of the "development version"
[23:49] <maco> i can't /away since installing intrepid :(
[23:49] <maco> crimsun: what does /away have to do with scrolling?
[23:49] <nhandler> maco: You need to specify an away message
[23:49] <maco> doh
[23:49] <nhandler> /away by itself returns you from being away
[23:49] <maco> i could've sworn an empty string was allowed
[23:50] <nhandler> maco: xchat allows it iirc
[23:50] <nhandler> But irssi does not
[23:50] <crimsun> it's not allowed through that client
[23:50] <maco> ok then
[23:50] <crimsun> LaserJock: ok, s/development/reported/
[23:50] <LaserJock> crimsun: I'd maybe go for "currently supported version"
[23:51] <LaserJock> if you can reproduce it in edgy I really don't care at this point :-)
[23:51] <crimsun> ok, so we'd shift the work to sru folks. sounds great to me ;)
[23:52] <LaserJock> well, I need to know about stuff I need to SRU
[23:53] <LaserJock> just because something is fixed in Jaunty doesn't mean my work is done unfortunately
[23:54] <crimsun> i'm fine w/ "currently supported versions or current development version"
[23:54] <LaserJock> me too
[23:54] <crimsun> or whatever their actual lp terminology is
[23:54] <seaq> hmm but that would mean that for triaging bugs you always would need someone else to try reproduce the bug...
[23:55] <bdmurray> seaq: Only to move a bug from Incomplete to Invalid
[23:56] <LaserJock> seaq: generally you want at least 2 people to see the same issue in order to confirm it's a bug
[23:59] <seaq> ok, so in order to move a bug to invalid we would need to check that the bug is not reproducible in the supported versions. By at least 2 people...