[00:43] <montel> Problems with audio should be marked as what package?
[00:44] <montel> I just came across one that was marked as firefox.
[00:44] <montel> Bug #509260
[00:44] <ubot4> Launchpad bug 509260 in firefox-3.5 "No audio on "Dell™ Dimension™ 4550 Series"" [Undecided,New] https://launchpad.net/bugs/509260
[00:45] <montel> Pulseaudio?
[00:45] <hggdh> montel: you can look at https://wiki.ubuntu.com/DebuggingSoundProblems
[00:45] <hggdh> firefox is certaqinly wrong
[00:47] <crimsun> montel: it should be triaged against alsa-driver for now. Please ask the OR to use "apport-collect -p alsa-base 509260"
[00:47] <montel> crimsun: I was just about to post that response.
[00:47] <montel> I was updating a typo in the Bug response wiki
[00:59] <montel> mplayer is provided through medibuntu, right?
[00:59] <montel> nvm
[01:01] <montel> is apport-collect -p alsa-base BUGNUMBER #<number> or just <number>?
[01:02] <crimsun> precise syntax given above
[01:03] <BUGabundo> montel: no #
[01:03] <montel> thank you BUGabundo crimsun
[01:10] <atrus> okay, i've switched to using packages. apport is collecting reports in /var/crash, but no GUI/dialog appears in response to a crash. Is there something that's supposed to be running in my session to catch these?
[01:17] <hggdh> atrus: what is your Ubuntu version?
[01:18] <atrus> karmic+updates+proposed, apport and apport-gtk are 1.9.3-0ubuntu4.2,
[01:19] <hggdh> atrus: check /etc/default/apport -- enabled should be set to 1
[01:19] <atrus> hggdh: yep, that's done, and crashes are successfully being collected in /var/crash
[01:20] <hggdh> ok. Did you reboot after changing /etc/default/apport?
[01:20] <atrus> no, but i did 'sudo stop apport' and 'sudo start apport'
[01:20] <hggdh> good.
[01:21] <hggdh> So apport should be fully up. I wonder if the crashes you have are actual Ubuntu package crashes
[01:21] <atrus> on a crash, apport runs, consuming CPU for a while
[01:21] <atrus> but no dialog appears.
[01:22] <atrus> it happens i'm using a non-ubuntu package (from a ppa), but under karmic alphas, those prompted dialogs too.
[01:22] <hggdh> please have a look at /var/log/apport.log -- it will state what apport has done
[01:22] <atrus> called for pid X, executable: X (command line: X), wrote report to /var/crash/.....
[01:22] <atrus> nothing further.
[01:23] <hggdh> weird.
[01:24] <hggdh> try running it by hand: /usr/share/apport/apport-gtk -c /var/crash/whatever
[01:24] <hggdh> of course, replace whatever by one of the crash reports
[01:25] <atrus> that causes the "Collecting problem information" dialog to appear for the first time in a few months :)
[01:25] <hggdh> it should have been automagic
[01:25] <atrus> that's good. now i just need to figure out why that didn't get called.
[01:26] <hggdh> I do not have a karmic machine handy to check on it, unfortunately
[01:28] <crimsun> montel: if a bug affects linux and already has the ubuntu-audio team subscribed, please don't change it to alsa-driver
[01:29] <montel> Thanks for letting me know crimsun
[01:29] <montel> what bug are yo talking about btw?
[01:29] <crimsun> 293596
[01:30] <montel> bug #293596
[01:30] <ubot4> Launchpad bug 293596 in alsa-driver "No sound in Ubuntu 8.10 64 bit" [Undecided,Incomplete] https://launchpad.net/bugs/293596
[01:30] <montel> Oh, yeah.
[05:43] <montel_>  /join #ubuntu-chicago
[07:03] <johe|work> hi there
[07:04] <johe|work> an python developer around, pointing pysnmp package
[08:46] <om26er> please mark this triaged/wishlist https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/498596
[08:46] <ubot4> Launchpad bug 498596 in empathy "provide ability to hide a contact/all contacts" [Undecided,Incomplete]
[08:54] <BUGabundo_remote> morning
[09:48] <vish> could someone wishlist Bug #164121
[09:48] <ubot4> Launchpad bug 164121 in gnome-control-center "no languages icon on the panel by default" [Undecided,New] https://launchpad.net/bugs/164121
[09:57] <thekorn> vish, DONE
[09:57] <vish> ty
[11:20] <om26er> if a bug is reported in empathy 2.28.1.1 today and seems fixed in 2.29.5 should i mark it invalid or fix released?
[11:21] <Hellow> Fix released.
[11:21] <om26er> thanc
[11:21] <Hellow> However, you should confirm that upstream fixed it before doing that.
[11:22] <thekorn> om26er, yes, mark it as fixed. You can also ask the reporter to download a lucid live cd and check if this bug is fixed there for him
[11:22] <thekorn> well, I suppose we are talking about an ubuntu task here, right
[11:22] <thekorn> ?
[11:23] <Hellow> What's the bug in question?
[11:25] <Hellow> Ok then.
[11:25] <Hellow> :P
[11:26] <thekorn> bug 509349 i think ;)
[11:26] <ubot4> Launchpad bug 509349 in empathy "personal information does not show IRC/MSN status" [Undecided,New] https://launchpad.net/bugs/509349
[11:43] <kermiac> if a bug exists in Karmic but can't be reproduced in the newer version included in Lucid I should mark it as "fix released"? Even though the bug still exists in Karmic?
[11:43] <kermiac> bug 506343
[11:43] <ubot4> Launchpad bug 506343 in tomboy "cliking on http links creates a new note" [Undecided,Confirmed] https://launchpad.net/bugs/506343
[11:43] <ikt> damn that's a good question
[11:44] <kermiac> yeah, it made me scratch my head
[11:47] <ikt> think there's a bug response for i
[11:47] <ikt> it
[11:48]  * kermiac looks through the stock responses page
[11:49] <kermiac> thanks ikt, found it :)
[11:50] <kermiac> https://wiki.ubuntu.com/Bugs/Responses#Fixed%20in%20Development%20release%20while%20still%20existing%20in%20a%20previous%20release
[11:50] <ikt> :>
[11:54] <kermiac> does anyone know if tomboy could be backported for tomboy easily? Or would it have to go through SRU testing?
[11:54] <kermiac> backported for Karmic easily
[12:04] <kermiac> nvm
[12:39] <plentz> hey guys. i think that i found a bug in ubuntu, but i wanna check if it's really a bug before reporting it
[12:40] <seb128> hi
[12:41] <seb128> usually it's better to just ask your question
[12:41] <seb128> some people are busy and will not reply to random comments but will to specific questions
[12:41] <plentz> the problema is basically this: you change the soft and hardlimit of nofile inside /etc/security/limits.conf for the wildcard * and it wont work for all users. then you add the same limits, but directly for the user you anna change(jetty in this case) and it works
[12:41] <plentz> *problem
[12:42] <plentz> like:
[12:42] <plentz> *               soft    nofile          2048
[12:42] <plentz> *               hard    nofile          4096
[12:42] <plentz> won't work. but this works:
[12:42] <plentz> jetty               soft    nofile          2048
[12:42] <plentz> jetty               hard    nofile          4096
[13:21] <kamusin> buh!
[14:30] <plentz> well, its done
[14:30] <plentz> https://bugs.launchpad.net/ubuntu/+bug/509654
[14:30] <ubot4> Launchpad bug 509654 in ubuntu "wildcard(*) configuration don't work in /etc/security/limits.conf" [Undecided,New]
[14:33] <speaktrap> hello
[14:33] <speaktrap> grmonitor package is broken
[14:33] <speaktrap> gives SEGMENTION FAULT
[14:33] <speaktrap> this error sucks balls
[14:35] <yofel> and he's gone already...
[14:37] <sbc> yofel: At least now that we know it 'sucks balls' it should be easy to fix...
[14:37] <yofel> heh
[14:39] <BUGabundo_remote> lol
[14:39] <BUGabundo_remote> we need a bot to capture suckball and fw the user to LP SB package
[14:39] <BUGabundo_remote> and it needs packaging too.. can't fing sucksballs in my repo
[14:41] <yofel> lol
[14:45] <BUGabundo_remote> yofel: wouldn't it be nice to have $ suckballs to fix everything, when something breaks?
[14:46] <yofel> indeed, but then this channel would loose its meaning :P
[14:48] <xteejx> Hey guys, I signed up to the 5 a day thing yesterday, when does it update with my triaging stats, and how does it count them?
[14:48] <micahg> when someone fixes it :P
[14:49] <micahg> ah, nm, it is fixed
[14:49] <micahg> UTC midnight
[14:50] <xteejx> IT UTC GMT ?
[14:50] <yofel> http://qa.ubuntu.com/reports/five-a-day/
[14:50] <xteejx> *Is
[14:52] <xteejx> UTC~=GMT - so midnight here then that's easy hehe :)
[14:52] <micahg> xteejx: it's close enough I think
[14:52] <xteejx> 0.9 seconds difference, I can live with that ;)
[14:54] <xteejx> Is this thing counting touched bugs, commeted, subscribed, or what, since I'm kinda living in the expired bugs at the mo, it will count those right?
[14:58] <yofel> not sure, I guess it should count anything that appears on your lp karma page
[14:59] <xteejx> yofel: bug 308559, thanks :)
[14:59] <ubot4> Launchpad bug 308559 in ubuntu ""Could not connect to database" warning" [Undecided,Invalid] https://launchpad.net/bugs/308559
[14:59] <yofel> heh
[15:00] <xteejx> the LPGM responses do help sometimes ;)
[15:00] <yofel> I look through those sometimes too, but I mostly live in untriaged bugs without a pakcage ;)
[15:02] <xteejx> yofel: hehe :)
[15:02] <xteejx> bug 110358, should this be reopened and upstreamed to Debian?
[15:02] <ubot4> Launchpad bug 110358 in fontconfig "Updating /var/cache/fontconfig with no-bitmaps disables bitmap fonts also for users that enable them" [Undecided,Invalid] https://launchpad.net/bugs/110358
[15:03] <xteejx> I'm not sure if the OR is saying it was fixed in Jaunty and that he can now run that sudo command, or if the fonts.conf is still a problem, I'm a bit confused
[15:06] <xteejx> micahg, hggdh, would either of you mind looking at that ^ quickly if you're not busy please, it's bloody confusing
[15:07] <micahg> xteejx: sorry, not familiar with it
[15:08] <yofel> as he's using lenny, he should definitely report this bug in the debian BTS, now if this bug should be reopened or not I don't know, the ubuntu package has a few more patches than the debian one
[15:08] <xteejx> no worres micah
[15:08] <micahg> lenny is stable and old...
[15:09] <xteejx> Hmm....thing is, do I leave the Ubuntu task closed and just upstream and link it in, see what they say
[15:09] <micahg> xteejx: see if it's been fixed in testing or unstable
[15:10]  * yofel goes looking at the debian changelog
[15:10] <xteejx> its the 2 conflicting statements from the OR that confuse me "In any case, "sudo fc-cache -r -s -v" appears to do its job properly now." and "It's better in Jaunty, but there are still some differences:"
[15:10] <xteejx> does it work or not?!? lol
[15:11]  * yofel doesn't get that either
[15:11]  * xteejx thinks yofel should explain to dumbass xteejx here how to see the changelogs for Deb
[15:12] <yofel> err... I usually do apt-get source package/unstable, but I have testing and unstable repos in my sources.list pinned to -1 priority
[15:13] <xteejx> ohh
[15:13] <yofel> very custom setup ^^
[15:13] <xteejx> Yeah I guessed. I'll leave that one to you methinks hehe :)
[15:16] <hggdh> seems like the system configuration overrides user configuration
[15:17] <hggdh> and -- usually -- you would want specific configuration to be done user-level (the principle known as "give'em enough rope, and they'll hang themselves")
[15:18] <xteejx> hggdh, So it's kicking in some kind of 'failsafe'?
[15:19] <bddebian> Boo
[15:19] <hggdh> Boo, bddebian, still setting the clock :-)
[15:19] <xteejx> bddebian, What did I tell you the other day about scaring people? LOL :P
[15:19] <xteejx> Hi bddebian
[15:20] <xteejx> :)
[15:21] <hggdh> xteejx: not really. I do not know the package, so I cannot say much about it. But -- if reversing the order of two lines in the system conf allows user conf to be effective, then this is a bug either way
[15:21] <xteejx> Hmm, reopen it then as Confirmed, Low and set upstream link?
[15:21] <hggdh> xteejx: yes, I would say so
[15:22] <xteejx> Cool, thanks for clearing that up. :)
[15:24] <bddebian> Hi hggdh, xteejx :)
[15:24] <xteejx> Hey hey
[15:27] <xteejx> Why can I not add an upstream watch for bug 245219?
[15:27] <ubot4> Launchpad bug 245219 in ubuntu-meta "Ubuntu archive server returning incorrect content-encoding - content-header incorrect type" [Medium,Triaged] https://launchpad.net/bugs/245219
[15:30] <nigel_nb> xteejx, probably upstream for that *is* LP
[15:31] <xteejx> Oops, I've just realised, the affected package should be apache
[15:31] <xteejx> Maybe it's because it's set to ubuntu-meta?
[15:31] <nigel_nb> yeah
[15:32] <nigel_nb> you need to correct the package first and then add upstream in that case
[15:32] <xteejx> hehe, just added another project as affected, didn't realise you HAD to choose one, because it says "if you don't know leave it blank", which then doesn't allow you to add a watch
[15:33] <nigel_nb> exactly
[15:35] <xteejx> I thought LP worked it out from the upstream BTS, perhaps not :)
[15:36] <nigel_nb> LP also works out the package's upstream, so if the package is wrong, the upstream will be wrong
[15:37] <command> I was wondering where to place bugs for UN edition, update install...does this go under entire disk?
[15:38] <ikt> netbook edition
[15:38] <BUGabundo_remote> foo
[15:38] <BUGabundo_remote> late as ususal
[15:38] <ikt> command: which part of une?
[15:39] <command> upgrade from karmic using update command rather than install from disk?
[15:40] <ikt> https://launchpad.net/netbook-remix
[15:41] <ikt> I can't imagine the people at update-manager would be very happy with that bug
[15:42] <ikt> anybody see if this bug gets fixed: http://linuxhaters.blogspot.com/2009/11/bad-karma.html <- Problem #1? Using update-manager to upgrade Ubuntu from behind the firewall is slow. They try to do something that doesn't respect http_proxy and has to time-out before progressing.
[15:42] <jpds> a/37
[15:55] <qense> meeting in five minutes!
[15:57] <mrand> How did you know I have a meeting in five minutes?! :-)
[15:57] <qense> I've got a Google account!
[15:57] <qense> You aren't using IE6, are you?
[15:58] <mrand> I have a windows machine handy, yes.
[15:58] <vish> lol!
[15:58] <mrand> ooops, IE7
[15:59] <qense> The British security chief told that moving away from IE would be even more unsafe and that you just shouldn't visit infected sites. Just update and you don't have to worry!
[15:59] <qense> (security chief of MS)
[16:00]  * vish thought it was the french .. hm..
[16:00] <vish> oh , of MS.. ;)
[16:00] <qense> bdmurray, micahg, pedro_, adiroiban, and others: meeting!
[16:00] <mrand> Yeah, saw that.  I've been a huge fan (and user, and debugger) of Firefox since it was born as Phoenix
[16:01] <adiroiban> hi
[16:02] <mrand> As usual, I'll contribute what and when I can, but I can't get too distracted.
[16:02] <qense> the agenda is at <https://wiki.ubuntu.com/BugSquad/Meeting>, for those interested but unaware of the agenda
[16:02] <qense> ah, forgot one, ping: hggdh
[16:02] <dpm> hi all
[16:02] <Laibsch> Moin!
[16:02] <qense> hello
[16:02] <hggdh> pong
[16:03]  * micahg thinks translation bugs should be top priority
[16:03] <qense> yep
[16:04] <micahg> for this meeting at least ;)
[16:04] <qense> dpm, maybe you could start with a quick explanation of the way Translations uses LP now, for those who haven't followed the maillist discussion?
[16:04] <dpm> qense, sure
[16:06] <dpm> here is some background (https://wiki.ubuntu.com/Translations/KnowledgeBase/HandlingBugs). Basically, the way the translations team handles bugs is:
[16:06] <dpm> we've got a LP project
[16:06] <dpm> called ubuntu-translations
[16:06] <dpm> the idea is to report all translations-related bugs there
[16:07] <dpm> the UTC (ubuntu-translations-coordinators) is set as the project driver
[16:07] <micahg> dpm: what about the tasks for the ubuntu package/
[16:07] <dpm> and takes care of triaging and fixing
[16:07] <micahg> should they be marked as triaged pending action from the translators team?
[16:07] <mrand> dpm: reported ubuntu-translations even if the translation for that app is handled upstream?
[16:08] <pedro_> micahg, that's what i've been doing so far
[16:09] <micahg> pedro_: me too, but I want to verify if that's the process we want to keep
[16:09] <pedro_> btw the ubuntu-translators team is *pretty* fast to solve issues there
[16:09] <dpm> micahg, it sounds good to me if it sounds good to the bugsquad
[16:09] <dpm> :)
[16:09] <qense> Currently we have mostly two tasks: one for the source pacakge -- often filed by a user via the ubuntu LP project -- and one for the ubuntu-translations project. Most bugs are handled pretty fast by teh translators. However, they can't use all statuses for the source package task.
[16:10] <dpm> the problem we had on the last hugday was that the bugsquad could not set "our" bugs as confirmed
[16:10] <dpm> and what qsense is pointing out ^
[16:10] <qense> On top of that the two different tasks cause extra work and mail noise.
[16:10] <micahg> hmm, confirmed should be allowed on any project that's public
[16:11] <micahg> triaged can't be set
[16:11] <hggdh> the only thing I am not sure about (not even if it is needed) is that -- by assigning the bug to ubuntu-translators we lose track of the real affected package
[16:11] <micahg> hggdh: that's why we mark the ubuntu task as triaged
[16:11] <dpm> micahg, sorry for the confusion. yeah, triaged
[16:11] <qense> The Translators did say to prefer a separate ubuntu-translations project so they can keep track of all translation bugs.
[16:11] <qense> hggdg: there are two tasks iirc
[16:11] <hggdh> oh
[16:11]  * hggdh is slow as usual
[16:12] <hggdh> and I beg all pardon
[16:12] <dpm> I agree that the extra bug task is a downside, but is it that much of a problem given the number of translation bugs?
[16:12] <qense> pardon granted
[16:13] <micahg> dpm: one task isn't much of a problem
[16:13] <micahg> it's the same as upstreaming
[16:13] <qense> It is not much of a problem to me, but I could imagine that when you handle a lot of bugs it could cause you extra time. What seems to be the biggest problem here is the lack of permissions for both teams involved.
[16:13] <dpm> mrand, if the translation is handled upstream, we tend to point the reporters to upstream and close the ubuntu-translations task as invalid
[16:13] <adiroiban> I assume the permissions could be fixed
[16:13] <micahg> qense: I don't think that we should have triage permissions for the translators team
[16:14] <mrand> dpm: cool.  thanks.
[16:14] <dpm> ok, so we seem to agree that additional tasks in this particular case is not much of an issue
[16:14] <dpm> and that the issue is permissions
[16:14] <micahg> the whole point of triage permissions is to verify that a real issue exists
[16:14] <micahg> the translators team would know best where that effort should be
[16:15] <qense> Now there are two people with permissions necessary to properly mark one translation bug.
[16:15] <micahg> hence, we can confim the issue, and if they can fix it mark triaged and take the appropriate action
[16:15] <micahg> qense: adding translators team to bug control might be an option
[16:16] <qense> So first 'Confirmed', then a ubuntu-translations tasks and when they're done a 'Triaged' to the ubuntu task
[16:16] <qense> ?
[16:16] <micahg> but I don't think it makes sense the other way
[16:16] <adiroiban> or add bug control to ubuntu-translations project :)
[16:16] <thekorn> or leave it as it is right now ;)
[16:16] <adiroiban> :)
[16:17] <qense> btw, there is not explanation for this type of bug on Bugs/HowToTriage, shall I add one after this meeting?
[16:17] <dpm> qense, sounds great to me :)
[16:17] <micahg> qense: I thought that was the point of the meeting agenda item, to nail down the specifics
[16:17] <qense> because that's (part of) the main problem, I feel, the process isn't/wasn't well-known by the traigers.
[16:18] <qense> yes, the specifics
[16:18] <qense> is there a specific translators team for bug handling?
[16:18] <dpm> qense, we can then even remove the HandlingBugs page on the Translations wiki and point folks to the Bugs/HowToTriage one
[16:18] <micahg> hmm,maybe it does make sense to have bug control set triaged on the translators bugs
[16:18] <dpm> qense, ubuntu-translations-coordinators
[16:18] <micahg> triaged in ubuntu mean ready for dev to look at
[16:19] <qense> dpm: I wouldn't remvoe that page completely, but instead point to it from the HowTotTiage page
[16:19] <dpm> qense, ok, sounds good
[16:19] <qense> the translators are the devs here, so technically they shouldn't have to do anything with the Ubuntu task
[16:20] <micahg> qense: ok, so maybe my initial proposal was wrong...
[16:20] <qense> however, that would be a bit inefficient, so maybe adding the translators team to the bugcontrol, or a bug handling subset of the translators team, would be indeed the best solution
[16:20] <hggdh> I agree
[16:20] <micahg> qense: I think adiroiban had the better proposal
[16:21] <dpm> I also think adding bug control to ubuntu-translations might be a good idea
[16:21] <micahg> then the triager in Ubuntu can set the translations task as triaged which tells them they need to look at it
[16:21] <qense> That would make sense. people join the bugsquad to triage bugs and they join the translation team to translate, not to triage other bugs
[16:21] <qense> Maybe we could have some kind of Adopt-a(n)-Upstream/Package subgroup later on that focuses on translation bugs?
[16:21] <micahg> dpm +1
[16:22] <micahg> qense: I think that will divide our efforts further
[16:22] <qense> ok, it was just something that came up in my mind
[16:23] <micahg> qense: maybe one day when we have better coverage
[16:23] <qense> so we agree that the Ubuntu Bug Control team shouold get bug permissions for the ubuntu-translations project?
[16:23] <dpm> +1
[16:24] <micahg> +1
[16:24] <qense> +1 from me too
[16:24] <micahg> feels weird having a meeting w/out bdmurray
[16:24] <thekorn> +1 if we write down something about the process in our wiki
[16:25] <qense> I'll add a section to Bugs/HowToTriage, would that be sufficient?
[16:25] <thekorn> YES, great
[16:25] <qense> btw, who will write down the minutes of this meeting?
[16:25] <dpm> qense, I'll subscribe to that page in order to add a link to it on the Translations/HandlingBugs page when finished
[16:26] <xteejx> bug 509376, I really don't think this should have been Invalidated, it is clearly a bug if jockey is blacklisting the nvidia driver!!
[16:26] <ubot4> Launchpad bug 509376 in jockey "[lucid] nvidia-current failed to initialise" [Undecided,Invalid] https://launchpad.net/bugs/509376
[16:26] <qense> dpm: okay
[16:26] <dpm> if no one else volunteers, I can take care of the minutes
[16:27] <dpm> re: the adopt-apackage/upstream proposal, I think for now what we can do is to simply use the ubuntu-translations project as a target for regular hugdays like the one some weeks ago
[16:28] <qense> okay, that means this topic is done now?
[16:28] <dpm> just one sec
[16:29] <dpm> the translations team is still learning on bug triaging, etc and I've got one quick question:
[16:29] <dpm> We discussed the use of tags for translation bugs in the past
[16:29] <dpm> We've made a list here: https://wiki.ubuntu.com/Translations/KnowledgeBase/HandlingBugs#Tagging
[16:29] <dpm> Do you guys havve got any feedback, tips, advice on bug tagging?
[16:30] <qense> xteejx: it could have to do with the transition to the new proprietary nvidia drivers packaging layout, in that case users upgrading in a later stage wouldn't suffer from this bug and Invalid would be the right state.
[16:31] <xteejx> qense: Ahh ok, thanks for clearing that up :)
[16:32] <hggdh> tagging is still very much ad hoc. It might help for you to prefix the translation tags with -- say -- 'tr', or 'trans' -- so that there will be less chance of conflicts
[16:32] <qense> dpm: are you aware of the difference between official and unofficial tags? I'm not sure how tags behave when the bug has tasks for multiple projects, though/
[16:32] <dpm> qense, I've heard about them, but I'm not too clear on the distiction right now
[16:33] <qense> Official tasks get listed on the bugs overview page
[16:33] <dpm> although in the past there has been discussions on making the i18n or l10n tags official to give more relevance to translations-related bugs
[16:34] <qense> You could use tags to help the different i10n teams
[16:34] <hggdh> some tags are used "everywhere" -- like the regression* ones; these are the official ones. Others are specific to a project/usage, and completely out of control
[16:35] <dpm> how can we "apply" for translation-related tags to be made official for the ubuntu project?
[16:35] <dpm> (when relevant)
[16:36] <qense> not sure, bug control administrators maybe?
[16:36] <dpm> I'll look into it, then, thanks
[16:37] <hggdh> pretty much by adding your tags to the https://wiki.ubuntu.com/Bugs/Tags page (since you are dealing with bugs also)
[16:37] <dpm> thanks a lot for the advice and the feedback
[16:37] <hggdh> and sending out an email to bugsquad/control explaining why you are adding them there
[16:38] <dpm> ok, thanks
[16:38] <dpm> otherwise, I think that's all from my part on translations, unless adiroiban or ArneGoetje have something else to add
[16:38] <micahg> hggdh: does the ubuntu bug project admin have to mark them in LP in any wya?
[16:39] <hggdh> micahg: to my knowledge, no -- tags are still ad hoc. But I do not know the internals of LP/Malone
[16:40] <qense> hggdh: iirc there is a list of official tags on bugs.launchpad.net/{project}
[16:42] <qense> was that a split?
[16:43] <xteejx> yeah
[16:44] <hggdh> qense: I am not sure these are real official tags, or tags found in bugs. For example, Evolution lists a 'junk' tag...
[16:45] <qense> hggdh: found it! http://blog.launchpad.net/cool-new-stuff/official-bug-tags
[16:46] <hggdh> cool, qense, thank you
[16:46] <dpm> ah, great, thanks
[16:48] <qense> one question: should people open a ubuntu-translations task for all translation bugs, or only after they've been marked as triaged?
[16:49] <qense> I'd go for right away since the u-trans project was mostly meant for keeping track of all translation bgs, what would you say?
[16:50] <dpm> qense, yes, I think so. Furthermore, translation bugs are easily identifyable. What I mean is that when you spot one it is generally quite obvious that it is a translations-related bug
[16:50] <dpm> so it makes sense to file it against u-t straight away
[16:51] <qense> yes
[16:57] <qense> It's now almost 17.00 UTC. What shall we do with the points that weren't discussed. Micahg, you added most of them, what do you think?
[16:57] <micahg> heh, wait till next month :)
[16:57] <micahg> translations was the big ting
[16:57] <micahg> thing
[16:57] <dpm> yeah, the meeting was quite productive from my pov anyway
[16:57] <dpm> very
[16:58] <qense> good
[16:58] <micahg> so, dpm if you can add ubuntu-bugcontrol as a member of the translations-coordinators team, that allow us to set the triaged status
[16:58] <qense> dpm, if you or someone else from your team has got any questions about the bug triaging process, please feel free to mail the bugsquad maillist or come to this IRC channel
[16:59] <micahg> dpm: maybe setting us as bug supervisor would be enough?  idk if that would remove your teams abilities though
[16:59] <qense> You could make a separate Ubuntu Translations Bug Supervisor team and make both teams a member of it,
[17:00] <qense> That way you wouldn't give away permissions to both teams
[17:00] <micahg> that works too
[17:00] <dpm> micahg, I'll have to look into that, since adding bugcontrol to the team might not be an option (otherwise everyone can modify LP translation templates) - qsense's suggestion seems like the best option to me
[17:01] <micahg> dpm: k
[17:01] <hggdh> dpm: the translation team -- is it a restricted tem?
[17:01] <hggdh> team
[17:01] <micahg> yep
[17:01] <hggdh> so why not just add it to bug-control?
[17:01]  * micahg checked earlier
[17:01] <micahg> hggdh: then we can't set triaged in their projetc
[17:01] <dpm> hggdh, yes, it's actually the ubuntu-translations-coordinators team and it's restricted
[17:01] <qense> I don't think it would be wise to make bugcontrol a member of translations since they are both very different teams and have different applications procedures
[17:02] <xteejx> Why not just make a new team with both in, and set both as able to change status, i.e. same as Bug Control?
[17:02] <hggdh> yes, I agree, but the other way should work. And if we cannot set their task to triaged, not a problem
[17:02] <micahg> yep, then that new team can be made bug supervisor for the translations project
[17:02] <dpm> xteejx, I think that was qense's proposal
[17:02] <xteejx> oops :)
[17:03] <micahg> hggdh: that's what most of the discussion was about ;)
[17:03] <qense> I've got to go now, but I'll read the backlog
[17:03] <hggdh> yes. But we are complicating the issue, with Yet One More Team (TM)
[17:03] <qense> that team is just a technical trick
[17:03] <dpm> exactly
[17:03] <qense> afk!
[17:03] <dpm> thanks qense, bye!
[17:03] <hggdh> eppuir si mueve
[17:03] <micahg> hggdh: it's a set it and forget it team
[17:03] <thekorn> qense, thanks for running this meeting
[17:04] <hggdh> OK
[17:04] <dpm> I think I'll go ahead with the creation of the team and I'll add 'bugcontrol' and 'ubuntu-translations-coordinators' to it.
[17:05] <micahg> dpm: ubuntu-bugcontrol
[17:05] <dpm> ok, 'ubuntu-bugcontrol' and 'ubuntu-translations-coordinators'
[17:07] <dpm> micahg, what's the next step, then, set the new team as "Bug Supervisor" for the 'ubuntu-translations' project?
[17:08] <micahg> dpm: yep
[17:09] <dpm> thanks, any suggestions for the name of the new team? Otherwise I'll go with 'ubuntu-translations-bugsupervisors'
[17:09] <hggdh> dpm, this is descriptive, +1
[17:10] <dpm> cool, thanks
[17:19] <micahg> dpm: did you make the minutes page yet?
[17:19] <xteejx> Is the meeting over now then I assume?
[17:19]  * micahg saw the initial wiki commit
[17:19] <micahg> xteejx: yes
[17:19] <dpm> micahg, hggdh ok, done -> https://launchpad.net/~ubuntu-translations-bugsupervisors/ . I'm composing the minutes just now.
[17:20] <micahg> dpm: date is wrong on the minutes master page
[17:20] <micahg> shoul dI fix it?
[17:20] <dpm> micahg, yes, please, thanks for spotting it :)
[17:21] <micahg> dpm: fixed
[17:21] <dpm> pedro_, can you accept the invitation for ubuntu bug control to join ubuntu-translations-bugsupervisors? I'll add you and bdmurray as admins
[17:23] <xteejx> bug 382521, can someone change status on this please (I reported it therefore can't). Also, qemulator appears to be unmaintained, there have been no updates on the package despite the fact that this appears fixed upstream
[17:23] <ubot4> Launchpad bug 382521 in qemulator "[lucid] qemulator.py crashed with TypeError in on_treeviewBootimages_cursor_changed()" [Undecided,New] https://launchpad.net/bugs/382521
[17:24] <micahg> xteejx: what kind of status change?
[17:25] <micahg> xteejx: you can mark your own bug confirmed if there's a duplicate bug
[17:25] <xteejx> oh i didn't realise hehe, there is another affected user, but no comment
[17:25] <xteejx> oops no theres not
[17:26] <xteejx> it is VERY easily reproducible though, even in Lucid
[17:26] <micahg> xteejx: you have 2 other bugs duped to that
[17:26] <xteejx> micahg: lol sorry not with it today
[17:29] <xteejx> Would this bug be suitable for upgrade to Triaged? I think there's more than enough info
[17:31] <qense> xteejx: is there an upstream to report it to?
[17:32] <xteejx> There *is* an upstream, but doesn't appear to be any bug reporting facility, its maintained by Ubuntu Dev Team, and the svn version has been updated
[17:36] <qense> dpm: just curious, will the 'actions' for the different kind of bugs at Translations/KnowledgeBase/HandlingBugs be the addition of tags to the bug reports?
[17:38] <qense> dpm: furthermore I was also wondering if you new the Bugs/Responses (stock replies), Bugs/Status and Bugs/Importance wiki pages. Maybe it would be worth linking to them in the Translations KB, although I'm not sure if you can use the status and importance definitions of bug control without adapting them (slightly).
[17:40] <dpm> qense, not specifically, I was just trying to add the steps involved in dealing with each type of translation bug. Some of the steps will involve adding a tag, altough I haven't come to document that yet. We wanted to have some more feedback on the usage of tags, which we've now had. Yes, I'll link Bugs/Status and Bugs/Importance, that's a good point as well
[17:41] <qense> dpm: OK. Another suggestion: for the ubuntu project we have the ubuntu-bugs team, which has the same function as ubuntu-translations-bugsupervisors , which is subscribe to all bug mail with its contact address (a maillist). People or bots that are interested in following all bug mail can subscribe to that maillist and will get spammed.
[17:41] <qense> do you think that would be of any use for the translation project?
[17:42] <micahg> qense: we don't want the bug mail, we want the privd
[17:42] <micahg> privs
[17:42] <micahg> bbiab
[17:43] <qense> micahg: true, but the privileges team for the ubuntu project -- ubuntu-bugs -- also gets all bugmail
[17:43] <qense> it is sent to its contact address -- the ubuntu-bugs maillist -- and not to its members
[17:43] <qense> subscribing to the maillist is optional
[17:44] <qense> dpm: LP integration is also a task for the ubuntu-translations project?
[17:45] <xteejx> Can I use karmic PPA packages in Ludic?
[17:45] <xteejx> *lucid
[17:46] <qense> xteejx: you could fill karmic in as the distribution for those specific PPAs in your sources.list entries, and they might work, but they also might not
[17:46] <dpm> qense, it is a tag https://bugs.edge.launchpad.net/ubuntu-translations/+bugs?field.tag=needs-lp-integration for those apps which don't use the lp-integration lib, and thus are not showing the "Translate this application..." link (or the "Report a bug") one
[17:46] <qense> dpm: so bugs related to that should also get an ubuntu-translations task?
[17:46] <xteejx> so edit /etc/sources.list to include the karmic versions and fingers crossed?
[17:46] <xteejx> qense: ^
[17:47] <qense> xteejx: that's the solution, yes
[17:47] <xteejx> qense: didn't know that would work, thanks (#ubuntu was busy btw)
[17:47] <qense> packages like themes often work flawlessly, but more system critical applications can cause a mess
[17:48] <dpm> qense, that's what we've been doing so far. The idea is to group these bugs, since the patches to implement that functionality should be quite similar and could probably be ported from one app to the other
[17:48] <xteejx> I see
[17:48] <qense> dpm: ok, I will add that as well to the documentation then
[17:50] <dpm> great, thanks qense
[17:51] <qense> yw
[17:54] <dpm> qense, re: the suggestion on using the ubuntu-bugs team for translations, I'm not quite sure I follow? In which way do you think it could be useful for translations bugs?
[17:54] <qense> I wouldn't know, maybe some people would like to get all bug mail for ubuntu-translations?
[17:55] <dpm> qense, I'm not sure, they can already do that (and we encourage it) with https://bugs.edge.launchpad.net/ubuntu-translations/+subscribe
[17:56] <qense> well, it was just something that came up in my mind. If it's not useful then forget about it. ;)
[17:56] <qense> dpm: quick question, what is the name of the standard used for the language code in ubuntu-l10n-ll?
[17:57] <dpm> qense, iso 639
[17:58] <qense> dpm: thanks
[17:58] <dpm> no worries, here's the list of codes: http://www.loc.gov/standards/iso639-2/php/code_list.php
[17:59] <dpm> for the naming of Ubuntu Translations teams we use 2-letter codes or 3-letter ones if the former are not available
[17:59] <dpm> There is some more info there https://wiki.ubuntu.com/Translations/KnowledgeBase/StartingTeam
[17:59] <qense> ISO 639-3 ?
[18:00] <qense> ISO 639-2 is for less languages iirc, ISO 639-3 aims to cover all natural languages
[18:01] <dpm> we use the 639-1 (2-letter) code, if not available, then 639-2 (3-letter). Generally that covers it
[18:01] <qense> ah, the wiki page also names SO 639-3
[18:01] <dpm> 639-3 is used if we do not find the language in 639-2
[18:01] <qense> ok
[18:06] <qense> dpm: section added to https://wiki.ubuntu.com/Bugs/HowToTriage#Translation_Bugs_and_Launchpad_integration
[18:09] <dpm> qense, looks great - one note, I'm not sure we should so prominently mention Launchpad Integration, since it is just another type of bug related to translations, and perhaps not ass important as others. I think removing it from that section would make it simpler and less prone to confuse triagers
[18:09] <qense> But it is something you wouldn't naturally associate with translation.
[18:14] <dpm> yes, that's true, but I'm not sure I'd like to make it as prominent on the HowToTriage page, since it is described in more detail in Translations/HandlingBugs. Let me think about it... Otherwise, are there any other already established approaches for handling the launchpad integration library (since it basically affects translations, bugs and documentation)?
[18:17] <qense> dpm: I wouldn't know. I'll ask on the maillist what they think about mention it in the explanation in the mail I'm sending now to the teams with the details of what we've discussed here.
[18:17] <dpm> ok :)
[18:19] <pedro_> dpm, done re membership
[18:19] <dpm> pedro_, ah, great, thanks!
[18:19] <pedro_> np
[18:21] <tyranos> i m trying to report a bug and while reporting that bug i encountered this bug https://bugs.launchpad.net/malone/+bug/500856
[18:21] <ubot4> Launchpad bug 500856 in malone "Error while reporting a new bug" [High,Triaged]
[18:22] <xteejx> tyranos: For bugs in malone/LP better off speaking to the guys in #launchpad
[18:22] <tyranos> ok ill check it out
[18:27] <qense> I've sent a mail to the translations and bugsquad maillist about what we've decided in this meeting. Thanks for your minutes dpm!
[18:27] <dpm> qense, yesh, I'm still composing them, though :)
[18:28] <qense> I've already linked to them :) Anyway, it already gives a fair overview of the meeting.
[18:31] <hggdh> darn! Just remembered I have not yet added a warn to bugsquad on changes to our wiki pages :-(
[18:31] <hggdh> Will do it now.
[18:35] <tyranos> hggdh, i m back again trying to file that bug in hwinfo but i got this instead https://bugs.launchpad.net/malone/+bug/500856 how can i still file a bug
[18:35] <ubot4> Launchpad bug 500856 in malone "Error while reporting a new bug" [High,Triaged]
[18:35] <hggdh> tyranos: looking
[18:36] <hggdh> tyranos: you asked in #launchpad, right?
[18:37] <xteejx> tyranos: I'm not getting these blocked messages, have you been suspended or anything like that?
[18:37] <xteejx> It may be your ip has been blocked?
[18:38] <hggdh> xteejx: the #lp folks accepted the bug, so I guess it is a valid error. Since more of the OOPS are, er, unknown, only they can deal with it
[18:38] <xteejx> ahh ok, just a thought that's all
[18:39] <hggdh> pedro_: ping -- we should subscribe the bugsquad to changes to our wiki pages, but I do not seem to have auth for that
[18:39] <hggdh> brb
[18:40] <tyranos> xteejx, what do you mean by blocked messages?
[18:41] <xteejx> tyranos: Well I've had that message before. I asked in #lp and found out my IP had renewed itself from the ISP, and that was blocked by them for whatever reason. Had to have it unblocked
[18:41] <pedro_> hggdh, i cannot do that either, probably we need to ask to a wiki admin for that
[18:41] <xteejx> Blocked by LP I mean, not my ISP
[18:48] <hggdh> pedro_: thanks, will try to hunt down one
[18:49] <jjardon> Hello, how Can I remove Glade 3 as upstream here: https://bugs.launchpad.net/libglade/+bug/273233
[18:49] <ubot4> Launchpad bug 273233 in glade-3 "could not find a parent that handles internal children" [Unknown,Confirmed]
[18:51] <dpm> ok, meeting minutes finished at https://wiki.ubuntu.com/BugSquad/Meeting/Minutes/2010-01-19
[18:54] <xteejx> lol, my question about a stupid bug is in the meeting log! oh well :)
[19:00] <mrand> jjardon: change it to a null project (https://launchpad.net/null)
[19:01] <jjardon> mrand, how? I can't :/
[19:08] <mrand> jjardon: hmmm... seems we don't have permission.  The alternative is to move it to invalid for that project (preferrably including a brief note on why you're changing it to invalid).
[19:10] <jjardon> mrand, I can't change the status neither :(
[19:17] <hggdh> jjardon: you should be able to manually edit it -- remove the upstream bug reference (which is wrong anyways), and manually set the status to invalid. But you cannot remove it
[19:19] <jjardon> hggdh, thank you, now works :)
[19:19] <hggdh> jjardon: welcome, and nice to see you here ;-)
[19:20] <jjardon> hggdh, ;)
[19:38] <xteejx> bug 509802, what do we think?
[19:38] <ubot4> Launchpad bug 509802 in telepathy-idle "empathy does not allow /list command" [Undecided,New] https://launchpad.net/bugs/509802
[19:42] <qense> xteejx: it sounds like a feature request to me, so that would be wishlist. iirc it's already going to be supported in empathy 2.30, you'd have to check its roadmap to be sure though
[20:13] <xteejx> qense: Thanks. Just checked the roadmap for empathy, and its in GNOME bug 573407, but on that it says RESOLVED, FIXED, but there are no parts of the convo which say about the /list command
[20:13] <ubot4> Gnome bug 573407 in Multi User Chat "Empathy and telepathy-idle don't pass on server commands to server" [Enhancement,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=573407
[20:14] <qense> Well, I'd say link the bug to the report you've found on LP (if there is no other report on LP),generalise the LP report to include IRC commands in general and ask upstream for the /list command.
[20:14] <qense>  /list is in the bug description though
[20:15] <xteejx> It's in the LP bug because I filed it
[20:16] <qense> It was also mentioned in the GNOME bug report's description.
[20:16] <xteejx> I realise that :) What I mean is none of the patch attachments *actually* fix /list .. they only cover topic, join, query, msg and help
[20:17] <xteejx> I think they've missed that one or couldn't implement it
[20:17] <qense> I'd leave a comment asking for /list
[20:18] <kamusin> what or who is called this function that runs a postinstallation script when you are using synaptic? for example when you are installing a package and then finished an window called 'update information' appears that need run 'something' to finish all this process
[20:18] <xteejx> I didn't know I could do that hehe
[20:18] <kamusin> is it clear?
[20:19] <qense> xteejx: you do need a GNOME Bugzilla account, but everyone can comment on bug reports, yes
[20:19] <qense> kamusin: dpkg calls scripts included in the package
[20:20] <kamusin> but when I use dpkg for install this package.. you can skip this
[20:20] <xteejx> I have an account, and have done that thank you :) Fingers crossed they have a look and implement it
[20:20] <kamusin> for example if I install this package in a terminal
[20:21] <qense> kamusin: really? I didn't knew that
[20:23] <kamusin> well I found the mother of lamb
[20:23] <hggdh> kamusin: can you provide a package where this happens?
[20:24] <kamusin> bug 508089
[20:24] <ubot4> Launchpad bug 508089 in apt-file "apt-file fails 'There was an error creating the child process for this terminal'" [Undecided,Confirmed] https://launchpad.net/bugs/508089
[20:26] <hggdh> hum
[20:26] <hggdh> I will download the source package and have a look at it
[20:27] <hggdh> kamusin: for me, downloading might take a while. You can do the same, and look at the postinst since this is probably where this is triggered
[20:27] <yofel> hm, yeah, apt-file calls update-notifier when it's available
[20:27] <yofel> in the postinst script
[20:27] <kamusin> the main problem is located in /usr/share/apt-file/apt-file-update.update-notifier
[20:28] <kamusin> command is wrong
[20:28] <yofel> cool, it's been a while since I've seen a script calling su-to-root
[20:29] <kamusin> seh
[20:30] <hggdh> what is wrong in su-to-root?
[20:31] <yofel> nothing afaik, It's just that I rarely see it being used
[20:31] <kamusin> su-to-root do not exists
[20:31] <yofel> kamusin: huh? it does here
[20:32] <hggdh> it is provided by 'menu'
[20:32] <kamusin> I have too under karmic
[20:32] <hggdh> and should be a run-time depend for apt-file
[20:33] <kamusin> but not in lucid
[20:33] <hggdh> oooohh this is wrong... apt-file *suggests* menu. It should be required
[20:33] <yofel> it's a 'suggests'...
[20:33] <hggdh> heh
[20:34] <hggdh> so this is the cause of the error, kamusin. Please add the necessary comments. You might even go and propose a debdiff ;-)
[20:36] <hggdh> kamusin: BTW, thank you for spotting this one
[20:49] <kamusin> hggdh, :)
[20:49] <micahg> hmm
[20:50] <micahg> how do we not get mail for ubuntu-translations
[20:53] <montel> awesome. my karma went up 200
[21:04] <micahg> montel: one, please make sure you change status when requesting info from requestor
[21:04] <micahg> montel: two, please make sure that you have the package name correct
[21:04] <montel> micahg: thank you for letting me know.
[21:04] <micahg> montel: three, please try to be clear as to the reasoning when replying
[21:04] <montel> what bugs are you talking about?
[21:05] <micahg> montel: the FF one you showed me yesterday
[21:05] <montel> ah.
[21:05] <montel> micahg: wait, the one about the swf-dec?
[21:05] <micahg> montel: yes, the package name is swfdec-mozilla
[21:06] <micahg> montel: BTW, there's no need to mention the file as that confused the user
[21:06] <montel> Ohh..
[21:06] <micahg> montel: we get people with all skill levels opening these bugs
[21:06] <micahg> this user seems to be just starting
[21:07] <montel> ah.
[21:10] <montel> micahg: what number was that one
[21:10] <micahg> bug 509305
[21:10] <ubot4> Launchpad bug 509305 in firefox-3.5 "Firefox fails to display Flash for Ubuntu, while Konqueror does." [Undecided,New] https://launchpad.net/bugs/509305
[21:12] <montel> micahg: so what should i say back to him?
[21:13] <micahg> That he has 2 flash plugins that might be conflicting (swfdec-mozilla and adobe-flashplugin) and removing swfdec-mozilla will probably resolve the issue.
[21:14] <micahg> montel: the other possibility is that the addons are preventing it from showing
[21:14] <montel> ah. okay.
[21:14] <montel> thanks
[21:17] <montel> so it would be invalid or incomplete micahg ?
[21:17] <micahg> montel: incomplete
[21:17] <micahg> until the problem is solved or clearly not ours
[21:18] <montel> ah. how come i did not get a email when he responded to it micahg ?
[21:18] <micahg> montel: did you subscribe?
[21:18] <montel> no.
[21:18] <montel> i didnt know that i had to
[21:18] <micahg> montel: that's why :)
[21:19]  * montel loves the ajax in lp
[21:19] <ikt> https://bugs.launchpad.net/ubuntu/+bug/401066 <- no response, fixed, not fixed?
[21:19] <hggdh> known bug, still waiting resolution. You only get bug email for bugs you subscribe to
[21:19] <ubot4> Launchpad bug 401066 in ubuntu "Totem crashes while playing xvid encoded files and DVDs" [Medium,New]
[21:19] <ikt> montel:  I love the ajax as well, just wish lp overall would load faster
[21:19] <montel> ikt: Yes ,i agree
[21:19] <montel> Why do they require HTTPS?
[21:20] <micahg> montel: that's not what's slowing it down
[21:20] <hggdh> because of privacy issues, I would say
[21:20] <ikt> micahg: what's slowing it down?
[21:20] <micahg> ikt: the sheer amount of data IMHO
[21:21] <ikt> that's what I was thinking to, since later in the night it seems to get a bit faster
[21:21] <micahg> they're working on speeding things up with JS
[21:21] <hggdh> ikt: only the folks at #launchpad would be able to answer, but I think micahg is pretty much correct
[21:21] <micahg> so you don't need full page loads
[21:21] <micahg> but that in and of itself needs some speed up :)
[21:22] <micahg> ikt: LP is open source now, so patches welcome :)
[22:01] <xteejx> Why is my name not listed on the 5-a-day thing under "These fine people achieved their 5-a-day yesterday:" ??
[22:01] <xteejx> bdmurray, pedro_: ^
[22:02] <micahg> xteejx: do you have an email address visible in LP?
[22:02] <xteejx> yeah on my LP page I have 2 https://launchpad.net/~xteejx
[22:03] <micahg> xteejx: I get:        Email:                                                               No public address provided.
[22:03] <xteejx> strange...
[22:03] <xteejx> User information
[22:03] <xteejx> Email: Change e-mail settings
[22:03] <xteejx>     xteejyx@googlemail.com
[22:03] <xteejx>     xteejx@hotmail.co.uk
[22:03] <micahg> xteejx: do they have a lock next to them?
[22:03] <xteejx> yeah....
[22:04] <micahg> that means they're private
[22:04] <xteejx> oh wtf
[22:04] <xteejx> I just realised! What a div lol :P
[22:04] <xteejx> huh? I can't get rid of it
[22:05] <xteejx> Got it
[22:06] <xteejx> micahg: Will it not count me for today/yesterday because of that, or will it backdate it?
[22:07] <micahg> xteejx: no, it should backdate
[22:07] <xteejx> micahg: Cool. So I'll see my name somewhere on there at midnight? :)
[22:07] <micahg> you should
[22:08] <xteejx> I normally do 10-15 a day
[22:08] <micahg> xteejx: in about 2.5 hrs
[22:08] <xteejx> micahg: I'm GMT/UTC anyway ;)
[22:08] <xteejx> ...I think, it's 10:09PM here
[22:10] <xteejx> Expirable bugs don't go back any further than Jan 2009 now, took AGESSSSSSSS doing the 2008 ones but its all done.... and why the hell is my empathy window resizing while I'm typing?!?!?! BUGGGGG
[22:10] <hggdh> it's personal ;-)
[22:11] <xteejx> bloody rude!! That bug's gonna get a kick in the ermmm......
[22:13] <yofel> rofl, I'm looking through incomplete bugs right now and I like somewhat funny ones, but bug 497725 is somewhat...
[22:13] <ubot4> Launchpad bug 497725 in firefox-3.5 "No Bug" [Undecided,Incomplete] https://launchpad.net/bugs/497725
[22:14] <xteejx> hahahaha
[22:14] <xteejx> why report it then?
[22:14] <micahg> yofel: close
[22:14] <yofel> micahg: any idea if that can be closed?
[22:14]  * micahg was beingp olite
[22:14] <yofel> ok, I'll close it as missing requested inffo
[22:14] <yofel> *info
[22:15] <xteejx> Closed
[22:15] <xteejx> Hope the comment lightens the mood lol
[22:16] <yofel> we both did the same thing ^^
[22:16] <yofel> xteejx: and here I was thinking about being polite :P
[22:17] <xteejx> yofel: I wasn't being nasty, rather a cheeky comment ;)
[22:17] <yofel> heh, true *g*
[22:17] <xteejx> I remember last summer some of the guys were going to make a wiki page with the "dumbest bug reports"
[22:18] <xteejx> don't think they made it in the end
[22:18] <xteejx> Data Protection and all that
[22:19] <xteejx> Can anyone confirm bug 509866 (will take less than a min)
[22:19] <ubot4> Launchpad bug 509866 in ubuntu "empathy window resizes while typing in IRC" [Undecided,New] https://launchpad.net/bugs/509866
[22:32] <micahg> xteejx: please don't respond like that
[22:33] <xteejx> :( sorry
[22:41] <xteejx> How do I go about getting a package into Ubuntu, I'm interested in doing it myself
[23:01] <micahg> xteejx: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[23:02] <xteejx> micahg: Thanks :)