[09:00] <LimCore> how to use most recent nvidia drivers? since the glx-new seem to be crashing
[09:00] <RAOF> glx-new _are_ the most recent nvidia drivers.
[09:04] <LimCore> RAOF: I use them. regarding my resets in  https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/228417
[09:05] <RAOF> Oh, those would be Gutsy's nvidia-glx-new.  No, they're not the latest version.
[09:05] <LimCore> how to get the latest
[09:05] <LimCore> the latest should NOT have this SMP nvidia bug?
[09:05] <RAOF> No, the latest still have that SMP bug.
[09:06]  * LimCore bitchslaps nvidia CEO
[09:06] <LimCore> they know about this bug right?
[09:06] <LimCore> got urls about this bug?
[09:06] <RAOF> Yes, they do.
[09:06] <RAOF> Uumm...
[09:06] <RAOF> It'll be in a bug on linux-restricted-modules-2.6.24
[09:06] <RAOF> Don't have one offhand.
[09:08] <LimCore> lol https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24
[09:08]  * LimCore lols @ the bugfest
[09:10] <RAOF> What can I say?  Drivers are hard, and proprietary drivers suck.
[09:14] <LimCore> https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/151382
[11:11] <qense> hello
[11:12] <james_w> hi qense
[11:54] <qense> I'm going to mark bug 216272 as invalid since the problem reported is fixed. But there is another user with another problem having the same effect. It only happens when his networking is set to automatic, has anyone a clua against what package I should ask him to file a new bug describing his problem?
[12:00] <james_w> qense: I guess hal would be a good place to start
[12:00] <qense> is HAL also responsible for networking?
[12:00] <qense> that's new to me :)
[12:01] <hwilde> hardware abstraction layer is responsible for lots of things...
[12:01] <qense> OK, thanks
[12:03] <hwilde> i heard networking auto and certain interfaces files can conflict with nm-applet and gnome network settings...
[12:04] <qense> that could be the cause
[13:11] <Iulian> G'morning pedro
[13:13] <qense> pedro_: you marked one of the bugs you marked as duplicate also as invalid. I'm curious why you did this, because if I remember it correctly it's against the bug triaging policy
[13:13] <pedro_> qense: which bug?
[13:14] <pedro_> Iulian: morning!
[13:14] <qense> Bug 228630
[13:14] <qense> hello btw :)
[13:15] <pedro_> it doesn't really matter if its a duplicate
[13:16] <qense> it dissapeared from the https://wiki.ubuntu.com/Bugs/HowToTriage#head-170e00a7154fcfc87f0fc50f65bba9cff7ab27fe page
[13:16] <qense> but I can recall such a rule
[13:17] <qense> well, at least you marked is at duplicate. someone else marked a bug invalid and told it was a duplicate, but forgot to mark it duplicate
[13:17] <pedro_> there's no rule about that i'm afraid
[13:17] <qense> ok
[13:17] <qense> my bad :) I just was curious about that rule
[13:17] <pedro_> well sometimes we also mark them as invalid if we cannot find the exact number of the duplicate
[13:17] <pedro_> that can be hard to do if you deal with thousand of reports daily
[13:18] <qense> there are indeed a lot of bugs
[13:18] <qense> and that's an understatement
[13:18] <pedro_> but yeah i'd love to have a better search system :-)
[13:18] <pedro_> that allow me to search for functions names on the stacktraces and things like that
[13:46] <askand> ﻿Hello, I am not able to reach the settings for the loginscreen, is that a known bug?
[13:50] <qense> you need certain permissions to access it
[13:50] <qense> did you isntall the system by yourself?
[13:51] <qense> or manage it?
[13:51] <askand> ﻿askand: I manage it, someone over at #ubuntu have the same problem as me
[13:52] <askand> ﻿qense: it shows up after a long time and under that time the harddrive is very busy
[13:52] <qense> :(
[13:52] <qense> you can open other applications with gksu before it? (eg 'gksu gnome-system-monitor)'?
[13:52] <james_w> askand: do you get the gksudo password prompt?
[13:54] <askand> ﻿james_w: ﻿qense: Yes I got to the password prompt..however when I tried it again now it opened instantly
[13:55] <askand> ﻿qense: ﻿ james_w: both of us that had the problem was opening the settings for the first time after installation of the system..
[13:55] <askand> seems like some kind of indexing is going on?
[14:35] <james_w> askand: sorry, lost my net connection, did you get my last messages?
[14:36] <askand> ﻿james_w:  nope dont think so, did you get mine? :)
 seems like some kind of indexing is going on?
 askand: I think I know what this is, give me a minute.
 askand: good guess though.
[14:36] <askand> ﻿ james_w:  ahaa ok
[14:39] <james_w> I can't find the bug right now, if indeed there is one filed.
[14:39] <james_w> basically running some things under gksudo fires up a trackerd and some other things as root, and for some reason this trackerd is blocking, when normally it is not.
[14:40] <james_w> that means that when it happens you have to wait until it has indexed your disk, as you found.
[14:40] <askand> ﻿james_w: I see, I thought tracker had been disabled in hardy?
[14:40] <james_w> yep
[14:40] <james_w> and it shouldn't run in this case anyway.
[14:42] <askand> ﻿james_w:  I see
[14:43] <james_w> askand: nope, sorry, can't find the bug right now, and the people that I know will know if there is one are off today.
[14:44] <askand> ﻿ james_w: ok perhaps they will see this later or something, thanks for helping :(
[14:44] <askand> :)*
[14:44] <james_w> no problem
[15:20] <dashun> hello
[15:21] <james_w> Laney: bdmurray and thekorn are probably the best people to ask about py-lp-bugs
[15:21] <james_w> hi dashun
[15:21] <dashun> i have upgraded to ubuntu hardy and i get random disk shutdowns, where i can move the mouse for a while, but ultimately need to REISUB
[15:21] <dashun> hi james_w
[15:21] <Laney> james_w: Thanks
[15:21] <Laney> bdmurray, thekorn, or anyone else: Is there an API reference available for py-lp-bugs anywhere?
[15:22] <dashun> ...after REISUB, the disk doesn't start in bios and need to switch off and on to continue... so do i file a bug for this?
[15:22] <james_w> Laney: I don't know if help() from a python interactive session is helpful
[15:23] <james_w> dashun: probably.
[15:23] <james_w> what's REISUB?
[15:23] <dashun> the safer way to reboot. alt print+screen then those letters. limits the amount of file corruption i have been getting with the continual reboots...
[15:24] <james_w> and it's definitely a disk issue, it's not X freezing or anything?
[15:24] <thekorn> Laney, we have some wiki pages: https://wiki.ubuntu.com/BugHelper/Dev/python-launchpad-bugs/Bug
[15:25] <thekorn> Laney, and https://wiki.ubuntu.com/BugHelper/Dev/python-launchpad-bugs/API_changes/BugListExample
[15:26] <thekorn> for a start,
[15:26] <Laney> thekorn: Aha, thanks. I was looking for how to submit a bug, which seems to be here
[15:26] <dashun> i can hear my disk drive lose power or something (same sounds as hibernating and switching off), and after REISUB reboot, bios doesn't detect the disk...
[15:26] <thekorn> Laney, feel free to ping me if you have further questions
[15:26] <Laney> Cheers
[15:27] <dashun> james_w: i can also move mouse and type letters into terminal, commands just don't work (e.g. ls)
[15:28] <james_w> dashun: I would suggest filing a bug on the kernel
[15:29] <james_w> can you tail -f /var/log/syslog and look for anything interesting next time it happens?
[15:30] <dashun> i have checked the logs i know, but couldn't see anything interesting
[15:31] <dashun> i have been following http://ubuntuforums.org/showthread.php?t=765510...
[15:32] <dashun> .. and didn't know whether another bug report with seemingly randomly occuring bugs would be of benefit...
[15:32] <dashun> *randomly occuring freezing*
[15:34] <james_w> that forum thread has about 4 different problems described in it.
[15:34] <james_w> a bug might be helpful, I would think it was your best bet.
[15:34] <james_w> it would help to get as much information as possible though.
[15:35] <james_w> https://wiki.ubuntu.com/KernelTeamBugPolicies might help you
[15:38] <dashun> cheers james_w, i was going to follow that. i just came here to check because in http://www.ubuntu.com/community/ReportProblem it says "When to file a bug -  You can repeat the problem", which i can't
[15:38] <james_w> dashun: you can't repeat it at will, but it does keep happening doesn't it?
[15:38] <dashun> my computer could go down right now...
[15:38] <james_w> what kernel version are you running?
[15:39] <bddebian> Boo
[15:39] <dashun> % uname -r
[15:39] <dashun> 2.6.24-17-generic
[15:42] <dashun> and yes it does keep happening, about ~15 times in past week, open file corrupted 3 times
[15:42] <dashun> and since upgrade to hardy only
[15:45] <james_w> dashun: do you have the -16 kernel installed on your machine?
[15:48] <dashun> james_w: i did, but the crashing/freezing started, and so when the -17 kernel came, i upgraded, hoping that fixed it
[15:49] <james_w> ok, just wondered if you could narrow down when it started.
[15:49] <dashun> hardy
[15:50] <dashun> which i upgraded to from gutsy
[15:50] <james_w> yeah, unfortunately that's quite a large timeframe for the kernel
[15:52] <dashun> i regularly use aptitude and upgrade the repos so i probably had a recent version of the kernel before upgrading to hardy
[15:52] <dashun> and by recent, i mean end-user repos recent
[15:56] <dashun> i think maybe i was fine on 2.6.22-17-generic
[15:56] <ScottK> bdmurray: You around?
[16:00] <dashun> anyway cheers james_w, i will file a bug on kernel ala ﻿https://wiki.ubuntu.com/KernelTeamBugPolicies. bye.
[16:00] <james_w> thanks dashun
[16:01] <php_penguin> hi, is anyone else getting this bug: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/229587
[16:09] <bdmurray> ScottK: sure enough
[16:10] <ScottK> bdmurray: It seems we're still having trouble with bugsquad people messing with workflow bugs.
[16:11] <Hobbsee> which isn't helped by heno's revert
[16:11] <ScottK> I thought we had agreement they weren't supposed to mess with them, but now I hear the documentation about that was all reverted by heno.
[16:11] <Hobbsee> because documentation is, apparently, evil.
[16:13] <bdmurray> What exactly are looking for from me?  I'm not the one who changed the wiki.
[16:14] <ScottK> bdmurray: You're in charge of bugsquad.  It's your documentation isn't it?
[16:14] <ScottK> If someone is making bad edits to the bugsquad docs, I think it's in your area to speak to them about it.
[16:15] <ScottK> Currently one person is going through and adding [wishlist] to the title of all the sync requestes.
[16:15] <ScottK> It just makes no sense at all, is distracting, and discourages newcomers.
[16:16] <Hobbsee> and increases spam!
[16:16] <Hobbsee> yay, spam!
[16:16] <bdmurray> Okay
[16:17] <ScottK> Additionally, if you've got some way to contact https://edge.launchpad.net/~nglnx and get them to stop, that'd be marvelous too.
[16:18] <Hobbsee> ScottK: i hope that's not a kmos-clone, incidently.
[16:20] <bdmurray> Okay, just to clarify things I've never heard of this person even though they've joined the bug squad.  So saying that a bugsquad person is messing with workflow bugs is a bit presumptuous.
[16:21] <Hobbsee> it's technically correct, though.
[16:21] <ScottK> The larger problem is that the documentation saying not to do so was reverted and so we can't even point them at it.
[16:22] <ScottK> Hobbsee: If it's a kmos clone, he was making new accounts last year in anticipation of getting booted.
[16:22] <ScottK> bdmurray: If the documentation was present, we could just point them at it and ask them to stop.
[16:23] <bdmurray> ScottK: And what did you do before the documentation was present?  Which if I recall correctly you two only wrote last week?
[16:23] <ScottK> It's only recently it's started to be a significant problem.
[16:23]  * ScottK suspects 5-a-day is encouraging more useless bug edits.
[16:24] <ScottK> bdmurray: We're trying to make progress and people removing documenation isn't helping.
[16:25] <hggdh> ScottK: who is "people"?
[16:25] <Hobbsee> hggdh: heno, in particular.
[16:25] <Hobbsee> hggdh: and anyone else, if they decide to do the same thing.
[16:26] <james_w> ScottK: without trying to argue the validity of your point, it appears in this case that the person in question isn't taking part in 5-a-day, at least not using the tracking part.
[16:26] <hggdh> Hobbsee: there is the other side of the coin: we do have a SOP (right or worng, complete or incomplete) for dealing with bugs. It haoppens your current way breaks this
[16:26] <Hobbsee> hggdh: i'm sure it does, but i've yet to see anyone actually propose a valid way of handling them, that fits both teams.
[16:27] <Hobbsee> hggdh: and i asked a few days ago, when the revert was first made.
[16:27] <ScottK> james_w: OK.  It was more a reference to the perceived general increase in worthless bug churn.
[16:27] <hggdh> Hobbsee: I understood this would be discussed on the next meeting
[16:27] <james_w> ScottK: sure, I was just interested so I checked.
[16:27] <bdmurray> Hobbsee: It was mentioned that we should discuss this at UDS
[16:27] <Hobbsee> bdmurray: what time will it be discussed?
[16:28] <bdmurray> Hobbsee: I'm not certain but I could look into that for you
[16:28] <Hobbsee> bdmurray: and is it valid to delay it, when people are causing bug churn *now*?
[16:28] <ScottK> bdmurray: There's not much to discuss.  There's no point in bugsquad fixing workflow bugs.
[16:28] <ScottK> bdmurray: All it's going to get them is developers annoyed at them.
[16:28] <hggdh> ScottK: again, without discussing the merit: there is no point in you bypassing current bug SOP
[16:29] <ScottK> hggdh: I thought we had an agreement last week to change it.
[16:29] <Hobbsee> while i can understand that a more permanent thing should happen at UDS, then discussed with the bugsquad afterwards, it's still something that's happening now, and fundamental changes like that won't happen overnight.
[16:29] <Hobbsee> if you're going to change how the workflow bugs work, to fit in more with bugsquad aims, then the sponsorship teams have to redo their documentation, etc, too.
[16:29] <Hobbsee> there's no way that's really going to happen, with the associated discussion, in under a month.
[16:30] <ScottK> Hobbsee: That or I just unsubscribe to all the packages I'm subscribed to and quit worrying about it.
[16:30] <Hobbsee> is it *really* appropriate to do that?
[16:30] <ScottK> That'd solve the problem.
[16:30] <Hobbsee> and effectively ignore it in the interim?
[16:31] <Hobbsee> ScottK: no, it wouldn't, because in the case of your bug getting responded to on the list, it stays in the archive indefinetly,when it shouldn't, due to an incorrect closing.
[16:31] <ScottK> The bugsquad spam problem is only a problem for me because I'm trying to be invovled in more than the immediate issues that affect me.
[16:31] <bdmurray> ScottK: You've pointed at one person causing "bug churn".  Is there only one within past week?
[16:31] <ScottK> bdmurray: I don't know.  I only know when people complain about it or when it happens to me.
[16:32] <ScottK> I don't see what's so hard about "Developers use bugs to track stuff.  Don't change such bugs.  You can identify these bugs by ..."
[16:32] <bdmurray> Well, that's not much to go on.  Adittionally if you are getting when nglnx changes a bug you should be able to find their e-mail address in that bug mail.
[16:33] <ScottK> Why can't we just agree to that?
[16:33]  * Hobbsee unsubscribed from ubuntu-archive a while ago, but still saw various bug churn by members of the bugsquad.
[16:33] <Hobbsee> setting a tag, or setting importance.
[16:34] <bdmurray> ScottK: It increases the barrier to entry for triaging bug reports if people have a specific list of bugs not touch.  Additionally, these work flow reports make up the minority of bugs reported in Launchpad so it seems to me that you could be a little bit flexible.
[16:34] <ScottK> It's discouraging to new developers trying to learn.
[16:34] <Hobbsee> bdmurray: so, needless spam is encouraged?
[16:34] <bdmurray> Well, and its discouraging to new triagers to have a list of things not to touch.
[16:35] <ScottK> bdmurray: For new people if they don't understand it, they SHOULDN'T touch it.
[16:35] <Hobbsee> this is starting to sound like "let the triagers do whatever they like, just to get them on board"
[16:35] <bdmurray> Hobbsee: That's not what I said, what I mean is that you guys could be a little bit more forgiving and reasonable.
[16:35] <Hobbsee> is that the intention?
[16:35] <Hobbsee> bdmurray: every time they add something useless like that, it creates yet another bugmail.  how is that not needless spam?
[16:36]  * Hobbsee thought 'forgiving and reasonable' would be not sending them abusive emails, telling them 'DO NOT TOUCH', or something.
[16:36] <Hobbsee> which is what tends to happen when they do something really idiotic, like assigning motu to bugs.
[16:36] <Hobbsee> insta-bug-spam!
[16:36] <bdmurray> Hobbsee: that lacks any tact and really makes the person sending that e-mail seem like an ass
[16:37] <Hobbsee> bdmurray: that would be the summary of it, of course.
[16:37] <Hobbsee> not the entirety of the mail.
[16:39] <bdmurray> Clearly what nglnx has done is incorrect.  I'd like to see more examples of the types of things that are generating e-mails so I can get an idea of what people are doing exactly.
[16:39] <hggdh> Hobbsee: OK. another try, another tack: why are these dev requests kept in new, unassigned for so long?
[16:39] <Hobbsee> hggdh: oftne, they're confirmed.
[16:39] <ScottK> hggdh: It's irrelevant.
[16:39] <Hobbsee> hggdh: and because the sponsorship teams don't get assigned, for various reasons, as documented a few days ago.
[16:40] <ScottK> hggdh: Many workflow bugs have specific criteria for specific states and the timeline that's resonable is far different than regular bugs.
[16:40] <hggdh> ScottK: no it is not. It may be irrelevant for you, but not for bug triagers
[16:40] <ScottK> hggdh: Not if they just don't touch them.
[16:40] <ScottK> It gets back to "If you don't understand it, don't touch it."
[16:40] <ScottK> Which is, I think a good general rule.
[16:40] <hggdh> ScottK: you mean lets completely get out of the current API and completely disregard it?
[16:41] <ScottK> So the current rule is change it whether or not you understand the bug?
[16:41] <ScottK> That's messed upl
[16:41] <ScottK> up.
[16:41] <ScottK> If that's the case, then yes.
[16:41]  * Hobbsee notes that the X guys, and the mozilla guys, have special bug methodologies.
[16:42] <Hobbsee> i'm sure that makes it harder for new triagers, because it's not all the same
[16:42] <Hobbsee> so, surely those should go away too?
[16:42] <bdmurray> Hobbsee: those are for specific packages not *every* package
[16:42] <Hobbsee> [01:35] <bdmurray> Well, and its discouraging to new triagers to have a list of things not to touch.
[16:43] <Hobbsee> so, how is a package different from a subscriber, or a set of names?
[16:43] <Hobbsee> although, i see that it's easier to find a list of all those bugs.
[16:43] <pochu> I think it's easier to remember "sync, merge" than "firefox, thunderbird, xorg, xserver, x-x-v-*, ..."
[16:44] <pochu> OTOH, we could also do some things on our side to fix or minimize these cases
[16:44] <bdmurray> The subscriber portlet is not immediately obvious and its taught as something to look at in the bugsquad's current workflow.
[16:44] <ScottK> bdmurray already made a greasemonkey script to find such workflow bugs.  It can't be that hard.
[16:44] <pochu> like making request-sync to file Triaged bugs instead of Confirmed
[16:44] <pochu> (when no sponorship is needed)
[16:44] <pochu> or assigning teams to bug reports instead of subscribing
[16:44] <Hobbsee> pochu: how do you handle the case where it's thrown back, as it's wrong?
[16:44] <pochu> I still don't know what's wrong with assigning vs subscribing
[16:44] <ScottK> pochu: Generally archive-admins look at a filtered list of archive bugs.  They may not see those.
[16:44] <Hobbsee> pochu: i've already said earlier why assigning teams *does not work*.  please go back and read it.
[16:45] <pochu> ScottK: I understand, but it's probably not too much work to fix that, and the bugsquad won't probably annoy us for those bugs anymore
[16:46] <Hobbsee> pochu: in particular, they get unassigned, or the assignment switched when someone takes them, which looks the same to the email interface as those bugs which don't have any action on them.
[16:46] <Hobbsee> pochu: so there's then no differentiation, by the bugmail, about what is done, and what isn't.
[16:46] <geser> pochu: but this need to be discussed with all involved parties instead of just changing the procedures
[16:46] <pochu> Hobbsee: if it was the other day when we discussed it, if you really said it then I didnt understand it, in which case would be nice if you could rephrase (I'm not native speaker)
[16:46] <pochu> geser: ack
[16:46] <geser> workflow bugs are no new invention
[16:47] <Hobbsee> geser: documenting existing, unwritten procedures != designing new procedures.
[16:47] <pochu> geser: I'm just proposing solutions which could fit to everyone. I understand they may not be good enough though :)
[16:48] <Hobbsee> pochu: try assigning yourself to a bug, then unassigning.  note that you get no more bugmail about it.
[16:48] <Hobbsee> pochu: note that you also get no more bugmail if you are still assigned, but no one has done anything about the bug.
[16:48] <Hobbsee> pochu: how do you differentiate between the two?
[16:48] <pochu> That's clearly a Launchpad bug
[16:49] <Hobbsee> pochu: the subscription works, as people don't tend to unsubscribe the archive / sponsorship teams / etc.
[16:49] <pochu> when you are assigned to a bug, and someone unassignes you, you should get that mail, but not future mails
[16:49] <pochu> so you should see you are unassigned (and the comment if any)
[16:49] <Hobbsee> pochu: true, but it's a launchpad bug, there are many, and it's very unlikely to be fixed in a reasonably short timeframe.
[16:50] <Hobbsee> pochu: so, for the 6+ months that it doesn't get fixed, a workaround is probably a good idea.
[16:50] <bdmurray> pochu: do you know if there is an existing bug report for that?
[16:50] <pochu> Hobbsee: so do you think assigning bugs to teams would be ok if that would was fixed?
[16:50] <pochu> bdmurray: I'm looking into it right now
[16:50] <Hobbsee> pochu: yes, i think so.
[16:51] <ScottK> pochu: I think not myself.
[16:51] <Hobbsee> wait, no.
[16:51] <ScottK> To me, "Assign" means I have given you work.
[16:51] <ScottK> As a volunteer, I don't think anyone gets to do that, but me for me.
[16:51] <Hobbsee> ah, yes, it would solve the problem, as long as it also sent mail about the assignee change, too.
[16:52] <ScottK> When you're paying my consulting rate, feel free to assign me stuff.
[16:52] <pochu> Hobbsee: sure, it would show both the assignee change and the comment and the status change... (if any)
[16:52] <pochu> ScottK: well, here they would be teams, not you directly
[16:52] <geser> and assigning a team isn't really helpful either as still nobody knows who is exactly working on it (or even if someone is working on it at all)
[16:53] <Hobbsee> geser++.
[16:53] <ScottK> pochu: Indirectly it's the same.
[16:53] <Hobbsee> geser: it also encourages people to subscribe other teams.  like ~ubuntu-dev to any bug that the ubuntu developers should fix.  *sigh*
[16:53] <Hobbsee> er, s/subscribe/assign/
[16:53] <pochu> ScottK: but can I ask you to look into something without paying you?
[16:54] <ScottK> pochu: You can ask, but not direct.
[16:54] <pochu> So then I can't subscribe ~u-u-s without asking you first?
[16:54] <pochu> (assuming you're in u-u-s)
[16:54] <ScottK> Subscribe is not assign.
[16:55] <pochu> geser: I see. You can still reassign it to you, but I guess that's not ideal
[16:55] <Hobbsee> multiple teams can be subscribed, as can multiple people.
[16:55] <pochu> geser: OTOH you can mark it 'in progress'
[16:55] <Hobbsee> there's no actual commitment to fixing it there, just an "i'm interested in this bug"
[16:55] <ScottK> Subscribe gets it on a list that I'll look into if I choose.  The semantics are fundamentally different than assign.
[16:56] <pochu> ScottK: but AIUI, subscribing you is like asking you to look at it. YMMV though
[16:56] <Hobbsee> pochu: sure, but asking someone to look at it != demanding that they fix it
[16:56] <ScottK> pochu: As an individual, yes.  But, for example, I don't get bugmail when someone subscribed UUS.
[16:59] <pochu> I see it this way: If there's a sync bug from a developer, assign it to ~ubuntu-archive, which will proceed the bug and fix it. If it's a MIR, assign the bug to ~ubuntu-mir which will proceed it and in the end either fix or close as won't fix. If it's a sponsorship request, assign to ~u-[mu]-s which will either upload, ask for more work, or invalidate the request. If they ask for more work, they can switch it to Incomplete, or reassign to the one w
[16:59] <ScottK> pochu: What advantage does this have over subscribing?
[16:59] <pochu> that may not be a perfect, or even a good workflow, but it looks fine to me and IIUC should fix the problems with the bugsquad
[17:00] <pochu> ScottK: that the bugsquad isn't supposed to touch bugs with an assignee
[17:00] <pochu> "supposed"
[17:00] <Hobbsee> pochu: and it gets assigned back to the person, if it gets thrown back?
[17:00] <qense> bdmurray: there wasn't a single response at my email to the bugsquad(https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-May/000840.html) about the collection of data per source package about which we talked a while ago
[17:00] <qense> what should we do?
[17:00] <pochu> Hobbsee: yeah, either that, or set to incomplete, or both. whatever is better
[17:01] <bdmurray> I think assignment is a lot more visible than subscribers in the current layout of Launchpad.
[17:01] <bdmurray> Additionally, the subscribers portlet isn't covered at all in any triaging documentation or classes.
[17:02] <ScottK> So your solution is we have to update all the workflow processes?
[17:03] <pochu> BTW, doesn't seem to exist such a bugreport about not receiving a mail when being unsubscribed, at least looking at the 'email' tag from malone. I'll make one
[17:03] <qense> but aren't there a lot less devs than bug triagers? If we had to adapt our workflow and make it more complicated with a lot of exceptions I don't know if we can work as good as we do now
[17:03] <bdmurray> I think there must be some sort of compromise we can come to help further prevent us from meddling with your bugs.
[17:03] <bdmurray> pochu: let me know the number please
[17:04] <Hobbsee> qense: wouldn't bet on it, when all the devs are effectively bug triagers themselves.
[17:04] <pochu> ScottK: I understand that's not ideal, but neither of the other solutions are either way.
[17:04] <Hobbsee> by team structure, and by function
[17:04] <qense> you've got a point Hobssee
[17:04] <qense> but at lot of people start with helping Ubuntu in the BugSquad
[17:05] <qense> if everything is very complicated there they might be scared away from the project
[17:05] <Hobbsee> if they make things harder for other people, then they need to learn better.
[17:05] <qense> which of course doesn't mean that everyone should do exactly as the bugsquad wants
[17:06] <Hobbsee> qense: at some level, your argument there expands to "the bugsquad members should be able to do whatever they feel is appropriate, no matter what they've read, so they don't get scared away"
[17:06] <ScottK> I think the solution is don't touch stuff you don't understand.
[17:06] <Hobbsee> qense: is that your intention?
[17:06] <qense> no
[17:06] <qense> of course not
[17:06] <ScottK> I don't see what that's so hard.
[17:06] <qense> but if we add x exceptions they mighjt get confused
[17:07] <qense> and mess bug reports up so other people can't find them back
[17:07]  * Hobbsee thought that was covered above.
[17:08] <Hobbsee> [01:44] <pochu> I think it's easier to remember "sync, merge" than "firefox, thunderbird, xorg, xserver, x-x-v-*, ..."
[17:08] <Hobbsee> if the sync, etc, exceptions are confusing, then why allow mozilla and X ones, by your logic?
[17:08] <qense> they aren't very logic in my eyes
[17:09] <qense> we should try to work with as less exceptions as possible
[17:09] <askand> Hello, I have been able to find what causes a bug and know what has to be done to fix it..how can I get that out?
[17:09] <qense> askand: did you report the bug at LP?
[17:09] <Hobbsee> qense: so go tell the ubuntu mozilla guys to change their workflow?
[17:10] <ScottK> IMO if bugsquad people are wandering around setting importance to wishlist on bugs or adding [wishlist] to sync bugs, then there needs to be more emphasis on what they should be usefully doing.
[17:10] <james_w> askand: is this the tracker bug?
[17:10] <askand> ﻿james_w nono completly other bug
[17:10] <qense> I think we should create one workflow standard
[17:10] <bdmurray> ScottK: I'd still like to see some more examples of the things we've done wrong.
[17:10] <greg-g> ScottK: I agree with that
[17:10] <qense> which is 'compatible' with every team
[17:10] <james_w> askand: ah, ok, have you explained what the fix is in the bug report?
[17:11] <ScottK> bdmurray: OK.  I'll tell people to come complain to you about it then.
[17:11] <bdmurray> ScottK: That'd be fine
[17:11] <ScottK> bdmurray: Setting a sync bug to 'wishlist' isn't really wrong.  It's just pointless.
[17:11] <askand> ﻿ james_w: https://bugs.launchpad.net/ubuntu/+source/gmail-notify/+bug/89936 is the bug and it is solved by changning or removing a line in /usr/share/apps/gmail-notify/langs.xml
[17:11] <askand>  
[17:11] <qense> maybe we should make one mailist/tracker to document all confusions/mistakes/complaints and create with the gathered information one workflow for all teams
[17:12] <bdmurray> ScottK: I think that is subjective
[17:12] <ScottK> bdmurray: It doesn't affect any work that's actually done.
[17:13] <james_w> ScottK: developer work, in terms of triaging it may help to make it clear what needs to be worked on.
[17:13] <pochu> does 'to unassign' exist as a verb?
[17:14] <james_w> askand: great, if you can explain what the problem is in the bug report we can probably work to create a patch for that.
[17:14] <james_w> pochu: yes, I think so.
[17:14] <ScottK> james_w: For sync bugs it makes no difference at all.
[17:15] <bdmurray> ScottK: Then why does have them submitted as wishlist?
[17:15] <ScottK> Because they technically are, but the archive-admins process them the same if they are whatever.
[17:15] <bdmurray> s/does/not/
[17:16] <james_w> doesn't requestsync do that?
[17:16] <bdmurray> Okay, but then nobody would think the importance *needs* to be set
[17:16] <ScottK> james_w: It does now.  It didn't until recently.
[17:17] <qense> But do you think one workflow would be possible or are the requirements of different teams to different to get something like that done?
[17:17] <askand> ﻿ james_w: Ok I have now written what has to be done: https://bugs.launchpad.net/ubuntu/+source/gmail-notify/+bug/89936
[17:17] <pochu> Hobbsee: hmm, isn't this Malone bug the same with reassigning a bug to another package? the contacts for the original package won't receive the mail with the change
[17:17] <Hobbsee> pochu: probably
[17:17] <ScottK> qense: Workflow bugs do a lot of things differently to meet the need of that particular workflow.  Trying to shove them into the general bugsquad paradigm is unlikely to really work.
[17:17] <Hobbsee> pochu: er, yes, i think so.
[17:19] <qense> there's a certain contradiction. If a user reports a needpackaging it's treated like a normal bug, but when someone wants package to be imported you've got another workflow, although the required actions are the same
[17:19] <james_w> askand: thanks, I'm looking at it now.
[17:19] <ScottK> qense: The required actions are totally different.
[17:20] <pochu> Hobbsee, bdmurray: bug 229628
[17:20] <qense> both times there needs to be a new package created
[17:20] <qense> and uploaded
[17:20] <ScottK> Also needs packaging bugs have their own workflow involving REVU too.
[17:20] <bdmurray> pochu: thanks
[17:21] <qense> I need to reread all bugsquad documentation I think. It seems like a lot of things have been changed lately
[17:21] <ScottK> qense: No.  In one case a package needs to be made and approved.  In the other the archive-admins need to sync it from Debian.  Totally different work.
[17:21] <qense> are there mails send to the mailist when the bug triaging policy is changed?
[17:22] <james_w> askand: sorry, I don't speak Swedish, is the correction you put in the bug report an appropriate translation for "%(u)d unread message%(s)s"?
[17:23] <qense> maybe the school stuff replaced some Ubuntu stuff in my head and am I the one that's confused ;)
[17:23] <askand> ﻿james_w: yes it works good too, I made a patch for it now
[17:23] <ScottK> qense: The workflow stuff for needs packaging, sync, merge hasn't changed in some time.
[17:23] <qense> ok
[17:23] <thekorn> IMHO the most important question here is: what do the responsible launchpad devs think about workflow bugs?
[17:23] <ScottK> thekorn: I think that's got it backwards.  LP devs should be supporting distro needs, not the reverse.
[17:24] <qense> yeah, I think the best solution would be an adaption/extension of launchpad
[17:24] <ScottK> Good luck with that.
[17:24] <ScottK> What to do in the intervening years?
[17:25] <qense> yeah, that's important now
[17:25] <qense> use things like [merge] in front of bug titles like [apport]?
[17:25] <james_w> askand: can you try changing that line to "%(u)d oläst(a) meddelande%(s)s" please? Does that still make sense?
[17:25] <askand> ﻿james_w: http://FastFreeFileHosting.com/file/5825/gmail-patch.html
[17:25] <qense> that would make those things a lot easier to find for you I suppose
[17:26] <askand> ﻿james_w: No that is the problem..
[17:26] <askand> ﻿james_w: makes no sense :P
[17:26] <thekorn> that's the real issue here: It will take ages to implement necessary features
[17:26] <bdmurray> I think subscription is a non-obvious way to identify these workflow reports right now.
[17:27] <james_w> askand: paste.ubuntu.com is good for passing patches around, it took me a minute to find the download button on that page.
[17:27] <qense> thekorn: I meant to add this manually, not implement it in Launchpad
[17:27] <askand> ﻿james_w: but since the word mail is kind of both plural and singular it should work
[17:27] <askand> ﻿james_w: ah sorry thanks for the tip
[17:27] <james_w> askand: ok, I'll take your word for it.
[17:27] <ScottK> qense: Then there will be a long list to remember.
[17:28] <qense> just [workflow] ?
[17:28] <ScottK> I still don't understand why bugsquad people think they should be marking up bugs they don't understand.
[17:28] <qense> we're  'trained' to make thing easier and clean for the devs
[17:28] <hggdh> ScottK: this is training, or lack of
[17:29] <qense> so they don't have to ask for clarification of a bug report
[17:29] <greg-g> ScottK: my only response to that is the person adding [wishlist] thinks they understand it well enough to add that, thinking it might help in some way
[17:29] <greg-g> ie: there are many levels of "not understanding"
[17:29] <bdmurray> Additionally, making mistakes is a part of learning as far as I know.
[17:29] <ScottK> qense: Then why when devs show up here and say "doing X doesn't help, it's a bother" we get pushback?
[17:30] <ScottK> bdmurray: So far we aren't allowed to even document what they should be doing.
[17:31] <hggdh> ScottK: as far as I can see, the basic problem is your solution is not a solution, but just a hack: "do not touch". This does not help bug triaging (but helps you)
[17:31] <bdmurray> ScottK: I had no problem with documentation but would like to find out what Henrik reverted it before reinstating it.  I also think some tweaking but be done to the workflow report process to make it easier for triagers to identify these.
[17:32] <bdmurray> s/but/could/
[17:32] <ScottK> bdmurray: Unliteral reverts is not a good way to work as a team player.
[17:32] <bdmurray> ScottK: If you've a problem with Henrik why don't you take it up with him?
[17:32] <ScottK> hggdh: It helps them by letting them invest their time in something useful.
[17:32] <qense> people like pedro triage a lot of bugs every day. if they had to check everytime if the subscribers or reporters are devs they'll lose a lot of time
[17:32] <qense> teams and bdmurrays greasemonkey script can help of course
[17:33] <qense> (with teams I mean assigned teams)
[17:33] <ScottK> bdmurray: Because it was you we'd discussed it with, so it seemed to make sense to start with discussing with you again.
[17:33] <qense> but it still can be better for people without greasemonkey
[17:34] <hggdh> ScottK: no, it does not help them. It helps you. This is the problem. We should not have bugtriaging transform itself in a series of exceptions
[17:34] <bdmurray> ScottK: Well, if you want to be a team player why don't send an e-mail to the team mailing list instead of discussing it on IRC.
[17:35] <qense> IRC does allow a directer discussion
[17:35] <james_w> askand: my battery is about to die, but I'll work on that bug once I get home. Thanks for the patch.
[17:35] <ScottK> bdmurray: Because I'm not on the bugsquad mailing list.  With the limited free time I have for Ubuntu I try to concentrate on development tasks.
[17:35] <askand> ﻿ james_w: okok you are welcome
[17:35] <thekorn> Is there an easy way of indentifing workflow bugs right now? a tag? a keyword? something to search for?
[17:36] <qense> thekorn: certain teams assigned
[17:36] <greg-g> subscribed, not assigned
[17:36] <qense> yeah, mistake
[17:36] <bdmurray> thekorn: the script I wrote parses the subscribers for one of half a dozen teams
[17:37] <thekorn> Identifieng a workflow bug by subscribers is not an easy way, in my opinion
[17:37] <qense> I agree with that
[17:37] <hggdh> thekorn: +1
[17:37] <ScottK> It's the most correct solution.
[17:37] <thekorn> it's not easy for new contributors
[17:37] <thekorn> it's not easy to search for
[17:37] <qense> and not everyone can run the greasemonkey plugin
[17:38] <ScottK> So far my sense is a couple of developers showed up and asked for help and got told to pound sand.
[17:38] <qense> if you'd just add [workflow] in the title or warn us in the message that we should triage them things would be easier
[17:38] <ScottK> See you later.
[17:38] <hggdh> I know it is a stupid question, but here it goes anyway. Why cannot them be assigned instead of subscribed?
[17:38] <qense> it probably doesn't fit in their workflow...
[17:38] <bdmurray> hggdh: there are some issues with e-mail
[17:39] <qense> it would indeed give a lot of mail noise
[17:39] <hggdh> so why not title them starting with [workflow] as quense proposed?
[17:39] <thekorn> the best solution for this issue is: ask the devs to use a tag for workflow bugs!!
[17:39] <qense> use tags, warn us in the message or title!
[17:40] <qense> that's the easiest for everyone
[17:40] <hggdh> s/quense/qense/   sorry
[17:40] <qense> :)
[17:41] <qense> I think we do want to help them
[17:41] <hggdh> the point is: with the title indication, all we need to say in the docs is "do not touch '[workflow]... bugs"
[17:41] <hggdh> instead of "do not touch {list, list, list, list, ...}
[17:42] <qense> sorry, dinner
[17:42] <bdmurray> hggdh: I think something like that makes the most sense but we should find out more about their workflows and find out how this would affect them.
[17:43] <thekorn> hggdh, exactly
[17:43] <bdmurray> And I don't think we should make any changes without discussing it with the teams affected.
[17:43] <hggdh> bdmurray: indeed. I am just proposing alternatives. I do not like the way they set it up right now, since it completely disrupts bug triaging flow. We get the brunt of it, they get the best of it
[17:43] <hggdh> collaboration, instead of imposition
[17:46] <bdmurray> Yes, I think having this list of exceptions that affects every package is a bit disruptive and looking at the subscriber's portlet, which is something that isn't normally done, is inconvenient.
[17:46] <bdmurray> and error prone.
[17:46] <hggdh> this could be one proposal on UDS. Not really the better, but at least easy to filter on searchs
[17:47] <bdmurray> I'd still like to see more examples of things we've done wrong.
[17:48] <askand> ﻿There is an update to the fglrx driver in hardy-propesed...anyone knows what it updates to? Is it an update to get me the latest drivers from ati or it does not work that way?
[17:52] <hggdh> bdmurray: I agree, we should have more details. This might as well have been a real triager mistake instead of purposeful messing with dev
[17:55] <pochu> askand: look at the changelog entry
[17:59] <pochu> Hobbsee: can you assign bug 229628 to you, and I'll unassign it so we check if that's still happening?
[18:02] <bdmurray> pochu: You could assign it to me if you need someone to test with
[18:03] <pochu> bdmurray: if you unsubscribe from it I'll do that :)
[18:03] <qense> bdmurray: there wasn't a single response at my email to the bugsquad(https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-May/000840.html) about the collection of data per source package about which we talked a while ago
[18:03] <qense> should we just start or send a better mail?
[18:04] <bdmurray> pochu: done
[18:07] <pochu> bdmurray: ok, assigned to you. Let me know if you receive a message about being subscribed to it in a few minutes
[18:12] <awalton__> jcastro, ping?
[18:15] <awalton__> bdmurray, maybe you can help me. I read on the wiki that upstream developers could join the bugcontrol group so we can more easily triage some of these bugs, is that correct?
[18:16] <greg-g> qense: I don't think you should be stopped from starting a basic overview of the source packages like that (upstream bug tracker, best practices for submitting bugs, known dupes, etc)
[18:16] <pochu> bdmurray: did you get a mail about being assigned to it?
[18:16] <jcastro> awalton__: pong
[18:16] <greg-g> qense: speaking as someone who isn't in charge of anything and only has untested opinions of course :)
[18:16] <qense> :)
[18:16] <awalton__> jcastro, ah there you are. I read on the ubuntu wiki that you were the person to contact about upstream members looking to join bugcontrol
[18:16] <qense> the problem is that there are a lot of packag
[18:17] <jcastro> awalton__: ah excellent, yep, I'm the guy to talk to
[18:17] <qense> so you should create a list (not manually! not manually! noooooo!) and start with the most important
[18:17] <greg-g> qense: of course, which is why you/we/us would start with the major ones first
[18:17] <awalton__> jcastro, glad I found you. I've been working on nautilus for months now wondering how that worked.
[18:17] <awalton__> jcastro, anything special I need to do?
[18:18]  * greg-g waves to jcastro 
[18:18] <bdmurray> pochu: I've gotten the assignment e-mail just now
[18:18] <jcastro> awalton__: give me a second, you will be the first upstream to ask me. :)
[18:18] <jcastro> awalton__: yeah sorry it's not plainly obvious on what to do, we need to fix that
[18:19] <qense> awalton__: now you're here: what's something that nautilus devs require/want to be included in bug reports? we're trying to create lists with this, but the mailists didn't respond to our questions
[18:20] <awalton__> qense, I'm sorry to hear that! we're fighting the tides as best we can at the moment, lots of new activity it seems
[18:20] <qense> I forgive you :P
[18:20] <qense> of course I understand you're busy
[18:20] <awalton__> solid backtraces for crashes is a huge starter, debian has been really bad about that lately and we've been getting terrible traces
[18:21] <qense> you're familiar with apport?
[18:21] <awalton__> only slightly. enough to know it's been giving us wonderful traces.
[18:21] <pochu> bdmurray: great, I'm unassigning you now, let's see if you get a mail about that or not
[18:22] <greg-g> awalton__: thats good to know that it is giving you good data to work with
[18:23] <qense> awalton__: ok, thanks :)
[18:23] <awalton__> qense, seems like that's all I can really think of at the moment. if it's a gvfs-related issue we'd love to see gvfs-bin commands being ran to see if we can differentiate between a nautilus issue and a gvfs issue
[18:24] <awalton__> greg-g, sure has. I think we've caught more from ubuntu backtraces then we have just about anywhere else, at least in my limited experience.
[18:24] <qense> OK, and when we forward bugs upstream, would you like just the LP url and a basic desc or mroe?
[18:24] <awalton__> qense, that should be fine, along with how reproducible the issue is. we seem to get phantom crashes every now and again that nobody can recreate...
[18:25] <qense> ok
[18:25] <jcastro> awalton__: https://wiki.ubuntu.com/UbuntuBugControl
[18:25]  * qense keeps this in mind for the nautilus page
[18:26] <awalton__> jcastro, mhm. I think I've done everything there... my CoC is signed and I've read the bullets a few times.
[18:26] <jcastro> have you applied for the team in launchpad?
[18:26] <awalton__> I don't think I've kept a good record of bugs I've triaged though, I could probably do that.
[18:26] <awalton__> jcastro, haven't done that either :)
[18:26] <jcastro> heh
[18:27] <qense> if you want to, you can subscribe yourself to nautilus bugs
[18:27] <jcastro> a list of at least 5 bugs would be useful.
[18:27] <qense> but that will get you a lot of mail noise I think
[18:27] <awalton__> qense, that I have done
[18:27] <qense> ok
[18:27] <awalton__> I should be able to do that, just a matter of going through them and finding a few good examples.
[18:28] <jcastro> awalton__: ok looks like you just need to make a quick list, then send a mail to bdmurray answering the "Application" questions, and applying for the team on lp.
[18:28] <jcastro> awalton__: feel free to link bugs that you've worked on on gnome bugzilla as well
[18:29] <awalton__> jcastro, ah, that will probably make things easier for me as well, I have better memory of the bugs I've worked on there ;)
[18:29] <awalton__> jcastro, thanks for the help, I'll go ahead and try to get that done today.
[18:30] <jcastro> awalton__: yeah we have a developer summit coming up and we'll be real busy so if you can get it in asap it would be awesome.
[18:31] <jcastro> awalton__: are you part of the gnome bugsquad?
[18:31] <awalton__> jcastro, I don't think so, I joined the regular bugsquad on launchpad but I haven't had a lot of time to figure everything out
[18:31] <awalton__> it's a bit confusing...
[18:32] <qense> is there actually a freedesktop bugsquad? I looked at their website but couldn't find any
[18:32] <jcastro> ok no worries, we'll get it worked out
[18:34] <jcastro> qense: I don't think there is
[18:34] <qense> so the devs handle the bugs all by themselves?
[18:34] <qense> poor devs
[18:34] <jcastro> I don't know how they do it
[18:34] <qense> I think I'm going to send a mail to their mailist to ask how they're handling things
[18:35] <qense> so we can improve the forwarding
[18:37] <pochu> jwendell: hi, does Vinagre work with ipv6 localhost connections, with vino is set to "local connections only" ? I just got this bug in Debian (from a Hardy user): http://bugs.debian.org/480863
[18:37] <qense> ping: bdmurray
[18:37] <jwendell> pochu, there is a bug in vino currently
[18:38] <jwendell> pochu, about ipv6 and localonly
[18:38] <pochu> In the GNOME bugzilla?
[18:38] <bdmurray> qense: hmm?
 bdmurray: there wasn't a single response at my email to the bugsquad(https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-May/000840.html) about the collection of data per source package about which we talked a while ago
 should we just start or send a better mail
