[00:08] <bdmurray> no package bugs are almost under 3100
[00:12] <chrisccoulson> talking of no package bugs, i'm just looking at this one - https://bugs.launchpad.net/ubuntu/+bug/252699
[00:13] <chrisccoulson> not entirely sure what to do with it. we know that some applications have yet to be ported to GIO, and the reporter seems unaware that he can still access Samba shares through the gvfs-fuse mount
[00:14] <chrisccoulson> i don't know whether there are bug reports tracking individual applications waiting to be ported that i could point him too, or whether to just close this one
[00:14] <bdmurray> given the quantity of bugs in the report it almost sounds like it should be an idea "Rock solid support of samba"
[00:15] <chrisccoulson> should i recommend he opens up an idea on ubuntubrainstorm?
[00:16] <bdmurray> Yeah, unless there is one specifc bug that report could be used for
[00:18] <chrisccoulson> the first four comments are really a non-issue (or certainly will be when the rest of the applications are ported to gio). perhaps the only issue might a discoverability one, where the reporter hasn't worked out that they can access samba shares in non-gio applications
[03:13] <mrooney> Gnome 2.24 is the targeted Intrepid version, correct? Meaning Nautilus 2.24 will be the Intrepid version?
[03:19] <mrooney> and question 2, unrelated, which package would you file a bug report against for the "About Ubuntu" dialog?
[03:25] <LaserJock> mrooney: what kind of problem with About Ubuntu?
[03:30] <mrooney> LaserJock: okay, it is the same question in qa, so I will go for it here. I was just wonder about bug 252621
[03:30] <mrooney> I don't know enough to know if what he describes is a bug, or if he should just be making his theme differently
[03:33] <mrooney> and also what package that would be
[03:33] <LaserJock> well
[03:33] <LaserJock> gnome-panel is the package
[03:34] <LaserJock> but it's really tricky
[03:34] <LaserJock> a lot of the About Ubuntu stuff is hard-coded
[03:35] <mrooney> I think his issue isn't that though, because the icon does change if a theme specifies a different one
[03:35] <LaserJock> it should change if the distributor logo changes
[03:35] <mrooney> it just uses the wrong one if you use a theme which doesn't explicitly specify one, apparently
[03:38] <LaserJock> well, I'm not sure if it's a bug or not
[03:48] <mrooney> I know, that is where I am at too :)
[03:52] <mrooney> Anyone know what package the gnome logout dialog is?
[03:53] <mrooney> apt-cache search'ing doesn't provide anything useful
[03:59] <LaserJock> mrooney: possibly gdm?
[04:31] <RAOF> Gnome session?
[07:48] <m0u5e> can someone take a look at https://bugs.launchpad.net/ubuntu/+bug/252817 and offer feedback? I'm not sure what I should do with this
[07:48] <AlmightyCthulhu> I'd like to update on bug 251338
[07:49] <AlmightyCthulhu> Foxconn has been in conference with me several times today
[07:49] <AlmightyCthulhu> the problem is not just Foxconn boards, it's spread to ASUS and MSI as well
[07:49] <AlmightyCthulhu> only if you have an American Megatrends BIOS
[07:50] <AlmightyCthulhu> how should I update this bug with that information?
[07:51] <RAOF> By pressing the "edit description" link.
[07:58] <AlmightyCthulhu> bug 251338
[10:05] <AlmightyCthulhu> bug 252861
[10:05] <AlmightyCthulhu> security, sweeeeet
[10:09] <wgrant> AlmightyCthulhu: Going to inform us of its content?
[10:09] <wgrant> Or just noticing that it is private?
[10:09] <AlmightyCthulhu> probably would phrase it as
[10:10] <AlmightyCthulhu> "npviewer.bin crashed with SIGSEGV right before my pr0n loaded"
[10:10] <AlmightyCthulhu> but then it wouldn't get the attention it deserves
[10:11] <wgrant> Odd - I should be able to see crash bugs, but can't see this one.
[10:11] <AlmightyCthulhu> I reported with apport
[10:11] <AlmightyCthulhu> I just noticed a 10 MB crash file
[10:11] <AlmightyCthulhu> and figured go for it
[10:11] <wgrant> Ah, I guess it might only end up accessible once it is attacked by a retracer.
[10:12] <james_w> yup, the retracer has to look first, and opens it up whether it suceeds or fails I believe.
[10:12] <wgrant> It doesn't normally open it up itself, does it?
[10:12] <wgrant> Rather subscribed the appropriate team.
[10:12] <wgrant> *subscribes
[10:13] <AlmightyCthulhu> looks that way
[10:13] <AlmightyCthulhu> actually, I was testing a rick roll
[10:13] <AlmightyCthulhu> I have my blog set to link every Ubuntu Code of Conduct link that someone spams it with
[10:13] <AlmightyCthulhu> to Together Forever
[10:13] <AlmightyCthulhu> or Never Gonna Give You Up
[10:14] <wgrant> That's slightly nasty.
[10:14] <james_w> wgrant: yeah, of course, sorry.
[10:14] <AlmightyCthulhu> wgrant: I'm sick of seeing them
[10:14] <AlmightyCthulhu> my link policy is if I no likey, I turn it into a rick roll
[10:14] <wgrant> The CoC is important.
[10:15] <AlmightyCthulhu> then you really don't want to see my blog, lmao
[10:16] <AlmightyCthulhu> there's nothing technically wrong with Ubuntu
[10:16] <AlmightyCthulhu> that thing suffers from rectal cranial inversion IMHO
[10:17] <AlmightyCthulhu> then Evolution crashed when I opened my hatemail about the rickroll
[10:17] <AlmightyCthulhu> so I posted a bug about that too
[10:20] <AlmightyCthulhu> I figured the rickroll is the perfect way to deal with the CoC links, it's overengineered, overused, over the top, corny, and lip synched
[10:20] <AlmightyCthulhu> but Flash no wanna worky :P
[10:22] <pwnguin> really, the CoC is fundamental. it can be over applied and overanalyzed
[10:23] <pwnguin> but its still important ground rules for participation in a community project like this
[10:24] <AlmightyCthulhu> I prefer the one rule approach
[10:24] <AlmightyCthulhu> "Don't be a (you know)"
[10:24] <pwnguin> well
[10:24] <AlmightyCthulhu> Rule 2: "Unless it's warranted"
[10:25] <AlmightyCthulhu> it's how you know a project has no soul
[10:26] <pwnguin> you have no idea
[10:26] <AlmightyCthulhu> Mozilla even uses the bug system when the price of soda goes up 5 cents in the machine upstairs
[10:26] <AlmightyCthulhu> they have a sense of humor
[10:26] <pwnguin> Debian is a rather abrasive community
[10:27] <pwnguin> the CoC I think largely stems from trying to produce an alternative, workable community
[10:28] <AlmightyCthulhu> sometimes banging your fist is the only way to get things done
[10:28] <pwnguin> things like assuming bad faith, telling new debian users to RTFM and then justifying the abuse because you spend a long day at work
[10:28] <AlmightyCthulhu> it should only be used when all else fails
[10:28] <pwnguin> so how long have you been using Ubuntu?
[10:29] <AlmightyCthulhu> since Warty
[10:29] <AlmightyCthulhu> before that it was Red Hat
[10:29] <pwnguin> neat
[10:29] <AlmightyCthulhu> and way before that, Slackware
[10:29] <AlmightyCthulhu> I still keep Fedora on most of my boxes
[10:30] <AlmightyCthulhu> so, I just find that wehen someone hands me the CoC
[10:30] <AlmightyCthulhu> it can be just as offensive as RTFM
[10:30] <wgrant> The CoC makes Ubuntu a lot more bearable than Debian.
[10:30] <pwnguin> well
[10:30] <AlmightyCthulhu> if not worse
[10:30] <pwnguin> telling everyone to call the FTC is so ridiculusly overboard
[10:30] <pwnguin> and assumes bad faith
[10:30] <AlmightyCthulhu> of course it does
[10:31] <AlmightyCthulhu> someone did this on purpose
[10:31] <AlmightyCthulhu> is using undocumented methods and a special version of DSDT and several other tables
[10:31] <pwnguin> never attribute to malice blah blah
[10:31] <AlmightyCthulhu> and going out of their way to detect Linux
[10:31] <AlmightyCthulhu> yeah, you would have to intentionally do this
[10:31] <AlmightyCthulhu> just putting _OS in there ain't gonna do it
[10:32] <AlmightyCthulhu> they've found a way to make Linux listen to that
[10:32] <pwnguin> look, if you're wrong, we all look like fools
[10:32] <pwnguin> and
[10:32] <AlmightyCthulhu> even though all reference material says Linux doesn't do that
[10:32] <AlmightyCthulhu> so according to documentation, Matthew Garrett is right
[10:32] <AlmightyCthulhu> according to what is going on, I am
[10:33] <AlmightyCthulhu> if he was here and dealing with this, he would be throwing a fit
[10:33] <AlmightyCthulhu> guarantee it
[10:33] <pwnguin> na
[10:33] <pwnguin> even if you're right, everyone now has one more reason to think twice before giving out engineering support contact information to the linux community
[10:34] <AlmightyCthulhu> look, hitting them on a Friday, very publicly was the only way to do this
[10:34] <AlmightyCthulhu> otherwise they would have just outright denied it
[10:34] <AlmightyCthulhu> and continued their line
[10:35] <AlmightyCthulhu> you may not like what I did, but I had to hit them while they were off balance
[10:35] <AlmightyCthulhu> or they never would have admitted fault
[10:35] <pwnguin> alternatively
[10:35] <AlmightyCthulhu> and there would still be 10-20 million bad boards out there
[10:35] <AlmightyCthulhu> with no resolution coming
[10:35] <AlmightyCthulhu> and more shipping
[10:36] <pwnguin> they're not at fault, and they bent over backwards to fix a percieved customer service problem
[10:36] <pwnguin> its not clear yet where the problem is, and that they're now calling AMI is a bad sign
[10:36] <AlmightyCthulhu> why is that?
[10:36] <AlmightyCthulhu> get the darned thing fixed
[10:36] <AlmightyCthulhu> fixed like the US Election
[10:37] <AlmightyCthulhu> B-)
[10:37] <AlmightyCthulhu> so Foxconn is negligent, AMI are the (poop)heads, and Microsoft told them their stuff looked good
[10:37] <pwnguin> i just dont know what to say. its abrasive and a long term stupid decision to treat them like enemies
[10:38] <AlmightyCthulhu> well, they lied and sold me and 20 million other people defective hardware
[10:38] <AlmightyCthulhu> and then tried to say fix the problem buy buying Windows Vista
[10:38] <AlmightyCthulhu> *by
[10:39] <pwnguin> so then document the defect so convincingly that they can't deny it
[10:39] <AlmightyCthulhu> they aren't denying it
[10:39] <AlmightyCthulhu> they have confirmed it
[10:39] <AlmightyCthulhu> and are blaming AMI
[10:39] <AlmightyCthulhu> and on MORE models than I accused them of
[10:40] <pwnguin> another plausible interpretation is that they're calling AMI because their engineers cant find anything wrong with it
[10:40] <pwnguin> it seems possible that there's a flaw in the kernel that gets exercised by their goofy extra tables
[10:42] <AlmightyCthulhu> pwnguin: not what is happening
[10:42] <AlmightyCthulhu> Brunning already told me
[10:42] <AlmightyCthulhu> definitely the BIOS
[10:42] <AlmightyCthulhu> they just can't do anything with it cause it's AMI's code
[10:43] <AlmightyCthulhu> and this is out of their agreement
[10:43] <AlmightyCthulhu> they said they will get it fixed though
[10:43] <AlmightyCthulhu> I don't think they'll have any trouble leaning on AMI
[10:44] <pwnguin> anyways, i need some sleep
[10:45] <AlmightyCthulhu> see, lack of huevos is what is pinning Linux down
[10:47] <pwnguin> stastically you are wrong
[10:47] <pwnguin> linux won't exceed 51 percent without women getting involved
[10:49] <pwnguin> and if it ever comes close, expect behavior like yours to merit tortous interference claims
[10:53] <AlmightyCthulhu> meh
[10:53] <AlmightyCthulhu> Cthulhu does like incomprehensible evil and horror
[10:58] <gnomefreak> has anyone ran into a bug about shutdown on intrepid yet?
[10:58] <gnomefreak> gnome DE
[11:34] <james_w> could someone on intrepid please run "ls /var/spool/cron/atjobs -d -l" and tell me what it outputs please?
[11:35] <afflux> james_w:  drwxrwx--T 2 daemon daemon 4096 2008-05-03 15:26 /var/spool/cron/atjobs
[11:36] <james_w> thanks, is that a clean install?
[11:38] <afflux> james_w: umm, what exactly do you mean?
[11:38] <afflux> james_w: ah, It's upgraded since hardy I think
[11:38] <james_w> ok, thanks
[11:40] <AlmightyCthulhu> Intrepid shutdown or reboot sends you to the login screen
[11:40] <AlmightyCthulhu> shutdown -r gives you a screen asking you to restart X
[11:40] <AlmightyCthulhu> which takes you to the login screen
[11:40] <AlmightyCthulhu> :P
[11:41] <afflux> AlmightyCthulhu: that's bug 250506
[12:03] <AlmightyCthulhu> bah, I bagged another Code of Conduct spam with Rick Astley
[12:03] <AlmightyCthulhu> that guy is awesome
[12:06] <james_w> AlmightyCthulhu: at the very least that is off-topic for this channel, please refrain from talking about Rick Astley here.
[12:07] <AlmightyCthulhu> I think Ubuntu should build that into it's typo correction system, can we get a time table?
[12:56] <AlmightyCthulhu> I found proof of my accusations
[12:56] <AlmightyCthulhu> it's in Chinese though
[12:56] <AlmightyCthulhu> I'm waiting on someone to translate the bits that are interesting to English
[12:56]  * Hobbsee wonders if that's really on topic for this channel
[12:57] <AlmightyCthulhu> it's about bugs
[12:57] <AlmightyCthulhu> they're using Henlan approach to ACPI, without actually implementing ACPI
[12:57] <AlmightyCthulhu> and bending over for Microsoft
[12:57] <AlmightyCthulhu> is the gist of this
[12:57] <Hobbsee> then surely you should be talking to them?
[12:58] <AlmightyCthulhu> I don't speak Chinese, I will link it later when I have some bullet points
[12:58] <Pici> Is this in any way related to Ubuntu?
[12:58] <AlmightyCthulhu> yes, very much
[12:58] <AlmightyCthulhu> tens of millions of motherboards that won't work right
[12:58] <AlmightyCthulhu> due to this
[12:59] <AlmightyCthulhu> but only if you use Linux on them
[12:59] <Hobbsee> then you would do better to contact the manufacturer, to fix their stuff.
[12:59] <AlmightyCthulhu> I have and they are, but what this guy says is they're falsely blaming a programmer
[12:59] <Hobbsee> it appears you already have forum threads about this, where you can put your discussions
[12:59] <AlmightyCthulhu> so that upper management doesn't catch flak for this
[13:00] <AlmightyCthulhu> typical
[13:01] <AlmightyCthulhu> I guess no matter where you are, some things don't change
[13:02] <mrooney> anyone know if bug 252795 is a dup?
[13:02] <jpds> bug #252795
[13:02]  * jpds prods ubottu 
[13:03] <Hobbsee> AlmightyCthulhu: this channel is for dealing with bugs, and triaging them only.  it's not a soap box, nor is it a place to recruit for an uprising against various manufacturers.
[13:03] <Hobbsee> mrooney: yeah, it is, the other was mentioned earlier
[13:03] <Hobbsee> https://launchpad.net/bugs/250506
[13:07] <mrooney> Hobbsee: it doesn't SOUND the same
[13:07] <Hobbsee> mrooney: bah.  i misread, sorry
[13:08] <mrooney> I notice in his screen shot it says live session user, does that mean a livecd?
[13:08] <Hobbsee> yes
[13:08] <Hobbsee> well, unless he's deliberately named himself Live Session User in the installer, of course.
[13:11] <afflux> mrooney: commented on the bugreport
[13:11] <Hew> Hey, I have a question on milestones. https://wiki.ubuntu.com/RCBugTargetting doesn't really sound sensible/relevant. If I find a bug which I believe should be fixed by Intrepid release, can I set the ubuntu-8.10 milestone for it?
[13:11] <afflux> mrooney: I've the same issue
[13:14] <mrooney> afflux: thanks!
[13:15] <mrooney> afflux: does it just happen sometimes, or always?
[13:15] <afflux> always
[13:16] <afflux> mrooney: are you on intrepid?
[13:16] <mrooney> nope, Hardy
[13:16] <mrooney> I wonder if there are any bugsquaders/bugcontrollers that don't actually use Ubuntu as their OS
[13:17] <afflux> mrooney: ah I see. Let me explain: the logout dialog has been completely replaced. The usual "logout" button in the top right corner (or was it at the bottom?) now leads to the logout dialog, as you can see in the screenshot the reporter posted
[13:18] <afflux> mrooney: the shutdown dialog is currently located in the applications menu, and the reporter wants to note that pressing the shutdown button should open the shutdown dialog instead of the logout dialog
[13:18] <afflux> shutdown button in this case means the hardware button ;)
[13:19] <Hew> afflux: So the logout button in the top right is intentional?
[13:19] <james_w> hi Hew, why doesn't that page sound sensible?
[13:19] <afflux> Hew: not sure. I didn't make that change ;)
[13:19] <Hew> afflux: Ok then, it's just something I had noticed :-)
[13:20] <afflux> Hew: yes, maybe it gets changed to shutdown in case enough users complain about it. I for example could use shutdown more than logout since I'm on a single-user machine
[13:21] <afflux> Hew: you can change it manually by just adding the shutdown applet
[13:22] <Hew> james_w: I would have thought milestones and release targeting were two separate things, but rather than setting a simple milestone for a task (which is apparently ignored), the guideline says I need to target it for Intrepid first, and then milestone that.
[13:22] <Hew> afflux: yea, single-user here too, I'm in the same situation
[13:23] <james_w> the old logout/shutdown dialog was a patch, upstream has re-organised so that patch doesn't apply, so we are currently following upstream.
[13:23] <james_w> it will probably change before the release, but it's not known yet whether that will be a change upstream, updating the patch, or switching to another patch.
[13:24] <afflux> I'm fine with that, I'm just wondering whether the user will like it ;)
[13:24] <afflux> ah I see
[13:24] <james_w> hang on, I've messed up my session, got to restart it.
[13:33]  * mouz notices 5 bugs per day can be pretty much :)
[13:35] <mrooney> mouz: :)
[13:35] <persia> Depends on the bugs :)  Some bugs take all day just by themselves.  Some are easy enough that one can get 50 done in just a few hours.
[13:36]  * afflux sometimes collects some duplicate python crasher bugs
[13:36] <afflux> woohoo, 50 bugs by running a script :>
[13:37] <persia> afflux: Does the apport dup-checker not catch python dupes?
[13:38] <afflux> persia: usually, yes, but it fails for some packages like screenlets
[13:39] <persia> afflux: Ah.  Any idea why?
[13:40] <afflux> persia: where one issue in the daemon backend causes every plugin to produce millions of tracebacks. I'm not sure but it often seems like apport checks for the whole traceback, which usually differs slightly
[13:41] <persia> afflux: differs how?  Near the crash, or near the initialisation?
[13:41] <afflux> initialisation, because different modules are calling the same backend
[13:42] <afflux> (I'm not sure whether this is really the problem for apport here, but I couldn't think of something better ;))
[13:43] <persia> afflux: Hmm.  I'm not sure that's easily soluable other than by the means you use.  Unfortunate though.
[13:43] <afflux> persia: bug 197712 is a good example
[13:45] <afflux> err, well. maybe I'm mixing something up now. It does detect some of them, but IIRC most duplicates were set manually.
[13:46] <persia> afflux: Those don't look like clear duplicates to me (based solely on the traceback).  At least those I examined differ on the crashing line itself.
[13:47] <persia> Mind you, they may have a common solution, as it appears the issue is a typing conflict of some sort between the session creation and the screenlet defintions, but they don't have the same trace.
[13:47] <persia> In other cases, it may not be the same bug (although it likely often is).
[13:48] <afflux> persia: well, the few I looked at were failing with "OSError: [Errno 17] File exists: '/tmp/screenlets'", sometimes in differend localisations
[13:50] <persia> afflux: Which is usually due to insecure tmpfile creation, but
[13:50] <persia> without looking at the code it's hard to determine if the insecure tmpfile creation only happens in one place or many places.
[13:51] <persia> If it's always in the same place, then it makes sense to have them duplicate.  If it's in different places, it is likely different bugs.
[13:51] <persia> Easy for a human to review and see if it's the same call, but maybe hard to automate.
[13:51] <afflux> yes, could be.
[13:52] <persia> (and in this case I suspect they are, as you've previously shown care with tracebacks and some understanding of python)
[13:53] <afflux> they all start (not really, since it's called before from a module) in create_session() of /usr/lib/python2.5/site-packages/screenlets/session.py, I think that's enough evidence
[13:58] <persia> See, that's the part I'm less sure about, as the arguments are different.  On the other hand, they all end with line 288 of session.py, which uses unsafe tmpfile creation (which is often a security issue).
[13:59] <persia> That points to likely being the same crash.
[14:00] <persia> Because they start differently, it may be that the callbacks for each are different: without code examination, one can't know that TMP_DIR is created in session.py rather than generated by the individual Screenlet.
[14:01] <afflux> indeed, you got a point there.
[14:02] <persia> afflux: Note that in this case, it appears correct: it's just that the Traceback.txt alone isn't sufficient to confirm the duplicate unless you know the code.
[14:03] <afflux> I think, in this special case (with os.mkdir raising an exception with it's argument mentioned) it would be enough to scan the traceback from down to up and notice that a most part looks similiar and fails with the same message.
[14:04] <persia> As long as one knows that TMP_DIR is defined in session.py (or some other common location), and not by the screenlet.  The first time one does that, one should check the code.  The second time, one already knows it's a dup.
[14:04] <afflux> ah yes
[14:05] <afflux> If I remember correctly I recently saw some python code which catches exceptions and shows a more detailed traceback, with function arguments and some local variables. Might this help in such cases?
[14:07] <bddebian> Boo
[14:11] <persia> afflux: That would show the values of the variables, which may help with debugging the actual issue, but it won't show whether the definiton of the variable depends on the module being loaded, which one can only know from code inspection.
[14:11] <afflux> true, okay
[20:55] <chrisccoulson> could somebody take a look at this bug with no package and voice their opinion: https://bugs.launchpad.net/ubuntu/+bug/252535
[20:56] <bdmurray> That's a launchpad wish list request
[20:56] <chrisccoulson> thats what i was going to ask
[20:56] <chrisccoulson> thanks
[20:56] <bdmurray> Also I thought there was a wiki page for that too
[20:56] <bdmurray> with the standard information to include
[20:56] <nhandler> bdmurray: I think you are thinking of this: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[20:57] <bdmurray> more https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages/ExamplePackageRequest but yeah thanks
[20:58] <chrisccoulson> so this report is invalid really? unless the wiki page needs to be more discoverable. i've never filed a bug report of this type before, so i don't know
[20:58] <bdmurray> Well, it really could be a feature of Launchpad
[20:59] <LaserJock> bdmurray: I wonder how that could be done?
[20:59] <chrisccoulson> could i ask you to respond to this one then please? i can't set the wishlist status anyway
[21:00] <LaserJock> bdmurray: with "needs-packaging" being a tag we'd have to have per-tag filing instructions
[21:00] <bdmurray> LaserJock: I've no idea but grouping the needs-packaging bugs with the bugs w/o a package is less than ideal so maybe the solution could resolve both of those
[21:00] <LaserJock> bdmurray: well, when I created that system I was told that was the preferred method
[21:01] <bdmurray> LaserJock: Its the best current solution but could be better
[21:01] <LaserJock> originally we were going to try to do it like Debian with a project or fake package
[21:01] <LaserJock> but LP devs said tags were better
[21:01] <bdmurray> Right and if that happened and we had per filing bug instructions we'd be golden
[21:02] <LaserJock> yeah
[21:02] <LaserJock> but uh, we were told not to do that ;-)
[21:03] <LaserJock> maybe having per-package/project filing instruction there would be better motivation
[21:08] <bdmurray> How long ago was that?  There are per-project filing instructions so maybe a separate project would work.
[21:09] <LaserJock> well, that was before per-project filing instructions for sure
[21:10] <bdmurray> I think a new project might really be a good idea
[21:11] <bdmurray> There are currently ~1000 needs-packaging bugs that have to be sorted out of the rest of the bugs without a package
[21:12] <LaserJock> hmm
[21:13] <LaserJock> what we really need a junk projects
[21:13] <LaserJock> or packages, not sure which would map better in LP
[21:15] <LaserJock> alternatively though, I think the number of bugs without a package is a symptom of a problem with LP/bug filing
[21:15] <bdmurray> Its just that having them clumped in another area ends up being a lot of busy work for people
[21:15] <LaserJock> we really shouldn't have a lot of bugs without a package associated
[21:19] <LaserJock> bdmurray: am I right that there are 5k open bugs without a package?
[21:20] <bdmurray> LaserJock: perhaps, the ones w/o a package and new are about 3100 at the moment
[21:20] <LaserJock> k
[21:21] <LaserJock> so can you think of any reasons why a bug shouldn't have a package (other than needs-packaging)?
[21:21] <bdmurray> This isn't a new problem and isn't an easy one to solve.
[21:21] <bdmurray> Package names are not easily discoverable for reporters
[21:21] <LaserJock> I know the history
[21:28] <jcastro> i've been doing the bugs without a package as my 5-a-day
[21:28] <jcastro> I think a bunch are just kernel/hardware related and people don't know what to do
[21:30] <LaserJock> but a wrong package seems better than no package
[21:31] <LaserJock> so perhaps LP should help people find packages better rather than just dumping them in no-where land
[21:35] <jcastro> or not let them submit until they find one?
[21:36] <LaserJock> jcastro: well, that's what I was getting at ;-)
[21:37] <bdmurray> A fair number of bug reports end up in Firefox, wrongly, by virtue of it's liblaunchpad integration and the mozilla team doesn't necessarily know which package is the right package so I wound't say a wrong package is better than no package
[21:40] <chrisccoulson> a few reports also seem to wrongly end up with yelp
[21:51] <LaserJock> bdmurray: I do, the mozillateam is better able to figure out what package it should be
[21:51] <LaserJock> rather than having all these bugs with no package at all
[21:52] <greg-g> at least with the no package land it is an easy search query for BugHug days :)
[22:01] <sbeattie> bdmurray: does your no-package list filter out bugs that have the needs-packaging tag?
[22:02] <bdmurray> sbeattie: which list?
[22:02] <bdmurray> sbeattie: also there is not !tag filter in launchpad
[22:03] <LaserJock> bdmurray: there isn't or is a !tag filter
[22:03] <LaserJock> ?
[22:03] <bdmurray> there is no !tag
[22:03] <LaserJock> ok, I knew there was a long-standing bug about that, but thought maybe it'd finally gotten fixed
[22:04] <sbeattie> bdmurray: e.g. http://people.ubuntu.com/~brian/reports/no-package-clues.html does that include needs-packaging bugs?
[22:05] <bdmurray> sbeattie: nope
[22:06] <LaserJock> I can't think of anything but bug  1 and "needs-packaging" that shouldn't have a package associated
[22:07] <LaserJock> so if we were to use a project for the later and maybe special-case the former, we could require a package to be entered when filing
[22:09] <bdmurray> I think that's a poor solution though
[22:09] <LaserJock> why?
[22:09] <LaserJock> seems like a much better solution that currently to me
[22:11] <LaserJock> I don't really see how having thousands of bugs that just sitting there is helpful
[22:11] <bdmurray> As greg-g mentioned it is easy to find these now and as I mentioned sometimes people won't know where to put it when it is wrongly filed so what will happen with the bugs then?
[22:12] <LaserJock> bdmurray: well, if they're filed against a package somebody will know about them
[22:12] <bdmurray> But not necessarily the right somebody
[22:12] <LaserJock> so?
[22:13] <bdmurray> So they'll just be "sitting" somewhere else which is less discoverable
[22:13] <LaserJock> somebody who has a decent chance of knowing the right package vs. no package at all seems like a clear winner to me
[22:14] <LaserJock> well, presumably they'll be sitting "closer" to where they should go
[22:14] <LaserJock> if the user can't get reasonably close we're unlikely to want them filing the bug via LP
[22:15] <LaserJock> for instance, somebody filing a bug against anything "linux" for a kernel problem is better than nowhere
[22:16] <LaserJock> similar for anything FF related
[22:17] <greg-g> LaserJock: the only thing is there are many many packages which aren't looked at very often (the smaller ones) and having a bug assigned to that package intead of "no package" seems like a bad situation (ie: I won't go look at $random_small_nonused_package but I will look at "no package" bugs)
[22:17] <LaserJock> it just seems like not requiring a package is helping people do the wrong thing rather than the right thing (i.e. getting the package right/close)
[22:17] <greg-g> of course, that is a part of it
[22:17] <LaserJock> greg-g: well, then we need to address that
[22:18] <LaserJock> "bugs with no package assigned" should not in general be more well triaged than bugs in general
[22:18] <LaserJock> hmm, to many "in general" there ;-)
[22:18] <greg-g> if we make an effort to look at the nopackage/new bugs every month during a bughug day, then I think the no package category could be useful
[22:18] <greg-g> heh
[22:19] <LaserJock> but it *shouldn't* be useful is my point
[22:19] <LaserJock> those triagers should be doing other things
[22:19] <greg-g> hmmm
[22:19] <LaserJock> that's wasted effort to me
[22:19] <LaserJock> it's like having a status that nobody should ever use
[22:20] <greg-g> kinda, except, to be honest, there are some people who that is about the level of triaging ability they have.  Now... I don't want that to sound like I want to ensure they have something to do, but, just that they are available and willing.
[22:20] <greg-g> heh :)
[22:20] <LaserJock> why have it there, it's just a sink for things to go instead of where they should be going
[22:20] <greg-g> yeah, I see that and agree that it is a "sink"
[22:20] <bdmurray> Additionally, assigning bugs to package is can be an easy entry point for new triagers
[22:21] <LaserJock> I don't think that's a very useful argument
[22:21] <LaserJock> I can create all kinds of silly little things for people to do
[22:21] <LaserJock> but the fact remains if it's wasted effort it's wasted effort and I'd rather find other useful, but easy, things for them to do
[22:22] <greg-g> hmmmmmmmm
[22:22] <LaserJock> and on top of that if the user can't figure out what package a bug belongs to I'm not really certain that it's a great place for new triagers
[22:23] <LaserJock> as they are likely to get it wrong as well, and then you have doubly wasted effort
[22:23] <greg-g> I think those are great places actually.  New triagers are fine with asking the "basics" (logs, steps to reproduce) where the nopackage bugs usually lack
[22:24] <greg-g> s/where/which/
[22:24]  * greg-g is still on the fence on whether bugs have to be assigned to a package to be filed
[22:25] <LaserJock> minimally we need package and version of Ubuntu
[22:25] <pwnguin> at least with no package assigned we have a good place to look for these things
[22:25] <LaserJock> just to have any useful starting place
[22:26] <LaserJock> and Launchpad should be helping people with those in some way
[22:26] <LaserJock> and allowing people to just not give information is counter-productive
[22:27] <LaserJock> the fewer times we have to go back-n-forth with people the better
[22:28] <greg-g> it is the perennial debate over "many bugs with some(many) which are described poorly, with the advantage of possibly getting more actual bugs" vs "fewer bugs but better described with the possibility of missing some issues"
[22:28] <greg-g> low barrier vs higher barrier
[22:28] <LaserJock> higher barrier wins almost every time
[22:28] <pwnguin> i agree that launchpad could do a better job of package assignment assist
[22:28] <LaserJock> though it's basically a balance
[22:29] <pwnguin> improving LP moves the "sweet spot" towards more bugs
[22:30]  * greg-g has no answers strong opinions at this point
[22:31] <LaserJock> I'm pretty sure we're not starving for bugs ;-)
[22:31] <pwnguin> who all can assign package names besides the reporter?
[22:31] <LaserJock> anybody
[22:33] <pwnguin> heh
[22:33] <pwnguin> here's an idea
[22:33] <pwnguin> mturk
[22:34] <greg-g> hehe
[22:34] <pwnguin> pay 5 cents per bug in the no package assigned queue
[22:35] <LaserJock> or ... don't let people do that in the first place ;-)
[22:35] <pwnguin> yes
[22:35] <pwnguin> then we can start the "move bugs out of yelp" program
[22:37] <LaserJock> I just don't see the point of letting people do things that not only don't help them ("why isn't my bug being looked at?") but doesn't help us
[22:39] <pwnguin> because sometimes theres no way a computer can know
[22:39] <greg-g> I think LaserJock is wanting the user/reporter to know, or at least guess and get close
[22:40] <pwnguin> sometimes even I don't know
[22:40] <pwnguin> i have to go on irc to ask
[22:40] <pwnguin> pretending i can just figure it out is bunk
[22:40] <LaserJock> pwnguin: exactly!
[22:41] <sbeattie> LaserJock: forcing people to pick a package without assistance won't help much, as someone who received apparmor bugs from the opensuse bugzilla -- for a while, apparmor was first in the dropdown list, so if people didn't know, we'd often get selected merely to have something selected.
[22:41] <pwnguin> example: which package is the logout dialog?
[22:41] <LaserJock> sbeattie: I didn't say they should have to do it without assistance
[22:41] <chrisccoulson> gnome-session;)
[22:41] <LaserJock> what I want is to get the bugs closer to the right answer to start with
[22:41] <pwnguin> chrisccoulson: right, which you probably know because you asked someone else ;)
[22:42] <LaserJock> some of them won't be quite right, but at least people who should know more about what they're doing can direct the bug
[22:42] <bdmurray> apparmor doesn't sound closer to me
[22:42] <chrisccoulson> i knew because i had to triage a related bug once and i played around with my system until i figured it out;)
[22:42] <pwnguin> LaserJock: sure, but lets not pretend we need packages assigned 100 percent of the time or the reporter can just buzz off
[22:42] <LaserJock> I didn't say that
[22:42] <pwnguin> then what's this about fewer bugs?
[22:43] <LaserJock> I'm saying, if they can't even get close (with help) then I'm doubting the bug will be of much use
[22:43] <LaserJock> we should help people get close
[22:43] <LaserJock> then reassign if they still didn't get it right
[22:44] <LaserJock> so we should have per-package filing help
[22:44] <LaserJock> so for packages that get commonly confused we can offer specific help
[22:44] <LaserJock> and we should most definitely *not* have a drop-down list of packages
[22:45] <pwnguin> one of the things I do is subscribe to a few packages bugmail
[22:45] <greg-g> per-package filing help is good, but getting to that help is hard
[22:45] <LaserJock> greg-g: why?
[22:45] <LaserJock> I'm sure developers would love to help write per-package filing help
[22:45] <greg-g> drop_down_list_a_la_bugzilla--
[22:45] <LaserJock> less work fo rthem
[22:45] <pwnguin> i think that term should be explained
[22:45] <pwnguin> "per package filing help"
[22:45] <greg-g> getting TO the help for the package if you don't know what package
[22:45] <greg-g> LaserJock: ^
[22:46] <LaserJock> greg-g: you pick the one you think it is
[22:46] <LaserJock> for commonly confused packages you then see "oh, I made a mistake, I need package X"
[22:46] <pwnguin> LaserJock: start small, and fix the yelp problem ;)
[22:46] <greg-g> then we're going to get a lot of people filling out the "linux" package guidelines for naught :)
[22:46] <LaserJock> greg-g: huh?
[22:47] <LaserJock> pwnguin: I think that could be fairly easily done
[22:47] <LaserJock> but there has to be a motivation to make needed changes
[22:47] <greg-g> if people don't know, and don't hae a drop down but have a search box, they type in "linux"
[22:47] <pwnguin> LaserJock: the motivation is "i dont read wacom bugs assigned to yelp"
[22:48] <LaserJock> greg-g: ok, so they get linux, then the linux filing instructions give further information on how to direct the filer
[22:49] <LaserJock> pwnguin: that should probably be fixed then ;-)
[22:49] <greg-g> or: File Bug -> Do you know the Package?(define "package") if no GOTO "How to Find the Right Package" if yes GOTO "File Bug"
[22:49]  * greg-g appologizes for the GOTOs ;)
[22:49] <greg-g> that is a suggestion, btw
[22:50] <LaserJock> I would cut out the Do you know the Package part
[22:50] <LaserJock> because people are going to often say "yes" when they don't ;-)
[22:50] <LaserJock> I would just start bug filing by giving instructions and a package search box
[22:51] <greg-g> "instructions" being "how to find the right package" ?
[22:51] <LaserJock> when they select one the per-package filing instructions are shown
[22:51] <LaserJock> and they can confirm their choice or change to a better package
[22:51] <greg-g> I think if we go away from nopackage then we need a guide on how to find the package pretty early on in the submission process, which an easy to click "skip find package, I know it" link
[22:52] <greg-g> s/which/with/
[22:52] <LaserJock> greg-g: well, you shouldn't have to figure out how to find the package
[22:53] <LaserJock> and the Advanced Bug Filing form is for if you already know the package
[22:53] <greg-g> wait, then how do they find the package other than by guessing?
[22:53] <greg-g> unless they are using apport, launchpad won't know
[22:53] <pwnguin> you can do some analysis of the report itself
[22:54] <greg-g> pwnguin: "you" being the triager, I'm talking about the submitter
[22:54] <LaserJock> greg-g: I said a search box
[22:54] <pwnguin> no
[22:54] <pwnguin> you're missing a key player
[22:54] <pwnguin> Launchpad itself
[22:54] <LaserJock> so it should say something like "What software are you having a problem with?" or something
[22:55] <LaserJock> nice and easy
[22:55] <greg-g> uhhhh, right, and tell me how launchpad will know "I can't check my email" should go to thunderbird instead of evolution or firefox even?
[22:55] <LaserJock> greg-g: well, it can give you a list of email apps ;-)
[22:55] <pwnguin> greg-g: the same way we handle dups
[22:55] <greg-g> pwnguin: that is full text search, right?
[22:56] <pwnguin> it sees email and offers evolution, thunderbird, etc
[22:56] <pwnguin> well
[22:56] <greg-g> not just title
[22:56] <LaserJock> but I'd rather go with asking what software before the person even puts in any other information
[22:56] <greg-g> right, so, your "what package are you having a problem with" is my "howto find the right package"
[22:56] <pwnguin> greg-g: it could be either, depending on scientific analysis
[22:57] <LaserJock> greg-g: what do you mean?
[22:57] <pwnguin> theres also some network problems; if you have an indication of the package to report against, you might do better on dupe checking
[22:58] <LaserJock> I'm saying you have a search box with "What software are you having a problem with?"
[22:58] <chrisccoulson> thats ok for problems with things like e-mail applications or office applications, but what about bugs like 'My USB stick doesn't mount', or problems with things like the window manager. in those cases, it would still be difficult for your average user to know what package the bug report belongs too
[22:58] <greg-g> 17:54 < LaserJock> so it should say something like "What software are you having a problem with?" or something == my "17:49 <    greg-g> or: File Bug -> Do you know the Package?(define "package") if no GOTO "HOw to Find the Right Package"
[22:58] <LaserJock> greg-g: well, maybe, but I thin they're a bit different
[22:59] <LaserJock> *think
[22:59] <pwnguin> chrisccoulson: well mount would probably bring in pmount and the linux kernel as suggestions
[22:59] <greg-g> LaserJock: mine includes a helpful guide? :)
[22:59] <LaserJock> greg-g: yeah, I'm saying we don't want that
[22:59] <LaserJock> greg-g: it shouldn't be that hard
[22:59] <chrisccoulson> or hal / gvfs / nautilus / udev - the list goes on
[22:59] <pwnguin> indeed
[23:00] <chrisccoulson> a normal user will never know. unfortunately, in some cases it will always require quite a bit of experience to get the right package
[23:00] <LaserJock> exactly!
[23:00] <greg-g> I think to do what pwnguin is suggesting requires a lot of engineering, a guide doesn't
[23:00] <LaserJock> greg-g: I'm not suggesting what pwnguin was
[23:00] <greg-g> LaserJock: I know
[23:00] <greg-g> :)
[23:00] <LaserJock> k
[23:01] <greg-g> just making a statement
[23:01] <pwnguin> well, we have engineering, we dont have users that read guides or massive amounts of bug workers
[23:01] <LaserJock> exactly
[23:01] <greg-g> well, if to report the bug you have to click through the guide (or something similar to bugzilla's form submission) then I think it might help, some at least
[23:01] <LaserJock> I think Launchpad should have a usable package search function, in general
[23:02] <greg-g> useful_package_search_function++
[23:02] <greg-g> :)
[23:02] <pwnguin> ideally, suggestion features should be open to public competition the way netflix does
[23:02] <greg-g> pwnguin: not sure what you mean, sorry
[23:02]  * greg-g doesn't use netflix
[23:03] <chrisccoulson> i think apport reported bug reports could be a bit more intelligent with package assignment too. For example, if I go to change my screen resolution but i can't do it, i click the 'Help' button. When I can't find the information i'm looking for, I go to 'Report a bug'. That bug report is then automatically assigned (wrongly) to yelp
[23:03] <LaserJock> I don't think this is terribly difficult to get to
[23:03] <LaserJock> chrisccoulson: serious?
[23:03] <pwnguin> heh
[23:03] <pwnguin> chrisccoulson: I'm already writing a bug report RIHGT NOW about that
[23:04] <greg-g> nice
[23:04] <chrisccoulson> i think so. i havent tried it myself, but i quite often see reports wrongly assigned to yelp. i just assumed that was how they were wrongly assigned
[23:04] <chrisccoulson> i could be wrong though
[23:04] <pwnguin> it does
[23:04] <pwnguin> i tried it
[23:04] <pwnguin> it is plausible, but not nessecarily correct
[23:05] <greg-g> to fix that requires engineering (which we lack and ahve to depend on canonical for) while a guide could be user generated and updated (LP could just pull from a wiki page)
[23:06]  * greg-g is just making wild suggestions ;)
[23:06] <LaserJock> greg-g: well, engineering that LP should be doing vs a short term solution that will make LP not see the need for the engineering
[23:06] <pwnguin> i think suggesting to LP engineers that they just pull a wiki page instead of doing it right would probably result in them doing it right ;)
[23:07] <greg-g> LaserJock: true
[23:08] <LaserJock> I mean the search doesn't have to be very complicated at all
[23:08] <LaserJock> we have quite a bit of data to get somebody close
[23:08] <greg-g> yeah, that could work
[23:09] <greg-g> can we at least a have a link to a howto find the right pacakge guide for those who want to?  ;) ;)
[23:09] <LaserJock> searching through package descriptions for instance should get you fairly close
[23:09] <greg-g> yeah
[23:10] <LaserJock> so you weight heavily on the actual title of the app as the user sees it
[23:10] <LaserJock> then on the package name
[23:10] <LaserJock> and then look into the package descriptions to find likely suspects
[23:10] <LaserJock> on top of that you could also have a developer-feedback system
[23:11] <LaserJock> so if I'm getting a lot of misfiled bugs with a common element I can tell LP and it "learns" that information
[23:11] <greg-g> and the current fulltext (or whatever it is) dupe finding algo
[23:11] <greg-g> could be a winner
[23:11] <LaserJock> that *should* get you down to a short list
[23:11] <LaserJock> then for the packages that are very difficult (such as perhaps linux or FF)
[23:12] <LaserJock> you can have the per-package instructions that would give specific diagnostic help to determine the correct package
[23:12] <LaserJock> and that would be set/edited by perhaps package bug supervisors
[23:13] <pwnguin> bug #253128
[23:13] <LaserJock> and there you go, assigned packages without assuming reporters know the package
[23:14] <pwnguin> LaserJock: i believe we are proposing the same thing
[23:14] <pwnguin> largely
[23:14] <LaserJock> yeah
[23:15] <LaserJock> I just want to do it via "What program are you having problems with?" rather than "Describe your problem?"
[23:15] <LaserJock> I'm not quite sure which would give better results
[23:15] <LaserJock> but we can figure that out
[23:17] <pwnguin> maybe if apport included a process list
[23:17] <pwnguin> or just a process tree from init to itself
[23:18] <LaserJock> hmm
[23:18] <LaserJock> that's an interesting idea, but I'm not sure if that'd be general enough
[23:19] <LaserJock> but perhaps that could maybe feed into the algorithm
[23:19] <pwnguin> it'd probably break down in crashers
[23:19] <LaserJock> but crashers are easy
[23:19] <pwnguin> true
[23:19] <LaserJock> apport knows those
[23:20] <pwnguin> greg-g: to go back to netflix, they have a suggestion system for users. based on what you've rated and rented, they suggest new films for your queue
[23:20] <pwnguin> greg-g: they hold a contest where they invite people to improve the suggestion system measurably
[23:21] <greg-g> oh, yeah, collaborative filtering, yes, I was an undergraduate researcher with a team that does that.
[23:21] <pwnguin> well
[23:21] <pwnguin> the word collaborative might be wrong
[23:22] <greg-g> for netflix, it is right.  user ratings filtered to create suggestions
[23:22] <greg-g> "filtered" == "tons of matrix math"
[23:22] <pwnguin> i suppose if the algorithm considers a large group of people's preference then sure its collaborative
[23:22] <greg-g> not sure how LP would use a similar technology.... go on :)
[23:23] <greg-g> hand waving is fine ;)
[23:23] <pwnguin> well, first it has to be instrumented
[23:23] <pwnguin> you need definitions of success
[23:23] <pwnguin> and failure
[23:24] <greg-g> more hand waving, less specifics
[23:24] <pwnguin> instead of netflix suggestion
[23:25] <pwnguin> you use the bugs marked fixed released as a corpus of reports and package assignments
[23:26] <pwnguin> train some data mining algorithms to make guesses based on some slice of that
[23:26] <pwnguin> then tell the public to do you one up ;)
[23:27] <pwnguin> to rewrite that last sentence
[23:27] <pwnguin> tell the public to one up you
[23:27] <pwnguin> netflix offers a cash prize as motivation
[23:29] <greg-g> right, I get the contest, but not what what the algorithm they are one uping does
[23:29] <greg-g> just, suggesting a package based on a description of the problem?
[23:29]  * greg-g is dense right now
[23:29] <pwnguin> yea
[23:29] <greg-g> ahh, ok
[23:29] <pwnguin> we're after package assignment
[23:30] <pwnguin> i mean, the obvious candidate is bayes
[23:30] <LaserJock> well, a perhaps easier, but still useful method
[23:31] <LaserJock> would be to look at package reassignments
[23:31] <LaserJock> LP could look at what packages get reassigned a lot, and what they get reassigned to
[23:31] <LaserJock> then that would give a useful hint
[23:31] <pwnguin> like i said, the above suggestion is somewhere in the neighborhood of ideal. there are practical concerns, and theoretical complexities