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