11:01:16 <lbt> #startmeeting Mer Bug Triage 30 July 2012
11:01:16 <MerBot> Meeting started Mon Jul 30 11:01:16 2012 UTC.  The chair is lbt. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
11:01:16 <MerBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:01:51 <phaeron> 
11:02:01 <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:02:22 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=477 - sulogin is missing, thus e.g., systemd emergency mode fails
11:03:08 <phaeron> normal?
11:03:08 <lbt> normal
11:03:31 <lbt> Stskeeps - you editing?
11:03:42 <Stskeeps> yes
11:03:51 <Stskeeps> can we make it /bin/sh or something, perhaps?
11:04:07 <Stskeeps> actually, we have newer util-linux
11:04:12 <phaeron> that would be a security issue , right ?
11:04:36 <Stskeeps> not necessarily.. generally it should show a big fat 'device didn't boot up' ;)
11:04:54 <phaeron> MALF :D
11:04:56 <Stskeeps> #info normal, we have newer util-linux in queue
11:04:59 <phaeron> anyway
11:05:43 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=478 - If /etc/resolv.conf on host changes it doesn't reflect to SDK
11:05:58 <Stskeeps> really difficult to deal with..
11:06:01 <Stskeeps> scratchbox had same issue
11:06:15 <Stskeeps> perhaps update on 'enter'?
11:06:16 <lbt> we have parentroot
11:06:24 <lbt> it can be a symlink
11:06:30 <Stskeeps> tuue
11:06:31 <Stskeeps> true
11:06:52 <lbt> mind you I did something similar with CA-certs *g*
11:07:01 <phaeron> low
11:07:08 <Stskeeps> :nod: i agree on low
11:07:23 * phaeron twitches on mention of ssl
11:07:30 <lbt> OK - it'll get done in the SDK sweep this week I hope
11:07:45 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=480 - osc branch does weird things with names with a '.'
11:07:58 <lbt> yeah ... and I found it with Mer.MDS :/
11:08:01 <Stskeeps> normal
11:08:08 <phaeron> low, report upstream ?
11:08:14 <Stskeeps> that too
11:08:56 <Stskeeps> i think normal as it's a pretty normal developer use case
11:08:59 <phaeron> lbt: you could maybe rename that project :)
11:09:12 <Stskeeps> and in all our docs
11:09:20 <phaeron> ouch
11:09:21 <lbt> phaeron: and all the deployed projects
11:09:37 <phaeron> on cobs move then
11:09:49 <Stskeeps> next
11:09:51 <lbt> I'd say normal and fix it
11:09:52 <Stskeeps> #info normal
11:10:10 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=481 - gdb is broken when building qt-mobility in sb2
11:10:21 <Stskeeps> link to 'provide cross gdb'
11:10:33 <Stskeeps> #info deps on 206
11:10:46 <Stskeeps> normal as it might affect launch time
11:11:17 <phaeron> building or running in desc ?
11:11:40 <Stskeeps> the readonly is part of some trick qt/qt mobility uses
11:12:59 <phaeron> ok have no idea
11:13:38 <Stskeeps> #info normal
11:13:39 <Stskeeps> next
11:13:49 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=482 - XOrg from Mer:Next (as of 20120725) dies with SIG 6 during start on i586
11:14:08 <Stskeeps> part of kmod issue, we've fixed this, i think
11:14:24 <Stskeeps> high prio
11:14:34 <Stskeeps> and release blocker
11:14:35 <phaeron> high
11:14:45 <lbt> OK, he'd reflashed at this point so wasn't able to retest
11:14:57 <lbt> asking for a re-test would be good
11:15:56 <Stskeeps> #info high, release blocker, part of kmod issue
11:15:56 <Stskeeps> next
11:16:13 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=485 - eat-run-command causes remote test executions to fail
11:16:30 <Stskeeps> that really looks like a shell quoting malfunction..
11:16:42 <E-P> this happens only if eat-store-env is not executed
11:16:58 <phaeron> hmm I only tested normal eat ssh and testrunner on device
11:17:03 <Stskeeps> ok, so if there's no eat-store-env being executed?
11:17:06 <Stskeeps> otherwise it works fine?
11:17:40 <E-P> yes
11:17:57 <E-P> phaeron: this only comes when using remote execution
11:18:19 <Stskeeps> ok, so it works fine with eat-run-command, but if eat-store-env has been done, it fails?
11:19:09 <lbt> comment 1 suggests the opposite
11:19:16 <E-P> it works with eat-run-command when eat-store-env has been done, if not then it fails
11:19:24 <Stskeeps> ok
11:19:50 <Stskeeps> normal or low prio ?
11:20:01 <E-P> low
11:20:38 <E-P> btw, do you have to execute the eat-store-env manually?
11:21:00 <Stskeeps> #info low, 13:19] <E-P> it works with eat-run-command when eat-store-env has been done, if not then it fails
11:21:04 <phaeron> no the eat device key does it when you ssh using it
11:21:05 <Stskeeps> it gets done by /etc/xdg/autostart
11:21:24 <phaeron> ah sorry store env ny xdg right
11:21:30 <E-P> ok, my x didn't start so thats why it was missing
11:21:34 <Stskeeps> yes
11:21:41 <Stskeeps> as it's about the session
11:21:42 <E-P> so low is good then
11:21:54 <Stskeeps> next
11:22:04 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=486 - outdated tzdata package.
11:22:16 <Stskeeps> i think high..
11:22:47 <Sage> :nod:
11:23:01 <lbt> I'd say normal
11:23:17 <Stskeeps> for products, sane tzdata matters a lot
11:23:37 <lbt> totally agree :)
11:24:07 <Stskeeps> high, imho
11:24:27 <Stskeeps> #info high, sane tzdata matters a lot for products
11:24:30 <lbt> i see other things that block a product delivery more - it's not a big/disruptive task
11:24:36 <Stskeeps> mm
11:24:39 <lbt> so high is fine
11:24:40 <Stskeeps> next
11:24:48 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=488 - CA certificates does not hash certificate directory
11:25:05 <Stskeeps> we need to switch ssl certs strategy, the fedora way is simply not sane
11:25:05 <phaeron> high :)
11:25:13 <lbt> high
11:25:40 <Stskeeps> and doesn't work nicely with our core-hw adaptation-ui seperation
11:26:35 <lbt> not sure I follow that bit
11:26:37 <Aard> everything for that is already done and tested on jolla side, basically just needs to be moved to mer
11:26:38 <Stskeeps> #info high: fedora ssl certs strategy does not sync well with core-hw adaptation-ui seperation
11:26:56 <lbt> Aard: pm me a link please
11:27:01 <Stskeeps> next
11:27:13 <lbt> what has this got to do with hw/ui ?
11:27:36 <lbt> monolithic cert packages?
11:27:37 <Stskeeps> lbt: fedora delivers a full product
11:27:50 <Stskeeps> and yes, it doesn't give much leeway for extensibility on cert side
11:28:23 <lbt> it feels to me that ssl certs should be part of the product
11:28:36 <Stskeeps> yes, but we can provide some from mer side, and allow vendor to add own
11:28:40 <lbt> OK
11:28:41 <Stskeeps> that's the problem right now
11:28:53 <lbt> that's not clear in the bug
11:29:25 <Stskeeps> it is now
11:29:25 <Stskeeps> :P
11:29:28 <lbt> maybe it should say that we need a way to support multiple cert packages
11:29:30 <lbt> :)
11:29:38 <Stskeeps> next?
11:29:40 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=489 - mic won't copy /etc/mtab during image build even if it is created by the ks
11:29:49 <lbt> just getting paste ready ...
11:30:08 <Stskeeps> that's even a bug for tizen, i would imagine
11:30:24 <Stskeeps> it should not tamper with /etc/mtab at all, just leave it as a symlink
11:30:26 <phaeron> high but needs to depend on sorting Tools mess
11:30:26 <lbt> I wonder why
11:30:38 <lbt> phaeron: part of my SDK work this week
11:30:53 <Stskeeps> high bug, it will be needed for next SDK release
11:30:53 <lbt> though mic may not make it - we'll see
11:30:56 <phaeron> yes
11:31:18 <Stskeeps> #info high, needed for next SDK release
11:31:24 <lbt> my concern is *why* that exception went in
11:31:25 <kallaballa> fyi: i've got the solution at hands it think. turned out to be rather simple.
11:31:41 <Stskeeps> lbt: probably ancient code
11:32:44 <lbt> ok ... we'll see
11:33:29 <Stskeeps> next pleae
11:33:43 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=490 - Curl uses fixed CA file instead of CA path
11:33:56 <Stskeeps> same thing about certificate strategy
11:34:00 <lbt> kallaballa: please comment in bug btw - ty
11:34:27 <Stskeeps> normal bug for now, i think
11:34:37 <lbt> yep
11:34:39 <phaeron> normal , but also part of fedora mess
11:34:48 <Stskeeps> yes
11:34:51 <Aard> Stskeeps: it breaks things for jolla
11:35:04 <Stskeeps> Aard: agreed, but it takes higher prio bugs in order to solve it first anyway
11:35:08 <Stskeeps> so it comes in next line
11:35:29 <lbt> Aard: also if it's high for Jolla then Mer doesn't stop Jolla from fixing it
11:35:43 <Stskeeps> :nod:
11:35:50 <Aard> lbt: the important fix about the rehashing is on jolla side. this one is just a 2 minute thing
11:36:12 <Aard> lbt: and I'm currently not beeing able to use gerrit due to the id registration thing
11:36:26 <lbt> now *that* is high IMHO
11:36:31 <Stskeeps> (id registration thing?)
11:36:34 <lbt> yes
11:36:36 <Stskeeps> what mer bug is that?
11:36:50 <lbt> dunno - check in closing part of triage
11:36:53 <Stskeeps> ok
11:37:08 <lbt> so normal here too
11:37:21 <Stskeeps> Aard: i'm setting to normal prio, and deping on 488 - i think honestly the fix for this comes with 488 fix
11:37:33 <Aard> ok
11:37:43 <Stskeeps> as it's a openssl.cnf thing
11:38:36 <Stskeeps> #info normal, dep on 488. 488 might solve issue altogether
11:39:22 <phaeron> it doesn't I think it's different
11:39:35 <Stskeeps> it gets capath/cabundle from somewhere, at least
11:39:38 <Stskeeps> anyhow, we'll see
11:39:39 <Stskeeps> next?
11:39:40 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=493 - powertop doesn't build against Mer:Tools
11:39:51 <Stskeeps> didn't we skip one?
11:40:03 <Stskeeps> 491
11:40:30 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=491 - Vendor request: A policy restricting copying packages from other distros
11:40:41 <Stskeeps> assign to me, we need to bring this up in release management
11:40:43 <Stskeeps> normal prio
11:41:13 <lbt> agreed
11:41:27 <Stskeeps> next
11:41:43 <Stskeeps> (493)
11:41:49 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=493 - powertop doesn't build against Mer:Tools
11:42:03 <lbt> just noted it to fix in SDK work this week
11:42:04 * Stskeeps looks
11:42:55 <Stskeeps> lbt: https://build.pub.meego.com/project/show?project=Mer%3ATools%3ATesting looks totally screwed
11:43:36 <lbt> yeah - does rather
11:44:15 <Stskeeps> #info carsten should SR pciutils to Mer:Tools:Testing
11:44:28 <lbt> do you already have it ?
11:44:33 <Stskeeps> yse
11:44:36 <Stskeeps> in home:stskeeps:grande2
11:44:54 <Sage> hmmp... IIRC systemd would like to use libpci as well, but it is currently not used as it is not available.
11:44:56 <lbt> note in bug so I don't redo it
11:45:01 <Stskeeps> ok
11:45:06 <lbt> core?
11:45:25 <Sage> ah, pciutils was the thing
11:46:10 <Stskeeps> lbt: i presume you'll look at all the failed
11:46:24 <lbt> yep
11:46:33 <lbt> I have a task in sprint FWIW
11:46:50 <Stskeeps> #info SR#5344, resolved/fixed
11:46:53 <Stskeeps> next?
11:46:54 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=495 - Ensure the worker cache is being used
11:47:00 <Stskeeps> high
11:47:08 <lbt> yup
11:47:29 <Stskeeps> next
11:47:30 <Stskeeps> #info high
11:47:32 <lbt> new one
11:47:35 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=496 - As a vendor, I want to be able to contribute without an OpenID account
11:47:50 <Stskeeps> without?
11:47:52 <lbt> Aard couldn't find an openid so made this for us :D
11:47:59 <Stskeeps> you can use yahoo or google, too ;)
11:48:15 <lbt> I think it means - please use LDAP in gerrit
11:48:19 <Stskeeps> yes
11:48:28 <Stskeeps> do we have a bug for that yet?
11:48:28 <Stskeeps> else i
11:48:30 <Stskeeps> 'll rename
11:49:04 <Stskeeps> normal prio, it is kinda invasive so i dont want to do it at pace of 'high'
11:49:17 <Stskeeps> lbt: did we have a ldap openid endpoint yet?
11:49:26 <lbt> I couldn't see a bug
11:49:41 <lbt> not looked at that
11:49:45 <Stskeeps> ok
11:50:12 <lbt> last I recall we had to switch to LDAP 100%
11:50:16 <Stskeeps> yes
11:50:34 <Sage> I would personally prefer rest of the stuff to go towards openid ;)
11:50:42 <Stskeeps> #info renamed bug, next
11:50:42 <lbt> and IMHO we don't have bandwidth to examine other options
11:50:50 <Stskeeps> #info normal prio
11:50:54 <Stskeeps> next
11:50:58 <lbt> all done
11:51:27 <lbt> Sage: too complex - we *could* look to have openid authentication enabled as per stackoverflow
11:51:39 <lbt> but too much hassle atm
11:51:41 <Stskeeps> lbt: any tasks?
11:51:49 <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:51:57 <lbt> #topic https://bugs.merproject.org/show_bug.cgi?id=476 - Mer should have a clear license policy dealing with GPLv3 etc
11:52:31 <Stskeeps> architect view: vendors are still not comfortable with GPLv3, especially in STB
11:52:37 <Stskeeps> assign to me, please
11:52:47 <lbt> (you're editing)
11:52:57 <Stskeeps> oh, right
11:53:40 <Stskeeps> next
11:53:47 <lbt> nb .. the bug is about the ability to consistently communicate the policy - not opinion on it
11:53:48 <Stskeeps> #info architect view: vendors are still not comfortable with GPLv3, especially in STB
11:53:53 <Stskeeps> yes
11:54:07 <lbt> that was it I think...
11:54:11 <lbt> yep
11:54:20 <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:56:04 <Stskeeps> and bug list?
11:56:04 <phaeron> so
11:56:24 <lbt> sry, was reading
11:56:31 <lbt> phaeron: ?
11:56:56 <lbt> were you going to say something?
11:57:19 <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=
11:58:05 <Stskeeps> we can drop 202 in priority a bit, i hink
11:58:22 <Stskeeps> 387 can be resolved/fixed, i've merged it now
11:58:32 <phaeron> no just poking the silence
12:00:09 <Stskeeps> ok, i think we're done?
12:00:48 <lbt> OK
12:01:04 <lbt> #endmeeting