[00:08] <Linux000> This is my first triage, so could someone make sure bug 534582 is a wishlist item?
[00:08] <ubot4> Launchpad bug 534582 in light-themes (Ubuntu) "background looks weird on vertical panels (affects: 1)" [Undecided,New] https://launchpad.net/bugs/534582
[00:25] <crimsun> plars: in Lucid, please export LIBASOUND_DEBUG as a non-empty value and try again
[00:26] <crimsun> plars: alternately, ltrace
[00:26] <bdrung_> Linux000: i wouldn't consider it as withlist item. it's a bug and not a feature request.
[00:26] <Linux000> Thanks, so what would it be?
[00:27] <Linux000> Sorry, misread your post
[00:29] <Linux000> Could someone set bug 534582 to Importance low, I can't seem to.
[00:29] <ubot4> Launchpad bug 534582 in light-themes (Ubuntu) "background looks weird on vertical panels (affects: 2)" [Undecided,Confirmed] https://launchpad.net/bugs/534582
[00:29] <plars> crimsun: exporting LIBASOUND_DEBUG=y and playing something doesn't give me anything
[00:29] <plars> crimsun: do you want the ltrace on aplay, or paplay?
[00:31] <crimsun> plars: both, please
[00:31] <Linux000> And set bug 534582 to Triaged? Thanks.
[00:31] <ubot4> Launchpad bug 534582 in light-themes (Ubuntu) "background looks weird on vertical panels (affects: 2)" [Undecided,Confirmed] https://launchpad.net/bugs/534582
[00:31] <crimsun> plars: current board is running 1.0.22-0ubuntu6, correct?
[00:32] <Linux000> Never mind the Triaged status on 534582, new here.
[00:32] <plars> crimsun: of which package?
[00:32] <crimsun> plars: libasound2
[00:33] <plars> crimsun: yes
[00:33] <plars> crimsun: do you think that's where I should file a bug against for now? then attach the logs?
[00:34] <crimsun> plars: please do, yes.
[00:35] <plars> crimsun: will do that shortly, have an interrupt at the moment
[00:36] <crimsun> np. Thanks.
[03:07] <crimsun> plars: note: aplay expects PCM. It won't play vorbis as you intend.
[03:08] <crimsun> plars: specifically, PCM->wav
[03:08] <plars> crimsun: ah, my mistake.  Still, the rest of it holds true.  I'll retry that part with wav files
[03:09] <crimsun> plars: now, the symptom that you describe in bug 534815 typically points to an incorrect resampling rate configured in pulse
[03:09] <ubot4> Launchpad bug 534815 in alsa-lib (Ubuntu) "imx51 some audio files play, others do not (affects: 1)" [Undecided,New] https://launchpad.net/bugs/534815
[03:10] <plars> crimsun: I have a similar, but opposite bug on another SoC
[03:10] <crimsun> plars: to verify, please see default-sample-rate in /etc/pulse/daemon.conf
[03:11] <plars> ; default-sample-rate = 44100
[03:11] <crimsun> plars: in verbose mode, the pulse daemon will use snd_pcm_dump() to print hw config. Please see https://wiki.ubuntu.com/PulseAudio/Log
[03:12] <crimsun> plars: another more apropos environment variable to test is to export PULSE_NO_SIMD to a non-empty value and forcibly restart the pulse daemon
[03:13] <crimsun> plars: finally, try bypassing pulse entirely by using speaker-test -Dplughw:0 [any additional params]
[03:13] <crimsun> plars: (or, pasuspender -- speaker-test -Dplughw:0 [...])
[03:15]  * persia idly notes that it's common for different hardware solutions to need different sorts of quirks.
[03:31] <plars>  crimsun: ah, yes, with -Dplughw:0 speaker-test -c2 -t wav works (without it, it does not)
[04:00] <crimsun> plars: ok, definitely a pulse bug, then.
[04:01] <crimsun> plars: did PULSE_NO_SIMD=1 help?
[04:02] <plars> crimsun: no, I turned that on when I reproduced it for the verbose log
[04:03] <crimsun> ok, I haven't read the log yet
[04:03] <crimsun> still commuting from work
[04:05] <plars> crimsun: np, thanks for all your help.  About to go to sleep myself
[04:47] <dreamer_> has anyone here got jack+pulse working in lucid
[04:47] <dreamer_> everytime I fire up jack with pulse apps won't start and I get Bus error (core dumped) messages from almost all apps I try to run (even ubuntu-bug)
[07:18] <kermiac> vish: ping re last comment in bug 532633. I'll ask as you have been involved in this bug too. Are you happy for me to go ahead & change the description to focus only on the wm controls?
[07:18] <ubot4> Launchpad bug 532633 in light-themes (Ubuntu) "[light-theme] please centre window title and order window controls (affects: 36) (dups: 6)" [Wishlist,Triaged] https://launchpad.net/bugs/532633
[07:19] <kermiac> vish: the wm controls are the main issue in this bug
[07:19] <vish> kermiac: yeah , sure , i wanted to do it either way.. there are many dups , we can use this for the controls..
[07:20] <vish> only the title needs change
[07:20] <vish> kermiac: thanks for following up
[07:20] <kermiac> you don't think i should remove the reference to the window title from the description? If I change one, I think both should be changed
[07:22] <kermiac> vish: ^^
[07:22] <vish> kermiac: hmm , the title and the controls will probably need to be changed at the same time , we can just leave it alone
[07:22] <kermiac> vish: ok, no probs :) I'll update the title
[07:30] <Anzenketh> That is a lot of bugs
[07:45] <Zus> hello guys
[07:45] <Zus> and gals
[08:54] <BUGabundo_remote> \0
[09:25] <ikt> BUGabundo_remote: \o/
[09:31] <BUGabundo_remote>  /8\ ikt
[09:34] <ikt> BUGabundo_remote:  wut is that?
[10:01] <ikt> https://bugs.launchpad.net/ubuntu/+source/yelp/+bug/529378
[10:01] <ubot4> Launchpad bug 529378 in yelp (Ubuntu) "yelp crashed with signal 5 (affects: 2)" [Medium,Incomplete]
[10:12] <ikt> wow @ vish w/57 days in a row
[10:14] <ikt> 57 weeks?
[10:19] <vish> ikt: 57 weeks is 1 yr ;)
[10:19] <vish> more than*
[10:20] <ikt> that would be quite insane
[10:20] <ikt> or not really
[10:21] <ikt> so if you can do 5 a day for 5 days in a 7 day week, that counts if you say miss out on 2 days?
[10:22] <vish> ikt: hm.. i havent done 57 weeks  , but yeah , 5 in 7 days counts
[10:24] <ikt> ah sweet
[12:57] <ttx> pedro_: hey, thanks for the samba bugday announcement. Unfortunately I have an emergency on Wednesday (European) morning so I won't be able to kick off early
[13:00] <pedro_> ttx, hola, no worries!, thanks for let us know ;-)
[13:01] <pedro_> ttx, we can always wait a little bit for the other folks on the server team to ask questions if we have any
[13:01] <ttx> pedro_: ack
[13:02] <chrigi> hi! i'm new here and i've got a question regarding the ubuntu bugfixing process. is this the right place for such a question?
[13:04] <pedro_> chrigi, better to ask at the #ubuntu-motu channel
[13:04] <persia> We can try.
[13:04] <pedro_> oh well persia is here ;-)
[13:04] <persia> pedro_: Why?
[13:05]  * persia thinks bugsquad is probably subscribed to more bugs than MOTU :)
[13:07] <pedro_> cause they might know better about the bug fixing process from the developer point of view ;-)
[13:09] <chrigi> Well some time ago I had this problem that my keyboard went dead after I resumed from suspend. I found several bugreports on launchpad on it. Further I found that the problem was already fixed in the head of the upstream repository. now my question is: how will the bug find it's way from the upstream github to the ubuntu repos? And what to do with the bugreport?
[13:09] <chrigi> Sorry for the n00b question ;)
[13:11] <yofel> waah, there I'm busy for 2 weeks only to come back and find out we have the meeting, kernel bug day and 2 hug days the same week o.O, busy...
[13:12] <yofel> chrigi: usually the bug get's fixed in the development  release once a new upstream release gets into lucid containing the fix
[13:13] <yofel> chrigi: to fix bugs in released versions of ubuntu you have to follow https://wiki.ubuntu.com/StableReleaseUpdates
[13:15] <yofel> chrigi: btw, you mentioned a bug report, which bug?
[13:15] <chrigi> yofel: thanks! well I think it's not major enough for a StableReleaseUpdate, but is there some place I can see what development release of the package will make it into lucid?
[13:16] <chrigi> yofel: it's the following bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/437862
[13:16] <ubot4> Launchpad bug 437862 in xserver-xorg-input-evdev (Ubuntu) "device key_bitmask has changed (affects: 19) (dups: 3)" [Medium,Triaged]
[13:16] <yofel> ah, X...
[13:17] <yofel> !info xserver-xorg-input-evdev lucid
[13:17] <ubot4> yofel: xserver-xorg-input-evdev (source: xserver-xorg-input-evdev): X.Org X server -- evdev input driver. In component main, is optional. Version 1:2.3.2-3ubuntu1 (lucid), package size 80 kB, installed size 204 kB
[13:17] <yofel> chrigi: that's the version we have right now
[13:17] <yofel> chrigi: for more details you'll probably get better help in #ubuntu-x
[13:18] <chrigi> yofel: 2.3.2 is perfect, where did you get this info?
[13:19] <yofel> chrigi: look at the last line I posted before ubot4 posted the information, also you can query the bot in private with '/msg ubot4 info <pkg> lucid'
[13:20] <chrigi> and what to do with the bug report? just leave it as "triaged" or change it to fix released (as it is already fixed in upstream)?
[13:20] <chrigi> yofel: thanks!
[13:21] <yofel> chrigi: also useful is the 'rmadison' command that's part of the devscripts package
[13:21] <yofel> actually  I find most of the 'ubuntu-dev-tools' package useful
[13:24] <chrigi> !info xserver-xorg-input-evdev lucid
[13:24] <ubot4> chrigi: xserver-xorg-input-evdev (source: xserver-xorg-input-evdev): X.Org X server -- evdev input driver. In component main, is optional. Version 1:2.3.2-3ubuntu1 (lucid), package size 80 kB, installed size 204 kB
[14:08] <zeroseven0183> Hi! Am I right in saying that the meeting will start in two hours?
[14:09] <zeroseven0183> I'm living in the Southeast Asia and it's already 10PM in the evening here. I won't be able to attend the meeting if my timing is correct.
[14:14] <yofel> zeroseven0183: yes, in 2 hours
[14:19] <persia> zeroseven0183: I have a similar issue in my timezone.  If I have something I want to raise, I usually ask someone else to raise it for me, and review the logs later.
[14:19] <persia> zeroseven0183: logs can always be found at irclogs.ubuntu.com
[14:20] <persia> (or if they are missing, complain, because they *should* be there)
[14:23] <zeroseven0183> Thanks for the suggestion persia. I guess I have to checkout the logs after
[14:24] <zeroseven0183> I wanted to familiarize myself with the terminologies the BugSquad is using
[14:24] <zeroseven0183> So I can easily triage bugs
[14:24] <zeroseven0183> and better help this team
[14:24] <persia> zeroseven0183: Best way to do that is to check the wiki pages in the /topic
[14:25] <zeroseven0183> Yup. Actually, it helps me a lot.
[14:25] <persia> zeroseven0183: Or just ask: there's lots of us in Asia, and a healthy overlap with early-rising Europeans, and late-sleeping Americans.
[14:26] <persia> (for the purposes of the above, the antipodes are "Asia": apologies for overgeneralisation.  Africans aren't mentioned only because I don't see many early-rising ones around often)
[14:30] <BUGabundo_remote> seb128: I'm experiencing similar lag as the fixed GTK bug we had a few weeks ago :(
[14:31] <seb128> BUGabundo_remote, ok, dunno where from since we dropped this gtk patch a week ago in lucid
[14:32] <BUGabundo_remote> I'll test with gtkperf once I get home
[14:32] <BUGabundo_remote> it just started feeling like that right after this last batch of updates
[14:32] <BUGabundo_remote> The following packages will be upgraded:
[14:32] <BUGabundo_remote>   cheese cheese-common f-spot firefox firefox-branding firefox-gnome-support gdm gnome-settings-daemon gstreamer0.10-plugins-good gstreamer0.10-pulseaudio libcheese-gtk18   libgnomekbd-common libgnomekbd4 libgweather-common libgweather1 linux linux-generic linux-headers-generic linux-image linux-image-generic tomboy xulrunner-1.9.1   xulrunner-1.9.1-gnome-support
[14:33] <BUGabundo_remote> but I don't see anything even closelly related
[15:59] <bdmurray> Today is meeting day right?
[15:59] <yofel> if everybody remembered yes
[15:59] <bdmurray> I remembered ;-)
[15:59] <yofel> me too :P
[16:00] <yofel> hm, hggdh is here, qense and micahg aren't :/
[16:00] <mrand> As usual, I'll be in and out.
[16:01] <pedro_> is there any agenda item?
[16:01] <bdmurray> There are some additional topics we haven't discussed
[16:04] <bdmurray> I guess the only topic with an attendee is hggdh's
[16:04] <bdmurray> hggdh: ?
[16:05] <BUGabundo_remote> foo
[16:08] <hggdh> here, sorry
[16:08] <yofel> maybe we should send out a metting reminder to the ML a day before ^^
[16:08] <bdmurray> no problem
[16:08] <yofel> *meeting
[16:08] <bdmurray> yofel: yeah, that'd be good ;-)
[16:09] <mrand> Should probably be a way to do that automatically so someone doesn't have remember to send it out ;-)
[16:10] <hggdh> so. Are we going to talk about the pending nominations?
[16:10] <bdmurray> hggdh: yes, sounds good
[16:10] <BlackZ> hi all
[16:11] <hggdh> Laibsch started to review pending nominations, and asked what is the procedure there. This is a rather vague process right now
[16:12] <bdmurray> If its vague its because the nomination workflow is incomplete or lacking in Launchpad
[16:13] <bdmurray> One issue is that any bug can be nominated for a release - it doesn't need to be confirmed or triaged or anything
[16:13] <bdmurray> That might be handled socially if we were to educate people about when to nominate
[16:13] <hggdh> yes indeed. I would rather have social controls than programatic ones
[16:14] <bdmurray> However, another issue is that its not possible to renominate a bug for a release so if you decline a nomination people don't have much recourse
[16:14] <hggdh> which, then, makes it difficult to work on them...
[16:15] <hggdh> coiuld we have package owners/bug-control able to re-nominate?
[16:16] <hggdh> (which would mean a LP bug to be opened, of course)
[16:16] <bdmurray> well, package uploaders can target disapproved nominations for release but there is no way for them to get back in the queue
[16:16] <hggdh> but this is an individual action, bypassing the rejected nomination
[16:16] <bdmurray> so let's pretend we have a new / incomplete bug nominated for lucid
[16:17] <bdmurray> it then gets declined / rejected ... how will it be renominated?
[16:17] <bdmurray> should the decliner subscribe to the bug in the off chance it becomes complete?
[16:18] <hggdh> hum
[16:18] <bdmurray> Maybe there is some workaround we could use with tags?
[16:19] <thekorn> sorry, but I'm missing something: how are nominations used in the development comunity? is the current use of nominations described somewhere?
[16:19] <hggdh> perhaps by -- instead of officially declining it -- by tagging "declined"?
[16:19] <bdmurray> hggdh: right and telling people to remove it if the bug is squared away
[16:19] <nigelb> thekorn: nominations are used for SRU I think
[16:20] <hggdh> but the flow is quite undocumented
[16:20] <thekorn> release management is also using it, right?
[16:20] <bdmurray> thekorn: https://wiki.ubuntu.com/RCBugTargetting
[16:21] <bdmurray> 'To indicate that a bug should be fixed prior to the final release, the bug should be nominated using the "nominate for release" option in Launchpad'
[16:21] <hggdh> bdmurray: who has final decision power on nominations?
[16:21] <charlie-tca> Then why can you nominate for any release instead of just the development release?
[16:21] <bdmurray> hggdh: generally uploaders of the packages
[16:21] <pedro_> charlie-tca, because of the SRU
[16:22] <thekorn> ok, cool. Related question: who can set nomination in ubuntu?
[16:22] <bdmurray> thekorn: anybody
[16:22] <charlie-tca> anyone
[16:23] <thekorn> I think I never used it ;)
[16:23] <bdmurray> hggdh: so using tags for declining would allow more people to participate in the workflow
[16:23] <bdmurray> which would be good I think
[16:23] <hggdh> I agree
[16:24] <hggdh> and it is something we can do without changes to LP
[16:25] <hggdh> I guess we could do with just one tag -- to signal it is being declined. Absence of the tag would mean it is game for nominations
[16:26] <bdmurray> hggdh: yes and then query for nominations without the "declined" tag
[16:26] <charlie-tca> The problem is the bug could be nominated for 5 releases, then declined for one only
[16:26] <pedro_> declined-release , right?
[16:26] <bdmurray> pedro_: yep
[16:26] <bdmurray> and maybe even nomination-declined-lucid
[16:27] <pedro_> sounds better to me
[16:27] <bdmurray> to avoid confusion with declining other things that I don't have an example of ;-)
[16:27] <charlie-tca> As in a bug nominated for lucid, karmic, hardy, dapper
[16:29] <bdmurray> charlie-tca: I think that's covered right?
[16:29] <charlie-tca> As long it is a release specific tag
[16:30] <hggdh> and I like the hierarchical naming
[16:30] <charlie-tca> nominating is a favorite for spammers. Once they do it, you have to decline all of them, and the bug can never be nominated again at a later date
[16:31] <hggdh> yes. This is why we are considering tagging instead of officially declining them
[16:31] <thekorn> does anyone know if the procedure described in https://wiki.ubuntu.com/RCBugTargetting "untargeting bugs" ever worked?
[16:32] <bdmurray> thekorn: I think it does
[16:32] <hggdh> but it gets to be more work than tagging, I think
[16:32] <bdmurray> thekorn: they are talking about if a bug is targetted to lucid, then it doesn't have a current release tag if you won't fix the lucid task a "current" one gets added
[16:32] <bdmurray> current release task not tag
[16:33] <thekorn> hmm, maybe I'm just too confused ;)
[16:33] <thekorn> sorry
[16:33] <bdmurray> https://bugs.staging.launchpad.net/ubuntu/+source/debian-installer/+bug/229699
[16:33] <ubot4> Launchpad bug 229699 in debian-installer (Ubuntu) ""setting locale failed" if using other keyboard layout then language (affects: 1) (dups: 1)" [Undecided,Confirmed]
[16:34] <bdmurray> there is an example I just made
[16:34] <bdmurray> on staging
[16:34] <bdmurray> so I think if you won't fix the lucid task a new one will appear
[16:34] <bdmurray> It doesn't really help with the work flow we are discussing as this one's nomination was already approved
[16:35] <bdmurray> hggdh: So I think we should discuss this with the release team / slangasek
[16:35] <hggdh> I agree.
[16:35] <thekorn> no, it did not work, but yeah it's not relevant to our discussion
[16:36] <bdmurray> In the mean time an announcement about when to nominate a bug would still be a good idea though
[16:36] <hggdh> and a wiki update?
[16:37] <bdmurray> thekorn: I think it did work as there is now a confirmed task
[16:37] <bdmurray> hggdh: maybe I was thinking mailing list / blog
[16:38] <thekorn> bdmurray, sorry, you are right
[16:40] <hggdh> bdmurray: probably the wiki should wait for after the discussion with slangasek
[16:40] <bdmurray> hggdh: right, I was just thinking saying don't nominated bugs unless they are confirmed
[16:40] <hggdh> bdmurray: +1
[16:42] <bdmurray> okay anything else about release nominations?
[16:42] <hggdh> not from me
[16:42] <thekorn> no
[16:42] <pedro_> nope
[16:43] <bdmurray> And any other agenda items to discuss?
[16:44] <yofel> how about backporting apport?
[16:44] <yofel> micahg: ping
[16:44] <micahg> yofel: pong
[16:44] <hggdh> micahg: can you expand on backporting apport?
[16:45] <micahg> hggdh: well, where possible add new feature/hooks that are useful in older releases
[16:46] <nigelb> micahg: basically backporting hooks to older releases?
[16:46] <bdmurray> apport depends on python-launchpadlib so that would likely get tricky
[16:46] <hggdh> is it a large dependency tree?
[16:47] <bdmurray> have a package that was a collection of backported package hooks would be neat
[16:47] <bdmurray> however, those might also depend on a newer version of apport if they call a general hook
[16:48] <sbeattie> you'd also want to be sure that the reason the package hook is different in the newer release is not because something in the package configuration (e.g. different logfile layout, etc.)
[16:48] <micahg> bdmurray: how about where possible?
[16:48] <hggdh> which releases would we target (if we get to do it)?
[16:48] <micahg> hggdh: LTSs
[16:48] <micahg> at least
[16:49] <bdmurray> micahg: I think its a neat idea and interesting but not something I'd work on directly.
[16:49] <micahg> one of the big problems in triaging bugs is trying to get info off of a harsystemdy
[16:49] <bdmurray> maybe it is something we could do for Lucid though
[16:49] <micahg> hardy system
[16:49] <bdmurray> so as new hooks come out in M add them to Lucid
[16:49] <nigelb> I can help with that :)
[16:50] <micahg> could package hooks also be allowed in SRUs
[16:50] <bdmurray> I mean really its Hardy and Lucid is almost here
[16:50] <hggdh> another thing to think on -- as bdmurray said, a package with the hooks, as opposed to hooks in each package
[16:50] <bdmurray> micahg: there is some cost to having an SRU just for a package hook - downloading the whole thing etc...
[16:51] <micahg> hggdh: that package would probably get updated frequently
[16:51] <micahg> bdmurray: maybe included with some other fix?
[16:51] <hggdh> yes, it will, but better than -- for example -- rebuild Evolution for a hook
[16:51] <bdmurray> micahg: right better one small package than all of X / firefox
[16:52] <hggdh> and all other large packages...
[16:52] <micahg> bdmurray: k, sounds good, but who maintains it?
[16:52] <bdmurray> ubuntu-bugcontrol in backports?
[16:53] <micahg> bdmurray: well, wouldn
[16:53] <micahg> t' that mean that it can't be shipped with the release?
[16:53] <micahg> and not everyone uses -backports
[16:54] <bdmurray> so an optional package in universe with updated version of the package hooks for apport
[16:54] <micahg> bdmurray: I'd say we need to discuss this on the -devel list
[16:55] <bdmurray> micahg: okay, could you start the discussion?
[16:55] <micahg> bdmurray: sure
[16:56] <micahg> but the problem with bugsquad maintaining the hooks is a lack of the package knowledge
[16:56] <micahg> I think that's one of the reasons there are hooks in the package
[16:57] <hggdh> this would not change
[16:57] <hggdh> it is just the target package that would change
[16:57] <bdmurray> micahg: I'm not following I think it would be as simple as watch the archive for new package hook.  Put package hook in meta-package.
[16:57] <micahg> hggdh: you can;t have two packages offering the same file
[16:58] <hggdh> no, you cannot. This is another thing to discuss with -devel. I frankly do not like having the hooks on each package
[16:58] <bdmurray> hggdh: it makes it so universe devels can add a hook to their one package without waiting on apport
[16:58] <micahg> hggdh: yes, but as I said it's usually the package maintainers that best know what should be in the hook
[16:58] <bdmurray> s/one/own/
[16:59] <hggdh> bdmurray: the universe devels could just forward the branch
[16:59] <hggdh> micahg: so could the maintainers
[16:59] <bdmurray> hggdh: still it becomes a bottleneck
[16:59] <micahg> hggdh: as it is, we;re short on core-devs
[16:59] <hggdh> more than now?
[17:00] <micahg> hggdh: exhibit A is the main sponsors queue :)
[17:00] <hggdh> LOL. The DA rests ;-)
[17:01] <micahg> it would be nice to be able to at least authorize in SRU inclusion an updated hook
[17:01] <micahg> and any apport features that aren't py-lplib specific
[17:01] <hggdh> obviously, this would require a lot of talking. But I still think it simpler to change a small package (with a low cost to build) than a whole complex one
[17:02] <bdmurray> and maybe we could stick them in /usr/share/apport/package-hooks/backported/
[17:02] <micahg> bdmurray: that's an idea...
[17:02] <hggdh> good idea, makes it more resistant to other unintentional consequences
[17:03] <micahg> then those can be in a single package :)
[17:03] <hggdh> defence rests...
[17:03] <hggdh> defense
[17:03] <micahg> still needs to be discussed on -devel list but this has a chance of being awarded by the jury :)
[17:03] <hggdh> yes
[17:04] <hggdh> next one?
[17:04] <bdmurray> I think that's all we have time for
[17:04] <hggdh> CoC signing requirement?
[17:04] <hggdh> oh, OK
[17:05] <nigel_nb> meeting officially over?
[17:06] <hggdh> nigel_nb: yes, I guess so. Left-over for next meeting
[17:06] <nigel_nb> hggdh: :)
[17:06] <nigel_nb> pedro_: got a min?
[17:07] <pedro_> nigel_nb, yes
[17:07] <nigel_nb> you had confirmed bug 401028, but the original bug was in telepathy-butterfly and the upstream task is also actually in telepathy-butterfly
[17:07] <pedro_> no bot?
[17:07] <ubot4> Launchpad bug 401028 in pymsn (Ubuntu Karmic) (and 4 other projects) "telepathy-butterfly crashed with TypeError in b64decode() (affects: 416) (dups: 27)" [Undecided,New] https://launchpad.net/bugs/401028
[17:07] <pedro_> ah just slow
[17:08]  * nigel_nb pets ubot4 :)
[17:08] <pedro_> looking nigel_nb
[17:08] <nigel_nb> :)
[17:10] <nigel_nb> bdmurray: any particular requirements to meet to be part of reviewers?
[17:10] <bdmurray> nigel_nb: no, not really
[17:10] <nigel_nb> bdmurray: I had applied, I guess you'll get to it.
[17:10] <bdmurray> nigel_nb: I actually can't add people
[17:11] <nigel_nb> oh
[17:11] <nigel_nb> Persia and I've worked with expanding the tags for review too.  Mailed you the conclusion of what could be a better workflow
[17:11] <bdmurray> I'll try and get that sorted
[17:11] <bdmurray> nigel_nb: right I need to reply to that but I think its overly complicated
[17:12] <nigel_nb> it sounds complicated, but its practical when you want to work on patches
[17:12] <nigel_nb> I was hitting debdiffs a lot of times
[17:13] <nigel_nb> we actually developed that workflow when I was doing patch review, based on each situation that I faced
[17:14] <bdmurray> okay, fine but have 6 or 8 tags seems like a bit much if you want people to participate in the process easily
[17:15] <nigel_nb> the idea is, it helps filter out bugs that area already dealt with
[17:15] <nigel_nb> or need not be reviewed by reviewers
[17:16] <pedro_> nigel_nb, done, I've closed the pymsn task
[17:16] <nigel_nb> pedro_: I would have done it, but I wasn't really sure :)
[17:17] <nigel_nb> pedro_: when I was going through the SRU, I quite confused
[17:17] <pedro_> nigel_nb, is ok, the bug is actually on papyon rather than at pymsn
[17:17] <nigel_nb> its on papyon
[17:18] <nigel_nb> while the pymsn bug may exisit, it is not related to papyon
[17:18] <nigel_nb> pymsn does not depend on papyon( at least as far as I could see)
[17:18] <nigel_nb> now the trouble is, a lot of people who says "Affects me too" may have said it for pymsn :(
[17:21] <pedro_> well i think the quantity of affected users are counted as a whole at the bug reports and not per task
[17:21] <nigel_nb> I know
[17:22] <nigel_nb> This means there might be a bug in pymsn too
[17:22] <nigel_nb> and that might not be fixed yet
[22:41] <hggdh> bdmurray: on it now
[22:43] <hggdh> bdmurray: "... it is possible comment on the branch in a merge ..." I am not sure what you wanted to state here
[22:44] <bdmurray> hggdh: fixed thanks
[22:47] <Hillshum> Bug #417757 is fixed, but people with similar symptoms keep complaining. What should be done?
[22:47] <ubot4> Launchpad bug 417757 in glibc (Fedora) (and 6 other projects) "[karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups (affects: 158) (dups: 17)" [Unknown,Confirmed] https://launchpad.net/bugs/417757
[22:51] <hggdh> bdmurray: some typos corrected. Also, you talk about ubuntu-core-devs and ubuntu-devs (and give examples with both). Are they interchangeable?
[22:51] <bdmurray> hggdh: yes for now
[22:52] <bdmurray> maybe I'll just use one in there
[23:18] <kklimonda> is there a master bug for all reports about missing mouseover tooltip for all applications ported to the appindicator?