[00:00] <hggdh> anyways, gutsy is still supported, right?
[00:01] <Ampelbein> the commenter about hardy has the same problem but with a different driver, the ipw3945 does not support the wireless-4965 afaics.
[00:01] <hggdh> no... the last commenter is running iwl
[00:01] <hggdh> indeed
[00:01] <hggdh> bdmurray, is gutsy still supported?
[00:02] <bdmurray> yes, feisty and gutsy are
[00:02] <hggdh> is there any chance of this bug being fixed, or should we go Ampelbein's suggestion?
[00:03] <bdmurray> I'd check with the kernel expert ogasawara!
[00:03] <hggdh> thanks ;-) Ampelbein, let's wait for a word form the masters, if you do not mind
[00:03] <tormod> Ampelbein: I don't think duplicates should be changed to invalid (e.g. 135025)
[00:03] <bdmurray> hggdh: btw what was the reasoning for needs-packaging becoming a work flow bug?
[00:04] <Ampelbein> hggdh: fine for me.
[00:04] <hggdh> an exchange between Hobbsee and myself; to my understanding, this is something that only the packagers can decide
[00:05]  * ogasawara looks at bug 163236
[00:05] <bdmurray> can decide what?  Its easy to determine if something is or isn't packaged.
[00:05] <hggdh> (although I hate this process, goes completely outside bug practices)
[00:05] <hggdh> it is a needs-packaging, not a question if it is already packaged or not
[00:05] <bdmurray> I've had to invalidate some needs-packaging bugs that were already packaged.
[00:06] <hggdh> bdmurray, we really should go back and formalise this process
[00:06] <Ampelbein> tormod: ok, i'll just add the duplicate-mark then. thanks for the info.
[00:06] <bdmurray> hggdh: For needs-packaging bugs?
[00:06] <hggdh> for the workflow bugs
[00:07] <hggdh> put them (somehow) into normal flow
[00:07] <hggdh> if at all possible
[00:07] <hggdh> but -- if needs-packaging are to be dealt by triagers, then I apologise
[00:09] <Ampelbein> tormod: and please excuse if i make any mistakes, just started with helping on launchpad.
[00:09] <bdmurray> Well, I think there is some that triagers can do with needs-packaging bugs but if there are enough developers to handle those ....
[00:09] <ogasawara> Ampelbein, hggdh:  so basically what I'd recommend for bug 163236 is that the last commenter saying they have issues with 4965 needs to open a new report as this report is about ipw3945 and eventually iwl3945
[00:10] <tormod> Ampelbein: no problem. thanks for helping out! better do small mistakes than doing nothing :)
[00:10] <hggdh> ogasawara, and what should be done with the ipw one? Close?
[00:10] <ogasawara> Ampelbein, hggdh:  it does seem that the newer iwl3945 in hardy does resolve the issue.  It's unlikely a SRU will be done to fir the ipw driver for Gutsy, so I'd make it a won't fix for Gutsy
[00:10] <bdmurray> Duplicates being Invalid or not is somewhat pedantic
[00:11] <Ampelbein> ogasawara: thanks for having a look. i'll leave a comment for the last commenter with the 4965.
[00:11] <ogasawara> Ampelbein, hggdh:  I can clean up the bug if you like
[00:11] <tormod> bdmurray: it's for the case the duplicate turns out wrong, then the bug should be back where it was.
[00:11] <Ampelbein> ogasawara: that would be fine.
[00:11] <Ampelbein> ogasawara: thank you.
[00:11] <hggdh> ogasawara, no problem for me, I was just trying to help Ampelbein
[00:12] <ogasawara> Ampelbein, hggdh:  no problem, thanks for helping with the triage
[00:12] <bdmurray> tormod: Okay, I can see that arguement as it would take one less step - you wouldn't have to Unmark and re-open
[00:12] <tormod> bdmurray: and reopen to the right status
[00:13] <tormod> (and not everybody can take it back to "triaged" for instance)
[00:41] <Hobbsee> hggdh: although, wrt needs-packaging, all the triagers can (and possibly should) do is set the bug to wishlist, and ensure it has the needs-packaging tag.
[00:41] <Hobbsee> hggdh: that's all anyone can do, until someone decides to put in the effort to package it.
[00:42] <Hobbsee> hggdh: and to check they're not in the archive already, etc.
[00:47] <hggdh> Hobbsee, good. We can, then, take it out of the forbidden realm, and document the procedure
[00:48] <hggdh> do you want to edit the wiki, ar should we do it?
[00:48] <Hobbsee> hggdh: you can :)
[00:48] <hggdh> :-)
[00:48] <hggdh> bdmurray, should I?
[00:48] <Hobbsee> hggdh: it would also be helpful to check if it's in debian, and write a comment on the bug if it is
[00:48] <Hobbsee> yes, you probably should :)
[00:48] <bdmurray> perhaps mentioning rmadison as a tool to check debian
[00:49] <bdmurray> What about setting the bug to Confirmed if it doesn't exist?  That still leaves Triaged as a possible next step if necessary for developers.
[00:53] <hggdh> k. so, let's recap: if needs-packaging: (1) check if already packaged; if not, then (2) check if in Debian (use rmadison); if it exists there (same version), set it to confirmed
[00:54] <Hobbsee> and add the tag if it's not there :)
[00:54] <bdmurray> if it does not exist there set to confirmed and wishlist
[00:54] <hggdh> (3) add the tag "needs-packaging"; set the bug to wishlist
[00:54] <bdmurray> if it did exist in debian it'd be a sync request right?
[00:54] <hggdh> huh
[00:54] <hggdh> indeed
[00:55] <hggdh> so (2) if in Debian (same version), update description to "Please sync <package>"
[00:56] <hggdh> OK, let me try it
[00:58] <bdmurray> LaserJock: hggdh is writing up some documentation regarding how to triage them
[00:58] <LaserJock> well, I'm not quite sure what the triagers want to do with them
[00:59] <bdmurray> Well, we thought we could help out if that's alright
[00:59] <bdmurray> My e-mail had my thoughts
[00:59] <LaserJock> that is cool
[01:00] <LaserJock> but one of the important things about triaging needs-packaging is licensing compatibility checks
[01:00] <hggdh> LaserJock, what we would like to do is to help. If, on the other hand, you would rather not have us touch them, that's OK also
[01:00] <bdmurray> My thought was Confirmed would mean is not packaged and Triaged would mean meets licensing compat issues
[01:01] <LaserJock> well, personally I'd love everybody to work on them together, not separation between triagers and packagers :-)
[01:01] <LaserJock> bdmurray: yeah, I'm trying to scare up some documentation on that
[01:01] <hggdh> amem, LaserJock, amem
[01:02] <LaserJock> so if triagers feel comfortable with going to Confirmed then that's cool
[01:02] <hggdh> perhaps it would be better to link to a different wiki page on this. I had thought about licencing, but was unsure on how to proceed there
[01:02] <bdmurray> Licensing documentation would be neat because its a mystery to me
[01:02] <LaserJock> the Importance is something but it's really not necessary at this point
[01:02] <LaserJock> since *everything* needs-packaging is Wishlist it's rather pointless as an Importance
[01:03] <hggdh> do we still have packages.ubuntu.com?
[01:03] <LaserJock> yep
[01:03] <bdmurray> I personally use apt-cache search
[01:03] <LaserJock> depends on what you need ;-)
[01:04] <LaserJock> rmadison is also wonderful as it catches all releases
[01:04] <LaserJock> but a lot of the time package names aren't trivial to find
[01:05] <LaserJock> however, one thing I think maybe should be discussed before launching into a documentation blitz
[01:05] <LaserJock> is triaging needs-packaging worth the effort?
[01:05] <bdmurray> as they get mixed in with the bugs w/o a package yes
[01:06] <LaserJock> well ...
[01:06] <LaserJock> perhaps it's fixing the wrong problem, as we've discussed before the bugs w/o a package thing is a mess for several reasons
[01:07] <bdmurray> okay, but that isn't fixable today
[01:07] <bdmurray> documenting what to do with the bugs w/o a package mess is
[01:07] <LaserJock> neither is spending valuable man-hours on triaging somewhat pointless bugs
[01:07] <hggdh> LaserJock, I would really have all bugs with S.O.P.s so that triagers would be able to know what to do (or *not* to do)
[01:08] <LaserJock> hggdh: that's indeed a good goal
[01:08] <yuriy> SOPs?
[01:08] <LaserJock> not a panacea, but a good goal for sure
[01:08] <hggdh> Standard Operating Procedures
[01:09] <hggdh> there is no panacea... but at least there might be documentation
[01:09] <LaserJock> I don't particularly like the "Special types of bugs" heading there
[01:09] <LaserJock> there are all kinds of special bugs, that's just a list of workflow bugs
[01:10] <hggdh> if there are other, we should list them also
[01:10] <LaserJock> well, Xorg bugs, kernel bugs, etc.
[01:10] <Hobbsee> bug 159304
[01:10] <LaserJock> there are special groupings of bugs that are treated differently than a generic bug
[01:11] <LaserJock> hggdh: are you wanting documentation on triaging these bugs specifically, or about them in general?
[01:12] <LaserJock> there are a few that people doing general triage just shouldn't touch
[01:12] <LaserJock> there are other that triage can be done on in general, even though they're workflow bugs
[01:12] <hggdh> in general. I would like to have all special cases documented, so that new triagers (and old ones, for that matter) could have a reference to go
[01:13] <LaserJock> or developers ...
[01:13] <hggdh> and, in special, those that are verbotten for gtriagers
[01:13] <LaserJock> many of us don't know the SOP for them either
[01:14] <hggdh> LaserJock, this is the crux -- we should be able to know what to do, whoever we are (triagers, developers, packagers, etc)
[01:14] <LaserJock> well, as I look at the list
[01:14] <LaserJock> I honestly don't see a lot to do
[01:15] <LaserJock> needs-packaging is the only one there that I can see any "work" for people to do
[01:15] <hggdh> what I would not want is a new triager being blasted because of lack of docs
[01:15] <LaserJock> the others are I think all covered in developer documentation
[01:15] <hggdh> LaserJock, that is already good -- so we can just add in the needs-packaging one
[01:16] <hggdh> and maintain the "there be dragons" for the others
[01:16] <LaserJock> well, it shouldn't be "there be dragons", but rather, "oh, nothing to do here"
[01:16] <hggdh> :-)
[01:16] <hggdh> eppuir si muove
[01:17] <LaserJock> we aren't trying to blast triagers
[01:17] <LaserJock> we just want them to know they're wasting their time and creating noise when they're trying to triage these things
[01:17] <hggdh> I know. But ut has happened
[01:18] <LaserJock> and occasionally it's caused problems in processes that depend explicitly on Statuses
[01:19] <hggdh> this is another reason for having them documented
[01:20] <LaserJock> well, they are documented
[01:20] <LaserJock> just not in the bug squad/triager documentation
[01:22] <LaserJock> well, I can't find any policy we have on needs-packaging other than open one if you want a package or are going to packaging something and close one when you upload to NEW
[01:22] <LaserJock> so I guess we can make one up :-)
[01:22] <bdmurray> There is that template too right?
[01:22] <LaserJock> yeah, there is a template
[01:22] <bdmurray> so if the report is very incomplete we could use that in a response
[01:22] <LaserJock> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages/ExamplePackageRequest
[01:23] <LaserJock> well, I guess
[01:23] <LaserJock> honestly I don't know how much it's really used
[01:24] <LaserJock> it's predecessor, the wiki page, was mostly something to point people at who were bugging MOTU about packaging something
[01:24] <LaserJock> it's not terribly useful as a working list
[01:25] <LaserJock> and we haven't as of yet, actually tied it to any real packages
[01:25] <LaserJock> that's done on REVU
[01:26] <LaserJock> hence why I'm a tad hesitant about people spending time triaging it
[01:27] <bdmurray> I don't think it is something useful to do in and of itself but when looking at bugs w/o a package it is useful to remove those for the list
[01:27] <bdmurray> s/for/from/
[01:28] <LaserJock> right, but how is it really going to do that?
[01:28] <bdmurray> by them not having a status of new or importance of undecided
[01:28] <hggdh> well, if it has no package, then it is a tad more difficult indeed...
[01:28] <bdmurray> that is the standard no package query
[01:28] <LaserJock> I see
[01:29] <LaserJock> well, it's a lot of bugs to go through, but it would do the trick I suppose
[01:30] <bdmurray> I think you are missing what I am trying to say, lets say you are going through the list at https://launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-datecreated&search=Search&field.status%3Alist=New&field.importance%3Alist=Undecided&field.assignee=&field.owner=&field.omit_dupes=on&field.has_patch=&field.has_no_package=on
[01:30] <bdmurray> and you find a needs-packaging bug, you already have the tab open so why not do the right thing
[01:32] <hggdh> firs try set. Please see https://wiki.ubuntu.com/Bugs/HowToTriage, and comments are appreciated
[01:34] <LaserJock> bdmurray: right, that does make sense
[01:34] <LaserJock> bdmurray: I just want to get it right the first time
[01:34] <LaserJock> I really don't think we should have bugs without packages
[01:35] <bdmurray> hggdh: rmadison -u debian <package>
[01:35] <hggdh> dammit
[01:35] <LaserJock> but for now definitely a good pragmatic approach is helpful
[01:35] <hggdh> fixing
[01:35] <dupondje> plz check: https://bugs.launchpad.net/ubuntu/+source/dmraid/+bug/247027 fixxed the bug :)
[01:36] <LaserJock> hggdh: I wouldn't turn them into sync bugs if they are in Debian
[01:36] <LaserJock> I would invalidate them
[01:37] <hggdh> OK, will do. This was proposed earlier
[01:37] <bdmurray> hggdh: it's dinner etc here I'll review more later.  thanks for writing it up
[01:37] <hggdh> bdmurray, np. Thanks for bearing with me
[01:37] <LaserJock> there are semi-automatic tools for syncing in new packages from Debian
[01:37] <LaserJock> and for the rest it's probably better to approach it from the developer end, IMO
[01:40] <hggdh> LaserJock, done. thank you.
[01:40] <LaserJock> hggdh: what is the "for the same version" part saying?
[01:40] <LaserJock> in the first bullet
[01:41] <hggdh> LaserJock, let me get there
[01:41] <hggdh> ah, OK. This can probably go out. This was written when we would be considering syncs. I will take it out
[01:42] <LaserJock> while you're there
[01:42] <hggdh> yes?
[01:42] <LaserJock> I think you can shorten the rmadison bits by just giving the rmadison command
[01:43] <LaserJock> so, (see http://packages.ubuntu.com, or use run {{{rmadison <package>}}})
[01:44] <LaserJock> s/use//
[01:45] <hggdh> doing it
[01:45] <LaserJock> and you can shorten the example link by [UbuntuDevelopment/NewPackages/ExamplePackageRequest| Example Request] I think
[01:46]  * LaserJock gets out his whip, faster hggdh faster!
[01:46] <LaserJock> ;-)
[01:46] <hggdh> ouch
[01:46] <hggdh> done
[01:47] <hggdh> except the shortening
[01:47] <hggdh> getting it now
[01:48] <hggdh> redone
[01:48] <hggdh> well, saving... sort of slow, the wiki
[01:48] <LaserJock> darn, I told you wrong
[01:48]  * LaserJock tries to remember the right synatx
[01:48] <hggdh> and I just copied :-(
[01:49] <LaserJock> oh, probably needs [[ and ]]
[01:49] <hggdh> yes, double. Getting it right
[01:49] <LaserJock> course I could just fix it myself rather than torture you with it ;-)
[01:50] <hggdh> :-)
[01:50] <hggdh> saving
[01:51] <LaserJock> awesome
[01:52] <hggdh> LaserJock, thank you. I hope you understand why I am getting this documented
[01:52] <LaserJock> alright, I need to head home but I'll try to have another look at it tonight. I might have a couple thoughts on some readability/usability improvements ;-)
[01:53] <LaserJock> sure
[01:53] <hggdh> most certainly... this was written in a hurry, and can most probably get better
[01:53] <LaserJock> it's usually pretty hard to over-document these kinds of thing
[01:53] <LaserJock> bbl
[02:00] <hggdh> dupondje, the correct status is not fix committed yet
[02:00] <dupondje> In Progress ?
[02:01] <hggdh> could you run a diff and add in the diff as a patch
[02:04] <hggdh> although this seems to have worked, I would still like a developer to validate it.  first question I would ask is "why 30 seconds?"
[02:04] <hggdh> why not 10, or 27, or 42?
[02:04] <hggdh> fix committed means the package is already corrected, but not yet available
[02:05] <hggdh> which is not the case -- the patch will still need to be reviewed, and added in
[02:05] <hggdh> the correct status would be either Confirmed or Triaged
[02:06] <dupondje> Ubuntu 8.04 uses that line ... seems like its gone in 8.10
[02:06] <dupondje> no id why
[02:06] <dupondje> with the line it works perfect again ...
[02:06] <dupondje> anyway, nite
[02:13] <hggdh> dupondje, merci beacoup
[02:55] <kinema> Do bugs filled against a Universe package automatically get forwarded to the Debian BTS?
[02:55] <Hobbsee> no
[02:56] <kinema> So shouldn't I file bugs against such bugs in the Debian BTS?
[02:59] <Hobbsee> ?
[03:00] <Hobbsee> as in, filing bugs saying that these other bugs are filed wrong, or that they're getting filed at all?
[03:00] <kinema> Aren't packages in Universe just Debian packages?
[03:00] <kinema> Are they even modified by Ubuntu devs?
[03:01] <Hobbsee> some of them are.
[03:01] <Hobbsee> most aren't.
[03:01] <Hobbsee> however, it may be that the bugs don't occur with the debian packages
[03:01] <kinema> The package in questing shows: "Maintainer: Ubuntu MOTU Developers"
[03:01] <Hobbsee> and you should check for that, before filing anything in debian
[03:02] <kinema> My bug is simple. I just wish that the calendarserver package mentioned in it's description that it is in fact the "Darwin Calendar Sever" and that it's a CalDAV server.
[03:03] <RAOF> You almost certainly need some form of testing on a Debian system before you can reasonably submit a bug to Debian.
[03:03] <RAOF> Right.  That sort of bug would be one of the exceptions :)
[03:04] <kinema> The problem is that I was looking to see if the DCS was packaged so I searched for "darwin calender" and found nothing. I then searched for caldav looking for another caldav server but the calenderserver package wasn't listed as nowhere does it mention that it supports caldav (it's primary purpose).
[03:05] <RAOF> "Apple's Calendarserver is a standalone caldav server with: "
[03:06] <RAOF> That's the first line of the long description, at least in Intrepid.
[03:06] <kinema> Does "aptitude search" not search descriptions?
[03:07] <RAOF> Not the long description, IIRC.
[03:07] <kinema> Isn't there a keywords section or something in deb files?
[03:07] <RAOF> There's tag support that's recently landed.
[03:08] <RAOF> Synaptic certainly searches the long description.
[03:09] <kinema> I'm running on a headless sever with no X.
[03:10] <RAOF> There's probably an aptitude switch to search on long-description.
[06:02] <Hew> Can someone help me triage bug 120199? This guy refuses to answer my questions (test with Hardy), but seems to enjoy ranting instead.
[06:03]  * Hobbsee tries not to think bad thoughts
[06:03] <Hobbsee> hm, not who i suspected.
[06:08] <Hew> They refuse to test on Hardy, even though I've provided evidence that the program has changed..
[06:09] <dholbach> good morning
[06:09] <Hew> good afternoon dholbach
[06:09] <dholbach> hi Hew
[06:11] <nellery> morning dholbach :)
[06:11] <dholbach> heya nellery :)
[06:18] <LaserJock> Hew: well, honestly I see the guys point. It'd be worth somebody investigating at least
[06:18] <LaserJock> I don't know that it's reasonable to close people's bug just because they don't want to change OS versions to test
[06:19] <Hew> LaserJock: It was left in an incomplete state for a month, what else can we do? I've asked him to test using Hardy, and I've looked and the files he's talking about aren't there anymore, but he still refuses to test.
[06:19] <Hew> LaserJock: I don't even know what release he reported the bug against (I assume Feisty)
[06:20] <LaserJock> well, somebody needs to find out if ntpd works (with respect to his bug) properly in Intrepid
[06:21] <LaserJock> it seems to have enough information to investigate, not sure why it'd be Incomplete
[06:21] <Hew> LaserJock: Exactly, that's why I've asked the reporter to check. He hasn't refused to test, he just keeps ranting about how he knows the problem still exists.
[06:21] <Hew> LaserJock: It's incomplete because I asked a question (Does the issue exist in the latest release) and he hasn't answered.
[06:21] <LaserJock> Hew: actually he said that we don't know that it *does* still exist and that fact that we don't have those files indicates that it might be worse
[06:22] <Hew> LaserJock: I suspect the files have been moved and redone in a different area
[06:22] <LaserJock> rather, we don't know that it *doesn't* exist
[06:22] <LaserJock> Hew: me too, but somebody needs to test to make sure
[06:22] <LaserJock> right?
[06:22] <Hew> LaserJock: Who? The bug reporter is the person most familiar with this issue.
[06:23] <Hew> LaserJock: you are exactly right
[06:23] <LaserJock> somebody running ntpd on Intrepid
[06:23] <LaserJock> I can't blame the guy for not wanting to upgrade just to do other people's work for them (from his perspective)
[06:24] <LaserJock> he's being fairly aggressive, but many of his points seem fairly valid to me at least
[06:25] <Hew> LaserJock: He may even be on Hardy right now, I have no idea because he won't tell me.
[06:25] <LaserJock> right
[06:26] <LaserJock> but it's not, IMO, the bug reporters obligation to do release testing
[06:26] <LaserJock> it's nice when they do for sure
[06:26] <LaserJock> but we're the ones investigating/fixing the bugs
[06:30] <LaserJock> Hew: I can understand your frustration for sure, but I tend to think the ball's in our court to figure out if it's affecting Intrepid.
[06:32] <Hew> LaserJock: I'm still not really sure what the problem is, the bug description mostly consists of "fix these files" (which no longer exist). I don't have a laptop and I only have one network here, so I don't know how to test the issue myself.
[06:33] <LaserJock> Hew: you likely can't
[06:33] <Hew> LaserJock: I reckon I'm just going to leave that bug alone now, it's too hard to triage..
[06:34] <LaserJock> well, maybe not too hard to triage
[06:34] <LaserJock> in the sense that there's information, you've worked hard to get as much as you can
[06:34] <LaserJock> what needs to be tested, as far as I can tell, is if you hibernate and then resume, what happens to ntpd? does it get respawned or not
[07:10] <tuxmaniac> heya gang
[08:05] <dholbach> does anybody of you use the "global-august-08-lima" tag in 5-a-day still? :)
[08:06] <dholbach> ah, it was nxvl, he turned it off now - all is good
[08:08] <thekorn> hi "master-of-bugs-jams" dholbach
[08:08]  * dholbach hugs thekorn
[08:09] <dholbach> how's it going?
[08:09]  * thekorn hugs dholbach 
[08:10] <thekorn> good, I'm happy that dvb-t is working for me, so I'm able to follow the olympics
[08:10] <dholbach> ahh nice :)
[09:13] <dholbach> bdrung: just looked at your branch - I like your changes, it adds much more clarity to the code
[09:15] <dholbach> bdrung: what do you think about moving the parsing logic to fiveaday/parser.py again and pass a dict or an object? that way the 5-a-day tool itself is smaller again and we don't need to change the function calls every time we drop or add a new option
[09:15] <bdrung> dholbach: thx. it was 50 % a copy paste work :)
[09:15] <bdrung> dholbach: good idea
[09:16] <dholbach> bdrung: excellent - I'm happy to review it again or help out if you get stuck
[09:17] <dholbach> I will look into using   bzr lp-login   instead of the .5-a-day file later
[09:20]  * dholbach rushes off for some shopping - bbl
[10:57] <bdrung> dholbach: done
[10:57] <bdrung> now using dicts and sets
[10:57] <dholbach> bdrung: nice - will check it out in a bit
[10:58] <bdrung> dholbach: i have set COMMAND_LINE_SYNTAX_ERROR = 2 for return value. is 2 ok or which number do you prefer?
[10:59] <dholbach> 2 is fine with me, AFAIK it should not affect the 5-a-day applet
[11:08] <bdrung> dholbach: using tabs or spaces?
[11:08]  * bdrung prefers tabs.
[11:08] <dholbach> bdrung: spaces - try running the .py files with   python -tt  to find out if there are mixed spaces/tabs
[11:09] <dholbach> we don't adhere strictly to pep8, but try to get close to it: http://www.python.org/dev/peps/pep-0008/
[11:30] <bdrung> dholbach: pushed changes
[11:33] <dholbach> bdrung: looks good on a first glance - will check it more thoroughly in a bit (getting lunch first)
[11:33] <dholbach> thanks a lot
[14:53] <cacf3b2074> hi
[14:53] <cacf3b2074> all players hang when I switch away from the VT they use. Against what package should I report it?
[14:58] <persia> cacf3b2074: Could you define "player"?
[15:02] <cacf3b2074> persia: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/258158
[15:04] <persia> LimCore: Ah.  No idea then: it may be you've put it in the right place.
[15:04] <chrisccoulson> cacf3b2074 - It would be really beneficial for you to attach your ~/.xsession-errors file to your bug report after you trigger this event (don't log out and back in again though before attaching it, else it will not contain anything useful)
[15:04] <limcore_work> chrisccoulson: ok. Im also doing strace/dbg
[15:06] <chrisccoulson> thaI'd have a look in your ~/.xsession-errors file first. it might tell you something important and avoid having to go through the process of strace, which can generate a lot of data
[15:07] <chrisccoulson> that'd should equal i would
[15:07] <chrisccoulson> d'oh!
[15:10] <limcore_work> are there some GUI tools to better analyze strace, gdb etc?
[15:41] <hggdh> limcore_work, for gdb you have ddd
[17:08] <dholbach> bdrung_: your patch looks very good, I'll play with it some more before I upload it to PPA, but I'll merge it now
[17:08] <chrisccoulson> i've noticed some triagers recently adding a 'patch' tag to some bug reports that have patches attached. is this standard practise, and should this be documented in https://wiki.ubuntu.com/Bugs/Tags?
[17:09] <bdrung_> dholbach: e.g. you can use 5-a-day 4234 -au 242 --htlm 234
[17:09] <dholbach> chrisccoulson: no, it isn't - LP knows itself if an attachment is a patch or not, thus you can search for bugs with attached patches
[17:10] <dholbach> chrisccoulson: it's part of the tag wild growth in Ubuntu bugs
[17:11] <chrisccoulson> ok, thanks for that. i know a lot of people just add random tags to new bug reports they create. i sometimes remove these if i triage them and add the standard tags from the wiki page
[17:11] <dholbach> thanks a lot for that!
[17:13] <dholbach> bdrung_: pushed the changes and added you to the changelog entry
[17:13] <dholbach> bdrung_: on Monday, I'll look into bug 255340
[17:13] <dholbach> bdrung_: afterwards we can do an upload of the package :)
[17:13] <dholbach> bdrung_: thanks again for your great work on this
[17:13] <dholbach> the world is a better place again
[17:15] <bdrung_> dholbach: no problem. this was a low hanging fruit and python is a nice toy.
[17:15] <dholbach> it's more than a toy, but it's definitely fun :)
[17:16] <bdrung_> but for big programm i miss the compiler for type checking etc.
[17:23] <bdrung_> dholbach: if you have some time, could you have a look into htmlvalidator in my https://launchpad.net/~bdrung/+archive (except the missing license it should be ok)
[17:24] <dholbach> I'm about to call it a day now
[17:24] <dholbach> (been up since 6:00)
[17:24] <bdrung> tip: do not stand up so early :D
[17:24] <dholbach> but if you submit it to the sponsoring queue and nobody deals with it until Monday, I'll pick it up right there
[17:25] <chrisccoulson> talking about the ever growing list of tags in LP again - the 'Tags' box appears under the 'Summary' box when you report a new bug in Launchpad, so it is very accessible to any bug reporter but with has explanation of what the tags are actually for, and which tags are appropriate. IMO, this just encourages people to add anything they want in that box, which is probably why we have a long list of tags
[17:25] <dholbach> have a great weekend everybody
[17:26] <bdrung> dholbach: you too
[17:26] <dholbach> thanks :)
[17:26] <bdmurray> chrisccoulson: tags are being discussed for launchpad 3.0 changes
[17:26] <chrisccoulson> thanks, that was going to be my next question actually
[17:26] <bdmurray> There's also a greasemonkey script to make tags a bit more interesting
[17:27] <chrisccoulson> this one? http://www.bryceharrington.org/drupal/node/25
[17:28] <bdmurray> nope
[17:28] <bdmurray> http://bazaar.launchpad.net/~gm-dev-launchpad/launchpad-gm-scripts/master/annotate/41?file_id=lp_hide_tags.user.js-20080721195143-hbctm6414a1dt69y-1
[17:29] <chrisccoulson> thanks for that. i might have a look at that later
[17:30] <bdmurray> It helps by paring down the long list of tags you mentioned
[17:31] <chrisccoulson> that could be quite useful
[17:41] <bullgard4> htop prints: "Uptime: 2397 days(!)". How does such an error develop? This Ubuntu 8.04.1 computer has been booted last time about 6 days ago.  http://paste.debian.net/14847 Is it right to report this error in Launchpad?
[17:52] <hggdh> bullgard4, yes. Add in your Ubuntu and htop's version, and also the output of 'uptime'
[17:55] <bullgard4> hggdh: I will do so. Thank you for advising.
[18:09] <hggdh> bullgard4, you are welcome. Thank you for helping
[18:32] <nellery> morning
[18:33] <bdmurray> hello
[18:34] <limcore_work> hi
[18:34] <Initial_M> hi there
[18:35] <Initial_M> anybody here who knows if there's effects/animations for file transfer on ubuntu somewhat like windows
[19:29] <bullgard4> Initial_M: Please read the topic:  User support (not related to triage) is in #ubuntu.
[20:02] <hggdh> Bug 252287
[20:11] <emgent> evening
[21:08] <askand> Anyone got some tips on where I can get info on the problem in bug 249833
[21:08] <askand> What logs to check?
[21:09] <chrisccoulson> i'd have a look in ~/.xsession-errors first