[00:01] humm seb128 is not here [00:01] pedro neihter [00:01] should I upstream https://bugs.edge.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/403248 [00:02] Launchpad bug 403248 in gnome-power-manager "DIM will dim my screen even when not idle" [Undecided,New] [00:02] ? [00:02] or is it karmic related? === asac__ is now known as asac === nhandler_ is now known as nhandler === nhandler_ is now known as nhandler === Pici` is now known as Pici === bdefreese2 is now known as bddebian === WelshDragon is now known as Fluffles === jarlen_ is now known as jarlen === ejat is now known as e-jat [10:23] bug 403387 is not assigned a package, the bug itself is about audacious, but the the problem in this case is that the corresponding version audacious-plugings isn't in karmic yet [10:23] Launchpad bug 403387 in ubuntu "audacious has broken dependencies in karmic" [Undecided,New] https://launchpad.net/bugs/403387 [10:24] should it be assigned to audacious or audacious-plugins? [10:26] the merge of audacious-plugins is bug 399617 [10:26] Launchpad bug 399617 in audacious-plugins "Please merge audacious-plugins 2.1-1 (universe) from Debian unstable (main)" [Wishlist,In progress] https://launchpad.net/bugs/399617 === yofel_ is now known as yofel [11:15] /exit [12:49] is this where i wanna be for the ubuntu hug day today? [12:49] diverse_izzue: yes, welcome :) [12:50] ok, question. say i cannot reproduce a bug which is "new" in a newer version of the program. should i mark it as "invalid" or "fixed"? [12:53] diverse_izzue: I would set the bug to 'Incomplete' and post that I was unable to reproduce the issue in the newer version and ask the reporter if he is able to reproduce it with the newer version. After that I would go with the rules for Incomplete bug without a response if he doesn't answer. If he answers that he can't reproduce it as well then I would set the status to 'Invalid' [12:54] use 'Fix Released' only when there really was a Fix released for this exact issue. [13:00] yofel, does newer in this context imply newer in the same version of ubuntu? [13:20] trothigar: actually I would also ask him to check the bug in a newer ubuntu release if a newer one is available since the bug might be already fixed there. Although if the reported version is obsolete in his ubuntu release then he should try to reproduce it with his never version first. [13:22] yofel, so if the bugs fix in a later version, isn't it still a bug in the earlier version (assuming the earlier version is still within its supported time)? [13:24] trothigar: that would then become a question if the newer package should be backported to the older release. But I'm not to confident about this myself, so maybe somebody else could comment on that? [13:36] if the bug is critical enough to justify a backport, and it is possible to, then it will be backported [13:37] please see https://help.ubuntu.com/community/UbuntuBackports for more details of the process [13:38] Backports don't require critical bugs [13:38] yeee. Indeed. Sorry, just wake up [13:39] Backports just require adequate testing to establish justifiable belief that it will work on the older release and not break other things. [13:40] This is a problem, because now we have PPAs, people generally can't be bothered [13:41] this is a point where the PPAs disrupted the process [13:44] diverse_izzue, going back to your original question: if you find a bug on a newer release of a package then: (1) if the package is from a PPA, or erternal, contact the authors directly; (2) if the package is from Ubuntu, open a bug on it; (3) if the package is the pure upstream version (either dist point or trunk), open the bug upstream [13:47] diverse_izzue, if you cannot reproduce a bug on a newer version, as yofel said, enter a comment about it, mark incomplete, and wait a bit. The bug -- if indeed fixed on a newer release -- is actually to go to Fix Released, with a comment that [13:49] the fix for the current user release may be implemented if the reporter requests it ("Nominate for Release"), and the fix does not require extensive rebase. Otherwise it is either a backport request, or no fix on reporter's release [13:51] hm, that reminds me... The official backport procedure is to create a new bug in -backports. But I've seen bugs that just had an affects of -backports added, is that a valid way too or should that be converted into a seperate backport request? [13:53] s/affects of/affects on/ [14:07] yofel, ideally, you create a bug in -backports [14:07] it is not a good thing to have many different actions on the same bug === d0ntKn0w is now known as d0ntKn0w_ === d0ntKn0w_ is now known as d0ntKn0w__ === d0ntKn0w__ is now known as d0ntKn0w [15:21] hey guys, hope someone can help me, I've not sure if I've done the right thing or not [15:21] I've put the following bug against compiz -> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/391461 [15:22] Launchpad bug 391461 in compiz "Compiz Slow on Karmic w/ NVIDIA and 2.6.30 Kernel" [Undecided,New] [15:22] just not sure if I was right to do so, could be a driver issue but no idea how to figure out what the culprit is. any advice? [16:04] Boo === andrea-bs_ is now known as andrea-bs === micahg1 is now known as micahg [19:01] is gnome bugzilla website a litle overloaded? [19:01] I can't load any url [19:02] Kamusin, that's "normal" [21:59] hey fellow ubunteros [22:01] 'ello BUGabundo [22:02] Hello [22:03] hello Hellow [22:03] XD [22:09] I bet you get that a lot [22:09] and when you are going to leave, do you change it to _goodby_ ? [22:09] :p [22:09] hehe [22:49] hey seb128 [22:50] hi BUGabundo [22:50] oh it was a reconnect [22:50] sorry to have bothered you :) [23:23] hm, what is one supposed to do with an old bug report about a package that was only released in hardy and intrepid? === asac_ is now known as asac