[00:03] <Fallenou> asac < you see ? it's what it should be :p
[00:04] <asac> yeah ... maybe a bios thing?
[00:04] <asac> i have the same ethernet driver here and it works like a charm
[00:05] <Fallenou> hum but how do you explain that it works well on windows XP and gutsy ?
[00:05] <Fallenou> without touching the bios meanwhile
[00:05] <asac> hard to say ;)
[00:05] <Fallenou> =)
[00:05] <Fallenou> is it possible ? ^^
[00:06] <asac> everything is possible :)
[00:06] <asac> Fallenou: when did you upgrade to hardy?
[00:07] <Fallenou> on monday
[00:07] <Fallenou> but when i saw that it didn't work well (for the network) i installed from scratch with Hardy ISO CD
[00:07] <Fallenou> the same day
[00:07] <Fallenou> so it's not anymore an upgrade
[00:11] <asac> Fallenou: do you get any process with ps -eaf | grep dhcdbd
[00:11] <asac> ?
[00:13] <Fallenou> yes
[00:13] <Fallenou> one
[00:14] <Fallenou> root 5443 1 0 00:31 ? 00:00:00 /usr/sbin/dhcdbd --system
[00:15] <Fallenou> is it normal asac ?
[00:17] <asac> yes
[00:17] <asac> i assigned your bug to kernel package now
[00:17] <asac> i'd try to update bios and hope that its that.
[00:17] <asac> but that is just me ;)
[00:18] <Fallenou> ok thank :)
[00:18] <Fallenou> do you think i should remove/change/add some more information/file on the bug page ?
[00:19] <asac> no. if they need more information, they will probably ask
[00:19] <Fallenou> ok i will check the page everyday
[00:19] <Fallenou> thank you for your help and your time :)
[00:19] <Fallenou> 'im gonna borrow some network card tomorrow ^^
[00:20] <asac> maybe a good idea ;)
[00:20] <Fallenou> :)
[00:20] <Fallenou> thanks a lot, really
[00:20] <asac> np. sorry for being not more helpful ;)
[00:21] <Fallenou> you gimme your time that's the best you could do :)
[00:21] <Fallenou> good evening/night/morning
[00:21] <Fallenou> i'm going to bed =)
[04:09] <Deniz_Ogut> Hello is there anyone who can help me to decide what to do related with a vedy important bug related with xubuntu, Turkish locale. There's a report in launchpad written bya non-Turkish friend but some other people marked it as a duplicate of another bug; for me this is not the case. Would you please mentor me what to do?
[04:12] <JohnPhys> anyone having issues with the update to openssh-server on gutsy?
[04:12] <RAOF> JohnPhys: What sort of issues?
[04:12] <Savago> @all: anyone out there playing with bluetooth services? It seems that SDP is lacking somethings... it breaks with most of clients using serial port profile (ID list 0x1101).
[04:12] <RAOF> Your (stupidly compromised) SSH public key being denied?
[04:13] <RAOF> Deniz_Ogut: If you believe the bugs are not the same you can unmark it as a duplicate.  At the same time, you should provide information on the bug (which you are removing the duplicate status of) as to why you believe it to not be a duplicate.
[04:14] <Deniz_Ogut> @RAOF: Thank you. I'll do so.
[04:14] <JohnPhys> RAOF:  http://paste.ubuntu.com/11965/
[04:17] <RAOF> JohnPhys: Hm.  I haven't seen that; it's possible that the update is broken.  Have you checked launchpad?
[04:20] <JohnPhys> RAOF:  closest I can find is Bug #230147, but that bug is for hardy, which worked for me this morning.  I'm having issues with the gutsy package.
[04:22] <RAOF> JohnPhys: Hardy works for me, too.  I'd suggest filing a new bug, with /var/log/dpkg* and other such goodies.
[04:22] <JohnPhys> Should I mark it at as a security issue, since the update is a security-related one I think?  Or not?
[04:30] <Savago> I just found the bug (#227429). Is anyone working on this?
[04:30] <JohnPhys> RAOF:  Looks like the fix is already up ( Bug #230003 )  Odd that that didn't show up when I searched "openssh-server" but showed up in the bug report.  I guess I have to wait for the fix to trickle over to the mirror I use.
[04:33] <RAOF> JohnPhys: Maybe your mirror hasn't sync'd the new version yet?
[04:34] <RAOF> JohnPhys: Gah.  EWRONGCONTEXT.  Sorry.
[04:41] <JohnPhys> RAOF:  It's all right, they'll get it soon enough, I can wait for the update.
[04:48] <JohnPhys> RAOF:  as far as the ssh security vulnerability, I'm a little confused on the announcement:  https://lists.ubuntu.com/archives/ubuntu-security-announce/2008-May/000705.html  Is there anything I have to do besides upgrade the package?  Will that automatically re-generate the keys that are generated upon installation of openssh?
[04:48] <JohnPhys> RAOF:  I understand that if I manually generated any key pairs, those need to be regenerated, but what about automatically generated ones?
[04:49] <RAOF> Installing the package will automatically regenerate your server's host key.
[04:49] <RAOF> Everything else is up to you.
[04:49] <techno_freak> JohnPhys, it automatically regenrates the keys, but it's better to do it manually again
[04:50] <RAOF> techno_freak: Which keys?  AIUI, it's just the host key it'll touch?
[04:50] <JohnPhys> RAOF:  Ok.  I already removed my public ssh keys from the various servers I had them on.
[04:50] <techno_freak> RAOF, when it regenerates and again i test it with the dowkd.pl, it reports it to be weak
[04:50] <techno_freak> RAOF, i meant the user keys
[04:51] <RAOF> techno_freak: The package won't regenerate user's ssh keys; it can't.
[04:51] <techno_freak> RAOF, ah ok
[04:52] <RAOF> _Only_ the server's host key will be regenerated.  Any keypairs you've got need manual intervention.
[04:57] <JohnPhys> RAOF, techno_freak:  Thanks for the clarification.  Good thing I only have one set of user keys.
[04:58] <techno_freak> :)
[05:43] <gnomefreak> geser: yes i do i have already fixed my ssh key
[06:48] <LimCore> how to report a general bug that ubuntu fails
[06:48] <LimCore> how to see bug number 2?
[07:17] <LimCore> community needs reality check
[07:17] <LimCore> some people from ubuntu/debian call "trolldot" and gentoo trolls
[07:17] <LimCore> while ssh bug was introduced solely by debian team (afaik right?)
[07:28] <techno_freak> LimCore, what is your problem?
[07:29] <LimCore> techno_freak: X crashes easly
[07:29] <LimCore> let me check will it crash now as well after disabling compiz totally (uninstall)
[07:29] <techno_freak> LimCore, file a bug for us to help it get solved
[07:34] <LimCore> sigh
[07:34] <LimCore> techno_freak: ok.
[07:34] <james_w> LimCore: is there something you are doing to make it crash?
[07:34] <LimCore> james_w: one sec.
[07:35] <LimCore> yes, go to http://tech.slashdot.org/tech/08/04/30/1822237.shtml
[07:35] <LimCore> click on  "One post"
[07:36] <LimCore> there is this really long pidgin page.  scroll around up and down a bit
[07:36] <LimCore> works on nvidia (glx-new) amd64 bit
[07:36] <LimCore> "One comment"
[07:36] <techno_freak> is it your X crash or Firefox crash? neither for me
[07:37] <james_w> LimCore: Firefox 3?
[07:38] <LimCore> james_w: yes
[07:38] <LimCore> entire X crashes
[07:38] <techno_freak> LimCore, you mean it freezes up?
[07:38] <LimCore> no, it crashes (resets)
[07:38] <LimCore> Im back at login screen
[07:39] <LimCore> Im a devel, I know difference crash vs freez =)
[07:39] <techno_freak> hmm, i saw a similar bug
[07:43] <LimCore> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/230183
[07:46] <LimCore> do you also often find important bugs in ubuntu?
[08:06] <Yur1> hello
[08:07] <Yur1> could anybody help me with understanding of acpi-handling in hardy?
[08:08] <LimCore> can anyone comment on https://bugs.launchpad.net/ubuntu/+bug/230180 please
[08:09] <RAOF> LimCore: I'd comment that it's probably going to be marked invalid.
[08:09] <RAOF> By the title, but I'll read it first.
[08:10] <RAOF> LimCore: Basically, that's not very useful.
[08:10] <LimCore> what other way to confince ubuntu to put more effor in qa?
[08:11] <LimCore> I reported or confirmed number of such critical yet important bugs... I can link to them there
[08:11] <LimCore> the point
[08:12] <LimCore> is to look for systemic, strategic solution.
[08:12] <RAOF> Any suggestions?
[08:12] <LimCore> as I written there
[08:12] <LimCore> Perhaps it would be nice to create teams dedicated solely to
[08:12] <LimCore> 1. fixing in any way bugs in critical components. Workaround, older version, patch - no matter what but it really should Just Work
[08:12] <LimCore> 2. and a team reviewing security related code, especially in main systems like openssh
[08:13] <RAOF> We _already_ fix things when we can.
[08:13] <LimCore> I know.  therefore: "Since Ubuntu is backed up by real company, perhaps it would be possible to invest more into increasing such teams."
[08:13] <RAOF> Basically, your suggestion boils down to "do what you have been doing, except better".
[08:14] <LimCore> right
[08:14] <RAOF> And "make Canonical hire more Ubuntu devs" is not a bug in Ubuntu :)
[08:15] <Hobbsee> LimCore: find more people.  do it.
[08:16] <Hobbsee> LimCore: simple, no?
[08:16] <LimCore> Hobbsee: no
[08:16] <LimCore> Hobbsee: but I like RAOF's way
[08:17] <LimCore> hire more devels
[08:17] <Hobbsee> LimCore: then don't complain, unless you're either going to a) contribute useful effort to the project, or b) contribute money.
[08:17] <LimCore> b)
[08:17] <Hobbsee> go on, then.
[08:17] <LimCore> :)
[08:18] <LimCore> can someone uninvalid my bug report, when I post interesting idea for a solution there?
[08:18] <LimCore> (I dont want to univalid my own bug)
[08:18] <Hobbsee> is it actually a bug?
[08:19] <Hobbsee> sounds like something for the idea storm, or a mailing list, or something.
[08:19] <LimCore> any www gate to mailing list for this purpose?
[08:20] <RAOF> I don't believe so, no.
[08:21] <Hobbsee> www.hotmail.com / www.gmail.com ....
[08:21] <Hobbsee> webmail.isp.com ...
[09:12] <techno_freak> LimCore, try brainstorm for it rather than launchpad ;)
[09:12] <LimCore> techno_freak: url?
[09:13] <techno_freak> LimCore, http://brainstorm.ubuntu.com/
[09:13] <LimCore> nice
[09:13] <LimCore> it doenst share login with lunchpad?
[09:15] <stgraber> LimCore: nope, not yet
[09:44] <LimCore> after bootup,  VT-1 contains trash  "kernel alive"  "kernel direct mapping" text.   anyone knows that bug?
[09:44] <LimCore> how to report it, against what package? kernel?
[09:49]  * LimCore reported it in kernel,  https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/230204
[11:49] <copyofjohan> #205919
[11:51] <copyofjohan> hi, I hope I dont disturbe you to much, but I really need a workaround for this bug 205919. Do you have an idea?
[13:09] <asac> bdmurray: can you please extend bugcontrol-membership of fta?
[13:09] <asac> mail doesnt provide that option for him ... or he lost that mail
[13:12] <LimCore> since ubuntu have so many epic failures, like kformula (unusable in 8.04)
[13:13] <LimCore> how about providing easy way to install&use previous version of given program
[13:13] <LimCore> or perhaps this should be done by QA teams... if given appl is too buggy, then put the downgraded version as officiall one (so on aptitute upgrade clients will install the older but usable version)
[13:13] <Hobbsee> apt-get install foo=1.3.4
[13:14]  * Hobbsee suggests reading before advocating solutions, and also dropping the "people are incompetent" mentality.
[13:14] <LimCore> the point is to allow both versions at once on one box
[13:14] <LimCore> foo-1.3.4  foo-2.0  and foo is a symlink to one of them
[13:14] <seb128> what about fix the issues which make the thing unusable rather?
[13:15] <Hobbsee> seb128: that requires work, rather than just throwing other people's money at the problem, so LimCore doesn't want to do that.
[13:15] <LimCore> seb128: that will take months at avarage
[13:15] <LimCore> "throwing other people's money at the problem" ?
[13:16] <Hobbsee> sure.  you were talking about it earlier
[13:16] <seb128> there is no reason new versions should be that broken
[13:16] <Hobbsee> "just get canonical to hire more developers and qa people"
[13:16] <LimCore> Hobbsee: using MY money
[13:16] <seb128> downgrading is not a real solution
[13:16] <Hobbsee> LimCore: oh good.
[13:16] <LimCore> seb128: kformula. I used it for 10 seconds and found 2 ciricail bugs
[13:17] <LimCore> seb128: can't export to SVG, and can't read own native format .kfo
[13:17] <LimCore> Hobbsee: does the above entitle a bit "people are incompetent" mentality
[13:17] <seb128> seems to be a crappy software if they roll new version without testing if it can open things
[13:18] <LimCore> seb128: I just want to export one simple mathml into svg :'(  and it seems impossible in ubuntu... any other appl does that?  other seem to export only to gif and pdf
[13:18] <Hobbsee> interestingly, there don't appear to be any bugs for it on launchpad.
[13:19] <LimCore> Hobbsee: that is indeed interesting, as ~10 bugs showed up while I was reporting mine as possible duplicates
[13:19] <Hobbsee> nothing open, anyway
[13:19] <Hobbsee> https://bugs.edge.launchpad.net/ubuntu/+source/koffice?field.searchtext=kforumla&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_
[13:19] <Hobbsee> package=
[13:19] <Hobbsee> yay, launchpad.
[13:19] <LimCore> kformulas is part of koffice
[13:19] <LimCore> kformula is part of koffice
[13:20] <Hobbsee> yes, it is.
[13:20] <LimCore> https://bugs.launchpad.net/ubuntu/+source/koffice/+bug/61189
[13:21] <Hobbsee> ah, drat, i can't spell.
[13:21] <LimCore> actually, can someone please confirm my bug?
[13:21] <LimCore> formula is simple:  1. start kformula  2. type in "2+2"   3. file-export test.svg
[13:21]  * LimCore 8.04 amd64
[13:22] <LimCore> my bug is https://bugs.launchpad.net/ubuntu/+source/koffice/+bug/230243
[13:22] <Hobbsee> 1.6.5....that's the kde3 branch, isn't it?
[13:22] <LimCore> yes
[13:23] <LimCore> I will test -kde4 in a moment
[13:23] <Hobbsee> that's probably why it's not getting much attention from upstream.
[13:23] <LimCore> it is a rare occasion that one application can be trivially installed in 2 versions at once.   My idea was to allow that always easly, not just for kde3/4 transition
[13:25] <seb128> LimCore: there is no easy way to do that and that would be lot of extra work for few win
[13:25] <seb128> little win rather
[13:26] <Hobbsee> O.O
[13:26]  * Hobbsee marks an upstream bug.  without pain!
[13:26] <LimCore> Hobbsee: related to kformula or other topic?
[13:27] <LimCore> kformula-kde4 doesnt work as well.. they simple removed the export to SVG.........
[13:27] <Hobbsee> LimCore: added an upstream bug to one of your kformula
[13:27] <LimCore> \o/
[13:27] <Hobbsee> LimCore: interestingly, http://bugs.kde.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&product=kformula&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bugidtype=include&bug_id=&votes=&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&
[13:27] <Hobbsee> order=Importance&cmdtype=doit is the only stuff filed for kformula, that's open.
[13:27] <LimCore> I'm a happy when without any reading and with people are incopetent mentallity I still manage to report meaningfull bugs.
[13:28] <LimCore> ok seriously.  Can I at all export mathML file to SVG using ubuntu?
[13:29] <LimCore> Hobbsee: I dont understant what you ment by last statement
[13:29] <Hobbsee> dunno.  check google.
[13:29] <Hobbsee> LimCore: that query is all the stuff in the kde bugtracker that's open, for kformula
[13:30] <LimCore> http://tinyurl.com/6377xh
[13:30] <seb128> LimCore: try asking on #ubuntu, there is lot of softwares in universe and some people might use mathml there
[13:31] <LimCore> seb128: I ask on serveral channels and searched in synaptic
[13:31] <LimCore> it seems that no.
[13:32] <Hobbsee> LimCore: no one does kde questions, btw.
[13:32] <seb128> you can try abiword, it seems abiword-plugins uses libgtkmathview
[13:32] <LimCore> seb128: good idea
[13:32] <seb128> otherwise libgtkmathview-bin might have some tools to do that
[13:32] <Hobbsee> LimCore: and it's not an area, so far, that canonical has wanted to invest in further, and doesn't seem like it will in future.
[13:33] <LimCore> you are saying this in reference to what? to investing into say kde bugfixes?
[13:33] <Hobbsee> your open question on kdebase, about compiz.
[13:33] <Hobbsee> oh
[13:33] <LimCore> oh right
[13:33] <Hobbsee> yes.
[13:34] <Hobbsee> effectively
[13:34] <LimCore> I was thinking
[13:34] <LimCore> you know vim model?
[13:34] <LimCore> pay for vim to vote what to fix
[13:34] <LimCore> (or develop)
[13:35] <Hobbsee> i'm sure you could contract someone to work on kde for you, if you wished.
[13:35] <LimCore> I can just donate myself, but without organized action its ineffective
[13:35] <LimCore> exacly.  one person with 100 usd  -vs- 100000 ubuntu users * 10 usd
[13:36] <Hobbsee> so, organise it.
[13:36] <LimCore> what do you think about this idea
[13:36] <Hobbsee> sounds good, if someone actually does it.
[13:37] <LimCore> example: in 2012 5.000.000 linux users payed 5*5.000.000 usd annual license. 15% goes to KDE 5% to kernel 5% to compiz/xgl/etc  [...] 0.004% to kformula   etc
[13:37] <Hobbsee> go ahead and organise it, then :)
[13:37] <LimCore> ok
[13:38] <LimCore> in the meantime, do you think its justified that I think that kformula ubuntu developer REALLY did a bad, bad job?
[13:38] <LimCore> U are a devel right? can you set importance of this bug?
[13:38] <seb128> you assume that there is a kformula ubuntu developer which might not be the case
[13:39] <LimCore> Latest release:  1:1.6.3-5ubuntu2
[13:39] <LimCore> Uploaded By:  Jonathan Riddell
[13:39] <seb128> upstream did a bad job rolling a buggy new version
[13:39] <LimCore> Maintainer:Maintainer:  Ubuntu Core Developers  Ubuntu Core Developers
[13:39]  * LimCore stupid mouse button
[13:39] <seb128> welcome to the kde world, koffice is not only kformula I guess
[13:39] <jdavies> LimCore: doesn't mean he wrote it
[13:39] <Hobbsee> LimCore: you don't get it.  for the most part, the ubuntu developers don't work on the individual apps.
[13:39] <LimCore> Hobbsee: I really do know that
[13:39] <Hobbsee> seb128: and neither is kde koffice :)
[13:39] <seb128> updating the source package doesn't mean working on all the softwares is ships
[13:39] <jdavies> LimCore: look under Help -> About KFormula for the dev names
[13:40]  * LimCore makes a bitter joke what happens when distro devels apply own patches for dsa  (well ok, thats debian)
[13:40]  * Hobbsee makes a bitter joke about users who try to manage everything from their armchairs, and are very happy to throw blame around, seeing as they pay money, so zomg everyhting should be fixed for me, right now.
[13:41] <Hobbsee> hmmm.  i wonder if i can add a filter on listadmin.
[13:41] <LimCore> Hobbsee: if in this case user is not entitled to complain, then when?
[13:42] <seb128> complaining is not really constructive
[13:42] <Hobbsee> LimCore: sure, you can complain.  whether people help you is an interesting question.  especially if you're blaming everyone.
[13:42] <seb128> make sure to report issues that's constructive
[13:42] <LimCore> but I see your point Hobbsee. and I dont know what can I realistically do to fix things.. I'm not rich to sponsor entire team to fix all buggs I find
[13:42] <Hobbsee> or at least, people who's fault it isn't.
[13:42] <seb128> well, complaining that other people don't do that either will not fix those issues
[13:43] <seb128> report the issues you find and try to provide require details
[13:43] <LimCore> I do all the time
[13:43] <seb128> and try writting a patch if you really want to contribute
[13:43] <askand> Hi, what are the chanses that bug 147883 will get into hardy-proposed?
[13:43] <LimCore> then I wait... and wait, and....
[13:44] <seb128> askand: I've a hardy update on my disk, I'm just waiting for upstream feedback for the patch I attached to bugzilla
[13:44] <Hobbsee> 100 / 700 done!
[13:44] <askand> ﻿ seb128: nice, thanks
[13:44] <seb128> you are welcome
[13:44] <LimCore> kformula-kde4 seem to not have at all SVG export. am I doing something wrong?  perhaps I should report that too?
[13:45] <Hobbsee> LimCore: do us all a favour, and report it on bugs.kde.org
[13:46] <Hobbsee> the developers are there, who actually code the app
[13:46] <LimCore> ok
[13:54] <LimCore> ok I tried abiword
[13:56] <LimCore> https://bugs.launchpad.net/ubuntu/+source/abiword/+bug/187034
[14:31] <bddebian> Boo
[14:33] <geser> foo
[14:33] <ogra> bee
[14:33] <bddebian> :)
[15:35] <Hobbsee> bdmurray: ping
[15:36] <Hobbsee> bdmurray: you may want to get https://launchpad.net/~sebastian-ro to do something more useful - looks like he's deciding to mark sync and merge bugs as wishlist.  i'm sure you can find other bugs which are far more useful for him to look at, which no one else has seen.
[15:37] <Hobbsee> people wasting their time is never a good idea :\
[15:39] <pck-chem> He's probably doing it out of ignorance, I had no idea dev's used launchpad to track their work until the recent email exchange on the mailing list :/
[15:39] <Hobbsee> likely.
[15:39] <Hobbsee> of course, the way to stop people being ignorant is to write documentation warning them what not to touch.
[15:40] <pck-chem> We'll, I
[15:40] <Hobbsee> pck-chem: that's the thing.  we've had 3 contributors in the past couple of weeks who have been repeatedly changing those types of bugs.  yet out of all the bugs, they're only a small part.
[15:41] <Hobbsee> pck-chem: i'm starting to think that they're going out and looking for them, because, as you rightly point out, most people don't know about them, and most people don't touch them
[15:41] <Hobbsee> the chances of multiple people managing to find a whole chunk of bugs that they should be ignoring, which are only a small subset of the reported bugs is quite low.  yet multiple people manage.
[15:42] <Hobbsee> and there are still stacks of bugs that people aren't seeing.
[15:42] <pck-chem> Hobbsee:  Well, I understand, but I'm not getting into it anymore than the emails have already. My personal opinion is that people shouldn't even bother with that kind of stuff when there are hundred of unpackaged/totally untriaged bugs but I can see both sides of the issue here.
[15:42] <Hobbsee> exactly!
[15:49] <thekorn> Hobbsee, out of curiosity: can you please give me a bug number of a bug this guy messed up
[15:49] <Hobbsee> norsetto: ^
[15:49] <Hobbsee> launchpad isn't letting me see the exact ones.
[15:50] <thekorn> all bugs he marked as wishlist have none of these dev-teams subscribed
[15:51] <norsetto> [16:16] <norsetto> seems like somebody had the great idea to mass-create needs-packaging bugs for all lp hosted projects
[15:51] <norsetto> [16:27] <norsetto> scottk: and there is already somebody busy filing them all as wishlist ... so much so for bug triaging
[15:51] <james_w> Hobbsee: you said sync/merge bugs, but this time the discussion started with needs-packaging, did he move on to others?
[15:52] <Hobbsee> james_w: oh, even better.
[15:52] <Hobbsee> that's the one category i didn't put in.
[15:53]  * Hobbsee can see all the importance-only changes, but not bugs that they were added to.
[15:53] <Hobbsee> silly advanced search.
[15:54] <Hobbsee> oh well.  i'm sure that if he wants to create bugs for every piece of software on launchpad that's not in the archives, he can.
[15:54] <Hobbsee> i'm sure there's more useful stuff for him to be doing, though.
[15:54] <Hobbsee> as long as he closes them when the software packages get added to ubuntu, whether those be syncs, etc, or whatever.
[15:54] <Hobbsee> so he's not adding to bug cruft, instead of triaging it.
[15:55] <james_w> Hobbsee: there are two people here, one is adding the bugs, the other is wishlisting them and adding the needs-packaging tag.
[15:56] <Hobbsee> fun.
[15:56] <Hobbsee> the first is wasting his time, effectively, and the second could find more productive things to do, if the first stopped.
[15:58] <hggdh> thekorn: see bug 230234 for an example of what Hobbsee is talking about
[15:59] <norsetto> and apparently none of the two checks for dupes, I can see at least two ....
[16:00] <Hobbsee> norsetto: which means that any doc probably wouldn't have helped, as they clearly didn't read it anyway.
[16:01] <hggdh> Hobbsee: ^^ agree :-(
[16:01] <Hobbsee> in which case, does something get done about them, before they become more kmos-like?
[16:02] <hggdh> this, I guess, is a question for bdmurray and ogasawara_. I do not have ways of reaching them (none that I have seen publishes email addresses).
[16:03] <hggdh> but I have a bug Seb Rode subscribed to -- I can add a comment asking him to come here
[16:06] <pck-chem> SHIT
[16:06] <pck-chem> https://bugs.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
[16:06] <pck-chem> sorry for the curse
[16:06] <pck-chem> check that out
[16:07] <hggdh> well, the good part is only a few got set to wishlist ;-)
[16:08] <pck-chem> What are those bugs doing on my "These need triaged" search
[16:08] <Hobbsee> pck-chem: close them, with "if you want to package them, feel free, else you're just creating needless cruft"
[16:08] <Hobbsee> :P
[16:09] <hggdh> Hobbsee: now a question for you -- please do not get me wrong: how can bug triagers decide what is a legitimate needs-packaging, and what is not?
[16:09] <qense> hello
[16:10] <Hobbsee> hggdh: they're all "legitimate"
[16:10] <pck-chem> qense: Hi
[16:10] <Hobbsee> hggdh: however, creating bugs for them, when they're mostly synced from debian, etc, anyway, and when relatively get in thru ubuntu, just adds to ubuntu bug cruft, as no ubuntu people are actually looking to package them, and to close those bugs.
[16:10] <Hobbsee> hggdh: so, is there any point in filing them, and/or keeping them open?
[16:11] <Hobbsee> hggdh: particularly when there's no rationale for why we might want them there, etc.
[16:11] <Hobbsee> hggdh: also, filing needs-packaging bugs for everything in the FOSS world will never scale.
[16:11] <Hobbsee> (in terms of everything getting packaged)
[16:12] <Hobbsee> hggdh: and as was said above, they're not even checking for dupes now - are they planning to coem back every release, and see if we've gotten the package from debian?
[16:12] <Hobbsee> hggdh: the new packages from debian are on an autosync.
[16:13] <pck-chem> Would anyone seriously mind if I "Invalidated" them all because this is not what launchpad is for?
[16:13] <Hobbsee> pck-chem: not at all.
[16:13] <Hobbsee> pck-chem: if you do it by mail, you should be able to kill them all in one hit.
[16:13] <pck-chem> Hows that?
[16:13] <Hobbsee> suggest that the guy follows <insert docs here> and works on <random list of bugs>
[16:14] <Hobbsee> pck-chem: help.launchpad.net/UsingMaloneInterface or something.
[16:14] <Hobbsee> pck-chem: https://help.launchpad.net/BugTrackerEmailInterface
[16:14] <Hobbsee> it changed names.
[16:15] <pck-chem> Just making sure we're on the same topic, you want me to close bugs like #230281 because they have no place in launchpad right?
[16:15] <pck-chem> ﻿230281
[16:15] <Hobbsee> bug 230281
[16:16] <Hobbsee> pck-chem: because there are other ways to track them, it's unfeasible to file that everything needs packaging, and that these bugs don't get automatically closed if someone in debian packages them, which is often the case, yes.
[16:17] <pck-chem> Thats what I was thinking, I just wanted to make sure not to massively piss someone off because I closed 30 of their "bugs"
[16:17] <Hobbsee> oh, i'm sure you'll annoy him.
[16:17] <hggdh> Hobbsee: I understand the rationale, and I agree with it -- but I am (was) a developer also
[16:17] <Hobbsee> but, if he's going to proceed on a useless path like that, the only real option is that he gets frustrated :)
[16:18] <Hobbsee> the more he does of it, the more he gets frustrated.
[16:18] <pck-chem> We'll like I said I think it needs to happen I just wanted to make sure someone would have my back if crap hit the fan.
[16:18] <Hobbsee> hggdh: true.
[16:18] <Hobbsee> pck-chem: yeah, we will.
[16:18] <hggdh> but I think we need a a bit more of documenting on the "filling [needs-packaging] bugs
[16:19] <Hobbsee> pck-chem: mind you, if he hasn't read bugsquad docs, he likely wouldn't be able to read or use enough thought to know how to complain :)
[16:19] <Hobbsee> hggdh: true.  MOTU has some on it.  However, bugsquad and documentation.....
[16:19] <Hobbsee> hggdh: you have to get them to agree to it at UDS, else they'll just revert it.
[16:20] <Hobbsee> like they did with my edit.
[16:20] <hggdh> Hobbsee: it is not only bugsquad, but the whole process that will have to be revisited. I think this is partially due to the success we had on Ubuntu
[16:21] <Hobbsee> likely
[16:21] <pck-chem> hggdh: Agreed
[16:21] <Hobbsee> there were discussions in sevilla about it.  unfortunately, little fo it came out
[16:21] <pck-chem> I see this as a problem with a non-traditional use of launchpad, not a problem with bugsquad.
[16:22] <Hobbsee> yet no one's actually proposed a better solution.
[16:22] <Hobbsee> it would be nice if launchpad grows a workflow thing, and we can convert bugs to workflows, etc.
[16:22] <hggdh> pck-chem: I agree... and perhaps this was why Hobbsee's edit was reverted
[16:22] <pck-chem> and I understand, which is why I said before I see both sides :)
[16:22] <Hobbsee> OTOH, that wouldn't happen for at least a couple of years.
[16:22] <Hobbsee> so finding a solution *now* is a good idea.
[16:23] <hggdh> Hobbsee: 100% with you
[16:23] <hggdh> Hobbsee: unfortunately I will not participate in UDS
[16:23] <Hobbsee> hggdh: why?
[16:24] <pck-chem> Couldn't we just make "ubuntu-workflow" a "package" and just report all workflows against that instead of Ubuntu?
[16:24] <hggdh> Hobbsee: (1) far from me; (2) business conflicts; (3) remember, I am an "incognito" ;-)
[16:25] <pck-chem> Its another non-traditional use, but it would keep devs and bugs from mixing in the Ubuntu package.
[16:26] <pck-chem> *project not package excuse me
[16:26] <hggdh> pck-chem: LP *can* be used this way, all we need is rules and -- perhaps -- a new status (and corresponding finite-machine changes)
[16:26] <james_w> pck-chem: it's an interesting idea.
[16:27] <pck-chem> hggdb: True but canonical would have to dig into launchpad's internals do you think that could happen on a timely basis?
[16:28] <Hobbsee> hggdh: pity.  although i doubt that tehy'd insist on real names.
[16:28] <Hobbsee> pck-chem: giving devs 2 places to check when doing anything.  great.
[16:28] <Hobbsee> pck-chem: (they check for existing bugs, too)
[16:28] <hggdh> pck-chem: it can -- after all, that's the whole idea on having Lp in the first place
[16:28] <Hobbsee> it's also an abuse of packages
[16:29] <hggdh> Hobbsee: yes... given my experience on both sides of the fence, I think I could help
[16:29] <pck-chem> Hobbsee: Like I said <--lowley triager. Just throwing out ideas.
[16:30] <hggdh> Hobbsee: it is indeed an abuse of packages, but the current dev usage is also an abuse of bugs ;-) we need to find a common ground
[16:31] <pck-chem> hggdh: Thanks, what I was attempting to express.
[16:38] <hggdh> Hobbsee: in fact -- *where* is the next UDS? I cannot find it online...
[16:41] <james_w> hggdh: Prague
[16:41] <james_w> if you mean the one next week.
[16:42] <hggdh> james_w: thanks. Indeed, quite far from Dallas, TX :-) and I am back from Paris for good :-(
[16:42] <hggdh> (darn! I *was in Prague last November!)
[16:44] <james_w> hggdh: when we were all in Boston, MA? :-)
[16:52] <pck-chem> anyone know what to report bad iso's against? I've always just passed these over. bug 230189 for example
[16:54] <bdmurray> pck-chem: I'm looking at the bug but it seems unlikely
[16:54] <stgraber> the images are ok, so I would blame the user's burning software
[16:55] <bdmurray> They should check the md5sum of the iso they downloaded
[16:55] <stgraber> looks like the problem here is Roxio giving errors, so clearly not an Ubuntu bug
[16:55] <bdmurray> And it'd be helpful if you found out the url that used to download it
[16:56] <pck-chem> They said three different sites, three different softwares failed. Thats why I felt this was possibly legitimate
[16:57] <ffm> pck-chem: They have a bad burner.
[16:58] <bdmurray> ffm: They said 3 different systems
[16:58] <ffm> bdmurray: Ah.
[16:59] <stgraber> bdmurray: packing your stuff for Prague ? :)
[16:59] <pck-chem> Again my question, should I report it against a certain package? or just leave it Ubuntu?
[16:59] <ogra> stgraber, who is not :)
[16:59] <bdmurray> stgraber: yep
[17:00] <stgraber> ogra: those not coming to FOSSCamp :)
[17:00] <ogra> ah, well, they can package later :)
[17:00] <ogra> *pack
[17:00] <ogra> .oO(to much work in my head)
[17:01] <bdmurray> pck-chem: just leave it to Ubuntu but it'd be good to get some more information out of the reporter
[17:02] <pck-chem> bdmurray: roger. Quick question I've been meaning to apply for bugcontrol can you handle that now or should I send the email?
[17:04] <bdmurray> pck-chem: Could you e-mail it to me?  I should be packing now.
[17:04] <pck-chem> bdmurray: Sure, have fun in prague.
[17:07] <greg-g> need assitance on bug 198292 , specifically, should I mark this as an intrepid milestone so it gets looked at/fixed before that round of dist-upgrading?
[17:08] <bdmurray> greg-g: This is affects gutsy2hardy too right?
[17:10] <greg-g> bdmurray: correct
[17:10] <greg-g> and I just took a look at all bugs reported against motion, there are at least 3 other dupes there
[17:10] <bdmurray> So it might be good to have it looked at for 8.04.1
[17:11] <greg-g> ah, yeah, forgot about that release
[17:11] <greg-g> so should I milestone it?
[17:11] <bdmurray> So you could nominate it for Hardy, and I'll approve it.
[17:12] <greg-g> will do
[17:12] <greg-g> and done
[17:13] <bdmurray> then you could milestone the Hardy task or I'll do it
[17:13] <LucidFox> seb128: reuploaded f-spot debdiff
[17:13] <greg-g> to 8.04.1 correct?
[17:13] <seb128> LucidFox: thanks
[17:14] <pck-chem> How long does it normally take malone to respond to email commands? I've waited about 15 minutes now and received neither a failure or success message.
[17:14] <bdmurray> greg-g: right and it seems status and importance aren't inheriteed
[17:14] <bdmurray> pck-chem: did you gpg sign the e-mail?
[17:15] <pck-chem> bdmurray: Yessir. The help said if I didn't I would at least receive a failure email.
[17:16] <bdmurray> pck-chem: if you pastebin the e-mail I could look at it.  15 minutes should be enough
[17:17] <greg-g> bdmurray: done
[17:17] <pck-chem> bdmurray: Pastebin ?
[17:17] <greg-g> bdmurray: thanks for taking the time, I know you're busy
[17:17] <greg-g> !paste
[17:18] <greg-g> pck-chem: ^
[17:18] <pck-chem> http://paste.ubuntu.com/12076/
[17:19] <bdmurray> pck-chem: What e-mail address did you send it to?
[17:19] <pck-chem> 230127@bugs.launchpad.net
[17:20] <pck-chem> bug 230127
[17:20] <pck-chem> whoops
[17:20] <pck-chem> bug 230271
[17:21] <pck-chem> went dsylexic there.
[17:21] <bdmurray> what is your launchpad username?
[17:21] <pck-chem> Patrick Kilgore
[17:24] <bdmurray> pck-chem: is the gpg key you signed your mail with the same one in launchpad?
[17:25] <pck-chem> bdmurrary: Yes sir.
[17:25] <LimCore> btw, are all developers needed to create new ssh keys?
[17:26] <ffm> LimCore: Yepper.
[17:26] <ffm> LimCore: Assuming you were affected.
[17:26] <LimCore> I ment ubuntu developers
[17:27] <LimCore> will they all create new keys
[17:27] <ffm> LimCore: Yeah, assuming _they_ were affected.
[17:27] <LimCore> for themselves when managing ubuntu repository
[17:27] <ffm> LimCore: Packages are signed with gpg, so no compromise there.
[17:27] <Pici> LP removed the ssh keys.
[17:27] <ffm> LimCore: Repos are intergrated with lp's ssh key manager.
[17:27] <ffm> It's very nice actually.
[17:28] <bdmurray> pck-chem: hmm, I'm not sure then
[17:29] <pck-chem> bdmurray: Old fashioned way I guess. Thanks for trying.
[17:33] <bdmurray> pck-chem: I'm not certain marking that bug as Invalid is the best idea
[17:34] <pck-chem> bdmurray: What should happen then? We had about a half hour discussion earlier. This guy is cluttering up launchpad.
[17:35] <hggdh> pck-chem: this bug 230127 is interesting... needs-packaging for something that does not even have code available
[17:35] <hggdh> darn it! now it is _my_ time to go dyslexic
[17:35] <pck-chem> lol
[17:36] <bdmurray> My concern is there is a lot of documentation in the wiki that says filing a needs-packaging bug is the right thing to do
[17:36] <pck-chem> All of these submissions are confusing, unpackage, and taking up a lot of real estate on https://bugs.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
[17:36] <bdmurray> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[17:36] <pck-chem> Which is the primary link for finding unpacked/new bugs
[17:36] <hggdh> bdmurray: how can we package something that does not even been written yet?
[17:36] <hggdh> s/does/has/
[17:37] <bdmurray> My point was more the idea of closing needs-packaging bugs as Invalid
[17:38] <hggdh> yes, I agree, and I asked Hobbsee the same -- how can bug-triagers mess with dev stuff?
[17:38] <bdmurray> pck-chem: If you added importance not wishlist to your query would that help.
[17:39] <bdmurray> I could wishlist the needs-packaging bugs fairly quickly
[17:39] <pck-chem> bdmurray: I got this link from the wiki, should I update it there as well?
[17:39] <pck-chem> and should I set needs-packaging to wishlist in the future?
[17:40] <bdmurray> pck-chem: regarding the wiki url that'd be great
[17:41] <hggdh> pck-chem: how to deal with [needs-packaging] is what is going to be discussed at UDS
[17:41] <bdmurray> hggdh: cool, I missed that in the backscroll then
[17:42] <hggdh> I would recommend to wait until UDS is done (and -- hopefully -- an agreement has been reached on how to deal with dev bugs)
[17:43] <pck-chem> Hmm found another report about bad amd64 8.04 image...
[17:43] <hggdh> bdmurray: do you have a way of contacting the triagers that are changing the dev bugs?
[17:44] <bdmurray> their e-mail address is in the bug mail they send
[17:44] <bdmurray> So, yes
[17:45]  * hggdh does not subscribe to all bugs updates anymore... got buried in them...
[17:45]  * thekorn waves
[17:47] <hggdh> bdmurray: just went to lists.ubuntu.com, and looked up the archives of ubuntu-bugs: no archive after March 2007!!
[17:47] <bdmurray> hggdh: only the mboxes are available
[17:48] <hggdh> bdmurray: where are they?
[17:48] <bdmurray> additionally gmane carries the ubuntu-bugs mailing list
[17:49] <hggdh> should we then update  https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs to point to gmane for archives?
[17:49] <bdmurray> I'll add that to my todo list
[17:50] <hggdh> I guess I do not have authorisation  to change it?
[17:50] <bdmurray> I think only the mailing list admin would
[17:51] <hggdh> ah well.
[17:51] <hggdh> mdz, I guess
[17:51] <thekorn> wow, is bug 230234 really the reason for 2 hours of a "don't touch workflow bugs"-discussion?
[17:51] <hggdh> thekorn: I think it is just one of a sequence
[17:53] <thekorn> IMO, the triager did nothing wrong
[17:54] <hggdh> seb128: hello, and are you aware of any problems with evo and gnome-keyring?
[17:54] <mmm4m5m> hi all. I think I found a bug. Does someone want to check it? This is not working:  dialog --editbox "file_name" 20 20 >/dev/tty
[17:54] <thekorn> no chance for him to know if this is a packaging bug or not, such a report looks more like invalid for me
[17:54] <mmm4m5m> error message is: 'Segmentation fault (core dumped)'
[17:55] <hggdh> thekorn: I do not completely disagree, but it just shows that we really, really need to get some sort of agreement done at UDS
[17:55]  * pck-chem can't wait until they figure out workflow bugs because god knows we've talked about it enough.... 
[17:55] <mmm4m5m> I am using ubuntu gutsy
[17:55] <seb128> hey hggdh, what kind?
[17:55] <seb128> hggdh: we have "evolution can't store different password for different protocols on the same server"
[17:56] <seb128> hggdh: is, smtp and pop on the same server using different password
[17:56] <hggdh> seb128: k, not this, so it is probably new: sometimes my evo hangs
[17:56] <seb128> hggdh: and we have "evolution forget the passwords when using gpg"
[17:56] <hggdh> I have been running under gdb, and a bt on the hang shows gnome-keyring driven, but in wait
[17:57] <hggdh> guess its brand new, then :-(
[17:57] <hggdh> seb128: is the gnome-keyring a Ubuntu change, or was it done upstream?
[17:59] <seb128> hggdh: upstream, we just switched recently to it though
[17:59] <thekorn> hggdh, but the agreement can not be to add 100 exceptions to the howtotriage wiki-page, like dont't touch bugs with subscribers ..., with tags ..., with titles like ...
[17:59] <seb128> hggdh: I didn't want to ask users to re-enter their passwords
[17:59] <seb128> hggdh: but mbarnes added passwords migration code to the gnome-keyring in 2.22.1.1
[17:59] <thekorn> hggdh, it's more the devs who have to think about their workflow and usage of LP
[18:00] <hggdh> seb128: I agree, and I saw the dialogs. I wil dig into the bt
[18:00] <seb128> ok
[18:00] <hggdh> thekorn: I would humbly suggest we need to collaborate -- a common solution would benefit all
[18:01] <thekorn> hggdh, I agree
[18:01] <hggdh> thekorn: for better or worse, dev uses LP bugs, possibly because this is the only thing they could get that would "work"
[18:03] <hggdh> so methinks a meet-in-the-middle would benefit all. I think bdmurray or ogasawara_ will drive this at UDS, and hopefully we will all be set
[18:03] <thekorn> hggdh, IMO it would really help if they could point us to messed up bugs and a percentage of workflow-bugs and wrong triaged ones
[18:05] <hggdh> seb128: one think I noticed after upgrading to 2.22.1.1 is that every so often, on a new run of evo, I would be asked to deny/one/always authorise evo to look in the g-k storage. I would expect that this would be done just once, the first time evo came up with g-k integration. This is weird, and I cannot account for it
[18:06] <seb128> hggdh: well, on the first keyring use in your session you need to unblock the keyring if you use autologin
[18:06] <hggdh> thekorn: I agree. So far I only saw one bug that scottk blasted the triager.
[18:07] <hggdh> seb128: yes, but I got the prompts for all my emails, and on _multiple_ evo sessions (one different email per session)
[18:07] <seb128> hggdh: are you sure those are keyring prompts?
[18:07] <seb128> hggdh: do you have a screenshot showing one of those?
[18:08] <hggdh> seb128: sure -- no. The dialog does not state who is asking for it. But it was asking to allow/deny access to the email account password. And, no, unfortunately I did not screenshoot it
[18:09]  * hggdh is rather slow lately
[18:09] <seb128> ok, deny or allow access seems a keyring thing
[18:09] <seb128> otherwise you would get the password text entry and the checkbox to store the password
[18:09] <hggdh> yes, this is why I thought of keyring
[18:09] <seb128> I start thinking we should revert the keyring use
[18:09] <seb128> though have passwords not encrypted is not optimal either
[18:10] <hggdh> clear-text (or xor-ed) passwords is really not cool
[18:10] <hggdh> but I agree with you: I wonder if this is the moment for g-k integration
[18:11] <hggdh> but I have not seen anybody else complaining about this hang I got, so... there is still a chance
[18:12] <hggdh> but I saved the core on the last hang, so I can gdb back into it. I will try it, and see what I find
[18:13] <thekorn> bdmurray, if you have a minute, can you please renew my u-bugcontrol membership
[18:21] <geser> anyone an idea what to do with bug 230350 till LP gets fixed? ignore?
[18:32] <james_w> geser: what's the bug, lp is timing out for me?
[18:32] <james_w> or is that what you mean?
[18:47] <sectech> Anyone know gnome-system-monitor well?  I am triaging an issue that claims the free diskspace is being reported incorrectly... I was just wondering how they calculated it... 1MB = 1024K or 1000K?
[18:47] <sectech> df claims I have 30.0GB free and system monitor says 29
[18:47] <sectech> bug #230379
[18:52] <CarlFK> Bug #22301
[18:52] <CarlFK> bg #22301
[18:53] <CarlFK> bug #22301
[18:53] <CarlFK> cookie.
[18:54] <geser> james_w: exactly, someone added so many tasks that LP can't handle the bug anymore :(
[18:54] <james_w> ah, ok.
[18:54] <james_w> Is that the Original-Maintainer bug?
[18:55] <CarlFK> anyone want to poke at a 3 year old bug?
[18:56] <ogra> geser, please invalidate many of these packages listed there are not even in debian
[18:56]  * ogra points to ubuntu-calendar-*
[18:57] <ogra> that script is missing checks first place
[18:57] <geser> ogra: I hope the email interface still work on this bug
[19:02] <hggdh> CarlFK: which bug?
[19:04] <CarlFK> ﻿Bug #22301
[19:04] <sectech> gnomefreak, you around?
[19:06] <hggdh> CarlFK: I see no updates since 2007. Are you suffering from it?
[19:07] <CarlFK> hggdh: yes
[19:07] <CarlFK> hggdh: I dumped all my config stuff here http://dev.personnelware.com/carl/temp/May14/b/dhcp11/
[19:07] <CarlFK> and did the ln workaround
[19:07] <hggdh> did it work?
[19:08] <CarlFK> yup
[19:08] <hggdh> what Ubuntu version you are running?
[19:08] <CarlFK> hardy
[19:09] <hggdh> CarlFK: thanks. Can you please update the bug with your experience? It is indeed good to know it is still present in Hardy.
[19:09] <CarlFK> will do
[19:10] <hggdh> CarlFK: and I will set it to triaged -- all we can do here
[19:15] <sectech> hggdh,  you wouldn't know how they calculate the free diskpace in gnome-system-monitor would you? :P
[19:24] <greg-g> sectech: I'm not sure how they calculate it, but it looks like it would be in the disks.cpp file in the source
[19:25] <hggdh> sectech: sorry, no. But I guess looking at the code should give us it
[19:26]  * greg-g is looking right now, but it looks like they are calling some premade function, not sure yet
[19:26] <sectech> I could dig through the source code...  29GB is pretty close to 30GB though...  I'm not sure if they consider some hd space reserved or not
[19:27] <sectech> At least I'm doing better then the reporters "0MB free"
[19:33] <hggdh> sectech: on the source, if the disk being looked at is not a real device, it is all set to zero
[19:34] <sectech> Ahhh I see
[19:35] <hggdh> CarlFK: please tar/zip your config, and attach it to the bug -- this way it will survive more than 2 weeks
[19:36] <hggdh> sectech: what is the bug #?
[19:36] <sectech> hggdh,  230379
[19:37] <sectech> It looks like this guy has a laptop...   I don't have any hardware info added with the bug though
[19:37] <sectech> (just going by the screen shot)
[19:39] <hggdh> sectech: it might be interesting to find out what the filesystem tab shows
[19:40] <hggdh> sectech: but this difference does not really sound like being a MiB vs MB
[19:41] <sectech> See I didn't know that if gnome doesn't see the device as real it will set it to 0..(like you said)...I bet you that's what's happening
[19:42] <sectech> I'll ask for the output of pci -vvv and a screensnap of the filesystem tab
[19:42] <sectech> .... might help if I had the laptop make/model as well... it might be an existing bug
[19:45] <sectech> My battery is running low, time to head home... bb later
[20:30] <\sh> g'day
[20:30] <jderemer> hello
[20:30] <jderemer> :)
[20:31] <greg-g> ello
[20:31] <\sh> guys, a bug report with a stack trace of a stable package and no .crash report != "invalid bug report"
[20:32] <\sh> please ask people for the steps of reproducing it...but don't "invalid" the report, because it's just like a "close and get rid of the crap report"
[20:33] <\sh> the "stack trace" is more valuable for us...to determine what we have to ask in future...or what you "bug triagers" should ask the customer :)
[20:36] <hggdh> \sh: which bug?
[20:36] <\sh> bug #230439
[20:36] <\sh> hggdh: greg-g is involved
[20:37] <greg-g> I took care of the situation on the LP side of them (reopened, asked for information)
[20:37] <hggdh> thanks, \sh, greg-g. Let me look at it anyways
[20:38] <greg-g> np
[20:38] <\sh> greg-g: read -motu...don't let me be misunderstood
[20:39] <hggdh> \sh: there is no stack trace there
[20:39] <hggdh> and, it seems, no .dbgsym or dbg
[20:39] <\sh> hggdh: stacktrace hmm...backtrace with less debug symbols...
[20:40] <hggdh> \sh: backtrace with *no* debug symbold :-)
[20:40] <seb128> \sh: the reply on this bug was correct
[20:40] <seb128> \sh: and that's duplicate
[20:40] <\sh> seb128: TBH, no...
[20:41] <greg-g> seb128: there are others like it, but I couldn't find a duplicate
[20:41] <\sh> seb128: ** Yelp:ERROR:(yelp-document.c:217):yelp_document_get_page: assertion failed: (document != NULL && YELP_IS_DOCUMENT (document)) is more then "no debugging symbols"
[20:41] <seb128> \sh: we don't care, we get too much bugs, crashes should be send using apport so they are in the autoduplication database
[20:41] <greg-g> there are others with the same amount of information that were forwarded upstream and set at triaged
[20:42] <seb128> greg-g: that was a mistake then
[20:42] <\sh> seb128: hardy is no apport without manual intervention...please..
[20:42] <greg-g> see bug 220142
[20:42] <hggdh> seb128: isn't apport disabled on hardy nowadays?
[20:42] <seb128> did you guys read the stock replied used to close the bug?
[20:42] <seb128> it's mentioned there
[20:42] <greg-g> yes, apport is disbaled by default, and this reporter enabled apport and reproduced the crash but no .crash file was created
[20:43] <jderemer> yes i enable apport
[20:43] <greg-g> jderemer == the reporter
[20:43] <seb128> I still don't care, he should use file an apport bug or attach a debug stacktrace
[20:43] <jderemer> and i just dis a valgrind log
[20:43] <\sh> seb128: the reporter is in here...and we hopefully file another bug report against apport
[20:43] <seb128> we get a zillion bug a week
[20:43] <jderemer> seb128: hey ...
[20:43] <seb128> and having useless stacktrace is of no use there
[20:43] <jderemer> seb128: then tell me what you want
[20:43] <seb128> jderemer: hi ;-) nothing personal, but this bug bring no useful informations and create extra work
[20:43] <jderemer> Seb128: saying you dont care doesnt help... just fustrates me
[20:44] <greg-g> so instead of closing it and being done, we should ask him to do a valgrind no?
[20:44] <seb128> no
[20:44] <hggdh> jderemer, greg-g we need to have the debug symbols
[20:44] <seb128> jderemer: open an apport bug, figure why it's not working and then open the bug using apport
[20:44] <greg-g> then if A) the application crashes but B) no .crash file is created the what should I ask him to do?
[20:44] <hggdh> a bt/stacktrace without debug symbols is not worth the virtual paper
[20:44] <seb128> jderemer: or install libglib2.0-0-dbgsym libgtk2.0-0-dbgsym yelp-dbgsym and get a new stacktrace
[20:44] <jderemer> what do i need to do to get the symbols
[20:44] <jderemer> ok
[20:45] <jderemer> will do
[20:45] <seb128> greg-g: to file a bug against apport, fix his installation and then open a decent crash bug using apport
[20:45] <greg-g> "fix his installation" meaning what?
[20:45] <seb128> or to get a debug stacktrace installing the required dbgsym packages which depends of the stacktrace
[20:45] <\sh> seb128: that's I'm sorry to say "bullshit"...having a bug in apport is not the fault of a user...the bug report is valid and usable
[20:46] <seb128> greg-g: whatever the apport maintainer will figure is buggy and make apport not work for him
[20:46] <hggdh> jderemer: please also see https://wiki.ubuntu.com/DebuggingProgramCrash
[20:46] <seb128> \sh: no it's not usuable, it has no debug information
[20:46] <jderemer> hggdh: im there now :)
[20:46] <\sh> seb128: it has more debug reports in it then a stupid glibc crash..
[20:46] <jderemer> hggdh: this part will take a minute
[20:46] <hggdh> jderemer: take your time
[20:46] <greg-g> if it has no debug information then why go around the issue and start with apport instead of asking to install the -dbg packages? (or am I missing something)
[20:47] <seb128> \sh:
[20:47] <seb128> "Program received signal SIGABRT, Aborted.
[20:47] <seb128> [Switching to Thread 0xb6d08940 (LWP 6817)]
[20:47] <seb128> 0xb7f9e410 in __kernel_vsyscall ()"
[20:47] <hggdh> jderemer: also install yelp.dbgsym
[20:47] <jderemer> ya.
[20:47] <seb128> \sh: do you read consider that an useful stacktrace?
[20:47] <\sh> seb128: yes...having the reporter the say of how reproducing it
[20:47] <seb128> \sh: you should teach me how to track bug from a such stacktrace then
[20:47] <LaserJock> the guy wrote steps to reproduce, it should at least be looked at before marked Invalid out of hand
[20:47] <seb128> \sh: do you get the issue doing "going back to the first page opened in yelp"?
[20:48] <seb128> LaserJock: no
[20:48] <seb128> we have too many bugs to spend hours getting the details for submitter
[20:48] <LaserJock> that's just crap
[20:48] <seb128> we accept detailled desktop bugs or not
[20:48] <seb128> well, have to handle several hundred bugs a week and we will talk about it again
[20:48] <\sh> seb128: question: how do you get bugs fixed in server environments?
[20:48] <greg-g> I was willing to do the work to get this report up to snuff
[20:48] <LaserJock> then don't provide the tools to do so!
[20:49] <LaserJock> if you can't handle the volume remove apport
[20:49] <seb128> the other alternative is that we just stop to care, declare that bugs are useless and stop reading those
[20:49] <greg-g> false dichotomy
[20:49] <seb128> LaserJock: it's not enable in stable, that bug has not been filed using apport
[20:49] <LaserJock> seb128: it should *be* there if you don't want people using it
[20:50] <seb128> LaserJock: ? that's not coherent
[20:50] <LaserJock> everybody is told to use apport, so the user enables it and then get's rejected for doing so
[20:50] <\sh> really...I have bug reports with less info then this to bugfix apps...which are written in flash crap...this info in the bug report is more worth then bug #1
[20:50] <seb128> LaserJock: where did you get somebody sending an apport bug rejected?
[20:50] <seb128> LaserJock: this bug has not been sent using apport
[20:50] <jderemer> im running into an issue with the install of libgtk2.0-0-dbgsym and libglib2.0-0-dbgsym
[20:50] <LaserJock> seb128: this guy sent the bug via apport
[20:50] <seb128> no he doesn't
[20:50] <hggdh> jderemer: what is the issue?
[20:51] <seb128> or the bug would have the distribution and packages version
[20:51] <jderemer> wants versions that arent in the repository yet..
[20:51] <seb128> and the environment
[20:51] <hggdh> LaserJock: it was not filled via apport
[20:51] <seb128> and the stacktrace
[20:51] <jderemer> hggdh:   libglib2.0-0-dbgsym: Depends: libglib2.0-0 (= 2.16.3-1ubuntu1) but 2.16.3-1 is to be installed
[20:51] <jderemer>   libgtk2.0-0-dbgsym: Depends: libgtk2.0-0 (= 2.12.9-3ubuntu4) but 2.12.9-3ubuntu3 is to be installed
[20:51] <LaserJock> jderemer: did you use apport or not?
[20:51] <greg-g> lets try to help him work through his present problem first
[20:51] <jderemer> laserjock: apport did not give me any files
[20:51] <hggdh> jderemer: look for the .dbg packages
[20:52] <hggdh> it seems dbgsym generation is running behind
[20:52] <LaserJock> we should at least ask for information rather than rejecting it out of hand
[20:52] <jderemer> hggdh: yea.. the yelp one installed find
[20:52] <hggdh> LaserJock: look at bug 230439
[20:52] <seb128> jderemer: stable update candidates might not have the dbgsym available yet
[20:52] <LaserJock> hggdh: I have been
[20:52] <hggdh> LaserJock: this is not an apport bug
[20:52] <seb128> LaserJock: the bug has been rejected asking to send a new one using apport and giving explanations on how to do so
[20:53] <seb128> and explaining why it has been rejected
[20:53] <LaserJock> but why should it be rejected?
[20:53] <seb128> because it's useless
[20:53] <seb128> it has no debug information
[20:53] <LaserJock> but it can be made better
[20:53] <LaserJock> but rather than do any work we just Invalidate it
[20:53] <seb128> well, apport will open a new bug
[20:53] <jderemer> seb128:  i dont agree. it makes the user feel useless
[20:54] <seb128> yes, because apport doesn't attach to new bugs
[20:54] <jderemer> seb128:  expanding information is easy
[20:54] <\sh> seb128: "If you are running the Ubuntu Stable Release you might need to enable apport in /etc/default/apport and restart." is the explanation of "how do I enable bloody apport on a stable release" when it gives me enough knowledge about a null pointer assignment and crash?
[20:54] <seb128> jderemer: sorry to do that but you are filling a duplicate without debug information, that creates extra work for everybody for no win
[20:54] <jderemer> seb128: i spent 20 minutes looking at bug
[20:54] <seb128> jderemer: not your fault but that's the case and that's why we ask for apport bugs which are decently handled
[20:54] <jderemer> seb128: didnt see any dups
[20:55] <\sh> hey...if I can't grep or vi the stupid source...I'm not a dev...I'm a stupid working horse...and should really retire
[20:55] <greg-g> seb128: which is the duplicate? (have to ask)
[20:55] <\sh> the error report comes from the (let's say it kde/qt wise) qdebug line..and tells me where it crashed
[20:56] <seb128> \sh: what null pointer assignment?
[20:56] <\sh> the reason WHY it crashed needs to come from the reporter...and it's obviously missing...whereas the triages needs to ask "how did you bloody do it?"
[20:57] <seb128> \sh: no, we need a bug open using apport, that's the only way we manage to duplicates handling
[20:57] <seb128> if everybody file non debug crasher manually the retracer don't register the stacktraces and we have to do the work
[20:57] <seb128> that doesn't scale
[20:57] <seb128> that might suck but that's the best we can do desktop wise with the ressources we have
[20:58] <\sh> seb128: read the stupid error message..this warning is a NULL POINTER ASSIGNMENT warning...there is something wrong, and it stupidly throwas a debug message on STDERR...
[20:58] <seb128> and that's why we ask people to use apport
[20:58] <\sh> seb128: as long apport is not enabled by _default_ for stable releases...we need to use more brain instead of closing and throwing away bugreports
[20:59] <\sh> seb128: I do agree with you for devel releases.
[20:59] <hggdh> \sh: then we need more physical bodies to add up
[20:59] <seb128> \sh: read the report, the reply just ask to enable apport, and report the bug again using it, what is wrong there?
[20:59] <greg-g> because he did and no .crash file was created
[20:59]  * ogra shudders imagining seb128 stuffing bodies into LP
[21:00] <seb128> \sh: we are not really interested by stable crashers to be honest, 98% of those are duplicates from crashes which have been sent during the unstable cycle
[21:00] <\sh> If you are running the Ubuntu Stable Release you might need to enable apport in /etc/default/apport and restart.
[21:00] <\sh> If you are using Ubuntu with the Gnome desktop environment - launch nautilus and navigate to your /var/crash directory and double click on the crash report you wish to submit.
[21:00] <\sh> If you are using Kubuntu or Xubuntu you can file the crash using /usr/share/apport/apport-qt --crash-file=/var/crash/_my_crash_report.crash in a terminal - where _my_crash_report.crash is the crash you would like to report.
[21:00] <\sh> please..do read the lines and tell me I'm not stupid...
[21:00] <jderemer> hggdh: its uploaded
[21:00] <\sh> what should I bloody do : touch "/etc/default/apport" and "/sbin/reboot"
[21:00] <seb128> \sh: read https://wiki.ubuntu.com/Bugs/Responses maybe?
[21:01] <\sh> seb128: really...I don't care about wrong docs
[21:01] <seb128> \sh: and suggest improving the wiki page rather than blame people for using the stock reply
[21:01] <\sh> seb128: many of the docs are doomed and not trying to reach reality..really
[21:01] <seb128> \sh: you are not trying to reach reality either
[21:02] <seb128> \sh: it's not possible to deal with the hundred of useless stacktrace we get every week without asking some efforts from submitter
[21:02] <seb128> \sh: those efforts being to use apport
[21:02] <seb128> it's not too much to ask
[21:02] <hggdh> jderemer: we are still missing some data
[21:02] <seb128> and it gives lot of extra informations
[21:02] <jderemer> seb128: once again this effort
[21:02] <seb128> and make everybody's work easier
[21:02] <jderemer> seb128:  your as ass if you say im not trying
[21:02] <hggdh> jderemer: after you get the SIGABRT, please type in the GDB session 'bt full'
[21:03] <jderemer> hggdh: ok
[21:03] <hggdh> and then type in 'thread apply all bt'
[21:03] <hggdh> jderemer then please upload the output
[21:04] <seb128> jderemer: I don't say that, as said before it's nothing personal, we just get hundred of bugs every week and there is a bunch of us triaging those, it's just not possible to do the efforts for the submitters
[21:04] <jderemer> hggdh:  that help at all?
[21:05] <jderemer> hggdh: didnt seem to spit out much info..
[21:05] <seb128> jderemer: so either we do energetic triaging and ask submitter to use apport or we give up and stop reading bugs because that's too much things and it's not workable
[21:05] <hggdh> jderemer: let me refresh it
[21:05] <\sh> seb128: do you really know how many false positives we have and dealing with? if we would close all those bugs with "invalid, please use this tool...if you can't go away"...I do trust people who reply in time (let's say 1 or two 2 days) but closing them randomly because "it doesn't in my workflow" just doesn't work
[21:05] <hggdh> wow
[21:05] <jderemer> seb128: im not saying you get a lot, im saying im here... im putting the effort..  just help
[21:05] <hggdh> that is cool... \sh, there you go
[21:06] <seb128> jderemer: if you comment here on the bug saying apport doesn't work we will tell you how to get a stacktrace or fix apport
[21:06] <hggdh> huh... I am referring to the bug
[21:06] <seb128> jderemer: marking the bug "invalid" is just a way to tell that it is of no use for us right now, it can be reopen
[21:06] <jderemer> if invalid, i doubt youll ever look at it again
[21:06] <jderemer> :(
[21:07] <jderemer> or few ppl do
[21:07] <hggdh> jderemer: it is invalid until you (for example) reopen it with more data
[21:07] <\sh> seb128: marking "invalid" is the only way for LP to mark it as "this bug report is closed"
[21:07] <seb128> \sh: not sure who you call "we", but I don't think you can tell we are doing a bad job on desktop bugs
[21:07] <seb128> \sh: and that's why we use it ;-) because we close things which are of no use
[21:07] <\sh> seb128: bug is bug, no need to divide it into desktop server or whatever bug
[21:07] <seb128> \sh: and we reopen when they are of interest again
[21:08] <seb128> \sh: well, I'll not speak for packages you maintainer but it works fine for desktop bugs, we close the bug because apport will open a new bug and not attach to an existant one and that the new one will have extra informations
[21:08] <hggdh> \sh please look at the bug, and see if there is enough data for you
[21:08] <jderemer> hggdh: didnt think i could reopen. thought one of you guys had to do it
[21:08] <seb128> \sh: it's efficient to do it this way rather than mark the bug incomplete, ask the submitter to mention the duplicate number and then close the bug
[21:09] <\sh> hggdh: I already greped the source...no need for something else...I just need the info how to reproduce it properly.
[21:09] <hggdh> jderemer: I *think* you can
[21:09] <greg-g> \sh: yeah, I cna't reproduce it unfortunately
[21:09] <hggdh> jderemer: \sh needs you to explain how to reproduce
[21:09]  * hggdh cannot reproduce either
[21:09] <greg-g> yes, anyone can change a bug from "invalid" to "new" or "imcomplete"
[21:10] <seb128> this bug is bug #218537 anyway
[21:10] <seb128> why do you guy insist so much on reopening a duplice?
[21:10] <seb128> duplicat
[21:10] <seb128> bug #218537
[21:11] <greg-g> because I missed that duplicate
[21:11] <LaserJock> seb128: I'm more concerned with upsetting reporters by just off-hand invalidating with a canned response
[21:12] <seb128> LaserJock: well it's either that or we give up on dealing with the bug load
[21:12] <greg-g> want me to change the topic to something more meaningful, like the error message?
[21:12] <jderemer> i dont see how its a bug if its a different situation
[21:12] <seb128> LaserJock: asking to use apport as several advantage
[21:12] <jderemer> dup bug*
[21:12] <seb128> - the bug is registered in the stacktrace database for autoduplication
[21:12] <greg-g> s/topic/title/
[21:12] <seb128> - it has details on the system
[21:12] <seb128> - it gives a detailled stacktrace
[21:13] <LaserJock> sure
[21:13] <seb128> jderemer: "** Yelp:ERROR:(yelp-document.c:217):yelp_document_get_page: assertion failed: (document != NULL && YELP_IS_DOCUMENT (document))"
[21:13] <LaserJock> but that doesn't change the fact that it looks like people are just rejecting user's problems
[21:13] <seb128> jderemer: that's the same error and source code line
[21:13] <greg-g> I'm going to change the title of that bug to the error message to more closely conform to how apport titles bugs and to make it more useful, any -1's?
[21:14] <seb128> LaserJock: the stock reply should be clear "closing this bug report since the process outlined above will automatically open a new bug report which can then dealt with more efficiently. Thanks in advance for your cooperation and understanding."
[21:14] <seb128> LaserJock: you are welcome to suggest a better stock reply thoguh
[21:14] <LaserJock> I suggest that apport figure out how to add to the bug rather than having people closing bugs
[21:15] <seb128> LaserJock: I'm not sure it would be clear to have some useless comments and then the useful informations rather than a new stock useful bug
[21:15] <seb128> LaserJock: but I think there is an apport bug about that and once it's fixed we can discuss it again
[21:16] <\sh> seb128: the problem is not apport, even it's not running, but the human intervention...nothing more nothing less..
[21:16] <seb128> but for now we do with what we have, apport always open a new bug and that's why we close the current one
[21:16] <seb128> \sh: what is your issue exactly there? you want to keep useless bugs open to make submitter happy or something?
[21:18] <\sh> seb128: people closing bugs, because they don't understand the reason why the bug was opened...mostly because of not reading, or if the text was read, not understanding...
[21:19] <seb128> \sh: that's clear, crash bug -> use apport
[21:19] <jjesse> \sh: are you then trying to prevent people from mistakes somehow? or people who are closing bugs that should know better
[21:19] <seb128> that's the only way the retracer will know about the duplicates and do its work
[21:19] <\sh> seb128: nope...crash bug, use something which gives me more knowledge
[21:19] <marnanel> sometimes people do show a surprising inability to read the rest of a bug
[21:20] <seb128> \sh: welcome to the real world but you way is not manageable, we make use of the tools we have to handle the bug load
[21:20] <jderemer> all i can say is this is getting way to hard
[21:20] <seb128> \sh: duplicating bugs manually because submitter don't want to use apport is not an option
[21:21] <seb128> jderemer: that's why we ask to use apport too, it's too hard when the user has to figure what to install and how to get the informations
[21:21] <jderemer> everything is installed
[21:21] <seb128> jderemer: the issue is that apport is not working in your case
[21:23] <greg-g> to bring it back to productive discussion, what things should jderemer / I put in an apport bug about this issue (apport not working in his case)?
[21:23] <CarlFK> hggdh: will do
[21:24] <\sh> seb128: the real world don't use public bug reports (adobe)...and don't have this problem...being a community guy, and opensource facist, thinking about people not having the knowledge I have makes more sense...we do have the tools, which are not really in place here...marking as "yes, we know already about it, marking it as dup #xyz" or "guy, thanks for the bugreport, I know it's bugging you, but heck, how did you do it" or "thanks, I read the bug,
[21:24] <\sh> I know it's a patch file of 1MB, I see dev Y is assigned to it, so I leave it alone"...the discussion we have, right here right now is about sense, not tools or pre-defined answers
[21:24] <seb128> greg-g: that's a duplicate of bug #218537
[21:24] <seb128> I'm not sure why gdb is not working though
[21:24] <seb128> but there is no real need of extra details
[21:25] <greg-g> seb128: yeah, I mean, you suggested to report a bug against apport as it wasn't working correctly, wondering what information I should have jderemer give for that bug
[21:25] <seb128> \sh: the stock reply describe the issue clearly, we need to have the bug reported using apport to be able to deal with it efficiently, what is offencive for users there?
[21:26] <seb128> greg-g: well, the issue there is that it SIGABRT and I'm not sure apport catch those
[21:26] <\sh> seb128: machines vs. people -> stock replies vs. people not knowing our business but using our software....the whole market around linux.
[21:26] <greg-g> seb128: ok, so then no apport bug then
[21:26] <hggdh> greg-g: state apport was not kicked on this bug (provide the link to the bug), and ask why, and what can be done
[21:26] <seb128> \sh: how the submitter knows it's a stock reply?
[21:27] <\sh> seb128: the bug about apport and eventually "SIGABRT" is out problem...not the reports
[21:27] <\sh> reporters
[21:27] <hggdh> greg-g: this will probably end up with pitti, anyway
[21:27] <greg-g> hggdh: ok
[21:27] <seb128> \sh: I'm happy to open bugs about apport when it doesn't work for me, but that's not the case there
[21:28]  * hggdh thinks we live in interesting times
[21:28] <seb128> \sh: anyway that's not really constructive, as said either we keep thousand of useless bug open because the user might have apport not working or we explain them that we close the bug because if they use apport then the bug can be better handled and suggest them to do that
[21:28] <\sh> seb128: apport actually is a bug tool for the devs*(ubuntu)...no user has to take care about it...
[21:29] <seb128> no, it's not
[21:29] <seb128> it's the way for user to report issues
[21:29] <jderemer> A WAY
[21:29] <jderemer> not the ONLY way
[21:29] <seb128> I don't use apport and  don't care about it
[21:29] <jderemer> so if it doesnt work
[21:29] <seb128> I use gdb and valgrind when I've issues
[21:29] <jderemer> and someone asks
[21:29] <seb128> apport is a way for users to report issues without having to care about those details
[21:29] <jderemer> seb128: both of those reports are there though
[21:30] <hggdh> jderemer: the beauty of apport is it takes cares of collecting the necessary data from your system, and you (the user) do not need to worry about details like what happened with the dbgsyms
[21:31] <hggdh> jderemer: yes, they are, and \sh said it is enough for him to work on it
[21:31] <jderemer> hggdh: ya, but the #ubuntu-bugs channel should help and not just complain when a user is trying to get information
[21:31] <seb128> jderemer: in 90% of the case apport work, so between keeping 90% of the bugs open for nothing or reopening 10% because apport doesn't work we pick the second option, it's not ideal but that's the only way we can deal witht he bug load
[21:31] <hggdh> jderemer: we do help. It just happens you got in while we were discussing work flow
[21:31] <jderemer> hggdh: yep... i want to make my point thought.  When this method is learned, more ppl learn.  if some one asks how to do something dont tell them to bad
[21:32] <jderemer> er didnt mean that toward hggdh..
[21:32] <seb128> jderemer: there is no complain, but the discussion turned in a disagrement between people doing distribution work
[21:32] <jderemer> ment it in geeneral
[21:32] <seb128> and you are in the middle now
[21:32]  * \sh goes to his wife now, cries a lot, goes to work later and fixes yelp
[21:32] <seb128> sorry about that ;-)
[21:32] <jderemer> its fine
[21:32] <jderemer> im not an idiot though
[21:32] <jderemer> so when i learn somethign new i can use it in the future
[21:32] <jderemer> :)
[21:32] <seb128> ;-)
[21:33] <hggdh> jderemer: I understand -- *we* understand
[21:33] <seb128> ok, so to be back to your bug
[21:33] <jderemer> learned a lot today, and hope to give better ones in the future
[21:33] <jderemer> and i still dont think its a dup
[21:33] <seb128> I've marked as duplicate of bug #218537 which has the same exception on the same line
[21:33] <hggdh> the whole thing -- and it might explain a bit -- Ubuntu is community effort. We need help
[21:33] <jderemer> its a differnt use
[21:33] <jderemer> i read that bug
[21:33] <hggdh> jderemer: but it is the same error, same place
[21:33] <jderemer> its nothing like what i was doing.
[21:33] <hggdh> chances are it is the same issue
[21:34] <seb128> jderemer: exact same message on the exact same code = same bug in 99.9% of the cases
[21:34] <seb128> jderemer: buggy code paths can be trigger by different ways often
[21:34] <hggdh> jderemer: the developer/maintainer working on this bug should look through the duplicates
[21:34] <jderemer> one sec
[21:36] <seb128> jderemer: see bug #223918, the description is similar to yours
[21:37] <jderemer> ok now 223918 i did NOT see
[21:37] <hggdh> and if they decide one issue is not the exact scenario, they should unduplicate (sorry) it
[21:38] <jderemer> yeppie for crappie launchpad search
[21:38] <jderemer> ol
[21:39] <jderemer> hggdh: thanks for the help
[21:40] <seb128> jderemer: this one was already closed as duplicate of the other one ;-)
[21:40] <jderemer> and the courtesy
[21:40] <hggdh> jderemer: welcome. We will be here, and -- one way or the other -- we will get it done :-)
[21:40] <seb128> jderemer: and the default search doesn't list duplicates
[21:40] <seb128> jderemer: you are welcome and sorry again about the discussion about how bugs should be handled
[21:42] <seb128> any enough bug discussion for now
[21:42] <seb128> I've some things to do before uds ;-)
[21:43] <jderemer> um
[21:43] <jderemer> suggestion
[21:43] <jderemer> next time
[21:43] <jderemer> mark it as duplicate
[21:43] <jderemer> not invalid... lol
[21:43] <greg-g> jderemer: don't worry, that bug that yours was marked a duplicate of had a bad title, I just changed it to what it is now
[21:43] <jderemer> i saw :0
[21:43] <greg-g> :)
[21:44] <greg-g> jderemer: have a good one, and again, don't be afraid to come back :)
[21:45] <jderemer> i dunno
[21:45] <jderemer> this place is scary :-P
[21:45] <greg-g> heh, this is true, but you must be brave :)
[21:45] <jderemer> haha
[21:45] <jderemer> im a little mad all that work did nothing
[21:45] <jderemer> :(
[21:45] <jderemer> but o well
[21:45] <jderemer> theres always next time
[21:46] <greg-g> jderemer: well, you confirmed that the bug is still present, at least :)
[21:47] <hggdh> jderemer: welcome to the fringe... ;-)
[21:48] <jderemer> hahaha
[21:48] <jderemer> so true
[21:48] <jderemer> both statements :)
[23:01] <wolfger> any suggestions how to treat bug 162855 ?
[23:19] <ffm> wolfger: It should be {blueprint, brainstorm idea}
[23:19] <ffm> (one of)