[00:33] <kermiac> persia: if you're still around, is bug 512454 a better example of what you were talking about in regards to bugs for my bug control application?
[00:33] <ubot4> Launchpad bug 512454 in apt (Ubuntu) "hylax-server is configured before hylafax-client is installed & configured. (affects: 1)" [Low,Fix released] https://launchpad.net/bugs/512454
[00:35] <persia> kermiac: Yes, especially because I remember your work to investigate the different dependency paths required to discover the workaround.
[00:35] <kermiac> ok, thanks persia I'll add that one to the list :)
[00:36] <kermiac> bug 517925 wasn't quite as obscure, but would it be another one that I could use?
[00:36] <ubot4> Launchpad bug 517925 in yelp (Ubuntu) "The help files won't print (affects: 1)" [Low,Fix released] https://launchpad.net/bugs/517925
[00:37] <persia> I'm going to stop giving you reviews of each bug.  I think you should think about what makes a bug well-triaged, and then use that as your criteria: picking good bugs is part of the trick of making a good application :)
[00:37] <kermiac> ok, that's fair enough mate :)
[00:37] <kermiac> thanks for your advice
[00:39] <persia> No problem.  Good luck :)
[00:39] <persia> I think you're doing good work, but I just don't want to undermine the process :)
[00:40] <kermiac> yes, I understand that & didn't really think about it that way. I totally understand :)
[01:29] <malev> persia, are U there?
[01:29] <persia> usually?  Why me?
[01:32] <malev> persia, what should I do to get persissons for change the importance of a bug? why you? because you've answering my questions, and ... I trust you ;)
[01:32] <persia> It's best to ask questions generally.  There's a lot of people who know things, and we all are around different hours.  I'll see if I can dig up the link.
[01:33] <persia> https://wiki.ubuntu.com/UbuntuBugControl
[01:34] <malev> I'm checking! thanks
[01:36] <malev> thanks! I'm not gonna aply right now.. I think I need mor experience. thanks anyway
[01:36] <persia> Yeah :)  Most people who have to ask for the link need more experience, but at least it gives you an idea of what we seek.
[01:36] <persia> But feel free to ask here if you need someone to set importance until you get there.
[01:38] <malev> excelent! as the mather of fact, I need right now:
[01:38] <malev> https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/521350
[01:38] <ubot4> Launchpad bug 521350 in nautilus (Ubuntu) "Emblems on folders disapear after renaming (affects: 2)" [Undecided,Confirmed]
[01:39] <malev> I was thinkig of: low importance :D
[01:39] <persia> OK.  Why "Low" vs. "Wishlist"?
[01:40]  * persia has to step away for a bit, but will be back very shortly and catch up backscroll
[01:40] <malev> Because, I think it is not something that could damage the system
[01:40] <malev> or that could disturb the normal funcions :D
[01:40] <malev> I don't know
[01:43] <Sinani201> If I tell someone that the bug doesn't have information, should I change the status of the bug to Triaged?
[01:45] <Sinani201> ...
[01:46] <persia> malev: https://wiki.ubuntu.com/Bugs/Importance
[01:46] <persia> Sinani201: Which bug are you looking at?
[01:46] <malev> Sinani201, can you set th status to triaged???
[01:47] <persia> Sinani201: Generally we don't like to use "Triaged" until the bug has all the information necessary for a developer to act on it.
[01:47] <Sinani201> OK.
[01:47] <Sinani201> Thanks.
[01:47] <malev> Sinani201, in those cases I set it to incompelte... but it depeds on every case
[01:50] <malev> persia, you're right, I think wishlist is better for the bug ;)
[01:51] <persia> malev: OK.  Next step would be to rephrase the title and description to make it into a feature request rather than a bug report.
[01:51] <virtuald> ok
[01:51] <Sinani201> Persia's bug doesn't look like a wishlist
[01:51] <persia> Then, you'd want to check the bugs in Bugzilla, to find out the bug number where it's already reported (I'm sure there is one), and link to that.
[01:51] <persia> Sinani201: Which bug?
[01:51]  * persia thinks bug #521350 is wishlist
[01:51] <Sinani201> https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/521350
[01:51] <ubot4> Sinani201: Error: Bug #521350 is private.
[01:51] <ubot4> Launchpad bug 521350 in nautilus (Ubuntu) "Emblems on folders disapear after renaming (affects: 2)" [Undecided,Confirmed] https://launchpad.net/bugs/521350
[01:52]  * persia tries to understand how it's "private"
[01:53] <malev> Sinani201, that's the bug I'm talking about. what's up with it?
[01:53] <persia> jpds: The above message seems unexpected and odd.  ubot4 was able to parse it before and after, but not in the middle.  race condition maybe?
[01:54] <persia> Sinani201: Why don't you think that is wishlist?
[01:54] <Sinani201> malev: persia thought that it was a wishlist, and I disagreed.
[01:54] <malev> Sinani201,  why do you disagreed?
[01:54] <Sinani201> Because it's not a feature request... it seems like a bug to me.
[01:55] <Sinani201> File emblems shouldn't be removed just for renaming a file.
[01:55] <jpds> Erm.
[01:55] <persia> Sinani201: It's certainly written as a bug "This doesn't work", but given how nautilus works, it requires a new feature, and could as easily be written "Please track emblems by some means other than file names".
[01:56] <Sinani201> A change like that doesn't really seem like a new feature to me.
[01:56] <jpds> persia: That piece of error is rather... hacky: http://bazaar.launchpad.net/%7Ejpds/ubuntu-bots/bugs-via-launchpad-api/annotate/head%3A/Bugtracker/plugin.py#L595
[01:57] <persia> Sinani201: Well, argue the case for another importance: if you convince me, I'll change it.  Use one of the cases in Bugs/Importance in making your argument.
[01:58] <persia> jpds: heh.  So all sorts of errors end up being "private", do they?
[01:58] <jpds> Probably.
[01:59] <jpds> Purely because I can't do: if bug_data.private:
[01:59] <Sinani201> persia: The bug looks like it is somewhere in between Low and Medium for importance, but I would label it under Low.
[01:59] <persia> Perhaps we could change 601 to be "Bug #%s is unavailable (%s)." %id %${whatever python syntax digs some name out of the exception name} ?
[01:59] <Sinani201> Bugs which affect functionality, but to a lesser  extent than most bugs, examples are:
[01:59] <Sinani201> Ones  that can be easily worked around
[02:00] <persia> OK.  How does it affect functionality?
[02:00] <persia> TO me, it only affects appearance.  Same as "Please make the background green"
[02:01] <Sinani201> I don't know much about emblems because I don't use them, but I think emblems can be used to sort files.
[02:01] <Sinani201> It is much more significant than a user wallpaper.
[02:02] <persia> I don't see a way to sort by emblem in a bit of fiddling with nautilus.
[02:02] <persia> If one could sort by emblem, I'd agree with "Low".
[02:03] <Sinani201> Right now I'm using Windoze so I can't test that functionality.  Are you using Ubuntu?
[02:04] <persia> I am, but I can't sort that way.  Then again, I'm not an advanced nautilus user.
[02:05] <Sinani201> I don't think you can sort. http://www.linuxquestions.org/questions/linux-desktop-74/nautilus-emblem-sort-search-611408/
[02:05] <jpds> persia: I'll look into it.
[02:06] <persia> jpds: Thanks.  Alternately, don't worry about it.  I was just surprised :)
[02:06] <Sinani201> Since there is a workaround to the problem, it should be marked as low, as staded by the almighty Bugs/Importance.
[02:06] <Sinani201> *stated
[02:06] <persia> Except we need to identify some functionality that is affected.  If we can't sort, I think it's just different graphics that appear.
[02:07] <persia> Because if no functionality is affected, it's clearly wishlist.
[02:07] <Sinani201> It affects the functionality of the file explorer.
[02:08] <persia> How?
[02:08] <Sinani201> Or... it affects the functionality of nautilus
[02:08]  * persia is not trying to be obnoxious, but just doesn't understand.
[02:08] <persia> Yes, but how?
[02:09] <Sinani201> Because if I were to rename a file, I don't want my emblem(s) to go away.
[02:09] <persia> Right, but that's a "want".
[02:09] <persia> It still does things the same, it's just a minor display difference.
[02:10] <Sinani201> If a developer were to implement a better emblem system that gixed this problem, would it be considered a new feature, or a fix?
[02:10] <Sinani201> It would be a fix.
[02:10] <persia> I think it would be a feature.
[02:11] <Sinani201> It wouldn't add functionality...
[02:11] <persia> Same as the "fix" to "Nautilus fails to preserve the icon layout for each folder" was to introduce spatial nautilus, which was widely considered a new feature (and some people didn't like it)
[02:11] <persia> Yes it would, because then emblems would be a property of files, rather than filenames, so one could implement things like "sort by emblem".
[02:12] <Sinani201> The fix doesn't have to work like that.
[02:13] <Sinani201> It could just track the file name and then preserve the emblem upon a rename.
[02:13]  * persia knows almost nothing about the internals of nautilus, so is kinda guessing based on the bug and the linuxanswers page
[02:13] <Sinani201> I don't know much either...
[02:13] <persia> That can't work.  nautilus has no way to know if a file is renamed.
[02:14] <persia> Because there are *lots* of ways to rename files.
[02:14] <Sinani201> Errr... this sort of sounds like a stupid question, but what exactly IS nautilus?
[02:14] <Sinani201> Is that the file explorer?
[02:14] <persia> Yeah, and it also provides the desktop, for GNOME.
[02:14] <Sinani201> Oh.
[02:14] <persia> (which is really just displaying some folder)
[02:15] <Sinani201> I have to go.
[02:15] <Sinani201> You could be right about the bug being a feature requset
[02:15] <Sinani201> Bye.
[02:16] <persia> Bye :)  Thanks for the debate: although we didn't come to a conclusion, I think it was a good example of how to think about the difference.  You might even be right about it being a bug :)
[02:17] <persia> malev: But I'm leaving it wishlist because it's your bug, and when I asked you whether it should be "Low" or "Wishlist", you said "Wishlist".  Let me know if your mind was changed by the debate.
[02:20] <malev> persia, wishlist is ok!
[02:20] <malev> I'm triyng to do the next step (that about bugzilla)
[02:21] <persia> Cool.
[02:30] <malev> persia, what do you mean with: " OK.  Next step would be to rephrase the title and description to make it into a feature request rather than a bug report."
[02:31] <persia> malev: Well, it depends on whether you can find the upstream, but ideally the request should be phrased in a way that makes someone want to do it.
[02:32] <persia> So "This is broken" is less inviting than "Please make this work in this way", and similar.
[02:32] <malev> persia, oks! I'm gonna try to think of one :D
[02:34] <kermiac> I'm still trying to get my head around https://wiki.ubuntu.com/Debian/Usertagging
[02:34] <kermiac> I would send an email to
[02:34] <kermiac> control@bugs.debian.org
[02:34] <kermiac> would the following go in the bosy
[02:34] <kermiac> bosy/body
[02:34] <kermiac> user mitch.towner.ubuntu@gmail.com
[02:34] <kermiac> usertag 566621 + patch + origin-ubuntu lucid
[02:35] <kermiac> the wiki isn't quite making sense to me
[02:35] <persia> user ubuntu-devel@lists.ubuntu.com
[02:35] <persia> I'd send "tags: patch" and "usertag: origina-ubuntu lucid"
[02:35] <kermiac> even though i sent the original report using my email address?
[02:36] <persia> Sure.  The point of https://wiki.ubuntu.com/Debian/Usertagging is to track the patches that Ubuntu sends to Debian.
[02:36] <kermiac> ok, I wasn't sure that you could send both "tags" & "user tags"
[02:36] <persia> Yeah, you can send them both.
[02:36] <kermiac> ok, so that helped me undertand that ty :)
[02:36] <persia> Tags: are for everyone, usertags are only by request.
[02:36] <kermiac> would I put anything in the subject line?
[02:37] <persia> "Tagging bug nnnnnn" maybe?
[02:37] <persia> Next time you'll include this when you create the bug, but this time it's less important :)
[02:37] <kermiac> ok, so the subject line will be just that - the subject
[02:37] <persia> That's how it should be.
[02:38] <kermiac> yes, I wan't exactly sure of what I was doing when I sent the original report. Sending bug reports via email seems very foriegn still
[03:29] <Sinani201> Can someone please mark this bug as wishlist? https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/521503
[03:29] <ubot4> Launchpad bug 521503 in indicator-sound (Ubuntu) "Show icon for recording level (affects: 2)" [Undecided,New]
[03:31]  * persia looks
[03:31] <persia> Sinani201: What status?
[03:31] <Sinani201> ?
[03:32] <persia> And I think this is clear enough that it doesn't need brainstorm, but that's a very subjective area :)
[03:32] <persia> Sinani201: For bug 521503: what should be the status when I set it to wishlist?
[03:32] <ubot4> Launchpad bug 521503 in indicator-sound (Ubuntu) "Show icon for recording level (affects: 2)" [Undecided,New] https://launchpad.net/bugs/521503
[03:32] <Sinani201> I think it should be set to triaged.
[03:33] <persia> Sounds good to me.  So set.
[03:33] <Sinani201> Thanks.
[03:33] <persia> Thanks for digging through the bugs.
[04:35] <Sinani201> I think that this bug should be set as 'Wishlist.' https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/521505
[04:35] <ubot4> Launchpad bug 521505 in indicator-sound (Ubuntu) "Show currently selected sink (affects: 1)" [Undecided,New]
[04:35] <persia> What status?
[04:35] <Sinani201> Triaged...
[04:37] <persia> OK.  What do you think about the relation between this and bug 521309?
[04:37] <ubot4> Launchpad bug 521309 in indicator-sound (Ubuntu) "No longer shows sound volume in % (affects: 1)" [Undecided,New] https://launchpad.net/bugs/521309
[04:37] <persia> Or about the status/importance of 521309?
[04:38] <Sinani201> The one I posted has more info... should I set 521309 as duplicate?
[04:38] <persia> I'm not sure.  They are both about the tooltip for indicator-audio
[04:38] <persia> *but* one seems to suggest one thing and the other the other, or I'm confused.
[04:39] <Sinani201> They both want more or less the same thing.
[04:39] <persia> When there's a clear unambivalent feature request (like "Please provide an indicator for audio input"), it's easier :)
[04:40] <persia> So, I think there are two options: 1) make 521505 as duplicate to 521309, and edit description/title to describe a feature-set that addresses both *or* to open an entry on brainstorm and suggest both reporters go discuss it there.
[04:41] <persia> I don't think it can work both ways (if I read it correctly), so we shouldn't push both requests to upstream separately.
[04:41] <Sinani201> Isn't 521309 a duplicate of 521505, rather than the other way around?
[04:41] <persia> I'm just not sure whether it's better to combine them in a bug or in a brainstorm entry.
[04:41] <persia> No, because 521309 came first :)
[04:42] <persia> very rarely we'll do it in the other order, but that's for cases where the master is useful, and the prior report isn't.
[04:42] <Sinani201> OK
[04:42] <persia> In this case, I think they are both equally useful (just text, no need for special attachments).
[04:42] <persia> Anyway, ask for a new status/importance once you sort out which way to want to handle it, and finish massaging the bugs.
[04:43] <Sinani201> I think both of them should go to Brainstorm
[04:44] <persia> It's probably worth creating the summary entry there combining the requests, and then pointing the reporters directly at that.
[04:44] <persia> Otherwise they might create two separate brainstorm ideas which doesn't help the confusion :)
[04:44] <persia> Just note the brainstorm link in the bug comments.
[04:45] <Sinani201> ohhh...
[04:45] <Sinani201> I put the canned response on both,
[04:45] <Sinani201> Whoops...
[04:47] <persia> I like to reserve the canned brainstorm response only for those rambling feature bugs that need lots of work before anyone could even think about implementation.  These are pretty clear, just mixed and and needing some combination.
[04:47] <Sinani201> How do you combine two bugs?
[04:48] <persia> Sinani201: If I were triaging these, I'd have marked the new one as a dup of the old one, and then changed the title and description to request a tooltip that showed the current sink and audio level.
[04:51] <Sinani201> OK, I'll do that.
[05:08] <MTecknology> persia: you're brilliant; just had to say that
[05:11] <Sinani201> ...
[05:11] <Sinani201> bye
[05:11] <persia> MTecknology: Thanks :)
[06:23] <kermiac_> I'm not sure about my new title for bug 520685
[06:23] <ubot4> Launchpad bug 520685 in nautilus (Ubuntu) "Computer short cut in the Places menu does not work (affects: 2)" [Undecided,Confirmed] https://launchpad.net/bugs/520685
[06:23] <kermiac_> opening "Computer" with nautilus fails 1st time after login when using Extra Pane view
[06:23] <kermiac_> is what I came up with
[06:23] <kermiac_> does that sound ok?
[06:55] <kermiac_> please set bug 520685 triaged/low as there are 2 easy workarounds
[06:55] <ubot4> Launchpad bug 520685 in nautilus (Ubuntu) "Opening "Computer" with nautilus fails 1st time after login when using Extra Pane view (affects: 2)" [Undecided,Confirmed] https://launchpad.net/bugs/520685
[07:15] <vish> kermiac_: you need to send that upstream as well
[07:21] <vish> first we need to check if there already is a report upstream
[07:22] <kermiac_> I don't have an account with the gnome tracker yet. I'll set one up & have a look
[07:25] <vish> kermiac_: btw, the description update was pretty impressive :)
[07:26] <kermiac_> ty vish :) It took a while to figure out exactly what the OP was referring to
[07:26] <vish> yeah , i noticed the original description ;)
[07:34] <Kermiac> I searched for "extra pane", "file system", "mounted" & "computer" upstream. That didn't find a match... anything else it might be under?
[07:34] <ddecator> Kermiac, what are you looking for?
[07:35] <Kermiac> Hi ddecator :)   I'm looking to see if bug 520685 has already been reported upstream
[07:35] <ubot4> Launchpad bug 520685 in nautilus (Ubuntu) "Opening "Computer" with nautilus fails 1st time after login when using Extra Pane view (affects: 2)" [Low,Confirmed] https://launchpad.net/bugs/520685
[07:36] <ddecator> that's an oddly specific bug...
[07:37] <Kermiac> yeah, it is now that I updated the description - have a look at the original description. It was a fun one :)
[07:37] <Kermiac> I'm trying to find "obscure bugs" for my application to bug control :)
[07:37] <ddecator> haha, at least it was enough info to know where to start...i like the layout of your update though
[07:37] <ddecator> good idea
[07:37] <ddecator> alright, let me see if i find anything...
[07:38] <Kermiac> ty ddecator - I haven't found anything that seems like this in the upstream tracker. I've gotta go have some dinner, BBL
[07:43] <vish> kermiac_: if you didnt find any earlier reports , we can just add a new report
[07:44] <ddecator> vish, doesn't hurt to look thoroughly, gnome gets enough bug reports to deal with =p
[07:45] <kermiac_> vish: I haven't found any yet. I'm about to have dinner, I'll look at the correct way to file a report upstream soon. Hopefully the interface is easier to use than the debian BTS :)
[07:45] <ddecator> bugzilla is pretty straightforward
[07:45] <kermiac_> that's good to know :)
[07:45] <ddecator> and once you have an account, you can file bugs in b.g.o and b.m.o
[07:46] <kermiac_> I haven't filed an upstream bug report on bugzilla yet. I'll have a look after dinner. BBL
[07:46] <ddecator> alright, enjoy dinner
[07:57] <ddecator> kermiac_, i couldn't find anything, so go ahead and report it upstream
[07:59]  * ddecator is officially a huge fan of Meld
[08:15] <kermiac> I noticed what I was referring to as "extra pane" view is called "split view mode" in the nautilus changelogs. Should I refer to it as "split view mode"
[08:16] <kermiac> nautilus (1:2.29.1-0ubuntu1) lucid; urgency=low
[08:16] <kermiac>   * New upstream version:
[08:16] <kermiac>     - Make browser mode the default
[08:16] <kermiac>     - Add split view mode
[08:16] <ddecator> you could put "aka, split view mode" or something
[08:16] <kermiac> good idea, ty ddecator :)
[08:17] <ddecator> yw kermiac
[08:17] <ddecator> so stack traces are amazing
[08:26] <kermiac> have you had much experience with bugzilla ddecator?
[08:26] <kermiac> or anyone else?
[08:26] <ddecator> a decent amount
[08:26] <ddecator> what's up?
[08:27] <kermiac> just wondering if I should C&P the most important/ relevant info from bug 520685 over to bugzilla
[08:27] <ubot4> Launchpad bug 520685 in nautilus (Ubuntu) "Opening "Computer" with nautilus fails 1st time after login when using Extra Pane view (A.K.A "split view mode") (affects: 2)" [Low,Confirmed] https://launchpad.net/bugs/520685
[08:27] <kermiac> or is there a wiki or something I should read first?
[08:27] <vish> kermiac: your lp description is good , that should do for this bug
[08:28] <kermiac> ty vish :)
[08:28] <ddecator> that's what i usually do. i just say that it was reported on Ubuntu's Launchpad, C&P the details, then say "the full report can be found here: <link>" i've never found a wiki for bugzilla reporting
[08:29] <vish> kermiac: when adding bugs upstream just mention the lp report and add you description.. adding theh lp report helps you get back to the lp bug later ;)
[08:29] <kermiac> ok, that sounds good to me ty ddecator & vish
[08:30] <ddecator> yw kermiac
[08:30] <vish> np..
[08:30] <ddecator> it's good you're getting this experience
[08:31] <kermiac> very true :)
[08:32] <kermiac> would I copy the whole LP bug report (i.e. test case, workaround, etc) or just the initial description of the problem
[08:32] <ddecator> kermiac, you're whole description
[08:32] <ddecator> s/you're/your
[08:32] <kermiac> thanks again :)
[08:33] <ddecator> kermiac, the report will be seen by devs who aren't much different from ubuntu devs, so if you feel it's enough information for an ubuntu dev, then it should be enough for an upstream dev. they can always ask for more info too if they need it
[08:34] <kermiac> I just was mainly wondering what the relationship with gnome devs was like. I have heard of a lot of ppl getting flamed for mentioning ubuntu on the debian BTS
[08:34] <kermiac> I was wondering if I should leave out info regarding the version of ubuntu & such other "ubuntu specific" info
[08:35] <ddecator> nah, leave it in, i've never been flamed for it
[08:35] <vish> kermiac: actually mentioning the lp report also helps us tell upstream we are contributing upstream as well :)
[08:36] <ddecator> gnome and mozilla have good relations with us, especially since a lot of our devs work with them
[08:36] <vish> debian is probably where you *might* get flamed... but just a few of those folks like that ;)
[08:37] <kermiac> ok :)
[08:37] <ddecator> just don't be surprised if a gnome dev says "wontfix," they do a lot just due to the amount of reports they get, and i think they are especially now since gnome 3 is being worked on
[08:43] <kermiac> ok, upstream bug linked to LP bug report. Can someone pls mark it as triaged?
[08:44] <ddecator> i wish i could =/
[08:44] <ddecator> vish, you want the honors?
[08:45] <ddecator> btw, very good report kermiac =)
[08:47]  * ddecator might take a lesson from kermiac's descriptions of reports
[08:50] <ddecator> maybe even tomorrow, i've been meaning to clean up some of my reports
[08:52] <vish> kermiac: done... one thing i would change in the upstream report is : mention the lp link at the top itself
[08:53] <vish> but thats just nit-picking ;p
[08:54] <vish> kermiac: when you plan to send your application for bug control  , you should include bugs such as these
[08:57] <ddecator> ah, is it normal to have a lot of bugs that you've requested info on and never heard back?
[08:59] <vish> ddecator:  it depends on the occurrence and level of user annoyance ;) , recently in the ubuntuone hug day i noticed that almost all the bugs which had requested for additional info were never replied by the OP
[09:00] <ddecator> vish, around half of the bugs i've commented on have never gotten a response from the OP, it's just discouraging that i want to work on the bugs but they didn't include enough info so i can't do anything haha
[09:02] <edakiri> kermiac: i think what you could typically expect from a debian maintainer, and how i would react if i were a debian maintainer, is i would not want a Debian BTS entry on a bug that had been discovered in Ubuntu but not yet been tested and found in Debian.  Possible exception for packages that have no Ubuntu patches, but remember dependencies might have ubuntu patches.  I hate working with the debian BTS anyway.  That is perhaps the largest re
[09:03] <edakiri> Actually, yes: the greatest reason I changed to Ubuntu was Debian BTS versus Launchpad.
[09:16] <kermiac> bah... had a brown-out & had to reset the router
[09:18] <edakiri> kermiac: then maybe you missed my message, so i will repeat
[09:18] <kermiac> I think I got about half of it, lol
[09:18] <edakiri> kermiac: i think what you could typically expect from a debian maintainer, and how i would react if i were a debian maintainer, is i would not want a Debian BTS entry on a bug that had been discovered in Ubuntu but not yet been tested and found in Debian.  Possible exception for packages that have no Ubuntu patches, but remember dependencies might have ubuntu patches.  I hate working with the debian BTS anyway.  That is perhaps the largest re
[09:18] <edakiri> Actually, yes: the greatest reason I changed to Ubuntu was Debian BTS versus Launchpad.
[09:19] <kermiac> yes, ty edakiri i didn't get the second half. I have only used the debian BTS a couple of times & it is taking a lot of reading to try & get used to
[09:20] <kermiac> ty for marking 520685 triaged vish:)
[09:31] <ddecator> anyone here work with pulse or alsa bugs?
[09:32] <vish> ddecator: that would be crim_sun  , if you have doubts you can ask him
[09:32] <kermiac> i do sometimes, although I'm still learning.
[09:32] <kermiac> yeah - he's the guy to talk to :)
[09:33] <kermiac> if it's not too hard I might be able to help. bug #?
[09:34] <ddecator> vish, yah he made a comment on a bug i assigned to pulse, asking them to run 'apport-collect -p alsa-base <bug>', but i don't think the person did, it looks like the OP just set the status back to "new" without actually doing anything, but idk what information should have been added to the report
[09:34] <ddecator> bug 518492
[09:34] <ubot4> Launchpad bug 518492 in pulseaudio (Ubuntu) "after upgrading to 9.10 i am not able hear sounds while i use the players (affects: 1)" [Undecided,New] https://launchpad.net/bugs/518492
[09:35] <nigelb> ddecator, apport not re-run there
[09:35] <vish> ddecator: the user might not have understood the previous comment , try again..
[09:35] <nigelb> he's just set back to new
[09:35] <kermiac> yeah, you need more info
[09:35] <ddecator> nigelb, that's what i thought
[09:35] <vish> ddecator: there is a stock responce "collect it" use it
[09:36] <nigelb> ddecator, set back to incomplete and ask Op to run collect it in terminal or alt + f2
[09:36] <kermiac> if got a "sound" one
[09:36] <kermiac> if/I've
[09:36] <nigelb> vish, need your suggestions on bug 518910
[09:36] <ubot4> Launchpad bug 518910 in evolution (Ubuntu) (and 1 other project) "intermittent mail notifications. (affects: 1)" [Low,Incomplete] https://launchpad.net/bugs/518910
[09:36] <nigelb> its the one I talked to yday about
[09:37] <kermiac> http://ubuntu.pastebin.com/f4dddbcad
[09:38] <ddecator> ty nigelb and vish
[09:39] <nigelb> np
[09:42] <vish> nigelb: not sure what the problem there is ? but even the evolution[Ubuntu] task needs to be changed to evolution-indicator
[09:42] <vish> nigelb: i know only where the bug needs to go ;p
[09:43] <nigelb> vish, I was about to close evolution task as invalid
[09:43] <kermiac> ddecator: we usually change "BUGNUMBER" to the actual bug number in the response to avoid confusing the OP. Hopefully it doesn't matter as you added "where BUGNUMBER is the number of the bug you have reported (in this case, 518492)"
[09:43] <nigelb> now, I'm lost as to what to do.  Just leave it there and wait for some to take care of it or poke someone
[09:43] <vish> nigelb: nah... ask him to also mention which version of evolution-indicator he is using
[09:44] <ddecator> kermiac, i started to do that, but i didn't want the person to potentially reuse the exact command i put in there for a different bug, so i thought that might be more clear
[09:44] <nigelb> vish, "I've changed the package to evolution-indicator, which seems to be the root of the issue here.  Please also report the version of evolution-indicator that you have installed so that someone can take a look at this."
[09:45] <vish> nigelb: sounds right
[09:46] <kermiac> I don't think I follow exactly what you mean ddecator, but like I said it shouldn't matter in this case as you added another comment to the end
[09:47] <vish> ddecator: are you using firefox and lp improvements extension?
[09:47] <ddecator> vish, yes
[09:48] <vish> ddecator: then there is a sock reply "collect it" just use that , it is pretty descriptive
[09:48] <vish> stock*
[09:48] <nigelb> lol
[09:48] <ddecator> vish, yah i just noticed all of those links...
[09:52] <edakiri> as far as motivations for switches, KDE4 was the reason I switched to Gnome.
[09:52] <ddecator> wow, how did i never pay attention to all of those links sitting there ready to do the work for me? -_-
[09:53] <edakiri> where do you get the extension?  it has the links?
[09:53] <ddecator> it's in the repos, let me find the package name...
[09:54] <ddecator> firefox-lp-improvements
[09:54] <nigelb> I dont think its there in the repos.  its a ppa
[09:54] <nigelb> at least for karmic
[09:55] <edakiri> i'm on lucid since import freeze.  it has been tolerable for main system use.
[09:56] <ddecator> oh yah, you're right (sorry, it's almost 4am here so i'm a little out of it, haha)
[09:57] <ddecator> gm-dev-launchpad ppa according to my software sources
[09:57] <nigelb> here you go https://launchpad.net/~gm-dev-launchpad/+archive/ppa
[09:57] <nigelb> add hte ppa to your sources, update sources, and install
[09:57] <ddecator> perfect, and on that note, i obviously need some sleep...night all
[11:40] <_Narc_> Hello everyone. I'm learning to triage, I apologize for the dumb question but how come bugs that are already affected to a package still show up in a search for "homeless" bugs ?
[11:43] <kermiac> hi _Narc_ do you have an example?
[11:45] <_Narc_> Hi kermiac. Yes, bug #521293 for example. It's affected to four packages and it shows up when I do a search for no-packages bugs using this link I found on the BugSquad wiki (https://bugs.edge.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-datecreated&search=Search&field.status%3Alist=New&field.assignee=&field.owner=&field.omit_dupes=on&field.has_patch=&field.has_no_package=on)
[11:45] <ubot4> Launchpad bug 521293 in opensuse (and 3 other projects) "fsck destroys data on interruption (affects: 1)" [Undecided,New] https://launchpad.net/bugs/521293
[11:48] <kermiac> I think the list of "homeless" bugs isn't updated in real time. It takes a while (unsure how long) to update. This bug was only filed yesterday. Maybe someone else here can has more insight into this issue than me
[11:48] <David-T> _Narc_: it affects 4 projects, not packages...
[11:49] <kermiac> ty David-T - that's a better explanantion
[11:49] <kermiac> night all
[11:50] <_Narc_> David-T: Ok, thanks. So they're not the same and a package can be affected to a project and still be considered homeless.
[11:52] <David-T> _Narc_: a bug can affect a project and still be homeless, yes.
[11:54] <_Narc_> David-T: Ok, thanks. I'm still learning, sorry. :)
[12:01] <David-T> don't worry, so am i...
[15:15] <l3on> Hi all...
[15:15] <l3on> someone of you can confirm me that bug  515105 is invalid
[15:15] <l3on> ?
[15:15] <ubot4> Launchpad bug 515105 in sdl-image1.2 (Ubuntu) "sudo apt-get install vlc vlc-plugin-pulse mozilla-plugin-vlc, error 'libsdl_image1.2' (affects: 1)" [Undecided,New] https://launchpad.net/bugs/515105
[15:16] <BUGabundo> 64bits?
[15:18] <l3on> Title: package libsdl-image1.2-dev (not installed) failed to install/upgrade: trying to overwrite '/usr/include/SDL/SDL_image.h', which is also in package sdl-image-devel 0:1.2.10-2
[15:21] <persia> The title is clearly invalid.  The problem report seems to also indicate some issue with libsdl-image1.2 and libsdl-image1.2-devl
[16:12] <jibel> l3on, Hello. Thank you for your help on triaging.
[16:12] <jibel> l3on, Just a remark, your comment on this report is  a bit rude. Please add some courtesy, please, thank you, ...
[16:12] <jibel> l3on, You'll find standard responses to help you at https://wiki.ubuntu.com/Bugs/Responses
[16:19] <l3on> jibel: thanks... I'll read it :)
[16:24] <jibel> l3on, you're welcome
[16:29] <bcurtiswx> micahg: im still under the impression that fix-committed can still include that fixes have made it upstream..
[16:30] <micahg> bcurtiswx: only on an upstream task
[16:30] <micahg> https://wiki.ubuntu.com/Bugs/Status
[16:30] <micahg> bcurtiswx: you're not the only one to do this though
[16:30] <micahg> I think we need to clarify/emphasize the policy
[16:30] <qense> micahg: agreed
[16:31] <qense> Not all people seem to understand that well enough.
[16:31] <micahg> in fact it was confusing before, so I had bdmurray separate the ubuntu/upstream tasks in wiki status page
[16:31] <micahg> s/had/asked :)
[16:31] <bcurtiswx> hmm.. I think I was trained the way I've done it... <shrugs>
[16:33] <qense> micahg: It would indeed be good to add a clear notice to that page that briefly explains the difference.
[16:33] <bcurtiswx> micahg: a lot of things in bug triage still are "take it how you see it"..
[16:33] <micahg> qense: the page is pretty clear IMHO
[16:33] <micahg> I just don't know how many people have read it :P
[16:33] <qense> that is indeed the main problem
[16:34] <qense> people don't read the documentation (properly)
[16:34] <bcurtiswx> micahg: not entirely.  the 2nd section for upstream bug tasks in "fix-committed" could be taken that "if the upstream task is...etc...., then the bug can be fix-committed"
[16:45] <micahg> bcurtiswx: I don't see how
[16:45] <micahg> they are clearly labeled ubuntu task and upstream task
[16:46] <bcurtiswx> micahg: we each see things differently.  Which is why constructive criticism is needed while triaging
[16:46] <micahg> :)
[17:01] <BUGabundo> FYI in case anyone wants to confirm/SUB. I've sent it upstream https://bugs.launchpad.net/ubuntu/+bug/521767
[17:01] <ubot4> Launchpad bug 521767 in nautilus (Ubuntu) (and 1 other project) "[lucid] its no longer possible to use alt+NUMs to change between nautilus tabs (affects: 1)" [Undecided,New]
[17:14] <BUGabundo> can some one mark as wishbug https://bugs.edge.launchpad.net/ubuntu/+source/zsync/+bug/521782
[17:14] <BUGabundo> thanks
[17:14] <ubot4> Launchpad bug 521782 in zsync (Ubuntu) "[wishbug] zsync should run ioniced (affects: 1)" [Undecided,New]
[17:15] <hggdh> oh BUGabundo, quousque tandem abutere patientia nostra?
[17:15] <hggdh> apply to -control!
[17:15] <hggdh> :-)
[17:16] <micahg> hggdh: did you catch the earlier bit about the fix committed status?
[17:16] <hggdh> micahg: no, just logged in
[17:17] <BUGabundo> hggdh: n me baralhes mais a cabeça, hablando en espanol
[17:20] <hggdh> BUGabundo: ora, é latin!
[17:21] <micahg> hggdh: http://irclogs.ubuntu.com/2010/02/14/%23ubuntu-bugs.txt from 16:29 to 16:46
[17:22] <hggdh> micahg: (1) thank you; (2) yes, we have discussed this on and off for some years now ;-)
[17:23] <hggdh> except for some teams, fix committed is to be used when the fix has landed in bzr or -proposed
[17:23] <hggdh> for desktop-team, for example, it is used for when a fix lands in the upstream repository
[17:24]  * hggdh gotta go, be back in about 2 hours
[17:52] <persia> micahg: There seems to be wide consensus that "Fix Committed" is only meaningful in a VCS context.
[17:52] <persia> micahg: However, some teams happen to maintain packages in Ubuntu in VCS, which means they have a use for them, and other teams don't, which means it's useless.
[17:53] <persia> My personal opinion is that we need better hints to determine which packages are VCS-maintained, so we have a way to determine when "Fix Committed" is useful or appropriate.
[18:07] <micahg> persia: fix committed for Ubuntu is usually if in -proposed or Ubuntu VCS
[18:07] <persia> Right.
[18:07] <micahg> according to the Wiki
[18:07] <micahg> but the Desktop team uses it for upstream VCS commits
[18:08] <micahg> which confuses triagers
[18:08] <persia> Well, the Desktop team tracks upstream VCS closely.
[18:08] <persia> So Ubuntu VCS is derived from upstream VCS every week or two (depending), and it's sure that anything in upstream VCS will be included in Ubuntu.
[18:08] <micahg> right, but the upstream task being fix released means upstream task is in VCS
[18:09] <persia> The bit that's missing is some way to identify the inheritance paths so that we can know that a given commit is in the right place to be sure to arrive in Ubuntu.
[18:09] <persia> Well, that's dependent on the upstream.  In my mind, a responsible upstream differentiates Fix Committed and Fix Released.
[18:10] <persia> But that gets into the discussion "What does "released" mean?
[18:10]  * persia thinks it's all hopelessly compiicated, and too hard to jam into a single model that works for everyone.
[18:11]  * BUGabundo thinks release means its on +1 archive
[18:12] <BUGabundo> or at least on the repo where it means to fix something
[18:12] <persia> Does it?  Does it mean that upstream released a tarball?  Does it mean that the code has been released to the world?
[18:12]  * persia thinks the answer depends on the individual project
[18:13] <micahg> fix released upstream should mean released a tarball if it's manual
[18:13] <persia> For *Ubuntu*, I agree that "Fix Released" means "A fixed package is in the development repository".
[18:13] <persia> micahg: Some upstreams don't have tarballs though :)
[18:13] <micahg> but if it's automatic, most upstreams use fix released when it hits the VCS
[18:13] <BUGabundo> are we discussing Ubuntu Bugs or LP projects bugs?
[18:14] <BUGabundo> 'cause I stand by my statement for Ubuntu bug
[18:14] <micahg> Ubuntu Bugs
[18:14] <BUGabundo> as for other LP projects, each may need its own interpetentain
[18:14] <BUGabundo> well then, we all agree... no more rambling :D
[18:15]  * BUGabundo goes back to feed catching up
[18:15] <persia> BUGabundo: We're discussing the complications of bug fixes travelling between different places.
[18:15] <BUGabundo> from Upstream BTS to LP ?
[18:15] <persia> Specifically, that the Desktop team uses the "Fix Committed" status in the Ubuntu task to indicate when a fix was committed to upstream VCS.
[18:49] <qense> persia: maybe something for the next Bug Squad meeting?
[18:52] <persia> qense: I don't think so: we've been discussing it for many years without conclusion already :)
[18:52] <persia> Maybe something for a Desktop Team meeting, I'd think.
[18:52] <qense> persia: yeah, in that case the Desktop Team would be the right team to bug.
[18:52] <qense> Do you think they'd agree?
[18:54] <persia> Not unless a new compelling argument was presented.
[18:54] <qense> Why don't they agree then?
[18:54] <persia> Simply being in line with everyone else doesn't seem to be enough.
[18:54] <persia> Because they've always done it that way, and don't see any reason to change.
[18:54] <qense> That means an important part of the bugs we handle should be handled differently. :S
[18:55] <qense> I thought it was the Bug Control/QA team that was responsible for determining the bug workflow.
[18:55] <thekorn> unfortunatly not ;)
[18:55] <qense> Isn't the upstream task enough for them?
[18:56] <persia> qense: It is, but there was a big gap for a few releases where this team was basically dysfunctional, and practices drifted during that time.
[18:56] <qense> So now we have both the MOTU and the DesktopTeam using their own work-flow?
[18:57] <thekorn> the hard part is to change existing team workflows
[18:57] <qense> the hard part for us is to make new triagers accustomed to all those different processes. ;)
[18:57] <thekorn> instead of changing them we should have per package/per project bug status/importance explainations in the LP UI (maybe as tooltips)
[18:57] <persia> What part of MOTU workflow differs?
[18:58] <thekorn> or some kind of bug triaging guidelines
[18:58] <syn-ack> hi kicks
[18:58] <syn-ack> kids too
[18:58] <thekorn> like we have bug reporting guidelines
[18:58] <qense> persia: a while ago we were basically told to not do anything with packaging/MOTU bugs anymore.
[18:58] <qense> there were some 'arguments' about several bug reports where bug triagers had changed the status
[18:58] <persia> That discussion got out of hand :(
[18:58] <qense> yeah, quite
[18:59]  * persia hunts for the relevant bug
[18:59] <qense> so in the end we basically left it like it was before. Which was not the best solution, imho
[19:00] <persia> bug #179857
[19:00] <ubot4> Launchpad bug 179857 in malone "Package sponsorships involve awkward bugtracker machinations (dups: 1)" [Low,Triaged] https://launchpad.net/bugs/179857
[19:00] <persia> But that applies to *all* development groups, not just MOTU
[19:01] <qense> true
[19:01] <persia> The issue is that there isn't any good way to track sponsorship requests, so bug statuses are (incorrectly) abused to address this.
[19:01] <persia> I tried to set the documentation for managing these to be something close to that used for regular bug triage, but it doesn't fit perfectly, unfortunately.
[19:02] <qense> yeah
[19:02] <qense> Our lives would be a lot easier if everything would be using the statuses the same way.
[19:02] <persia> Indeed.
[19:02] <persia> dholbach has been working on the sponsoring workflow with an out-of-launchpad tool, and so some of this may become less bad in the future.
[19:03] <persia> But for now, it's just awkward :(
[19:03] <qense> Importance: Low :S
[19:03] <persia> On the other hand, please don't blame this on MOTU: it applies to all the developer groups (although the non-MOTU groups tend not to be as good about sponsoring stuff).
[19:04] <qense> agreed
[19:07] <qense> MOTU has to make do with what it's got, and they're doing that well considering the tools.
[19:07] <persia> qense: If you have any suggestions on how the workflow for sponsoring requests or sync requests could be improved to be more in line with regular bug triage workflow, I'd be happy to help promote implementation of the ideas.
[19:09] <qense> persia: If I find something I surely will.
[23:43] <kamalmostafa> bugcontrol please:  I request bug 518314 be set to importance [High] since it is severe if its true (but leave status "Incomplete" since I can't reproduce it and have asked submitter for more information).
[23:43] <ubot4> Launchpad bug 518314 in eglibc (Ubuntu) "strcmp crashes (affects: 1)" [Undecided,Incomplete] https://launchpad.net/bugs/518314
[23:54] <hggdh> kamalmostafa: I am not sure this is a high -- I agree it was the potential, but we need more data to raise it
[23:55] <Sinani201> I agree… it isn't that bad
[23:57] <hggdh> at least not yet ;-)
[23:58] <kamalmostafa> hggdh, Sinani201: my thinking is actually that it seems very unlikely to be "real" -- my hope is to raise its visibility to get a few more folks to test it (since I'm not calling it "Invalid" just because I can't reproduce it).   I have no objection to it remaining "Undecided" importance, but I'm not sure how we will ever "decide".  :-)
[23:59] <hggdh> well, usually, we set Medium to incomplete bugs
[23:59] <hggdh> Will do that
[23:59] <Sinani201> I agree.