14:03:09 <Stskeeps> #startmeeting Mer bug triage 2/1/2012
14:03:09 <MerBot> Meeting started Mon Jan  2 14:03:09 2012 UTC.  The chair is Stskeeps. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
14:03:09 <MerBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:04:28 <Stskeeps> welcome to the first mer bug triage :) the procedure is fairly simple, we walk through https://bugs.merproject.org/buglist.cgi?priority=Undecided&query_format=advanced&emailassigned_to1=1&order=Bug%20Number&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=need-triage&emailtype1=substring , set priority, ...
14:04:34 <Stskeeps> ... discuss a bit about the bug and issues. If you see a bug you're volunteering to fix, feel free to indicate this
14:06:32 <Stskeeps> we can vary on severity=critical,major,normal,trivial,enhancement and task, and priority=low,normal,high
14:06:43 <Stskeeps> task means it's a bite-size task someone can do
14:06:46 <Stskeeps> okay, let's start started
14:07:06 <Stskeeps> er, get started :)
14:07:24 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=3 - qt-mobility does not build QtMessaging module
14:08:05 <Sage> do we have qmf in mer core already?
14:08:06 <Stskeeps> i propose this to become a task, and changing it into "enable pkgconfig(qmf) as buildrequires" - priority high
14:08:09 <Stskeeps> yes, it's there
14:08:15 <Stskeeps> that was bug 10 :)
14:08:46 <Sage> ok. Then this is quite easy however I would prefer someone to try the qt messaging before it is submitted to mer core as a patch.
14:09:16 <Sage> qmf is already release or currently in pre release?
14:09:19 <Stskeeps> any takers for fixing it or any objections (if you want, assign to yourself later)?
14:09:21 <Stskeeps> prerelease, i think
14:09:37 <Sage> I can take this one for packaging point of view but someone else needs to test it.
14:09:49 <Stskeeps> ok
14:10:03 <Stskeeps> #info task, high, assigned to sage, someone else needs to QA
14:10:05 <Sage> I might be the one who removed it originally :)
14:10:29 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=4 - Bug 4 - process needs a way to wait-for other changesets to be merged for testing
14:10:55 <lbt> I think I should take that one
14:10:56 <Stskeeps> in Mer, we use a workflow system called BOSS, and this bug deals with developers being able to indicate "please first merge this when another change has been made"
14:11:18 <Stskeeps> i'd say medium priority as it's not critical, but with the latest toolchain work, it is definately needed
14:11:34 <Stskeeps> #link http://gitweb.merproject.org/gitweb?p=mer/boss-workflow.git;a=tree
14:11:40 <lbt> good - that's what I wondered
14:11:53 <Stskeeps> any objections to medium priority?
14:12:16 <Stskeeps> #info assign to lbt
14:12:40 <Stskeeps> #info medium
14:12:51 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=6 - Toolchain bug occurs on armv7hl architecture builds
14:12:58 <lbt> mmm
14:13:13 <Stskeeps> #info has been fixed with prerelease new compiler, to my knowledge
14:13:20 <Sage> yes
14:13:44 <Sage> at least someone said so at IRC IIRC
14:14:16 <Stskeeps> i propose RESOLVED FIXED, commenting in bug this fact
14:14:53 <Sage> agreed
14:14:56 <Stskeeps> #info RESOLVED FIXED, fixed in prerelease new compiler
14:15:28 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=7 - DNS address not set with static IP
14:16:05 <lbt> Is this a Mer bug?
14:16:12 <Stskeeps> isn't connman always listening on 127.0.0.1 and forwarding to the correct DNS server?
14:16:32 <Sage> we should test newer connman
14:16:33 <Stskeeps> or whatever it perceives as the correct DNS server
14:16:53 <Sage> the one that fixes the grps DHCP/DNS query problems might fix this one
14:16:58 <wagi> Stskeeps: yes, ConnMan has a dnsproxy
14:17:25 <Stskeeps> #info connman has dnsproxy, DNS setting may be reliant on what connection is being set as 'default'
14:17:38 <lbt> FWIW the file should contain a comment about usage in Mer
14:17:44 <wagi> Yep, ConnMan keeps a list of DNS servers
14:17:49 <Stskeeps> agreed, ie, "AUTOGENERATED"?
14:17:58 <Stskeeps> resolv.conf is created by connman so, afaik
14:18:09 <wagi> You can ask with the python test scripts what DNS server is active
14:18:09 <lbt> "do not edit this file as Mer uses conman on 127.0.0.1"
14:18:40 <wagi> resolv.conf forwards all DSN requests to ConnMan
14:18:55 <Stskeeps> ok, so i propose NEEDINFO - wagi: could you elaborate to the submitter on what python test scripts to use to gain more accurate info?
14:19:06 * Sage misunderstood the bug
14:19:24 <wagi> Stskeeps: sure, there are some test scripts in the ConnMan repository
14:19:28 <Stskeeps> :nod:
14:19:33 <andre__> but there is no NEEDINFO state?
14:19:34 <Stskeeps> connman-tests
14:19:38 <Stskeeps> andre__: there's no NEEDINFO state?
14:19:39 <wagi> They use work on the ConnMan D-Bus API
14:19:50 <andre__> not by default. except for that you (or somebody) added it.
14:19:53 <wagi> So you can use them to find out what's the current configuration
14:20:05 <Stskeeps> andre__: oh crap :)
14:20:15 <lbt> Sage: doesn't this mean that the GUI isn't telling conman what DNS server to use?
14:20:42 <wagi> You can of course add static DNS configuration if you like
14:20:49 <Sage> lbt: I'm not sure how the user is setting the ip there.
14:20:59 <wagi> Stskeeps: sure, propably I need to create an account first :)
14:21:08 <Sage> lbt: if user sets the IP without using the connman dbus api it is user problem IMO.
14:21:13 <Stskeeps> andre__: hmm, we have a field for it - let's take this in #mer after the meeting
14:21:21 <Stskeeps> yes, it's unclear if user sets IP without using connman APIs
14:21:25 <lbt> Sage: that's what I meant - is this a Mer or Nemo bug
14:21:31 <Sage> lbt: Mer
14:21:56 <lbt> What mechanism is the user using to set the IP config on wifi ?
14:22:01 <Stskeeps> lbt: connman d-bus apis
14:22:08 <andre__> Stskeeps: https://bugs.merproject.org/editworkflow.cgi for getting NEEDINFO
14:22:14 <andre__> (I guess)
14:22:15 <lbt> I don't see that in the bug so OK
14:22:46 <Sage> lbt: user isn't telling that what he is using, but he should be using connman dbus api's. thus NEEDINFO
14:23:03 <Stskeeps> #info User needs to explain what he uses to configure DNS, NEEDINFO
14:23:10 <Stskeeps> #info should be done with connman d-bus apis
14:23:27 <wagi> yep
14:23:31 <lbt> wagi: are you editing that bug then?
14:24:02 <Stskeeps> we'll edit as we go?
14:24:07 <wagi> lbt: Okay, I'll edit the bug
14:24:12 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=9 - Mer_Core_armv6l/maliit-framework compilation error
14:24:17 * wagi creates account
14:24:20 <lbt> Stskeeps: yes - but we should say who or we'll collide
14:24:24 <Stskeeps> yes, ok
14:24:37 <Sage> Stskeeps: just marked that resolved fixed as it is fixed in next prerelease
14:24:38 <Stskeeps> i believe this framework compilation error was fixed with the new toolchain
14:24:46 <Stskeeps> #info RESOLVED FIXED, fixed with prerelease
14:25:10 <wagi> lbt: if you have an account you can update it? It seems to take a while until I have the account. whitelisting :)
14:25:17 <lbt> will do
14:25:22 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=13 - ca-certificates packages is missing from Mer Core
14:25:23 <wagi> lbt: thanks
14:25:30 <veskuh> would be nice to have ALREADYFIXED for the previous kind of cases
14:25:48 <Stskeeps> #info maybe we need ALREADYFIXED?
14:26:03 <Stskeeps> this should be severity=task and priority=high
14:26:08 <andre__> well, ALREADYFIXED is just FIXED with an older TM ;-)
14:26:13 <lbt> we need a bug lifecycle
14:26:18 <lbt> andre__: ^^^ ?
14:26:34 <Sage> Stskeeps: I can take this one as well if you create ca-certificates to gitweb
14:26:44 <Stskeeps> ok
14:26:44 <Sage> I have the packaging ready already for this
14:26:57 <Stskeeps> #info assign to sage, stskeeps makes git repository
14:27:01 <andre__> lbt, well, there is one by default. but maybe it does not (yet) totally fit. :P
14:27:02 <Stskeeps> #info severity=task, priority=high
14:27:39 <Stskeeps> Sage: ca-certificates added
14:27:50 <Sage> ok
14:27:58 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=14 - Bug 14 - Organizer
14:28:03 <andre__> I assume I can close #14 as INVALID, with a comment explaining how to file good bug reports?
14:28:11 <Stskeeps> nah, the bug is correct
14:28:15 <Stskeeps> #info should be QtOrganizer missing
14:28:18 <andre__> ah
14:28:37 <Stskeeps> #info http://doc.qt.nokia.com/qtmobility/qtorganizer.html
14:28:44 <andre__> I always have problems if people keep it too short.
14:29:00 <Sage> I have fix for this as well but someone needs to test it
14:29:02 <Stskeeps> Sage: can you look at this together with pkgconfig(qmf)?
14:29:02 <Stskeeps> ok
14:29:08 * andre__ edits the bug summary
14:29:17 <Stskeeps> #info assign to sage as he has fix for it but needs QA
14:29:22 <Stskeeps> medium priority?
14:29:35 <Sage> I guess so if nobody is ugently needing this and willing to test :)
14:30:09 <vgrade> same as https://bugs.merproject.org/show_bug.cgi?id=3
14:30:17 <Sage> Stskeeps: are you handling the assignments later after the meeging btw?
14:30:34 <Stskeeps> yes, after triage
14:30:39 <lbt> when doing NEEDINFO do we assign to the OP ?
14:30:54 <Sage> Stskeeps: ok
14:31:12 <Sage> vgrade: not same, similar. Qt messaging vs qt organizer.
14:31:23 <Stskeeps> #info medium
14:32:02 <lbt> Stskeeps: there is no "medium" (AFAICT)
14:32:09 <Stskeeps> ok, "normal"
14:32:25 <Stskeeps> #info normal
14:32:31 <Stskeeps> consistency++
14:32:31 <Stskeeps> :P
14:32:36 <lbt> yeah :D
14:32:50 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=21 - qt-mobility has timestamps in debugsource
14:33:25 <Stskeeps> so, why are timestamps bad in binaries or source? :) because it means that if qtmobility recompiles and it compares differently to previously built rpms of same source package, it will rebuild everything utilizing qtmobility
14:34:04 <Stskeeps> so i'd say 'normal'
14:34:21 <Sage> sounds good
14:34:39 <Stskeeps> w00t: you're up for this one?
14:34:59 <w00t> i've not tried mobility before, and have a bit of a backlog, but sure
14:35:01 <w00t> i can take it
14:35:02 <Stskeeps> ok
14:35:08 <Stskeeps> #info normal, assign to w00t
14:35:32 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=23 - openssl contains timestamps
14:35:46 <Stskeeps> same problem as before, except openssl causes a lot more rebuilds
14:36:05 <Stskeeps> it should be a __DATE__ __TIME__ removal patch somewhere, so this is a perfect starter job :)
14:36:33 <vgrade> \o
14:36:40 <Stskeeps> assign to vgrade?
14:36:55 <vgrade> yup
14:36:55 <Stskeeps> #info turn into task, high priority, assign to vgrade
14:37:39 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=24 - Drop libGL dependancy from cairo
14:37:45 <Stskeeps> this is related to Bug 19 - Drop GL support from Mer Core
14:37:56 <Stskeeps> as we want to make a consistent api across platforms, and glesv2/egl is one that's shared
14:38:00 <Stskeeps> should probably be a 'task' instead
14:38:56 <Stskeeps> if you have any objections to the nature of some tasks, those are welcome too
14:39:24 <Stskeeps> #info low priority, task
14:39:34 <Stskeeps> also a nice easy packaging job
14:40:29 <Sage> I can take it if nobody else wants it.
14:40:47 <Stskeeps> #info assign to sage, other takers welcome
14:41:11 <lbt> do we need a backlog assignee ?
14:41:32 <lbt> for triaged but non-allocated tasks
14:41:38 <Sage> fixed ;)
14:41:45 <lbt> :P
14:41:51 <Stskeeps> we try to set a priority and then that becomes a task available for taking
14:42:27 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=25 - Bug 25 - Drop libGL dependancy from Xephyr / drop Xephyr
14:42:39 <Stskeeps> i'm a little unsure why xephyr needs libGL in dependancies, may be bad packaging
14:42:39 <Sage> that might be a bit harder one
14:42:42 <Stskeeps> yeah
14:42:48 <Stskeeps> low priority?
14:43:04 <Sage> I can check if it is easy or if it needs more work.
14:43:09 <Stskeeps> ok
14:43:21 <Stskeeps> #info sage will look into the nature of the task to elaborate on it
14:43:26 <Stskeeps> #info low priority
14:44:07 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=34 - python randomly fails to build
14:44:16 <Stskeeps> this one is really annoying as it fails our build checks very often
14:44:19 <Sage> btw, in which package xephyr is?
14:44:23 <Stskeeps> xorg-x11-server
14:44:43 <Stskeeps> so i'd say normal priority, it may be a race condition
14:45:22 <Stskeeps> and fixable with -j1
14:46:01 <Stskeeps> we run with -j8 which occasionally stumps builds
14:46:22 <Stskeeps> #info normal , may be fixable wih -j1, we use -j8 which occasionally breaks matters
14:47:11 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=36 - Bug 36 - Information missing from project-core gitweb summary page
14:47:17 <Stskeeps> this should be over in IT and gitweb instead?
14:47:38 <lbt> seems reasonable
14:47:49 <Stskeeps> medium priority, it annoys developers
14:48:15 <Stskeeps> #info should be in IT, gitweb - medium priority
14:48:38 <lbt> not sure if it's a feature request
14:48:47 <Stskeeps> enhancement, i guess
14:48:52 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=37 -  cross-*-gcc Requires: libgcc/cpp/libgomp/libmudflap but contains it itself
14:49:09 <Stskeeps> this one is fixed in prerelease, http://review.merproject.org/270
14:49:17 <Stskeeps> #info RESOLVED FIXED, fixed in prerelease, http://review.merproject.org/270
14:50:31 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=38 - Bug 38 - binutils, binutils-devel has a possible bashism in RPM scriptlets
14:50:37 <Stskeeps> okay, so, now we're at the bashism bugs
14:51:15 <Stskeeps> #info http://www.mail-archive.com/mer-general@lists.merproject.org/msg00054.html for a description of these
14:51:35 <Stskeeps> we can convert all those into tasks, ie, "remove bashism from RPM scriptlets" type of summary
14:51:38 <Stskeeps> and low priority
14:51:56 <Stskeeps> the idea is that we want to make it possible to perhaps switch to dash as /bin/sh over time
14:52:26 <Stskeeps> ie, https://bugs.merproject.org/show_bug.cgi?id=26
14:53:20 <Stskeeps> any objections to this assesment?
14:53:40 <Stskeeps> some of them are good junior jobs to take, easy to fix, others need to fix RPM macros
14:53:51 <lbt> will we stop shipping bash?
14:54:13 <Stskeeps> that remains to be seen, it's very useful as a user shell still ;)
14:54:23 <lbt> I'm thinking that as long as it says #!/bin/bash then bash-isms are OK
14:54:26 <Stskeeps> yeah
14:54:32 <Stskeeps> we just have to limit them
14:54:36 <lbt> but policy should say "use dash unless we have to"
14:55:00 <Stskeeps> #info Bashisms: convert to task, summary "Remove bashism from RPM scriptlets" type of summary, low priority
14:55:15 <Stskeeps> #info idea is that we want to make it possible to switch to dash as /bin/sh over time, see https://bugs.merproject.org/show_bug.cgi?id=26
14:56:36 <Stskeeps> #info do this for bugs 39,41,42,43,44,45,46,47,48,49,50,51 too
14:56:51 <Stskeeps> i'm skipping those bugs in the triage, hope that's OK :)
14:57:26 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=62 - gcc on x86 should only bootstrap when needed
14:57:54 <Stskeeps> right now gcc runs a full bootstrap, ie, first builds a gcc, then builds itself with that gcc each and every time on x86
14:58:18 <Stskeeps> this isn't terribly needed and some logic to prevent it from doing so unless the source has modified in any way
14:58:31 <Stskeeps> i'd say low priority as it's a build time slowness?
14:58:47 <lbt> yes
14:59:04 <Stskeeps> #info right now gcc runs a full bootstrap, ie, first builds a gcc, then builds itself with that gcc each and every time on x86 - low priority
14:59:59 <lbt> I'll take that one
15:00:09 <Stskeeps> ok
15:00:14 <Stskeeps> #info assigned to lbt
15:01:20 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=64 - - kernel-adaptation-n810 compiled using pre-release fails boot before reaching fbcon
15:01:52 <Stskeeps> this is a bug in toolchain, workaround is available in https://lkml.org/lkml/2011/5/31/385
15:02:04 <Stskeeps> high?
15:02:46 <lbt> what's the bug?
15:02:56 <lbt> toolchain or kernel ?
15:03:01 <Stskeeps> -fconserve-stack misaligns variables on the stack
15:03:14 <lbt> sorry, I wasn't clear
15:03:15 <Stskeeps> and it's being used in ARM kernels
15:03:26 <lbt> what's bug 64...
15:03:37 <lbt> fix the toolchain or fix the kernel conf
15:03:42 <Stskeeps> fix the toolchain
15:03:48 <Stskeeps> we need to track upstream for a fix
15:05:01 <Stskeeps> #info waiting for upstream for fix, workaround exists
15:05:06 <Stskeeps> #info high
15:06:02 <Stskeeps> #info rename to "toolchain -fconserve-stack misaligns variables on the stack, for ARM"
15:06:32 <lbt> heh... was just hovering on the "edit"
15:06:53 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=65 - upower needs pm-utils
15:07:00 <Stskeeps> Sage: i can create git repo?
15:07:06 <Sage> I have this ready when git repo appears
15:07:07 <Stskeeps> ok
15:07:16 <Stskeeps> done
15:07:19 <Sage> :)
15:07:25 <Sage> so assign to me and I'll fix it
15:07:29 <Stskeeps> #info medium, assign to sage
15:09:25 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=66
15:09:47 <Stskeeps> high priority, perl rebuilding is really annoying :) nice junior task too
15:10:00 <Stskeeps> happens when a build happens overnight
15:10:03 <Stskeeps> as the timestamps change
15:10:25 <lbt> o/
15:10:26 <Stskeeps> any takers to find and patch ths?
15:10:30 <Stskeeps> ok
15:10:34 <Stskeeps> #info lbt, high
15:10:39 <Stskeeps> #info assign to lbt, high
15:10:58 <Sage> out of bugs? :)
15:11:19 <Stskeeps> almost
15:11:20 <lbt> 73 ?
15:11:30 <Stskeeps> #topic https://bugs.merproject.org/show_bug.cgi?id=73 - Bug 73 - ofonod segfaults at boot on N900
15:12:01 <Sage> ofono :/
15:12:07 <Stskeeps> this looks awkward, would be good to see if this changed in prerelease
15:12:28 <Stskeeps> should we ask reporter to see if he sees it in new release when we have nemo on top of that?
15:12:31 <Stskeeps> i'd say medium priority
15:12:39 <Sage> sure
15:12:54 <Stskeeps> and help him collect coredumps
15:14:08 <Stskeeps> #info ask reporter to check if it happens in next mer release + nemo on top, high priority
15:14:14 <Sage> we should do guide how to collect core dumps :)
15:14:18 <Stskeeps> yes
15:14:22 <Sage> corewatcher would be nice btw
15:14:39 <Sage> at least for nemo
15:14:48 <Sage> but that needs patching the gtk stuff out.
15:15:06 <Stskeeps> #info medium priority
15:15:33 <Stskeeps> okay, that was it for the triage list
15:16:16 <Stskeeps> thank you all for coming
15:16:19 <Stskeeps> #endmeeting