14:00:06 <licquia> #startmeeting LSB Bug Triage 2013 Aug 8
14:00:06 <lsbbot> Meeting started Thu Aug  8 14:00:06 2013 UTC.  The chair is licquia. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:06 <lsbbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:00:17 <licquia> good morning
14:00:41 <mwichmann> morning
14:01:29 <mwichmann> another huge attendance
14:01:44 <licquia> yup
14:03:34 * licquia should figure out how to get the statistics re: open bugs, etc. from bugzilla someday
14:03:53 <mwichmann> .me realizes he's running on f18 because of the navigator problems.... and so the full header rebuild is taking double the time, sigh...
14:04:04 <mwichmann> can't even type right this morning
14:04:18 <mwichmann> I have prpared queries in my old deskzilla setup
14:04:27 <mwichmann> I fire that up every time I want the stats
14:06:20 <licquia> #info 2 new
14:06:45 <licquia> this should be quick
14:06:54 <licquia> !lsbbug 3830
14:06:56 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3830 normal, P2, ---, licquia, NEW , libbat needs an extension at step 9:
14:07:45 <licquia> this is a buildbot thing
14:08:54 <licquia> orc_fedo: is this really a problem?  i like being able to see whether a libbat/appbat build needed to download some source
14:09:42 <licquia> red = cache not found, green = at least some pkgs found in cache
14:11:05 * licquia asks the question in the bug, will leave for later
14:11:43 * mwichmann does not have strong opinions here, but you should indeed reassign, it's not an sdk bug/issue
14:12:53 <licquia> !lsbbug 3831
14:12:55 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3831 normal, P2, ---, licquia, NEW , MEDIATOR_FAILED rollup bug
14:13:01 <orc_fedo> licquia: just in ... I am more of the mind that: if a tell tale is needed, add a tell tale
14:13:11 <orc_fedo> what you describe is 'secret knowledge' stuff
14:13:52 <mwichmann> <poof>
14:14:12 <orc_fedo> (I do this for myself, and add 'hovers', for internally written web controlled stuff, to remind a future me what the old me was thinking when I designed / wrote it)
14:14:17 <orc_fedo> mwichmann: indeed
14:14:56 <licquia> sure, but there's no good way to add a tell to buildbot that doesn't require you to drill down into the step
14:15:13 <orc_fedo> my design appraoch is taken from Chostbusters (I):  http://www.youtube.com/watch?v=mlnqmXuDXO4
14:15:26 <orc_fedo> the light is green the trap is clean
14:16:14 <orc_fedo> licquia: dunno -- sounds like a buildbot usage issue then
14:17:55 * licquia supposes he could add an echo to the step itself, so if drilling down into a red step, there's a note that the step is allowed to fail
14:19:51 <mwichmann> are the allowed-fail steps in general marked?
14:20:06 <mwichmann> this has sometimes worried me looking at a screen
14:20:17 <licquia> they are in the config, but not indicated in any way on the web pages
14:21:03 <mwichmann> right
14:21:17 <licquia> that actually might be a better option: see if there's some way to indicate an "allowed to fail" step generally
14:21:26 <licquia> might require some buildbot hacking, though
14:21:27 <orc_fedo> my efforts to replicate teh LSB buildbut stable internally continue so I can better offer suggestions
14:21:41 <mwichmann> really the color scheme is a pain
14:21:56 <licquia> mwichmann: just in this case, or generally?
14:21:59 <mwichmann> red=failed, green=worked is fine
14:22:17 <mwichmann> I don't like yellow for in-progress, is all
14:22:23 <licquia> ah
14:22:51 <licquia> could do blue for in-progress and yellow for "failed but allowed to fail"
14:23:05 <licquia> orc_fedo: would that satisfy you?
14:23:10 <mwichmann> that might help me... maybe nobody else at all
14:23:16 <orc_fedo> licquia: seems fine to me
14:23:22 <licquia> consensus!
14:23:30 * licquia cuts-n-pastes into the bug
14:23:45 <orc_fedo> licquia: trim it up or we will hear grumbling
14:23:50 <mwichmann> heh
14:23:57 <mwichmann> side note:
14:24:22 * mwichmann requests, via bugzilla, a review of the 2nd set of nspr adds (2902)
14:26:11 <licquia> #info handle 3830 by indicating "failed-but-ok" state on buildbot screens
14:26:23 <licquia> #agreed handle 3830 by indicating "failed-but-ok" state on buildbot screens
14:26:32 <licquia> wrong tab
14:26:34 <licquia> tag
14:26:41 * licquia can't type today, either
14:27:20 <mwichmann> we're having a spate of fall weather, and I think it's confusing me
14:27:36 <licquia> ok, back to 3831
14:27:54 <licquia> decided the MEDIATOR_FAILED stuff in olver deserved its own rollup
14:28:14 <licquia> that seems to happen often enough that we should have a better way to report those bugs
14:28:35 <licquia> (though, am also testing a patch which supposedly fixes a pile of them)
14:29:16 <mwichmann> well, it presents a theory which can be worth exploring:
14:29:34 <mwichmann> can mediator-fails in general be attributed to faulty setup?
14:30:20 <licquia> if i remember correctly, MEDIATOR_FAILED is basically "some part of the test apparatus fell over"
14:30:43 <licquia> for example, the proposed ncurses fix was due to an uninitialized variable
14:31:02 <mwichmann> right, in the agent it talks to, rather than in individual tests
14:31:09 <licquia> correct
14:31:11 <mwichmann> I think most (all) groups of tests have an "agent"
14:31:51 <mwichmann> so maybe if we gt a new rash of these, the first thing to look at is if something is now failing in the agent?
14:32:12 <mwichmann> I think those are kind of hard to look at, you tend to trace the testcase execution instead, and then scratch your head
14:32:39 <mwichmann> anyway... what can we say about the bug?
14:33:02 <licquia> that's what i'm thinking needs improving: instead of just saying "mediator failed", we should have a bunch of post-mortem information about which mediator, how it failed (segfault, SIGABRT, bad return value, etc.)
14:33:20 <mwichmann> I bet that would help
14:34:04 <licquia> the other purpose: isolate the specific fails from the stable update cycle w/o losing track of them
14:34:57 <licquia> so: mark assigned, otherwise leave alone?
14:35:24 <mwichmann> seems right, add whatever comments you like to clarify
14:36:28 <licquia> #agreed mark 3831 assigned, add note re: task to do for bug
14:36:53 <licquia> ok, that's done; want to go back to 2902?
14:37:05 <mwichmann> sure
14:37:16 <mwichmann> since I want to stop working on it :)
14:37:23 <licquia> !lsbbug 2902
14:37:25 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=2902 enhancement, P2, 4.1-updates, mats, ASSIGNED , RFE: Add symbols for libnspr4
14:38:14 <mwichmann> #info with two rounds of changes (one not yet pushed), nspr4 has gone from 36 to 86 interfaces
14:39:49 <mwichmann> second round has a patch, and a diff of headers, attached to bug
14:40:06 <mwichmann> if that's okay, I'll push it and hope nothing more happened
14:40:08 * licquia reads
14:40:44 <licquia> don't see anything that jumps out at me
14:40:52 <licquia> so i'd say: push, and let's see what happens
14:41:15 <mwichmann> visual check indicates all prototypes are okay, devchk will tell us more though
14:41:37 <mwichmann> though devchk would need a great deal of work to go back to working on native
14:41:57 <mwichmann> does anyone remember if there's a bug on "devchk useless on lsb-only headers"?
14:41:57 <licquia> noted
14:42:08 <licquia> don't recall
14:42:14 <mwichmann> I know there was a suggestion somewhere, maybe just in email
14:42:23 <mwichmann> guess I'll file
14:42:55 <mwichmann> maybe it's more "procedure" than "bug"
14:43:20 <licquia> #info push latest work on 2902, see what happens
14:43:30 <licquia> want to do more 5.0 bugs?
14:43:38 <mwichmann> we can
14:43:49 <licquia> !lsbbug 2970
14:43:52 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=2970 enhancement, P2, 5.0, mats, ASSIGNED , RFE: Add ncurses extensions to LSB
14:44:34 <licquia> this is different from ncursesw
14:44:45 <mwichmann> yes
14:45:03 <licquia> looks like the merge has happened; any indication that there's more to do here?
14:45:04 <mwichmann> it's actually suggesting some stuff that's beyond your guideline there
14:45:19 <mwichmann> doc links
14:45:43 <mwichmann> we have a link-checker tool, we could maybe defer worrying about it when we run that
14:46:32 <mwichmann> so let's mark this done
14:46:34 <licquia> i think my guideline is more about "keep ncurses and ncursesw in sync"; if we decide it's a good idea to add to ncurses, then we should do it both places
14:47:02 * licquia is cool with that; we know we'll have work to do on missing docs
14:47:05 <mwichmann> well, you see in comment #3 what the flow was....
14:47:13 <licquia> true
14:47:25 <mwichmann> "how about we add".... nothing for 2.5 years
14:47:43 <mwichmann> "look, they're in the ncursesw import, so we could just go ahead and make the match"
14:47:58 <mwichmann> anyway, I'm not worried
14:48:00 <licquia> #info resolve 2970
14:48:17 <licquia> !lsbbug 3264
14:48:20 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3264 enhancement, P2, 5.0, mats, ASSIGNED , RFE: add pam_get_user, pam_set_data
14:49:23 <mwichmann> seems like this work is not done
14:49:40 <licquia> looks that way
14:49:56 <licquia> #info work for 3264 is still not done
14:50:18 <licquia> anything more to say?  don't think the actual conclusions are any different
14:51:01 <mwichmann> no, it's just how to untangle the header mess
14:51:14 <licquia> ok, moving on then
14:51:23 <licquia> !lsbbug 3469
14:51:26 <mwichmann> and whether that untangling is done for all LSB versions, or just for 5.0
14:51:26 <lsbbot> licquia: 04Bug http://lsbbugs.linuxfoundation.org/show_bug.cgi?id=3469 enhancement, P2, 5.0, mats, ASSIGNED , RFE: uplift LSB to POSIX 2008
14:52:17 <mwichmann> honestly, I don't know how to conclude if we're done or not
14:52:21 * licquia saw a discussion on linux-api re: this very subject
14:52:45 <licquia> they're talking about adding the kernel bits for those two posix 2008 features we don't support
14:53:25 <mwichmann> hmmm
14:53:34 <mwichmann> that would be hard to required for 5.0 though
14:53:38 <licquia> true
14:53:46 <licquia> but still, something interesting
14:54:08 <mwichmann> in general, I've muddled through a bunch of lists, awk'd this and sed'd that and so on
14:54:26 <mwichmann> I think all the key pieces are switched over, including the doc links
14:54:44 <mwichmann> but there's no test to "prove" it's done
14:54:59 <licquia> ok; did we deprecate the long list of withdrawn functions?
14:55:21 <mwichmann> I don't recall
14:55:48 <licquia> ok, so someone needs to basically review the list of todo items and make sure they all arrived in some form
14:56:10 <licquia> with the deprecation list being one in particular to check
14:56:15 * licquia volunteers
14:56:23 <mwichmann> sampling one, I see a recommendation for setcontext, but not a deprecation
14:56:29 <mwichmann> http://linuxbase.org/navigator/browse/int_single.php?cmd=list-by-name&Ilibrary=libc&Iname=setcontext
14:56:32 <licquia> probably best to have a second set of eyes on those
14:56:46 <mwichmann> ab-so-lutely
14:56:51 <licquia> aha, so clearly the extra deprecations didn't happen
14:56:58 <licquia> ok
14:57:31 <licquia> #action licquia review the list of items for 3469, and create sql for the deprecation list
14:58:00 <licquia> ok, think that should keep me busy :-)
14:59:49 <licquia> #info lsb 5.0 bugs not reached, carry over to next week: 3470, 3550, 3659, 3757, 3758, 3759, 3778
15:00:07 <licquia> so, anything else, or should we call it a meeting?
15:00:34 <orc_fedo> I have no conflict til local noon
15:01:35 <mwichmann> looks like there's something in comment 13 that may need a look...
15:01:58 <mwichmann> we turned AIO back on, did some POSIX constant need to be kicked, that I didn't remember to do?
15:02:16 <licquia> worth checking
15:02:20 * licquia adds a comment
15:03:30 <mwichmann> I'm going to wander off and do non-LSB things, so I think ending here is ok
15:03:39 <licquia> alrighty
15:03:58 <licquia> #endmeeting