[00:01] <sn9> it should also be noted that the original mac layout as used on macs never actually used these particular compose sequences, so finnish users would still notice it long before anybody else
[00:01] <RAOF> Right.
[00:02] <RAOF> The couple of commits needed to be cherry-picked for finnish support should be an easy SRU.
[00:02] <RAOF> I'm less sure about the overall mac one, because it's not a regression.
[00:04] <sn9> well, debian decided that cherry-picking would be more regression-prone in this case than a simply resynching with upstream
[00:04] <RAOF> Then perhaps we should do the same.
[00:04] <sn9> IOW, a backport from intrepid
[00:04] <RAOF> Regardless, the bug is more obviously SRU worthy when talking finnish.
[03:17] <tlp> Hi. I'd like to report a bug, but I'm not sure what package it pertains to. I think it might be ALSA, but I'm unsure--the bass/treble mixer controls are broken on the SB Live! 5.1 unless 'Tone' is checked and enabled.
[03:23] <persia> tlp: Take a look at https://wiki.ubuntu.com/DebuggingSoundProblems
[03:24] <persia> I think it's a bug, but might be a minor usability issue, and may not be easy to fix.  Starting there ought help you get sufficient information to describe the problem in a way that can be used by the developers to determine if a solution is possible.
[03:24] <tlp> yeah, found that. Thanks. I'm hoping it's just something that can be enabled by default.
[06:27] <gnomefreak> mrooney: are you around?
[06:28] <persia> gnomefreak: mrooney said goodnight a couple hours back (which may not be an answer, but may provide a hint)
[06:28] <gnomefreak> persia: thanks ill catch him tomorrow
[06:47] <mcas> hi i need some help with one bug on lp
[06:48] <mcas> bug 247310
[06:48] <mcas> is this invalid or wishlist?
[06:49] <persia> mcas: Probably wishlist, unless there is already some other mechanism in place to handle adding additional configuration files.
[06:50] <mcas> ok can you please change it to wishlist i cannot do this
[07:00] <persia> mcas: Done.  Have you completed the research from reading the README files and similar?  I suspect that if you're sure it's wishlist, you can also confirm it (in which case, please do)
[07:06] <mcas> persia: thx
[07:08] <mcas> i looked for some informations about this and the README tells you to add one more file and they tell you to do so in /etc
[07:09] <mcas> so i don't know if it will be a good decision to change the default locations of config files
[09:31] <sn9> hmm, can't sleep. i think i'll just join #ubuntu and help folk
[11:03]  * amireldor is away: I'm busy, sorry
[11:13] <afflux> morning
[11:22] <mouz> If a bug has status 'Fix Committed', should I find it in https://launchpad.net/ubuntu/intrepid/+queue (under any of the queue states)? I ask because the patch in bug 223882 is not applied in the version I find there. I'm tempted to set the status of the bug back to 'Confirmed'.
[11:34] <Hew> what package would Preferred Applications be listed under in Launchpad?
[11:37] <sn9> gnome-control-center
[12:16] <joumetal> mouz: according to https://wiki.ubuntu.com/Bugs/Status 'Fix Committed' is correct.
[12:18] <joumetal> Does someone have powers to set 2.6.22 part of bug 130923 Wont fix?
[12:19] <gnomefreak> joumetal: you want to change fix released to wont fix?
[12:19]  * gnomefreak wonders why since fix released means its fixed
[12:20] <joumetal> gnomefreak: just gutsy part of it.
[12:20] <gnomefreak> joumetal: ok opening and looking
[12:20] <gnomefreak> why cant you change it?
[12:21] <gnomefreak> we already have plans to bump the version of pulse audio in Gutsy so i can get flash 10 into gutsy backports
[12:22] <gnomefreak> joumetal: i dont see a gutsy task i see the kernel task and its marked triaged
[12:24] <joumetal> i don't have option wont fix. maybe because not having permissions to set priority.
[12:24] <gnomefreak> joumetal: you want the kernel task wont fix?
[12:25] <gnomefreak> bdmurray: what is up with the kernel task on bug 130923 you set it to triaged is it being worked on?
[12:26] <persia> joumetal: re: Fix Committed: it's only correct to set this when something gets put in VCS for bugs against upstream projects: not for bugs against Ubuntu (with some special exceptions).
[12:26] <joumetal> gnomefreak: are there better options for 2.6.22 kernel? probably not worth of sru.
[12:27]  * gnomefreak trying to figure out what the linux task is about and why was it marked fix released if the kernel task is now a wont fix
[12:27] <gnomefreak> joumetal: we will never backport a kernel or change the base kernel in the release.
[12:28] <gnomefreak> joumetal: example in hardy there is kernel 2.6.24 (i think) it will stay 2.6.24 only the last digit will change
[12:28] <persia> The 2.6.22 is for Feisty.
[12:28] <afflux> gnomefreak: the "linux" task means kernel >= 2.6.24, linux-source-2.6.22 is the "gutsy" task. he asks for wontfix, because the fix is in the hardy kernel (so source package linux), and probably won't get backported to 2.6.22.
[12:29] <gnomefreak> changing kernel versions in a stable release is ALWAYS a bad idea and will break things
[12:29] <afflux> persia: feisty was 2.6.20, wasn't it?
[12:30] <gnomefreak> afflux: its assigned to a team that means that someone from the sound team should look at it and decide unless someone just added them to bug for giggles
[12:30] <gnomefreak> afflux: yes
[12:30] <persia> Err  Gutsy.  Anyway, while the version won't be backported, it may be possible to create a patch for just this issue against 2.6.24: it ought get an SRU decision.
[12:30] <persia> afflux: Yes.  I can't count :)
[12:30] <afflux> it's assigned to the team because it's the kernel bug policy for triagers to assign bugs to the specific teams.
[12:31] <gnomefreak> the fix can land in gutsy since i know crimsun will be/is working on pulseaudio for gutsy
[12:31] <persia> gnomefreak: That'd be an argument for leaving the Gutsy task as "Triaged" rather than "Won't Fix".
[12:31] <afflux> mark it for sru then
[12:34]  * gnomefreak still not seeing a reason to change it to wont fix without talking to sound team it is in thier hands crimsun is on that team and last i heard he was going to see what he can do to get pulse audio in Gutsy to get flash 10 to work. As for kernel patch that is possible and yes sru might be possible 
[12:35]  * joumetal leaves it triaged then.
[12:35] <gnomefreak> you might want to talk to someone from the team before changing it (not sure if bdmurray had a reason to set it to triaged (triaged means all info is on the bug to fix it and is ready to get a fix) thats why i would leave it for sound guys
[12:42] <mrooney> gnomefreak: hi!
[12:42] <gnomefreak> hi
[12:43] <mrooney> gnomefreak: I see you were perhaps looking for me?
[12:43] <gnomefreak> mrooney: i dont remember why it was about a bug but dont rmeember sorry
[12:43] <mrooney> gnomefreak: okay :) well let me know if you do remember
[12:44] <gnomefreak> k
[12:54] <EdgeAU> Hello, I reported a bug with the package ivman a couple of months ago and supplied a patch written by somebody else (and tested by me) and nothing has been done about it. How can I help get the patch into the next version of the package?
[12:55] <EdgeAU> GVORR: hello, can you help me get a bug fixed (I have the patch)
[13:04] <EdgeAU> Hello, I reported a bug with the package ivman a couple of months ago and supplied a patch written by somebody else (and tested by me) and nothing has been done about it. How can I help get the patch into the next version of the package?
[13:06] <savvas> is it normal that thunderbird uses ~/.mozilla-thunderbird and firefox uses ~/.mozilla/firefox ? shouldn't it be in ~/.mozilla/thunderbird too?
[13:13] <broonie> EdgeAU: Ask on #ubuntu-motu
[13:13] <broonie> EdgeAU: They're the people responsible for updates to packages in Universe.
[13:36] <gnomefreak> savvas: yes depending on what you mean
[13:36] <gnomefreak> savvas: thunderbird has a separate profile than firefox
[13:37] <gnomefreak> in hardy thunderbird uses ~/.thunderbird and firefox uses ~/.mozilla/firefox or *default*
[13:37] <gnomefreak> we dropped ~/.mozilla-thunderbird
[13:38] <gnomefreak> broonie: motu doesnt do updates to mozilla apps
[13:38] <gnomefreak> oops you meant EdgeAU
[13:57] <hefe_bia> sn9: I have updated the debdiff for bug 223812. Thanks for the patch and the discussion!
[13:57] <savvas> gnomefreak: i just installed thunderbird and it used ~/.mozilla-thunderbird
[13:59] <savvas> gnomefreak: it's not much of a big deal.. just that it would be easier if it was .firefox and .thunderbird, I got confused while helping out a user :)
[14:01] <gnomefreak> savvas: cant we put more than just firefox into ~/.mozilla
[14:02] <gnomefreak> savvas: looks like they changed it back
[14:02] <gnomefreak> hold that thought
[14:03] <gnomefreak> ah ok i think ~/.thunderbird was used for tbird-3
[14:04] <gnomefreak> savvas: you would have to talk to asac about that but there is a reason we us ~/.mozilla/firefox instead of ~/.firefox
[14:04] <gnomefreak> i just cant remember why
[14:08] <asac> savvas: tbird being in that folder is historic cruft. .mozilla/firefox is intended though
[14:11] <gnomefreak> personally if everything mozilla got dumped in ~/.mozilla/ would be best IMHO but tbird i know we cant
[14:11] <gnomefreak> but atm liferea and friends use own profile
[14:25] <savvas> thank you both for the clarification :)
[18:27] <hggdh> any Dutch speakers here?
[18:28] <hggdh> if so, please help translating bug 247378
[18:32] <bdmurray> hggdh: I'm looking at bug 247607 and wanted some feedback regarding it
[18:38] <hggdh> bdmurray, what can I do for you?
[18:39] <techno_freak> bdmurray, by any chance the global bug jam teams get EeeBotu for their channels? if yes, whom should i request?
[18:39] <bdmurray> techno_freak: I believe EeeBotu belongs to mrooney
[18:39] <techno_freak> bdmurray, ok :)
[18:40] <bdmurray> It'd be interesting to have it customized for the bug list the loco is working on.  For example if a team was working with update-manager have it annouce new update-manager bugs
[18:41] <techno_freak> hmm :) but we are starting our introductory sessions tomorrow, so thought that a general bug bot will help, during the bug jam we might have specific packages to concentrate
[18:41] <sn9> so, what's the story with ubotu vs. ubottu?
[18:42] <bdmurray> hggdh: I can't believe I'd include Invalid by accident but I can't remember why I included it either! ;)  I'd appreciate some help reviewing http://people.ubuntu.com/~brian/tmp/invalid-patches.csv to ensure that they really should be Invalid.
[18:42] <bdmurray> techno_freak: oh, have general announcements makes sense for an intro session then
[18:43] <techno_freak> yes :)
[18:46] <bliZZardz> techno_freak : tuxmaniac had asked similar Qs in #ubuntu-motu and the following were shared https://launchpad.net/ubuntu-bots , https://edge.launchpad.net/ubuntu-bots ..
[18:46] <hggdh> bdmurray, will do
[18:47] <bdmurray> hggdh: outstanding!  I've looked at a few myself and they didn't seem to belong
[18:48] <hggdh> bdmurray, my pleasure; I will start from the bottom of the list; what should I do with each I find?
[18:49] <hggdh> and I understand that real invalids are correct in the list
[18:49] <bdmurray> hggdh: I was just looking for a spot review of like 10 or so.  :)  I feel like Invalid shouldn't be included too, but wanted another person to check too.
[18:50] <bdmurray> I remember explictly including duplicates because patches could be lost that way but I've yet to find a use case for Invalid being included.
[19:18] <hggdh> bdmurray, I cannot find any that does not apply
[19:18] <bdmurray> hggdh: okay, great I'll fix that now then
[19:19] <hggdh> bdmurray, thank you
[19:19] <hggdh> also -- the repeats we have there will not hurt, correct (some entries are repeated)
[19:20] <bdmurray> hggdh: I think they don't show up in harvest itself
[19:20] <hggdh> cool
[19:21] <hggdh> good work, BTW
[19:25] <bdmurray> Thanks, it was an interesting problem and I hope the data is useful.
[19:27] <hggdh> bdmurray, it is, I am already using it to review bugs
[19:27] <bdmurray> http://people.ubuntu.com/~brian/reports/harvest/patches.csv should not have them now
[19:33] <savvas> is there a team for hardware bugs?
[19:33] <savvas> ( bug 247541 )
[19:35] <hggdh> I confirm that the one I found originally is not in the patches.csv
[19:35] <bdmurray> Cool, that should resolve it then
[19:36] <hggdh> bdmurray, how long for the harvest-data to be updated?
[19:36] <sn9> savvas: sudo update-pciids
[19:37] <savvas> sn9: wait, I'll see if he's around
[19:40] <savvas> sn9: he's not here, should he do that and post lspci again?
[19:41] <bdmurray> hggdh: I'm not certain
[19:41] <sn9> savvas: yes, and especially, what the problem actually is, since you never said
[19:42] <savvas> will do!
[19:44] <savvas> sn9: i think the problem is his sata disk, but there were a lot of other unknown devices listed there, but anyway, I'll ask him what specific problems he has when he comes back
[21:05] <eyalev> I think Bug #247638 should be set to wishlist.
[21:06] <sn9> that bug title is awkward...
[21:23] <persia> eyalev: I think the space key does that.  Can you confirm?  I'm fairly sure it's "Invalid".
[21:24] <persia> Oh.  Enter too.  The big keys.  Hard to miss.  Much easier to hit than F2 :)
[21:25] <eyalev> Confirmed indeed :)
[21:25] <persia> eyalev: In that case, please update the bug.
[21:26] <eyalev> sure, thanks.
[21:31] <eyalev> ﻿persia: I marked as Invalid. Is this the end of triaging for this bug?
[21:32] <persia> eyalev: Yep.  You've provided the workaround, and marked it Invalid.  time for the next bug.
[21:34] <persia> I generally try to provide a short explanantion when marking Invalid.  In this case, I'd have said "I'm marking this bug as Invalid as are a couple different single key shortcuts to restart the game."
[21:34] <persia> While this is a repetition to the workaround described, it also helps the submitted understand why it is Invalid, so they are less likely to feel their issue isn't important.
[21:35] <eyalev> I'll keep that in mind, thanks.
[21:35] <persia> Note that if you encounter something like this where it's not a bug, but you can't find the answer so quickly, you'd use the Convert to Question function to help redirect the submitter to the appropriate support forum: when you know the workaround, there's no point to opening a question.
[21:39] <eyalev> Thanks for all the explanations, sure gives motivation for some more triaging.
[21:41] <persia> eyalev: Thanks for helping out.
[21:56] <eyalev> Triaging question: bug 247435 is duplicate of 202089?
[21:56] <persia> bug 202089
[21:58] <persia> eyalev: Likely, although I'm not sure there's enough information to be sure (or at least to my eyes right now).
[22:00] <eyalev> ﻿persia: What sould I do then?
[22:02] <persia> eyalev: Try to understand the bugs better than I.  If you're sure they are the same, mark 247435 as a dup.
[22:02] <eyalev> ﻿persia: ok
[22:02]  * persia only looked quickly:; they are simillar, but there may be more hints somewhere in one of the current dups for 202089 or in the tail of the comments to verify for sure.
[22:35] <mrooney> bdmurray: I can definitely at least spin off a bot to do custom bug jam stuff, I don't think I can easily have it working as one bot
[22:36] <bdmurray> mrooney: ah, that makes sense it'd have know which channel it was in and what they were working on
[22:37] <mrooney> ideally I want to have EeeBotu able to have people register "callbacks", so you give it a regex and a nick/chan to announce to, and it checks each for any matches per global ubuntu bug
[22:37] <mrooney> so with that infrastructure I think might work for many neat cases
[22:38] <bdmurray> that'd be sweet!  I'd like it if only announced High or Critical bugs somewhere
[22:38] <mrooney> but if you wanted it to say, scrape a wiki page for changes, that would require some sort of spinoff probably
[22:39] <bdmurray> mrooney: no, what I had in mind was a list made a head of time and then if any new bugs came in about that package during the jam the bot would announce those
[22:39] <bdmurray> the list being the wiki page
[22:39] <mrooney> bdmurray: yeah, I am thinking you register a callback and can send like -importance string -package string, etc, where each string is a regex
[22:40] <mrooney> so it should be really flexible that way, and something like just announcing HIGH|CRITICAL would be trivial
[22:40] <bdmurray> that's very exciting
[22:41] <mrooney> yeah, I just have to settle on a python irc bot package, there are a bunch
[22:42] <mrooney> the only hangup with a channel is you can't msg channels which you aren't in, so I guess EeeBotu would have decide how to handle that, hang out in the channel as long as the callback exists, perhaps, since naturally there will be a way to unregister callbacs
[22:42] <persia> While you're both here...
[22:43] <persia> bdmurray: What do you think about setting -t in -announce so mrooney can update the /topic with bot status, etc.
[22:44] <bdmurray> persia: I actually have no thoughts about it since I'm not really certain what it does. ;)
[22:44] <persia> It allows anyone in the channel to change the topic.  With +t, changing the topic is limited to channel operators.
[22:45] <persia> (the other option would be adding mrooney to the channel operator list, but that requires coordination with IRCC, which may not be quick).
[22:45] <persia> I think the people in that channel are a fairly small group, and tend to watch, so we'd catch any /topic abuse.
[22:46] <bdmurray> And we have pretty good timezone coverage for people in that channel?
[22:46] <sn9> /topic foo? bar!
[22:46] <persia> Well, there's you and I, which probably covers all times :)
[22:46] <mrooney> there is a mode that just allows +v's to set topic, isn't there
[22:47] <mrooney> is everyone +v? if not that might be easier to manage or something
[22:47] <bdmurray> It's a bit depressing that 2 people can cover 24 hours
[22:47] <persia> Quite possibly.  My IRC-fu isn't up to knowing which though.
[22:47] <sn9> there is +t
[22:47] <persia> bdmurray: True, but :)
[22:47] <persia> sn9: +t lets anyone change, no?
[22:47] <sn9> persia: no, only ops
[22:48] <sn9> -t is anyone
[22:48] <persia> sn9: Oh, right.  That's what we have now, which means mrooney can't keep us updated when the bot has issues, etc.
[22:48] <bdmurray> I could op him in the channel though right?
[22:48] <sn9> yes
[22:48] <bdmurray> That seems like a better solution then
[22:49] <mrooney> if I am identified (which I am) does that persist?
[22:49] <persia> bdmurray: Better to tell chanserv to authorise him, but I think that's supposed to involve notification to IRCC of a new operator for the channel, and there's some expectation of certain behaviour.
[22:49] <hggdh> bdmurray, question re. harvest-data
[22:49] <mrooney> bdmurray: thanks!
[22:49] <persia> mrooney: It persists if chanserv will op you.  It doesn't persist if you're given operator status directly.
[22:49] <bdmurray> persia: really?
[22:50] <persia> bdmurray: Sure.  Modes clear on disconnect.  Without registering with services, one can't maintain them.  While nickserv can handle the identification, and pass the credentials to chanserv, that's not because the modes persist.
[22:51] <mrooney> bdmurray: by the way, another neat use of eeebotu callbacks would be registering them for metabugs and announcing here, if we could determine enough info from incoming titles to classify
[22:51] <sn9> not just disconnect, but /part also
[22:51] <bdmurray> persia: I meant the bit about IRCC
[22:51] <persia> sn9: Right.
[22:51] <bdmurray> hggdh: shoot
[22:51] <persia> bdmurray: From my understanding, all IRC ops are beholden to IRCC for their actions on Ubuntu channels.
[22:52] <mrooney> persia: well it was ChanServ who oped me, if that means anything
[22:52] <persia> I presume there's some activity that takes place.  I have op on one channel (or maybe two), but I remember being introduced the day I was given that.
[22:52] <persia> mrooney: That will persist.
[22:52] <sn9> but only after identify
[22:52] <persia> Or, rather, it won't persist, but you can ask chanserv to op you whenever you need it.
[22:53] <persia> (yes, as long as you're identified)
[22:57] <hggdh> bdmurray, when I mark one entry 'reviewed', sometimes it takes, sometimes it does not. Any reason
[22:57] <hggdh> ?
[22:57] <persia> hggdh: harvest interface, or harvest-data ?
[22:57] <bdmurray> hggdh: that sounds like a harvest issue, I'm really only familiar with harvest-data
[22:58] <hggdh> persia, I am on http://daniel.holba.ch/harvest/handler.py. I would guess this is -data
[22:58] <persia> No, that's harvest itself.  -data is just the CSV input lists.
[22:59] <hggdh> hah
[22:59] <persia> Which opportunity are you reviewing?
[22:59] <hggdh> evolution
[23:00] <hggdh> I just marked 106103 and 94766 as reviewed, and they still show up in the list. On the other hand, I also marked 82227 as reviewed, and it went to the right place
[23:04] <persia> hggdh: Maybe because 1-6103 and 94766 are dups of something?  I suspect this is two bugs: one in harvest-data that it oughtn't pull dupes, and one in harvest that it ought handle those well.
[23:05] <persia> hggdh: Also, you marked 82227 reviewed.  Why?
[23:05] <hggdh> persia, they are dups, and so where others I reviewed. If I understand the thingy correctly, this was expected (dups are whown)
[23:06] <hggdh> persia, because it is a dup of 66880
[23:06] <persia> Oh.  I missed that.  Right.
[23:07] <persia> bdmurray: Is the "Fixed upstream" list one of yours?
[23:07] <hggdh> and I just noticed, it also happens to be one of mine ;-)
[23:07] <bdmurray> persia: I believe so
[23:07] <persia> hggdh: Pure coincidence.
[23:08] <hggdh> yes indeed. Time to play the lotto, anyways
[23:08] <persia> bdmurray: Would you like a bug to disclude dupes, or is that trivial?
[23:08] <hggdh> persia, I think dupes should be in
[23:08] <hggdh> better safe than sorry
[23:08] <bdmurray> Yeah, that was a design decision to include them
[23:08] <persia> hggdh: Why?  It's the same opportunity.  Having the dupes just gives the reviewers more work.
[23:08] <persia> bdmurray: Why?
[23:09] <hggdh> because sometimes dupes are incorrect
[23:09] <bdmurray> because bug watches are not inherited by the master bug report so a duplicate could have a bug watch that is fixed upstream and the master not have one
[23:09] <hggdh> and this gives us a chance of reviewing it
[23:09] <persia> OK.  I'd like to think we handle that somewhere better than harvest, but...
[23:10] <persia> bdmurray: That makes sense.  Is there already an LP bug about failure to inherit upstream links?
[23:10] <hggdh> and there's what bdmurray stated -- all my dupes on Evo had an upstream link
[23:11] <bdmurray> persia: I don't know of an LP bug about that
[23:13] <bdmurray> I'm actually headed out shortly but if you happen to find or submit one I'd like to be subscribed to it.
[23:16] <persia> bdmurray: I'm unlikely to search today, but I'd also like to be subscribed if someone else does.  Otherwise, I'll take a look another day.
[23:23] <bdmurray> I've reported that as bug 247737 but it could probably use an example bug
[23:23] <bdmurray> persia: you are subscribed to it now
[23:24] <persia> bdmurray: You are quick.  Let's hope someone dupes it :)
[23:24] <bdmurray> Well, I looked around too and did not see one that matched it.