12:02:16 <Stskeeps> #startmeeting Mer bug triage 12/3/2012
12:02:16 <MerBot> Meeting started Mon Mar 12 12:02:16 2012 UTC.  The chair is Stskeeps. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
12:02:16 <MerBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:02:36 * phaeron lurks
12:03:03 <Stskeeps> welcome to another week's bug triage
12:03:12 <Stskeeps> the bugs we'll walk through today are https://bugs.merproject.org/buglist.cgi?emailassigned_to1=1&query_format=advanced&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=trivial&bug_severity=enhancement&bug_status=NEEDINFO&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=TRIAGEDUPSTREAM&bug_status=REOPENED&email1=need-triage&emailtype1=substring
12:03:48 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=214 - Bug 214 - Connman crashing
12:03:50 <lbt> &order=bug_id
12:04:00 <Stskeeps> that too
12:04:14 <Stskeeps> i think we need a NEEDINFO on some kind of backtrace
12:04:23 <Stskeeps> it's obviously a problem if connman crashes, it really shouldn't
12:05:27 <Stskeeps> anyone with a nemo device who can try to replicate it?
12:05:43 <lbt> do we have a link on getting backtraces ?
12:06:03 <Stskeeps> Sage_: did we ever make a debug page?
12:06:44 <Sage_> yes
12:06:55 <Sage_> http://wiki.merproject.org/wiki/Debugging
12:07:32 <lbt> normal or high ?
12:07:48 <Stskeeps> i think we can't triage it yet as there's simply not enough info
12:08:02 <Sage_> FYI there is new connman available http://git.kernel.org/?p=network/connman/connman.git;a=blobdiff;f=ChangeLog;h=f7a6cacb50e7c6b53e59b685818072bf5fa77b81;hp=2b35dd140107fca99d5d45b71cef21753fb6a89e;hb=442b1fe603e005814f592a3dbcf0d0bfb13f961c;hpb=04cac51a36804f9d1327351144014501e528f824
12:08:34 <Stskeeps> no fixes?
12:08:49 <Stskeeps> either way, we should get that in
12:08:52 <Sage_> I guess they just haven't mentioned those
12:09:23 <Stskeeps> ok
12:09:40 <Stskeeps> NEEDINFO, stay in need-triage state, may need testing with new connman?
12:10:11 <Stskeeps> need backtrace
12:10:34 <lbt> all done
12:10:40 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=213 - zypper search doen't find packages based on patterns in the sdk - zypper
12:11:01 <Stskeeps> do we know what breaks this stuff?
12:11:14 <lbt> isn't this a dupe?
12:11:19 <Stskeeps> good question
12:11:22 <Stskeeps> dupe of ?
12:11:43 <Sage_> yes, duplicate
12:11:52 <Stskeeps> yes, but .. what id :)
12:12:11 <Sage_> o_0
12:12:20 <lbt> 76
12:12:32 <lbt> "Currently our zypper is not functioning properly"
12:12:54 <Stskeeps> that's rather a dep
12:13:00 <Stskeeps> and 213 is a symptom
12:13:02 <lbt> well yeah
12:13:08 <Sage_> :nod:
12:13:14 <Sage_> we don't have search bug
12:13:36 <lbt> agreed
12:13:46 <Stskeeps> medium, quite annoying, but it weirds me out that zypper install foo* works fine
12:15:10 <lbt> done
12:15:51 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=215 - Should 'build' be in core - and if it should, it's old
12:16:02 <Stskeeps> i think it has to be in 'build' for mkbaselibs support, if i remember correctly
12:16:06 <Stskeeps> in core, that is
12:16:51 <Stskeeps> it should be updated for sure
12:16:53 <Stskeeps> task?
12:17:28 <lbt> yes, medium?
12:17:33 <Stskeeps> :nod:
12:17:42 <Stskeeps> atm we have two builds, one in tools and one in core
12:17:43 <lbt> not sure why it's needed in core
12:17:45 <Stskeeps> that's not good
12:17:52 <Stskeeps> it's needed because of the baselibs configuration
12:18:04 <Stskeeps> and delta rpms
12:18:54 <lbt> is that a bug?
12:19:19 <Stskeeps> i wouldn't call it that.. maybe intentional feature
12:19:47 <lbt> so build in Tools should be removed
12:19:53 <Stskeeps> right, and provided in core
12:20:50 <lbt> FYI we may need to provide build in some Tools area for non-Mer
12:21:10 <Stskeeps> point
12:21:14 <Sage_> isn't it enough if we provide SDK?
12:21:24 <lbt> obs worker
12:21:45 <Sage_> ah, that kind of thing ok
12:21:48 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=216 - Pulseaudio mutex issue on dual core ARM devices
12:22:01 <Stskeeps> normal, we might need to move to a upstream pulseaudio soon-ish
12:22:05 * Sage_ runs
12:22:07 <Stskeeps> may disappear with eglibc 2.15 too
12:22:33 <Sage_> but yes, we should move to upstream pulseaudio
12:22:53 <Stskeeps> we should do a ABI test on libpulse for nemo's sake
12:23:35 <Sage_> there isn't much we can do for the proprietary lib if it fails
12:23:36 <Stskeeps> to see if we can avoid regressing there, it always helps to have a phone-capable device as demonstrator
12:23:41 <Stskeeps> yeah, i know
12:24:11 <Stskeeps> i'm just happy we're registering the PA mutex issue
12:24:21 <vgrade> there was a patch mentioned
12:24:26 <Stskeeps> yeah / workaround
12:24:32 <Stskeeps> priority inherited mutex should really work on arm
12:25:06 <vgrade> I'll check eglibc next time im on tegra
12:25:07 <Stskeeps> k
12:25:25 <Stskeeps> i'm planning eglibc for the release after the next, fwiw
12:25:34 <Stskeeps> to bring us up to date
12:26:32 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=218 - "mic chroot" fails to enter target
12:26:40 <Stskeeps> pirut ran into this yesterday and i could replicate
12:26:48 * lbt skips over 217
12:27:04 <Stskeeps> urgh
12:27:11 <Stskeeps> let's take 217 afterwards :)
12:27:30 <Stskeeps> Sage_: saw this before? it seems a bit awkward it searches after kernel modules
12:29:23 <Sage_> hmmp
12:29:33 <Stskeeps> this is under sdk, fwiw
12:30:08 <Sage_> I recall trying the mic chroot once some time ago and it failed
12:30:11 <Sage_> can't recall the reason though
12:30:23 <Stskeeps> ok, one you can take on perhaps?
12:30:30 <Stskeeps> it's a fairly normal thing to use
12:30:32 <Stskeeps> for arm
12:30:36 <Stskeeps> not sure if x86 does same
12:30:58 <Sage_> I can check that probably if it doesn't have high prio (ie., not this week)
12:31:04 <Stskeeps> :nod:
12:31:07 <Stskeeps> low/normal
12:31:17 <Stskeeps> we'll have sb2 too anyway, so that helps
12:32:39 <lbt> OK, normal and -> SDK
12:33:00 <lbt> Sage_: assign to you ?
12:33:09 <lbt> or not-taken?
12:33:12 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=217 - Need to document how user can rebase the changeset properly
12:33:18 <Sage_> lbt: me
12:33:58 <Stskeeps> low-normal, we hit it for first time yesterday for first time in project history?
12:34:02 <Sage_> faced this during the weekend when rebasing package. Managed to duplicate the request and still fail on rebase :)
12:34:15 <Sage_> Stskeeps: second time actually but still quite rare
12:34:28 <Stskeeps> ok
12:34:39 <Sage_> first time I just rm'd everything :P
12:35:39 <Stskeeps> low then
12:36:45 <lbt> I'll add it as a use case with new pkging  too
12:37:16 <Stskeeps> k
12:37:43 <Stskeeps> that was all bugs -- take a peek at https://bugs.merproject.org/buglist.cgi?query_format=advanced&emailassigned_to1=1&order=Importance&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=trivial&bug_severity=enhancement&bug_status=NEEDINFO&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=TRIAGEDUPSTREAM&bug_status=REOPENED&email1=not-taken&columnlist=bug_severity%2Cpriority%2Cop_sys%2Ca ...
12:37:49 <Stskeeps> ... ssigned_to%2Cbug_status%2Cresolution%2Cshort_desc&emailtype1=substring (not sure if it sorts by importance for you)
12:37:49 <lbt> nb gerrit-patchset-created is wrong
12:37:52 <Stskeeps> $@%
12:38:02 <Stskeeps> https://bugs.merproject.org/buglist.cgi?query_format=advanced&emailassigned_to1=1&order=Importance&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=trivial&bug_severity=enhancement&bug_status=NEEDINFO&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=TRIAGEDUPSTREAM&bug_status=REOPENED&email1=not-taken&columnlist=bug_severity%2Cpriority%2Cop_sys%2Cassigned_to%2Cbug_status%2Cresolution ...
12:38:08 <Stskeeps> ... %2Cshort_desc&emailtype1=substring (not sure if it sorts by importance for you)
12:38:11 <lbt> missed 212 I think
12:38:11 <Stskeeps> ok
12:38:13 <Stskeeps> ircfail
12:38:25 <Stskeeps> you're right
12:38:34 <Stskeeps> #topic Bug 212 - Provision of Source Code for a particular release - https://bugs.merproject.org/show_bug.cgi?id=212
12:38:43 <Stskeeps> task, should be easier now that we have tags for releases
12:39:13 <lbt> ah, assignee reset on component change :)
12:39:41 <lbt> I think this is low for now
12:39:47 <Stskeeps> ok
12:40:09 <lbt> Agree it needs to be done - happy for a vendor to contribute a solution
12:40:26 <Stskeeps> should be easy tbh
12:40:51 <Stskeeps> check out core with a certain tag, browse through packages.xml, check out specific git repo sha's
12:41:15 <lbt> note that the vendor should be running their own MDS
12:41:17 <Stskeeps> publish
12:41:34 <Stskeeps> of course
12:41:47 <lbt> and we have things like the override issue coming from Nomovok
12:41:58 <lbt> where they don't ship Mer code
12:42:03 <Stskeeps> :nod:
12:42:07 <lbt> so that's the kind of thing to watch out for
12:42:14 <Stskeeps> still, tools to aid compliance is good
12:42:52 <Stskeeps> i think they actually list that as a yocto feature, if i remember correcly
12:43:08 <lbt> I was thinking something along those lines
12:43:23 <lbt> "why override Mer the Mer way"
12:43:43 <Stskeeps> i meant license compliance
12:43:52 <lbt> yes
12:44:16 <lbt> doing the override of any code in a consistent manner means you won't accidentally screw up publishing code
12:44:20 <Stskeeps> mm
12:44:34 <lbt> I think we agree :)
12:46:52 <Stskeeps> anyway, weekly sanity check: http://bit.ly/A9NR4s
12:46:53 <Stskeeps> looks sane?
12:48:35 <lbt> 159 .. osc vc... normal as we start to use the SDK now
12:48:43 <Stskeeps> ok
12:50:15 <lbt> there was another CONFIG_ one somewhere ...
12:51:04 <lbt> CONFIG_INPUT_EVDEV from vgrade
12:51:09 <Stskeeps> right
12:52:02 <Stskeeps> not strictly needed but very useful
12:53:11 <lbt> #73 ?
12:53:42 <lbt> ah, thought it was high and languishing
12:53:42 <Stskeeps> not sure if fixed or not
12:54:41 <Stskeeps> alright, think that's it for today
12:54:43 <Stskeeps> thank you all for coming
12:54:50 <lbt> shall I NEEDINFO 76
12:54:53 <lbt> 73
12:55:00 <Sage_> cya
12:55:03 <Stskeeps> if it still happens i guess
12:55:29 <lbt> done - ty all
12:55:34 <Stskeeps> #endmeeting