[00:01] <James500> I have a debdiff for a bug in a multiverse package - how do I report it?
[00:02] <secretlondon> attach it to the bug
[00:02] <secretlondon> and then subscribe universe sponsors
[00:02] <James500> to a Launchpad bug report?
[00:07] <secretlondon> yes
[00:13] <James500> thanks, bug report submitted
[01:54] <Laibsch> ﻿I wonder why anki which is in Debian is not in intrepid.  bug 145007
[01:55] <Laibsch> Same goes for latest version of apt-cacher-ng which is 0.1.9 in intrepid and 0.1.13 in debian
[01:55] <Laibsch> Am I misunderstanding something?
[02:04] <RAOF> Laibsch: I don't _think_ the autosync has been turned on yet?
[02:09] <ogra> well, MOM is runing
[02:10] <ogra> and the toolchian is in place
[02:14] <Laibsch> Ah, I see
[02:14] <Laibsch> I saw intrepid and immediately assumed the sync had been already done
[02:15] <Laibsch> So, I guess I need to be a bit more patient and things should fall into place
[02:19] <ogra> autosync should start soon
[02:49] <yuriy> ah the bot is broken
[02:49]  * yuriy was wondering why he didn't have a pile of bugs to look through
[11:00] <mr-russ> hi, does php have a upstream tracker attachement in launchpad?
[11:01] <james_w> it looks like "php" is registered
[11:02] <mr-russ> I got error when I put a bug URL in.
[11:03] <mr-russ> http://bugs.php.net/44890
[11:03] <mr-russ> Launchpad does not recognize the bug tracker at this URL
[11:04] <james_w> hmm, I'm not sure then
[11:07] <mr-russ> okay, I'll add the URL as a comment.  I have no idea how to add the php bug tracker, it's not a standard one I recognise.
[11:08] <james_w> mr-russ: once one of the experts is up we can get it done properly
[11:10] <mr-russ> bug no is: 218891
[11:10] <mr-russ> I may not be up when they get up.  Good old Australia in the middle of know where :)
[11:11] <james_w> thanks for the info, I'll relay it to them
[12:11] <gnomefreak> can anyone please try to reproduce bug 224966 ? no matter how hard i try i cant do it
[12:20] <laga> gnomefreak: works fine in kubuntu hardy, w/o compiz.
[12:21] <gnomefreak> thanks i think its something that he did :(
[12:21] <gnomefreak> wish i could prove it though without a shadow of a doubt
[13:30] <kahrytan> Hello
[13:30] <kahrytan> Should I change the title for https://bugs.launchpad.net/ubuntu/+bug/220952 ?
[13:36] <persia> kahrytan: As the issue seems to be about lack of support for a specific display model, changing the title might make it clearer to bug reviewers.
[13:36] <kahrytan> like to 'Xorg Config Needed for Viewsonic VA1916W"
[13:37] <persia> That certainly seems to encapsulate the issue more clearly.
[13:37] <kahrytan> I dont know the name of templates for displayconfig-gtk
[13:38] <james_w> kahrytan: Hi. I've been meaning to ask you about that bug. Are you using displayconfig-gtk, or are you using "System->Preferences->Screen Resolution"?
[13:39] <kahrytan> james_w,  gtk applet doesnt do much at all. displayconfig-gtk doesnt recognized the monitor so its generic.
[13:39] <james_w> kahrytan: sorry? I don't understand your answer.
[13:39] <kahrytan> james_w,  in short, both. Niether work.
[13:39] <james_w> In 8.04 the program that is run by "System->Preferences->Screen Resolution" changed, so displayconfig-gtk isn't right if you are using that.
[13:40] <kahrytan> displayconfig-gtk doesnt know what it is so its generic. And its not listed at all
[13:40] <kahrytan> and that Screen Resolution thing sucks royally. doesnt do anything useful
[13:41] <kahrytan> The only thing it is useful  is changging resolution and thats it
[13:43] <kahrytan> Ubuntu doesnt detect the monitor and even know what it is.
[13:44] <kahrytan> james_w,  Why you ask?
[13:45] <james_w> just to get the bug to the right plave
[13:45] <james_w> place, I mean.
[13:45] <kahrytan> So, What is your job
[13:46] <james_w> does that matter?
[13:46] <kahrytan> I changing title to "X Support needed for Viewsonic VA1916W"
[13:46] <kahrytan> or you got better one?
[13:47] <james_w> sounds good. I don't know where that needs to be included, but it's not displayconfig-gtk or gnome-display-properties, so I've invalidated that task.
[13:47] <kahrytan> Why?
[13:47] <james_w> they just get the information from X, and then tell it to tweak things.
[13:48] <kahrytan> How about, put it where Ubuntu can detect it and configurate X properly so it full screen games can be played?
[13:48] <james_w> I can't speak for displayconfig-gtk, but gnome-display-properties certainly has no idea of the quirks of a particular monitor.
[13:48] <kahrytan> X is right place.
[13:48] <kahrytan> Xorg
[13:48] <james_w> yes, and there is still a task open for that, I was just explaining why I closed it for displayconfig-gtk
[13:49] <kahrytan> But if it existed in the monitor list then people can use it to configured xorg.conf
[13:50] <james_w> yeah, but displayconfig-gtk is deprecated, and it's much better if X can do it all by itself.
[13:51] <kahrytan> Gutsy X did fine with it.
[13:51] <kahrytan> it's the version in Hardy that sucks
[13:52] <kahrytan> Why is displayconfig deprecated?  is there better tool to configure Xorg.conf?
[13:53] <kahrytan> NV driver detected it just fine, btw.
[13:53] <laga> vim
[13:53] <laga> scnr.
[13:53] <james_w> The plan is to move it all in to X
[13:53] <kahrytan> That explains the lack of support for this monitor. Someone forgot to add it?
[13:54] <james_w> I've no idea. I doubt that every monitor is listed
[13:54] <james_w> I imagine that the monitor is just reporting what it can handle incorrectly or in a strange way.
[13:54] <kahrytan> james_w,  again, NV driver did fine with it
[13:55] <kahrytan> james_w, http://launchpadlibrarian.net/14028337/NV_Output_Xorg.log
[13:55] <james_w> so it's a problem with the nvidia driver?
[13:55] <james_w> "Confirmed aka Tested and Broken for both Nvidia and NV drivers. "
[13:55] <kahrytan> not exactly
[13:56] <kahrytan> NV still adds bad rates to modelines.
[13:56] <kahrytan> But detects alright.
[13:57] <kahrytan> are they trying to do away with xorg.conf too?
[13:58] <james_w> bdmurray: Hi. When you get a minute can you do any necessary magic to add http://bugs.php.net/bug.php?id=44890 as the upstream watch of bug 218891?
[13:58] <james_w> bdmurray: or is it that lp needs to add support for dealing with the php tracker?
[13:59] <james_w> kahrytan: yes, in most cases, it would still be used as a way to change things if needed (driver etc.).
[14:00] <kahrytan> james_w, Thats a really bad idea.
[14:00] <kahrytan> Unless X developers want to keep on top of every single hardware ever created past, present, and future.
[14:01] <james_w> that's their plan.
[14:01] <james_w> I'm going to get lunch now, back later.
[14:01] <kahrytan> Yeah bad idea
[14:01] <kahrytan> really bad.
[14:01] <kahrytan> They should focus on other things.
[14:02] <kahrytan> otherwise, bugs like this will continue to happen forever.
[14:21] <bddebian> Boo
[14:21] <jaredbuck> hey. what's up?
[14:32] <niekie> Woei!
[14:32] <niekie> Err.. wrong chan.
[14:59] <thekorn> I got an additional slot today in the openweek, does anybody have suggestions on how to fill this extra hour?
[15:03] <qense> a Q&A hour about bug triaging/managing? Explain who can set what, what's the purpose of milestones, why you shouldn't mark duplicates as invalid
[15:03] <qense> what teams you have to join
[15:03] <qense> what you ahve to do before you're a bug triager
[15:03] <gaurav> ^ that would help me :)
[15:06] <james_w> hi thekorn. I like the libnotify support in the applet, thanks.
[15:06] <qense> yes, that's a nice feature
[15:07] <thekorn> sounds like a plan, so if anybody who is more experienced in bug triaging and maybe more involved into the whole process have some time in the 16.00 UTC hour, feel free to join the session
[15:07] <qense> I can help a bit
[15:07]  * thekorn waves to james_w 
[15:08]  * thekorn hugs qense 
[15:08] <qense> :)
[15:08] <qense> it's already 16:08 here, but still two hours until it's 16:00 UTC
[15:09] <jaredbuck> it's a little after 7 am in my neck of the woods.
[15:09] <gnomefreak> 10 here
[15:16] <qense> thekorn: When I upgraded my fathers computer to hardy the upgrade programs removed the five-a-day program. I think this was done because the repository containing the tool was (temporally) disabled. But is this a bug in five-a-day or in the updater? I don't like it when programs I'm using are removed during an upgrade. ;)
[15:18] <qense> pedro is also having a talk about the bugsquad tomorrows
[15:19] <thekorn> qense, I'm by no means a packaging magician, i've no clue, the simpliest answer for me is: it's the updater ;)
[15:20] <thekorn> but feel free to open a bugreport and add a five-a-day task and we can try to sort it out
[15:20] <qense> I think I'm going to do that
[15:20] <qense> but what's the package for the updater?
[15:21] <thekorn> not sure, maybe update-manager
[15:22] <james_w> qense: did you grab the logs from the upgrade?
[15:23] <qense> I'm grabbing them at the moment
[15:23] <james_w> cool, let us know and we can have a log
[15:23] <james_w> s/log/look/
[15:33] <qense> ah
[15:33] <qense> the package had a broken dep on libbonobo2-bin
[15:33] <qense> it was a dependency op the applet, which was a dependecy of the program tiself
[15:35] <qense> it's probably already solved
[15:42] <afflux> morning
[15:42] <qense> hello
[15:43] <jaredbuck> good morning.
[15:43] <MightyTweek> morning!
[15:44] <afflux> yippie, bughelper session in ~15 mins
[15:44] <thekorn> good morning afflux, how are you doing today ;)
[15:45] <afflux> thekorn: I'm fine, could sleep longer than estimated ;)
[15:45] <jaredbuck> and it's a double dose of bughelper too - two hrs today.
[15:45] <afflux> oh right
[15:47] <jaredbuck> yeah. and jcastro's having a q and a session right after.
[15:48]  * afflux will start reading the python packaging logs from yesterday evening
[15:49] <jaredbuck> too technical for me, that.  i read the kde 4 and podcast logs :)
[15:50] <james_42> where will the bughelper session be held?
[15:50] <afflux> #ubuntu-classroom-chat
[15:50] <afflux> argh, not -chat
[15:51] <james_42> afflux: thanks
[15:57] <qense> thekorn: gl ;)
[15:57] <thekorn> ;)
[16:05] <qense> the next hugday at https://wiki.ubuntu.com/BugSquad isn't right I suppose
[16:05] <qense> unless we're going to wait for another year
[16:08] <afflux> that was the wrong button :(
[16:18] <ScottK> bdmurray: Would you please emphasize/add as needed in your documentation the bugsquad people should leave sync/merge bugs alone?
[16:18] <ScottK> Stuff like https://bugs.launchpad.net/ubuntu/+source/wammu/+bug/225669/+activity interferes with our MOTU workflow.
[16:19] <afflux> ScottK steals my suggestions!
[16:19] <persia> Nah.  It's called "relaying good ideas".  It's collaboration.
[16:19] <afflux> oh. ;)
[16:19] <ScottK> Actually, I think another good rule would be for bugsquad not to touch any bug that has ubuntu-universe-sponsors, ubuntu-main-sponsors, or ubuntu-archive subscribed.
[16:20] <ScottK> My first plan was to hunt down the individual in question and explain it to him, but he's not on IRC right now, so I decided to work on a more systematic approach.
[16:21] <afflux> (possibly related:) IMHO our guidelines should be far more visible to new LP users. Lots of users just set bug states without knowing what "fix committed" actually means. Same thing for assignments
[16:22] <qense> yeah, we should integrate it somehow
[16:22] <qense> maybe we should actually use the help system
[16:23] <qense> I've written this as stock reply for Brainstorm bugs: http://pastebin.ubuntu.com/9509/
[16:23] <afflux> hum, that's not really close to the bug interface imho. I learnt about the help system quite some time after I started using LP
[16:23] <qense> do you think it's good enough?
[16:24] <ScottK> qense: Personally I'm not a fan of stock replies.  They come across as impersonal and are counter to the idea of Ubuntu being Linux for human beings.
[16:24] <jaredbuck> me either.
[16:24] <qense> yeah, I don't use them very often. Almost never actually. ;) But it's a task on the ToDo list, I think at least someone wants to use it.
[16:29] <persia> Just because someone wants to avoid thinking by using a stock reply doesn't mean they should be encouraged.
[16:29] <qense> :D
[16:30] <qense> I think ti would be good to discuss with bdmurray if stock replies are really needed
[16:30] <qense> because (almost?) everypne here says (s)he doesn't use it
[16:30] <afflux> they were useful for me when I started triaging.
[16:31] <afflux> I still use some of them to get the "best" wording, since I'm a non-native englishspeaker and I sometimes have to check gramar or similar stuff.
[16:31] <afflux> that does not mean I copy+paste them and click "submit" but rather take parts, adjust them to fit the needs in the respective bug and so on
[16:31] <qense> they are indeed a good guideline
[16:31] <james_w> I think recommending that you tweak the wording each time or similar would take away most of the impersonal nature.
[16:32] <persia> afflux: That's a good point.  The stock replies can definitely be useful for people learning English.  It's hard to balance it right, and would likely benefit (as with so much else) from more, and better, documentation.
[16:32] <qense> we could also make checklists for everycase
[16:32] <qense> so you know what to include
[16:32] <james_w> however, ask someone that deals with hundreds of bugs whether they are useful in some circumstances.
[16:32] <afflux> exactly
[16:33] <qense> pedro!
[16:33] <persia> james_w: TO a certain degree, I agree, but on the days that I've gone over 100 bugs triaged, I've tended to type roughly the same thing in every case, but could rarely cut & paste, as each bug is a little different.
[16:33]  * persia can never get above about 25 unless focusing on vertical triage: lots of bugs in the same category
[16:36]  * afflux recommends https://wiki.ubuntu.com/UbuntuBugDay/20080425, there are plenty left and most of them are easy to check off ;)
[16:36] <ScottK> I see utility is saying the reply should be along these lines and include these elements.
[16:36] <james_w> maybe I'm wrong then, I've just seen stock replies used for things like duplicates from people like pedro who triage loads of bugs.
[16:38] <ScottK> Particularly in the case of duplicates, I think it's important to encourage people to learn and continue to contribute.  I think that's more important that have the bug database more accurate.  Stock replies are not as a rule encouraging to receive.
[16:38] <ScottK> Even if he has a basic stock answer, it should still be adjusted for the situation and not just reused verbatim.
[16:39] <persia> I am frequently bothered by finding bugs with the duplicate stock reply and no duplicate marker.  I think it's almost better to have a duplicate marker with no comment.
[16:42] <afflux> persia: not sure. I'm subscribed to a bug with a fairly big number of duplicates and some of them had no comment but just the marker, resulting in people commenting on every bug but the master
[16:42] <bdmurray> ScottK: you said bug 225669 right?
[16:43] <persia> afflux: Maybe.  My bother is when I get bugmail saying something is a duplicate with no pointer to the master, as it means I would have to repeat someone else's work in order to follow the thread.
[16:43] <ScottK> Yes.
[16:44] <bdmurray> And the bug shouldn't be confirmed?
[16:44] <ScottK> bdmurray: The fundamental problem is bugsquad really shouldn't try to 'improve' these workflow bugs.
[16:44] <bdmurray> ScottK: Well these aren't even really bug reports per se.
[16:44] <ScottK> bdmurray: No.  Because for a sync request confirmed means that a MOTU has reviewed it and agrees a sync is the correct thing to do.
[16:44] <ScottK> Exactly.
[16:44] <persia> bddebian: Right, but LP is also used for workflow.
[16:44] <afflux> persia: ah yes
[16:44] <Konam> The package gnome-subtitles isn't working as expected on my system. It crash when I try to create a new sub and doesn't open subs that I already have on my hdd
[16:45] <bdmurray> I've mixed feelings about sync requests even being in the bug tracker.
[16:46] <persia> bdmurray: I can agree with that, but it's where the archive admins want them for now.  There's the same issue with MainInclusionReports, merges, etc.
[16:46] <bdmurray> So then bug triagers should not touch - MIR, sync requests, merges and needs-packaging bugs?
[16:47] <qense> maybe we should create a separate website for merge/sync requests?
[16:47] <persia> Probably also promotion/demotion bugs, and remove-from-archive bugs.
[16:47] <persia> qense: As long as you have all of subscriptions, LP-authentication, LP-teams, and ability to directly interact with Soyuz, that sounds like a good idea.
[16:48] <qense> if it would be in python you can just use the lp module
[16:48] <persia> Well, except for the interact-with-Soyuz bit.
[16:48] <qense> oh
[16:49] <ScottK> qense: A lot of this used to be tracked on the wiki, but it didn't scale.
[16:50] <bdmurray> My concern is asking people to come help triage bugs excpets for a,b,c,d and sometimes e.
[16:50] <ScottK> bdmurray: I think a simple rule is to look and see who's subscribed.  uus/ums/ubuntu-archive/motu-release/ubuntu-release/ubuntu-mir bugs should all be left alone.
[16:51] <qense> can't the LP devs create some automated marker to make this more clear?
[16:51] <ScottK> Even if there are issues in those bugs, it's a safe bet someone more experienced is/will look at the bug.
[16:51] <persia> What about ubuntu-sru/motu-sru?  Does their workflow get interrupted by changes, or is it better integrated with bugsquad?
[16:52] <persia> qense: Yes, but not soon.  See e.g. bug #180388 as an example of one of those sorts of things
[16:53] <qense> it would be great if bugs in specific packages would get a certain flag
[16:53] <persia> bug #179857 covers some of the issues as well.
[16:53] <bdmurray> persia: I don't think so as bugs going through SRU are at Confirmed / Triaged state and most mistakes happen to New bugs.
[16:54] <persia> bdmurray: I think you're probably right.  I also think the SRU teams are more integrated with their use of bug status as those tend not to be workflow bugs.
[17:56] <qense> What should we do with https://wiki.ubuntu.com/Bugs/Triaging ? I haven't had time for it lately and I have to admit that I've also forgotten it.
[17:57] <bdmurray> I thought there was a fair bit of overlap with it and debugging procedures
[17:58] <qense> yes, that's true
[17:59] <bdmurray> For example if you look at https://wiki.ubuntu.com/DebuggingUpdateManager there is a section for Forwarding Upstream although it isn't necessary
[17:59] <qense> there is also a group of wiki pages about upstream bug trackers
[17:59] <qense> I think we should merge those three groups into one
[17:59] <bdmurray> It had been my thought that each package, or subsystem, would have a landing page like that
[18:00] <qense> that was also my though
[18:00] <qense> but the upstream peopel didn't reply to my email
[18:00] <qense> (except for the libmtp people)
[18:02] <bdmurray> I think some packages will point to the same upstream page so have the upstream page separate makes sense to me
[18:03] <bdmurray> However, we could setup an include to make it all on one page
[18:03] <qense> but does the include function already work?
[18:03] <qense> I know there is a marco for that but I don't know if it's already enabled
[18:04] <bdmurray> Yes, if you look at http://wiki.ubuntu.com/Bugs/Tags you can see network-manager and update-manager tags included
[18:05] <qense> wouldn't it be better to create pages like http://wiki.ubuntu.com/Bugs/Package/* and let that pacakge contain all information we have/need about that package
[18:05] <qense> of course the tags should also be held at Bugs/tags to keep an overview
[18:07] <bdmurray> Having Bugs/Package/* makes sense and is easier to remember than DebuggingPackage.  I think we'd need to setup redirects though as a fair number of bug reports point to the existing wiki pages
[18:09] <qense> I'd say that we should make the old/current pages redirect to the new one
[18:09] <qense> but it will be a lot of work to gather all information about all packages
[18:10] <bdmurray> right, so looking at the packages with the greatest number of bugs first makes sense to me
[18:11] <qense> are we going to use the packages launchpad uses?
[18:12] <bdmurray> What do you mean exactly?
[18:12] <qense> in lp you have different names like gnome-system-utils instead of users-admin
[18:13] <qense> I think ti would be the best idea to use gnome-system-utils to limit the amount of work needed
[18:15] <james_w> qense: that's the "source" package name, and it's what developers tend to refer to the package as, so I would suggest sticking with that.
[18:15] <james_w> if there are packages that are not at all obvious we could set up redirects.
[18:15] <bdmurray> Ah, yes naming it the same as the Launchpad package makes sense but maybe we should also add a user-admin page that redirects to the package name
[18:18] <qense> how are we going to gather all the data?
[18:19] <qense> it's quite a lot of work that needs to be done
[18:20] <bdmurray> The information about how to treat a package?  I think it'll need to happen manually.
[18:20] <qense> yes
[18:21] <qense> I think we need to create some kind of ToDo list where people can assign themselves to a package
[18:22] <qense> is there a way to export a list of packages from LP?
[18:23] <bdmurray> I think we should focus on ones widely used and with lots of bugs first rather than looking at every package in LP
[18:24] <qense> but we need to keep track of what's done at some way
[18:25] <highvoltage> howdy! anyone around?
[18:25] <bdmurray> I could probably get that list
[18:25] <qense> hello highvoltage
[18:25] <qense> ok
[18:25] <highvoltage> hey qense
[18:25] <highvoltage> if a bug is resolved in hardy, and the bug was filed against gutsy, then the bug can be resolved right?
[18:25] <highvoltage> refering to https://bugs.launchpad.net/ubuntu/+source/firefox-themes-ubuntu/+bug/136686 in particular
[18:27] <qense> yeah, that can probablu
[18:35] <qense> bdmurray: shall I create the page directly or do you think it would be better to wait for the list?
[18:36] <bdmurray> qense: which page? we've talked about quite a few things recently
[18:39] <qense> a starting page for Bugs/Packages, the progress page for this and maybe a start with the content
[18:40] <bdmurray> I think talking about it with the whole team on the mailing list would be a good idea.
[18:41] <qense> ok
[18:41] <qense> I'll try to write a summary of what we've just discussed and mail it to it.
[18:41] <qense> bugcontrol or bugsquad?
[18:42] <bdmurray> bugsquad I think
[18:42] <qense> ok
[22:54] <afflux> good night