[00:12] <hggdh> stpere, probably, yes. I do not consider 2.24.3 stable enough, so it will probably be a SRU
[00:12] <stpere> SRU?
[00:13] <greg-g> Stable Release Update
[00:13] <stpere> oh ok
[00:13] <stpere> thanks
[00:13] <stpere> because I'm having a very bad bug here
[00:13] <greg-g> https://wiki.ubuntu.com/StableReleaseUpdates
[00:13] <stpere> a sent email that get sent over and over again
[00:13] <stpere> everyday
[00:13] <stpere> it doesn't get out of outbox
[00:14] <stpere> it's marked as deleted in the outbox, so it's hidden
[00:14] <stpere> but is sent again anyway
[00:14] <stpere> very embarrassing
[00:31] <hggdh> indeed, and I have not heard of such before
[00:36] <savvas> the pythonistas bugs really need a check for incomplete/invalid/outdated bug reports: https://bugs.launchpad.net/~pythonistas/+packagebugs
[00:40] <Rocket2DMn> can somebody who knows something about backtraces have a look at bug 325903 and tell me if they think the root of the problem is in lib4vl
[00:40] <Rocket2DMn> im terrible at reading down traces
[00:41] <sectech> why does it have a "Medium" and a "new" status?
[00:41] <Rocket2DMn> bug 322368 actually crashes at the same line in telepathy's nain
[00:41] <Rocket2DMn> main*
[00:42] <Rocket2DMn> sectech, i think apport does that when it gets a complete backtrace
[00:42] <sectech> Ahh ok...
[00:42] <sectech> explains a few that I have seen previously then
[00:42] <Rocket2DMn> yaeh its actually getting fairly common
[00:42] <sectech> I actually had a person report a bug against a "known problem" which he even quoted was in the release notes.
[00:43] <sectech> I guess he didn't read to NOT report bugs related to those.
[00:43] <Rocket2DMn> lol
[00:44] <sectech> I didn't want to spend too much time for that one so I kindly explained that it was a known issue, hence his quote of the release notes and set it to "Won't fix" so he couldn't fiddle with the status
[00:44] <sectech> I could have dup'd it by searching for the original issue, but the point would seem kind of moot
[00:44] <Rocket2DMn> heh, well, any ideas about those traces?
[00:45] <sectech> Hmm let me pull up the bug
[00:45] <Rocket2DMn> im thinking actually since there are 2 bugs crashing initially at the same line in the program, it is a program problem
[00:45] <Rocket2DMn> not a lib4vl issue
[00:46] <sectech> First I would look through the traces for sensitive information, and if there is none mark it public
[00:46] <sectech> I'm not the best at traces but I'll see if anything pops out at me
[00:46] <hggdh> Rocket2DMn, this seems to be  an abort signal from glib
[00:47] <Rocket2DMn> good to know hggdh , how can you tell that glib is the source of the problem?
[00:47] <Rocket2DMn> i mean, glib is in practically every gnome crash report
[00:48] <hggdh> oh, I cannot. signal 5 is sigabrt, a request to abort the programme
[00:48] <hggdh> glib generated it
[00:48] <hggdh> probably as a result of the processing in first entry in the BT
[00:49] <sectech> hggdh, where did you see the sig 5?
[00:49] <hggdh> in the title and the description of the bug
[00:49] <sectech> heh, helps if I scrolled up
[00:49] <sectech> I was looking though the traces
[00:50] <hggdh> this is more probably an issue in the package itself (telepathy)
[00:51] <Rocket2DMn> ok hggdh , but the big question is: how do i know the true source of the problem
[00:51] <hggdh> heh
[00:51] <nschembr_> I think I found a bug in the livecd boot process. I need to talk to some before I submit a bug report.
[00:52] <Rocket2DMn> hggdh, both bugs i listed crashed at the same line in the program's main.c, a lot of the traces are similar, but they end differently at 0
[00:52] <hggdh> Rocket2DMn, you would have to go to the source, and look it up in the glib docs on why it would generate an abort
[00:52] <hggdh> huh -- I had not noticed the second bug
[00:53] <Rocket2DMn> /headdesks
[00:53] <nschembr_> any one working on the livecd
[00:54] <hggdh> Rocket2DMn, yes, both of them ended in sigabrt. Also both BTs show that glib is processing an assertion, and that this assertion failed
[00:54] <hggdh> perhaps the users were running with --g-fatal-warnings ?
[00:55] <Rocket2DMn> i have no idea what that option is
[00:55] <hggdh> any failed assertion will cause the programme to terminate
[00:55] <Rocket2DMn> so you think the bug needs to be filed against glib?
[00:56] <Rocket2DMn> glib2.0 to be specific
[00:56] <hggdh> Rocket2DMn, I do not think so, not so far
[00:57] <hggdh> I do not know telepathy, so this can still be a telepathy issue
[00:57] <hggdh> although glib bugs do happen, they are quite rare
[00:57] <Rocket2DMn> that's what i would hav einitially thought
[00:57] <Rocket2DMn> look at the bottom of both stacktraces, they crash at the samea line in main
[00:58] <Rocket2DMn> stream-engine-main.c:335
[01:00] <hggdh> yes -- this is probably where it is registering itself with glib
[01:01] <Rocket2DMn> so i guess i should file this against telepathy on freedesktop
[01:02] <hggdh> yes, sounds so
[01:03] <Rocket2DMn> man there are a fair number of bugs reported, how the heck am i supposed to find dups
[01:03] <Rocket2DMn> wish they had a dup-finder like gnome
[01:05] <Rocket2DMn> hmm none jump out at me
[01:07] <hggdh> yes, this would help -- the dup finder rocks
[01:24] <Rocket2DMn> ok, i have question about defining an upstream link on LP
[01:25] <Rocket2DMn> telepathy-stream-engine package has no upstream links defined, and i think "stream-engine" is what is needed
[01:25] <Rocket2DMn> I was going to add that as an upstream series, but i'm not 100% sure
[02:39] <hggdh> Rocket2DMn, sorry for the delay, in a work technical discussion
[02:39] <hggdh> Rocket2DMn, you copy copy & paste the link to the bug upstream
[02:39] <hggdh> s/copy copy/just copy/
[02:48] <Rocket2DMn> hggdh, say again?
[02:48] <Rocket2DMn> i asked in #launchpad and they said to go ahead and make the connection
[02:49] <Rocket2DMn> hggdh, bug 322368 - i connected that ubuntu package with stream-engine (which is part of Telepathy)
[02:50] <Rocket2DMn> that package didnt have an upstream project associated with it yet
[02:52] <Rocket2DMn> anyway, thanks for the help, im signing off now.  peace
[05:39] <saivann> bdmurray : In case you're here, my membership in the bugcontrol team is about to expire and I would like to ask you to renew my membership if possible. I've not been as active with bugs in 2008 compared to 2007 but I'm still contributing when I have time and I expect to continue in that way in the next years.
[05:41] <saivann> bdmurray : I'm going outside now but if you want, you can email me at anytime or ping me on IRC
[10:30] <shankhs> was navigating through LP to prepare for the Global Bug Jam I ran into this : https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/294991 the page says that its confirmed then triaged and I think its an upstream bug(right?) is there any more information I can get about this bug?
[10:33] <shankhs> anybody there?
[10:38] <dholbach> shankhs: what do you want to know exactly?
[10:38] <dholbach> it's an upstream bug, yes
[10:38] <dholbach> one part of it seems to be fixed upstream already
[10:39] <dholbach> just click on the links in the "assigned to" column
[10:50] <shankhs> dholbach: there are 2 links. both of them are trying to fix the bugs? Or is it that the bug affects both of them?
[10:50] <dholbach> that's what I think
[10:50] <dholbach> but I did not investigate it muchly and am no expert
[10:52] <shankhs> dholbach: it also says that the bug is triaged and is confirmed that its an upstream bug then why ubuntu bothers to keep it in LP why not let gnome tackles it ?
[10:52] <dholbach> shankhs: we still track it in LP, it's not resolved yet
[10:53] <bdmurray> In case there is a fix upstream that we want to add as a patch to the ubuntu package.
[11:03] <pedro_> shankhs: btw empathy bug is already fixed on jaunty, but a task in Ubuntu for telepathy-sofiasip needs to be open to keep tracking of the upstream one
[13:23] <calc> a couple bugs that i noticed that make triaging a bit harder are bug 291968 and bug 291980
[13:26] <calc> bdmurray: do you know how to escalate issues like the above to the launchpad team?
[13:26] <calc> bdmurray: i didn't know if this meeting was the appropriate place to raise the above issues
[14:45] <kagou> Hi
[14:46] <kagou> where should I report bug for the gnome login sound (glitches)... pulseaudio ?
[14:46] <kagou> in 9.04
[14:53] <bdmurray> mvo bug 274737
[14:59] <mangilimic> kagou: I think that the best place for that kind of bugs is gnome-control-center , although I'm not an expert so... let's wait for some more suggestions!
[15:01] <kagou> may be seb128 have a better idea ?
[15:02] <seb128> no clue, open a pulseaudio bug on launchpad
[15:03] <kagou> thanx
[15:03] <kagou> cya
[15:03] <mangilimic> kagou: :)
[15:04] <mangilimic> kagou: I told you that it was better to wait for some more suggestions!
[15:39] <allquixotic> With the new updates, Kubuntu networkmanager works in Jaunty again :)
[16:16] <kagou> mangilimic, at leat my bug report is confirmed by someone else :)
[16:36] <thekorn> MrKanister, I updated the hugday-tools package in my PPA this morning, I should work now without pulling py2.4
[16:37] <thekorn> this sqlite thing should also be fixed
[16:40] <MrKanister> thekorn: Thank you very much. The "hugday init" now works with "--cookie" (the ppa version), I will try the "--moinmoin-id" way later
[16:41] <thekorn> super, thanks fr testing
[16:42] <MrKanister> thekorn: Great. "--wiki-id" is working like a charm :)
[16:49] <thekorn> cool, if you have any ideas how this tool can be improved, I'm happy to hear about them
[16:50] <pedro_> thekorn: I've added an agenda item to the QATeam for next week asking for testing on the hugday-tools
[16:51] <pedro_> btw folks if you have something to discuss https://wiki.ubuntu.com/QATeam/Meetings
[16:51] <pedro_> something new and cool you want to talk about just add it
[16:51] <pedro_> gotta run now, see you later guys
[17:41] <mbwjr12> hey all
[17:46] <mbwjr12> on Ubuntu's website, under the BugSquad section, under Getting Involved, I think there is a bug in the link to bugs without a package.
[17:46] <mbwjr12> the entire top part of the list are bugs that need packaging, and i believe this is a different problem
[17:47] <mbwjr12> or, it might be a bug in the search for bugs without a package, as requests for packages inherently have no package
[18:02] <thekorn> mbwjr12, I think the problem here is that an important part is missing in the descriptive text of this section on the wiki page
[18:02] <thekorn> something like "there are also some workflow related bugreports, like needs packaging bugs"
[18:05] <thekorn> I'm bad in phrasing such texts
[18:10] <mbwjr12> thekorn: using the advanced search function to find bugs without packages also returns bugs with [needs-packaging] in them
[18:13] <thekorn> mbwjr12, right, because all this needs packaging bugs are not targeted to any package/project yet
[18:15] <thekorn> and this is what should be explained on this wiki page, that there are alot of easy to triage bugs where the reporter was unable name a package,
[18:15] <mbwjr12> thekorn: right, the search function is correct, they don't have a package. however, i think it would makes more sense not to list them because they will never have a package, they will be closed whenever they do get a package
[18:17] <mbwjr12> can i just assign them a package with the name of whatever they want packaged?
[18:17] <thekorn> but there are also this "needs packaging" workflow bugreports
[18:18] <thekorn> no, because this package does not exist in ubuntu, and so it does not exist in launchpad
[18:18] <thekorn> unfortunatly it is impossible to exclude this kind of bugs in the searchresults in launchpad
[18:20] <thekorn> because there is no "exclude" tags (or similar) option in the search (yet)
[18:21] <mbwjr12> ok
[18:22] <thekorn> rule of thumb is: don't touch such workflow bugs unless you know what you are doing
[18:23] <thekorn> and this has to be added to this "getting involved" page
[18:25] <mbwjr12> using the same page to show bugs, and according to https://wiki.ubuntu.com/Bugs/HowToTriage/ under the section "Needs Packaging Bugs", there are number of bugs which need to have the wishlist status assigned to them if they aren't already in ubuntu or debian
[18:26] <mbwjr12> for instance, this bug https://bugs.launchpad.net/ubuntu/+bug/263554 needs to be confirmed and set to wishlist importance.
[18:27] <mbwjr12> i see that i have permissions to confirm it, so should i confirm it and then let someone else come along and decide the importance? what is the proper course of action to take?
[18:28] <charlie-tca> Normally, you mark it confirmed and then request here it be marked wishlist
[18:28] <mbwjr12> ok
[18:29] <mbwjr12> i have another question, brb
[18:30] <sectech> I marked that bug as wishlist
[18:30]  * thekorn is wondering if the reporter of this bug is a (spam) bot or something
[18:31] <sectech> Although the license part needs to be corrected. "open source" is a  little vague
[18:31] <mbwjr12> thekorn: lol, this is what my next question was going to be
[18:31] <thekorn> he filed about 600 bugs, almost all of them seem to be autogenerated needs packaging bugs
[18:31] <mbwjr12> why do people think that will somehow make ubuntu more likely to include the package?
[18:32] <thekorn> maybe this is the reason why is account has already been deaktivatid
[18:33] <charlie-tca> That would seem logical
[18:34] <mbwjr12> so what would be the thing to do with this bug?
[18:34] <sectech> Which bug?
[18:34] <mbwjr12> https://bugs.launchpad.net/ubuntu/+bug/263554
[18:34] <sectech> As in here and bug-control will mark it as wishlist
[18:35] <sectech> If it looks complete, which it wasn't.  It had the license as being "open source". I found the package source and verified it as GPL
[18:35] <sectech> and corrected it
[18:35] <thekorn> I think we should talk to the motu guys how they would like to handle this 600 bugs, maybe close them all as invalid by a script
[18:36] <thekorn> and ask to reopen it if somebody really wants to have this package in ubuntu
[18:37] <mbwjr12> i also just found the source and it looks to affero gpl v3
[22:26] <maxb> There isn't any way to get apport to attach its stuff to an existing bug report is there?
[22:26] <charlie-tca> none that I know. Usually just have to use duplicate