11:01:28 <lbt> #startmeeting Mer Bug Triage 23 Jul 2012
11:01:28 <MerBot> Meeting started Mon Jul 23 11:01:28 2012 UTC.  The chair is lbt. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
11:01:28 <MerBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:02:19 <lbt> good morning all
11:02:57 <phaeron> 
11:03:01 <lbt> https://wiki.merproject.org/wiki/Bug_Lifecycle  for anyone new
11:03:10 <alterego> Good afternoon
11:03:20 <lbt> please don't edit bugs during the meeting to avoid in-flight changes
11:03:32 <lbt> Stskeeps will do changes today
11:03:34 <lbt> ty
11:03:37 <alterego> emergency exits are here, here and here.
11:03:44 <lbt> indeed :)
11:03:46 * Stskeeps blocks the emergency exists
11:03:48 <Stskeeps> -s
11:03:51 <lbt> good man!
11:03:59 <alterego> lol
11:03:59 <lbt> #info We'll start with the bugs: https://bugs.merproject.org/buglist.cgi?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&emailassigned_to1=1&emailtype1=substring&query_format=advanced&order=bug_id
11:04:02 <timoph> o/
11:04:31 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=437 - glibc should be a 586 package . This also allows mic to work with -A / --architecture i586
11:04:57 <Stskeeps> low, it's mostly an annoying cosmetic issue, IMHO
11:05:07 <Sage_> :nod:
11:05:20 <Stskeeps> the 'i686' part is a little more involved in the packaging than one might thin
11:05:21 <lbt> makes release scripts need to cope with strange edge-cases
11:05:23 <Stskeeps> k
11:05:27 <Stskeeps> good? ;)
11:05:44 <lbt> OK then :/
11:05:57 <Stskeeps> we have armv7tnhl in some archs, so
11:06:19 <lbt> add any hints on packaging to enable others to take
11:06:29 <Stskeeps> the problem is in ./configure call, i think
11:06:38 <lbt> #info low - cosmetic
11:07:01 <Stskeeps> done
11:07:01 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=441 - Add versions to patterns
11:07:20 <Stskeeps> normal, i'd say, something that matters in SSU like setups
11:07:32 <lbt> hmm
11:08:01 <lbt> wondering if this should be a release area task ?
11:08:09 <Stskeeps> yes, it might be
11:08:16 <Stskeeps> but the patterns are coming from project-core
11:08:58 <Stskeeps> normal sounds sane?
11:08:59 <lbt> can we link it to the createrelease area so it's not missed
11:09:13 <lbt> yes
11:09:23 <Stskeeps> ok
11:09:39 <lbt> #info normal, matters for SSU and re-creation
11:09:51 <Stskeeps> done
11:09:52 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=442 - Mer should provide a 'sb2-mount' that sets up CWD as sb2 target
11:10:22 <alterego> Does this fix the annoying osc chroot issue?
11:10:23 <lbt> yeah - feels like a dupe
11:10:24 <Stskeeps> the current method we're using to set up a given image with sb2 is far too complex to explain to people
11:10:40 <Stskeeps> dupe from where though?
11:11:11 <Stskeeps> this should be a task, for what it's worth
11:11:13 <Stskeeps> so is 441
11:11:43 <lbt> can't see the dupe - maybe not recorded well - just add a note that there's a potential dupe
11:11:46 <Stskeeps> :nod:
11:11:51 <Stskeeps> prio, normal?
11:11:56 <Stskeeps> it's 'be nice to developers'
11:12:33 <Stskeeps> this was based in a real life situation fwiw, hence me stating it :P
11:12:38 <lbt> looking at scope
11:12:50 <lbt> are they able to download a rootfs?
11:13:07 <Stskeeps> set up a given sb2 target which is in $cwd
11:13:18 <Stskeeps> er, $PWD
11:13:27 <lbt> $DIR is fine
11:13:37 <lbt> adding cd $DIR is manageable :)
11:13:49 <Stskeeps> so basically after the fact you can access the sb2 target
11:13:54 <Stskeeps> build against it, add new packages, etc
11:13:59 <lbt> yeah - normal - it's a small task
11:14:03 <lbt> reasonable win
11:14:17 <Stskeeps> next
11:14:30 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=443 - OBS worker won't shutdown
11:14:43 <Stskeeps> normal, i think, i've encountered this a little too many times
11:15:02 <lbt> yes
11:15:23 <lbt> #info normal - happens a bit
11:15:47 <Stskeeps> next
11:15:52 <lbt> #info 442 is normal and a good simple task
11:15:57 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=445 - BFD (GNU Binutils) 2.22 assertion fail elf32-arm.c:12049
11:16:19 <Stskeeps> low - it hasn't shown any visible problems so far and will probably disappear with next binutils
11:16:22 <Stskeeps> but should be tracked anyway
11:16:51 <lbt> #info low - seems to be a no-visible-effect warning
11:17:42 <Stskeeps> have seen it on ubuntu too afaik
11:18:07 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=446 - Create test coverage chart/table for core packages
11:18:10 <E-P> task, maybe normal
11:18:21 <E-P> or even high
11:18:37 <Stskeeps> let's say high, that way we can track progress better?
11:19:02 <lbt> can this be auto-generated?
11:19:04 <Stskeeps> next
11:19:11 <E-P> lbt: not at the moment
11:19:19 <lbt> even if it needs package-specific generation snippets
11:19:32 <E-P> when we have tests then yes
11:19:39 <lbt> I worry about the value of anything relying on manual updates
11:19:49 <lbt> ie mainly useless :)
11:20:37 <E-P> yep
11:20:39 <lbt> so just add something that says that to the notes to ensure this is more about laying foundations for automated generation than getting it right today
11:20:50 <lbt> ty
11:21:12 <E-P> ok
11:21:15 <lbt> #info high - can't be autogenerated yet but that should be the goal
11:21:19 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=447 - Create a smoke test plan for Mer releases
11:21:28 <E-P> also task
11:21:38 <Stskeeps> high?
11:21:43 <lbt> yes
11:21:45 <E-P> yes
11:21:59 * Stskeeps looks at the burning buildings after last prerelease..
11:22:14 <lbt> create something where these smoke tests are in prio order too
11:22:39 <E-P> nod
11:22:43 <lbt> prolly obvious - sry
11:22:44 <Stskeeps> next
11:23:03 <lbt> OK, we have a slew of "update bugs"
11:23:21 <Stskeeps> all tasks
11:23:29 <Stskeeps> for sure
11:23:41 <lbt> yep - any stand out as high or low
11:24:01 * Stskeeps looks
11:24:05 <lbt> #topic - many update bugs
11:25:02 <Stskeeps> possibly libpng
11:25:29 <Stskeeps> hmm
11:25:29 <Stskeeps> no
11:25:30 <lbt> libXScrnSaver ?
11:26:15 <Stskeeps> libjpeg-turbo is probably normal
11:26:46 <lbt> Stskeeps: OK - quick enough to update now and yell when done... or offline?
11:27:40 * Stskeeps takes low first
11:30:00 <Stskeeps> moment..
11:31:47 <Stskeeps> 466 i've changed summary on and changed to normal
11:31:49 <Stskeeps> (libjpeg)
11:31:54 <Stskeeps> it includes new neon/ssse3 optimizations
11:32:28 <Stskeeps> lbt: let's start from 468
11:32:47 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=468 - update libtiff to 4.0.2 [possibly CVE-2012-1173, CVE-2012-2113]
11:33:01 <Stskeeps> high, due to CVE
11:33:04 <lbt> (sorry, was uploading kitten pictures to facebook)
11:33:49 <lbt> makes sense
11:33:50 <lbt> #info high due to CVE
11:34:01 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=469 - update pixman to 0.26.2
11:35:23 <Stskeeps> sec, reading changelog
11:36:29 <Stskeeps> normal, a lot of new optimizations for MIP
11:36:29 <Stskeeps> A
11:36:30 <Stskeeps> S
11:36:46 <lbt> #normal a lot of new optimizations for MIPS
11:36:55 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=470 - update qt to 4.8.2
11:38:17 <lbt> I think we should have a better page on Qt for Mer
11:38:33 <lbt> ie how we handle upstream relationship and packaging
11:39:43 <Stskeeps> welll
11:39:44 <Stskeeps> :P
11:40:01 * Stskeeps ponders if there's a changelog
11:41:46 <Stskeeps> low prio, we need it eventually to smoothen transition to qt5
11:42:22 <lbt> #info low prio, we need it eventually to smoothen transition to qt5
11:42:33 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=471 - fdisk and partx use GPLv3 licensed code
11:43:19 <Stskeeps> high.. i need to check exact implications
11:43:50 <lbt> I wasn't sure you could accept GPL3 code snippets to GPL2 code
11:43:59 <lbt> is this an upstream bug?
11:44:16 <Stskeeps> well its known parts of util linux is gplv3
11:46:19 <lbt> agree high
11:46:26 <Stskeeps> next
11:47:11 <lbt> #info high - implications need checking - note we could also benefit from a clear position statement on gpl2/3 licensing and permissibility of various blends
11:47:22 <lbt> in fact that's a task
11:47:50 <Stskeeps> nah, it's a bug in this particular case.. there shouldn't be gplv3 on device in first place
11:48:07 <lbt> I agree - where does it say that in the wiki?
11:48:24 <lbt> and under what circumstances do we permit gpl3?
11:48:32 <lbt> that's all I would like to see :)
11:48:38 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=472 - glibc build fails at times to syntax error in build-i686-linuxnptl/shlib.lds:128
11:49:04 <Stskeeps> https://wiki.merproject.org/wiki/Architecture#GNU_utilities
11:49:19 <Stskeeps> low, race condition that happens on occasion, a bit annoying but difficult to catch in act
11:49:29 <lbt> obviously, next to the leopard....
11:49:33 <Stskeeps> yes
11:50:14 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=475 - Undefined reference to QTMLocationProvider::QTMLocationProvider()
11:51:00 <Stskeeps> i guess high
11:51:03 <Stskeeps> we need the api to be there
11:51:06 <Stskeeps> for later replacement
11:51:43 <lbt> so "package libqtm-location-dev" ?
11:51:53 <Stskeeps> nah, worse
11:51:57 <Stskeeps> give it a standard backend
11:53:01 <Stskeeps> ok, next
11:53:30 <lbt> #info high - need to provide a standard backend
11:53:37 <lbt> anything useful in tizen?
11:53:47 <Stskeeps> we can probably just wire up gpsd or gypsy
11:53:56 <Stskeeps> and run-time replace on a vendor basis..
11:54:22 <lbt> OK
11:54:26 <lbt> #topic Moving on to 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&order=bug_id
11:54:41 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=439 - Testability Driver: Merging agent_qt qt5 branch to Mer
11:55:05 <Stskeeps> E-P, opinion/
11:55:06 <Stskeeps> ?
11:55:22 <E-P> normal for mer, but high for nemo
11:55:31 <Paimen> Stskeeps: I promised to look that and 440
11:55:47 <E-P> I would say high
11:57:00 <lbt> #info high
11:57:07 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=440 - Testability Driver: agent_qt QT5 branch needs corrections for QtQuick 2.0 naming
11:57:18 <E-P> normal
11:57:44 <lbt> worth merging the tasks?
11:57:58 <Paimen> just for info that needs to be done with 339 because qt5 branch does not compile with old naming scheme
11:58:06 <Paimen> 439*
11:58:29 <lbt> good - avoids a double review - ah, it does depend (shouldn't it block?)
11:59:31 <lbt> #info normal - needs to be done with #439
11:59:37 <lbt> OK ... all done...
11:59:42 <lbt> #info Task list is now: https://bugs.merproject.org/buglist.cgi?bug_severity=task&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=not-taken%40&emailassigned_to1=1&emailtype1=substring&query_format=advanced&order=priority%2Cbug_id&query_based_on=
11:59:43 <Paimen> well if you look it from that angle, but how we proceed, first merge and then fix naming or first fix things to qt5 branch and then merge
12:00:23 <lbt> Paimen: up to you - ideally do it to permit the reviewer to check the tasks by themselves
12:00:42 <Paimen> ok
12:00:56 <lbt> ie 2 logical patches (or patch sets)
12:00:58 <lbt> yeah
12:01:13 <Paimen> well those can be merged to one task too if it is easier
12:01:48 <lbt> yep - the main thing is that the reviewer would probably do both in the same afternoon, not a week apart :)
12:02:37 <lbt> ah, 475 was renamed... OK
12:05:08 <lbt> #info Not taken bugs: https://bugs.merproject.org/buglist.cgi?bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=trivial&bug_severity=enhancement&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=not-taken%40&emailassigned_to1=1&emailtype1=substring&query_format=advanced&order=priority%2Cbug_id&query_based_on=
12:08:27 <lbt> we sure need that bug-squash session
12:08:46 <Stskeeps> yup
12:09:30 <lbt> OK - if there are no more comments I think we're done
12:09:56 <lbt> thank you all for coming
12:10:02 <lbt> #endmeeting