[00:40] <nekohayo> hey there, would anyone know how to run a search in gnome bugzilla for all bugs in product X that have attachments that are patches?
[00:40] <nekohayo> oh nevermind
[00:40] <nekohayo> found https://bugzilla.gnome.org/show_bug.cgi?id=629694
[00:40] <ubot2> Gnome bug 629694 in source list "Importing a source which has already been imported raises an error and the import process doesn't continue" [Normal,Unconfirmed]
[00:41] <nekohayo> I mean https://bugzilla.gnome.org/page.cgi?id=patchreport.html&product=pitivi&max_days=300
[00:41] <nekohayo> stupid clipboard
[00:48] <bcurtiswx_> i get a lot of dist-upgrade bugs with empathy.  Knowing it's after a dist-upgrade, what are some possible causes of the bug?
[00:49] <bcurtiswx_> what can i ask next of the reporter?
[00:49] <bcurtiswx_> i.e. empathy contact list not showing.
[00:59] <erik_> i have a question on the intel video problem
[01:02] <erik_> when i installed ubuntu 9.10 i rebooted then the monitor goes black an just sits there can someone please help
[01:02]  * persia can't understand why anyone would want a graph of *jaunty* bugs, as we're nearly done with the support cycle for jaunty
[01:02] <erik_> i was told 10.04
[01:02] <persia> erik_, This isn't really a support channel (#ubuntu is).  You might try with Ubuntu 10.04 to see if it changed.
[01:02] <erik_> has same problem
[01:03] <persia> I'm not sure.  Both worked fine for me on my Intel graphics machines.  I suspect it to be highly chip-dependent.
[01:05] <erik_> intel 8xx onboard
=== nigelbabu is now known as nigelb
[03:47] <rusivi> Regarding bug 449473 I am a little lost on what he means. Ask for a screenshot?
[03:47] <ubot2> Launchpad bug 449473 in wine (Ubuntu) "Notification icons have grey background, ie transparancy is not working (affects: 2) (heat: 20)" [Undecided,Incomplete] https://launchpad.net/bugs/449473
[03:49] <micahg> rusivi: I'd suggest checking for a similar description in the winehq bugtracker first
[03:49] <rusivi> micahg good suggestion let me check it out real quick
[03:51] <rusivi> Another question, unrelated, when one posts to Launchpad it says in the "FROM" field of E-mails it is from your E-Mail address when it's clear it's from Launchpad... strange?!
[03:52] <rusivi> Purposeful?
[03:52] <micahg> rusivi: well, reply to is set correctly
[03:52] <micahg> rusivi: that's somewhat common when posting, that the poster's address will be used in From with a Reply To set properly
[03:53] <rusivi> micahg: it just throws me off
[03:53] <rusivi> micahg: i'm like, I never e-mailed that
[03:53] <micahg> well, if you posted the comment, it means that you "sent" it
[03:54] <rusivi> micahg: not from my E-mail address
[03:54] <rusivi> :)
[03:54] <micahg> well, you can select which address is displayed from Launchpad
[03:54] <rusivi> ahhhh k let me check that out too
[03:54] <rusivi> ty!
[03:55] <rusivi> micahg: yes I thought your suggestion about address chosen was different then my understanding.
[03:55] <rusivi> micahg: it just seems really weird and not representative of the transaction that occurred....
[03:57] <rusivi> micahg: yeah I 2x'ed launchpad no option to change "FROM" field
[03:57] <rusivi> seems like a bug!
[03:57] <micahg> rusivi: bug 31586
[03:57] <ubot2> Launchpad bug 31586 in malone "Malone comments are sent in email and forge the address of the person who filed them (affects: 1) (dups: 2) (heat: 33)" [Medium,Triaged] https://launchpad.net/bugs/31586
[03:57] <rusivi> ty micahg
[03:57] <micahg> rusivi: don't bother commenting unless you can add something missed, but you can see the logic behind it
[03:58] <rusivi> I will not comment just mark as I am affected
[03:58] <micahg> :)
[03:58] <rusivi> micahg: I do
=== micahg1 is now known as micahg
[04:57] <rusivi> micahg: quick followup my search did not yield a bug on WINEHQ that discussing transparency but I'm not using heuristics I'm newbing it by hand
[04:59] <micahg> rusivi: wine 22315
[04:59] <micahg> http://bugs.winehq.org/show_bug.cgi?id=22315
[04:59] <ubot2> bugs.winehq.org bug 22315 in -unknown "Notification tray icons using solid rather than transparent background colors" [Trivial,New]
[04:59] <rusivi> like I said newb'ing it
[04:59] <rusivi> hehe
[05:00] <micahg> take a look at the bug mentioned and see if the one you found is a duplciate
[05:00] <rusivi> k
[05:06] <rusivi> micahg: seems ubuntu buug 449473 should be marked as dup of ubuntu buug 403135
[05:06] <rusivi> *testing ubot2
[05:07] <rusivi> hehe
[05:11] <micahg> rusivi: yep
[05:11]  * hggdh kicks ubot2
[05:12] <nigelb> why? bug misspelled as buug
[05:12] <micahg> right
[05:12] <nigelb> !botsnack
[05:12] <ubot2> Yum! Err, I mean, APT!
[05:12] <nigelb> :)
[05:15] <hggdh> just in case...
[05:17] <micahg> rusivi: you can go ahead and mark it and use the duplicate response
[05:22] <rusivi> micahg: you got it!
[05:23] <micahg> rusivi: thanks
[05:25] <rusivi> micahg: sorry I marked dup first then it tells me don't comment unless the dup'ing is wrong... :(
[05:27] <micahg> rusivi: go ahead and add the response
[05:27] <rusivi> ty
[05:28] <rusivi> Is their a bug outstanding for clicking dup+comment?
[05:29] <micahg> rusivi: bug 520405
[05:29] <ubot2> Launchpad bug 520405 in malone (and 1 other project) "Canned "this is a duplicate" response wastes time (affects: 2) (dups: 1) (heat: 20)" [Low,Triaged] https://launchpad.net/bugs/520405
[05:29] <rusivi> ty ubot2 ;)
[05:40] <vish> rusivi: about the email from addy » Bug #31586
[05:40] <ubot2> Launchpad bug 31586 in malone "Malone comments are sent in email and forge the address of the person who filed them (affects: 3) (dups: 2) (heat: 46)" [Medium,Triaged] https://launchpad.net/bugs/31586
[05:40] <micahg> vish: I already mentioned that :)
[05:41] <vish> doh! i should read full backlogs :D
[05:42] <rusivi> vish: k let me look at it real quick
[05:43] <vish> rusivi: nah, that was the bug micahg already gave you.. its about the question you had asked.
[05:43] <rusivi> vish: let me check one sec plz
[05:44] <rusivi> Vish: sorry brain lag yes what can I talk with you about it?
[05:44] <vish> rusivi: hmm , nothing.. was just pointing out the bug for that issue
[05:45] <vish> rusivi: if you are affected, you can mark "as affected too"
[05:45] <rusivi> k ty
[05:45] <vish> persia: devildante is planning on a jaunty bug day, hence the graph for the page i suppose
[05:45] <persia> Why do we want to have a jaunty bug day?
[05:46] <persia> Really, anyone with a bug in jaunty should upgrade to lucid by way of karmic, or suffer from the unable-to-upgrade-cleanly-because-my-release-is-EOL bug.
[05:46] <vish> not sure, but many seemed to like the idea.. maybe that needs to be changed.
[05:46] <micahg> vish: I still think that should be done closer to/after Maverick release and there should be a focus on Beta/RC regressions
[05:46] <persia> (although, that bug doesn't get really painful until the release *following* the release one has installed is EOL'd)
[05:46] <micahg> persia: the idea would be to clear the bugtracker of old non-relavent bugs
[05:47] <vish> micahg: we already did that, jibel did a maverick target bug day.. that was the upgrade bugday
[05:47] <micahg> vish: that just covered one package
[05:47] <persia> vish, It might be interesting to sweep jaunty bugs to make sure they are all fixed in maverick, but I don't see significant value to other approaches (and I believe people like new ideas because they are new, regardless of merit)
[05:47] <vish> micahg: ah! right!
[05:48] <persia> micahg, LP autocloses all the jaunty tasks when it is EOL'd.  Any other bug on jaunty quite possibly affects maverick.
[05:48] <vish> persia: well, i think they discussed it on -qa meeting and they went with it.. :)
[05:48] <micahg> persia: right, so the idea would be to go through the jaunty tagged bugs w/out tasks
[05:48] <vish> persia: or maybe they are encouraging new members to participate.. not sure, hggdh and charlie-tca might know more
[05:49] <persia> Yeah.  That happens a lot.  I'd probably make more noise about it if the QA meeting wasn't at an annoying hour, or I had more interest in making sure folks didn't waste their time.
[05:49] <vish> i mean to participate in bug day planning..
[05:52] <vish> micahg: i think your idea of the maverick target bugs from all packages might be more a problem tracking, most of the teams themselves track those bugs and would already know the status , but the real maverick bugs that have not be check is tough to identify i suppose
[05:52] <persia> the vast majority of packages aren't tracked by teams.
[05:52] <micahg> right
[05:52] <micahg> vish: I'd say maverick tagged bugs w/out a task
[05:52] <persia> And the vast majority of packages that *are* tracked by teams end up with mostly pushes of new upstreams, rather than close attention to bugs.
[05:53] <vish> ooh! tagged maverick may work!
[05:54] <vish> but we should have bug days like that, just before release for the 3weeks before release, would be better QA for the release
[05:54] <persia> 3 weeks is kinda late: archive is usually already frozen.
[05:55] <micahg> vish: well, this week would be good to clear out pre-RC bugs, next week would be good to catch the RC bugs
[05:55] <vish> 3 rounds of bug days.. before the freeze?
[05:55] <maco> s/kinda/extremely/
[05:55] <maco> vish: after you mean?
[05:55] <maco> freeze was a week or two ago
[05:56] <micahg> 9 days ago
[05:56] <vish> maco: in future. maverick is too late for anything now ;)
[05:56] <micahg> vish: I still think there's value to doing it now
[05:56] <micahg> archive is open for bug fixes, especially universe
[05:56] <micahg> but even main if it's important enough
[05:56] <vish> micahg: yea, but i meant that *3 rounds* as a future idea..
[05:57] <micahg> vish: oh, well, maybe pre/post beta and pre/post RC would be good
[05:57]  * vish nods
[05:57] <micahg> or pre/post every milestone after alpha 2 even
[05:58] <micahg> as long as people don't get bore
[05:58] <micahg> d
[06:03] <AbhiJit> hi
=== zyga is now known as zyga-greece
[10:28] <Tetsuo55> hey
[10:28] <Tetsuo55> my bug was marked duplicate of https://bugs.launchpad.net/bugs/645161, but this bug cannot be viewed
[10:29] <ubot2> Tetsuo55: Error: Bug #645161 is private.
[10:29] <Tetsuo55> private
[10:29] <Tetsuo55> :(
[10:34] <micahg> Tetsuo55: no longer private
[10:34] <Tetsuo55> yay
[10:35] <micahg> Tetsuo55: it doesn't say much though
[10:36] <Tetsuo55> https://bugs.launchpad.net/telepathy-butterfly/+bug/597381
[10:36] <ubot2> Ubuntu bug 597381 in telepathy-butterfly (Ubuntu) (and 1 other project) "telepathy-butterfly crashed with UnicodeDecodeError in _signal_text_received() (affects: 97) (dups: 2) (heat: 471)" [Medium,Fix released]
[10:36] <Tetsuo55> looks a lot like this one
[10:37] <Tetsuo55> especially since its the same nickname that caused my ticket that was duplicate of the one you just unprivated
[10:39] <micahg> Tetsuo55: indeed
[10:39] <Tetsuo55> hope that helps, that ticket is supposed to be fixed with the new upstream release
[10:40] <micahg> Tetsuo55: which you have :)
[10:40] <Tetsuo55> yep
[10:40] <micahg> Tetsuo55: no, it's a different traceback
[10:41] <Tetsuo55> ok so its a new thing, maybe the fix upstream was incomplete
[10:41] <micahg> Tetsuo55: well, you can get a similar crash for a different code path (which is the case this time)
[10:41] <Tetsuo55> thats what i meant to say :P
[10:41] <Tetsuo55> you said it better
[10:47] <m4rtin> Hi, I'd like to report a problem with graphical boot, can someone point me to the correct package? (Usplash? Plymouth?)
[10:54] <micahg> m4rtin: probably plymouth
[10:54] <micahg> m4rtin: https://wiki.ubuntu.com/Bugs/FindRightPackage#During%20boot
[10:55] <m4rtin> micahg: thank you; apologies, that page is very heloful
[15:10] <devildante> vish: ping
[15:10]  * devildante sees his message in double... darn you empathy!
[15:10] <vish> devildante: pong
[15:10] <vish> devildante: i think *you* are just high ;p
[15:11] <devildante> :p
[15:11] <devildante> vish: do you think I should send an e-mail about hugday now, or later?
[15:11]  * devildante thinks this is a funny bug
[15:11] <vish> devildante: about jaunty bug day?
[15:12] <devildante> yep :)
[15:13] <vish> devildante: finished all the prep for the bug day?
[15:13] <devildante> oh, I forgot the graph! silly me :p
[15:14] <vish> persia: ^ devildante is here, incase you are around.. :)
[15:14] <devildante> persia: need something?
[15:15] <persia> devildante, I just didn't understand the point of a jaunty bug day, and folks referred me to you.
[15:16] <devildante> persia: jaunty is going to be EOL in less than one month, and there are still many bugs pertaining to it. So we should verify if the bugs are still present, ask the reporter if he still experiences this issue, etc...
[15:17] <persia> I'd probably not bother asking folk: few will have an environment suitable to reproduce the bug anymore.
[15:17] <devildante> if you can't reproduce a bug, that means it must have been fixed, right?
[15:17] <persia> Verification makes sense, and it's as good a way as any other to find bugs, although I'm not sure it's better or worse than any other way of selecting a bundle of them :)
[15:17] <persia> Not quite.
[15:18] <persia> Ideally, one verifies that one can reproduce in jaunty and can't in maverick (or whatever).
[15:18]  * AbhiJit wonders why to look for an versino which is shortly reaching its EOL
[15:18] <persia> Some bugs are locale-dependent, or HW dependent, or require other things to be active.
[15:18] <persia> AbhiJit, That was what I wondered, but I can't fault it as a way to select some old bugs that probably need to be rechecked.
[15:19] <AbhiJit> hmm
[15:20] <devildante> heh... even if we can't reproduce these bugs, we can't let them just rot, not knowing if they were fixed or not
[15:21] <persia> Well, we do that for other bugs :)
[15:22]  * bilalakhtar needs a person to test his SRU
[15:22] <bilalakhtar> devildante: Could you do me a favour?
[15:22] <persia> Were I looking for rotting bugs, I'd probably try to review the first 1000 oldest bugs.  Then start over again.  If that cycle was too fast, maybe a larger number.
[15:22] <rusivi> One quick comment on Jaunty bug day, great idea for community involvement as Community members may still have Jaunty installed. Many of the issues may not be reproducible and if they are fixed for those affected then mission accomplished. Nice to know either way if it is fixed or not. Thank you.
[15:23] <devildante> bilalakhtar: I have Maverick and SRU is for stable (Lucid). Is it still good?
[15:23] <bilalakhtar> devildante: I thought you are using Lucid
[15:23] <persia> rusivi, anyone who still uses Jaunty needs to upgrade.
[15:23] <bilalakhtar> sorry then
[15:23] <devildante> rusivi: thank YOU for sharing your opinion :)
[15:23] <rusivi> persia: agreed
[15:23] <devildante> bilalakhtar: no proble ;)
[15:23] <rusivi> devildante: np
[15:23] <bilalakhtar> Jaunty is going to reach EOL
[15:25] <vish> devildante: we discussed this actually today mornin,[check the irc.logs] i think people thought a bug day targeted at maverick at this time would be more beneficial.. for a better QA of Maverick
[15:26] <persia> vish, Let's not worry about trying to organise everyone: we'll do best if we're all doing slightly different things.
[15:26] <vish> :)
[15:29] <devildante> hmm, I just saw the logs, and I like to see great discussions :)
[15:30] <devildante> like vish (?) said, it's too late for Maverick, we're in FinalFreeze
[15:31] <devildante> but maybe you don't agree, so voice your opinions please :)
[15:34] <persia> For Maverick, I agree it's too late except for SRU-qualified bugs.
[15:34] <devildante> (and those are already targeted)
[15:34] <persia> For bugs in general, I think it's probably better to look at age, rather than release target.  There's lots of bugs in hardy that *still affect* supported users, for example.
[15:35] <persia> Actually, heaps of SRU-qualified bugs *aren't* targeted.  Some have yet to be discovered.
[15:35] <devildante> ah
[15:36] <persia> The ones that are targeted for 10.10-updates (or whatever the milestone) are those that we *know* will be sorted then, and most of them are things rejected by the release team for pre-release (or things developers are sure they won't have time to fix).
[15:36] <devildante> hmm, great, thanks for the insight :)
[15:39] <devildante> Back to the topic, what should we do? If everyone chooses not to have this target as a bug day, I won't oppose, so don't worry about me crying :p
[15:40] <persia> I think it's a fine target for one bug day.  Doesn't hurt anyone, and can help.
[15:40] <devildante> thanks :)
[15:40] <persia> I mostly wanted to make sure the goal was sensible: cleaning up old bugs is a good goal.
[15:40]  * devildante waits for other opinions though
[15:40] <persia> For next time, I might recommend another way to find old bugs, but that's all.
[15:41] <penguin42> the old ones are annoying of course, but things like regressions from Lucid would be good to nail
[15:42] <devildante> penguin42: we might do a bug day on "regression-*" tags + "lucid" tag
[15:43]  * penguin42 still has a bunch of regressions on this machine, and there are of course the one or two things that have only broken in the last week or so (like the ia32-libs)
[15:43] <persia> regressions from hardy as well.  10.04.1 was recent, and I know some institutions are just starting to migrate to lucid.
[15:43] <rusivi> Regarding Jaunty bugs, for my skill set it tends to be the best I can do is offer empathy and inclusion by inquiring if their problem still exists.
[15:43] <penguin42> ooh, except chris has just done a commit for that
[15:45] <persia> rusivi, most jaunty bug filers aren't going to be able to reproduce in jaunty: it's a far better thing for us to install a jaunty VM and try to check which bugs we can reproduce there, and not in maverick.
[15:45] <persia> Extra points for also testing lucid for anything that looks potentially SRU-worthy.
[15:45] <rusivi> persia: agreed.
[15:45] <persia> Excellent, so please don't inquire if those bugs still exist: we should be able to tell.
[15:46] <persia> If we can't, let's batch those differently (perhaps with an unverifiable tag), and then target them aggressively later.
[15:46] <rusivi> persia: It seems both a test for my personal skill growth + seeing if reporter wants to help too.
[15:46] <rusivi> persia: I will follow your lead though on it. I'll test before I comment.
[15:47] <persia> rusivi, Yes, but it's actively harmful.  It annoys the reporter (as they can't perform the requested action, and feel like they've been ignored for 18 months), and generates potentially useless bugmail for developers.
[15:47] <rusivi> persia: Yes sir!
[15:47] <persia> Just test, and close with comment if you can reproduce in jaunty and not in maverick :)
[15:47] <rusivi> persia: np
[15:47] <persia> And no need to call me sir :)  I'm very much not in charge when it comes to bugs: I've just been around a while.
[15:48]  * penguin42 should probably keep a lucid VM for that type of thing
[15:48] <devildante> persia: that's why there is in the beginning of each bug table: "Verify the bug has still not been fixed" ;)
[15:48] <persia> devildante, Yep :)
[16:27] <om26er> what should be done to people with this attitude bug 648180 ?
[16:27] <ubot2> Launchpad bug 648180 in unity (Ubuntu) "Unity sucks (affects: 1) (heat: 6)" [Undecided,Opinion] https://launchpad.net/bugs/648180
[16:29] <vish> om26er: tell them this is a better place for that ? » <http://www.reddit.com/r/Ubuntu/comments/diqvy/is_it_just_me_or_is_nbr_1010_complete_crap/> ;)
[16:29] <m4rtin> a polite response to say that, should he wish to know what the decision making process was, he should have got involved in the development?
[16:29] <vish> om26er: anywho.. he has marked the bug as opinion itself, no need further triage there :)
[16:30] <m4rtin> people are entitled to opinions, but, in the majority of cases, those opinions are only founded on knee-jerk reactions and ignorance. They can be ignored!
[16:30] <om26er> well the bug report has nothing useful in in at all. *reason* ;)
[16:30] <penguin42> om26er: I guess you could ask him to say what he preferred about the old one
[16:31] <vish> om26er: i think mark might reply there himself.. if he is bored, otherwise just go "meh.." :p
[16:31] <om26er> na I wont be replying. I am just preparing myself for future situations.
[16:32] <om26er> oh and if it was as an upstream bug report for gwibber . I would have kicked his *
[16:36] <om26er> joining this https://launchpad.net/~ubuntu-typeface-interest team should require signing CoC so that people try to behave
[16:37] <vish> om26er: thats a nice suggestion.. not sure how it would work though..  could you tell that to sladen?
[16:38] <devildante> om26er: wow, I didn't know that there is such a group!
[16:38]  * devildante just applied to the group
[16:38] <om26er> vish, I'll try
[16:39] <vish> om26er: oh noes! we had hidden that group from devildante! :(
[16:39] <vish> now he knows :s
[16:39]  * devildante will get his revenge
[16:40] <vish> devildante becomes evildante  ? ;p
=== devildante is now known as evildante
[16:40] <om26er> there is already an evildante I just cant find him
[16:41] <evildante> too late I nuked devildante, now you'll experience the true pain :p
=== bilalakhtar_ is now known as bilalakhtar
=== AbhiJit is now known as Guest30026
=== AbhiJit_ is now known as AbhiJit
[18:23] <yofel> AbhiJit: it would help if you wouldn't part/join a channel all the time... http://paste.ubuntu.com/501052/
[18:24] <AbhiJit> :o
[18:24] <AbhiJit> me?
[18:24] <yofel> (or did you have a connection reset?)
[18:25] <AbhiJit> yofel, thanks. but 'you' told me which is the latest version. i want it from ubottu. so that in future i dont need to disturb you all busy peoples in #ubuntu or #ubuntu-kernel
[18:25] <yofel> just use rmadison
[18:25] <AbhiJit> what is rmadison?
[18:25] <brunogirin> Hi all, how can I debug an issue where apport says "The program crashed on an assertion failure, but the message could not be retrieved. Apport does not support reporting these crashes"?
[18:26] <yofel> AbhiJit: command line tool to check package versions for different releases, part of devscripts (just install ubuntu-dev-tools)
[18:26] <AbhiJit> yofel, ok
[18:27] <yofel> AbhiJit: you can also use '/msg ubottu linux-image-generic <release>' but that's not as convenient as rmadison
[18:27] <yofel> err, wrong
[18:27] <AbhiJit> ??
[18:27] <yofel>  /msg ubottu info linux-image-generic <release>
[18:28] <AbhiJit> yah that worked thats what i wanted
[18:28] <Nafallo> !info linux-image-generic hardy
[18:28] <penguin42> yofel: Does that program know about debian versions as well ?
[18:28] <ubot2> Nafallo: linux-image-generic (source: linux-meta): Generic Linux kernel image. In component main, is optional. Version 2.6.24.28.30 (hardy), package size 26 kB, installed size 52 kB
[18:29] <yofel> penguin42: use 'rmadison -u debian <pkg>' for that
[18:29] <penguin42> yofel: Ah neat, I keep wondering when I report something if there is a newer debian version of a package I should try
[18:32] <yofel> it's essentially the same as 'apt-cache madison' but uses an external database that contains all supported releases
[18:47] <penguin42> chrisccoulson: IOU one muffin
[19:21] <brunogirin> any idea what package contains the libgnome-keyring debugging symbols?
[19:22] <yofel> brunogirin: libgnome-keyring0-dbgsym and libgnome-keyring1.0-cil-dbgsym
[19:23] <yofel> brunogirin: see https://wiki.ubuntu.com/DebuggingProgramCrash
[19:23] <brunogirin> yofel: yes, I'm currently trying to follow this: https://wiki.ubuntu.com/DebuggingWithApportRetrace
[19:24] <brunogirin> but it tells me: E: Unable to locate package libgnome-keyring0-dbgsym
[19:24] <brunogirin> am I missing some sources?
[19:25] <yofel> right, apport-retrace should fetch the neccessary dbgsym packages if you have the ddeb lines in your sources.list
[19:25] <brunogirin> yofel: how can I check that my sources.list is correct?
[19:26] <yofel> brunogirin: read the wiki page I linked to and check if you added those lines, the ddebs repositories aren't available by default
[19:26] <brunogirin> yofel: will do, thanks
[19:31] <penguin42> Is there a right way to nominate a bug for update during the maverick cycle?
[19:31] <penguin42> as in, yes I know it's missed the release but it would be good to not wait until the next version?
[19:34] <yofel> penguin42: only if it's universe/multiverse, main is in final freeze, only SRU-able uploads are permitted
[19:35] <penguin42> hmm, it is universe - I hadn't realised the freeze only applied to Main
[19:36] <yofel> hm, actually, if I read the mail right, only unseeded universe/multiverse packages may be uploaded until the 6th
[19:37] <charlie-tca> Yup
[19:37] <yofel> probably best if you ask in -devel
[19:37] <penguin42> yofel: It's bug 606063   it's unfortunate it's hung around for so long, but it's had a patch for over a month
[19:37] <ubot2> Launchpad bug 606063 in wireshark (Ubuntu) "[maverick] ERROR:capture.c:177:capture_start: assertion failed: (capture_opts->state == CAPTURE_STOPPED) (affects: 2) (heat: 58)" [Undecided,New] https://launchpad.net/bugs/606063
[19:37] <charlie-tca> but you can still tag the bug maverick, and ask
[19:38]  * penguin42 really should remember to nominate, most things I've reported that have been nominated have got fixed
[19:39] <yofel> that should be possible, since it's a bugfix and not a new package
[19:42] <hggdh> worst scenario it will come as an update
[19:43] <yofel> penguin42: how do you reproduce that bug?
[19:44] <penguin42> yofel: Start wireshark as root, (sudo wireshark), double click on eth0
[19:44] <brunogirin> yofel: I seem to have a conflict between libc6-dbg and libc-bin-dbgsym libc6-dbgsym; how can I solve this? remove libc6-dbg?
[19:44] <yofel> ah, I did a single click and wondered why nothing crashed ^^
[19:45] <yofel> brunogirin: yes, remove libc6-dbg
[19:45] <yofel> the -dbgsym and -dbg packages are usually (or always?) incompatible
[19:46] <micahg> penguin42: is that wireshark bug fixed in 1.2.11?
[19:47] <penguin42> micahg: No
[19:47] <brunogirin> yofel: that will remove valgrind, is that normal and can I re-install valgrind afterwards without re-installing libc6-dbg?
[19:48] <charlie-tca> Then remove the -dbgsym package instead
[19:49] <yofel> well, that's a dependency conflict I guess, you can always use debootstrap to create a chroot for apport-retrace
[19:49] <brunogirin> yofel: I'll look into that at some point, at the moment I can do without valgrind so not a major problem
[20:01] <njin> hello to all, i'm trying to launch apport-collect alsa-driver in maverick but i receive this error #failed to retrieve property `GtkTreeView::odd-row-color' of type `GdkColor' from rc file value "((GString*) 0x3262ea0)" of type `GString'
[20:05] <crimsun> njin: you probably want alsa-base, not alsa-driver; I can't reproduce that symptom
[20:05] <crimsun> penguin42: just to confirm, you applied gregor's patch onto maverick's source package of wireshark, correct?
[20:06] <njin> I'm trying with alsa-base
[20:08] <njin> alsa-base is a binary assigned to alsa-driver, nut me and the reporter can't run apport-collect
[20:08] <hggdh> brunogirin: keep the -dbg
[20:09] <hggdh> brunogirin: I opened a bug on this, asking for a Depends on libc6-dbg | the libc6-dbgsym(s), but it was closed wontfix
[20:09] <kklimonda> why?
[20:10] <hggdh> brunogirin: finally: valgrind will force back in libc6-dbg. This is *no* problem, mixing -dbg and -dbgsym from different packages
[20:11] <hggdh> kklimonda: because the maintainer decided so
[20:11] <hggdh> I did not agree, but had no arguments
[20:11] <hggdh> (and I asked for it exactly because of valgrind)
[20:11] <kklimonda> hggdh: debian maintainer?
[20:11] <hggdh> ours
[20:12] <brunogirin> hggdh: thanks, I'll do that when I'm done with my retrace
[20:12] <crimsun> njin: try switching GTK themes and again?
[20:12] <hggdh> kklimonda: Loïc, IRRC
[20:12] <kklimonda> hggdh: oh? I'm surprised.
[20:12] <yofel> well, eglibc builds one libc6-dbg but many *-dbgsym packages as -dbgsym are for the binary packages, not really compatible
[20:13] <hggdh> the -dbg has *all* symbols
[20:13] <hggdh> so it still ends up as being complete
[20:13]  * yofel wishes the buildds would just create -dbgsyms for source packages too :/
[20:13] <hggdh> +1
[20:14] <charlie-tca> hggdh: can not get ubuntu to install yet from the cd's. ubiquity keeps crashing today, and the alternate image is oversized
[20:16] <njin> crimsun: yes, in tty works
[20:16] <yofel> tty will use apport-cli not apport-gtk so that should always work for gtk errors
[20:16] <crimsun> and, you can then use apport-collect to push it to a bug report
[20:17] <crimsun> so, apport-cli --save foo alsa-base
[20:17] <hggdh> charlie-tca: no problem, and thank you for trying
[20:18] <charlie-tca> yw, I will keep working at it
=== evildante is now known as devildante
=== yofel_ is now known as yofel