[05:56] <bliZZardz> Hi, w.r.t Bug#162658 - the user has preferred to drop the bug report - in these cases, what is the preferred course of action? Shall i move it to 'Invalid' ?
[05:57] <mrooney> bug #162658
[05:58] <mrooney> bliZZardz: yes, Invalid, if you are sure that is his intent
[06:01] <mrooney> bliZZardz: in that case I would always say something like, "I am marking this as Invalid as per your request, if you can duplicate it or come up with more information, please feel free to re-open the bug."
[06:01] <persia> bliZZardz: Note that if you can reproduce, and understand the bug, and disagree, you can take it over, and make it good: but this is likely rare in those cases.
[06:07] <bliZZardz> mrooney : sorry , saw your comment late - but have done something similar. You may kindly look into it
[06:07] <bliZZardz> persia : that is what i try first - but here there was no information at all
[06:10] <bliZZardz> mrooney, is it the same (Invalidating the bug) for places wherein an older version is being used - and the bug being quoted is actually a feature in the newer release?
[06:14] <mrooney> bliZZardz: hm, can you give a real example? if someone is using an out-of-date version of something the bug is Invalid anyway, or Incomplete if they are going to test with an up to date version, I believe
[06:15] <mrooney> I look at it as, Incomplete: I need more information to decide what the issue is / if this is an issue in the package, Invalid: the report is not applicable to the package for one of many reasons, WontFix: the report is applicable to the current package, ie it accurately describes behavior, but it won't be changed
[06:16] <mrooney> however WontFix and Invalid can be confusing, I am not sure what to do if the thing which they say is a bug is explicitly a feature and intended
[06:17] <persia> When it's explicitly intended to be that way, it's "Won't Fix".
[06:17] <mrooney> that makes sense
[06:17] <mrooney> but for extreme cases Invalid seems more semantically logical
[06:18] <bliZZardz> w.r.t bug #119958
[06:18] <mrooney> like if someone filed a bug "pidgin connects to networks successfully" and in the description says they do not want pidgin to actually connect to networks but instead show errors
[06:18] <mrooney> obviously that is absurd but, to me that makes more sense as Invalid, as the use case is Invalid
[06:19] <bliZZardz> mrooney : probably what you just said can be put as a FAQ in the wiki (or is it already there?)
[06:19] <mrooney> there is a guide for importances and statuses
[06:19] <mrooney> https://wiki.ubuntu.com/Bugs/Status
[06:19] <bliZZardz> got it - thanks
[07:39] <bliZZardz> a variant of my Q : If a bug is confirmed upstream , and it is to be released as a 'feature' in the upstream release - then should the status of the Bug be changed to 'Confirmed' in LP? (The upstream guy denies this as a bug, and says that the fix is already present in the upstream trunk and does not want to track it with a Bug# in his tracker)
[07:41] <Hobbsee> bliZZardz: then set it to fix committed, as the fix exists, but isn't in ubuntu.
[09:00] <afflux> morning
[09:00] <thekorn> hello afflux
[09:08] <qense> hello
[09:10] <techno_freak> hi
[12:54] <bliZZardz> how can i reassign a bug to a diff project (if it wasnt assigned properly before) - does this require privileges?
[12:54] <bliZZardz> (eg.Bug #91845)
[13:58] <askand> bug 38512 is fixed upstream
[14:07] <sectech> mornin mornin
[14:09] <techno_freak> hi
[14:12] <askand> bug 213367 should now be fixable since libiptcdata has been promoted to main
[16:02] <mcas> hiho
[16:08] <bddebian> Boo
[16:11] <LaserJock> ahhhhhhhhhhh! <--- delayed reaction
[16:11] <bddebian> heh, heya LaserJock
[16:11] <LaserJock> hi Barry
[16:22] <mcas> hi
[16:22] <mcas> i want to help the bugsquad
[16:23] <mcas> how can i help
[16:23] <persia> mcas: Have you read the HelpingWithBugs page?
[16:23] <mcas> yes
[16:24] <mcas> i am already doing some bug triage
[16:24] <persia> Excellent.  That's the best way to help bugsquad, as triage is most of what we do.
[16:25] <persia> That said, if you have the time and interest, and want to either adopt a package or fix a bug, that works too :)
[16:25] <norsetto> AHHHHHHHHHHH! <--- very delayed reaction
[16:26] <persia> norsetto: You might want to recondition your synapses: with that sort of flight/fight response, you're likely to get run over at the next Zebra crossing.
[16:27] <norsetto> LaserJock: 1/2 of 5 is 2.5 (or so I hear), so , what half of me should I consider?
[16:27] <norsetto> persia: its an advantage when you die, it takes time for your brain to understand that
[16:27] <persia> mcas: also, if you're short on bugs, #ubuntu-bugs-announce reports all the new ones (well, right now there's a bug that reports the new ones AND the recently updated ones, but usually)
[16:27] <LaserJock> norsetto: well, obviously we'd have to figure something out ;-)
[16:27] <persia> norsetto: Ah.  Good point.  You'll actually be able to enjoy being mellow when you're dead :)
[16:28] <LaserJock> norsetto: although maybe we can do a left-brain/right-brain trick :-)
[16:28] <norsetto> LaserJock: ah, a vertical split, didn't consider that :-)
[16:29] <mcas> ok thx persia
[16:47] <torkiano> hello all, can anyone help me with bug 244754
[16:47] <torkiano> ?
[16:56] <torkiano> Can anyone mark bug 244754 as triaged?
[17:17] <Zelut> my sound is broken in intrepid alpha1.  what information is required for that type of bug report?
[17:26] <jonpackard> Zelut: in terminal do "sudo lspci -v > lspci.txt"
[17:26] <jonpackard> this will give information about your pci devices.. if you have a usb sound device.. change lspci to lsusb
[17:26] <james_w> hi Zelut. Please see https://wiki.ubuntu.com/DebuggingSoundProblems
[17:32] <Zelut> thanks
[17:47] <thekorn_> bdmurray, maybe I should have checked before: from your point of view is it ok when I merge the intrepid.merge branch into the main one of py-lp-bugs today?
[17:48] <bdmurray> thekorn_: are you saying you've done it already?
[17:49] <thekorn_> bdmurray, no
[17:50] <thekorn_> but I would like to do it as soon as possible,
[17:51] <bdmurray> right, doing it soon makes sense to me but I'd like to review the changes again
[17:52] <thekorn_> bdmurray, ok
[18:09] <Zelut> might the lack of a linux-ubuntu-modules package for the intrepid kernel be a reason behind my lack of sound?
[18:15] <askand> bug 213367 should now be fixable since libiptcdata has been promoted to main :)
[18:16] <seb128> askand: you already said that some hours ago I think, better to add a comment on the bug than on irc, bug triagers don't do uploads usually
[18:18] <askand> seb128: ah ok thanks
[19:12] <Vegar> what are the chances of the latest version of pidgin entering hardy? (see http://developer.pidgin.im/ticket/6220 - ICQ reports that "client is too old")
[19:22] <james_w> Vegar: I believe it is already in -proposed. If you want to help then please test those packages and report your results to the Ubuntu bug report
[19:22] <Vegar> oh, ok
[19:23] <Vegar> I'll check that out, thanks
[19:59] <bdmurray> thekorn: I think merging it would be fine, just be sure to increment the changelog appropriately
[20:03] <thekorn> bdmurray, ok, cool, what do you think 0.2.35 or should we go with as 0.3
[20:09] <bdmurray> thekorn: i think 0.3 is appropriate based on the scope of changes
[20:09] <thekorn> I agree,
[20:10] <thekorn> so I will start with the merge in a bit, but writing the changelog will take a bit
[20:12] <walters> is there a way i can see stack traces collected by apport?
[20:12] <walters> an ubuntu user is reporting dbus crashes, i assume apport should have picked them up and submitted them, is there a way I as a DBus developer can access those?
[20:13] <pochu> walters: apport crashes are reported as private bugs, so either you need to be in ~ubuntu-qa or the bugs need to be marked as public
[20:13] <bdmurray> walters: do you know what release of Ubuntu they are experiencing them with?
[20:13] <walters> 8.04
[20:14] <pochu> hmm, I misunderstood the question
[20:14] <pochu>  /etc/default/apport, enabled=1 should enable apport so he can erport it to Launchpad
[20:15] <pochu> or so that the crash file is created in /var/crash/
[20:15] <seb128> pochu: I don't think that's the question
[20:15] <bdmurray> in stable releases apport is disabled by default that is why this is necessary
[20:16] <walters> pochu: yeah i could (just did actually) ask him to look in /var/crash, but i'd like to access the crash data from the 99% of people who won't join #dbus IRC and ask about it
[20:16] <seb128> walters: https://launchpad.net/ubuntu/+source/dbus/+bugs
[20:17] <walters> seb128: ahh that is helpful, thanks!
[20:17] <seb128> walters: the title which have SIGSEGV are usually crashes sent using apport, they are not always retraced correctly though
[20:17] <walters> perfect, yep
[20:17] <bdmurray> Some of the bug reports are private though as pochu mentioned
[20:17] <seb128> walters: the ones which have a lock are still private, either because they have sensible informations or because nobody reviewed those yet
[20:18] <pochu> but he won't see them, so he won't see the lock, right?
[20:18] <pochu> there are 2 private bugs in dbus
[20:18] <bdmurray> walters: As an upstream developer we can get you added to the team that has access to the private reports
[20:18] <seb128> as you can see looking at the list we apparently lack somebody being actively triaging those
[20:19] <snap-l> Vegar: BTW: ICQ is causing a lot of other clients fits.
[20:21] <seb128> walters: and as said before by other people apport is disabled by default on stable versions for different reasons so users need to enable apport in /etc/default/apport to get crashes collected
[20:22] <walters> seb128: ohh, hm i didn't know that
[20:22] <walters> why is it disabled?
[20:22] <seb128> mainly because the user experience is not really good, the program which crashes is frozen during the time apport is collecting the dump and informations
[20:23] <walters> bdmurray: that would be helpful, though i'm not the only developer; maybe think about some process which can feed these back into bugs.freedesktop.org or more general whatever the upstream tracker is
[20:23] <seb128> which can easily be 30 seconds when you use evolution or firefox for example
[20:23] <walters> ah, that seems fairly fixable
[20:23] <seb128> and also because stable users mostly run into crashes which have been reported during the unstable cycle
[20:23] <seb128> so we get 95% duplicates and lot of extra work and trouble for users for no real win
[20:25] <bdmurray> walters: we do generally work on forwarding bugs to the appropriate upstream when we determine that the bug is not ubuntu specific and valid
[20:26] <seb128> walters: the "send back upstream" works quite fine for packages which are actively maintained, we do a good job on most GNOME components but nobody is really looking at dbus apparently
[20:26] <seb128> walters: that's mainly a manpower issue, pitti is looking at updates and doing syncs on debian but I think he's too busy to do the bug triage
[20:26] <seb128> and dbus is not the easier thing to triage for contributors
[20:27] <bdmurray> walters: is there any documentation you would recommend for triagers?
[20:27] <walters> seb128: yeah, i can understand that
[20:28] <walters> bdmurray: hm i can't think of anything specific to dbus
[20:29] <walters> hopefully there aren't too many dbus crashers left since we are trying to be very conservative with changes, but this is the 3rd time someone's gotten on IRC and said their system bus crashed which is pretty serious
[21:25] <thekorn> bdmurray, I think this is the complete changelog for the 0.3 release, any suggestions or improvements? http://paste.ubuntu.com/24544/
[21:28] <bdmurray> line 28 should be milestone right?
[21:29] <thekorn> you are right
[21:30] <thekorn> it'S a duplicate entry then
[21:30] <bdmurray> a duplicate of what?
[21:31] <thekorn> nevermind, forget this
[21:31] <thekorn> mixed two things here ;)
[21:31] <bdmurray> Perhaps documenting the changes in the API in the wiki would be helpful for others too
[21:32] <thekorn> working on the wiki pages is on my TODO for tomorrow morning
[21:32] <thekorn> especially reflecting the recent changes
[21:33] <bdmurray> okay, I think merging is a good idea then and we'll update the package in intrepid when that is set
[21:33] <bdmurray> that being the wiki
[21:33] <thekorn> ok cool
[21:33] <thekorn> thanks
[21:34] <bdmurray> thank you!
[21:35] <thekorn> pushed as rev 107
[21:36] <LaserJock> thekorn: would it be possible to get automatically generated API docs?
[21:36] <LaserJock> to make your life easier :-)
[21:38] <thekorn> LaserJock, sure, but unfortunatly the __doc__ strings are not as complete as they should be
[21:38] <LaserJock> time for a SoC student ;-)
[21:39] <thekorn> o/
[21:39] <thekorn> if it can wait one year
[23:43] <charlie-tca> Hello, not having done any bug_work in a long time, I need to start triaging again. Is it time for the Hug Day yet?
[23:52] <bdmurray> It's Hug Day in some parts of the world!


[02:56] <thumper> https://github.com/juju/juju/pull/11869 is now ready for review
[02:56] <thumper> wallyworld, hpidcock, tlm, kelvinliu, or anyone really
[03:23] <tlm>  I can take a look thumper
[03:27] <thumper> thanks tlm
[03:51] <tlm> lgtm thumper
[04:55] <mertgor> Hi people!
[04:59] <tlm> hi mertgor
[05:00] <mertgor> tlm: how are you today, i was configuring my Juju account in the forum
[05:02] <mertgor> tlm: i'm new to Juju and related projects backed by Canonical, are you more experienced than me ?
[05:03] <tlm> welcome mertgor, all the devs for the project hangout here and on discourse https://discourse.juju.is/
[05:04] <tlm> may not be to chatty here this afternoon as it's getting later in the arvo for the APAC region and europe/north america are coming online
[05:05] <mertgor> tlm: okay Thanks, i need to think about how i do my computing again
[05:05] <mertgor> I'm from Turkey, it is 08:04
[05:06] <tlm> oh nice. Good morning
[05:06] <mertgor> tlm: Thanks :)
[05:08] <mertgor> Active summary for every 30 minutes is nice :)
[09:40] <stickupkid> anybody know if juju/charm is used by anybody else?