[18:38] <qense> what do you think?
[18:38] <pochu> jwendell: ah, this one: http://bugzilla.gnome.org/show_bug.cgi?id=403192
[18:38] <bdmurray> I'd like to think abut it a bit more and will reply to your e-mail
[18:39] <pochu> jwendell: alright, thanks for the info :)
[18:39] <qense> ok
[18:39] <jwendell> pochu, yep
[18:40] <jwendell> pochu, I think we're fix this for 2.24, there's already a patch around...
[18:41] <pochu> cool
[18:43] <bdmurray> pochu: I've gotten e-mail about being unassigned
[18:43] <pochu> Hobbsee: ^
[18:43] <pochu> bdmurray: ok, thanks. I'll close it as invalid then
[18:44] <bdmurray> pochu: the 2nd part might still be vaild
[18:44] <bdmurray> regarding package changes
[18:44] <qense> almost only Ubuntu members in this channel speaking atm(except me)
[18:44] <qense> is everyone here a developer, canonical employee or can you become a member with triaging bugs too?
[18:45] <bdmurray> qense: an Ubuntu member?
[18:45] <qense> yes, you are, pochu is, jwendell is, jcastor is
[18:46] <pochu> Ubuntu member or Canonical employee?
[18:46] <qense> qense> is everyone here a developer or canonical employee, or can you become a member with triaging bugs too?
[18:46] <pochu> jcastor :)
[18:46] <qense> if I'd write it correct I'd ping him, and he's already away for a while
[18:46] <qense> there is no need to get his attention
[18:46] <pochu> that's because 'castor'
[18:47] <pochu> I found it funny :-) http://es.wikipedia.org/wiki/Castor
[18:47] <qense> but is it true that a lot of bug triagers acticve are Ubuntu members?
[18:47] <bdmurray> qense: greg-g is an ubuntu member
[18:47] <greg-g> yep, I am.
[18:47] <greg-g> not a dev either
[18:47] <qense> I thought that bugcontrol was one of the few groups without a lot of members
[18:47] <bdmurray> and not a developer nor a canonical employee
[18:47] <pochu> I'm no Canonical employee, although I'm a MOTU
[18:47] <pochu> bdmurray: what, I thought you were employed by Canonical
[18:48] <greg-g> pochu: he was talking about me
[18:48] <pochu> ah
[18:48] <pochu> heh
[18:49] <qense> are afflux and pedro members?
[18:50] <bdmurray> pedro_ is a Canonical employee
[18:51] <qense> what's his job?
[18:51] <bdmurray> Gnome desktop bug triaging
[18:52] <qense> ok
[18:59] <qense> is thekorn a member?
[19:00] <thekorn> qense, of which team?
[19:01] <qense> ubuntu member
[19:01]  * sectech hasn't given up triaging... I am just busy with moving to a different city
[19:01] <qense> I'm doing a little 'research' on how much people in this channel are ubuntu members
[19:01] <qense> justcurious :)
[19:01]  * sectech isn't a member.... yet
[19:01] <thekorn> qense, no, I'm not
[19:01] <qense> ok
[19:02] <qense> I realized that a lot of people here are member
[19:02] <qense> at least from the active people
[19:09] <qense> bdmurray: I think I've found the cause of ScottKs frustration: https://edge.launchpad.net/hct
[19:09] <qense> it uses Launchpad to keep track of things
[19:09] <qense> so I think it requires a certain way of handling things
[19:11] <greg-g> not sure about that.
[19:11] <james_w> qense: hct isn't active at all any more as far as I know.
[19:11] <qense> oh
[19:11] <qense> my bad
[19:18] <hggdh> qense: I am not a member
[19:18] <sectech> Jeeze some reporters are arrogant...   Could someone please verify bug #228798... The reporter got a bit snappy with me
[19:18] <qense> hggdh: weren't you the one from the real name discussions?
[19:19] <qense> sectech: I"ll ahve a look at it
[19:19] <qense> komputes sounds familiar
[19:20] <qense> I can confirm this
[19:21] <hggdh> qense: yes. This is indeed the reason I never applied for membership
[19:21] <qense> I wouldn't have given him the links but just ask him to clarify what he means
[19:21] <qense> but he did it
[19:21] <sectech> So can I...  I just wasn't able to reproduce it recently
[19:21] <qense> I can confirm it happens in all GNOME save file windows
[19:21] <komputes> qense: quite familiar, I was working on that one today
[19:21] <qense> hello komputes :P
[19:22] <sectech> komputes, hello....
[19:22] <komputes> qense: sectech: hello to you both
[19:22] <sectech> komputes, I didn't mean to offend you with the questions on the bug report...
[19:22] <qense> things sound often a bit rude when you communicate via letters
[19:23] <komputes> sectech: I just thought you may want to try it before copy-pasting simon's, what I call "noob response"
[19:23] <sectech> I do give a general response probing for more information when I see a report that appears fairly vague
[19:23] <qense> but this one isn't really a crasher
[19:23] <qense> it's more a usability request
[19:24] <qense> I'd confirm the bug and mark it as wishlist
[19:24] <qense> it's not a regression
[19:24] <komputes> sectech: the debug instructions are vast, it would be more helpful to point the user towargs what information you are missing
[19:24] <awalton__> also, nautilus has nothing to do with it ;).
[19:24] <komputes> awalton__: really?
[19:24] <qense> isn't this bug in libgnomeui?
[19:24] <awalton__> yes really.
[19:24] <awalton__> it's a bug in gtk+ if anywhere.
[19:24] <sectech> komputes,  I did test it, that's the thing...  I have saw the issue 1000 times before, but I couldn't find an app that would do it recently.
[19:25] <komputes> awalton__: well see you know better than I do.
[19:25] <qense> I filed a bug against this dialog, but choose libgnomeui
[19:25] <pedro_> which dialog?
[19:25] <awalton__> libgnomeui has a gio backend for gtkfilechooser atm, but it will go away in ibex.
[19:25] <pedro_> the file chooser one?
[19:25] <pedro_> that's a gtk+ product
[19:25] <komputes> sectech: yes, I am on 7.10 and since hardy it has been fixed. I did make a mistake by not including the release version in the original post, but I thought I had seen the same issue in 8.04
[19:25] <awalton__> (when we merge gtk+ from trunk-ish)
[19:26] <pedro_> there's no code about that on libgnome*
[19:26] <qense> so atm there are several file dialogs in use?
[19:26] <sectech> komputes,  And that was my major issue... You could have been running Windows XP for all I knew.
[19:26] <awalton__> qense, backends yes.
[19:26] <qense> that's not really good
[19:26] <komputes> sectech: ;) not likely
[19:26] <sectech> of course I would hope that no one would do that.
[19:26] <sectech> haha... you know what I mean
[19:26] <awalton__> qense, it's the only way it could work wrt GnomeVFS
[19:27] <awalton__> qense, with GIO, we will be able to write a filechooser that doesn't have external dependencies, so that whole abstraction will go away.
[19:27] <komputes> qense: thanks for putting it as a wish list for a past release, will take be looked at or simply passed over?
[19:27] <qense> did I put it as wishlist?
[19:27] <qense> what where who
 I'd confirm the bug and mark it as wishlist
