[00:34] <mrooney> bdmurray: the apport hook API seems like it could be cleaner
[00:34] <bdmurray> mrooney: hmm?
[00:35] <mrooney> for example instead of having to import * from apport.hookutils and then doing attach*(report)
[00:35] <mrooney> why not just do something like report.attach_hardware()
[00:35] <greg-g> don't change it! I just spend time writing one for gwibber! ;)
[00:36] <greg-g> s/spend/spent/
[00:36] <mrooney> greg-g: I didn't say drop support for the old style :)
[00:36] <mrooney> but it seems like those methods belong on the report object
[00:36] <mrooney> seems more coherent ot me
[00:36] <greg-g> hardest part was figuring out how to remove passwords from a txt file
[00:37] <greg-g> isn't pitti the author of apport?
[00:37] <mrooney> sbeattie: around by any chance?
[00:37] <bdmurray> yeah
[00:37] <sbeattie> mrooney: what's up?
[00:38] <mrooney> sbeattie: oh great! can you take a quick peek and see if bug 338476 is a dupe of that other one, bug 336512
[00:39] <mrooney> sbeattie: it sounds like potentially the same thing where you can install it fine by manually going through
[00:40] <sbeattie> mrooney: yep, looks the same to me, feel free to dupe it with 336512. Thanks.
[00:40] <mrooney> sbeattie: okay, thanks!
[01:14] <crashsystems> https://bugs.edge.launchpad.net/ubuntu/+source/gnome-control-center/+bug/338502
[01:15] <hggdh> and?
[02:05] <pedro_> charlie-tca: nice work on the hug day ;-)
[02:05] <charlie-tca> Thank you
[05:33] <harrisony> can i get my membership in ubuntu-bugcontrol renewed - LP:harrisony (just got the email and reminded me what fun i had triaging bugs :))
[06:23] <dholbach> good morning
[06:45] <YoBoY> good morning
[12:21] <jsquared> howdy -- I think I found a bug, but I can't figure out what package to report it under
[12:22] <jsquared> what's the best way to figure that out?
[12:23] <jsquared> specifically, the bug manifests itself in the administrative password entry dialog in Gnome under Ubuntu 8.10 whenever you need to do administrative tasks
[12:25] <persia> jsquared, Is that maybe gksu?
[12:27] <jsquared> persia: I'm not sure -- I can't tell if it's a problem with gksu specifically or with whatever draws password text boxes (gtk?)
[12:27] <jsquared> oh... just realized I didn't tell you what the bug was
[12:27] <persia> Doesn't matter.
[12:28] <jsquared> basically, if you enter Unicode text mode, the wrong number of characters is underscored when you're typing
[12:28] <persia> I'd recommend reporting against gksu.  If the bug is actually in a lower-level library, then that task can be added as the bug is investigated.
[12:28] <jsquared> okay. thanks persia!
[12:28] <jsquared> huzzah, first Ubuntu bug filing
[12:44] <jsquared> can I get someone to confirm this? (8.10, Gnome) https://bugs.launchpad.net/ubuntu/+source/gksu/+bug/338727
[12:49] <seb128> jsquared: not confirming on jaunty
[12:49] <seb128> jsquared: that widget is a standard gtkentry no reason for it to be buggy specifically in gksu
[12:50] <jsquared> weird
[12:50] <jsquared> thanks seb128!
[12:51] <seb128> you get the issue?
[12:51] <jsquared> yeppers
[12:51] <jsquared> oh, not on jaunty, no
[12:51] <jsquared> on intrepid
[12:51] <seb128> you don't get it in gtk-demo?
[12:52] <jsquared> not sure what that is -- just noticed it this morning when I started using Gnome instead of KDE
[12:52] <seb128> gtk-demo is a binary name
[12:53] <seb128> or try in any gtk app which has a text entry
[12:53] <jsquared> oh, normal text entry works fine
[12:53] <jsquared> in Gtk apps
[12:53] <seb128> gksu uses a normal text entry
[12:53] <jsquared> just *password* text entry doesn't work fine
[12:53] <seb128> try running sudo app and see if you get the issue
[12:53] <jsquared> gksudo or sudo?
[12:54] <seb128> whatever
[12:54] <seb128> the goal is to run the application under sudo
[12:54] <seb128> the wrapper doesn't make a difference
[12:54] <seb128> to see if that's user specific
[12:54] <seb128> you run your app as your user
[12:54] <seb128> but gksu is an admin tool
[12:55] <seb128> though the ui might be running as your user
[12:55] <seb128> dunno, works for me on jaunty and as said that's a classic widget, weird that gksu behaves differently
[12:55] <seb128> and I didn't know that it was possible to have unicode chars in your user password ;-)
[12:55] <jsquared> how do I flush my sudo privileges?
[12:56] <jsquared> it doesn't prompt me, I think I authenticated too recently
[12:58] <persia> sudo -k
[12:58] <jsquared> yeah, I definitely get it with "sudo synaptic"
[13:00] <seb128> where? in synaptic?
[13:00] <seb128> and sudo gtk-demo?
[13:00] <jsquared> no, in the password box that pops up to request permission
[13:01] <seb128> sudo is a command line tool in doesn't display any dialog
[13:01] <jsquared> sorry, *gksudo synaptic
[13:02] <jsquared> what repository is gtk-demo in?
[13:03] <jsquared> ah, it's part of gtk2.0-examples
[13:06] <jsquared> seb128: I can't seem to find a gtk-demo demo that will show me a password-mode text box
[13:08] <seb128> try with a normal entry
[13:08] <jsquared> just to be clear, there's no problem with normal Gtk text boxes, only when they're set to password mode
[13:09] <jsquared> tried it again, I get the expected result
[13:09] <seb128> try "zenity --entry --hide-text"
[13:09] <jsquared> yeah, that has the same erroneous behavior
[13:10] <seb128> so it's a gtk bug
[13:10] <seb128> try LC_ALL=C zenity ...
[13:10] <seb128> if that's buggy in english too that was likely a gtk bug
[13:10] <jsquared> also erroneous
[13:10] <seb128> and since that works on jaunty I would say it's fixed in jaunty
[13:10] <jsquared> neat
[13:11] <seb128> don't bother opening a bug we will not a backport for a such small change
[13:12] <jsquared> ah, actually I was already told to open a bug earlier in here
[13:12] <jsquared> should I close that one?
[13:12] <jsquared> https://bugs.launchpad.net/ubuntu/+source/gksu/+bug/338727
[13:15] <persia> Yes.  Close that bug as "Fix Released" with a comment that the behaviour seems to be fixed in Jaunty.
[13:16] <jsquared> persia: Okay. should I move the package too since that seems to have been incorrect?
[13:17] <persia> jsquared, That's best practice, yes.
[13:17] <jsquared> persia: which package contains the actual gtk controls?
[13:17] <persia> That keeps a nice documentary record in case anyone else finds it.
[13:18] <persia> I'd think it was libgtk2.0-common, but I'm just guessing.
[13:19] <jsquared> hm.. that doesn't seem to be a package I can pick
[13:20] <jsquared> ah. "'libgtk2.0-common' is a binary package. This bug has been assigned to its source package 'gtk+2.0' instead."
[13:20] <persia> Right.
[13:43] <jgoguen> when triaging, I can't change the Importance, so is it better to leave it Undecided and wait for someone on bug-control to change, or is it better to come in here with a list of bugs and ask someone to confirm that I have chosen the right Importance and then have them change it?
[13:43] <persia> jgoguen, The latter.
[13:44] <jgoguen> persia: thanks :)
[13:53] <jgoguen> I'd like to start with bug 224105, I think it's Medium
[15:16] <YoBoY> hi
[16:01] <bddebian> Boo
[17:02] <qense> Is the Anjuta dependency problem for amd64 caused by a packaging delay or is it a bug?
[17:03] <maxb> What is the problem?
[17:05] <qense> the new package overwrites a file that's also in  libgbf-1-2
[17:05] <qense> I'm talking about Anjuta 2:2.25.902
[17:06] <qense> it replaces the old 2.24 one
[17:06] <qense> oops
[17:06] <qense> it's dinner time here
[17:06] <qense> I'm sorry, I'll return here later. I really got to go
[17:36] <qense> back
[19:10] <tx2650> Hi. How can I tell Intrepid to download the old (2.6.24) Hardy kernel?
[19:12] <greg-g> you will have to install that manually, but there will most likely be a fair amount of issues if you just do a replacement of kernels
[19:13] <andresmujica> tx2650:  clean your apt-cache, backup your source.list, then change intrepid with hardy, then update your cache then install the hardy kernel, then recover your original source.list, clean your cache, and update again.  CAREFULLY
[19:14] <andresmujica> the idea is not install any package diferent from kernel.  but what greg-g says would be true.  however i've made some successful tests (i needed a domain0 kernel.. only at hardy)
[19:15] <greg-g> basically, doing that is NOT supported by Ubuntu and you won't be able to file any bugs if something doesn't work.  But...
[19:16] <greg-g> more power to you if you want to do it.
[19:16] <tx2650> what kind of issues are we talking about? Will some progs stop to work, will there be just some warnings etc..?
[19:18] <greg-g> if certain hardware interactions are written to work with features from a newer kernel then they may not work
[19:19] <tx2650> sounds like the safest thing to do is to backup and reinstall
[19:19] <tx2650> ok, tnx for the advices
[19:28] <andresmujica> ohh yes, that could be messy.. always choose the safest path or the more confortable for you :)  good luck tx2650
[19:28] <tx2650> tnx
[19:34] <tx2650> another thing: what`s with cpufreq on em64t? No support in Hardy or Intrepid?
[20:17] <hggdh_> charlie-tca, I give up on the PPA thingy
[20:19] <charlie-tca> Does seem more difficult than it should be, for sure.
[20:20] <charlie-tca> Thanks for trying, I appreciate your effort
[20:20] <hggdh_> it does not make sense. Malone does not support it right now, but the people that answered seem to be having a knee-jerk reaction, and not really thinking it through
[20:23] <charlie-tca> I know. I don't know how to get people to think about it rationally
[20:23] <hggdh_> perhaps we should propose opening a sf.net project called Ubuntu PPA bugs. This might make them more happy
[20:23]  * hggdh_ is frustrated
[20:23] <charlie-tca> It just shouldn't be that difficult.
[20:25] <hggdh_> and the hell of it is that -- twice -- I proposed involving LP devel; and -- twice -- I got answered that it would be better to get LP devel involved... which makes me think they did *not* read all
[20:25] <charlie-tca> I agree. I don't think they are taking time to read it, they see half a sentence, and it sets them off.
[20:26] <charlie-tca> They are not taking any time to see what else is written
[20:26] <hggdh_> yes. Sic tempora gloria mundi, and all of that
[20:27] <charlie-tca> Well, give it a day or two, and see what develops.
[20:27] <charlie-tca> At the rate we're going, it will be a dead issue
[20:27] <hggdh_> heh. I am, right now, in the mood of giving it eternity -- which is to say, I give up
[20:28] <charlie-tca> I can't yet, but I don't see any point if fighting the same voices over and over, either.
[20:28] <hggdh_> hah! I *know* now what I did wrong. I should have answered with *ONE* single, small sentence ;-)
[20:30] <charlie-tca> I tried that, it's like I forgot to respond
[20:35] <seb128> hggdh_: what is the issue?
[20:35] <seb128> hggdh_: there is clearly a lack for ppa bug tracking right now
[20:36] <charlie-tca> That is the issue, seb128
[20:36] <seb128> hggdh_: but that doesn't mean the corresponding ubuntu component should be abused, I don't want to get bugs on ubuntu packages for every ppa patches version around I don't know about
[20:36] <seb128> charlie-tca: that's is a legitimate concern but nothing to be frustratred about
[20:36] <seb128> that's just not there yet and require work
[20:37] <hggdh_> seb128, I agree. The point is: where else to record the bugs?
[20:37] <hggdh_> hum
[20:37] <seb128> there is just no place right now
[20:37] <hggdh_> could we open a new project on LP called "PPA"?
[20:37] <hggdh_> so if there is no place, then we should do nothing?
[20:38] <seb128> you could but who would want to subscribe to the bug for all the ppa existing?
[20:38] <seb128> well, I just say I've no good idea until launchpad does it right
[20:38] <seb128> abusing the ubuntu tracker is clearly not good
[20:39] <hggdh_> I agree. Waiting for LP to catch up is also not the answer. So we need a middle term somewhere
[20:40] <seb128> I've no good idea for that as said
[20:40] <seb128> out of using the answer tracker
[20:40] <seb128> or mailing whoever does upload to the ppa
[20:40] <bdmurray> Maybe it would be a good idea to see if how many ppa bug reports there are before deciding if it really is a problem.
[20:40] <hggdh_> these are already two options
[20:41] <seb128> neither being very good
[20:41] <seb128> the answer tracker would scale though
[20:41] <hggdh_> better than the "No WAY, and no alternatives
[20:41] <seb128> there is a difference between uploads done to track a bug fix for an ubuntu issue
[20:42] <seb128> and uploads to make available crack of the day svn versions
[20:42] <hggdh_> yes, and I pointed this out in my reply
[20:42] <seb128> I'm fine getting feeback on bug fixes
[20:42] <seb128> but I don't want to get bugs for svn cracks uploaded to a random user ppa somewhere
[20:42] <hggdh_> +1. Abuses should be curbed...
[20:43] <hggdh_> the answers would also fail in identifying the issue as a PPA issue, though
[20:51] <hggdh> bdmurray, how can we identify PPA bugs currently? This would be indeed a good idea
[20:51] <hggdh> that is, if there are any...
[20:52] <bdmurray> hggdh: I'm running a query now, I'll let you know what I find
[20:53] <hggdh> thanks
[20:55]  * charlie-tca thanks bdmurray too
[21:04] <bdmurray> sbeattie: re 338507 you can file bugs w/ apport to staging
[21:11] <bdmurray> hggdh: looks like ~25 for February based of the word "~ppa" in the description
[21:11] <bdmurray> 6 for March so far
[21:11] <hggdh> so not really an issue, although most people do not open PPA bugs
[21:12] <charlie-tca> So if there are so few, why would they need to be marked invalid?
[21:12] <sbeattie> bdmurray: hrm, so I see. It would be nice if apport-collect had a --help option and/or would take a command line arg rather than an environment variable.
[21:12] <bdmurray> Right not an issue from 2 perspectives - it wouldn't clutter bug lists and we won't run into them much
[21:13] <bdmurray> sbeattie: ubuntu-bug?  I was thinking adding a commented out line to crashdb.conf would help
[21:14] <bdmurray> and then documenting that line somewhere
[21:16] <sbeattie> bdmurray: apport-collect's manpage suggests that if the APPORT_STAGING environment variable is set, it will use staging.
[21:16] <bdmurray> hmm, pitti only mentioned crashdb.conf to me
[21:17] <bdmurray> sounds like some testing is in order
[21:23] <bdmurray> hggdh: Another thing to take into consideration is I don't think there is a way to get from ppa package version to person / team associated with that
[21:25] <hggdh> bdmurray, I agree. We really would need LP devs to step up. Meanwhile, PPAs are more and more used to test fixes, and we need a way to have the PPA owner aware of issues
[21:26] <bdmurray> hggdh: I don't understand your first sentence.  What I mean is that if we have this "0.13-0ubuntu0~ppa1~intrepid1" - we've no idea whose ppa it is from.
[21:28] <seb128> charlie-tca: <charlie-tca> So if there are so few, why would they need to be marked invalid?
[21:28] <seb128> charlie-tca: because people having a ppa for <something> are not subscribe to the ubuntu <something> component
[21:28] <seb128> charlie-tca: and because the ubuntu maintainter for <something> doesn't know about the ppa version and doesn't care about thing he or she doesn't know
[21:28] <hggdh> bdmurray, heh. I mis-expressed myself. I understand that, and this is the link we currently miss.
[21:29] <charlie-tca> Thanks, seb128
[21:29] <seb128> you're welcome ;-)
[21:29] <charlie-tca> If they are subscribed and take the bug, is it okay to use it?
[21:29] <hggdh> and, as seb128 pointed out, we should not mark a bug against an official package
[21:29] <seb128> the ubuntu maintainer still might not want to get emails about issues for things he's not working on
[21:30] <hggdh> yes indeed
[21:30] <charlie-tca> That does make sense
[21:30] <seb128> we lack the media to channel those bugs
[21:30] <hggdh> pretty much like the upstream fixes I every so often put available for Evolution
[21:30] <seb128> but as said abusing the ubuntu component is poor workaround
[21:30] <seb128> better to email the maintainer or use the answer tracker imho
[21:30] <hggdh> they are not Séb's issue, but mine, and upstream
[21:30] <seb128> the answer tracker is for support and not bugs
[21:31] <hggdh> there is a point here: right now we either abuse LP, or the answer track...
[21:31] <bdmurray> I'm thinking Invalidating and tagging so the ppa maintainer could find them is the right idea until there is a way to find out whose ppa the package is from
[21:32] <seb128> I would say that somebody uploading to a ppa is working personnaly on the thing uploaded
[21:32] <seb128> so using direct email is okish
[21:32] <hggdh> seb128, +1
[21:32] <hggdh> (or the team -- see FFox, and others)
[21:32] <hggdh> what about just adding a sentence in the PPA description to directly email the author?
[21:33] <hggdh> like: "Please do not open LP bugs against these PPA packages -- they will be summarily invalidated; instead, please email the author."
[21:34] <bdmurray> hggdh: where would people see this?
[21:34] <hggdh> bdmurray, nowhere, since nobody actually goes to the PPA URLs... but at least we are trying
[21:34] <bdmurray> heh
[21:35] <hggdh> and, when we close invalid, we add this to the reason. Standard responses...
[21:35] <charlie-tca> Better than what we are now doing, I think.
[21:36] <hggdh> that is the point. We will not get the ideal scenario anytime soon, but at least we will be getting somewhere
[21:37] <hggdh> just a policy change, right now
[21:38] <charlie-tca> every little bit helps.
[21:58] <crashsystems> For some reason right-clicking the indicator applet does not pull up the context menu necessary to remove it (I accidentally added an extra applet). Is this a feature or a bug?
[22:00] <LaserJock> bdmurray: just read your apport post. Do you imagine there's influence from 1) workflow bugs 2) people filing bugs on machines other than the one experiencing the bug and 3) apport isn't intuitive to find
[22:01] <bdmurray> LaserJock: 1) is less than 10% of the volume
[22:02] <LaserJock> bdmurray: ok, I wasn't sure how much. I didn't think it'd be too much
[22:03] <bdmurray> LaserJock: 3) could be - the motiviation for the post was to educate people
[22:03] <LaserJock> yeah, I just never think to, I just use a LP +filebug URL
[22:08] <LaserJock> bdmurray: anyway, good post and thanks especially for the stats.
[22:08] <bdmurray> LaserJock: no problem, I hope to see the March numbers go up! ;-)
[22:09] <LaserJock> bdmurray: is there any way to separate out how many of the apport bugs are the automatic crash ones?
[22:10] <LaserJock> i.e. how many people are actually thinking "I need to open a bug, I know, I'll use apport" as opposed to something crashed and apport just came up
[22:11] <bdmurray> They are already separated, apport-crash is used for crash reports and those are initially private so don't hit the ubuntu-bugs mailing list.
[22:15] <LaserJock> bdmurray: ok, so those weren't included in your stats?
[22:16] <bdmurray> LaserJock: that's right apport-bug are only the ones reported by "Help -> Report A Problem" or ubuntu-bug not crashes and not package upgrade problems
[22:17] <LaserJock> wow
[22:17] <LaserJock> then I'm actually impressed by 10-13%
[22:17] <LaserJock> I would have guessed much lower
[22:29] <andresmujica> bdmurray: enlight me please, when a user faces a bug (and never before has faced one,) how do the user knows about reporting at launchpad ?
[22:31] <bdmurray> maybe? http://www.ubuntu.com/community/ReportProblem
[22:31] <bdmurray> or the release notes
[22:31] <bdmurray> or the help menu in the application
[22:44] <andresmujica> ok, maybe we could find a way to make that less technical for the final users.. maybe an screencast showing how to report the bug using apport..  i'm thinking about the experience of reporting a bug...  and the usefulness of their report..
[22:44] <bdmurray> a screencast is a great idea!
[22:45] <dtchen> (we should probably have screencasts for a bunch of different workflows)
[22:45] <bdmurray> One thing I was curious about was making them easier to edit as UIs change
[22:46] <bdmurray> Rather than rerecording the whole thing
[22:48] <dtchen> if you aim for a short 'cast, e.g., 2 minutes, it wouldn't be too bad just to rerecord whichever portion changed
[22:50] <andresmujica> i was trying to do that but couldn 't do it.. bad video editing skills
[22:55] <bdmurray> andresmujica: wrt bug 297890 there are some issues with bug watches not updating
[22:58] <harrisony> bdmurray, can i poke you to get my ubuntu-bugcontrol status renewed - https://edge.launchpad.net/~harrisony
[23:00] <bdmurray> harrisony: you should be set
[23:04] <andresmujica> yeap
[23:04] <andresmujica> that was filippo asking about.. i hadn't look at it yet...
[23:05] <andresmujica> talking about bugcontrol i've recently apply for it.. :)
[23:06] <andresmujica> so i wonder if bdmurray had the chance to take a look at the application...
[23:06] <bdmurray> andresmujica: If I found that bug and it was in your app...
[23:08] <andresmujica> duh
[23:25] <bcurtiswx> bdmurray: bug triagers have to ask on a more frequent basis, questions to bug reporters , along the lines of ubuntu version and package reported version... What im wondering, is why isn't this information gathered in the initial bug report? (i think apport collects this), but manual reports don't.
[23:25] <bcurtiswx> or anyone who feels like responding :)
[23:28] <bdmurray> bcurtiswx: How would it be collected?
[23:28] <charlie-tca> I'm starting to think the version is not always needed, unless you are going to backport the fix
[23:28] <dtchen> hacktick: please assign bugs to `linux' *not* `alsa-driver'
[23:28] <dtchen> grr
[23:29] <bcurtiswx> bdmurray: the initial questions in a manual report should ask the user the version of ubuntu and the version of the package effected for the bug(if they know)
[23:29] <charlie-tca> There used to be a set of questions on the reporting page, in launchpad, that did state it was needed. Didn't seem to help much, though
[23:30] <bdmurray> The "Ubuntu guidelines:" on https://edge.launchpad.net/ubuntu/+filebug-advanced ?
[23:31] <charlie-tca> That's it. Doesn't seem like most reporters think that is important, though
[23:33] <bdmurray> A surprising number of bug reports are reported from https://bugs.edge.launchpad.net/bugs/+filebug where they don't get the Ubuntu guidelines.
[23:33] <bcurtiswx> bdmurray: charlie-tca: that informations requested at the bottom.  And i believe most people, who are trying to file a bug quickly, won't bother to read that... i think it should be changed and moved to a text field in the top section.. this way bug reporters can have that information available, since most of the time we have to wait a day or two at least for the persons response
[23:33] <bdmurray> Which is really unfortunate but I believe its being worked on.
[23:36] <bcurtiswx> maybe even make it a required field.. (at least the ubuntu version, i can understand a bug reporters that don't know the package involved)
[23:37] <charlie-tca> Keeping in mind, people already refuse to file bugs because it is too much work to file it in launchpad.
[23:39] <bcurtiswx> charlie-tca: i think thats the same with a lot of bug maintainers
[23:39] <bcurtiswx> i.e. gnome, debian
[23:40] <charlie-tca> The more boxes you create, the more work it becomes
[23:40] <bcurtiswx> well, maybe on submit grab that information from submitters computer?
[23:40] <charlie-tca> Doesn't that defeat the purpose, of it?
[23:41] <charlie-tca> I like that idea, if it is possible.
[23:41] <bcurtiswx> bdmurray: ^^
[23:41] <bcurtiswx> if they choose a package.. then maybe we can grab the version number on submit too
[23:42] <bdmurray> I seem to recall some talk of writing a Firefox extension that'd grab some information and prepopulate the field in LP.
[23:43] <bcurtiswx> bdmurray: is it too much of a security/infringement to have launchpad do this on submit.. no extensions/plugins needed
[23:56] <bdmurray> bcurtiswx: I've no idea - maybe check with the LP devs?
[23:56] <bcurtiswx> bdmurray: will do