12:00:14 <Stskeeps> #startmeeting Mer bug triage 8/2/2012
12:00:14 <MerBot> Meeting started Wed Feb  8 12:00:14 2012 UTC.  The chair is Stskeeps. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
12:00:14 <MerBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:00:44 <Stskeeps> hi, welcome to another week of bug triages for Mer, usually we run these on mondays, but most of us were in Brussels, Belgium for FOSDEM and we kind of forgot :)
12:01:15 <Stskeeps> #topic Not-triaged bugs (not tasks) - 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:01:23 <Stskeeps> #topic Not-triaged bugs (not tasks) - 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:01:33 <Stskeeps> the rather long url is the bugs we'll go through :)
12:01:59 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=151 - Installing IMG on debian6 had some errors - Component: IMG
12:02:25 <Stskeeps> any impact on ability to install?
12:02:28 <Stskeeps> (lbt)
12:02:48 <lbt> it's a problem for other people - not blocking me
12:03:01 <lbt> right now our systems offering is not ready
12:03:05 <lbt> so low IMHO
12:03:07 <Stskeeps> ok, so low
12:03:09 <Stskeeps> any takers?
12:03:23 <Stskeeps> (please indicate with "o/" during the meeting if you want to fix the bug)
12:04:08 <lbt> done
12:04:37 <Stskeeps> ok, moving on to next..
12:05:09 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=159 - osc vc produces a bad changelog format for Mer - Component: OBS
12:05:17 <lbt> "Fix as part of packaging a Mer version of tools for SDK" ?
12:05:21 <Stskeeps> mmm
12:05:23 <Stskeeps> i guess so
12:05:35 <lbt> I say low too
12:05:38 <Stskeeps> what was the versioning thing priority?
12:05:40 <lbt> it's not a blocker
12:05:40 <Stskeeps> it is related to that
12:06:04 <lbt> yes it is ... and I want to have an SDK with Mer git so we can sync all these things
12:06:17 <Stskeeps> ok
12:06:33 <Stskeeps> low then
12:07:12 <Stskeeps> #topic Not triaged tasks: https://bugs.merproject.org/buglist.cgi?emailassigned_to1=1&query_format=advanced&bug_severity=task&bug_status=NEEDINFO&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=TRIAGEDUPSTREAM&bug_status=REOPENED&email1=need-triage&emailtype1=substring
12:08:40 <lbt> I think this is part of the work on ks patterns
12:08:41 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=146 - maybe net-tools should be in base set?  --  .Project
12:09:09 <Stskeeps> yes, though i can sympthatise with it being there
12:09:39 <lbt> me too - for the minimalists we can document it as a possible removal
12:09:49 <Stskeeps> assign over to me i guess
12:09:57 <lbt> I don't think Mer is primarily a super-small rootfs
12:10:18 <lbt> assign or leave as not-taken?
12:10:31 <Stskeeps> assign
12:10:58 <lbt> low?
12:11:06 <Stskeeps> low
12:11:23 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=147 - Use --with-gnu-ld and --with-gnu-as  -- component: gcc
12:11:29 <lbt> minor comment: that means no-one else can work on it and if it's low you may not get round to it for a while
12:11:59 <Stskeeps> i usually try to pick those small ones up at each release
12:12:05 <Stskeeps> not much to do than to add a oneliner
12:12:39 <lbt> *nod* :)
12:12:56 <Stskeeps> it makes sense that we tell GCC that by default it can assume that it has a gnu linker and gnu assembler
12:13:01 <Stskeeps> so medium
12:13:26 <lbt> handled in the prjconf
12:13:31 <Stskeeps> hmm?
12:14:03 <lbt> is this a configure option for gcc
12:14:09 <Stskeeps> yes, configure
12:14:11 <Stskeeps> not optflags
12:14:13 <lbt> or do you want default flags in prjconf
12:14:15 <lbt> OK
12:15:07 <lbt> normal
12:15:09 <Stskeeps> i'm not entirely sure if it is already autodetected at onfigure time
12:15:25 <Stskeeps> so yeah, normal
12:15:45 <lbt> done
12:15:50 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=148 - update rpmlint to version 1.4 - rpmlint
12:16:00 <Stskeeps> makes sense, normal?
12:16:04 <Stskeeps> not blocking anything
12:17:03 <lbt> done
12:17:40 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=153 - Include xrandr to core - .Project
12:17:50 <Stskeeps> this is talking about the xrandr command line util
12:18:01 <Stskeeps> that and xinput is fairly used
12:18:10 <lbt> in production?
12:18:16 <lbt> xinput yes
12:18:28 <lbt> or more in hacking about?
12:18:31 <Stskeeps> xrandr can be used in production too
12:19:02 <lbt> I use it a lot - but I'd expect it to mainly be applied by Qt
12:19:26 <Stskeeps> mm
12:19:31 <Stskeeps> well, Mer Tools at least
12:19:42 <Stskeeps> low prio
12:20:15 <lbt> we actually have the mer-gfx-tests in core
12:20:19 <Stskeeps> yeah, okay
12:20:22 <lbt> so the same criteria apply
12:20:28 <Stskeeps> then i guess normal
12:20:53 <lbt> we may want to add this to a core-hacking pattern
12:21:07 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=154 - Evaluate zif vs zypp   -- .Other
12:21:16 <Stskeeps> low prio, possible replacement for packagekit backend
12:21:19 <Stskeeps> packagekit is a bit heavy
12:22:12 <lbt> done
12:22:25 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=157 - update openssl to version 1.0.0g (note: security fixes)
12:22:28 <Stskeeps> high
12:24:02 <Stskeeps> moving along..
12:24:10 * lbt will add a task - figure out how to track CVEs that apply to Mer
12:24:24 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=158 - https://bugs.merproject.org/show_bug.cgi?id=158 - NFS support on Mer
12:24:31 <Stskeeps> probably in wrong component, should be in project-core instead
12:24:43 <Stskeeps> NFS is very useful for product development
12:24:53 <Stskeeps> due to the fact you don't have to always re-write sd cards
12:25:08 <lbt> so I don't think this should be in core :)
12:25:14 <lbt> I agree it's useful
12:25:20 <Stskeeps> i agree, in mer tools and installable
12:25:21 <lbt> but not for production
12:25:26 <lbt> *nod*
12:25:38 <lbt> I *would* accept smb in core
12:25:45 <lbt> after a debate :)
12:26:01 <lbt> think NAS etc
12:26:05 <Stskeeps> smb isn't useful for this purpose, but ok
12:26:17 <lbt> no, but it is for production
12:26:20 <Stskeeps> 'normal'?
12:26:27 <lbt> yes
12:26:34 <Stskeeps> and we need somewhere that's not project core to host these tasks in
12:27:00 <lbt> Mer integration tools product
12:27:03 <lbt> has tools
12:27:05 <Stskeeps> ok
12:27:10 <Stskeeps> move it to there then
12:27:38 <Stskeeps> okay, let's quickly review open bugs
12:27:46 <Stskeeps> #topic Open bugs for taking
12:27:52 <Stskeeps> #link 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&emailtype1=substring
12:28:10 <lbt> sec
12:28:41 <Stskeeps> any reprioritazation needed there?
12:29:00 <Stskeeps> or any takers for any of the bugs
12:29:08 <vgrade> \o, 143, 132, 142
12:29:39 <Stskeeps> alright
12:30:00 <Stskeeps> i can take 135
12:30:09 <Stskeeps> and 127
12:30:30 <lbt> please do takes yourselves
12:30:40 <lbt> I'll do any other tweaks
12:30:55 <lbt> vgrade: take as you start on them ?
12:31:08 <vgrade> sure
12:31:40 <lbt> I'm talking to phaeron about 145 - obs packaging
12:31:49 <lbt> that's post-SDK for me
12:32:05 <lbt> they may mingle...
12:32:17 <Stskeeps> obs packaging needs to be done before SDK
12:32:26 <Stskeeps> as it blocks mer releases, due to switch to SB2-OBS
12:32:33 <lbt> OK
12:32:35 <Stskeeps> as we can't prerelease and have COBS test it
12:32:54 <lbt> I'll switch them
12:33:35 <lbt> and I'll take it
12:34:10 <Stskeeps> ok, and re-priorization that you see?
12:34:23 <Stskeeps> ie, some stuff that ought to be more important than others
12:34:54 <lbt> 134 maybe
12:35:23 <Sage> o/ I can take 139
12:35:33 <lbt> 73 is important but it seems Nemo driven
12:35:42 <Sage> err
12:35:46 <lbt> so we let our vendor work on it
12:35:46 <Sage> sry, wrong bug again :)
12:36:06 * Sage changed the bug 139 description :)
12:36:56 <Sage> back to nottaken
12:37:04 * lbt wonders how 73 would be handled if it was "Spark segfaults with ofonod"
12:37:30 <Stskeeps> lbt: well, a core component segfault is always bad
12:37:55 <lbt> agreed - it's not a "go away" .. it's a "how do we communicate" question
12:38:00 <Stskeeps> :nod:
12:38:31 <Sage> our ofono is lacking behind _a lot_
12:38:38 <Sage> probably fixed already in upstream
12:38:40 <Stskeeps> okay, let's quickly review tasks, if you want to take on a task, communicate it here and assign it to yourself
12:38:44 <Stskeeps> https://bugs.merproject.org/buglist.cgi?emailassigned_to1=1&query_format=advanced&bug_severity=task&bug_status=NEEDINFO&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=TRIAGEDUPSTREAM&bug_status=REOPENED&email1=not-taken&emailtype1=substring
12:38:50 <Stskeeps> any re-priorizations needed or takers?
12:39:21 <lbt> "Update wiki with new mic installation details" is not high
12:39:30 <lbt> not until we have SDK etc
12:39:32 <Stskeeps> ok
12:39:35 <Stskeeps> normal?
12:39:38 <lbt> yes
12:40:02 <Stskeeps> regarding MER#27, eglibc has the benefit of ARM unwind support as an example
12:40:04 <lbt> do we even *have* new mic in tools?
12:40:06 <Stskeeps> so you can get proper backtraces
12:40:07 <Stskeeps> yes, we do
12:40:17 <Stskeeps> check out platform sdk page
12:40:35 <Stskeeps> lbt: we still need a proper place for placing them
12:40:35 <lbt> keep trying but can't... need to package OBS :P
12:40:43 <Stskeeps> which i guess is on my table
12:41:42 <lbt> I think we should be careful with things like that
12:41:48 <lbt> ie we need a 1.0
12:41:57 <lbt> and we should say if this is in or out
12:42:07 <lbt> if out then we defer until post 1.0
12:42:11 <Stskeeps> :nod:
12:42:18 <Stskeeps> 'like that'?
12:42:31 <lbt> eglibc
12:42:36 <Stskeeps> right
12:42:55 <lbt> no technical issues with it at all
12:42:59 <Stskeeps> we do need to have 2.14 too probably
12:43:01 <Stskeeps> for security fixes, et
12:43:02 <Stskeeps> c
12:43:04 <Stskeeps> but that's on my table
12:43:32 <lbt> 103 is blocked on IMG
12:44:00 <Stskeeps> 144 (ARM thumb2) support i'd like to see if we can do more efficiently
12:44:22 <lbt> hmm that list should have 'blocked' as a column
12:44:23 <Stskeeps> ideally it should be following B_CNT.CI_CNT from 'lower end'
12:44:28 <lbt> blocked by
12:44:49 <Stskeeps> ie, that we have an armv7l port and then armv7 + thumb is an overlay choice
12:45:15 <Stskeeps> perhaps useforbuild kind of thing
12:45:26 <Stskeeps> so it doesn't do entire build cycles itself
12:45:37 <lbt> (you should document the term overlay)
12:45:49 <Stskeeps> mm
12:45:49 <Stskeeps> :P
12:45:56 <Stskeeps> it's a bit ambigious in this case :)
12:46:56 <lbt> 128  = upgrade readline ... low->medium yet? or post 1.0
12:47:07 <Stskeeps> that one was gplv3 problematic i think
12:47:32 <lbt> oh yes
12:48:31 * lbt adds #161 to list
12:50:24 <lbt> OK - I see a lot of work but not much to change
12:50:51 <Stskeeps> yeah, proceed forward
12:51:01 <Stskeeps> anything else or can we close the meeting?
12:51:42 <lbt> release blocking
12:52:02 <Stskeeps> mmm
12:52:11 <Stskeeps> "blocks next release"?
12:52:14 <lbt> do we have any intention of marking bugs as release blockers
12:52:16 <lbt> yes
12:52:25 <lbt> just to help schedule
12:52:31 <Stskeeps> perhaps
12:53:22 <lbt> it should help us anticipate when a release is at risk of slip
12:53:27 <Stskeeps> yes
12:53:43 <lbt> and may push certain things back - which helps
12:53:50 <Stskeeps> i'm fairly sure that tomorrow's release will slip, as i want to have at least a prerelease on top of COBS before pushing this out
12:53:58 <Stskeeps> the good news is that it's already quite good release
12:55:32 <lbt> what release cycle are you working on - maybe we should get this described better:  http://wiki.merproject.org/wiki/Special:Search?search=Release&go=Go
12:56:02 <lbt> raise a task bug?  :P
12:56:02 <Stskeeps> :nod:
12:56:22 <Stskeeps> i'm trying to hit 0.20120209.1 and well, that's not happening
12:56:32 <Stskeeps> i can much better do this if we get BOSS process going sanely
12:57:22 <Stskeeps> so we have either a 7-day or 14-day schedule of releases
12:57:52 <Stskeeps> anyway, back to work..
12:57:55 <Stskeeps> thank you all for coming
12:58:03 <Stskeeps> thanks to lbt for sorting out the bugs
12:58:35 <lbt> thanks
12:58:42 <Stskeeps> #endmeeting