[19:27] <qense> oh
[19:27] <qense> :)
[19:28] <komputes> oh you said i would, not i will hehe
[19:28] <qense> well, it's not as bad as this report: bug 182410
[19:28] <qense> I will now
[19:28] <komputes> thx
[19:28] <qense> if sectech doesn't want to do it
[19:28] <komputes> sectech: sorry bout the frustration man
[19:28] <sectech> I am not on bugcontrol yet... just bugsquad... so I actually am a noob komputes  lol
[19:28] <qense> ok, I'll mark it
[19:29] <qense> awalton__: what lib should I assign it to? :)
[19:29] <sectech> komputes,  No problems...   :)
[19:29] <awalton__> qense, gtk+
[19:30] <qense> ok, thx
[19:30] <qense> great to have a GNOME guy here
[19:30] <sectech> Well I'm a noob to bug reports in Ubuntu anyway... I have done SQA testing before..
[19:30] <awalton__> qense, upstream may have a bug on it too, gtkfilechooser component.
[19:30] <qense> I'll check for it
[19:31] <qense> someone marked it as a dup!
[19:31] <pedro_> i did it
[19:31] <qense> ok :P
[19:31] <sectech> qense, I have saw quite a few like 182410.... lol.... I have to decide if I reply to those or not lol.
[19:32] <pedro_> i already told you so, that's a gtk+ bug
[19:32] <qense> yeah?
[19:32] <qense> I should read the chat better
[19:32] <qense> but I'd like Launchpad to warn me if the bug has been changed while I change it
[19:33] <qense> I'll file a bug in LP
[19:33] <pedro_> btw why mark it as wishlist if it's a bug?
[19:33] <pedro_> i mean the importance
[19:33] <pedro_> wishlist should be used for new features
[19:33] <pedro_> not for bugs on existing ones
[19:34] <qense> is it a regression?
[19:35] <sectech> It's fixed in hardy...
[19:35] <sectech> or so it seems
[19:35] <pedro_> regression on gutsy? on hardy works fine
[19:35] <awalton__> it's fixed with gtk+ trunk - 3 days at least :)
[19:35] <sectech> as soon as I don't want it to happen I'll probably be able to get it to occur
[19:36] <pedro_> it seems that federico committed the patch on february
[19:37] <awalton__> was that back during the gtk hackfest then?
[19:40] <pedro_> don't know, but with trunk i haven't had this problem in a few time
[19:41] <qense> it was probably just an issue in gutsy
[19:41] <pedro_> indeed
[19:41] <qense> and before gutsy?
[19:42] <pedro_> maybe, however there's no report indicating that
[19:43] <qense> but I've got at least some more reason to file it as a wishlist! I'm not that bad!
[19:43] <qense> :P
[19:46] <qense> well, I'm going to shut this computer down. gl everyone!
[20:02] <sectech> It's too nice outside to be indoors... back later
[20:05] <ScottK> bdmurray: I did just finish reading the "Incomplete with no response >30 days" thread in the bugsquad archives.  I think you'll have to balance the impact of losing triage volunteers who don't like annoyed comments from developers versus more complex procedures.  I think Henrik's comment "A small group is using the bug tracker in an unorthodox way" is gratuitoiusly and knowingly wrong.  These workflow bugs have existed for years and are part of
[20:05] <ScottK> the standard procedure for a long time.
[20:05] <ScottK> You all can do whatever you like with your procedures.  I'll just let triagers know my opinion when I run into it.
[20:08] <pochu> Is it known that bash-completion is broken in Hardy?
[20:08] <pochu> 'dpkg -L vina<tab>' expands to 'dpkg -L vina^[\[m^[\[K^[\[m^[\[Kgre' here
[20:21] <jwendell> pochu, not here
[22:22] <ffm> Hey, is it possible to mark myself as the bug contact for a package in ubuntu? I'm particullarly fond of the sugar package, and I'm happy to forward upstream etc.
[22:24] <Erosion> Does anyone know if the #Sound bug (here: https://wiki.ubuntu.com/iMacIntel?highlight=%28iMac%29) has been fixed yet?
[22:25] <bdmurray> ffm: yes it is
[22:26] <bdmurray> Do you want to subscribe to the package's bugs?
[22:27] <Erosion> Just wondering if it had been fixed yet
[22:28] <ffm> bdmurray: Ok, how do I go about that?
[22:28] <bdmurray> Erosion: it seems to be fixed in hardy
[22:29] <bdmurray> ffm: https://bugs.launchpad.net/ubuntu/+source/sugar/+subscribe
[22:48] <crimsun> bdmurray: WRT Erosion's question, it's difficult to tell.
[22:48] <crimsun> {s,}he really didn't provide any details.
[22:49] <bdmurray> crimsun: okay, I went off the status of the upstream bug and then what I found in the Ubuntu bug
[22:54] <crimsun> bdmurray: the problem is pretty common for hardware devices; lspci -v rarely reveals sufficient info, and sometimes even lspci -nv is insufficient.  In the case of audio codecs, you need the codec spew (/proc/asound/card*/*codec*)
[22:55] <ffm> If suspend/resume does not work on my hardware, what's the best way to gather all the needed data for others to debug it?
[22:57] <bdmurray> crimsun: the problem being only outputting sound to the headphone jack?
[22:57] <ffm>  (and then file a bug report on it)
[22:57] <crimsun> bdmurray: yes.
[22:58] <greg-g> ffm: https://wiki.ubuntu.com/DebuggingACPI#head-2cb1e3f691b1b47302f5e9f2e4c55db5da6fd60c
[22:59] <crimsun> (there are additional problems, like simultaneous output not being supported, and per-jack output level controls not supported, but those are beyond the scope of the bug)
[22:59] <greg-g> ffm: that is a good start at least
[23:00] <greg-g> ffm: also https://wiki.ubuntu.com/DebuggingKernelSuspend
[23:00] <ffm> Is there some table somewhere where people can put up "this , that, and the other thing work on my hardware, but not _that_"
[23:01] <mrooney> ffm: I thought so, but I don't know where specifically
[23:01] <greg-g> laptop specific: https://wiki.ubuntu.com/LaptopTesting
[23:02] <ffm> greg-g: desktops?
[23:02] <greg-g> ffm: https://wiki.ubuntu.com/HardwareSupport
[23:04] <greg-g> ffm: also, a relatively new project with that as its goal: http://dohickey-project.com/
[23:05] <ffm> greg-g: hm... that's nonfree... but I'll try it.
[23:05] <ffm> (cc-by-sa-nc
[23:06] <greg-g> just the text on the site, the code should be gpl
[23:10] <greg-g> ffm: and not to divert the topic, cc-by-sa-nc doesn't mean you can't use it fro commercial purposes, you just have to ask permission first (CC licenses are non-exclusionary)
[23:12] <persia> greg-g: cc-by-sa-nc means you can't use it for commercial purposes under the cc-by-sa-nc license.  The act of asking permission renegotiates the license.
[23:14] <greg-g> persia: right, you ask for a different license for your specific purpose. which doesn't negate the original license, just you get a special pass basically.  Anyways...........
[23:15] <persia> greg-g: Maybe, but yes, Anyways....
[23:15] <greg-g> :)
[23:24] <secretlondon> well its still non free by all the normal standards
[23:25] <secretlondon> if I have to ask then it's not much different from something under a non-CC license
[23:38] <howapt> Trying to use GParted to shrink my vista partition and use the space for Ubuntu, only problem is... regardless if I sudo in, or su to root, when the program loads it shows keyrings next to the drives, and I cant edit anything
[23:40] <greg-g> secretlondo: yeah, I was just sharing one aspect of CC licenses that some people don't know (how they aren't exclusive) I wasn't really arguing that it was totally free(dom)
[23:41] <secretlondo> well most licenses are non exclusive, many people do seem to think that the non fre Cc licenses are better than they are
[23:41] <greg-g> right
[23:53] <secretlondo> eg I was looking for sounds for tuxpaint, and I came across the Free Sound project, all under a CC license (sampling plus). doesn't allow distribution of unmodified files. Non free by our standards
[23:54] <RAOF> secretlondon: Doesn't allow distribution of _un_modified files?  So not only is it non-free by our standards, it's not distributable by us?
[23:54] <secretlondon> very hard to to find actual free sounds, best there is is wikimedia commons. I've had to make my own tbh
[23:55] <secretlondon> RAOF: I wouldn't touch anything on that site, just giving it as an example of "free" being used to describe non free stuff
[23:55] <secretlondon> just because it's under _a_ creative commons license doesn't mean it's free
[23:55] <RAOF> Yeah.
[23:55] <RAOF> Is there _any_ CC license which is DFSG free?
[23:56] <secretlondon> we have cc-by-sa stuff in debian
[23:56] <secretlondon> whether that breaks debian policy I dunno, I know that debian doesn't like the gfdl either, even without invariant sections
[23:57] <secretlondon> cc-by-sa is the most copyleft of the cc licenses